1. “1T 参数”到底描述了什么

参数量是 checkpoint 中可学习权重的总量。dense 模型每个 token 通常经过大部分 FFN 权重；稀疏 MoE 则把大量 FFN 分成专家，router 只选少数专家参与该 token 的前向。因此总参数、激活参数、每层激活参数和每 token FLOPs 是不同概念。它们分别决定存储容量、算力、通信与成本，必须分开报告。

把总参数笼统写成“模型大小”会混淆计算与存储。MoE 让单个 token 的计算远低于同规模 dense 模型，但未按需换出的专家仍要分布在 GPU HBM 或更低层存储中。稀疏计算不会自动解决权重常驻。

2. 在讨论某个模型前，先冻结版本和部署假设

同名模型可能有 base、instruct、不同上下文、不同精度 checkpoint 和不同 runtime 适配。为了避免“看起来相同、实际不可比”，每次讨论都应写清 checkpoint hash、权重格式、是否有量化 scale、tokenizer、最大上下文、top-k、是否启用 speculative decoding、GPU 型号、节点拓扑及 runtime 版本。开放权重也不等于所有权重格式、推理内核和许可条件相同。

题名本身不能推出 K2 的层数、专家数或激活参数。精确结构要查官方 model card、仓库和 release；下面只给出适用于超大 MoE checkpoint 的分析方法。

3. 第一步是显存账本，而不是先选并行策略

设总参数 P、存储位宽 b，裸权重下界为 P×b/8。真实 HBM 还包含量化 scale、非量化层、KV cache、激活、kernel workspace、collective buffer、CUDA Graph capture 和 allocator 余量。以总参数非常大的 MoE 为例，即使 token 只激活少数专家，未 offload 的专家总体仍必须有 owner。因此先算每个 shard 的常驻权重和目标并发下的 KV，才能得到可运行而非“刚好装下”的卡数下界。

M_GPU = M_weight_shard + M_KV + M_activation_peak + M_workspace + M_collective + M_graph + fragmentation + headroom N_min ≥ ceil(M_total_weights / usable_HBM), usable_HBM < physical_HBM

为所有 GPU 预留同样的 KV 空间不一定合理。EP owner 的权重大小、热点专家和 TP shard 可能不同，应该按最大 shard 与最坏路由余量规划。任何“每卡还有 X GB”都要来自实际 allocator 报告而非纸面物理容量。

4. MoE 的一个 token 具体做了哪些工作

hidden state 先经过 attention 和共享路径，router 产生对专家的排序与 gate；token 被按 owner 打包、跨 EP group 传输、在目标 GPU 上按 expert 分组做 MLP，再传回并按 gate 聚合。每层的计算量主要随被选专家数、hidden/intermediate 维度和 token 数增长；通信量则随 hidden payload、top-k、rank 映射与 token 分布增长。

compute(token) ≈ attention + shared_FFN + k × expert_FFN communication(token) ≈ dispatch(hidden) + combine(hidden) memory(resident) ≈ all loaded expert weights + KV + runtime buffers

这三项的比例随 prefill/decode 改变。prefill 有较多 token，专家 GEMM 容易形成较大矩阵；decode 每轮 token 少，KV 读取、通信启动与小 GEMM 更突出。不能用 prefill 的矩阵利用率来宣称交互 decode 同样高效。

5. 大 MoE 的并行 mesh：每个维度解决不同问题

EP 把专家分开，解决权重容量并引入 token all-to-all；TP 切同一层的大矩阵，减小单卡权重/计算却引入逐层 collective；PP 把连续层分成 stages，减轻每个 stage 的权重容量但有流水气泡；DP 复制执行 mesh 增加总吞吐；CP 切上下文/KV，解决极长序列而添加 attention 通信。大型部署通常是这些维度的组合。

并行度不能只由“模型多大”确定。它必须服从真实拓扑：TP 放在最快 scale-up 域，EP 放在可承受 all-to-all 的网络域，PP 才可跨较弱链路。查看 并行与放置 能把这个 mesh 转成容量和延迟的可计算问题。

6. 专家通信为何会决定一个万亿模型的实用性

总参数变大通常意味着专家数量、expert shard 或 EP group 也变大。每层所有 token 都要依路由去往 owner，最慢 rank 决定一步完成时间。网络带宽不足、GPU-NIC 映射失衡、热点专家或小消息启动开销都会抵消“低激活参数”的计算优势。EP 需要按动态路由下的最大流量和尾部设计，平均数据量不足以描述压力。

观察指标至少包括每 rank 的 send/recv token、每 expert token、dispatch/combine P50/P99、链路利用率、热点与均值之比。将专家权重再复制几份可能缓解热点，但会增加 HBM 和一致性/加载成本；迁移专家可能缩短流量路径，却需要处理权重传输与路由映射。没有 trace，任何策略只是猜测。

7. 万亿参数并不替代 KV 容量规划

权重与 KV 是不同时间尺度的内存。权重启动后长期驻留；KV 随每个会话增长，直接限制在线并发和最长上下文。模型越大，权重占据的 HBM 越多，留给 KV 的空间可能越紧。将所有 GPU 用于承载专家后，若没有足够 attention/KV 空间，系统仍无法满足交互请求。

KV 容量应按精度、GQA/MQA、页面大小、上下文分桶和淘汰策略估算，不能只追求压缩率。prefix cache 可以降低重复 prefill，但需要路由局部性；KV offload 扩展容量却增加回取延迟；P/D split 能各自优化 prefill 和 decode，却引入 KV 传输。详见 KV cache 与内存。

8. Serving 的单位不是“模型”，而是可伸缩的 execution mesh

一组固定 TP/EP/PP rank 构成一个 execution mesh，能服务一个或多个并发 batch；多个 mesh 构成可独立扩缩的副本。副本数量增加会复制某些权重，但也提升故障隔离和总吞吐。请求 router 需在最短队列、prefix 命中、KV 位置、专家负载和期限之间折中。简单的轮询通常既损失 cache，又制造尾部热点。

对于长推理链，调度器要为输出长度不确定性留余量。连续批处理在每轮回收结束 slot、补充新 token，可提高利用率，但必须限制 prefill 对 decode 的干扰。SLO 目标应使用 TTFT/TBT 的分位数和 successful goodput，而不是只报告某一批的峰值 token/s。

9. 量化、投机解码和 offload 是不同层次的杠杆

权重量化主要减少常驻 HBM 与读取字节；KV quantization 主要增加会话容量；投机解码以额外 draft/验证计算换取每轮接受多个 token；专家 offload 以更低层存储换取更大的容量，但增加预取和 miss 风险。它们可以组合，却不能互相替代。比如把权重压小后，瓶颈可能从 HBM 转到 EP 通信；增加 speculative token 后，KV 与验证 batch 又可能成为瓶颈。

上线前应建立误差与性能的二维图：不同位宽下的准确度、格式遵循、长上下文与工具调用；不同 acceptance rate 下的延迟和成本；offload hit/miss 对 P99 的影响。只在短 benchmark 上接受的量化或 draft 策略，可能在长生成和高并发下失效。

10. 训练和推理共享模型图，不共享最优集群配置

训练需要梯度、优化器状态、反向激活和同步，目标多为 MFU、训练稳定性和全局 batch；推理没有反向，却有长寿命 KV、连续到达、TTFT/TBT 和多租户隔离。训练时可接受长 pipeline 或固定 batch，在线 serving 则更怕 stage 不均、动态上下文和请求取消。将训练 mesh 直接拿来 serving，常会让通信、KV 和副本粒度不合理。

从训练规格可学习模型的并行可行域，但不能推出生产卡数。生产评估应从实际 checkpoint、目标精度、负载 trace 和服务 SLO 开始，独立扫描 TP/EP/PP/DP 和缓存策略。

11. 当大 MoE 服务变慢时，按这张清单排查

  1. 确认版本身份：checkpoint、量化、runtime、GPU/NIC 拓扑是否与基线一致。
  2. 分开测 prefill 和 decode，并按 prompt/output/context 分桶，防止平均值遮蔽问题。
  3. 审计每卡 HBM：专家权重、KV、workspace、通信 buffer、碎片和预留余量。
  4. 记录每层 EP dispatch/combine 与专家 GEMM，找出最慢 rank 和热点专家。
  5. 记录 TP collective、PP stage idle、GPU-NIC 亲和性，确认不是 mesh 映射错误。
  6. 在固定 trace 下单变量扫描并行度、batch、chunk、KV 策略和精度，保留原始 profile。

12. 容易犯的五个结论错误

“激活参数小，所以单卡可跑”：忽略了所有常驻专家、共享层和 KV。
“加 EP 一定更快”：EP 增大同时增加 all-to-all 范围和小消息开销。
“GPU 总数足够就是容量足够”：最大 shard、通信 buffer、故障余量和 KV 分布可能先失败。
“总 token/s 上升说明更好”：若 P99 TTFT/TBT 超标，真实可售 goodput 可能下降。
“开放权重即可直接上线”：仍需验证许可、模型文件完整性、运行时兼容、量化精度和安全运营路径。

13. 容量规划应输出什么，而不是只输出 GPU 数

一个可执行的计划应给出模型权重布局、每个 mesh 的显存账本、最大并发与上下文桶、TTFT/TBT goodput 曲线、按副本的启动时间、允许的故障域、网络流量矩阵和成本。它还应列出在高峰、长上下文、专家热点、升级和单节点失效时的降级动作。GPU 数只是这个计划的一行结果。

最好将计划变成自动化 sweep：读取请求 trace，枚举可行 mesh，测每个点的 HBM、SLO、网络和能耗，输出 Pareto front。这样模型 checkpoint 更新或硬件换代后，团队不必重新靠经验争论，而能复用同一套判断程序。

14. Mainline 的阅读路径

大 MoE 的模型层从 Transformer/MoE 开始；显存与 KV 看 KV cache；参数放置看 并行放置；专家通信看 EP 与 DeepEP；把这些放入集群治理则看 训练/推理集群。这几页合起来才是“万亿参数能否服务”的完整答案。

15. 一手资料入口与时间边界

来源用途
Kimi K2 官方仓库入口应以发布说明、模型卡和许可为准核对结构与版本。
DeepEP 官方仓库MoE dispatch/combine 的公开系统实现入口。
Mainline：2026 前沿开放模型模型状态与证据边界的横向导航。

链接若因上游版本或仓库迁移发生变化，应以模型发布方当前主页为准。本文不会从标题中推断未给出的具体参数、许可或性能数字。