真实面经题目 · 原创解析
这题考 LLM 推理部署中的系统取舍。好的回答要把 vLLM 和 TensorRT-LLM 区分为不同工程侧重点：vLLM 更像面向在线服务的通用推理引擎和调度系统，强调 PagedAttention、连续批处理、OpenAI 兼容服务和模型接入灵活性；TensorRT-LLM 更贴近 NVIDIA GPU 上的编译优化与高性能运行时，强调 TensorRT engine、算子融合、专用 kernel、量化、KV cache、in-flight batching 和多 GPU 通信优化。不能简单说谁一定更快，要看模型、硬件、batch、延迟目标和工程成本。
我会先说它们的定位不同。vLLM 的核心优势是服务层和调度层友好，典型能力包括 PagedAttention 管理 KV cache、continuous batching 提升在线吞吐、prefix cache、OpenAI 兼容接口、较快支持多种模型和采样策略，适合需要快速上线、模型变化频繁、在线请求形态复杂的场景。TensorRT-LLM 更偏 NVIDIA GPU 上的深度优化推理栈，它通常需要把模型转换或构建成 TensorRT-LLM engine，然后用高度优化的 runtime 执行；优势来自图优化、算子融合、GEMM 和 attention 专用 kernel、FP8/INT8/INT4 等量化路径、paged KV cache、in-flight batching、remove input padding、多 GPU tensor/pipeline parallel 通信优化等。TRT-LLM 的加速机制不能只说 TensorRT 很快，要具体讲：第一，通过构建 engine 固化计算图和 kernel 选择，减少 Python 框架调度与通用算子开销；第二，把 RMSNorm、RoPE、QKV projection、attention、MLP 等路径尽可能用融合 kernel 或插件优化，减少显存读写和 kernel launch；第三，用半精度和低比特量化降低带宽与计算压力，但需要校准和精度验证；第四，用 KV cache 管理和 in-flight batching 提高解码阶段 GPU 利用率；第五，在多 GPU 下优化 tensor parallel、pipeline parallel 和通信 overlap。选型上，如果目标是快速服务化、多模型兼容、动态请求和较低接入成本，vLLM 往往更直接；如果目标是固定模型、固定 NVIDIA 硬件、极致吞吐或延迟，并愿意承担 engine 构建、版本适配和精度验证成本，TRT-LLM 更值得评估。最终还是要用同一模型、同一硬件、同一并发和同一输出长度压测 TTFT、TPOT、吞吐、显存、稳定性和精度，而不是靠框架名下结论。
vLLM 更像通用 LLM serving engine，重点在在线请求调度、KV cache 管理、API 兼容和模型支持速度。TensorRT-LLM 更像 NVIDIA GPU 上的编译优化与运行时栈，重点在 engine 构建、kernel 优化、量化和多 GPU 高性能执行。不同场景下二者优先级不同。
vLLM 通过 PagedAttention 把 KV cache 像分页内存一样管理，降低碎片并提升并发下的 cache 利用；continuous batching 可以把不同时间到达、不同长度的请求持续合批，提高在线吞吐。它还常用于 OpenAI 兼容服务、多模型快速接入和复杂采样策略。
TensorRT-LLM 通常会针对目标模型和硬件构建 optimized engine，运行时使用专门优化的 attention、GEMM、normalization、activation、KV cache 和通信路径。它的工程思路是减少通用深度学习框架开销，把关键路径尽量落到高效 kernel 和 TensorRT 图优化上。
TRT-LLM 构建 engine 后可以固化很多图级优化、kernel 选择和数据类型策略，但也意味着模型结构、权重格式、GPU 架构、batch/sequence 配置和版本兼容需要管理。模型频繁变化或需要快速试错时，这部分工程成本要纳入选型。
LLM 推理中很多时间花在 attention、MLP、norm、RoPE、QKV projection 和采样相关路径上。TRT-LLM 的一类加速来自融合 kernel 和插件，把多个小算子合并，减少中间张量读写和 kernel launch，提高 GPU 利用率，尤其是在 decode 阶段更关键。
TRT-LLM 支持多种低精度推理路径，常见目标是用 FP16/BF16、FP8、INT8 或 INT4 等方式降低显存占用、显存带宽和矩阵计算成本。量化不是免费收益，必须验证校准方法、模型精度、长上下文稳定性和不同 batch 下的性能。
LLM decode 阶段每步只生成少量 token，但要读大量 KV cache。TRT-LLM 和 vLLM 都会关注 KV cache 管理和动态批处理，只是实现路径不同。TRT-LLM 中 in-flight batching、paged KV cache、input padding 移除等机制可以减少无效计算并提高并发请求下的 GPU 利用率。
比较时要固定模型、权重精度、硬件、上下文长度、并发、输入输出分布、采样参数和服务接口，分别看 TTFT、TPOT、tokens/s、显存峰值、失败率、冷启动、扩缩容和精度。不能只看单机最大吞吐，也不能只看空载延迟。
engine 构建可以针对模型结构、权重类型、GPU 架构和推理配置选择更合适的 kernel、数据布局和图优化策略。这样运行时更少依赖通用框架动态调度，但代价是构建流程、版本兼容、配置管理和模型更新成本更高。
它主要解决在线 serving 中 KV cache 分配和碎片问题。不同请求长度不同、结束时间不同，如果 KV cache 需要连续大块内存，会造成浪费和搬迁成本。分页式管理可以让 cache 以块为单位分配和复用，从而提高并发下的显存利用率。
普通 batching 往往把一批请求一起开始、一起执行，容易被长短请求差异拖慢。in-flight batching 或 continuous batching 会在解码过程中动态加入新请求、移除完成请求，让 GPU 持续保持较高利用率，更适合在线流量的变长输入输出。
不一定。量化能降低显存和计算压力，但最终收益取决于硬件是否高效支持该精度、kernel 是否优化、batch 和序列长度是否合适，以及反量化或额外算子是否抵消收益。还必须验证精度和长上下文稳定性，不能只看 tokens/s。
先看约束：如果模型迭代频繁、需要快速兼容新模型、服务接口和调度能力优先，vLLM 往往更容易落地；如果模型相对固定、硬件是 NVIDIA GPU、目标是极致吞吐或延迟，并能投入构建和验证，TRT-LLM 值得压测。最终用真实业务流量分布做 A/B 压测决定。
