低并发场景自建MoE真的划算吗?

最近看到不少朋友在聊 MoE 架构，尤其是看到某些标称总参数 320B、每次生成却只激活 18B 的开源模型，大家第一反应往往是：“这算力成本不是直接打下来了吗？我们要不要自己拉几台机器搞一套？”每次听到这种想法，我都忍不住想拉住对方倒一杯苦水：朋友，低并发场景下自建 MoE，大概率是在给自己挖坑。

很多人把“激活参数小”直接等同于“部署成本低”，但这其实是两本完全不同的账。我刚开始算这笔账时也差点陷进去，后来才彻底想通：活跃参数决定的是每次前向计算花多少算力，但总参数卡死的却是实打实的显存容量。一个 320B 的大家伙，即便用 FP8 精度跑，光是模型权重就得吃掉 320GB 左右的显存，哪怕上了 FP4 也得 160GB 起步。这还没算上 KV 缓存、激活值和通信缓冲。为了把这套模型跑起来，你必须先搞定多卡甚至多机环境。显卡插在机架上，只要开机待命，每一秒都是真金白银的硬件折旧和电费，显存账本可不会因为你请求少就给你打折。

为什么低并发会把优势变成劣势

MoE 架构的省钱魔法，核心依赖的是高并发环境下的批量处理能力。混合专家网络的运作机制很清晰：门控网络把不同的 token 分发给对应擅长的专家子网络去计算。云厂商之所以能把 API 价格压得很低，是因为他们有海量的并发流量，一个批次里能塞进成千上万个 token，各个专家都能被喂得饱饱的，硬件利用率直接拉满。

但在低并发或者单用户的场景下，实际情况往往非常尴尬。由于发过去的请求稀稀拉拉，某些专家拿到了几个 token 在算，大部分专家却在空闲摸鱼，跨设备的通信调度开销反而占了大头。这时候 GPU 算力根本跑不满，大量的卡都在原地等待。我们自以为省下了计算量，结果单位 token 摊下来的硬件成本，反而比老老实实跑一个同等能力、完全占满的小体量稠密模型还要昂贵得多。

算清账再决定是自建还是调接口

如果你的业务场景每天就几十次内部调用，或者峰值并发只有个位数，自己花大价钱租上几张卡去扛那个庞大的总参数，真的极其不划算。不仅要承担静态的显存占位成本，还得在长上下文来临时担心缓存爆掉，更别提量化后可能带来的精度折损与复杂的运维负担。

看到这种大稀疏比例的架构，千万别被那个诱人的激活参数冲昏头脑。除非你的数据有极高的合规壁垒必须本地化，或者团队已经有现成的集群在闲置，否则在业务并发量真正跑起来之前，老老实实用云厂商调度好的现成服务，省下的机器钱和运维精力，足够把产品打磨好几个来回了。