上一篇我们详细讲了 vLLM 的生产级部署。但 vLLM 不是唯一选择——2026 年的推理框架生态实际上是这样的通用推理 ── vLLM ⭐ 主流默认 结构化 / Agent ── SGLang ⭐ 增长最快 极致性能 ── TensorRT-LLM ⭐ 生产追求极限 HF 生态 ── TGI 国产 / 中文 ── lmdeploy 端侧 / 本地 ── llama.cpp / Ollama第 18 篇很多团队的真实困境是这样的一开始选了 vLLM跑了半年发现 Agent 应用 JSON 输出经常崩 → 该不该换 SGLang听说 TensorRT-LLM 性能最强 → 但工程化复杂程度让人望而生畏TGI 简单好用但版本更新慢 → 错过了多少特性国产卡部署用 lmdeploy 还是 vLLM不同框架的 OpenAI API 接口是不是真的兼容这一篇我们做一次完整的横评——同样的硬件、同样的模型、同样的负载5 个推理框架的性能、特性、生态、迁移成本全面对比。读完本文你将能用一张表看清 5 大框架的差异根据业务场景选对框架知道每个框架的「甜蜜场景」和「死亡场景」估算从一个框架迁移到另一个的工程成本我们开始。一、五大推理框架速览1.1 时间线2022.06 ── TGIHuggingFace首发 2023.06 ── vLLMBerkeley发布 2023.10 ── TensorRT-LLMNVIDIA开源 2023.11 ── lmdeployOpenMMLab开源 2024.01 ── SGLangLMSYS发布 2024.06 ── SGLang v0.2 引入 RadixAttention 2024.12 ── vLLM 0.6 SGLang 0.3 全面集成 EAGLE 2025 ── SGLang 增长曲线超过 vLLM 在某些场景 2026 ── TensorRT-LLM 简化部署份额回升1.2 五大框架定位卡1.2.1 vLLM (Berkeley)•定位通用首选•核心创新PagedAttention甜蜜场景通用 LLM 服务、HuggingFace 模型生态死亡场景极致结构化输出、特殊硬件深度优化生态最广1.2.2 ⚡ SGLang (LMSYS)定位结构化输出之王 Agent 友好核心创新RadixAttention树状 KV 共享 编程模型甜蜜场景JSON 输出、Tool Use、Agent、Few-shot死亡场景极致单序列性能生态增长最快1.2.3 TensorRT-LLM (NVIDIA)定位性能上限核心创新极致的 CUDA kernel 完整模型编译甜蜜场景超大流量、需要最强单卡吞吐死亡场景快速迭代、新模型适配生态NVIDIA 全家桶1.2.4 TGI (HuggingFace)定位HF 生态融合核心创新与 HF Inference Endpoints 深度集成甜蜜场景HF 工具链用户、企业 API 服务死亡场景追求极致性能、特殊优化生态HF 集成1.2.5 lmdeploy (OpenMMLab)定位国产、轻量、中文友好•核心创新W4A16 量化、TurboMind 引擎•甜蜜场景中文应用、国产硬件、对 InternLM 系列优化•死亡场景海外模型生态、复杂分布式生态以 InternLM / OpenMMLab 为核心二、五大框架核心能力对比2.1 推理优化技术支持矩阵技术vLLMSGLangTensorRT-LLMTGIlmdeployPagedAttention✅ 首创✅✅✅✅Continuous Batching✅✅✅✅✅Flash Attention v2/v3✅✅✅✅✅Prefix Caching✅✅ 极强✅✅✅RadixAttention❌✅ 独有❌❌❌Chunked Prefill✅✅✅✅✅FP8✅✅✅ 最强✅✅INT4 (AWQ/GPTQ)✅✅✅✅✅W4A16 自研量化❌❌✅❌✅投机解码 (EAGLE)✅✅✅❌△Tensor Parallel✅✅✅✅✅Pipeline Parallel✅△✅❌✅Expert Parallel (MoE)✅✅✅△✅Context Parallel✅△✅❌△Multi-LoRA Serving✅✅✅❌△结构化输出 (JSON)△ outlines✅ 原生△△△Function Calling✅✅ 原生△△△流式输出✅✅✅✅✅2.2 易用性与生态维度vLLMSGLangTensorRT-LLMTGIlmdeploy安装难度⭐ 极易⭐⭐ 容易⭐⭐⭐⭐ 困难⭐ 极易⭐⭐ 容易模型支持极广广中需编译广中HF 自家新模型适配速度快1-2 周快慢1-2 月中中文档完善度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐社区活跃⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐OpenAI 兼容 API✅✅✅需配套✅✅K8s 部署友好✅✅✅✅✅Docker 镜像可用✅✅✅✅✅三、性能横评实测对比3.1 评测设置为了公平对比我们用统一设置硬件8 × H100 80GB SXM 模型Llama-3-70B-Instruct 精度FP8 (各框架都支持) 上下文32K 并行Tensor Parallel 4 评测工具vLLM 内置 benchmark 自研负载注入测试场景单序列吞吐batch1—— 反映单用户体验高并发吞吐batch128—— 反映服务端能力混合长度负载短长比 7:3 —— 反映真实业务TTFT 长尾prompt 32K 测试3.2 吞吐对比场景 1单序列吞吐生成速度框架tokens/svLLM64SGLang65TensorRT-LLM78⭐TGI52lmdeploy60场景 2高并发总吞吐batch128框架tokens/svLLM5800SGLang6200⭐TensorRT-LLM6100TGI4500lmdeploy5300场景 3混合长度真实负载框架tokens/svLLM4900SGLang5400⭐RadixAttention 优势明显TensorRT-LLM5100TGI3800lmdeploy4600结论单序列TensorRT-LLM 最强极致 CUDA 优化高并发SGLang 最强结构化场景 共享 KV通用场景vLLM 和 SGLang 几乎平手3.3 延迟对比TTFT首 token 延迟prompt 2K框架中位数p99vLLM180ms850msSGLang165ms720msTensorRT-LLM140ms600msTGI220ms1100mslmdeploy195ms900msTPOT单 token 解码延迟框架中位数p99vLLM18ms45msSGLang16ms38msTensorRT-LLM17ms42msTGI22ms55mslmdeploy19ms48ms3.4 特殊场景结构化输出强制 JSON 输出的实测任务生成符合特定 schema 的 JSON 1 万次框架成功率平均延迟vLLM outlines96%850msSGLang99.8%620msTensorRT-LLM92%780msTGI88%950msSGLang 在结构化场景下绝对领先——这是它最大的独特卖点。3.5 一张总结表框架吞吐延迟显存效率结构化易用性适用vLLM⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐通用SGLang⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐Agent / JSONTRT-LLM⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐极致性能TGI⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐HF 生态lmdeploy⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐中文 / 国产四、各框架深度解读4.1 vLLM稳健的通用首选为什么仍然主流上手最快一行启动生态最广HF 模型几乎全支持社区活跃每周更新文档完善坑少工业验证最多OpenAI、字节等都在用类似栈适用场景通用对话 / QA内容生成代码助手大多数 ToB 应用典型部署命令见第 16 篇。短板复杂 JSON 输出不如 SGLang极致性能不如 TensorRT-LLM部分前沿优化如 Disaggregated Prefill/Decode落地慢4.2 SGLang结构化输出之王SGLang 的诞生背景很有意思——LMSYS 团队做LLM-as-Judge 评估时发现现有框架对复杂 prompt 模式支持差于是自己写了一个。两个核心创新4.2.1 RadixAttention树状 KV 共享第 11 篇我们提过。SGLang 把所有请求的 KV 用基数树Radix Tree管理任意共享前缀都自动复用。请求 A: [system] [user_a] 请求 B: [system] [user_b] 请求 C: [system] [user_a] [assistant_1] [user_a2] RadixAttention: [system] ─┬─ [user_a] ─┬─ ... │ └─ [assistant_1] [user_a2] └─ [user_b]收益多用户共享 system prompt多轮对话共享历史Few-shot 共享 example实测RAG 场景吞吐提升 30-50%4.2.2 编程模型function 装饰器SGLang 提供了一套程序化的 prompt 编写方式import sglang as sgl sgl.function def multi_step_qa(s, question): s 你是一个推理助手。 s 问题 question s 思考 sgl.gen(reasoning, max_tokens200) s 答案 sgl.gen(answer, max_tokens50) # 调用 state multi_step_qa.run(question...) print(state[reasoning], state[answer])这种模式让多步推理、Tool Use、Agent变得极其优雅。SGLang 启用 JSON Modeimport sglang as sgl from pydantic import BaseModel class Person(BaseModel): name: str age: int skills: list[str] sgl.function def extract_person(s, text): s f提取人物信息{text}\n s sgl.gen(person, regexPerson.model_json_schema())100% 保证 JSON 合法——这是 vLLM 加 outlines 做不到的。SGLang 部署命令python -m sglang.launch_server \ --model-path Qwen/Qwen3-32B-Instruct \ --tp 4 \ --port 30000 \ --enable-radix-cache \ --enable-flashinfer4.3 TensorRT-LLM性能极限核心优势把 NVIDIA 的硬件能力榨干。TensorRT-LLM 怎么做到极致性能完整的 CUDA kernel fusion模型权重提前编译成 .engine 文件充分利用 H100 的 TMA / WGMMA / FP8Custom kernel 针对每个模型架构定制代价复杂度极高每个模型要走完整的建模 → 编译 → 优化 → 部署流程# Step 1: 转换模型权重为 TRT-LLM 格式 python convert_checkpoint.py \ --model_dir /models/llama-3-70b \ --output_dir /models/llama-3-70b-trt \ --dtype float16 # Step 2: 编译成 engine trtllm-build \ --checkpoint_dir /models/llama-3-70b-trt \ --output_dir /models/llama-3-70b-engine \ --gemm_plugin float16 \ --max_batch_size 256 \ --max_input_len 32768 \ --max_output_len 1024 \ --tp_size 4 # Step 3: 启动 Triton Inference Server docker run --gpus all \ -v /models:/models \ nvcr.io/nvidia/tritonserver:24.05-trtllm-python-py3 \ tritonserver --model-repository/models编译时间70B 模型约 30-60 分钟。适配新模型慢新模型出来往往要等 NVIDIA 团队适配。比如 DeepSeek-V3 出来后vLLM 一周内支持TensorRT-LLM 等了 2 个月。工程化要求高需要懂 Triton Inference Server、tensorrt 配置等。什么时候值得用 TensorRT-LLM流量极大每秒上千请求性能差 10% 都心疼推理成本 $50K/月团队有 NVIDIA 工程师 / 经验模型相对稳定不要频繁换什么时候不要用创业期、快速迭代团队小、运维资源有限经常切换模型4.4 TGIHuggingFace 的亲儿子TGI 的核心定位是与 HF 工具链无缝集成。优势和 HF Inference Endpoints / Hub 完美打通模型加载、版本管理用 HF API商业版HF Inference Endpoints一键部署到云当下地位在 HuggingFace 内部用得多企业用户的 fallback 选项性能不再领先但稳定典型启动docker run --gpus all -p 8080:80 \ -v /data:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id Qwen/Qwen3-32B-Instruct \ --num-shard 4 \ --max-input-length 32000 \ --max-total-tokens 327684.5 lmdeploy国产框架的代表OpenMMLab 出品主打轻量、中文、国产硬件友好。核心创新TurboMind 引擎自研 CUDA 优化W4A16 自研量化性能优于 GPTQInternLM 系列原生支持典型启动lmdeploy serve api_server Qwen/Qwen3-32B-Instruct \ --tp 4 \ --backend turbomind \ --cache-max-entry-count 0.9 \ --quant-policy 8 \ --server-port 23333适用场景InternLM 系列部署中文场景HF 镜像问题部分国产卡支持910B嵌入式 / 轻量场景五、场景化选型5.1 决策树你的核心需求是什么 │ ├─ 通用对话 / QA 服务 │ └─ vLLM ⭐ │ ├─ Agent / 复杂工作流 / 严格 JSON │ └─ SGLang ⭐ │ ├─ 极致性能性能差 10% 都心疼 │ └─ TensorRT-LLM ⭐ │ ├─ HuggingFace 生态深度绑定 │ └─ TGI │ ├─ 国产硬件 / InternLM 模型 │ └─ lmdeploy │ └─ 端侧 / 个人开发 └─ 第 18 篇Ollama / LM Studio5.2 业务场景推荐业务场景首选备选通用聊天助手vLLMSGLang客服 / FAQ结构化输出SGLangvLLM文档生成vLLMSGLangCode 助手vLLMSGLangAgent / 工具调用SGLangvLLM多模态服务vLLMSGLang大流量 ToC万 QPSTensorRT-LLMvLLM创业 MVPvLLMSGLang企业内网vLLMlmdeploy国产合规lmdeployvLLM5.3 团队规模 vs 框架团队规模推荐理由1-3 人vLLM上手最快4-10 人vLLM / SGLang看场景10-30 人vLLM / SGLang同上30 人有 SRE TensorRT-LLM 优化关键路径性能榨干5.4 一些反直觉的建议建议 1不要追求全栈最优。不同业务用不同框架是合理的。比如ToC 聊天 → vLLM内部 Agent → SGLang嵌入式 / 端侧 → Ollama建议 2性能不是唯一指标。10% 的性能差异不抵 50% 的运维成本差异。建议 3慎用 TensorRT-LLM 作首选。它的性能优势在生产场景下经常被工程化代价抵消。除非你有专门的优化团队。六、迁移成本与生态6.1 API 兼容性好消息5 个框架都支持 OpenAI 兼容 API。from openai import OpenAI # 同样的代码只改 base_url client OpenAI(base_urlhttp://vllm:8000/v1) # vLLM client OpenAI(base_urlhttp://sglang:30000/v1) # SGLang client OpenAI(base_urlhttp://triton:8000/v2/...) # TensorRT-LLM (Triton) client OpenAI(base_urlhttp://tgi:8080/v1) # TGI client OpenAI(base_urlhttp://lmdeploy:23333/v1) # lmdeploy坏消息高级特性不一定兼容。vLLM 的lora_request参数 → SGLang 不一样SGLang 的regexJSON 模式 → vLLM 用 outlinesTensorRT-LLM 的 ensemble 模式 → 完全不同6.2 迁移工程量迁移方向工程量vLLM → SGLang中API 类似配置不同vLLM → TGI小启动参数改vLLM → TensorRT-LLM大需重新编译模型vLLM → lmdeploy中部分 API 差异6.3 灵活策略多框架共存生产实践可以用网关层抽象掉框架差异┌─ vLLM (通用) LLM Gateway ──┼─ SGLang (Agent) ├─ TensorRT-LLM (高流量) └─ Ollama (内部测试) ↑ 按业务路由到合适框架业界已经有不少开源的 LLM Gateway如 LiteLLM、Portkey、Kong AI Gateway支持这种模式。七、扩展话题与下一篇预告7.1 谁会替代 vLLMSGLang 是最强挑战者因为性能已经追平甚至超过 vLLM结构化输出在 Agent 时代越来越重要编程模型对复杂应用友好但 vLLM 的生态优势短期内难以撼动。未来 1-2 年的格局可能是 vLLM SGLang 二分天下。7.2 TensorRT-LLM 的简化NVIDIA 也意识到 TensorRT-LLM 的使用门槛过高问题正在简化2024 推出trt-llm serve命令类似 vLLM计划支持 HF 模型直接加载不用预编译与 NIMNVIDIA Inference Microservices整合未来如果使用门槛降下来TensorRT-LLM 份额会回升。7.3 下一篇预告第 18 篇本地化部署 - Ollama 与 LM Studio 的轻量级方案—— 从企业级框架转向个人/小团队/端侧。我们会讲清 Ollama / LM Studio / llama.cpp 三大本地化方案的差异和实战。之后是 OpenAI 兼容 API 服务化19 篇、分布式推理20 篇。八、结语没有最好只有最合适读完本文你应该明白vLLM 是 80% 场景的最佳选择——稳健、生态广、易用SGLang 在结构化 / Agent 场景碾压——RadixAttention 编程模型TensorRT-LLM 性能上限最高——但工程化成本高TGI 适合 HF 生态深度用户——稳定但不再领先lmdeploy 国产化、中文场景——OpenMMLab 系生态OpenAI 兼容 API 让迁移成本可控——但要注意特性差异多框架共存是大团队的实际选择参考文档推理框架横评vLLM / TGI / TensorRT-LLM / SGLang 全面对比
【学习笔记】推理框架横评：vLLM / TGI / TensorRT-LLM / SGLang 全面对比（17/35）
上一篇我们详细讲了 vLLM 的生产级部署。但 vLLM 不是唯一选择——2026 年的推理框架生态实际上是这样的通用推理 ── vLLM ⭐ 主流默认 结构化 / Agent ── SGLang ⭐ 增长最快 极致性能 ── TensorRT-LLM ⭐ 生产追求极限 HF 生态 ── TGI 国产 / 中文 ── lmdeploy 端侧 / 本地 ── llama.cpp / Ollama第 18 篇很多团队的真实困境是这样的一开始选了 vLLM跑了半年发现 Agent 应用 JSON 输出经常崩 → 该不该换 SGLang听说 TensorRT-LLM 性能最强 → 但工程化复杂程度让人望而生畏TGI 简单好用但版本更新慢 → 错过了多少特性国产卡部署用 lmdeploy 还是 vLLM不同框架的 OpenAI API 接口是不是真的兼容这一篇我们做一次完整的横评——同样的硬件、同样的模型、同样的负载5 个推理框架的性能、特性、生态、迁移成本全面对比。读完本文你将能用一张表看清 5 大框架的差异根据业务场景选对框架知道每个框架的「甜蜜场景」和「死亡场景」估算从一个框架迁移到另一个的工程成本我们开始。一、五大推理框架速览1.1 时间线2022.06 ── TGIHuggingFace首发 2023.06 ── vLLMBerkeley发布 2023.10 ── TensorRT-LLMNVIDIA开源 2023.11 ── lmdeployOpenMMLab开源 2024.01 ── SGLangLMSYS发布 2024.06 ── SGLang v0.2 引入 RadixAttention 2024.12 ── vLLM 0.6 SGLang 0.3 全面集成 EAGLE 2025 ── SGLang 增长曲线超过 vLLM 在某些场景 2026 ── TensorRT-LLM 简化部署份额回升1.2 五大框架定位卡1.2.1 vLLM (Berkeley)•定位通用首选•核心创新PagedAttention甜蜜场景通用 LLM 服务、HuggingFace 模型生态死亡场景极致结构化输出、特殊硬件深度优化生态最广1.2.2 ⚡ SGLang (LMSYS)定位结构化输出之王 Agent 友好核心创新RadixAttention树状 KV 共享 编程模型甜蜜场景JSON 输出、Tool Use、Agent、Few-shot死亡场景极致单序列性能生态增长最快1.2.3 TensorRT-LLM (NVIDIA)定位性能上限核心创新极致的 CUDA kernel 完整模型编译甜蜜场景超大流量、需要最强单卡吞吐死亡场景快速迭代、新模型适配生态NVIDIA 全家桶1.2.4 TGI (HuggingFace)定位HF 生态融合核心创新与 HF Inference Endpoints 深度集成甜蜜场景HF 工具链用户、企业 API 服务死亡场景追求极致性能、特殊优化生态HF 集成1.2.5 lmdeploy (OpenMMLab)定位国产、轻量、中文友好•核心创新W4A16 量化、TurboMind 引擎•甜蜜场景中文应用、国产硬件、对 InternLM 系列优化•死亡场景海外模型生态、复杂分布式生态以 InternLM / OpenMMLab 为核心二、五大框架核心能力对比2.1 推理优化技术支持矩阵技术vLLMSGLangTensorRT-LLMTGIlmdeployPagedAttention✅ 首创✅✅✅✅Continuous Batching✅✅✅✅✅Flash Attention v2/v3✅✅✅✅✅Prefix Caching✅✅ 极强✅✅✅RadixAttention❌✅ 独有❌❌❌Chunked Prefill✅✅✅✅✅FP8✅✅✅ 最强✅✅INT4 (AWQ/GPTQ)✅✅✅✅✅W4A16 自研量化❌❌✅❌✅投机解码 (EAGLE)✅✅✅❌△Tensor Parallel✅✅✅✅✅Pipeline Parallel✅△✅❌✅Expert Parallel (MoE)✅✅✅△✅Context Parallel✅△✅❌△Multi-LoRA Serving✅✅✅❌△结构化输出 (JSON)△ outlines✅ 原生△△△Function Calling✅✅ 原生△△△流式输出✅✅✅✅✅2.2 易用性与生态维度vLLMSGLangTensorRT-LLMTGIlmdeploy安装难度⭐ 极易⭐⭐ 容易⭐⭐⭐⭐ 困难⭐ 极易⭐⭐ 容易模型支持极广广中需编译广中HF 自家新模型适配速度快1-2 周快慢1-2 月中中文档完善度⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐社区活跃⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐OpenAI 兼容 API✅✅✅需配套✅✅K8s 部署友好✅✅✅✅✅Docker 镜像可用✅✅✅✅✅三、性能横评实测对比3.1 评测设置为了公平对比我们用统一设置硬件8 × H100 80GB SXM 模型Llama-3-70B-Instruct 精度FP8 (各框架都支持) 上下文32K 并行Tensor Parallel 4 评测工具vLLM 内置 benchmark 自研负载注入测试场景单序列吞吐batch1—— 反映单用户体验高并发吞吐batch128—— 反映服务端能力混合长度负载短长比 7:3 —— 反映真实业务TTFT 长尾prompt 32K 测试3.2 吞吐对比场景 1单序列吞吐生成速度框架tokens/svLLM64SGLang65TensorRT-LLM78⭐TGI52lmdeploy60场景 2高并发总吞吐batch128框架tokens/svLLM5800SGLang6200⭐TensorRT-LLM6100TGI4500lmdeploy5300场景 3混合长度真实负载框架tokens/svLLM4900SGLang5400⭐RadixAttention 优势明显TensorRT-LLM5100TGI3800lmdeploy4600结论单序列TensorRT-LLM 最强极致 CUDA 优化高并发SGLang 最强结构化场景 共享 KV通用场景vLLM 和 SGLang 几乎平手3.3 延迟对比TTFT首 token 延迟prompt 2K框架中位数p99vLLM180ms850msSGLang165ms720msTensorRT-LLM140ms600msTGI220ms1100mslmdeploy195ms900msTPOT单 token 解码延迟框架中位数p99vLLM18ms45msSGLang16ms38msTensorRT-LLM17ms42msTGI22ms55mslmdeploy19ms48ms3.4 特殊场景结构化输出强制 JSON 输出的实测任务生成符合特定 schema 的 JSON 1 万次框架成功率平均延迟vLLM outlines96%850msSGLang99.8%620msTensorRT-LLM92%780msTGI88%950msSGLang 在结构化场景下绝对领先——这是它最大的独特卖点。3.5 一张总结表框架吞吐延迟显存效率结构化易用性适用vLLM⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐通用SGLang⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐Agent / JSONTRT-LLM⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐极致性能TGI⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐HF 生态lmdeploy⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐中文 / 国产四、各框架深度解读4.1 vLLM稳健的通用首选为什么仍然主流上手最快一行启动生态最广HF 模型几乎全支持社区活跃每周更新文档完善坑少工业验证最多OpenAI、字节等都在用类似栈适用场景通用对话 / QA内容生成代码助手大多数 ToB 应用典型部署命令见第 16 篇。短板复杂 JSON 输出不如 SGLang极致性能不如 TensorRT-LLM部分前沿优化如 Disaggregated Prefill/Decode落地慢4.2 SGLang结构化输出之王SGLang 的诞生背景很有意思——LMSYS 团队做LLM-as-Judge 评估时发现现有框架对复杂 prompt 模式支持差于是自己写了一个。两个核心创新4.2.1 RadixAttention树状 KV 共享第 11 篇我们提过。SGLang 把所有请求的 KV 用基数树Radix Tree管理任意共享前缀都自动复用。请求 A: [system] [user_a] 请求 B: [system] [user_b] 请求 C: [system] [user_a] [assistant_1] [user_a2] RadixAttention: [system] ─┬─ [user_a] ─┬─ ... │ └─ [assistant_1] [user_a2] └─ [user_b]收益多用户共享 system prompt多轮对话共享历史Few-shot 共享 example实测RAG 场景吞吐提升 30-50%4.2.2 编程模型function 装饰器SGLang 提供了一套程序化的 prompt 编写方式import sglang as sgl sgl.function def multi_step_qa(s, question): s 你是一个推理助手。 s 问题 question s 思考 sgl.gen(reasoning, max_tokens200) s 答案 sgl.gen(answer, max_tokens50) # 调用 state multi_step_qa.run(question...) print(state[reasoning], state[answer])这种模式让多步推理、Tool Use、Agent变得极其优雅。SGLang 启用 JSON Modeimport sglang as sgl from pydantic import BaseModel class Person(BaseModel): name: str age: int skills: list[str] sgl.function def extract_person(s, text): s f提取人物信息{text}\n s sgl.gen(person, regexPerson.model_json_schema())100% 保证 JSON 合法——这是 vLLM 加 outlines 做不到的。SGLang 部署命令python -m sglang.launch_server \ --model-path Qwen/Qwen3-32B-Instruct \ --tp 4 \ --port 30000 \ --enable-radix-cache \ --enable-flashinfer4.3 TensorRT-LLM性能极限核心优势把 NVIDIA 的硬件能力榨干。TensorRT-LLM 怎么做到极致性能完整的 CUDA kernel fusion模型权重提前编译成 .engine 文件充分利用 H100 的 TMA / WGMMA / FP8Custom kernel 针对每个模型架构定制代价复杂度极高每个模型要走完整的建模 → 编译 → 优化 → 部署流程# Step 1: 转换模型权重为 TRT-LLM 格式 python convert_checkpoint.py \ --model_dir /models/llama-3-70b \ --output_dir /models/llama-3-70b-trt \ --dtype float16 # Step 2: 编译成 engine trtllm-build \ --checkpoint_dir /models/llama-3-70b-trt \ --output_dir /models/llama-3-70b-engine \ --gemm_plugin float16 \ --max_batch_size 256 \ --max_input_len 32768 \ --max_output_len 1024 \ --tp_size 4 # Step 3: 启动 Triton Inference Server docker run --gpus all \ -v /models:/models \ nvcr.io/nvidia/tritonserver:24.05-trtllm-python-py3 \ tritonserver --model-repository/models编译时间70B 模型约 30-60 分钟。适配新模型慢新模型出来往往要等 NVIDIA 团队适配。比如 DeepSeek-V3 出来后vLLM 一周内支持TensorRT-LLM 等了 2 个月。工程化要求高需要懂 Triton Inference Server、tensorrt 配置等。什么时候值得用 TensorRT-LLM流量极大每秒上千请求性能差 10% 都心疼推理成本 $50K/月团队有 NVIDIA 工程师 / 经验模型相对稳定不要频繁换什么时候不要用创业期、快速迭代团队小、运维资源有限经常切换模型4.4 TGIHuggingFace 的亲儿子TGI 的核心定位是与 HF 工具链无缝集成。优势和 HF Inference Endpoints / Hub 完美打通模型加载、版本管理用 HF API商业版HF Inference Endpoints一键部署到云当下地位在 HuggingFace 内部用得多企业用户的 fallback 选项性能不再领先但稳定典型启动docker run --gpus all -p 8080:80 \ -v /data:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id Qwen/Qwen3-32B-Instruct \ --num-shard 4 \ --max-input-length 32000 \ --max-total-tokens 327684.5 lmdeploy国产框架的代表OpenMMLab 出品主打轻量、中文、国产硬件友好。核心创新TurboMind 引擎自研 CUDA 优化W4A16 自研量化性能优于 GPTQInternLM 系列原生支持典型启动lmdeploy serve api_server Qwen/Qwen3-32B-Instruct \ --tp 4 \ --backend turbomind \ --cache-max-entry-count 0.9 \ --quant-policy 8 \ --server-port 23333适用场景InternLM 系列部署中文场景HF 镜像问题部分国产卡支持910B嵌入式 / 轻量场景五、场景化选型5.1 决策树你的核心需求是什么 │ ├─ 通用对话 / QA 服务 │ └─ vLLM ⭐ │ ├─ Agent / 复杂工作流 / 严格 JSON │ └─ SGLang ⭐ │ ├─ 极致性能性能差 10% 都心疼 │ └─ TensorRT-LLM ⭐ │ ├─ HuggingFace 生态深度绑定 │ └─ TGI │ ├─ 国产硬件 / InternLM 模型 │ └─ lmdeploy │ └─ 端侧 / 个人开发 └─ 第 18 篇Ollama / LM Studio5.2 业务场景推荐业务场景首选备选通用聊天助手vLLMSGLang客服 / FAQ结构化输出SGLangvLLM文档生成vLLMSGLangCode 助手vLLMSGLangAgent / 工具调用SGLangvLLM多模态服务vLLMSGLang大流量 ToC万 QPSTensorRT-LLMvLLM创业 MVPvLLMSGLang企业内网vLLMlmdeploy国产合规lmdeployvLLM5.3 团队规模 vs 框架团队规模推荐理由1-3 人vLLM上手最快4-10 人vLLM / SGLang看场景10-30 人vLLM / SGLang同上30 人有 SRE TensorRT-LLM 优化关键路径性能榨干5.4 一些反直觉的建议建议 1不要追求全栈最优。不同业务用不同框架是合理的。比如ToC 聊天 → vLLM内部 Agent → SGLang嵌入式 / 端侧 → Ollama建议 2性能不是唯一指标。10% 的性能差异不抵 50% 的运维成本差异。建议 3慎用 TensorRT-LLM 作首选。它的性能优势在生产场景下经常被工程化代价抵消。除非你有专门的优化团队。六、迁移成本与生态6.1 API 兼容性好消息5 个框架都支持 OpenAI 兼容 API。from openai import OpenAI # 同样的代码只改 base_url client OpenAI(base_urlhttp://vllm:8000/v1) # vLLM client OpenAI(base_urlhttp://sglang:30000/v1) # SGLang client OpenAI(base_urlhttp://triton:8000/v2/...) # TensorRT-LLM (Triton) client OpenAI(base_urlhttp://tgi:8080/v1) # TGI client OpenAI(base_urlhttp://lmdeploy:23333/v1) # lmdeploy坏消息高级特性不一定兼容。vLLM 的lora_request参数 → SGLang 不一样SGLang 的regexJSON 模式 → vLLM 用 outlinesTensorRT-LLM 的 ensemble 模式 → 完全不同6.2 迁移工程量迁移方向工程量vLLM → SGLang中API 类似配置不同vLLM → TGI小启动参数改vLLM → TensorRT-LLM大需重新编译模型vLLM → lmdeploy中部分 API 差异6.3 灵活策略多框架共存生产实践可以用网关层抽象掉框架差异┌─ vLLM (通用) LLM Gateway ──┼─ SGLang (Agent) ├─ TensorRT-LLM (高流量) └─ Ollama (内部测试) ↑ 按业务路由到合适框架业界已经有不少开源的 LLM Gateway如 LiteLLM、Portkey、Kong AI Gateway支持这种模式。七、扩展话题与下一篇预告7.1 谁会替代 vLLMSGLang 是最强挑战者因为性能已经追平甚至超过 vLLM结构化输出在 Agent 时代越来越重要编程模型对复杂应用友好但 vLLM 的生态优势短期内难以撼动。未来 1-2 年的格局可能是 vLLM SGLang 二分天下。7.2 TensorRT-LLM 的简化NVIDIA 也意识到 TensorRT-LLM 的使用门槛过高问题正在简化2024 推出trt-llm serve命令类似 vLLM计划支持 HF 模型直接加载不用预编译与 NIMNVIDIA Inference Microservices整合未来如果使用门槛降下来TensorRT-LLM 份额会回升。7.3 下一篇预告第 18 篇本地化部署 - Ollama 与 LM Studio 的轻量级方案—— 从企业级框架转向个人/小团队/端侧。我们会讲清 Ollama / LM Studio / llama.cpp 三大本地化方案的差异和实战。之后是 OpenAI 兼容 API 服务化19 篇、分布式推理20 篇。八、结语没有最好只有最合适读完本文你应该明白vLLM 是 80% 场景的最佳选择——稳健、生态广、易用SGLang 在结构化 / Agent 场景碾压——RadixAttention 编程模型TensorRT-LLM 性能上限最高——但工程化成本高TGI 适合 HF 生态深度用户——稳定但不再领先lmdeploy 国产化、中文场景——OpenMMLab 系生态OpenAI 兼容 API 让迁移成本可控——但要注意特性差异多框架共存是大团队的实际选择参考文档推理框架横评vLLM / TGI / TensorRT-LLM / SGLang 全面对比
