MoE 架构，天生适配显存不足的机器

　　大模型对显存的需求，过去几年几乎是一条死规矩：多少参数的模型，就得配多大显存的卡，装不下就是装不下。但混合专家架构正在改写这条规矩，而且它改写的方式，恰好是显存不足的机器最需要的。这类模型的参数大头是几百位“专家”，每次回答只唤醒其中一小撮，其余绝大多数时间在休息；真正每次都要干活的注意力部分，参数量反而很小。这个结构天然就适合拆开摆放：休息的专家丢进大内存待命，干活的密集部分留在显存里全力跑，CPU 和 GPU 各干各擅长的事，谁也不委屈。稠密模型做不到这一点——它的每个参数每次都要参与计算，拆一半到 CPU 上，速度立刻崩掉。所以 MoE 不是“勉强能跑在低配机器上”，而是天生就该这么跑。

　　我最近在一张老 T4 上把这件事验证了一遍。腾讯云那台 GPU 服务器，16GB 显存，Xeon 二十个物理核，78GB 内存，跑的是 Qwen3.6-35B-A3B：350 亿参数，每次激活 30 亿。模型文件 20 多 GB，显存装不下，但按上面的思路拆完，账就平了：所有层都声明上卡，再把其中二十一层专家的权重单独按回内存，每层约占 463 MiB，线性关系清清楚楚。专家参数量巨大但每次只被唤醒二百五十六分之八，算力密度低、访存稀疏，恰好是内存充裕的 CPU 的舒适区；GPU 留给注意力和共享专家这些算力密集的部分。逐档扫描之后定在二十一层而不是二十层，吞吐只差 1.4%，显存余量却多出五成以上。最终实测预填 688 tok/s、生成 40 tok/s，显存停在 15GB 出头，四千多 token 的真实长文七秒跑完。一张按理早该淘汰的老卡，就这样跑通了 350 亿参数的模型，还开满了 256K 上下文。

　　当然，“天生适配”不等于没有代价。生成速度的上限卡在 CPU 的内存带宽上，40 tok/s 一个人用足够，多人同时用就得排队；超长输入的预填也慢，十九万 token 得干等将近五分钟。所以这套玩法适合的是个人推理、小流量场景，而不是对外服务。但方向本身让我觉得值得记下来：显存不足，正在从“跑不了大模型”的死穴，变成“算一算就能跑”的工程题。模型结构在替硬件松绑，读懂结构的人，就能用手头的旧机器接到新一代模型的红利。一张服役多年的 T4 还有第二次生命，这件事本身就挺让人高兴的。