图 1：本文封面，三大框架的核心优化与适用场景速览。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料整理，与任何公司的当前招聘无关。「推理加速框架有哪些、各自什么特点」是典型的横向对比题，面试官想看的不是你背出一串框架名单，而是你能不能把差异收拢成几条清晰的优化主线，并落到选型结论上。
一句话结论：三者的共同基座是连续批处理，差异在显存管理、编译优化、服务化封装三条主线。
先说共同基座：连续批处理。
传统静态批处理要凑齐一批请求才开算，整批里最慢的请求拖住所有人，先到位的请求干等。连续批处理把调度粒度从「一个请求」细化到「一步 token 生成」：每一步迭代都可以有请求完成退出、新请求随到随插，GPU 始终被填满。vLLM 官方文档把 continuous batching 列在核心特性里，TensorRT-LLM 称之为 in-flight batching，TGI 同样内置——三家都把这套机制当作吞吐的根基。理解了这个基座，再看各家差异化的发力点。
vLLM：用操作系统的分页思想管 KV Cache。
vLLM 的杀手锏是 PagedAttention：把 KV Cache 像操作系统的虚拟内存一样切成固定大小的块，按需分配、按块引用，显存碎片大幅减少，同一张卡能同时容纳更多并发请求。官方文档列出的能力还包括前缀缓存、FP8/INT8/INT4 等多种量化、与 OpenAI 兼容的 API 服务，以及对 Hugging Face 两百多种模型架构的支持。它的定位是自研高并发推理服务的首选：Python 生态、社区活跃、模型覆盖广；代价是推理栈要自己搭建和运维，调优也得自己来。
TensorRT-LLM：把计算图烧成定制 kernel。
英伟达官方的 TensorRT-LLM 走编译期优化路线：算子融合把逐层计算图合并成针对具体硬件定制的 kernel，再叠加 FP8（H 系列 GPU 起）与 FP4（B 系列起）量化 kernel，配合分页 KV Cache、in-flight batching、投机解码等一整套生产特性。官方给出的口径是 FP8 相比 16 位浮点性能翻倍、显存减半且对精度影响很小。它的优势是极限延迟与极限吞吐；代价是深度绑定 GPU 平台，模型接入与调优的门槛在三家之中最高。
TGI：服务化封装，开箱即用。
Hugging Face 的 TGI 把推理能力封装成一个完整服务：张量并行、连续批处理、Flash Attention 与 Paged Attention、bitsandbytes 与 GPT-Q 量化、token 流式输出、Prometheus 指标全部内置，生态内模型一条命令起服务。它适合快速上线、少运维的场景，极限性能则不及专用引擎。还有一个选型时必须知道的信号：TGI 官方文档已宣布项目进入维护模式，只接受小幅修复，并建议新项目转向 vLLM、SGLang 等下游引擎。
三条主线对应三个指标。
把上面的差异翻译成评估语言：显存管理决定同样硬件能容纳多少并发，对应吞吐与成本；编译优化决定单步计算有多快，对应首 token 延迟与单请求时延；服务化封装决定从模型文件到上线 API 要多少人力，对应交付速度与运维负担。三个指标往往不可兼得，这正是选型题有讨论空间的原因——没有「最强框架」，只有「最适合当前约束的框架」。
选型一句话：要高吞吐且能自维护，选 vLLM；硬件固定追极限性能，选 TensorRT-LLM；要快上线少运维，选 TGI——但把维护模式这个信号纳入长期考量。
图 2：共同基座、三条优化主线与选型对照。
面试现场的答题结构。
先抛框架名单，每个给一句定位；然后收拢到方法论——三者都以连续批处理为基座，差异是显存管理（PagedAttention 分页）、编译优化（算子融合加量化 kernel）、服务化封装（开箱即用）三条主线，分别对应吞吐、延迟、易用性三个指标。遇到追问「你们项目该用哪个」，按三个问题作答：硬件是否固定、团队有没有运维推理栈的能力、性能要求到哪个量级。最后补一句时效意识：框架能力随版本快速演进，落地前以各自官方文档的当前特性为准。你在生产里用过哪个推理框架？选型时最看重的因素是什么？欢迎聊聊。