9. 最佳实践：从 DeepSeek 学到的可迁移经验
DeepSeek 的多数具体设计绑定它的约束（H800、MoE、自研框架），但方法论可迁移。本章按"可直接复用 / 需适配复用 / 不可盲目复用"三档整理。
9.1 可直接复用的工程原则
1. 先算通信账，再定并行策略。 在开始训练前回答三个问题：每 token 的通信字节数是多少？计算通信比是多少？通信能不能被藏进计算？V3 的答案是 229 KB/token、~140×、能——于是 PP16 × EP64 无 TP。任何并行方案设计都应先过这一关（Mini Demo 场景 3/5 提供了复算模板）。
2. 把流水线气泡写成公式贴在墙上。 Table 2 的三行公式 (PP-1)(F+B)、(PP-1)(F+B-2W)、(PP/2-1)(F&B+B-3W) 是通用知识，与实现无关。选 PP 度数、micro-batch 数、是否上 DualPipe 类调度时，先代数再调参。
3. 精度预算是设计出来的，不是测出来的。 FP8 上生产前的四步检查清单（源自 §5.3）：
- 格式：全 E4M3 还是混合？（尾数位优先给精度）
- 缩放：tensor-wise 在你们的激活分布下会不会踩次正规悬崖？（做动态范围扫描，如场景 2）
- 累加：硬件 MMA 内部累加精度够吗？不够时的提升间隔（N_C）取 128 元素起步消融；
- 验证：先在中小规模上训到 1T tokens 量级，对比 BF16 基线的端到端损失误差（口径学附录 B），而不是只看 GEMM 误差。
4. KV cache 按"元素/token/层"记账。 MLA 的压缩公式 2 × 头数 × 头维度 → 潜维度 + RoPE 维度 提醒：注意力架构选择直接决定服务成本。评估任何新架构（GQA/MLA/线性注意力）时，先把每 token KV 字节数、长上下文显存曲线、decode 带宽需求算出来。
5. 负载均衡与通信是同一个问题。 MoE 的三件套缺一不可：路由侧（无辅助损失 bias 或等价机制）、调度侧（EPLB 放置优化）、部署侧（冗余专家吸收热点）。只做一个，尾部延迟仍会由最忙专家决定。
9.2 需适配复用的设计模式
6. "为约束而设计"的结构化响应。 H800 弱 NVLink → 节点受限路由；H20 弱算力 → 推理侧 FP8/稀疏化。通用模式：列出约束的量化形态（带宽比、峰值比、成本比），让结构直接反映约束，而不是堆补偿层。适配到自己环境：先量化你的集群两级带宽比与成本结构，再决定 EP 组拓扑与路由限制。
7. 存储为负载特征定制。 3FS 的 CRAQ + 无状态元数据 + 用户态旁路，对应的是"大块、随机、可重建、读多写少、强一致需求弱"的 AI 负载。通用模式：先写负载特征清单（块大小分布、读写比、一致性需求、重建能力），再选存储协议——不要反过来。
8. 错峰与定价联动。 如果你们的推理集群有明显负载低谷，峰谷定价/折扣窗口是最便宜的"扩容"——它把需求侧变成可调度资源。需要前置条件：按 token 计量的成本核算能力（73.7K/14.8K tokens/s 这类口径）与任务可延迟性。
9. 论文/文档当工程资产经营。 公开 bubble 公式、profile 数据、kernel deep-dive、移植报告，换来的是生态与人才。小团队尤其划算：一份好的技术报告 = 永久性的招聘广告与合作伙伴筛选器。
9.3 不可盲目复用的部分
10. "不用 TP"不是普适结论。 V3 不用 TP 的前提是：MoE 激活参数比低（37B/671B）+ EP64 摊薄每卡参数 + 通信可隐藏。稠密模型、小 EP 度、强 NVLink（H100/GB200 整机柜）环境下，TP/EP 混合仍是主流最优。复用的是"账"，不是"结论"。
11. "零回滚"是结果，不是目标。 不要以"训练不许回滚"为 KPI 去牺牲实验速度。DeepSeek 的零回滚建立在：前期 16B/230B 尺度的 1T tokens 数值验证 + 保守数据管线 + 成熟框架。初创团队先用小规模把数值行为摸清，比在大规模上硬扛更省总成本。
12. 小团队方法论有条件。 垂直整合的前提是团队同时握有框架/kernel/通信/存储四类人才与单一场景（fire-Flyer 时代算力自购自用）。业务型团队复用开源栈（vLLM/SGLang + NCCL + 云存储）通常 ROI 更高——DeepSeek 自己也在用 DuckDB（smallpond）与 FoundationDB，"自研"永远发生在杠杆最大的那一层。
9.4 一页检查清单
训练系统评审：
- [ ] 每 token 通信字节数与计算通信比算过了吗？
- [ ] 流水线气泡有闭式公式与调度模拟吗？
- [ ] 低精度方案的"格式/缩放/累加/验证"四步过了吗？
- [ ] EP 负载均衡三件套（路由/放置/冗余）齐了吗？
- [ ] checkpoint 带宽与 3FS 类并行文件系统匹配吗？
- [ ] 单卡故障的影响面（无 TP = 无全局 allreduce 死锁）评估过吗？
推理系统评审：
- [ ] KV/token/层的字节数与长上下文曲线算过了吗？
- [ ] PD 分离与各自扩缩容策略定了吗？
- [ ] 热点吸收（冗余专家/复制专家）做了吗？
- [ ] 成本按 tokens/s 与每 token 美元核算了吗？
- [ ] 负载低谷有定价/调度手段变现吗？
组织与流程：
- [ ] 每个数量级改善（成本/显存/带宽）能对应到具体设计吗？
- [ ] 技术报告与 profile 数据在持续产出吗？
- [ ] 传闻与事实的引用纪律建立了吗？
9.5 与其他案例的对照速查
| 问题 | DeepSeek | Meta | OpenAI | |
|---|---|---|---|---|
| 算力从哪来 | 自有 + 受限版 GPU | 自研 TPU + GCP | 自建 GPU 集群 | 巨额采购 + Stargate |
| 框架策略 | 自研 HAI-LLM | 自研 XLA/Pathways | 拥抱 PyTorch 生态 | 闭源自研 |
| 开放姿态 | 权重 + 基础设施全开（MIT） | 软件栈开、硬件闭 | 权重 + OCP 硬件开 | 仅 API |
| 核心方法论 | 算法—系统协同省成本 | 垂直整合造超算 | 开放生态摊成本 | 规模 + 产品化 |
下一章 面试题 用 13 道题检验这些知识的掌握深度。