sskj/docs/hy3_infra_article/Hy3_Preview_AI_Infra_精读笔记.md

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

原文：腾讯混元 AI Infra 如何优化 Hy3 Preview：一次大模型推理性能提升的技术拆解 作者：混元 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。

这里需要特别注意：输入吞吐远高于输出吞吐并不奇怪。文章的真实流量平均输入约 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

它在 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 单独拖住整批请求。

收益

• 单 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 残差：

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

推理时执行两路 BF16 GEMM：

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

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

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

收益

在 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

这里有一个很重要的实验原则：同一个 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 路径通常按以下顺序执行：

AllReduce -> Residual Add -> RMSNorm

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

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。

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

4.4 GEMM + ReduceScatter 细粒度重叠

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

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

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

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

Load Warp -> MMA Warp -> Epilogue Warp

在 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% 通信带宽。

端到端 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 共享存储：支持跨实例复用。

与 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 重叠。

报告结果：

• 每轮减少约 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，仅更新量化相关参数，使模型适应任务分布。

报告称：

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

需要区分两种口径：

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

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

开源工具：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 逐渐衰减到尾部：

k_end = mu * k_start

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

9.2 Output-Aware Metric

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

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

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

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 计算复杂度快速增长的直觉。

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

对我们的意义

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

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

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

10.1 不要把所有加速比相乘

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

总体收益 = 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. 延伸资料

• 原始知乎文章
• Hy3 Preview 官方仓库
• HPC-Ops
• AngelSlim
• 腾讯混元 AI Infra 新开源：HPC-Ops 推理核心算子全面升级
• Mooncake

16. Mentor 结论

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

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

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

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