背景：两个厂商在同一天给了两组可对照的数字
整个事情的起点是这两个数字摆到了一起——
一边是蚂蚁百灵的 Ling-3.1-flash：总参数约 5600 亿，每 token 激活约 250 亿，最高 100 万上下文。它对路由专家用 MXFP4 量化，dense 层保留 block-FP8，权重占用从约 534GB 降到 292GB，团队给的 Hopper 配置里部署卡数由 8 卡降到 4 卡。
另一边是 Meta 的 Muse Spark Open：8160 亿总参、420 亿激活，苹果把它压到 4bit 后约 493GB，用雷雳 5 串两台 Mac Studio 就能跑，官方实测两台约 25 token/秒、四台约 37 token/秒。
这两组数字给了一个很少见的对照机会：同样是稀疏 MoE，同样的量化思路，落到不同的硬件上，账怎么算？
我手头没有这么多卡，但算账这件事不需要卡。所以写了个脚本。
技术要点一：从「总参 / 激活」反推专家规模
稀疏 MoE 有两个方程：
其中 E 是专家总数，k 是每个 token 选中的专家数，dense 是注意力、嵌入、路由这些每个 token 都要走的部分。两式相减就能解出 per_expert = (total - active) / (E - k)，再回代得到 dense。
这一步是整套测算的地基，也是最容易被忽略的假设。因为 E 和 k 厂商通常不公布，你得先猜。
跑一下就知道了。对 Muse Spark Open 我尝试了四组猜测：
看出来了么？前三组完全一样。因为真正决定专家总规模的是 E / (E - k) 这个比值，也就是 k/E——前三组的 k/E 都是 1/32。所以你不需要知道真实的专家数，只需要知道激活比例。
这是我在写脚本时意外捡到的一个结论，比脚本本身值钱。
技术要点二：分层位宽才是 MXFP4 的全部秘密
很多同学看到「534GB → 292GB」会以为全模型都压到了 4bit。不是。
按 Ling-3.1-flash 的数字用 E=256、k=8 反推，路由专家总体约 5523 亿参数，非专家部分约 77 亿。如果专家走 MXFP4、dense 走 block-FP8：
官方口径是 292GB，差 9.5%。这个差额我很满意——它说明模型结构合理，剩下的多半是英文二者的单位差异（GiB vs GB）和我没计入的嵌入层、多模态 tower。
反过来，专家在其中占 99% 以上。这意味着对 dense 层做不做 FP8 几乎不影响结果，真正决定显存的是你敢不敢把专家压到 4bit。
技术要点三：100 万上下文才是真正的吞卡怪兽
这部分是很多人算漏的。权重是一次性的，KV cache 是随会话涨的。
单条 100 万 token 的会话，FP8 精度下就要 175 GiB。 这比整个模型的权重还大得多的地方在于，权重是全局共享一份，KV 是每条会话各一份。
所以阶跃在 Step 5 Preview 里把「上下文压缩纳入强化学习」这个动作，我现在能看懂了：压到一半省 87.7 GiB，压到四分之一省 131.6 GiB。这不是为了更聪明，是为了装得下。
技术要点四：块级索引省的是「找」，不是「存」
这里有个很容易混的账。阶跃的 Sparse GQA 把相邻 8 个 token 合并成索引块，官方说索引与 top-k 选择的开销降到原来的八分之一。
脚本里可以验证：
但请注意：它省的是检索时的计算与选择开销，不省 KV 本身的体积。 这两个是完全不同的账。我见过有人把「开销降到 1/8」理解成「KV 也降到 1/8」，然后信心满满地接了 8 倍并发，上线当天 OOM。
完整脚本
零依赖，Python 3 标准库，输出确定（连跑两次 diff 为空）。保存为 moe_deploy_calc.py 直接跑。
实跑输出
三个结论
第一，「4 卡跑 5600 亿参数」这件事的前提是路由专家压到 4bit。dense 层留不留 FP8 影响很小（7.2 GiB vs 14 GiB），真正的大头在专家。所以下次看到「量化后缩小一半」，先问是哪一半。
第二，8 张 H100 装下模型之后，每卡只剩 8.8 GiB，8K 上下文只能跑约 6 条并发。这个数字我自己看到的时候愣了一下。534GB 的权重看起来只需要 8 卡，但加上 KV 你会发现卡几乎全给了权重。长上下文服务真正吃钱的不是权重，是并行会话数。
第三，租比买便宜。官方混合价约每百万 token 0.19 美元，每天 1 亿 token 也才 19 美元。自建的真实理由是数据不出内网和长尾稳定性，省钱从来不是。这句我愿意接受反驳，但请带上电费和折旧表。
踩坑提示
- 别把 GB 和 GiB 混着算。 厂商发布用 GB（10^9），系统和 GPU 用 GiB（2^30），差 7.4%。脚本里统一用 GiB。
- 12% 预留是我拍的。 真实碎片率取决于推理框架和 batch 策略，vLLM 和 SGLang 差不少。
- E 和 k 没公布时，别纠结绝对值，去估 k/E。 前三组的反推结果完全一样就是证据。
- 块级索引省的不是 KV。 前面说过，这条我说第二遍，因为我自己也在群里解释过两次。
- 层数、head 维度、k/E 都来自公开披露加反解。 换成你手上模型的真实架构再说。
