推理系统

1. DeepSeek V4 的新注意力机制架构

组件	描述	KV Cache 压缩策略
Multi-head Latent Attention (MLA)	核心注意力机制，引入潜在向量压缩	-
Swapped Attention (C4)	窗口注意力，看最近几个 token	每 4 个 token 压缩为 1 个
Compressed Attention (C128)	长距离压缩注意力	每 128 个 token 压缩为 1 个

流程：

• 新进入的 token 需要处理两类注意力机制
• 在不同 layer 中，从两个压缩后的 KV Cache 中选择其中一个
• C4 和 C128 分别有对应的 inflight 计算结果需要维护

2. 状态维护机制：Shadow Radix Cache

V4 共有 5 类状态 需要维护：

1. Naive Attention - 标准注意力
2. C4 (Swapped Attention) - 窗口注意力压缩
3. C128 (Compressed Attention) - 长距离压缩
4. C4 Inflight - C4 的实时计算结果
5. C128 Inflight - C128 的实时计算结果

实现：

• 为每个 layer 维护虚拟列表（virtual address list）
• 虚拟地址结合 layer 编号和 KV Cache 大小检索对应状态
• 对于已被压缩删除的状态，虚拟索引仍存在但物理内存已释放
• Inflight 部分采用**环状 Buffer** 技术保证有限内存使用

3. 内核优化

3.1 KV 压缩算子融合

KV 压缩计算流程包含 5 次内存访问：

读取 → 加法 → SoftMax → 点积 → 存储

优化：将中间三个计算操作融合为单个算子，将内存访问从 5 次减少到 2 次

3.2 LightningTopK 算子

• 100 万 token 上下文中，标准 TopK 计算需要 ~100 微秒
• DeepSeek V4 有 60 层，每层都执行此操作
• 100μs × 60 = 6ms，严重限制推理速度

优化：

实现方式	TopK 耗时
纯 PyTorch 实现	~100 微秒
LightningTopK	~15 微秒
提升幅度	6.7 倍

优化：改变计算流程增加并行度

4. 并行策略支持

4.1 张量并行 (Tensor Parallelism, TP)

V4 的注意力机制不是天然支持 TP，因为底层内核要求 head 数量是 64 的倍数。

解决：采用 Padding 机制，将非 64 倍数的部分补齐到 64 的倍数后再进行 TP 计算

4.2 上下文并行 (Context Parallelism, CP)

• 将长上下文分布在多个机器上
• 均摊内存消耗和计算开销
• 适用于单机内计算（通讯开销小）

4.3 流水线并行 (Pipeline Parallelism, PP)

• 跨机器时选择 PP
• 机器间只需一次通信即可完成跨机器数据传输
• 缺点：无法充分利用计算资源（8 卡只能用 4 卡）

场景	方案
单机多卡	上下文并行 (CP)
多机跨节点	流水线并行 (PP)

4.5 专家并行 (EP) 与数据并行 (DP)

• EP 在 MOE 上改动不大，可直接启用
• DP 非常简洁，直接可用
• 支持各种并行方案的排列组合

5. PD 分离支持

阶段	描述	类比
Prefill	对输入编码	AI 做阅读理解
Decode	生成 token	AI 写作输出答案

6. 动态内存管理

问题：不同长度请求对各类 KV Cache 的需求比例不同：

• 短请求：C4 和 C128 需求都较少
• 长上下文：C128 需求显著增加（C128 与上下文长度成正比）

方案：

• 提供参数让用户基于实际请求情况动态配置
• 静态预处理内存池 + 实时动态调整

7. CPU Offload

已实现：将 KV Cache Offload 到 CPU 内存

验证结果：可支持 3 倍 的上下文长度提升

随着 Agent 和 Coding 模型对上下文需求越来越高，在有限 GPU 显存无法完全存储 KV Cache 的情况下，Offload 是必然方向。

8. 开箱即用

• 扫描二维码获取开源推理框架
• 支持不同硬件、模型、场景的自定义配置
• 提供启动指令参考

---

训练框架与 RL 支持

1. 为什么训练做对齐比较困难？

方面	推理	训练
实现复杂度	只需 forward kernel	需要 forward + backward
验证方式	Benchmark 测试	没有标准 baseline
Debug 成本	低（有明确错误指示）	高（需要等几天观察涨点）

2. 训练 Backend 实现

2.1 需要实现的组件

组件	原生支持状态
Multi-head Latent Attention	需要实现
Swapped Attention (C4)	需要实现
Compressed Attention (C128)	需要实现
Inflight 计算	需要实现
MoE (Mixture of Experts)	部分支持

2.2 6 种并行策略支持

并行策略	实现说明
DP (Data Parallelism)	直接可用
TP (Tensor Parallelism)	需要在压缩注意力中实现，与 SP 配合使用
SP (Sequence Parallelism)	与 TP 配套实现
EP (Expert Parallelism)	MOE 上改动不大，直接可用
PP (Pipeline Parallelism)	需修改 Mega 的 PP 代码（MHA 导致 3D→4D tensor 维度变化）
CP (Context Parallelism)	最复杂（详见下文）

2.3 CP 实现难点：Overlap Transform

在 C4 (Swapped Attention) 中使用了 Overlap Transform：

• 相邻两个 compress token 使用的原始 token 有重叠
• 直接应用标准 CP 实现会遇到问题

解决：先应用变换，再恢复，确保正确性

2.4 DSA 索引器

• 基于 JM5 的 Decoupled Swizzled Attention (DSA) indexer kernel
• 针对 DeepSeek V4 架构做简单适配

2.5 Per-head Attention Bias

MHA 引入了 per-head attention bias，需要修改 MHA 的 forward 和 backward kernel 以保证正确性。

2.6 其他组件

• MHC (Multi-head Composition)：借用 DeepSeek 自带的 kernel
• 确保端到端精度正确

3. RL 相关特性

3.1 精度支持

阶段	支持精度
Roaming	FP8
Training	FP8 / BF16

3.2 自定义量化处理器

• 在 Muse 中实现不同的 quantization processor
• 保证从 training backend 传到 inference engine 的权重符合 SGLang 期望的格式

3.3 Attention QAT (Quantization-Aware Training)

• 基于 FP8 实现
• SGLang 推理端用 FP8 存储，训练端用 BF16

3.4 Roaming Replay

• 支持 Standard Replay Buffer
• 支持 R3 等已有 feature

3.5 Influx Replay（实验性 Feature）

背景：DSA 架构引入了类似 MoE 的 route router，为训练带来更大不确定性。

方案：记录 inference 时的 routing 结果，在训练时重放。

挑战：

• SGLang 中 routing 结果存储在 Cache 中
• Cache 的 format 不是简单直接
• 需要在正确位置提取数据，传给训练侧

4. 训练稳定性保障

4.1 逐 Tensor 验证

• 保存端到端每个 tensor 的值（activation、gradient）
• 任何可能破坏正确性的改动后，与之前实现做完整逐 tensor 比较
• 确保差异在可接受范围内（通常 10^-4 ~ 10^-5 量级）

4.2 案例：KV Gradient 精度问题

现象：CP=1 和 CP=2 实现中，attention KV tensor 的 gradient 差异巨大（cosine similarity ~0.2，而其他 tensor 差异在 10^-5 量级）。

原因：

• Compressed attention 架构特殊，部分 head 关注大量 token
• 梯度流动复杂
• 默认 BF16 精度对于其他 tensor（query、KV activation、KV gradient）都够用
• 但 KV gradient 的 reduction 更复杂，精度不够

解决：将 KV gradient 改为 FP32，CP=1 和 CP=2 结果完全吻合。

4.3 稳定性措施

• QD 中使用 deterministic mode
• MoE 部分做 deterministic 改动
• 禁用非确定性操作（如某些 CUDA 优化）

效果：KL loss 的 spike 消失

5. 结果

配置	参数
最大序列长度	4000 tokens
硬件	32 × GB300
结果	Actor reward 和 evaluation score 均上涨
KL divergence	稳定
最终	Average entropy = 0.02（非常低）

---

第三部分：Q&A 精彩问答

1. 并行策略选择

Q：PP 和 CP 应该如何选择？

A：

• 单机：更推荐 CP（通讯快）
• 多机跨节点：推荐 PP（跨机器通讯尽量少）
• PP 的问题是无法充分利用计算资源

2. 张量并行限制

Q：为什么不建议开 TP？

A：底层内核要求 head 数量是 64 的倍数。如果按 head 切分可能无法满足该约束，需要补齐操作引入额外开销。

3. KV Cache 形状与显存管理

Q：不同类型 KV Cache 形状不统一，SGLang 如何规划显存对齐？

A：

• 短请求：C4 和 C128 需求都较少
• 长上下文：C128 需求显著增加（与上下文长度成正比）
• 提供动态参数配置，允许用户根据实际情况调整

4. FP4 支持计划

Q：FP4 是做推理还是训练？

A：next step

1. 先做 FP4 的 Roaming
2. 再做完整 FP4 包 Q 的 Training

5. 硬件规模建议

模型规模	硬件配置
Flash (~DeepSeek V3)	64 × H200
Flash (~DeepSeek V3.2)	32 × GB300
1.6T Pro	256 × H200 或 128 × GB300（待验证）

6. SGLang vs Muse

Q：Muse 和 SGLang 的区别？

A：

• 两者非常相似，很多 feature 是共享的
• Muse 从 SGLang fork 出来
• Muse 主要做新硬件适配（如 Blackwell）和实验性 feature
• `做 Foothink Agent Training 架构

7. 算子融合的取舍

Q：有没有因为追求效率而放弃的优化？

A：算子融合并非一直有效。两个算子融合需要保证它们能沿着同一维度切分做并行计算。如果其中一个算子的最优切分方式与另一个不匹配，会产生额外开销，无法充分利用计算资源。

个人成长

修复 GEMM 内核 → MOE 相关工作（Expert Parallel）→ 并行策略扩展
→ 投机解码 + SPEC 结合 → Scope 越来越大

建议：从简单问题开始，SGLang 有 “newbie first” 标签的 issues 适合新开发者

• MiniG 项目学习（命名和调度写得比 SGLang 好），了解 continuous fusion 等技术

10. 从 SDE 到 MLC 开发的路径

1. 接触算力：找机会做训练/推理相关工作，争取 H100/A100 资源
2. 学习底层：Andrew Ng 的 CUDA/Triton 课程，理解算子编写
3. 理解上层：了解系统架构
4. 实践：从 MiniG/SGLang 小优化开始入手

不要只补窟窿，要思考这些窟窿的共性，尝试用一套框架/设计系统性地解决，做 System Research

• 存储-通信-计算三要素平衡：新一代硬件会打破旧平衡，需要新的算法/架构设计
• 数据管理：从单纯算力优化转向数据存储/记忆管理（如 Agent 可持续记忆、Dream and Memory）
• Sparse Attention 下限：V4 的纯 Swapped Attention 架构已经比较极限
• Off Policy 挑战：控制 fitness 上限，平衡稳定性和 inference efficiency

12. 长尾延迟问题

解决：

• 及时 abort 高 KV Cache 需求的请求
• 处理完其他请求后回头继续
• DeepSeek V4 新架构代码"不太优雅"，团队正在重构

---

技术	说明
MLA	Multi-head Latent Attention，潜在向量压缩
C4/C128	分层 KV Cache 压缩
Shadow Radix Cache	5 类状态的虚拟列表管理
LightningTopK	TopK 计算从 100μs → 15μs

SGLang 支持情况

功能	状态
全系列 Hopper/B200/Blackwell	✅ 已支持
TP/SP/EP/DP/PP/CP	✅ 全部支持
PD 分离	✅ 已实现
CPU Offload	✅ 已支持（3× 上下文提升）
FP8 Roaming	✅ 已支持
FP4	🔜 下一步
FP8/BF16 Training	✅ 已支持
RL 训练	✅ 已支持

• SGLang Quark Book：提供经过测试的推荐配置
• MiniG：轻量级学习项目，代码结构清晰
• SGLang GitHub：“newbie first” issues 适合新手上手

1. 学习 CUDA/Triton 基础
2. 阅读 MiniG 源码理解架构
3. 查找标记为 "newbie first" 的 issues
4. 修复简单问题提交 PR
5. 逐步扩展到 MOE、并行策略等工作

• System Research：抽象和美感，解决共性问题
• 新硬件适配（Blackwell、AMD、国产加速器）
• Agent 架构支持，辅助开发 & 迭代
• 训练稳定性探索