# Hy3 Preview AI Infra 推理优化精读笔记

> 原文：[腾讯混元 AI Infra 如何优化 Hy3 Preview：一次大模型推理性能提升的技术拆解](https://zhuanlan.zhihu.com/p/2053138680768943935)
> 作者：混元 AI Infra 推理团队
> 发布时间：2026-06-26
> 整理时间：2026-07-29
> 用途：推理优化学习、实验设计与工程路线参考

这是一份基于原文及配图整理的技术学习笔记，不是逐字转载。重点是解释每项优化在解决什么瓶颈、为什么有效、依赖什么条件，以及如何映射到我们当前的 vLLM、SGLang、DeepSeek-V4-Flash 和 Kimi-K3 实验。

## 1. 一页结论

这篇文章最值得学习的并不是某一个算子，而是它展示了一套完整的推理优化方法：

1. 先用真实业务数据和明确 SLO 定义目标，而不是只看固定长度随机请求。
2. 将 Prefill 和 Decode 分开分析，因为二者的瓶颈、并行策略和优化目标不同。
3. 从算子、融合、并行、缓存、调度、量化和稀疏算法六个层级逐层消除瓶颈。
4. 不是寻找一个对所有场景都最好的配置，而是围绕业务分布寻找吞吐、时延、容量之间的 Pareto 前沿。
5. 单算子加速不等于端到端等比例加速，必须回到真实流量和 SLO 重新测量。

文章的最终测试口径很有参考价值：

- 5000 条真实请求。
- 最大输入约 192K，平均输入约 68K。
- 最大输出约 64K，平均输出约 0.9K。
- 理论 Prefix Cache 命中率约 80%。
- 硬件为 96 GB Hopper 架构 GPU，结果图标注为 H20。
- SLO 为 TTFT 不超过 4 秒、TPOP 不超过 50 毫秒。
- 总体测试精度标注为 W8A8C8。

图中报告的最终单卡吞吐约为：

- 输入：287.8 万 token/min/GPU，约 47,967 token/s/GPU。
- 输出：8.6 万 token/min/GPU，约 1,433 token/s/GPU。

![最终单卡输入与输出 TPM](assets/01_overall_results.jpg)

这里需要特别注意：输入吞吐远高于输出吞吐并不奇怪。文章的真实流量平均输入约 68K、平均输出约 0.9K，输入 token 数本来就比输出多很多；同时 Prefix Cache 命中也会改变 Prefill 的实际计算量。不能只用这两个柱子的比例推断 Prefill 和 Decode 的硬件速度。

## 2. 模型与问题背景

Hy3 Preview 是一个 GQA + MoE 模型。官方仓库给出的主要规格包括：

- 总参数量约 295B，单 token 激活参数约 21B。
- 另有约 3.8B 的 MTP 层参数。
- 80 层主模型。
- 192 个专家，每个 token 激活 8 个专家。
- 64 个 Attention Head、8 个 KV Head，Head Dim 为 128。
- 原生上下文上限 256K。

官方模型仓库：[Tencent-Hunyuan/Hy3-preview](https://github.com/Tencent-Hunyuan/Hy3-preview)

它在 Hopper 96 GB GPU 上主要面对四类矛盾：

| 矛盾 | 表现 |
|---|---|
| 长上下文与 TTFT | Prefill 计算量大，混合长度请求造成长尾 |
| MoE 与通信 | Expert Dispatch/Combine、TP AllReduce 和跨节点流量较重 |
| 权重与 KV Cache | 权重挤压 HBM，限制长上下文和并发容量 |
| MTP 与异步调度 | 每轮实际接受 token 数不固定，CPU 无法按传统方式提前准备 |

文章的优化可以整理成六层：

| 层级 | 代表技术 | 主要目标 |
|---|---|---|
| 算子 | 动态 Attention、Router GEMM、FusedMoE | 提高单个热点算子的效率 |
| 融合 | Rope/Norm/Quant/KV、AllReduce/Norm/Add、Sampler、GEMM/RS | 减少 Kernel Launch、HBM 往返和通信等待 |
| 并行 | Prefill TPSP、Decode Attention-DP + MoE-EP | 为不同阶段选择合适的数据切分 |
| 缓存 | GPU、CPU、KVStore 三级缓存 | 扩大 Prefix Cache 容量并支持跨实例复用 |
| 调度 | MTP 异步流水 | 隐藏 CPU 调度开销 |
| 模型压缩 | W4A8、Attention FP8、Stem 稀疏注意力 | 降低权重、访存和长上下文计算成本 |

## 3. 算子优化

### 3.1 Attention：动态切分和负载均衡

#### 问题

线上 Batch 中常同时存在长、短请求。静态 Split-KV 必须预先固定切分粒度：

- 切得太少，长序列不能充分占满 SM。
- 切得太多，短序列会承担额外调度、归约和 Kernel 开销。
- 长短请求混合时，不同 CTA 的工作量不均，最慢 CTA 决定整次 Kernel 的结束时间。

#### 方案

文章采用统一 Tile 粒度加贪心装桶：

1. 将所有请求拆成统一大小的 Attention Tile。
2. 把不同请求产生的 Tile 汇总成一条任务流。
3. 根据全局 Tile 数量，为每个 CTA 分配相同或接近的任务预算。
4. 每轮推理前生成任务映射表，Attention Kernel 按表领取任务。
5. 最后由 Combine Kernel 合并 Split-KV 的局部结果。

配图中的例子把长度为 1024、5120、2048 的三个请求按 512 token 拆成 2、10、4 个 Tile，再给 4 个 CTA 各分配 4 个 Tile。长请求可以跨 CTA 执行，不再让某个 CTA 单独拖住整批请求。

![动态 Attention 调度](assets/02_attention_dynamic_schedule.jpg)

#### 收益

- 单 Batch 长文本场景，单算子最高约 2.95 倍加速。
- 混合长度 Batch 场景约 1.59 到 1.76 倍加速。

#### 对我们的启发

我们当前固定 ISL/OSL Grid 适合测容量边界，但不能验证这种负载均衡优化。要增加一个混合长度测试：

- 同一 Batch 同时放入 1K、4K、16K、64K、128K 请求。
- 保持总 token 数近似相同，对比固定长度 Batch。
- 观察 P95/P99 TTFT、GPU SM Occupancy、Attention Kernel 尾部空转时间。

### 3.2 Router GEMM：用两路 BF16 重构 FP32

#### 问题

MoE Router 和稀疏 Attention 的打分对精度敏感，可能需要 FP32 权重。直接执行 BF16 激活乘 FP32 权重会遇到：

- Tensor Core 路径利用不足。
- 激活转成 FP32/TF32 会增加类型转换。
- 小 M Shape 下，CUDA Core 路径尤其低效。

#### 方案

离线把 FP32 权重拆成高位 BF16 与低位 BF16 残差：

```text
W ≈ W_high + scale * W_low
scale = 1 / 256
```

推理时执行两路 BF16 GEMM：

```text
Y = X * W_high^T + scale * (X * W_low^T)
```

两路计算被放进同一个 Kernel：

- X 只从 HBM 读取一次。
- 两路结果分别在寄存器中累加。
- Epilogue 中完成修正。
- 最终只写回一次结果。

![双 BF16 重构 FP32 Router GEMM](assets/03_router_gemm.jpg)

#### 收益

在 N=192、K=4096、M=2 到 4096 的测试范围内，相比 FP32 cuBLAS 路径约快 2.86 到 3.22 倍。

#### 对我们的启发

这不是简单的 `dtype` 开关，而是数值表示、Kernel 实现与模型精度共同设计。它提醒我们：

- Router 往往是小矩阵，不能用大 GEMM 的经验判断性能。
- 看 GPU 利用率时，要单独检查 Router、Indexer 和 Expert GEMM 的 Shape。
- 对 DeepSeek/Kimi 的稀疏路由，需要区分“精度敏感的小算子”和“吞吐主导的大算子”。

### 3.3 FusedMoE：重排完整专家执行链

文章不是只替换 Grouped GEMM，而是重构了整个 MoE 数据通路：

1. 在共享内存中分块统计路由结果，并为每个专家预留连续输出区间。
2. Gate-Up GEMM 直接按路由索引读取原始输入，省略显式 Gather。
3. 取消部分 Warp Specialization，以提高 SM 驻留密度。
4. 激活量化结果按专家连续写入，供 Down GEMM 顺序读取。
5. 末端直接完成 Top-K 加权聚合，减少中间 HBM 往返。
6. 用 PDL 串联阶段，降低频繁 Kernel Launch 形成的空隙。

报告的单算子收益：

- TP=8、EP=1：相比 vLLM CUTLASS、vLLM Triton 和 SGLang 路径约快 1.5 到 1.6 倍。
- TP=1、EP=8：约快 1.2 到 1.5 倍。

开源实现：[Tencent/hpc-ops](https://github.com/Tencent/hpc-ops)

这里有一个很重要的实验原则：同一个 MoE Kernel 在 TP8/EP1 与 TP1/EP8 下的收益不同，因为每卡 Expert 数、每个 Expert 收到的 token 数、通信方式和矩阵 Shape 都变了。比较 MoE Backend 时必须固定完整的 TP/DP/EP 拓扑。

## 4. 算子融合

### 4.1 Rope + Norm + Hadamard + Quant + Store KV

QKV Projection 之后通常存在一串算术强度很低的 Element-wise 操作。若每一步都是独立 Kernel，就会反复：

- 从 HBM 读数据。
- 写回中间结果。
- 发起新的 Kernel。

文章把 Rope、RMSNorm、Hadamard、量化和 KV Cache 写入融合为一个 Kernel。中间值尽量停留在寄存器中，最后直接以低比特格式写入 KV Cache。

报告的融合算子加速约 5 倍。它体现的是典型原则：

> 对访存受限的小算子，减少一次 HBM 往返往往比减少几次算术操作更重要。

### 4.2 AllReduce + Norm + Add

TP 路径通常按以下顺序执行：

```text
AllReduce -> Residual Add -> RMSNorm
```

拆开执行会产生通信等待和中间 Tensor 读写。文章把它融合为：

```text
RMSNorm(AllReduce(x) + residual, weight)
```

提供两类实现：

- Prefill 高吞吐路径：利用 NVSwitch 多播，面向较大的 token Batch。
- Decode 低延迟路径：使用 Lamport P2P，并用 PDL 让两个 Kernel 重叠。

覆盖约 8K 到 32K token 的场景，相比 NCCL 和 FlashInfer 同类路径最高约快 1.68 倍。

这说明通信优化不能只看 NCCL Bandwidth。对于小消息和 Decode，Kernel Launch、同步点与后处理往往和网络带宽同样重要。

### 4.3 Sampler 融合

常规采样可能包含重复惩罚、温度缩放、Top-K、Top-P、Softmax 和随机采样等十余个 Kernel。文章将其压缩成两个核心 CUDA Kernel，并根据简单温度采样或完整采样选择专用路径。

关键设计：

- 全局词表尽量只读取一次。
- 重复惩罚掩码留在 GPU 内处理。
- 单请求可拆给多个 CTA。
- Max Top-K 不超过 64 时使用局部堆归并。
- Top-K 与 Softmax 的 max/sum 归约融合。

下图直观展示了融合前后的 profiler 时间线：融合前有大量碎片化 Kernel，融合后主体工作集中到少数长 Kernel。

![Sampler 融合前](assets/04_sampler_before.jpg)

![Sampler 融合后](assets/05_sampler_after.jpg)

文章报告相较 vLLM 与 FlashInfer 的采样路径分别约有 5.5 倍和 2.5 倍单算子提升。端到端收益仍取决于输出长度、Batch 和模型主体计算占比。

### 4.4 GEMM + ReduceScatter 细粒度重叠

传统执行顺序是完整 GEMM 结束后再开始 ReduceScatter。文章将 SM 分成两类角色：

- 计算 SM：执行 GEMM。
- 通信 SM：搬运已经完成的输出 Tile。

计算 SM 每生成一个 Tile，就写入本地 Buffer 并通知通信 SM；通信不必等待整个矩阵完成。

此外，GEMM 内部又划分为三级 Warp 流水：

```text
Load Warp -> MMA Warp -> Epilogue Warp
```

![GEMM 三级 Warp 流水](assets/06_gemm_comm_fusion.jpg)

在 M 为 8K、16K、32K、64K 的四组 Shape 上，通信覆盖率约从 76.5% 增长到 84.8%，端到端相较串行路径约快 1.68 到 1.81 倍。

这个方向对多机 TP/EP 特别重要。我们以后跑 NCCL Test 只能知道通信上限，真正的模型吞吐还取决于能否把通信藏在计算后面。

## 5. Prefill 与 Decode 的并行策略

### 5.1 Prefill：TPSP

文章认为 Hy3 Preview 的纯 TP8 Prefill 有三个问题：

1. Norm、Router 等 token-wise 算子在各 TP Rank 重复计算。
2. 频繁 AllReduce 交换完整激活。
3. MoE Grouped GEMM 沿 Hidden 维切得过窄，Shape 不利于 Tensor Core。

因此，它没有让整层始终使用同一种并行方式，而是在不同模块切换布局。配图给出的一层时间线包含：

- Attention 使用 TP8。
- Routed Expert 使用 TP4 + SP2。
- Shared Expert 沿 token/sequence 维使用 SP8。
- AG + QKV 和 RS + O Projection 做通信计算融合。
- Shared Expert 与通信使用多 Stream 重叠。
- AllGather 通信采用 FP8，图中说明可比 BF16 减少约 50% 通信带宽。

![TPSP 单层执行时间线](assets/07_prefill_tpsp.jpg)

端到端 Prefill TTFT：

| 输入长度 | 优化前 | 优化后 | 降幅 |
|---|---:|---:|---:|
| 16K | 764 ms | 536 ms | 29.9% |
| 32K | 1885 ms | 1424 ms | 24.5% |

#### 对我们的启发

“TP 越小通信越少，所以一定更快”是不完整的。TP 改变的不只是通信量，还会改变：

- 每卡权重与 KV Cache 容量。
- GEMM 的 M/N/K Shape。
- 是否存在重复 token-wise 计算。
- Batch 在 DP Rank 之间的分散程度。
- 是否能使用特定融合算子。

因此，TP2/DP4、TP4/DP2、TP8/DP1 必须端到端实测，不能只用通信直觉排序。

### 5.2 Decode：Attention DP + MoE EP

Decode 阶段通常 Batch 较小，单 token GEMM 更偏 Memory-bound。文章采用 Attention DP 与 MoE EP 的混合并行：

- Attention 权重在 DP Rank 上复制，让请求可以分开执行。
- Expert 权重按 EP Rank 分布，减少每卡权重占用。
- 多节点请求汇聚到 Expert 后形成更大的 Grouped GEMM Batch。
- 使用异步 EPLB，根据真实专家负载重排权重。
- Shared Expert 计算与 Dispatch/Combine 尽量重叠。
- 长序列 Attention 使用 DPTP 混合方式缓解 DP Rank 负载不均。

报告的端到端吞吐提升约为 15.7% 到 44.7%。

这和我们之前 Custom DP 的现象能够对应：

- 短上下文、高并发时，独立实例容易各自形成稳定 Batch，Custom DP 可能反超。
- 低并发时，请求被分散后每个实例 Batch 太小，GPU 利用率下降。
- 长上下文时，Prefill 和 KV Cache 压力成为主导，简单 Round Robin 无法替代全局调度与混合并行。

## 6. GPU、CPU、KVStore 三级缓存

文章把 Prefix Cache 扩展成三级：

| 层级 | 介质 | 特点 | 复用范围 |
|---|---|---|---|
| L1 | GPU HBM | 延迟最低、容量最小 | GPU 进程 |
| L2 | CPU DRAM | 容量更大、回载较快 | 实例内部 |
| L3 | 本地盘或共享 KVStore | 容量最大、延迟最高 | 本机或跨实例 |

完整请求流程：

1. Scheduler 先查 L1 GPU Prefix Cache。
2. 对未命中部分查询 L2/L3。
3. 命中的完整 KV Block 按需加载回 GPU。
4. 跳过已经命中的 Prefix Prefill。
5. 新生成的完整 KV Block 异步下沉到 L2/L3。
6. L3 连续读取失败时降级到 CPU-only，避免外部存储故障拖垮服务。

配图中的 L3 Backend 可以是：

- HoverDB 本地磁盘：本机持久化缓存。
- NitroFS 共享存储：支持跨实例复用。

![三级 KV Cache 架构](assets/08_multilevel_cache.jpg)

#### 与 Mooncake 的关系

这正是 Mooncake/HiCache 一类系统的价值所在。即使不开 PD 分离，多级缓存仍能在以下场景产生价值：

- 多轮 Agent 对话存在长公共前缀。
- Coding 请求反复携带同一仓库上下文。
- 实例扩缩容、迁移或重启后仍希望复用 Prefix。
- GPU HBM 不足，希望把冷 KV 下沉到 CPU、SSD 或远端存储。

但如果测试流量全部是独立随机 token，几乎没有共享前缀，L2/L3 缓存只会增加查找和搬运开销。因此必须显式设计 0%、20%、50%、80% 命中率的测试组。

## 7. MTP 与异步调度

### 7.1 传统异步调度为什么失效

普通 Decode 每轮稳定生成一个 token，CPU 可以在 GPU 执行第 N 轮时提前准备第 N+1 轮。

MTP 会一次草拟多个 token，但实际接受长度是动态的。下一轮的：

- Sequence Length。
- Position ID。
- KV Cache Block 映射。
- 输入 token 布局。

都依赖本轮验证结果。若 CPU 必须等待 GPU 把接受长度拷回，就会重新出现同步气泡。

### 7.2 文章的方案

CPU 暂时不等待真实接受长度，而是：

1. 按最大可能接受长度插入 Placeholder。
2. 提前准备并 Launch 下一轮。
3. 真实接受长度继续保留在 GPU。
4. 下一轮正式计算前，再由 GPU 修正 Position、KV 映射等关键状态。

这样 CPU 可以提前一整轮，而不是只和很短的 MTP Layer Forward 重叠。

![MTP 与异步调度流水](assets/09_mtp_async_schedule.jpg)

报告结果：

- 每轮减少约 5 到 10 ms 的 CPU 气泡。
- 端到端性能提升约 10% 到 20%。

#### 对我们的启发

投机解码测试不能只记录 Accept Length。至少要同时记录：

- Target Model Decode TPS。
- Draft/MTP 接受长度和接受率。
- 每轮 CPU 调度时间。
- GPU 间隙和 Kernel Launch 间隔。
- 不同 Batch 下的收益。

小 Batch 时 CPU 气泡占比高，MTP 调度优化可能很重要；大 Batch 时 Target Forward 本身更重，收益比例可能下降。

## 8. W4A8、Attention FP8 与精度恢复

文章的压缩链路是：

1. SmoothQuant 风格的激活平滑，抑制少数通道的离群值。
2. Attention 的 Query/Key 在量化前做 Hadamard 正交旋转，把离群值打散。
3. 使用 GPTQ 做逐层权重重建，根据二阶信息补偿低比特权重误差。
4. 做轻量级 QAT，仅更新量化相关参数，使模型适应任务分布。

![Hy3 W4A8 量化流程](assets/10_quantization.jpg)

报告称：

- 多领域评测与 BF16 基线的差距控制在约 1% 以内。
- 端到端吞吐提升超过 28%。

需要区分两种口径：

- 文章开头的总体线上结果标注为 W8A8C8。
- 量化章节进一步讨论的是 W4A8 + Attention FP8 路线。

二者不能当成同一套权重和同一组最终吞吐数据。

开源工具：[Tencent/AngelSlim](https://github.com/tencent/AngelSlim)

#### 对我们的路线判断

这部分不适合当前最先做，因为它可能涉及 Calibration、GPTQ 重建和 QAT。优先级应该低于：

- 正确部署和基线测量。
- TP/DP/EP 与 Scheduler 调优。
- Prefix Cache 和多级缓存。
- Backend 与已有 Kernel 的选择。

当系统参数已稳定，并且确实被权重容量或 HBM 带宽限制时，再进入量化训练与精度评估。

## 9. Stem 稀疏注意力

Stem 的目标是在长上下文 Prefill 中，只计算最有价值的一部分 Attention Block。

### 9.1 Token Position Decay

普通 Uniform Top-K 对不同 Query 位置使用相同预算。Stem 认为：

- 序列头部 token 会参与更多后续因果聚合，误差可能逐层传播。
- 序列尾部 token 的影响范围较小，可以更激进地稀疏。

因此 Top-K 预算从头部的 `k_start` 逐渐衰减到尾部：

```text
k_end = mu * k_start
```

在总计算预算近似不变时，把更多预算留给影响更大的早期位置。

### 9.2 Output-Aware Metric

仅按 `QK^T` 选 token，只衡量注意力路由概率，没有衡量 Value 实际携带的信息强度。Stem 加入 Value 向量模长：

```text
M(i, j) = QK^T + beta * max(0, log(||V_j||_2))
```

然后基于该分数做 Top-K，并交给 Block Sparse Flash Attention 计算。

![Stem 稀疏注意力](assets/11_stem_sparse_attention.jpg)

### 9.3 性能与精度

文章给出的长上下文 Prefill 加速：

| 长度 | FA3 BF16 | FA3 FP8 | Stem |
|---|---:|---:|---:|
| 16K | 1.27x | 1.45x | 1.50x |
| 32K | 1.36x | 1.73x | 1.96x |
| 64K | 1.42x | 2.02x | 2.68x |
| 128K | 1.47x | 2.29x | 3.62x |

![稀疏 Attention Prefill 加速](assets/12_sparse_speedup.jpg)

效果随长度增长而放大，符合稠密 Attention 计算复杂度快速增长的直觉。

配图还比较了 BF16 与“FP8-W8A8 + Stem”的多个任务分数。后者在不同任务上有小幅升降，例如 LongBench v2 和 SWE-bench Verified 约下降 2 个绝对分，Terminal-Bench 基本持平，ClawEval 略有提升。不能只看平均值，需要为实际业务单独设精度门槛。

![量化与 Stem 的任务精度对比](assets/13_sparse_accuracy.jpg)

#### 对我们的意义

你以前做过稀疏注意力基模工作，这一块很适合作为中后期深入方向，但需要把“算法”和“系统”同时验证：

- 稀疏索引本身的计算是否抵消节省。
- Indexer 在 Prefill/Decode 的 Shape 是否覆盖。
- Block Pattern 能否被现有 Kernel 高效执行。
- 稀疏 KV 的布局是否引入额外 Gather。
- 128K 以上是否仍保持精度。
- Chunked Prefill 是否改变选块逻辑或数值结果。

## 10. 如何正确理解文章中的加速数字

### 10.1 不要把所有加速比相乘

例如 Attention 2.95x、融合算子 5x、FusedMoE 1.6x 并不意味着端到端能快几十倍。Amdahl 定律决定了：

```text
总体收益 = 1 / (未优化部分 + 优化部分 / 加速比)
```

而且不同优化可能覆盖同一段时间，收益会重叠。

### 10.2 固定长度 Grid 与真实数据各有用途

| 方法 | 适合回答的问题 | 不适合回答的问题 |
|---|---|---|
| 固定 ISL/OSL/C Grid | 容量边界、Shape 性能、OOM 点、参数敏感度 | 真实 P95/P99、缓存收益、混合长度长尾 |
| 真实 Trace | 线上吞吐、SLO 达标率、Prefix Cache、调度效果 | 精确定位某个 Shape 的 Kernel 问题 |

正确做法不是二选一，而是：

1. 用 Grid 画出系统性能和容量地图。
2. 用真实 Trace 验证业务加权结果。
3. 对真实 Trace 暴露出的热点 Shape 再回到 Microbenchmark 和 Profiler。

### 10.3 文章没有完全披露的变量

做横向对比时还需要确认：

- 总 GPU 数与节点数。
- vLLM/SGLang 的具体版本和 Baseline 参数。
- Cache 命中是按请求、token 还是 block 计算。
- 输入 TPM 是否统计逻辑输入 token，还是实际执行 Prefill 的 token。
- MTP 接受率和平均接受长度。
- 量化精度数据与总体 W8A8C8 吞吐是否来自同一配置。
- 各单算子收益对应的 Batch、并行拓扑和频率锁定条件。

因此，这篇文章非常适合作为优化地图，但不能直接把数字当成我们的性能目标。

## 11. 映射到我们当前的工程路线

### 阶段 A：建立可信 Baseline

- 固定代码、镜像、模型权重和驱动版本。
- 保留 TP2/DP4、TP4/DP2、TP8/DP1 的 Shape Grid。
- 同时记录 TTFT、TPOT、ITL、E2E、请求吞吐、输入/输出/总 TPS。
- 记录实际成功请求的 Prompt/Output token，避免只用配置长度估算 TPS。
- 增加 GPU、HBM、PCIe/NVLink/RDMA、CPU 利用率和服务日志。

### 阶段 B：调度、缓存与并行

- 比较原生 DP 与 Custom DP。
- 对短上下文高并发和长上下文分别选择路由策略。
- 测试 Prefix Cache 命中率 0%、20%、50%、80%。
- 测试 GPU-only、GPU+CPU、GPU+CPU+Mooncake/KVStore。
- 对 MoE 分别测试 TP 主导、EP 主导和 Attention DP + MoE EP。

### 阶段 C：Profiler 驱动的 Kernel 优化

- 用 Nsight Systems 找 GPU 空洞、CPU 调度气泡和通信等待。
- 用 Nsight Compute 找热点 Kernel 的访存、Occupancy 和 Tensor Core 利用率。
- 先尝试已有 Backend：FlashInfer、FlashMLA、DeepGEMM、CUTLASS、Marlin、HPC-Ops。
- 只有现有 Backend 不覆盖关键 Shape 时，才值得自己写算子或提交 PR。

### 阶段 D：模型相关优化

- MTP/DSpark/EAGLE。
- W4A8、Attention FP8、KV Cache 量化。
- Stem/DSA 等稀疏 Attention。
- 精度回归、Calibration 和必要的轻量训练。

## 12. 建议补充的实验矩阵

### 12.1 真实流量 Baseline

先构建一个与文章接近但适合当前模型的 Trace：

- 输入长度按 1K、4K、16K、64K、128K、192K 分桶。
- 输出长度以 1K 左右为中心，同时保留短输出和长输出尾部。
- 混合长度请求一起进入服务。
- 每次测试至少数百到数千请求，保证 P95/P99 有意义。

### 12.2 Prefix Cache

| 变量 | 建议取值 |
|---|---|
| 前缀命中率 | 0%、20%、50%、80% |
| 前缀长度 | 4K、16K、64K、128K |
| Cache 层级 | GPU、GPU+CPU、GPU+CPU+L3 |
| 实例范围 | 单实例、跨实例 |

### 12.3 并行策略

| 阶段 | 候选策略 | 重点指标 |
|---|---|---|
| Prefill | TP8、TP/SP 混合、Chunked Prefill | TTFT、输入 TPS、通信时间 |
| Decode | TP、DP、Attention DP + MoE EP | TPOT、输出 TPS、负载均衡 |
| 多机 | TP/EP、DP/EP、PD 分离 | 网络流量、跨机长尾、容错 |

### 12.4 SLO 吞吐边界

不要只找 Total TPS 最大点。每个 Shape 应同时输出：

- 最大成功并发。
- Total TPS 峰值并发。
- 满足 TTFT SLO 的最大并发。
- 满足 TPOT SLO 的最大并发。
- 同时满足全部 SLO 的最大并发。

这些并发可能不是同一个点。

## 13. 阅读文章时需要记住的十个问题

1. 当前瓶颈属于 Prefill 还是 Decode？
2. 是 Compute-bound、Memory-bound、Communication-bound，还是 CPU-bound？
3. 优化改变了计算量，还是只改变了数据搬运和重叠？
4. 收益对应什么 Batch、Shape、TP/DP/EP？
5. 单算子收益在端到端占比是多少？
6. 是否依赖 NVLink/NVSwitch、RDMA、特定 GPU 架构？
7. 是否需要新权重、Calibration、QAT 或模型结构支持？
8. 是否改变数值结果或精度？
9. 对低并发、长上下文和混合长度是否仍成立？
10. 最终是否提高了满足 SLO 的吞吐，而不只是无约束峰值 TPS？

## 14. 术语速查

| 术语 | 含义 |
|---|---|
| CTA | CUDA Thread Block，Kernel 调度到 SM 的基本工作单元 |
| Tile | 对矩阵或序列任务做的固定粒度切块 |
| Split-KV | 将长 Attention 的 KV 维拆给多个 CTA，再合并局部结果 |
| PDL | Programmatic Dependent Launch，用于减少依赖 Kernel 之间的启动气泡 |
| SP | Sequence Parallel，沿 token/sequence 维切分 |
| TPSP | Tensor Parallel 与 Sequence Parallel 的混合布局 |
| EPLB | Expert Parallel Load Balancing，专家并行负载均衡 |
| TPOP | Time Per Output Token，与 TPOT 接近，衡量连续吐字速度 |
| Prefix Cache | 复用相同前缀已经生成的 KV Cache |
| W8A8C8 | 权重、激活和缓存均使用 8-bit 的总体精度标记，具体格式需看实现 |
| W4A8 | 4-bit 权重、8-bit 激活 |
| MTP | Multi-Token Prediction，一轮提出或预测多个后续 token |
| OAM | Output-Aware Metric，用 Value 强度修正稀疏 Attention 选块分数 |

## 15. 延伸资料

- [原始知乎文章](https://zhuanlan.zhihu.com/p/2053138680768943935)
- [Hy3 Preview 官方仓库](https://github.com/Tencent-Hunyuan/Hy3-preview)
- [HPC-Ops](https://github.com/Tencent/hpc-ops)
- [AngelSlim](https://github.com/tencent/AngelSlim)
- [腾讯混元 AI Infra 新开源：HPC-Ops 推理核心算子全面升级](https://developer.cloud.tencent.com/article/2688857)
- [Mooncake](https://github.com/kvcache-ai/Mooncake)

## 16. Mentor 结论

这篇文章可以作为我们后续推理优化工作的总地图，但学习顺序不要反过来。

当前最值得优先复刻的是：

1. 真实流量 + SLO 的 Benchmark 方法。
2. Prefill/Decode 分阶段分析。
3. TP/DP/EP 与混合长度负载的系统实验。
4. Prefix Cache 和多级缓存。
5. Profiler 驱动的 Backend 与融合优化。

量化、MTP 和稀疏 Attention 很有价值，但更依赖模型结构、精度评估和训练支持。等 Baseline、调度、并行与缓存做扎实之后，再进入这些方向，收益会更容易被正确测量，也更容易形成有说服力的技术成果。