MoE 专家触达率 · 被低估的显存带宽杀手
「激活 50B 参数」只在 batch=1 成立。批越大，每步需要读的专家权重越接近总参数量
| batch | 期望触达专家 | 触达率 | 每步需读权重 | 等效"激活参数" | 摊到单序列 |
|---|
这是 MoE 部署最反直觉的一点。 稀疏 MoE 省的是 FLOPs，不是 显存带宽。当 batch 足够大，每个 decode step 几乎要把所有专家权重都从 HBM 读一遍，此时 MoE 的带宽行为逼近同参数量的 dense 模型——但它换来的是每 token 的算力只有 dense 的 1/56。推论：MoE 部署应优先选高带宽卡，而非高算力卡。
评估框架方法论
Step 0 · 先分清你在算哪个问题
「要几张卡」有三个互不相同的答案，混淆它们是最常见的估算错误：
- 装得下（Capacity-bound）——权重 + KV + 激活 ≤ 集群总显存。这是原信息图回答的问题，也是下界。
- 跑得动（Latency-bound）——满足 TTFT / TPOT SLA。通常比装得下多要 1.5–4× 的卡。
- 扛得住（Throughput-bound）——满足 QPS × 平均输出长度。这才是生产环境真正的定卡依据。
最常见的翻车姿势：按「装得下」买了 2 台 B300，上线发现 TPOT 40ms 用户嫌卡，或并发到 30 就 OOM——因为 KV Cache 被漏算了。
Step 1 · 权重显存
N_total × bytes/param。注意量化格式的 scale 开销（MXFP4 +6.25%）、以及 embedding / lm_head 是否共享权重、是否量化（通常保持 BF16，对超大 vocab 是 GB 级差异）。
Step 2 · KV Cache（最容易被漏算的一项）
KV 随 并发 × 上下文长度 线性增长，长上下文场景下常常超过权重本身。三个数量级的架构差异：GQA ≈ 250 KB/token，MLA ≈ 34 KB/token，混合线性注意力可再降 4–8×。
Step 3 · 激活值与工作区
推理的激活峰值出现在 prefill：批token数 × hidden × 精度 × 系数。MoE 还额外需要 dispatch/combine 缓冲（token × top-k × hidden × 2）。经验上占权重的 3–10%，但长 prefill 批下可以爆到 100 GB 量级。
Step 4 · 固定开销与碎片
每卡 2–4 GB 的 CUDA context / NCCL buffer / cuBLAS workspace / CUDA Graph 捕获，不随分片减少。再叠加 5–10% 的分配器碎片。这就是「20% 冗余」经验值的来源——但它是粗糙的合并系数，本框架把它拆开算。
Step 5 · 选择并行策略（决定分片效率）
同样的显存需求，TP=8 / EP=64 / PP=4 的实际落盘方式完全不同。见「并行策略选择」页。
Step 6 · 反推吞吐，校验 SLA
Decode 用 Roofline 的带宽侧：每步读多少字节 ÷ 有效带宽。Prefill 用算力侧：2N·T FLOPs ÷ 有效算力。两边都要留 MBU/MFU 折扣。
Step 7 · 折算成 $/1M token，与 API 比价
这一步会让很多「自建更便宜」的直觉当场翻车。见「自建 vs 调 API」卡片。
1 · 权重显存
# 稠密 / MoE 通用
M_weight = N_total × b_w
# 量化格式的有效字节数
b_w(FP16) = 2
b_w(FP8) = 1
b_w(MXFP4) = 0.5 + 1/32 = 0.53125 # block=32, E8M0 scale
b_w(INT4-g128) = 0.5 + 2/128 + 2/128 = 0.53125 # scale+zero, FP16
# MoE 结构拆分（由 total / active 反解）
r = k / n_expert
N_dense = (N_active − N_total·r) / (1 − r)
N_expert = N_total − N_dense
2 · KV Cache
# 标准 GQA / MHA，每 token 每层
kv_per_tok = 2 × L_full × n_kv × d_head × b_kv
# MLA（DeepSeek / Kimi K2 系）：只存压缩潜向量 + RoPE 分量，不乘 2
kv_per_tok = L_full × (d_c + d_r) × b_kv
# 混合线性注意力：只有全注意力层随长度增长
L_full = L × ρ_full # ρ = 全注意力层占比
# 线性层为固定状态，≈ L·(1−ρ)·n_head·d_head·d_state·b，与 seq_len 无关
M_kv = kv_per_tok × ctx_avg × batch
3 · 激活值与工作区
M_act ≈ T_prefill × d_model × b_a × c_1 # c₁ ≈ 8–20（框架相关）
+ T_prefill × k × d_model × b_a × 2 # MoE dispatch + combine
+ logits: T × V × 4 # 大 vocab 时不可忽略
4 · 总需求与卡数
M_total = (M_weight + M_kv + M_act) × (1 + f_frag) + n_gpu × M_fixed
n_gpu = ⌈ M_total / C_gpu ⌉ # 隐式方程，需迭代求解
n_node = ⌈ n_gpu / 8 ⌉ # NVLink 域粒度取整
5 · Decode 吞吐（带宽 Roofline）
# MoE 关键：batch 下期望触达的专家数
E_touched(B) = n_expert × [ 1 − (1 − k/n_expert)B ]
# 每个 decode step 需从 HBM 读取的字节
Bytes_step = [ N_dense + N_expert × E_touched/n_expert ] × b_w
+ kv_per_tok × ctx_avg × batch
TPOT = Bytes_step / ( n_gpu × BW_gpu × MBU )
吞吐_cluster = batch / TPOT 单序列速度 = 1 / TPOT
6 · Prefill 延迟（算力 Roofline）
FLOPs_prefill = 2 × N_active × T_prompt # 前向 2N 法则
+ 2 × 2 × L_full × n_head × d_head × T_prompt² # 注意力二次项
TTFT ≈ FLOPs_prefill / ( n_gpu × FLOPS_gpu × MFU )
交叉点：当 T_prompt > 2·N_active / (2·2·L_full·n_head·d_head) 时，注意力二次项开始主导 prefill——这正是 1M 上下文必须上线性注意力的根本原因。
7 · 成本
# 云租赁
$/hr = n_gpu × price_gpu_hr
# 自建 TCO（每 GPU 每 wall-clock 小时，不含 util 折扣）
$/gpu·hr = capex/(years×8760) + TDP_kW × PUE × price_kWh
# 单位 token 成本 —— util 折扣只在这里施加一次
$/1M_out = $/hr / (吞吐_cluster × 3600) × 10⁶ / util
# 盈亏平衡：每月需产出多少输出 token 才追平 API
T_breakeven = ($/hr × 730) / price_api_out_per_M # 单位 M tok/月
易错点：利用率 util 只能除一次。若在「每小时持有成本」里除过 util，又在「$/token」里再除一次，自建成本会被系统性高估约 1/util²，常见于 Excel 版本的 TCO 模型。
四种并行的显存与通信画像
| 策略 | 权重分片 | KV 分片 | 通信量/层 | 适用域 | MoE 场景建议 |
|---|
| TP 张量并行 | 全部 ÷TP | ÷TP（按头切） | 2× AllReduce(T×d) | NVLink 内，TP≤8 | 用于 attention + dense 部分 |
| EP 专家并行 | 仅专家 ÷EP | 不分片（复制） | All2All(T×k×d)×2 | 可跨节点，EP 可到 64–320 | MoE 主力，K3 这种 896 专家必须用 |
| PP 流水并行 | 按层 ÷PP | 按层 ÷PP | 点对点 T×d | 跨节点，带宽要求最低 | 显存实在不够时的兜底，但引入气泡 |
| DP 数据并行 | 不分片（复制） | 各自独立 | 无（推理） | 任意 | 扩吞吐用，代价是权重多份副本 |
MoE 大模型的典型配方
# Prefill 集群（算力密集，追求高 MFU）
TP=8（节点内）× EP=节点数 × DP=1 # 大批 token，少并发
# Decode 集群（带宽密集，追求高并发）
TP=8（节点内）× EP=大（跨节点）× DP=多副本
# 关键：EP 越大，单卡承担的专家越少 → 单卡权重读取压力越小
# 但 All2All 通信量与 batch 成正比，跨节点带宽会成为新瓶颈
# PD 分离（Prefill/Decode Disaggregation）
# 两类节点独立扩缩容，通过 KV 传输衔接 —— 长上下文场景收益最大
EP 的显存直觉：896 个专家分到 EP=64，每卡只放 14 个专家。但 attention / 共享专家 / embedding 这些 dense 部分在每个 EP rank 上都要有一份——EP 开太大时 dense 副本会反噬显存。这是 EP 的实际上限来源。
负载不均衡：EP 下各卡专家被路由到的概率不等（尤其在 domain-specific 流量上），实测 P99 卡的负载可能是均值的 2–3×。需要 EPLB（专家负载均衡 / 冗余专家副本）——这会额外吃显存，务必在预算里留出 5–15%。
精度选择：先问「量化是训练时的还是事后的」
| 精度 | B/param | 硬件要求 | 质量损失 | 适用判断 |
|---|
| BF16/FP16 | 2.0 | 全部 | 基线 | 需要复现论文数值 / 做后训练时的参考 |
| FP8 (E4M3) | 1.0 | Hopper+ 原生 | <0.5% | 生产默认值。2× 显存 + 2× 带宽，几乎无损 |
| INT8 (W8A8) | 1.0 | Ampere+ 也可 | 0.5–2% | 老卡（A100/A800）上的 FP8 替代 |
| MXFP4 (QAT) | 0.531 | Blackwell 原生 | 接近无损 | 训练时就是 FP4（K3 走这条路），不是后量化，可放心用 |
| FP4/INT4 (PTQ) | 0.531 | Blackwell / 软件模拟 | 2–8% | 只在显存实在放不下时用，务必先跑领域评测 |
| KV FP8 | — | 广泛 | 可忽略 | 几乎总该开。长上下文下省的比权重量化还多 |
决策顺序（按性价比排）：① 先开 KV Cache FP8 → ② 权重降到 FP8 → ③ 上 PagedAttention / 前缀缓存压 KV → ④ 加 EP 摊薄权重 → ⑤ 最后才考虑权重 FP4。前四步几乎无损，第五步才需要做质量回归。
一个高频误判：「量化到 FP4 显存减半，所以吞吐翻倍」——只在 decode 且带宽受限时成立。Prefill 阶段是算力瓶颈，FP4 的收益取决于硬件是否有原生 FP4 Tensor Core（Hopper 没有，软件反量化反而更慢）。
对原信息图的复核结论
原图的核心口径正确，机器数换算与 8 卡整机口径完全对得上，但有两处值得注意：
| 项 | 原图数值 | 按其自述公式复算 | 判定 |
|---|
| FP16 总需求 | 6720 GB | 5600 × 1.2 = 6720 | 一致 |
| FP8 总需求 | 3360 GB | 2800 × 1.2 = 3360 | 一致 |
| FP4 总需求 | 1400 GB | 1400 × 1.2 = 1680 | 漏乘 20% |
| FP16 → B300 | 3 台 | ⌈6720/(288×8)⌉ = 3 | 一致 |
| FP16 → H200 | 6 台 | ⌈6720/(141×8)⌉ = 6 | 一致 |
| FP16 → H100 | 11 台 | ⌈6720/(80×8)⌉ = 11 | 一致 |
原图未覆盖、但会决定成败的四件事
- KV Cache 完全没进公式。1M 上下文是 K3 的卖点，而 KV 在长上下文下可以轻松超过权重本身。原图的「20% 冗余」明确写的是「激活值、通信缓存、系统上下文」，KV 是另外要加的。
- 「装得下」≠「跑得动」。1 台 B300 装得下 FP4 权重，但那 8 张卡要扛住 2.8T 参数在大 batch 下的带宽压力，TPOT 会很难看。
- MoE 的带宽行为随 batch 变化。「896 选 16」在 batch=256 时实际触达 99% 的专家——稀疏性在服务端几乎消失。
- H100 不支持原生 FP4。原图 FP4 行里的「3 台 H100」在硬件上需要软件模拟反量化，实际吞吐远不如 Blackwell，这一格的可比性存疑。
本框架自身的不确定度
- K3 的层数、注意力头配置、KDA 全注意力层占比尚未公开（技术报告随 7/27 权重一并发布）。本页 K3 预设中的这些值是基于同类混合架构的合理估计，已在预设名中标注「估」。总参数量、专家数、top-k、激活量、MXFP4 QAT 为官方公开值。
- MBU 70% / MFU 40% 是社区在成熟推理栈（vLLM / SGLang / TRT-LLM）上的常见区间，实际值随框架版本、kernel、批调度策略波动 ±15pp。
- 专家触达率公式假设路由均匀独立。真实流量有强 domain 局部性，实际触达率通常低于理论值——本框架在这一点上是保守（偏悲观）估计。
- GPU 单价随供需剧烈波动，表中为 2026 年中的公开报价中位区间，仅作量级参考。