主流 LLM 推理/部署框架指标对比

主流 LLM 推理/部署框架 关键指标上做了对比:吞吐量(Tokens/s)首 token 响应时间(TTFT,s)单 token 生成时间(TPOT,ms)并发能力推理时 TOKEN 生成效率 。注意:这些指标强烈依赖于:模型大小(13B/70B/Chat-style/decoder-only)、硬件(H100/GH200/Blackwell/H20/CPU)、量化与 KV-cache 支持、并发请求分发策略等

快速结论

  • 最高单卡吞吐 / 最低 TPOT(按 GPU 优化) :NVIDIA 的 TensorRT-LLM / FasterTransformer /TensorRT 引擎 与使用专有 Blackwell/H100 优化的堆栈通常拿到最优吞吐(常见在厂商基准中为最高 TPS)
  • 最佳交互(低 TTFT、优并发调度)vLLM 在很多公开基准/论文中对低延时交互、并发请求合批 (scheduling) 表现突出,尤其在 GH200/H100 上表现很好。
  • CPU / 边缘场景llama.cpp / ggml 类实现可在消费级 CPU 上运行,但吞吐远低于 GPU(常见 1--100 tokens/s 级别,依硬件差异大)。
  • 横向扩展 / 多卡 / 大模型DeepSpeed-Inference / Triton + TensorRT engines / FasterTransformer 更适合多卡分片和大模型(ZeRO/分片推理),在多 GPU 上能有效提高总 TPS,但实现更复杂。

对比表(按"典型行为 + 参考数值区间/排序")

说明:表中数字为公开基准或厂商/社区报告中常见的参考量级;实际请以你目标模型、batch、硬件、量化方式为准。

框架 / 指标 吞吐量(Tokens/s)典型(单卡) 首 token 响应(TTFT)典型 单 token 生成时间(TPOT)典型 并发能力(多用户) TOKEN 生成效率 / 优势点
TensorRT-LLM / FasterTransformer (NVIDIA) 非常高(在 H100/GH200/Blackwell 上:数百 --- 数千 TPS(取决模型/FP8/FP16)) (首 token 常在 ~几十 ms --- 几百 ms,取决 pipeline/quant) (几 ms/ token 到 <1 ms/token 级别在极端优化下) 大规模并发强,需 GPU 专有 stack 针对 NVIDIA 做深度 kernel/FP8/推理 fusion,适合最高吞吐与最低成本/令牌。
vLLM 高(在 GH200/H100 上公开基准显示领先同类软件在很多场景) 非常低(针对交互场景做 TTFT 优化与请求合并) 低 --- 中(优化 KV-cache/合批) 并发处理优秀,软件层能做智能调度/合批 以请求级合并 (scheduling) + 高效 KV-cache 为优势,适合低延时交互场景。
Triton Inference Server (+TensorRT engines) 高(与 TensorRT 引擎一起使用时吞吐接近 TensorRT-LLM) 中 --- 低(依 perf_analyzer/GenAI-Perf 调优) 低 --- 中 企业级路由、多模型并发、弹性扩容能力强 标准化 server,易于集成到生产流量链路和 autoscale;支持多后端。
DeepSpeed-Inference 高(多 GPU/ZeRO 分片时扩展好) 中(多卡通信与分片会影响首 token) 低 --- 中(优化多卡并行) 出色(为大模型多 GPU 设计) 优势在大模型分片/内存调度,适合 70B+ 级别分布式推理。
BentoML / LMDeploy / Ray Serve / KServe 取决后端(可接 TensorRT、vLLM、DeepSpeed 等) 取决后端 取决后端 侧重编排/部署/多实例/弹性,易做 A/B 是"服务编排层",性能取决所绑后端推理引擎
llama.cpp / ggml(CPU / 手机) 低(典型几 tokens/s 到几十/tens tokens/s,取决 CPU) 高(首 token 较慢,秒级或更长) 高(每 token 多十几到数百 ms) 并发差(受 CPU 限制) 极低资源消耗,可在没有 GPU 的设备运行,适合离线或边缘部署。

对比要点与解读

  1. 吞吐 vs TTFT 的权衡:实现最大吞吐(批处理、大 batch)通常会牺牲首 token 延迟(TTFT)。vLLM 通过智能合批/调度在保证吞吐的同时保持较低 TTFT;而 TensorRT-LLM 在 GPU kernel 层得到极致吞吐,但端到端首 token 仍受 I/O/模型加载/量化策略影响。
  2. TPOT(单 token)常由底层 kernel 决定:如果你在 GPU 上使用高度优化的矩阵乘法 / attention kernel(如 FasterTransformer/TensorRT),单 token 时间最短;在 CPU 或未优化框架上则慢很多。
  3. 并发能力依赖服务层:框架本身(vLLM/TensorRT)负责推理效率,但并发请求路由、限流、排队、合批策略由上层(Triton、BentoML、Ray Serve、Kubernetes)共同决定。生产环境一般把高效推理引擎(TensorRT/vLLM/DeepSpeed)放在后端,用 Triton/BentoML 做流量/实例管理。
  4. 硬件对比决定量级:GH200/Blackwell/H100 相比通用 GPU 能把吞吐提升数倍(同时配合 FP8/专用 kernel),因此同一框架在不同 GPU 上差别巨大。最近公开报道(例如 DGX B200)显示 Nvidia 在整合硬件+TensorRT 得到极高 TPS。
相关推荐
laplace012319 小时前
claude code架构猜测总结
架构·大模型·llm·agent·rag
lkbhua莱克瓦2419 小时前
RAG到RGA:生成式AI的范式演进
人工智能·llm·prompt·大语言模型·rag·rga
tswddd21 小时前
Debug:mlx-omni-server服务器用qwen3模型出错
llm·debug
致Great1 天前
TextIn × Agentic RAG:让大模型真正读懂学术论文
llm·agent
Stirner1 天前
A2UI : 以动态 UI 代替 LLM 文本输出的方案
前端·llm·agent
kagg8861 天前
mcp-gateway —— 隐藏mcp上下文以避免不必要的tokens开销
llm·mcp
夏日白云1 天前
《PDF解析工程实录》第 17 章|内容流里“看得见却看不见”的字符:那些幽灵文字从哪来?
pdf·llm·大语言模型·rag·文档解析
人工干智能2 天前
OpenAI Assistants API 中 client.beta.threads.messages.create方法,兼谈一星*和两星**解包
python·llm
Hcoco_me2 天前
大模型面试题61:Flash Attention中online softmax(在线softmax)的实现方式
人工智能·深度学习·自然语言处理·transformer·vllm