完整题目
请列举并简要说明当前主流的大语言模型推理框架，比较它们在性能、易用性和扩展性方面的优缺点。
推理框架要按工作负载、硬件和维护状态选型
vLLM 面向服务化高吞吐，提供连续批处理、分页 KV cache、OpenAI 兼容接口与多种并行方式，当前官方文档覆盖 NVIDIA CUDA、AMD ROCm、Intel XPU、CPU，并通过插件扩展其他加速器。优势是生态和开发效率，限制要查具体模型、量化、硬件与版本兼容矩阵。
TensorRT-LLM 针对 NVIDIA GPU 做图、kernel、量化与 in-flight batching 优化，适合愿意承担模型转换、引擎构建、版本验证和硬件绑定成本的团队。当前工作流可从 Hugging Face checkpoint 转 TensorRT-LLM 模型或 checkpoint，也有高层 API；并非必须先转 ONNX。SGLang 侧重高性能服务和前缀复用等能力。TGI 提供流式输出、连续批处理、张量并行和监控，但官方文档已标为 maintenance mode，新项目需考虑维护风险。
llama.cpp 不只是 Llama 或 CPU 小模型。官方项目列出 CUDA、HIP、Metal、Vulkan、SYCL、CANN、OpenCL、RPC 等后端，支持 CPU+GPU 混合、量化和服务端。是否适合多 GPU 或分布式要按 backend、模型和拓扑压测，不能笼统说 GPU 与分布式支持弱。内存也必须绑定参数量、GGUF 量化格式、context、KV cache、batch 和运行后端；“Q4 小于 2GB”没有模型规模就无意义。最终用相同模型、请求分布和 SLO 测 TTFT、TPOT、吞吐、P95/P99、峰值显存、稳定性与运维成本。
图解
继续追问 · 3 个问题
- 你们实际项目中选型时最看重哪个维度，为什么
- vLLM的PagedAttention和FlashAttention有什么区别和联系
- 如果要在国产GPU上部署，这些框架的适配情况如何
换一种问法，检查是否真正理解
场景切入
假设我们现在要上线一个电商客服机器人，后端得选一个推理框架来支撑高并发。你手头有vLLM、TensorRT-LLM这些选项，你会怎么挑？简单说说理由。
层层追问
现在部署大模型做服务，推理框架你接触过哪些？……那如果线上并发很高，比如每秒几百个请求，怎么保证吞吐？……这些框架各自有什么优化手段？比如内存管理、批处理这些。
直球架构
从性能、易用性、扩展性三个维度，对比几个主流的大模型推理框架，比如vLLM、TensorRT-LLM、llama.cpp。你直接说它们的核心特点和适用场景就行。
练习口述回答 · 30秒速答 + 90秒主答 + 完整展开
- 先定义并发、延迟、硬件和运维约束
- 比较 vLLM 与 TensorRT-LLM 的服务定位
- 说明 SGLang 与 TGI 的状态
- 还原 llama.cpp 的模型和后端支持
- 以统一压测和版本矩阵做最终选择
【30秒速答】 推理框架没有固定冠军。云端高并发常从 vLLM 或 SGLang 建基线，NVIDIA 上追求特定模型极致优化可评估 TensorRT-LLM，端侧、CPU、Apple Silicon 和多种异构后端可看 llama.cpp。TGI 有流式、连续批处理、张量并行和监控，但官方已标为 maintenance mode。TensorRT-LLM 当前可直接从 Hugging Face 权重转换或用高层 API，并非必须先转 ONNX。llama.cpp 支持 CUDA、HIP、Metal、Vulkan、SYCL、CANN 和 RPC 等，不能说主要只支持 Llama。
【90秒主答】 选型先固定模型、精度、输入输出长度、并发、硬件、SLO 和团队维护能力。vLLM 的优势是服务接口、连续批处理、KV cache 管理和社区模型集成，当前支持范围已不局限 NVIDIA，但具体量化和功能仍要查硬件矩阵。SGLang 强调结构化生成、高性能 runtime 和前缀缓存复用，适合多轮或共享前缀负载，仍需用自身请求分布比较。TensorRT-LLM 深度结合 NVIDIA 软件和硬件，可做 kernel、量化、并行和 in-flight batching 优化；它的工程成本在权重转换、引擎或运行配置、版本兼容和回归，价值取决于延迟或吞吐增益是否覆盖维护成本。TGI 仍有生产功能，但维护模式意味着未来主要接受小修，新项目需要评估迁移计划。
【完整展开】 llama.cpp 的定位是低依赖、广硬件和 GGUF 生态，不等于“CPU 玩具”。官方列出 x86、ARM、Metal、CUDA、HIP、Vulkan、SYCL、CANN、OpenCL 与 RPC 等后端，并支持 CPU 和 GPU 混合 offload、量化以及 OpenAI 兼容 server。它也支持很多非 Llama 架构。某个后端是否有张量切分、并发和特定算子优化要看当前版本，不能从早期印象给整体结论。Q4 只描述每权重量化的大致位宽，实际内存还包含元数据、部分高精度张量、KV cache、运行缓冲和 context；没有参数量时，“小于 2GB”无法成立。
统一压测要固定 tokenizer、模型权重、量化、最大上下文、请求到达分布和输出长度。分别记录冷启动、TTFT、TPOT、请求吞吐、token 吞吐、P50/P95/P99、峰值显存、OOM、错误率和长时间稳定性。服务功能还看多租户、LoRA、结构化输出、观测、滚动升级和安全隔离。框架迭代很快，答案应注明文档日期或版本。最终可能采用多框架：通用服务用一个稳定基线，端侧和特定硬件另有实现；但每增加一种框架都会增加测试与运维成本，必须由真实 SLO 和总拥有成本证明。
【验证补充】内存估算可以先按参数量和名义位宽得到权重下界，再实测运行时峰值；KV cache 则随层数、隐藏维度、并发和上下文增长。压测报告同时保存驱动、框架 commit、编译选项和容器镜像，否则同名框架的结果无法复现，也不适合直接作为长期选型依据。