主流 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。
相关推荐
桃西西呀1 小时前
你的 Agent 每判一次都要为大模型吐的字买单?-Laya模型帮你做判断
人工智能·llm·ai编程
AINative软件工程2 小时前
LLM 输出 Guardrail 工程实践:5 层防护栏让 AI 生成的内容不会炸掉生产
后端·llm·ai编程
武子康8 小时前
Agent 能接进 IDE,为什么还不能随意互换?
人工智能·llm·agent
武子康8 小时前
ESP32-S3 Mini 和 C3 Mini 怎么买?从 PSRAM、USB 到一张可核对的采购单
人工智能·llm·agent
10年前端老司机8 小时前
RAG 检索效果量化测评落地:完整流程、指标实现与踩坑总结
人工智能·llm·aigc
武子康8 小时前
权重装进了 24 GiB,四路 32K 上下文还装得下吗?
人工智能·llm·agent
Python私教8 小时前
DeepSeek本地部署Ollama+知识库,附3个报错解决
人工智能·llm·deepseek
闪学it8 小时前
闪学it-Linux云计+AIOps大模型
llm
武子康8 小时前
Codex 只读审查的权限边界:任务文件是谁写的?
人工智能·llm·agent
柒和远方8 小时前
混合检索 RAG 全链路:查询增强、双路召回与重排——向量库和搜索引擎联手补齐召回
elasticsearch·langchain·llm