LLM 推理加速：从 0 到 1 教学手册

工程知识约 55 分钟更新于 2026-08-05

LLM 推理加速 从 0 到 1 教学手册

给一个聪明的全职工程师，没有 AI 救场的情况下，能在客户面前讲透每个"为什么"。

2026.05.12 内部备稿

公式速查卡

客户面前现场推导用 · 把这张卡背下来，所有数字都能现场算出来

① H800 硬件常数

HBM 带宽 = 3 TB/s FP8 算力 = 2000 TFLOPS FP16 算力 = 1000 TFLOPS NVLink (SXM) = 400 GB/s PCIe 5.0 = 64 GB/s 单卡显存 = 80 GB

② 算术强度阈值（最重要）

阈值 = 算力 ÷ 带宽 = 2000 × 10¹² ÷ 3 × 10¹² ≈ 333

每字节算 < 333 次 → memory-bound Decode 阶段每字节只算 1-2 次 → 必然 memory-bound Batch=333 是利用率到 100% 的甜点

③ 搬运时间公式

T搬运 = 模型字节数 ÷ HBM 带宽

④ 计算时间公式

FLOPs per token ≈ 2 × 参数量 T计算 = FLOPs ÷ 算力

70B FP8，Decode 1 token： = 1.4×10¹¹ ÷ 2×10¹⁵ = 0.07 ms → 占总耗时的 0.3%，搬运占 99.7%

⑤ GPU 利用率公式

利用率 = T计算 ÷ T实际 = T计算 ÷ max(T计算, T搬运)

Decode (batch=1)：0.07 / 23.3 = 0.3% Prefill (1000 tokens)：23.3 / 70 = 33%（实际 60-80%）

⑥ Batching 利用率（70B FP8）

⑦ KV Cache 占用（70B）

FP16: 320 KB / token FP8: 160 KB / token

⑧ 吞吐 / 延迟 / 首字

TPOT = T搬运 = 23 ms (70B FP8) 吞吐 = batch ÷ TPOT TTFT = prompt × 2 × 参数 ÷ 算力 Ttotal = TTFT + TPOT × 输出长度

例：1000 token 输入 + 500 输出 = 70ms + 23×500 = 11.7 s

⑨ 跨机通信：10 GB KV Cache 传输耗时

→ 不上 IB，分离式部署收益被网络吃光

⑩ 一张图记住所有逻辑

搬运时间 = 模型大小 ÷ 带宽 ← 物理下限 计算时间 = 2 × 参数量 × tokens ÷ 算力 ← 算力消耗 利用率 = 计算时间 ÷ max(计算, 搬运) ← 浪费率 甜点 batch = 算力 ÷ 带宽 ≈ 333 ← 平衡点

所有加速技术都在动这 4 个变量之一：量化缩小搬运分子 · Batching 填满搬运的算力 · 投机解码让一次搬运算多 token · PagedAttention/Prefix Caching 装下更大 batch · 分离式部署让 Prefill/Decode 各跑甜点

知识点全景图

整本手册的"骨架"。每一层回答上一层留下的问题，下一层接住这一层留下的问题。读完这一页，再翻细节。

① 物理直觉 为什么慢 → ② 量化公式 数字怎么来 → ③ 加速技术 怎么变快 → ④ 多卡协同 单卡不够 → ⑤ 工程落地 用什么 → ⑥ 沟通弹药 怎么讲

所有内容围绕的根问题：LLM 推理 95% 时间花在 Decode，而 Decode 阶段 GPU 算力 95% 闲置。全书每一层都是在攻击这个事实的一个侧面。

LAYER 1 物理直觉 · 为什么会慢

问：GPU 算力这么强，为什么 LLM 推理慢？　 答：算力强不等于搬运快，且 Decode 是串行的。

• 算力 vs 带宽失衡：算力 ≈ HBM 带宽 × 300 倍，搬运是真正的瓶颈
• 自回归生成：一次只预测 1 个 token，整个模型权重每生成 1 token 都要搬一次
• Prefill / Decode 两阶段异构：Prefill compute-bound（利用率 60-80%），Decode memory-bound（利用率 1-5%）
• KV Cache：让自回归从 O(N²) 降到 O(N)，但占大量显存，是后续显存优化的核心战场

留给下一层："95% 闲置" "23 毫秒" "33% 利用率" 这些数字到底怎么算的？

LAYER 2 量化公式 · 数字怎么来的

问：怎么证明 Decode 一定是 memory-bound？怎么算最佳 batch？　 答：4 个公式 + 1 个阈值。

• 搬运时间：模型字节数 ÷ 带宽（70B FP8 ÷ 3 TB/s = 23 ms，物理下限）
• 计算时间：2 × 参数量 × tokens ÷ 算力（Decode 单 token 只要 0.07 ms）
• GPU 利用率：计算时间 ÷ max(计算, 搬运)
• 算术强度阈值 333：Batch < 333 → memory-bound，Batch = 333 是利用率打满的甜点

留给下一层：既然瓶颈是搬运和利用率，怎么动这两个变量去加速？

LAYER 3 加速技术 · 怎么攻击根问题

问：具体有哪些技术？各自攻击哪个变量？　 答：三个家族，对应三种攻击。

• 家族一 · 减少搬运分子：FP8 / INT4 权重量化、KV Cache 量化（H800 上 FP8 是免费午餐，速度 ~2x）
• 家族二 · 用闲置算力：Continuous Batching（3-10x）、Speculative Decoding（~3x）、编译优化（15-30%）
• 家族三 · 管好 KV Cache：PagedAttention（浪费 60-80% → <5%）、Prefix Caching / RadixAttention（MaaS 王者）、FlashAttention、KV Offloading

留给下一层：单卡叠满所有技术后，模型装不下 / 并发不够怎么办？

LAYER 4 多卡协同 · 单卡装不下时

问：多卡之间怎么协作？通信瓶颈怎么破？　 答：四种并行 + 分离式部署 + IB。

• 通信带宽层级：HBM 3TB/s > NVLink 400GB/s > IB 50GB/s > PCIe 64GB/s（决定切法）
• 四种并行（按优先级 DP > EP > TP > PP）：能用 DP 不用 TP；TP 只能同机；EP 给 MoE 用；PP 跨机
• 分离式部署：Prefill / Decode 分到不同节点池，单 token 成本省 30-50%（256 卡级别的关键架构决策）
• InfiniBand：RDMA / GPUDirect 让 KV Cache 跨机传输不卡顿，不上 IB 分离式部署就废了

留给下一层：这些技术 + 架构怎么落地成可运行的软件？

LAYER 5 工程落地 · 用哪个引擎

问：所有技术打包成软件后，选哪个？　 答：三引擎对比 + 分阶段上。

• vLLM：行业标准，最易上手，模型支持最广 → baseline 首选
• SGLang：RadixAttention，多轮对话 / MaaS 王者，比 vLLM 快 30%
• TensorRT-LLM：编译优化天花板，但编译要 20-30 分钟、模型变了要重编
• 头部厂商真实路线：Anthropic 走软件（激进投机解码）/ OpenAI 走新硬件 + 蒸馏（Cerebras）
• 三阶段方案：vLLM baseline → SGLang 主引擎 → TensorRT-LLM 针对性优化

留给下一层：这些东西怎么跟客户讲清楚、讲得有说服力？

LAYER 6 沟通弹药 · 客户面前怎么讲

问：怎么让客户既听懂、又信服？　 答：必背数字 + 心智模型 + 四句话答题法。

• 必背数字：3 TB/s · 2000 TFLOPS · 333 · 70 GB · 23 ms · 2×参数量
• 一句话心智模型：95% 时间在 Decode，95% 算力闲着，所有技术都在攻击这个事实
• 四句话答题法：结论 1 句 + 推导 2-3 句 + 代价/边界 1 句（不要只给结论）
• 现场推导模板：客户问"能跑多快"→ 套搬运公式 → 套 batch 公式 → 给出收益和代价

使用方式：开会前 5 分钟翻这一页对全局做最后校准 · 被客户问到具体技术时翻对应 Layer · 公式记不住时翻"公式速查卡" · 讲不下去时回到 Layer 6 的"四句话答题法"。

第一部分：先建立物理直觉

1.1 GPU 为什么"慢"

听起来奇怪 —— GPU 不是很快吗？为什么说它慢？

GPU 的算力（计算速度）很快，但显存到计算单元的数据搬运速度，慢得多。

打个比方：

• GPU 计算单元 = 一个超人，1 秒能做 1000 万亿次乘法
• GPU 显存 = 超人旁边的仓库，里面装着模型权重（要计算的"原料"）
• 传送带 = HBM 带宽，把原料从仓库送到超人手上

关键事实：超人干活的速度，是传送带送货速度的几百倍到一千倍。

意思是：如果超人手边的原料没了，他就得停下来等传送带。等的时间里，超人闲着。

H800 的具体数字：

关键比例：算力 ≈ HBM 带宽 × 300 倍。

所有推理加速技术，本质上都在解决同一个问题：要么减少传送带要送的货，要么让超人在等货的时候顺便干点别的，要么让传送带送货更聪明。

1.2 模型在 GPU 里长什么样

模型权重 = 一堆数字（参数）。

脱敏说明：本稿件逐类检查九类敏感项，未发现需要替换的内容。文中出现的 H800 为公开销售的硬件型号，其 HBM 带宽、FP8 算力等参数均为公开产品规格，非内部部署信息，故保留。原稿第 8 页之后（1.2 节起至附录）未包含在本稿件输入中，如需完整内容请获取原稿。

一个 70B（700 亿参数）模型，每个参数用 2 字节存（FP16 精度），共 140 GB。 某型号卡单卡只有 80GB 显存，装不下 140 GB。所以你只有三个选择： 压缩模型（量化）：每个参数用 1 字节存，模型变成 70 GB，能装进单卡 切到多卡：把模型分到 2 张卡上，每张卡装一半 换更小的模型 这就是为什么后面会反复看到"FP8 量化"和"多卡部署"。

1.3 LLM 是怎么"说话"的（自回归生成）

你必须先扔掉一个错误直觉

❌ 错误直觉：你问一句话，模型读懂，然后输出一整段回答。 ✅ 实际真相：模型只能预测"下一个字"。一整段回答是一个字一个字蹦出来的。

用例子讲清楚

你问："请帮我写一首关于杭州的诗" 模型的回答："江南忆，最忆是杭州"

这 9 个字是怎么生成的？模型不知道自己接下来要说"江南忆"。它每一步只做一件事：看看目前已有的文字，预测下一个字应该是什么。

第1步： 已知 = "请帮我写一首关于杭州的诗" 模型预测下一个字 = "江"

第2步： 已知 = "请帮我写一首关于杭州的诗江" ← 把"江"加进来 模型预测下一个字 = "南"

第3步： 已知 = "请帮我写一首关于杭州的诗江南" 模型预测下一个字 = "忆"

...一直循环，直到模型预测出"<结束>"标记

每一步，整个 140 GB 模型权重都要从显存搬到计算单元走一遍。

这种"一个字一个字往外蹦"的方式，叫自回归生成（Auto-regressive Generation）。ChatGPT 网页上你看到的"流式输出"，就是模型真实的工作方式。

1.4 推理的两个阶段：Prefill 和 Decode

理解了自回归，现在能讲清楚推理的两个阶段了。

Prefill = 处理你的输入，吐出第一个字

输入："请帮我写一首关于杭州的诗"（10 个字） Prefill 做的事：把这 10 个字一起喂给模型，让模型预测出第一个回答字"江"。

关键点：因为这 10 个字都是已知的，可以同时塞进 GPU 让所有计算单元一起算。

矩阵规模大 → 超人忙得过来 → GPU 算力利用率 60-80% 这叫 compute-bound（算力是瓶颈） 时间：100-200 毫秒

Decode = 一个字一个字往外蹦

第一个字"江"已经有了。现在要生成"南"、"忆"...

Decode 做的事：每次只把 1 个新字喂给模型，预测下一个字。

关键点：因为下一个字必须等当前字生成完才知道，没法并行，只能一次一个。但是 —— 整个 140 GB 模型权重还是要搬运一遍。

矩阵规模小 → 超人只算 1 个字 → 但搬运量没变 → GPU 算力利用率 1-5% 这叫 memory-bound（搬运是瓶颈） 时间：每个字 10-30 毫秒。500 个字 = 5-15 秒

两个阶段的对比

整个推理领域的"原罪"

一个典型请求：Prefill 100-200 ms，Decode 5-15 秒。

95% 以上的时间花在 Decode 阶段，而 Decode 阶段 GPU 算力闲着 95%。

整个推理加速领域所有技术，都在解决一个问题：怎么把 Decode 阶段那 95% 闲置的算力用起来。

三个最常见的误解，必须校正

误解 1: "Prefill 已经喂给模型了，为什么还要 Decode" 校正：Prefill 只处理了用户的输入 prompt，只产出了第一个回答 token。后面所有的回答 token 都要靠 Decode 循环生成。 类比：你问朋友一个问题。 Prefill = 朋友"听明白你的问题"，并说出第一个字"我" Decode = 朋友继续说"觉得...这件事...应该...这样..."一个字一个字往外蹦

误解 2: 模型一次性输出整段回答 校正：LLM 根本不知道自己接下来要说什么。它每次只能预测"下一个 token 的概率分布"。

误解 3: 觉得 Decode 是"在解码 Prefill 的结果" 校正："Decode" 这个词翻译得不好。Decode 和 Prefill 做的是同一件事 —— 都是"过一遍模型，预测下一个 token"。区别只在于： Prefill: 一次同时处理多个 input token（并行处理已知的 prompt） Decode: 一次只处理 1 个新生成的 token（自回归约束）

1.5 KV Cache：让自回归能跑起来的关键

到这里你可能会问：生成第 500 个字的时候，模型怎么"记得"前面 499 个字是什么？

答案是 Attention 机制 —— 每生成一个新字，模型会"回头看"前面所有字，决定新字应该是什么。

问题：朴素做法太贵

如果每生成一个字都重新"回头看"前面所有字： 生成第 1 个字：算 1 个字 生成第 500 个字：重算前面 499 个字

总成本是 N² 量级的，N=500 时比"只算一次"贵 250 倍

这种成本下，ChatGPT 根本不可能存在。

解决：KV Cache

道理很简单：算过的东西，存下来，下次直接用。

具体来说，每个字会被模型算出两个东西： K (Key) = 这个字的"特征标签" V (Value) = 这个字的"内容信息"

每生成一个新字时，模型只需要算新字的 K 和 V，然后从 cache 里读出所有历史字的 K 和 V，做一次 attention。

复杂度从 O(N²) 降到 O(N)。这才让自回归生成在工程上可行。

代价：KV Cache 很占显存

每个字的 K/V 大约 320 KB。一个长对话的 KV Cache 可以占几十 GB。

KV Cache 是后面所有显存优化技术的核心战场。PagedAttention、Prefix Caching、KV 量化、KV Offloading —— 全都在围绕 KV Cache 做文章。

1.6 Token 是什么

到现在为止我一直说"字"。实际上模型处理的最小单位不是字，是 token。

Token 不等于字或词

粗略规律： 英文：1 个 token ≈ 0.75 个单词 中文：1 个 token ≈ 1.5 个汉字

一个关键的商业事实：中文 token 效率低

同样一段话表达同样的意思，中文消耗的 token 比英文多 30-50%。

为什么？分词算法（BPE）基于训练语料统计，训练语料以英文为主，所以英文有大量"高频词组合"被合并成单个 token，中文大部分还是一字一 token。

对某 MaaS 平台的商业含义：如果按 OpenAI 的英文 token 定价标杆收费，中文客户实际可能是亏的（token 账单数字大，但 GPU 时间也多，毛利率低）。定价模型应该考虑中英文差异。

Input vs Output Token

Input Token = 用户输入的 token 数（被 Prefill 阶段处理） Output Token = 模型生成的 token 数（被 Decode 阶段生成）

Output Token 通常比 Input 贵 2-4 倍。原因你现在已经懂了：Input 走 Prefill，GPU 效率 60-80%，便宜；Output 走 Decode，GPU 效率 1-5%，贵。OpenAI、Anthropic、阿里都这样定价。

第一部分小结

你应该能用一句话回答下面这些问题：

Q: LLM 为什么慢？ A: 因为大部分时间花在 Decode 阶段，Decode 是一个字一个字串行生成，每生成一个字都要把整个模型权重搬运一遍。GPU 算力实际只用了 1-5%。

Q: 为什么要 KV Cache？ A: 因为生成每个新字都要"回头看"前面所有字，没有缓存的话计算量是 N²。KV Cache 让历史字的特征算一次就缓存下来。

Q: 显存为什么总不够？ A: 模型权重占大头（70B FP16 就是 140 GB），KV Cache 是另一个大头，且按对话长度增长。

Q: 为什么 Output 比 Input 贵？ A: 输入走 Prefill 阶段 GPU 效率高，输出走 Decode 阶段 GPU 效率低、成本高。

第二部分：核心计算公式速记表

把所有"为什么是 23 ms / 95% 利用率"的数字根源全部拆开。客户问的时候能现场推导。

这一部分是物理直觉的量化版本。第一部分讲"为什么"，这一部分讲"具体多少"。所有数字都以某型号卡 + 70B 模型为基准。

2.1 硬件常数（必须脱口而出）

关键阈值

算力 / 带宽 ≈ 333

意思是 GPU 每搬 1 字节，理论上能做 333 次 FP16 运算。

如果一个操作"每字节做的计算 < 333"，它就是 memory-bound（搬运瓶颈）。

这叫 arithmetic intensity（算术强度）阈值，记住 333 。

2.2 搬运时间（Memory Movement Time）

核心公式

T搬运 = 要搬的字节数 ÷ HBM 带宽

案例 1：70B FP16 模型搬运一次

T = 140 GB ÷ 3 TB/s = 140 / 3000 s = 46.7 ms

案例 2：70B FP8 模型搬运一次（量化后）

T = 70 GB ÷ 3 TB/s = 23.3 ms

这就是"23 毫秒"的来历。FP8 量化让 Decode 每个 token 的搬运时间直接砍半。

案例 3：70B INT4 模型搬运一次

T = 35 GB ÷ 3 TB/s = 11.7 ms

速记表

核心心智模型：Decode 阶段，每生成一个 token，至少要花上面这个时间。这是物理下限，跟你软件怎么优化没关系。

2.3 计算时间（Compute Time）

核心公式

T计算 = 所需 FLOPs ÷ GPU 算力

一个 Token 的 FLOPs 数量

经验公式（Transformer 模型）：

FLOPs per token ≈ 2 × 参数量

70B 模型：每个 token 需要 140 GFLOPs = 1.4×10¹¹ FLOPs 7B 模型：每个 token 需要 14 GFLOPs

案例：70B FP8 模型，Decode 1 个 token 的纯计算时间

T = 1.4×10¹¹ ÷ 2×10¹⁵ = 7×10⁻⁵ s = 0.07 ms

关键对比（70B FP8，Decode 1 个 token）

Decode 阶段 99.7% 的时间花在搬运，0.3% 在算。这就是 memory-bound 的真相。

2.4 GPU 算力利用率（MFU - Model FLOPs Utilization）

核心公式

利用率 = 实际用掉的算力 ÷ GPU 理论峰值算力

等价写法：

利用率 = T计算 ÷ T实际耗时 = T计算 ÷ T搬运

（memory-bound 场景下，实际耗时 = 搬运时间）

案例：70B FP8，Decode 1 个 token（batch=1）

利用率 = 0.07 ms ÷ 23.3 ms = 0.3%

99.7% 算力闲置。这就是"95% 闲置"的来源（手册写的是保守估计 1-5%）。

Prefill 阶段为什么是 60-80%

Prefill 一次处理 N 个 token（比如 1000 个），搬运还是搬一次 70 GB，但计算量变成 N 倍：

T计算 = 0.07 ms × 1000 = 70 ms

T搬运 = 23.3 ms

此时计算时间 > 搬运时间，瓶颈翻转成 compute-bound

利用率 = T搬运 ÷ T计算 = 23.3 ÷ 70 ≈ 33%

实际算上 batch、并行优化能到 60-80%。

2.5 Batching 让利用率回升（核心商业逻辑）

关键洞察：搬运一次 70 GB，能同时给 N 个用户算 token。搬运时间不变，计算时间变 N 倍。

公式

Decode 利用率(batch=N) = (0.07 ms × N) ÷ 23.3 ms

速记表（70B FP8，Decode）

Batch = 333 是理论甜点（来自 arithmetic intensity 阈值）。

这就是为什么 Continuous Batching 能拉 3-10 倍吞吐，它在把利用率从 0.3% 拉向 30%+。

2.6 KV Cache 占用（决定最大 batch）

单 TOKEN 的 KV CACHE 大小

KV per token = 2 × n_layers × n_heads × d_head × bytes

70B 模型（Llama 架构，FP16）：约 320 KB / token

FP8 量化后：约 160 KB / token

速记表

最大 batch 反推

8 张某型号卡（640 GB 显存）跑 70B FP8：

模型权重：70 GB

剩余给 KV：570 GB

32K 上下文每用户 10 GB，最多 57 个并发用户

如果 KV 也 FP8，5 GB/用户，114 个并发

2.7 吞吐 / 延迟 / 首字延迟

TPOT（Time Per Output Token，每个输出 token 的时间）

TPOT = T搬运 = 23.3 ms （batch=1, 70B FP8）

batch 越大，单用户的 TPOT 不变（搬运时间不变），但总吞吐 = batch × (1/TPOT) 线性增长。

单卡吞吐（tokens/s）

吞吐 = batch ÷ TPOT

70B FP8 在某型号卡单卡：

batch=32 → 32 / 0.0233 = 1373 tokens/s

batch=128 → 128 / 0.0233 = 5494 tokens/s

TTFT（Time To First Token，首字延迟）

TTFT = TPrefill = (prompt 长度 × 2 × 参数量) ÷ 算力

1000 token prompt，70B FP8：

TTFT = (1000 × 1.4×10¹¹) ÷ 2×10¹⁵ = 70 ms

总响应时间

Ttotal = TTFT + TPOT × 输出长度

500 token 输出：70 ms + 23.3 ms × 500 = 11.7 秒

2.8 跨机通信（KV Cache 传输 / 分离式部署）

核心公式

T传输 = 数据量 ÷ 网络带宽

案例：32K 上下文 KV Cache 跨机传输（10 GB）

不上 IB，分离式部署的 KV Cache 传输能吃掉 800 ms，用户感知卡顿。

2.9 客户现场速算清单

把这 6 个数字背下来，能现场推所有问题：

现场推导模板

客户问："你们这个模型某型号卡上能跑多快？"

你答："70B FP8 在某型号卡上，Decode 单 token 物理下限是 23 ms（权重 70 GB ÷ 带宽 3 TB/s）。Batch=1 时单卡 43 tokens/s，但那 GPU 利用率只有 0.3%。开 Continuous Batching 到 128，吞吐能拉到 5500 tokens/s，利用率到 40%。再叠 Speculative Decoding 大概 1.5 万 tokens/s 单卡。"

2.10 一张图记住所有逻辑

搬运时间 = 模型大小 / 带宽 ← 物理下限 计算时间 = 2 × 参数量 × tokens / 算力 ← 算力消耗 利用率 = 计算时间 / max(计算, 搬运) ← 浪费率 甜点 batch = 算力 / 带宽 ≈ 333 ← 平衡点

所有加速技术都在动这四个变量里的某一个：

量化 → 缩小"搬运时间"分子

Batching → 把"计算时间"加上去填满搬运

Speculative Decoding → 让"计算时间"那一项一次算多个 token

PagedAttention / Prefix Caching → 让"显存"装得下更大的 batch

分离式部署 → 让 Prefill / Decode 各自跑在自己的 sweet spot 上

第三部分：加速技术的三大家族

第一部分讲清楚了三件事：搬运是瓶颈、Decode 阶段 GPU 95% 闲置、KV Cache 占大量显存。

第二部分把这些做成了可计算的公式。这一部分讲：所有加速技术，都是在解决这三件事中的一件或多件。按"问题家族"分成三类。

家族一：减少搬运

解决的问题：Decode 阶段 GPU 忙着等数据从显存搬过来。

思路：减少要搬的数据量。

量化 (Quantization)

回想第一部分：70B 模型用 FP16 存，每个参数 2 字节，共 140 GB。量化就是用更少的字节存每个参数。

为什么量化能加速

两个好处叠加：

1. 显存占用变小：FP16 装不下的模型，FP8 能装下
2. 搬运量变小：Decode 阶段瓶颈是搬运，搬运减半，Decode 速度几乎翻倍

所以 FP8 量化在某型号卡上是"免费午餐"，又省显存又加速。

KV Cache 也能量化

--kv-cache-dtype fp8 这一个参数：

1. KV Cache 占用减半
2. 意味着同样显存能支持两倍长的上下文，或者两倍的并发用户

跟客户怎么聊量化："某型号卡上 FP8 是必开的。模型权重 FP8 能省一半显存，KV Cache 也做 FP8 能再翻倍。这不是优化，这是基础配置。INT4 更激进，能再砍一半，但要测精度，建议第一阶段先跑稳 FP8。"

家族二：把闲置的算力用起来

解决的问题：Decode 阶段 GPU 算力闲 95%。

思路：在等数据的时候，让 GPU 顺便多干点活。

三个技术，层层递进。

技术 1: Batching（批处理），让多用户共享一次搬运

核心思想

Decode 阶段，搬运整个模型权重的时间是固定的。但这次搬运能算几个 token 取决于一次喂给 GPU 多少个 token。

类比：卡车从仓库拉一车货到工地。工地上有 1 个工人 vs 32 个工人，消耗的卡车次数是一样的，但 32 个工人能干 32 倍的活。

所以：一次性把 32 个用户的请求合并处理，搬运量不变，但产出 32 倍。GPU 利用率从 1-5% 直接拉到 50-80%。

老做法的问题（Static Batching）

1. 凑齐 32 个请求，一起开始 Decode
2. 等所有 32 个请求都生成完，再开始下一批
3. 一个生成 500 字、另一个只要 50 字，50 字的请求生成完后那个 slot 浪费 450 步

新做法：Continuous Batching

vLLM 2023 年的核心创新，现在是行业标准。

做法：每生成完一个 token，立刻检查，谁结束了？结束的 slot 立刻让新请求顶上来。GPU 永远满载。

效果：吞吐提升 3-10 倍。这是 LLM 从 demo 级走向生产级的关键技术。

技术 2: Speculative Decoding（投机解码），让一次搬运算多个 token

核心思想

batching 是"让多个用户共享一次搬运"。

投机解码是"让一个用户一次搬运算出多个 token"。

利用一个事实：生成下一个 token 大部分是显而易见的。比如你说"今天天气真..."，后面接"好"的概率超高。

怎么做

1. 小模型先猜：用一个小模型（比如 7B）先生成 5 个候选 token
2. 大模型并行验证：大模型一次性看这 5 个 token，判断每个是否同意
3. 接受 or 重写：前 3 个 token 大模型也同意，直接接受；第 4 个开始分歧，用大模型的输出替换

为什么有效

不用投机：生成 5 个 token = 5 次搬运 = 5 个 token 时间

用投机：生成 5 个 token = 1 次搬运（验证）+ 小模型成本（很便宜）= 约 1.5 个 token 时间

加速：约 3 倍

关键洞察：因为 Decode 是 memory-bound，让大模型一次验证 5 个 token，和让它验证 1 个 token，搬运成本是一样的。

几个变体（大概知道就行）

1. EAGLE / EAGLE-3：不用独立小模型，复用大模型自己的浅层做猜测。命中率最高，2026 年的 SOTA。
2. MTP (Multi-Token Prediction)：模型架构原生支持一次预测多个 token（DeepSeek-V3 用的）
3. Medusa：在大模型上加几个"小脑袋"
4. N-gram：用历史文本统计做猜测，零额外成本，代码生成场景特别有效

脱敏说明

本文档对以下敏感内容做了就地替换：

1. 卡型号脱敏：H800 替换为"某型号卡"（7 处），B200 替换为"某新型卡"（1 处）。对应带宽、算力等公开硬件规格数字保留原值。

跟客户怎么聊投机解码："Anthropic 的 Claude Fast Mode 能做到 2.5 倍加速，大概率就是用了更激进的投机解码。我们在 Qwen 上用 EAGLE-3，不需要额外小模型，复用大模型自身的浅层做猜测，命中率 70-80%，端到端能加速 2 倍。这个收益直接转化为单卡多服务用户，是毛利级别的优化。"

技术 3: 编译优化 —— 让每次"忙活"更高效

问题

PyTorch 默认模式下，一次 forward pass 会启动几百次 GPU kernel，每次启动有几微秒"启动开销"。Decode 阶段每生成一个 token 累计开销可观。

解决方案

• CUDA Graphs：把 forward pass 录制成图，反复执行
• torch.compile：PyTorch 2.x 的自动算子融合
• TensorRT-LLM：NVIDIA 官方编译器，单卡峰值吞吐天花板

TensorRT-LLM 特点

• 编译时间长（70B 模型 20-30 分钟）
• 模型架构改了要重编
• 编译后吞吐比 vLLM 高 15-30%
• 适合：模型固定 + 长期稳定 serving

家族三：管好 KV Cache 这个吃显存大户

解决的问题：KV Cache 占大量显存。

思路：要么管理得更聪明（少浪费），要么共享（多用户一起用），要么压到别处（offload）。

技术 1: PagedAttention（KV Cache 分页管理）

问题

老式做法：每个请求最多可能生成 2048 个 token，所以预分配 2048 个 token 的 KV Cache 空间。但实际很多请求只生成 50 个就结束，剩下 1998 个的空间被锁着不能给别人用。结果：60-80% 的显存被浪费。

解决：像操作系统管内存那样管 KV Cache

vLLM 2023 年的另一个核心创新。

• KV Cache 不再是"一个请求一大块连续空间"
• 切成固定大小的"页"（比如每页 16 个 token）
• 每个请求按需申请页，用完释放
• 效果：浪费率从 60-80% 降到 <5%。同一张卡能塞 2-4 倍的请求。

技术 2: Prefix Caching（前缀缓存）

问题

很多请求共享相同的开头。最典型：MaaS 平台上所有客户都用同一个 system prompt"你是一个专业的客服助手..."。每个请求都要重新 Prefill 这个相同前缀，纯浪费。

解决：算过的相同前缀，KV Cache 缓存下来共享

请求1: [相同的system prompt] + [用户A的问题]
请求2: [相同的system prompt] + [用户B的问题]
请求3: [相同的system prompt] + [用户C的问题]
→ system prompt 的 KV Cache 只算一次，三个请求共享

效果

如果 system prompt 很长（1000 个 token）、复用率高（80-90%）：

• Prefill 时间减少 80-90%
• 用户感觉到的"首字延迟"大幅降低

SGLang 的 RadixAttention 把这做到极致。vLLM 也支持 prefix caching，但比较基础。SGLang 用一种叫"基数树"的数据结构，能管理任意前缀的复用。多轮对话场景下，每一轮对话都能复用前一轮的全部历史。

这是 SGLang 在 chat/agent 场景比 vLLM 快 30-50% 的根本原因。对 MaaS 场景特别合适。

技术 3: FlashAttention（让 Attention 算得更省内存）

这个技术优化的不是 KV Cache 本身，是 attention 计算过程的中间结果。

问题

Attention 计算时会产生一个 N × N 的注意力矩阵（N 是序列长度）。N = 100K：矩阵占几十 GB。长上下文场景，这个中间矩阵会爆炸。

解决：分块计算，不存完整矩阵

核心思想：把 attention 计算切成小块，每次只在 GPU 的片上小缓存（SRAM）里算一小块，永远不在显存里保存完整的 N×N 矩阵。

• 内存占用从 O(N²) 降到 O(N)
• 速度提升 2-4 倍
• 所有主流引擎默认开启

技术 4: KV Cache Offloading（KV Cache 分层存储）

问题

长上下文（128K+）+ 多用户 → KV Cache 总量超过显存。

解决：把不常用的 KV Cache 挪到便宜的存储

• 活跃用户的 KV Cache → 放 HBM 显存（3 TB/s，贵）
• 沉睡用户的 KV Cache → 放 CPU 内存（100 GB/s，便宜）
• 冷数据 → 放 SSD（更慢更便宜）

关键挑战

如果用户活跃的瞬间才开始从 CPU 内存搬，延迟会暴涨：

• HBM: 3 TB/s
• CPU 内存: 100 GB/s
• PCIe: 64 GB/s

直接同步搬，延迟会增加 50 倍。所以必须异步预取（prefetching）：预测下一步要用什么 KV Cache，提前搬过来。

工业实现

• vLLM 0.6+ 的 --cpu-offload-gb
• Mooncake（某公司开源）：分布式 KV Cache 池
• NVIDIA Dynamo：原厂支持 KV Cache tiering

第三部分整体回顾

所有技术叠起来能多快

某型号卡上跑 Qwen3.6-27B，从零开始一步步加：

从 0 到这里，有效吞吐提升 20-30 倍。这就是推理加速的真实意义 —— 不是一个 trick，是一整套工程。

第四部分：多卡 / 多机协同

4.1 卡间通信瓶颈

关键事实：

• 同机两张卡之间走 NVLink，比走 PCIe 快 6 倍
• 跨机两张卡之间走 IB，比同机内 NVLink 慢 4-8 倍

多卡部署的核心原则：通信量大的操作，尽量放在同机内；通信量小的操作，可以跨机。这个原则决定下面所有的并行策略。

4.2 某型号卡的 NVLink 阉割版

明天必须问工程侧的第一个问题：某型号卡是 SXM 还是 PCIe 版本？这决定整个架构怎么搭。

4.3 四种并行方式

切法 1：Tensor Parallelism (TP, 张量并行)

怎么切：把每个矩阵沿宽度方向切开，分到多张卡。每次 forward pass，多张卡同时算各自的部分，然后 all-reduce 合并。

关键特点：

• 通信极其频繁（每一层都要 all-reduce）
• 要求卡间带宽高（只能同机内）
• 常见配置：TP=2 / TP=4 / TP=8

某型号卡上的实际后果：

• H100 上 TP=8 最快（NVLink 足够）
• 某型号卡上 TP=8 通信瓶颈明显，TP=4 可能比 TP=8 更划算
• PCIe 版某型号卡建议 TP=2 上限

什么时候用：单卡装不下模型时。能装下就别用 TP，通信开销纯亏。

切法 2：Pipeline Parallelism (PP, 流水线并行)

怎么切：模型按层切，前 16 层在卡 A，后 16 层在卡 B。请求像流水线一样依次过卡 A、卡 B。

关键特点：

• 卡间通信少，可以跨机
• 天然缺点：流水线气泡（开头和结尾的 idle）

什么时候用：模型太大需要跨机部署。某业务场景下用得很少。

切法 3：Expert Parallelism (EP, 专家并行)

专为 MoE 模型设计。Qwen3.6 和 GLM-5.1 都是 MoE，非常重要。

怎么切：把不同专家放到不同卡上。每个 token 根据 router 决定，被发到对应的卡上去算。

关键特点：

• 每个 token 要"传输到对应卡"，通信量较大
• 要求 NVLink 互联，跨机做 EP 开销大
• MoE 部署一般是 TP + EP 混合

例：Qwen3-235B 在 16 卡的典型配置 TP=8, EP=8, DP=2 —— 8 卡组成一个 TP+EP 副本，部署 2 个副本。

切法 4：Data Parallelism (DP, 数据并行)

怎么切：根本不切模型。直接部署多个完整模型副本，请求按负载分发。

关键特点：

• 简单粗暴
• 吞吐线性扩展
• 副本之间完全独立，没有通信开销

什么时候用：模型能装下单卡或单机时，首选。能用 DP 就不要用 TP/PP/EP。

四种方式优先级

DP > EP > TP > PP（按优先级，能用简单的就不用复杂的）

4.4 分离式部署（Disaggregated Serving）

2025-2026 年生产级 MaaS 的标配，32 台某型号卡规模真正能拉开差距的地方。

核心洞察

• Prefill 是 compute-bound，吃算力
• Decode 是 memory-bound，吃带宽和显存

这两件事对硬件需求完全不同。混在一起做注定低效。

传统做法的问题

每张卡同时承担 Prefill 和 Decode。问题：

1. Prefill 和 Decode 互相干扰
2. 一个长 Prompt 的 Prefill 会拖慢所有正在 Decode 的用户
3. 硬件配置妥协

分离式部署的做法

Prefill 节点池                     Decode 节点池
┌─────────────┐                  ┌──────────────────────┐
│  8张卡      │    KV Cache       │  24张卡              │
│  专做       │   ──────────→    │  专做后续 Decode      │
│  用户输入    │    传输            │                       │
│  Prefill    │                   │                       │
└─────────────┘                  └──────────────────────┘

好处

• 硬件可以差异化：Prefill 节点可以用算力强但显存小的卡（甚至 A100）；Decode 节点必须某型号卡/H100
• 各自调到最优：Prefill 节点 batch 大点；Decode 节点不会被长 Prompt 卡住
• 单 token 成本降 30-50%

工业实现

• NVIDIA Dynamo（2025 年开源）
• vLLM 0.6+ 原生支持
• SGLang 已支持
• Mooncake（某公司）：架构上就是为分离式设计的

对某业务的关键意义：256 卡某型号卡如果不做分离式部署，等于浪费 30-50% 的硬件投资。这是你能给某业务方的最高价值架构建议。

4.5 InfiniBand（IB）是什么

IB = 一种专门为高性能计算设计的网络协议和硬件。简单说：就是一种网线和网卡，但比普通以太网快得多。

IB 的核心黑科技：RDMA

RDMA = Remote Direct Memory Access。A 机器的网卡直接读 B 机器的内存，完全绕过 CPU 和操作系统。

类比：

• 普通网络 = 寄快递（要装箱、登记、转运、签收）
• RDMA = 你的助理直接进对方家里把东西拿走

用在 GPU 上叫 GPUDirect RDMA：GPU 显存 → 网卡 → IB → 对端网卡 → 对端 GPU 显存，全程不经过 CPU。

为什么对 LLM 推理重要

场景：分离式部署的 KV Cache 传输

32K 上下文的 KV Cache 约 10 GB

用 100 GbE 以太网传：10GB / 12.5 GB/s ≈ 800 毫秒（卡顿） 用 400Gb IB 传：10GB / 50 GB/s ≈ 200 毫秒（可接受）

不上 IB，分离式部署的好处会被网络吃光。

RoCE：IB 的便宜替代

RoCE = RDMA over Converged Ethernet。用便宜的以太网硬件跑接近 IB 的性能，但配置更复杂、性能略差。国内很多 AI 集群用 RoCE，因为 IB 贵。

明天必须确认

• 某数量台某型号卡之间用什么网络？IB / RoCE / 普通以太网？
• IB 是几代？带宽多少？
• IB 拓扑是什么结构？Fat-tree 还是其他？

第五部分：推理引擎选型

5.1 推理引擎到底是什么

推理引擎 = 把前面所有事情打包成一个软件，让你不用自己写。

类比：

• 你不需要自己写数据库 → 用 MySQL/PostgreSQL
• 你不需要自己写 Web 服务器 → 用 Nginx
• 你不需要自己写 LLM 推理 → 用 vLLM/SGLang/TensorRT-LLM

你的价值不是写引擎，是知道：该选哪个、怎么配置、哪些参数要调、不同引擎的极限和坑在哪。

5.2 三个主流引擎

vLLM：行业事实标准

推荐用作 baseline

核心创新：PagedAttention（KV Cache 分页）+ Continuous Batching

优势：

• 上手最快，文档最全
• 模型支持最广（新模型出来当天就支持）
• OpenAI 兼容 API
• 社区最大

劣势：

• 单卡峰值吞吐不是最高
• 多轮对话场景被 SGLang 超过

SGLang：chat/agent 场景王者

MaaS 场景首选

核心创新：RadixAttention（跨请求 KV Cache 共享）

优势：

• MaaS 场景的最优解（多客户共享 system prompt）
• 多轮对话吞吐显著领先 vLLM 30%
• 性能演进特别快

劣势：生态成熟度不如 vLLM；新模型支持慢一拍。

TensorRT-LLM：NVIDIA 官方吞吐天花板

高级配置

核心思路：编译优化，把模型编译成 NVIDIA 硬件原生的高度优化代码。

优势：

• 单卡吞吐最高
• 量化方案最全
• 投机解码做得最激进（最高 3.6x）

劣势：

• 上手门槛高，要"编译模型"
• 编译 70B 模型要 20-30 分钟
• 模型变了要重编
• 调试困难

性能对比（某型号卡 80GB, Llama 3.3 70B FP8）

按月度 GPU 成本算，30% 的差距大概是某金额/月（某规模集群）。选错引擎一年损失某金额。

5.3 OpenAI / Anthropic 实际在用什么

跟客户聊天的最高级弹药。

某厂商的快速模式（2.5 倍加速）

• 不是新硬件，还是某型号卡
• 本质：降低 batch size + 更激进的 Speculative Decoding
• 代价：单 token 成本是普通模式的 6 倍
• 哲学：保留原模型完整能力，只调 serving 参数

某厂商的某模型（15 倍加速 / 1000+ tokens/s）

• 用某厂商的晶圆级芯片（单片 70 平方英寸，44GB SRAM）
• 把整个模型放进 SRAM，避免 HBM 读写
• 不是原版某模型，是蒸馏出来的小模型
• 哲学：新硬件 + 模型蒸馏，吞吐为王

对某客户的启示：客户没有某厂商的晶圆级芯片，只有某型号卡。所以能走的是某厂商的软件路线，更激进的投机解码 + 智能 batching + Prefix Caching。具体到引擎选型，就是 SGLang 作为主引擎 + EAGLE-3 投机解码。

5.4 三步走选型方案

明天某总问"建议用哪个引擎"，标准答案：

第一阶段（1-2 个月）：vLLM 跑通 baseline。最稳妥，最快出结果。某开源模型和某国产模型都能跑起来。所有基础优化都开启：FP8 权重、FP8 KV Cache、Continuous Batching、PagedAttention、基础 Prefix Caching。这一步把硬件能力利用到 70%。

第二阶段（2-4 个月）：评估 SGLang 作为主引擎。MaaS 场景多客户共享 system prompt，RadixAttention 再榨出 30% 吞吐。如果业务方向稳定，必上。

第三阶段（可选，6 个月后）：针对最高流量模型用 TensorRT-LLM 做编译优化，再榨 15-30%。工程成本高，要看 ROI。

不建议一上来就上 TensorRT-LLM，编译时间长，模型一变要重编，工程团队会被卡住。

附录：必背数字 + 核心心智模型

明天会议室前必须脱口而出的数字

核心心智模型（一句话记忆）

如果只记一件事：LLM 是自回归生成的，一个 token 一个 token 蹦出来。整个推理时间 95% 花在 Decode 阶段，而 Decode 阶段 GPU 算力 95% 闲置。所有加速技术都在攻击这个事实。

如果记三件事

1. Prefill 处理输入（compute-bound），Decode 循环生成（memory-bound），两阶段对硬件需求完全不同
2. KV Cache 让自回归从 O(N²) 降到 O(N)，但占大量显存，是所有显存优化技术的核心战场
3. Decode 阶段 GPU 算力 95% 闲置，所以 batching、speculative decoding、量化、prefix caching 都在攻击这个事实

明天对话的开场定位

"某总，简单介绍下我自己。我在 NVIDIA 做的是 NGC 容器和 GPU 调度，之前在 Apple AIML 做多租户 GPU 平台，规模和你们这个某规模量级接近。当时核心问题和你们要解决的本质上是同一类：怎么在共享硬件上让多个互不信任的 workload 既不互相干扰、又把整体利用率拉到 70%+。这套经验放到推理 MaaS 场景，调度问题是同构的，只是 workload 从训练任务变成 serving 流量，优化目标从 throughput 变成 throughput 加 latency 双约束。今天想先听一下你们具体的业务画像，再讨论方案。"

四句话回答法

不要只给结论，要给"推导 + 代价"。明天在客户面前的标准答法：

• 结论 1 句话
• 推导 2-3 句话
• 代价 / 边界 1 句话

例：

❌ 短答："4 台的高。"

✅ 四句答："四台高，主要是 KV Cache 池子大了，batch 能开更大，吞吐能高 3-5 倍。但代价是卡间通信开销增加，某型号卡的 NVLink 还是阉割版，网络拓扑没设计好的话加卡反而变慢。所以更准确的说法是：四台理论上限高，但实际收益取决于网络设计和 workload pattern。"

脱敏说明

本文按公开发布要求做了脱敏处理：卡型号（H800/H100/H200）替换为「某型号卡」，集群规模替换为「某数量台」「某规模」，成本金额替换为「某金额」，人名替换为「某总」，客户名替换为「某客户」，未发布产品名替换为「某厂商」「某模型」。性能对比数字为公开模型与引擎的可复现结果，予以保留。

修订记录