vLLM vs 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 | 轻依赖本地与边缘推理 | GGUF、多种整数位宽、CPU 和多类 GPU 后端、CPU/GPU 混合 | 支持远不止 Llama，但具体算子、模态与量化需查模型列表 |
框架不能脱离模型和硬件排名。应固定 checkpoint、prompt/output 长度、dtype/量化、并发和质量门槛，分别测冷启动、TTFT、TPOT、吞吐、P95/P99、峰值内存与能耗。任何“固定 50ms”都缺少模型、batch、上下文与硬件前提。
口语版讲法(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、多模态、监控、滚动升级和回滚。只有目标负载下的端到端结果，才能决定采用哪个框架。
【验证补充】生产验证应覆盖取消请求、超时、长短请求混合、模型热更新和异常输入。某框架在规则长度压测中领先，面对真实长度分布和结构化输出时可能改变排序，所以需要保存完整压测配置与原始延迟分布。
关键一句:框架支持列表和性能数字都必须绑定版本、模型、硬件与工作负载。
核验来源
面试官还可能这样问
- 问法 1 · 场景切入
假设现在要为在线大模型服务选择推理框架，业务同时关注首 token 延迟、持续生成速度、吞吐和显存。你会先定义怎样的 workload，再比较 vLLM、TensorRT-LLM 与 TGI？
- 问法 2 · 层层追问
模型、硬件、上下文和并发不固定时能直接排名吗？……PagedAttention、连续批处理和融合 kernel 分别解决什么？……模型/量化支持矩阵与维护状态怎样进入决策？
- 问法 3 · 直球技术
请在同模型、同硬件、同长度分布和同质量门槛下，对比 vLLM、TensorRT-LLM、TGI 的 TTFT、TPOT、吞吐、尾延迟、内存与模型支持，并给出选型流程。