vLLM vs TensorRT-LLM 怎么选?

来源标签：2026真题公司标签：京东 #vLLM #TensorRT-LLM #推理引擎 #吞吐量优化 #生产部署

搜索「并行」匹配到口述回答，相关段落已展开。查看匹配内容 ↓

完整题目

请列举并比较主流的大语言模型推理框架（如vLLM、TensorRT-LLM、HuggingFace TGI等），从吞吐量、延迟、内存优化和支持模型类型等方面进行分析。

框架比较必须以当前官方支持矩阵为准

框架	主要定位	典型能力	需要注意
vLLM	GPU/多后端高吞吐服务	PagedAttention、连续批处理、张量/流水线并行、OpenAI 兼容服务	支持架构、量化和硬件能力随版本变化
TensorRT-LLM	NVIDIA GPU 深度优化	TensorRT engine、in-flight batching、KV 优化、量化与多 GPU	使用自有 checkpoint/engine 工作流，可从 Hugging Face、NeMo 等来源转换，并非必须先经过 ONNX
TGI	Hugging Face 模型服务	连续批处理、流式输出、张量并行、量化和监控	官方文档当前标注为 maintenance mode，选型前应确认维护与后端支持
llama.cpp

学习内容与项目面试，在同一条路上。

站内 RAG 在线实战

继续追问 · 3 个问题

如果要在京东的客服场景部署一个7B模型，要求支持1000 QPS、P99延迟<200ms，你会怎么选型？
vLLM的Prefix Caching和Chunked Prefill具体解决了什么问题？
TensorRT-LLM的FP8量化在实际落地中有什么坑？

换一种问法，检查是否真正理解

场景切入

假设现在要为在线大模型服务选择推理框架，业务同时关注首 token 延迟、持续生成速度、吞吐和显存。你会先定义怎样的 workload，再比较 vLLM、TensorRT-LLM 与 TGI？

层层追问

模型、硬件、上下文和并发不固定时能直接排名吗？……PagedAttention、连续批处理和融合 kernel 分别解决什么？……模型/量化支持矩阵与维护状态怎样进入决策？

直球技术

请在同模型、同硬件、同长度分布和同质量门槛下，对比 vLLM、TensorRT-LLM、TGI 的 TTFT、TPOT、吞吐、尾延迟、内存与模型支持，并给出选型流程。

练习口述回答 · 30秒速答 + 90秒主答 + 完整展开

先锁定模型、硬件和服务目标
按框架官方能力说明定位
纠正 TensorRT-LLM 与 ONNX 的关系
说明 llama.cpp 的模型和硬件范围
用统一 benchmark 做最终选择

【30秒速答】推理框架没有脱离场景的总冠军。vLLM 侧重 PagedAttention、连续批处理和高吞吐服务；TensorRT-LLM 面向 NVIDIA GPU 深度优化，使用自己的 checkpoint 与 engine 流程，不要求模型必须先转 ONNX；TGI 提供成熟的 Hugging Face 服务能力，但官方当前把项目标成 maintenance mode；llama.cpp 面向轻量本地和边缘部署，支持 GGUF、CPU 与多种 GPU，也远不只支持 Llama。比较时固定模型、量化、上下文和并发，分别测 TTFT、TPOT、吞吐、尾延迟与内存。

【90秒主答】 vLLM 的强项是面向在线生成的内存管理与调度。PagedAttention 把 KV Cache 按块管理，连续批处理在请求结束后补入新请求，配合张量并行和 OpenAI 兼容接口，适合动态长度、高并发的服务。实际支持取决于模型架构、attention 形式、量化格式和设备后端，看到“兼容 Transformers”不代表每个自定义算子都能走最优 kernel。

TensorRT-LLM 更贴近 NVIDIA 软件栈。常见流程是把 Hugging Face、NeMo、ModelOpt 或其他来源的权重转换为 TensorRT-LLM checkpoint，再根据目标 GPU、并行度、最大序列和量化配置构建 engine。ONNX 可以出现在某些生态链路里，但不是 TensorRT-LLM 的硬性前置格式。它能充分利用 NVIDIA kernel、量化、调度和多 GPU 能力，代价是 engine 构建、版本配套和部署配置更专门。

【完整展开】 TGI 集成模型下载、流式输出、张量并行、连续批处理、量化、监控和安全相关能力，适合 Hugging Face 生态。当前官方文档明确标注项目进入维护模式，并推荐关注 vLLM、SGLang 与本地引擎，因此新项目不能只凭历史热度选它，还要评估维护周期、目标模型和硬件后端。llama.cpp 的核心是低依赖 C/C++ 推理与 GGUF 生态，支持多种整数位宽、Apple Silicon、x86、CUDA、HIP、Vulkan 等后端，也列出了 Mistral、Mixtral、BERT、Qwen、Gemma 等大量架构。它适合本地、CPU、混合卸载或资源受限环境，但不意味着所有模型和服务器负载都比 GPU 专用引擎快。

基准必须统一。先固定完全相同的模型权重或可对齐的量化权重、提示与输出长度、batch 策略、并发、硬件功耗限制和质量阈值。接着测冷启动、TTFT、TPOT、每秒 token、P50/P95/P99、峰值显存或内存、错误率与稳定运行时间。单请求 50ms 若没有说明是首 token、单 token 还是完整回复，没有任何可比性。框架选择还应考虑结构化输出、LoRA、多模态、监控、滚动升级和回滚。只有目标负载下的端到端结果，才能决定采用哪个框架。

【验证补充】生产验证应覆盖取消请求、超时、长短请求混合、模型热更新和异常输入。某框架在规则长度压测中领先，面对真实长度分布和结构化输出时可能改变排序，所以需要保存完整压测配置与原始延迟分布。