1. 先定义问题：效率要对谁、在什么 SLO 下成立
同一 V3/R1 类服务在离线吞吐、交互聊天、长上下文问答和推理链任务中，最优配置可以完全不同。用户看到的是首 token 延迟 TTFT、相邻 token 间隔 TBT、完成率和价格；运营者还关心每张卡的 goodput、显存余量、排队拒绝率和故障恢复时间。因此“效率高”至少要写清楚输入长度分布、输出长度分布、并发到达过程、精度、GPU 拓扑，以及 P95/P99 约束。
把指标只报成 aggregate tokens/s 容易误导。增加排队时间可以把 batch 堆大，让 GPU 账面吞吐上升，却让短请求的 TTFT 失控。相反，把 decode batch 压得极小可降低单用户 TBT，却浪费矩阵规模并抬高单位 token 成本。生产目标更接近：在 TTFT 与 TBT 均不越界时，系统每秒成功完成多少请求或 token。
2. 模型名不是部署规格：先把可变项拆开
“V3/R1”会同时指向不同 checkpoint、量化格式、上下文上限、提示模板和采样策略。推理链模型的输出往往更长，结束分布更宽，因而比普通聊天模型更容易让 decode 队列和 KV cache 波动。MoE 的总参数、激活参数、共享层、专家数量和每 token top-k 也不是同一个量。没有固定这些条件，任何卡数或 token/s 推论都只是量纲正确的猜测。
建议将一次基准的身份写成一个不可省略的元组：(checkpoint, tokenizer, precision, max_context, max_new_tokens, sampling, runtime_commit, GPU, topology)。遇到两个结果差异很大时，先比较这个元组而不是先怀疑硬件。尤其不要把训练报告中的模型浮点格式直接套用到 serving，也不要把宣传中的 active parameters 当作全部常驻显存。
3. 每个 token 的成本由计算、内存和同步三项组成
decode 阶段一次只新增少量 token。线性层和专家 MLP 有明确的矩阵乘法工作量，但注意力要读取已有 KV；上下文变长后，读取带宽和 KV 地址访问常成为主导。MoE 还多了路由、按专家打包、跨卡派发、专家计算、回收合并这条路径。若 TP、EP 或 PP 分布在多卡，collective 的启动、同步和尾部 rank 都会进入单 token 临界路径。
这里的加号并不意味着所有项串行。好的实现会把局部准备、通信和专家 GEMM 重叠；但端到端时间仍由无法隐藏的最大依赖链决定。评估某个优化是否有效，要看它缩短了 critical path，还是仅仅减少了一个本来被其他步骤遮住的局部时间。
4. KV cache 是服务容量的约束，不是附属缓存
对每层保存的 K 与 V，缓存通常随批内会话数和已生成长度增长。一个近似式是 M_KV ≈ 2 × L × T × H_kv × d_head × bytes；GQA/MQA 会减少 KV head 数，量化会降低每元素字节数，但分页元数据、对齐和碎片仍然存在。实际可服务并发取决于权重、KV、workspace、collective buffer、CUDA Graph 及安全余量同时装得下。
长 prompt 的 prefill 会一次性扩张大量 KV，长 output 的 decode 会长时间占用 slot。把“当前 batch token 数”限制住却不限制每个请求的生成上界，仍可能在几分钟后 OOM。生产系统因而需要 admission control：先根据新请求可带来的 KV 增量、预计输出、缓存命中和优先级判断是否接收，而不是等 allocator 失败。
5. 一条 decode token 穿过 MoE 层的真实路径
输入 hidden state 先经过归一化与 attention；attention 读取该会话历史 K/V，写入当前 token 的 K/V，然后把结果送入 router。router 为 token 选 top-k 专家并给出门控权重，runtime 按专家所在 rank 打包 token。若专家不在本地，token 经 all-to-all 发出；目标 rank 进行 grouped GEMM，结果再经 combine 回到原 token 所在 rank，按 gate 权重加和后进入下一层。
for layer in layers:
h = attention(norm(h), paged_KV[request])
route = topk(router(h), k)
buckets = pack_by_expert_owner(h, route)
remote = ep_all_to_all(buckets)
y = grouped_expert_gemm(remote)
h = residual(h, ep_all_to_all(combine(y, route)))
这段伪代码省略了 TP shard、量化反量化、通信 stream 和异步事件。诊断时先看专家 token 分布与 dispatch/combine timeline，再判断专家 GEMM 是否构成瓶颈。只盯 GEMM TFLOP/s，会漏掉 MoE 服务常见的 all-to-all 长尾。
6. Prefill 与 decode 不是同一种负载，必须分治
prefill 对整段 prompt 并行处理，矩阵较大、算术强度高，通常容易形成大 GEMM；decode 每步 token 少，受 KV 读取、kernel launch、通信延迟和小矩阵效率影响。把两者混在同一 GPU 队列里，长 prompt 会占用计算和 KV 写入，使正在交互的 decode 用户 TBT 抖动；只为 decode 配机器又会让 prefill 的高算力需求变成浪费。
常见策略是逻辑上的 P/D split：prefill worker 完成首轮计算和 KV 写入，随后将请求或其 KV 交给 decode worker。分离不自动带来收益，因为 KV 传输本身可能占满网络，也会破坏 prefix cache 的局部性。阈值应由 KV 大小、链路带宽、首 token SLO、请求长度分布和缓存命中率共同决定。
7. TP、EP、DP 的选择是在三类瓶颈之间交换
TP 把同一层矩阵拆到多卡，能降低单卡权重和计算，但每层需要 collective，decode 小 batch 下同步很敏感。EP 把专家分布到更多卡，避免每卡常驻全部专家，但引入 token all-to-all 和热点专家尾延迟。DP 复制完整执行 mesh 来增加总体吞吐，逐层通信较少，但消耗更多权重显存，并让 prefix/KV 局部性与负载均衡相互冲突。
物理映射比并行名字更重要。TP 的高频 collective 应放进最快的 NVLink/NVSwitch 域；EP 需要足够对称的双向带宽和 NIC 映射；DP 副本才适合跨更弱的域。一个“TP8, EP8”配置若没说明 rank 到 GPU/NIC 的映射，几乎没有可复现意义。详见 并行与放置 和 通信与拓扑。
8. 精度优化的正确问题是误差预算，不是位宽越低越好
权重量化降低静态 HBM 和读取流量，KV quantization 降低会话容量压力，FP8 或更低格式可提高 Tensor Core 吞吐。但不同张量承受误差的能力不同：router logits 的微小排序变化可以改变专家选择，attention score 的误差会随上下文累积，最终层和归一化通常需要更保守。任何“低 bit 可用”的结论必须包含准确度集、长上下文、采样和最大输出长度。
工程上可将量化看成预算分配：优先给权重和 KV 大头降存储，再对 router、激活异常值、共享专家和输出层设例外或更高精度。上线前应同时比对 exact-match 类任务、长链推理、工具调用格式和 token-level divergence，不能只比平均基准分数。
9. 连续批处理把空闲 token 槽变成产能
静态 batch 要等组内最长请求结束，短请求会空占 slot。连续批处理在每一步回收结束请求、插入新请求，使 active token 数保持在预算内。调度器要同时管理 prefill chunks、decode tokens、KV block、优先级与 deadline；“每轮塞满”并不总最优，因为巨大 prefill chunk 会推高已有会话的 TBT。
在 MoE 中还可以把 expert load 纳入打分：两个同长度请求若激活模式不同，给当前热点专家增加多少 token 并不相同。不过这个预测只能是辅助特征，不能为了“均衡”擅自改变模型的 router 决策。
10. 评估新 GPU 时，不能把峰值 FLOP/s 线性相乘
硬件代际变化会影响 Tensor Core 峰值、HBM 带宽与容量、NVLink 域、NIC、异步拷贝和通信库，但模型服务的加速比受 roofline 约束。对计算主导的 prefill，较高矩阵吞吐更可能兑现；对 decode，KV 读取、collective latency 和小 GEMM 可能压低收益；对 MoE，还要看 all-to-all 是否随网络与软件栈同步改善。
因此新平台评估应分层测：单 GEMM、paged attention、router、dispatch/combine、端到端 prefill、端到端 decode，再加不同并发与长度分布。只用一条大矩阵 benchmark 推出模型 token/s，会忽略整个系统中无法用矩阵峰值解释的部分。
11. 从症状反推瓶颈：一个可操作的诊断顺序
- 先按 prompt/output/context bucket 分开报 TTFT、TBT、queue time 和完成率，避免平均值掩盖长尾。
- 审计每卡权重、KV、workspace、reserved/allocated HBM，确定是否被容量限制。
- 在 timeline 中分出 attention、MLP、router、dispatch、combine、collective 和 idle；记录关键路径而不是只看总 GPU util。
- 记录每层、每 EP rank 的 token count 与最大/均值比，定位热点专家和 straggler。
- 在固定请求 trace 下扫 batch、TP/EP、prefill chunk、KV block size；每次只改一个变量。
- 最后再测试缓存命中、P/D 切换、故障恢复和突发流量，确认优化没有把风险转移到 P99。
12. 常见失效条件与错误归因
13. 一套可复现的效率评估实验
准备三组固定 trace：短问答、长文档问答、长推理链；每组记录 tokenizer 后输入长度、输出截止、到达时间和优先级。先用单副本、固定并发建立基础曲线，再逐步加入连续批处理、prefix cache、EP 通信重叠、P/D split 与多副本路由。所有结果应同时保留原始 trace、runtime commit、GPU/NIC 拓扑、环境变量与每秒指标。
最终不要只选“最高吞吐”点，而应画 Pareto 前沿：同一 SLO 下最少 GPU、最低能耗、最高 goodput 和最低 P99 分别是哪组配置。这个前沿才是采购、容量规划和模型版本切换时可复用的工件。
14. 放回 Mainline：这页应怎样继续读
本页给出端到端成本链。服务策略见Prefill、Decode 与 batching，缓存准入见KV cache 与内存，MoE all-to-all 的硬件映射见通信拓扑，数据中心资源计划见数据中心 KV 与 P/D。
对于后续的模型版本，原则不变：先从模型结构和请求分布推导瓶颈假设，再以可重复 profile 验证。不要从一篇分析文章或某个平台的单点数字直接外推到另一个 checkpoint、另一种精度或另一个集群。
15. 证据边界与进一步的一手资料
| 来源 | 本页用途 |
|---|---|
| DeepSeek-V3 官方仓库 | 模型公开资料的入口；具体结构以对应 release 为准。 |
| DeepSeek-R1 官方仓库 | R1 公开资料入口；不把标题推断成版本事实。 |
| Mainline：GPU 算子 | attention、GEMM 和 kernel-level 性能的独立解释。 |
| Mainline：speculative / MTP | 降低 decode 临界路径的另一条路线。 |
时间边界：本页由 2025 原题触发，内容不是该系列文章的替代性转载。模型实现、硬件和运行时均会迭代，任何生产配置均应在目标版本上重新测量。