## 一、推理和训练，是两种完全不同的动物

训练是流水线：几千个 token 一起过一遍模型，计算密集，GPU 吃得饱饱的。

推理是单行道：用户的问题（prompt）先整体算一遍（这叫 **prefill**），然后一次只能生成一个 token（这叫 **decode**）。生成第 2 个 token 依赖第 1 个，第 3 个依赖前两个，天生串行，没法并行。

decode 为什么这么贵？因为它是**内存带宽密集**而不是计算密集：

- 每一步前向，都要把整个模型的权重从显存（HBM）搬到计算单元（SM）。
- 70B 模型 FP8 权重大约 70GB，每一步都要完整搬一遍，而实际算的只是一个 token 的矩阵乘。
- 结果就是 GPU 的计算单元大部分时间在等内存，利用率只有个位数百分比。

![fig9-memory-wall.png](https://developer.qcloudimg.com/http-save/yehe-11479707/2a6c65752925271bc4c4271d00c72d5d.png)

一个直观的数字：H100 上跑 70B 模型 FP8，单个请求生成一个 token 大约要 25–40ms（纯权重搬运的理论下限约 20ms，全栈实测更高，2026 年公开基准）。这不是算得慢，是权重搬得太慢。这个"内存墙"是整个推理优化领域的出发点。

## 二、批处理演进：从"等最慢的人"到"边跑边上下车"

既然单请求喂不饱 GPU，很自然的思路是让多个请求一起算。但怎么批，学问很大。

**静态批处理**：攒够一批才开工，整批做完才放人。问题是序列长短不一，所有人都要等最长的那个，短的序列在"填充"上浪费大量计算。

**动态批处理**：设置一个 2–10ms 的窗口，窗口到了就把已经到的请求一起发出去，用延迟换吞吐（书第 16 章）。

**连续批处理**：真正的革命。不再等整批完成，而是每个 token 生成步结束时，把完成的请求踢出去、立刻拉新请求进来，GPU 槽位永远不空（书第 16 章）。大模型上批 4–8 个请求，吞吐通常能比 1–2 个请求翻一倍到三倍。

**分块预填充**：一个大 prompt 的 prefill 会独占 GPU 很久，把其他用户的 decode 全部堵死。解法是把大 prompt 切成小块，和 decode 交错着算，避免一个请求饿死整批人。

![fig9-batching.png](https://developer.qcloudimg.com/http-save/yehe-11479707/ad806d4395565960761f80d6db898a86.png)

2026 年，连续批处理已经是所有主流引擎的标配（vLLM、SGLang、TensorRT-LLM、NVIDIA Dynamo 都支持）。

## 三、PagedAttention：把显存当内存分页管

批处理做起来了，下一个瓶颈是显存放不下。

每个请求的 KV Cache（记录历史 token 的 key-value 张量）随序列长度线性增长。算笔账：Llama-3-70B 在 FP16 下，128K 上下文的 KV Cache 大约 35–40GB（随 GQA 头数而异），而模型权重约 140GB；高并发场景下，KV Cache 能占到显存需求的八成以上（2026 年 KV Cache 架构分析）。

传统做法是给每个请求预分配连续显存，浪费极大，利用率常不足 60%。

vLLM 的 **PagedAttention** 借鉴操作系统虚拟内存的分页思想，把 KV Cache 切成 16 或 64 token 的固定块，按需分配、不连续存储，物理块可以共享（Copy-on-Write）。效果：把显存浪费从传统预分配的 60–80% 压到 4% 以下（利用率约 96%），ShareGPT 真实对话负载下有效并发请求数从 7 提升到 30（来源：vLLM PagedAttention 论文）。

以前是每个请求占一整间房，现在改成按床位分配，还能多人拼床。

## 四、2026 引擎矩阵比较：vLLM vs SGLang vs TensorRT-LLM

引擎是推理性能的最终落点。同一个模型，不同引擎能差出 10% 以上的吞吐。

下面是 2026 年一组公开基准的量级对比（H100 80GB、Llama-3.3-70B FP8、100 并发，来源：Spheron Network 与掘金等公开评测）：

| 指标                   | vLLM                     | SGLang                          | TensorRT-LLM |
| -------------------- | ------------------------ | ------------------------------- | ------------ |
| 100 并发吞吐 (tok/s)     | ~2.4k                    | ~2.5k                           | **~2.8k**    |
| 100 并发 p95 TTFT (ms) | ~1.45s                   | ~1.38s                          | **~1.28s**   |
| 冷启动到首请求              | ~1 分钟                    | ~1 分钟                           | 首次编译约 30 分钟  |
| 前缀共享场景               | 一般                       | **最高（比 vLLM 高约 25–45%，视前缀命中率）** | 一般           |
| 硬件支持                 | 最广（NVIDIA/AMD/Intel/TPU） | NVIDIA 为主                       | **仅 NVIDIA** |
| 部署复杂度                | 简单                       | 简单                              | 较复杂（需编译流水线）  |

![fig9-engine.png](https://developer.qcloudimg.com/http-save/yehe-11479707/262c951f0a5c261b8f6c7b4099ddf941.png)

> 以上为公开基准的量级（模拟基准，仅示相对差距），不同负载、不同批次下结论会变，上线前务必用你自己的流量实测。

**选型决策树**（2026 年多篇引擎评测的共识）：

1. 硬件不是纯 NVIDIA？只有 vLLM 能选。
2. 模型经常换？选 vLLM，兼容性最广，先跑通再说。
3. 共享前缀多（agent、多轮对话、RAG）？选 SGLang，RadixAttention 前缀共享能多出约 25–45% 吞吐（视前缀命中率）。
4. 固定一个模型、追求极致性能、团队有运维余力？选 TensorRT-LLM。
5. 都不确定？选 vLLM，它是 2026 年的安全选择。

### 踩坑现场：三件容易被背刺的事

**① 70B 模型塞进 80GB 卡，上下文窗口一调大就 OOM。** 权重占了 70GB（FP8），剩下的显存全被 KV Cache 吃掉。调上下文长度前，一定先算显存账：KV Cache 是隐形内存怪兽。

**② TensorRT-LLM 首次编译要等半小时。** 它不是慢，是"一次性重活"：编译好的引擎二进制存下来，重启只要 90 秒。但如果模型一个月换三次，这半小时会变成日常开销。新出的 PyTorch 后端把冷启动压到 1 分钟左右，代价是吞吐低 15–20%。

**③ 无脑上 INT4。** 很多人以为 4-bit 一定比 8-bit 快。错。Hopper 上 INT4 权重没有真正的 4-bit 计算，要先把权重反量化回 FP16 再做矩阵乘，提速高度依赖场景（低并发 decode 才划算）；而 FP8 是 Hopper 原生精度，又快又准，精度损失还更小。**Hopper 上 FP8 优先于 INT4**（2026 年量化实测）。

## 五、一个反共识判断

市面上到处是"推理性能 PK"的榜单，但我的建议是：不要在开发阶段追极致优化。

先用 vLLM 默认配置把整个应用流程跑通，确认功能正确、拿到指标基线，再按瓶颈逐步开优化（量化、前缀缓存、PD 分离、投机解码）。过早优化是工程大忌，推理优化尤其如此，每一步优化都会引入新的配置面和排障成本。

vLLM 先跑通，瓶颈再换枪。这也是为什么 vLLM 能成为 2026 年开源推理引擎的事实标准（GitHub 8 万+ star，阿里、腾讯、字节等都在用）。

---

## 你被哪件事坑过？

你线上推理遇到过 OOM、冷启动爆炸，还是无脑量化翻车？评论区说说你的引擎选型和踩坑经历。

---

## 参考资料

- Chris Fregly, *AI Systems Performance Engineering*, O'Reilly Media（第 15–16 章）
- vLLM PagedAttention（SOSP 2023 论文）与 vLLM 官方文档
- Spheron Network：《vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks 2026》（掘金等转载复测）
- 掘金：《LLM 推理引擎实战横评：H100 上真实表现》
- AITechConnect：《Picking an LLM Serving Engine》
- ZOOZ Engineering：《LLM Inference Concepts and Optimization Techniques》

> 说明：图 fig9-memory-wall / fig9-batching 为示意。引擎对比为 2026 年公开基准量级（仅示相对差距），不同负载下结论可能不同；连续批处理、PagedAttention 机制沿用书第 16 章，截至 2026 年 8 月。


推理是单行道：用户的问题（prompt）先整体算一遍（这叫 prefill），然后一次只能生成一个 token（这叫 decode）。生成第 2 个 token 依赖第 1 个，第 3 个依赖前两个，天生串行，没法并行。

AI Infra 系列 · 第四章 推理引擎 (上)：为什么 LLM 一次只蹦一个 token，vLLM 和 SGLang 到底差在哪

训练是流水线，推理是单行道。一个 70B 模型在 GPU 上生成一个 token 要几十毫秒，用户感知就是"一个字一个字往外蹦"。这篇讲清楚 LLM 推理为什么天生慢、现代引擎（vLLM/SGLang/TensorRT-LLM）靠什么把它压回来，以及 2026 年三个引擎到底怎么选。

运维开发工程师

人工智能

云计算

架构设计

大模型推理性能受制于“内存墙”与串行解码，核心优化方案包括连续批处理、PagedAttention显存分页管理及引擎选型。对比vLLM、SGLang与TensorRT-LLM，各自适应不同场景，且需警惕显存计算、冷启动及INT4量化等常见陷阱，优先使用vLLM跑通流程再逐级优化。

2026上云采购 | AI焕新·智启新局

tione

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI Infra 系列 · 第四章 推理引擎 (上)：为什么 LLM 一次只蹦一个 token，vLLM 和 SGLang 到底差在哪-腾讯云开发者社区-腾讯云

AI Infra 系列 · 第四章推理引擎 (上)：为什么 LLM 一次只蹦一个 token，vLLM 和 SGLang 到底差在哪

AI Infra 系列 · 第四章推理引擎 (上)：为什么 LLM 一次只蹦一个 token，vLLM 和 SGLang 到底差在哪

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第四章 推理引擎 (上)：为什么 LLM 一次只蹦一个 token，vLLM 和 SGLang 到底差在哪

AI Infra 系列 · 第四章 推理引擎 (上)：为什么 LLM 一次只蹦一个 token，vLLM 和 SGLang 到底差在哪

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第四章推理引擎 (上)：为什么 LLM 一次只蹦一个 token，vLLM 和 SGLang 到底差在哪

AI Infra 系列 · 第四章推理引擎 (上)：为什么 LLM 一次只蹦一个 token，vLLM 和 SGLang 到底差在哪