完整题目
请列举并比较主流的大语言模型推理框架（如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、上下文与硬件前提。
继续追问 · 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 专用引擎快。