推理框架怎么选：vLLM、TensorRT-LLM、Transformers 推理的优缺点对比

在《Ai大模型训练教程：从入门到实战落地的系统课程》系列里，训练只是把模型“做出来”，推理框架的选择才决定了模型能否“跑得快、跑得稳、跑得省”。同一个 7B/13B 模型，用不同推理框架，吞吐、延迟、显存占用、部署复杂度会出现数量级差异。

本文围绕三类最常用的推理路径：Transformers（HF 直接推理）、vLLM、TensorRT-LLM，用“能落地的决策维度”拆解它们各自的优缺点，并给出可直接照做的选型步骤、典型配置建议与适用场景。

选型前先统一目标：你要优化的是哪一个指标？

推理框架对“性能”的提升往往是对特定指标的极致优化。选型前先把目标写清楚，否则很容易出现“上了最复杂的方案却没解决痛点”。常见目标如下：

1) 延迟（Latency）

• TTFT（Time To First Token）：从请求到返回第一个 token 的时间。
• TPOT（Time Per Output Token）：每输出一个 token 花的时间。

适用场景：在线对话、客服机器人、Copilot 类产品。

2) 吞吐（Throughput）

• tokens/s（总吞吐）：单位时间内生成的 token 总数。
• 并发能力：同时服务的请求数。

适用场景：批量生成、离线数据生产、内容审核/标注、RAG 批处理。

3) 成本（Cost）

• 显存占用：模型权重 + KV Cache + 运行时开销。
• GPU 利用率：是否能把 GPU “吃满”。

适用场景：多租户、云部署、预算敏感。

4) 兼容性与工程效率

• 是否支持你的模型结构（MoE、GQA、滑窗注意力等）。
• 是否方便接入 LoRA、多 adapter、多模型热切换。
• 是否容易运维：日志、监控、扩缩容、故障恢复。

三种推理路线的定位一句话总结

• Transformers 推理：最通用、最省心、最适合验证与小规模部署，但高并发吞吐通常不占优。
• vLLM：面向在线服务的“性价比王者”，核心优势是 PagedAttention + 连续批处理（continuous batching），吞吐和显存效率通常领先。
• TensorRT-LLM：面向极致性能/企业级优化的“硬核选手”，在 NVIDIA 生态内能把延迟与吞吐推到更高，但工程复杂度与约束也更多。

Transformers（Hugging Face）推理：优缺点与适用场景

优点

1) 上手最快、兼容最广

• 几乎所有开源 LLM（LLaMA 系、Qwen 系、Mistral 系等）第一时间都能用 Transformers 跑起来。
• 各类 tokenizer、chat template、generation config 最全。

2) 功能生态强

• 方便做实验：对比不同采样策略（top_p、top_k、temperature）、停止词、logits processor。
• 容易接入 PEFT/LoRA、量化（bitsandbytes、GPTQ/AWQ 的部分路径）。

3) 调试友好

• 报错信息、社区经验、issue 与示例多。
• 适合“先跑通再优化”的路线。

缺点

1) 高并发吞吐一般

• 虽然可以用 torch.compile、FlashAttention、BetterTransformer 等优化，但在“持续高并发 + 长上下文”的情况下，吞吐与显存效率往往不如 vLLM。

2) KV Cache 管理不够激进

• KV Cache 是推理显存大头。Transformers 通常按 batch 固定形态管理，面对多请求动态长度时，显存碎片与浪费更明显。

3) 服务化要自己拼

• 你需要自己做 batching、队列、超时、限流、监控，或依赖第三方服务框架。

适用场景建议

• 你在做 模型效果验证/Prompt 调试/小批量离线生成。
• 你需要 最强的模型兼容性（新模型刚出、结构特殊）。
• 你更关注功能正确性而不是极致吞吐。

实操建议（可直接照做）

• 小规模服务时，优先把以下三件事做对：
  1) 半精度/低精度：FP16/BF16 优先，其次再考虑 INT8/INT4。
  2) FlashAttention：能用就用，尤其长上下文。
  3) 合理的 max_new_tokens 与 stop：防止长尾请求拖垮整体延迟。

vLLM：为什么它在“在线推理服务”里很强？

vLLM 的核心竞争力通常来自两点：

1) PagedAttention：更省显存的 KV Cache 管理

传统实现中，KV Cache 通常为每个序列分配连续显存，序列长度变化会造成浪费；vLLM 采用类似“分页”的方式管理 KV Cache，让显存利用更接近真实使用量。

你能直接感受到的结果：

• 同一张卡上，vLLM 往往能承载更高并发或更长上下文。
• 多请求长度差异大时（真实线上很常见），优势更明显。

2) Continuous Batching：持续批处理提升吞吐

Transformers 的“静态 batch”对在线请求不友好：请求来得不齐就凑不出 batch；等 batch 又增加延迟。vLLM 的 continuous batching 让请求持续合并、持续出 token，在不显著牺牲 TTFT 的情况下把 GPU 填满。

vLLM 的优点

1) 吞吐与并发通常领先

• 对在线 chat、多用户并发最友好。

2) 服务化成熟

• 通常会配套 OpenAI API 风格接口或易集成的服务方式（不同版本/封装略有差异），更接近“开箱即用”。

3) 工程成本适中

• 相比 TensorRT-LLM，更少的引擎构建步骤与模型转换门槛。

vLLM 的缺点与坑

1) 并非所有模型结构/量化路径都第一时间支持

• 新架构刚出时，Transformers 往往先支持，vLLM 需要跟进。

2) 极致低延迟不一定最强

• 在“单请求极致低延迟”或特定硬件/特定 batch 的压榨上，TensorRT-LLM 往往更有上限。

3) 一些高级特性需要额外配置

• 多 LoRA adapter 热切换、复杂采样、特定 logits 处理等，有时不如 Transformers 灵活。

适用场景建议

• 你要做 线上推理服务，并发上来后 Transformers 顶不住。
• 你的痛点是 吞吐/显存/并发，希望在工程复杂度可控下提升性价比。
• 你希望比较标准的 LLM Chat/Completion 服务接口。

实操选型建议：vLLM 适合的“典型配置思路”

1) 先确定上下文长度与并发目标：例如 8k 上下文、并发 50。
2) 评估 KV Cache 显存占用：上下文越长，KV 越大；把并发与最大上下文乘起来估算。
3) 设置合理的限流与队列：在线服务必须限制 max_tokens、max_concurrency，否则少数长请求会把所有人拖慢。
4) 观测两个指标再调参：

• TTFT：是否因为队列过长而变差；
• 总 tokens/s：是否 GPU 利用率不高（可能 batch 还不够、或 CPU 成瓶颈）。

TensorRT-LLM：极致性能与企业级优化的路线

TensorRT-LLM 可以理解为：在 NVIDIA 生态上，把 LLM 推理做成“更贴近硬件、更激进融合”的高性能方案。很多情况下，它在同等硬件上能进一步降低延迟或提高吞吐，尤其是在固定模型、固定形态、追求极限的生产环境。

优点

1) 极致性能上限高

• kernel 融合、图优化、针对特定 GPU 架构的优化更激进。
• 对于固定 batch/固定 shape 的场景更容易跑出“压榨级”指标。

2) 对生产场景更“硬”

• 更适合企业里“模型稳定、版本可控、运行环境可控”的部署方式。

3) 与 NVIDIA 生态协同

• 与 Triton Inference Server、CUDA、TensorRT 等组件组合，形成相对完整的推理栈。

缺点与现实成本

1) 工程复杂度与约束更高

• 往往涉及模型转换、构建引擎（engine）、处理动态 shape、插件算子等。
• 模型一旦改结构/换版本，可能需要重新构建与验证。

2) 兼容性不如 Transformers“无脑”

• 新模型或特殊结构可能需要等待支持或手工适配。

3) 迭代速度较慢

• 如果你处在快速试错期（Prompt/模型频繁变化），这条路线可能拖慢迭代。

适用场景建议

• 你有明确的 SLA（比如 P99 延迟、固定吞吐），并且模型版本稳定。
• 你已经验证过模型效果，进入 规模化上线与成本优化 阶段。
• 你在 NVIDIA GPU 集群上，愿意用更复杂的工程换极限性能。

维度对比表：怎么一眼看出差异

核心对比（概念级）

• 上手难度：Transformers 最低；vLLM 中等；TensorRT-LLM 最高。
• 吞吐/并发：vLLM 通常最优；TensorRT-LLM 在特定场景可超；Transformers 通常落后。
• 单请求极致延迟：TensorRT-LLM 往往更强；vLLM 次之；Transformers 依赖优化。
• 显存效率（KV Cache）：vLLM 通常更好；TensorRT-LLM 也能很强；Transformers 相对一般。
• 兼容性/灵活性：Transformers 最强；vLLM 次之；TensorRT-LLM 更受约束。
• 迭代速度：Transformers 最快；vLLM 中等；TensorRT-LLM 最慢。

实操决策流程：按这 5 步选框架（建议直接照抄到你的项目文档）

Step 1：写清业务形态（决定优化方向）

• 在线聊天？还是离线批量？
• QPS/并发目标是多少？
• 上下文长度（输入 tokens）与输出长度（max_new_tokens）典型值是多少？

示例：

• 在线客服：并发 100，典型输入 2k，输出 256，P95 TTFT < 800ms。
• 离线改写：每天 500 万条，输入 512，输出 256，吞吐优先。

Step 2：锁定约束（硬件/环境/团队）

• GPU 型号（A100/H100/4090/L40S 等）、单机多卡还是多机。
• 能否接受 NVIDIA 生态绑定（TensorRT-LLM 更明显）。
• 团队是否有 CUDA/TensorRT 经验。

Step 3：先用 Transformers 跑通基线（强烈建议）

即便最终要上 vLLM 或 TensorRT-LLM，也建议先用 Transformers 做“正确性基线”：

• 产出可复现实验：同一批 prompt、同一组 generation 参数、同一组输出。
• 固化 tokenizer/chat template，避免后续框架切换引入“输出风格变化”。

Step 4：进入服务化与性能期，优先尝试 vLLM

当你发现：

• 并发一高就爆显存；
• GPU 利用率上不去；
• 延迟在高峰期抖动明显；

此时通常 vLLM 是投入产出比最高的优化。

Step 5：SLA 压力极大或成本极致优化，再上 TensorRT-LLM

只有当你满足以下条件时，TensorRT-LLM 才“更划算”：

• 模型版本相对稳定（至少一段时间不大改）；
• 你需要明确可量化的提升（例如吞吐提升 20%+ 或 P99 降到某个硬指标）；
• 你有足够工程投入做引擎构建、验证与回归。

常见误区与避坑清单

误区 1：只看 tokens/s，不看 TTFT 与长尾

在线业务里，用户体验往往被 TTFT 与 P95/P99 决定。vLLM 可能在吞吐很强，但如果限流/队列策略没配好，TTFT 会被排队时间吞掉。

建议：压测时至少同时记录：

• 平均 TTFT、P95 TTFT
• 平均 tokens/s、P95 tokens/s
• GPU 显存峰值与利用率

误区 2：上下文窗口开到最大，导致 KV Cache 把一切淹没

即使你用了 vLLM，超长上下文 + 高并发仍然会把 KV Cache 撑爆。

建议：

• 为不同业务路由不同的 max_model_len 或 max_input_tokens。
• 对 RAG 场景做检索裁剪与摘要，而不是无脑塞满上下文。

误区 3：频繁换模型版本却走 TensorRT-LLM

TensorRT-LLM 更适合“稳定模型”。你若还在快速试错期，每次改一点就要重新构建/验证，整体效率会下降。

建议：

• 试错期：Transformers / vLLM。
• 稳定期：TensorRT-LLM。

误区 4：忽略采样策略对性能的影响

• beam search 通常更慢。
• temperature/top_p 本身不一定慢，但复杂 logits 处理会增加 CPU/GPU 开销。

建议：对“性能敏感”接口尽量使用更简单的 decoding 配置，并分层：

• 标准回答：greedy/较简单采样
• 高质量生成：单独队列与配额

结论：三选一的快速建议

• 你要 最快跑通、最强兼容、快速验证：选 Transformers。
• 你要 在线高并发服务、显存效率、吞吐性价比：优先 vLLM。
• 你要 NVIDIA 生态内的极致性能与严格 SLA，且模型稳定、工程资源足：选 TensorRT-LLM。

在本系列《Ai大模型训练教程》中，建议把推理框架选型当成“工程路线图”的一部分：先用 Transformers 建立可复现的正确性与评测体系，再用 vLLM 提升服务能力，最后在规模化阶段评估是否值得为 TensorRT-LLM 的极限性能投入工程成本。