砍掉85%专家，Gemma在一个小任务上还活着

Reddit的r/LocalLLaMA上，用户Accomplished_Ad_56做了一次挺莽的实验：把Gemma 4 26B-A4B这个MoE模型剪到原大小的15%，每层只留8个专家。结果在一个分类任务上，剪枝版和原模型有92%的输出一致；作为参照，Gemma 4 12B和26B在同一批样本上的一致率是90%。

先补背景。26B-A4B里的A4B指每个token大约激活4B参数，MoE靠router在多个专家里选几个干活。作者每层只保留8个专家，而模型默认每个token正好选8个，router没得选，模型实际上变成dense，参数3.81B，Q4_K_M量化后2.75GB。按他的说法，模型体积从14.5GB缩到3.8GB，在Mac上跑到79 tokens/s，大约是12B的两倍，内存约一半。

他做这个是为了一个24/7跑在设备上的LLM应用，内存和能耗卡得死。目标很窄：让模型在一个足够小、能稳定干好的任务上工作，不指望它还能聊天。训练方法叫block-local training，作者说他不训练答案，训练思考过程：同样输入下，让每个block做同样的计算，产生同样的结果。剪枝本身是分析方法，不需要backprop或训练。他用自己数据在笔记本上过夜训完，并估计这套方法能在约5GB内存里跑在用户设备上，用用户自己的数据缓解部署数据与训练数据不一致的问题。这个设备端训练还没在真实用户设备上验证。

讨论里，Marrk直接叫它“神经网络脑叶切除”，作者回“THATS WHAT I SAID lol”。玩笑归玩笑，问题很实在：权重里很多信息没被测到。跟帖里IntelArtiGen提到，被剪掉的权重可能在记细节知识，问它trivia会明显变差，让它写科幻故事反而不容易露馅。作者也承认，模型在某些任务上会“far worse”，这个实验的目的就是约束到一个小任务。跟帖用户chocofoxy举了例子：abliterated Qwen在coding bench上看着正常，到了Flutter开发却几乎不会用，这种损伤不做针对性测试就看不见。

有人问为什么不用更小的分类模型。作者说性能会掉：他拿Gemma 4 E2B试过，错误率增加约30%，而prompt是按Gemma 12B的分类benchmark手调的。跟帖里coder543问E4B，作者解释E4B的4B是per-layer embeddings，某些运行时可以把embedding放磁盘懒加载，有效参数4B；他剪的是A4B这个MoE，追求的是4GB以内的常驻内存，7GB左右不在考虑范围。

这个实验的价值可能不在“85%权重可以删”这种大结论。它更像一个提醒：在固定任务、固定数据、固定部署环境里，模型里有一大块参数可能对当前任务没有贡献。把它们整个专家拿掉，模型会变快、变小，也会在没测过的地方变笨。作者把博客和翻译模型放出来了，也承认自己算力很少。跟帖里Regular-Register-358还提到ISTA在Flash next上剪过一半专家，并做了coder变体；作者说会看。对做端侧LLM的人来说，这个方向值得看，但别指望剪完还能通用。

博客：https://tolby.app/blog/frankensteining-gemmas-experts

翻译模型：https://huggingface.co/a1cd/shears-translate-en-ja-GGUF