推理框架硬件支持对比

完整题目

目前主流的大语言模型推理框架有哪些？请列举并比较它们在性能、易用性、支持硬件等方面的优缺点。

从服务形态、硬件矩阵和版本状态比较推理框架

服务端 GPU 高并发可从 vLLM 或 SGLang 建立基线。vLLM 当前官方安装文档覆盖 NVIDIA CUDA、AMD ROCm、Intel XPU、CPU，并列有 Apple Silicon 社区插件及其他硬件插件；具体模型、量化、并行和结构化输出仍要查 feature x hardware 矩阵。SGLang 强调高性能 runtime、调度与前缀缓存复用，但是否更快取决于共享前缀、并发和模型。

TensorRT-LLM 面向 NVIDIA 平台，提供权重转换、模型构建、高层 API、量化和服务能力。官方工作流可从 Hugging Face checkpoint 导入或转换为 TensorRT-LLM checkpoint，再构建或使用新服务 API，并不要求先经过 ONNX。llama.cpp 使用 GGUF 与多种量化，支持 CPU、Metal、CUDA、HIP、Vulkan、SYCL、CANN、RPC 等，适合本地、端侧和异构场景，也有 OpenAI 兼容 server。

TGI 具有 SSE 流式、连续批处理、张量并行、Prometheus 与 OpenTelemetry 等功能，但官方页面已注明 maintenance mode；不能额外宣称内置覆盖所有业务的通用安全过滤。StreamingLLM 是让注意力模型处理长流式输入的研究方法，保留 attention sinks 等 token 来维持性能，不是具备鉴权、队列、伸缩和监控的完整服务框架。选型用同一权重、精度、上下文、并发和硬件测 TTFT、TPOT、E2E、吞吐、显存、错误率与运维复杂度，并注明版本日期。

继续追问 · 3 个问题

你们实际项目中选型时最看重哪个指标，为什么
如果要在CPU上部署7B模型，你会怎么选
vLLM的PagedAttention相比传统KV Cache有什么本质改进

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

场景切入

假设你们要给电商客服搭一个实时问答服务，用户问完一个问题，系统要秒级响应。你打算用哪个推理框架？vLLM 还是 TensorRT-LLM？怎么选？

层层追问

现在主流的大模型推理框架你了解哪些？……比如 vLLM、TensorRT-LLM 这些，它们各自有什么特点？……如果我要部署在 CPU 上呢？

直球架构

请列举目前主流的大语言模型推理框架，并比较它们在性能、易用性、硬件支持方面的优缺点。

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

固定模型、硬件、并发和 SLO
比较 vLLM、SGLang 的通用服务能力
说明 TensorRT-LLM 的实际转换路线
区分 TGI、llama.cpp 与 StreamingLLM
以统一压测和版本锁定决策

【30秒速答】服务端高并发可先压测 vLLM 和 SGLang，NVIDIA 上追求特定模型优化可评估 TensorRT-LLM，本地、CPU、Apple Silicon 或异构设备可看 llama.cpp。TensorRT-LLM 当前支持从 Hugging Face 权重转换和高层 API，不是必须先转 ONNX。TGI 有流式、连续批处理、张量并行和监控，但官方已进入 maintenance mode，也没有覆盖所有业务的通用安全过滤。StreamingLLM 是长流式上下文的注意力方法，不是完整部署框架。

【90秒主答】比较前先锁定模型 checkpoint、精度、输入输出长度、并发、硬件和目标 SLO。vLLM 的价值在连续批处理、KV cache 管理、OpenAI 兼容服务和较广模型生态，当前官方文档列出 CUDA、ROCm、Intel XPU、CPU 等平台以及插件扩展，但量化和功能支持仍随硬件变化。SGLang 也面向高性能 serving，前缀缓存和调度对多轮、共享 system prompt 的负载可能有优势，需要用真实流量证明。TensorRT-LLM 针对 NVIDIA 做模型、kernel、量化和 in-flight batching 优化，流程可导入 Hugging Face checkpoint、转换权重并构建引擎，也在推进更高层服务接口。工程门槛来自版本、模型兼容、构建和回归，不是一个固定 ONNX 必经步骤。llama.cpp 则强调低依赖、GGUF 量化与广后端，可运行很多模型，并提供 server。

【完整展开】 TGI 的实际功能包括 token streaming、连续批处理、张量并行、分布式追踪和 Prometheus 指标。官方文档已写明维护模式，意味着新项目要考虑未来功能演进和迁移，而不是简单说“社区热度低”。安全过滤是业务策略，需要输入输出审核、权限、模型和规则组合，不能因为选了 TGI 就假设自动具备。StreamingLLM 论文解决的是超出训练上下文的流式注意力稳定问题，通过保留 attention sink 等设计避免直接滑窗失效；它没有自动提供 API 网关、队列、弹性伸缩、租户隔离和监控，因此应作为算法或缓存策略讨论。

压测同时测 TTFT、TPOT、端到端延迟、请求与 token 吞吐、P95/P99、峰值显存、OOM、错误率和长时间稳定性。输入长度、输出长度和到达分布都要固定，量化后还要做任务质量回归。易用性看模型接入、容器、观测、滚动发布和故障恢复；扩展性看多卡、多节点、LoRA、多模态和硬件矩阵。框架更新很快，结果附 commit 或版本。最终选择可能因负载拆分，但每多一套 runtime 都增加发布与排障成本，只有稳定的性能或硬件收益才能支撑。

【验证补充】还要区分核心仓库支持和社区插件支持。模型能加载不代表量化、并行、多模态与结构化输出全部可用，选型表应逐项链接当前兼容矩阵，并为升级准备回退镜像和质量基线。