235B MoE 模型每 token 只激活约千分之三参数时，如何估算推理 FLOPs、显存占用、KV Cache 和吞吐瓶颈？

60 秒回答模板

235B MoE 每 token 只激活约千分之三参数，只说明单 token 专家计算量接近 235B × 0.003 ≈ 0.705B 参数参与计算，并不代表部署显存也降到千分之三。权重存储、KV Cache、通信、非 MoE 层和 batch 调度都要单独估算。 先拆参数口径：总参数 235B 决定权重存储和专家分布；激活比例千分之三表示每 token 大约激活 0.705B 参数参与专家计算。未激活专家仍要部署在某些 GPU 上或可被访问，所以它不是显存折扣比例。 用公式估算 FLOPs：专家部分可先粗估为 FLOPs ≈ 2 × active_params × tokens，例如 0.705B 激活参数对应每 token 约 1.41B FLOPs；如果按一次乘加记 1 个 MAC，则约 0.705B MACs。然后再加 attention、非 MoE 层、embedding、router、top-k 选择和采样等成本。 权重显存不能按激活算：fp16 全量权重存储粗略是 235B × 2 bytes ≈ 470GB，量化可降低，但还要考虑专家分片、复制、通信 buffer、运行时碎片和框架开销。训练态 optimizer 不在推理内，但多副本部署会放大权重占用。 KV Cache 单独估算：KV Cache 近似按 layers × batch × seq_len × num_kv_heads × head_dim × 2(K/V) × bytes 估算，具体常数取决于层数、GQA/MQA、head 维度和精度；单卡占用还要按 KV sharding、tensor parallel、sequence parallel 等策略折算。长上下文或大 batch 下，KV Cache 可能比单次激活计算更先卡住显存。 区分 prefill 和 decode：prefill 阶段输入 token 可并行，主要看矩阵计算、attention 和专家通信吞吐；decode 阶段逐 token 生成，batch 调度、KV 读写、路由 all-to-all、专家负载不均和 tail latency 更容易成为瓶颈。 用压测校准估算：理论稀疏率只是起点。真实吞吐取决于 GPU 型号、网络带宽、量化、top-k、capacity factor、专家并行策略、请求长度分布、continuous batching 和 KV 管理。最终要用真实 prompt/output 长度压测 TTFT、prefill tokens/s、TPOT、decode tokens/s、all-to-all 时间、专家负载不均、P95 延迟和 GPU memory peak。 最后要把方案落到可验证的指标、失败兜底和迭代闭环上。面试里不要只讲概念名词，要说明边界、取舍、数据来源、线上观测和出问题后的回滚或人工介入。