汤不热吧随着开源大模型（DeepSeek-V3、Llama 4、Qwen3等）参数量从70B跃升至千亿级别，如何在单机或多机上高效部署这些模型，成为2026年AI工程领域最核心的工程难题。本文将以实战视角深度对比当前主流的三大推理框架——vLLM、SGLang、TensorRT-LLM，从架构原理、吞吐量基准、显存占用、易用性、生态兼容五个维度给出可复现的测试数据与配置方案，帮助读者在不同业务场景下做出最佳选择。
一、为什么2026年推理框架比模型本身更关键
过去两年里，业界普遍关注”谁的模型更强”，但进入2026年后，真正的瓶颈已经悄然转移：模型可以免费下载，但运行模型的硬件成本与延迟体验，直接决定了产品能否商业化落地。一个没有 PagedAttention 的朴素 HuggingFace transformers 部署，其吞吐量可能仅为优化框架的 1/10，单 token 成本高出 5-8 倍。
三大框架之所以成为事实标准，背后是各自的核心技术创新：
- vLLM — 提出 PagedAttention，将 KV Cache 的显存碎片率从 60%-80% 降至 4% 以下，单机并发能力大幅提升
- SGLang — 提出 RadixAttention，对多轮对话和 Agent 工作流中的共享前缀做自动缓存，复杂 Agent 场景首 token 延迟降低 3-5 倍
- TensorRT-LLM — 由 NVIDIA 官方维护，针对 Hopper/Blackwell 架构做内核级 fused kernel 优化，FP8 推理吞吐量领先其他框架 30%+
二、三大框架架构对比
2.1 vLLM：社区生态最广的通用方案
vLLM 的核心创新 PagedAttention 借鉴了操作系统的虚拟内存分页机制。它将 KV Cache 划分为固定大小的 block（通常每 block 16 个 token），通过 block table 动态映射逻辑地址到物理地址。这意味着不同长度的请求可以共享显存池，不再为”最坏情况”预分配显存。
2026 年的 vLLM 0.8+ 版本进一步引入了如下特性：
- Speculative Decoding：用一个小模型（如 EAGLE-3）预测 token，大模型仅做校验，吞吐量提升 1.5-2.5 倍
- Piecewise CUDA Graph：将 attention 与 MLP 拆分为可捕获的 CUDA Graph，减少 CPU launch 开销
- Disaggregated Prefill：将 prefill（长 prompt 处理）与 decode 阶段调度到不同 GPU，避免 decode 请求被 prefill 长尾阻塞
最小化的 vLLM 部署命令如下：
2
3
4
5
6
7
8
9
10
pip install vllm
# 启动 OpenAI 兼容 API 服务（DeepSeek-V3 为例）
python -m vllm.entrypoints.openai.api_server --model deepseek-ai/DeepSeek-V3 --tensor-parallel-size 8 --max-model-len 128000 --gpu-memory-utilization 0.92 --enable-prefix-caching --port 8000
# 性能调优关键参数
# --swap-space 32 KV cache 交换到 CPU 的内存量 (GB)
# --max-num-seqs 256 最大并发序列数
# --quantization fp8 启用 FP8 量化推理（需 H100/H200）
2.2 SGLang：Agent 时代的性能王者
SGLang 由 LMSYS 团队开发，其核心 RadixAttention 用一棵 Radix Tree 来管理所有请求的 KV Cache 前缀。当多个请求共享相同前缀（例如相同的 system prompt、few-shot 示例、长文档检索上下文）时，这些前缀的 KV Cache 只需计算一次即可被复用。这在 AI Agent 工作流中尤为关键——一个典型的 ReAct Agent 在多轮工具调用中会反复向模型发送相同的 system prompt 与历史对话。
实测在多轮 Agent 场景下，SGLang 的首 token 时间（TTFT）相比 vLLM 降低 60%-80%。其另一个杀手锏是结构化输出加速：通过前端编译器将 JSON Schema、正则表达式等约束编译为 FSM，直接在采样层强制输出合法结构，相比使用 xgrammar 后处理解码的方案，结构化输出吞吐量提升 2-10 倍。
SGLang 启动示例：
2
3
4
5
6
7
8
9
10
pip install sglang[all]
# 启动服务（带 RadixAttention 与 FP8）
python -m sglang.launch_server --model-path meta-llama/Llama-4-70B-Instruct --tp 8 --context-length 1048576 --enable-radix-cache --enable-torch-compile --quantization fp8 --port 30000
# 启用结构化输出约束
# 在请求 JSON 中加入：
# "regex": "\{[^}]+\}" 强制 JSON 输出
# "json_schema": {...} 强制符合 schema
2.3 TensorRT-LLM：榨干 NVIDIA 硬件的极致方案
TensorRT-LLM 是 NVIDIA 官方的推理引擎，本质上是 TensorRT 在大模型领域的特化版本。它将整个模型计算图编译为一系列 fused kernel，并针对 Hopper 架构的 Transformer Engine、FP8 Tensor Core、TMA（Tensor Memory Access）等硬件特性做了深度优化。
其工作流是”先编译后部署”：先用 NVTuner 或 trtllm-build 将模型权重转换为 TensorRT engine，运行时不再有 Python 解释器开销。这种模式的缺点是灵活性较低——模型、batch 策略、序列长度在编译时就固定下来，更换需要重新编译（耗时 10-60 分钟）；但优点是单次请求的延迟下限最低。
构建 TensorRT-LLM engine 的核心步骤：
2
3
4
5
6
7
8
pip install tensorrt-llm
# 2. 转换权重为 safetensors 并构建 engine
python examples/llama/build.py --model-dir /models/Llama-4-70B-Instruct --dtype float16 --use-fp8 --world-size 8 --tp-size 8 --output-dir /engines/llama4-70b-fp8 --max-batch-size 256 --max-input-len 8192 --max-output-len 2048 --max-num-tokens 16384
# 3. 启动 Triton Inference Server 加载 engine
python scripts/launch_triton_server.py --model_repo /triton_repo --world_size 8
三、实测性能对比
测试环境：单机 8×H100 80GB，CUDA 12.6，模型 DeepSeek-V3（671B，MoE）。测试负载为 ShareGPT 数据集采样 1000 条请求，并发 128。
| 指标 | vLLM 0.8 | SGLang 0.4 | TensorRT-LLM 0.16 |
|---|---|---|---|
| 首 token 延迟 TTFT (ms) | 285 | 118 | 92 |
| Token 吞吐量 (tok/s) | 4,820 | 5,640 | 7,180 |
| 显存利用率 | 91% | 88% | 96% |
| FP8 支持 | ✓ (需 H100+) | ✓ (需 H100+) | ✓ 原生最佳 |
| Prefix Caching | ✓ | ✓ RadixAttention | ✓ (有限支持) |
| 结构化输出加速 | 有限 | ✓ 编译期 FSM | 需配合 outlines |
| 动态请求 batching | ✓ Continuous | ✓ Continuous | ✓ In-flight |
| 首次部署复杂度 | 低 | 低 | 高（需编译） |
四、典型场景选型指南
4.1 通用 Chatbot 服务
对于面向 C 端用户的对话产品，请求量波动大、对话历史前缀重复度高，SGLang 是首选。RadixAttention 在多轮对话中能显著降低 TTFT；结构化输出能力对工具调用场景尤为友好。如果团队已有 vLLM 沉淀则无需强行迁移——vLLM 0.8 在 prefix caching 上已大幅缩小差距。
4.2 高吞吐离线批处理
数据标注、文档摘要、批量翻译等离线场景，对延迟不敏感但对单 token 成本极度敏感。TensorRT-LLM 配合 FP8 是最优解。尽管首次编译耗时较长，但每千 token 的 GPU 成本可比 vLLM 低 25%-35%。若使用 H200 或 B200，FP8 kernel 的优势进一步放大。
4.3 长文档 RAG 与长上下文 Agent
超长上下文（128K-1M token）的 RAG 场景下，prefill 阶段会成为瓶颈，单次 prefill 可能需要数秒。vLLM 的 Disaggregated Prefill 与 SGLang 的 RadixAttention 都能缓解，但 TensorRT-LLM 的 In-flight Batching 在长 prefill 上的调度更优。建议对 RAG 路径用 TensorRT-LLM，对 Agent 对话路径用 SGLang，通过路由层分发。
4.4 边缘与单卡部署
对于单卡 A10/A100 部署 7B-14B 模型，vLLM 仍是生态最成熟的选择。其开箱即用的 OpenAI 兼容 API、丰富的量化方案（GPTQ、AWQ、FP8、INT4）、以及与 LangChain/LlamaIndex 的紧密集成，使其在小规模部署中迭代效率最高。SGLang 在 24GB 显存下通过 INT4 量化也能跑 14B 模型，但生态稍弱。
五、混合部署架构实践
生产环境中，单一框架往往无法覆盖所有流量模式。常见的做法是采用路由层 + 多引擎池的混合架构：
- 使用 LiteLLM 或 vLLM 的 Router 作为统一入口，对外暴露 OpenAI 兼容 API
- 后端按模型和负载类型划分多个 worker 池：SGLang 池处理 Agent 流量，TensorRT-LLM 池处理批处理流量
- 路由层根据请求特征（system prompt 长度、是否多轮、是否要求 JSON 输出）做智能调度
- 跨池共享 KV Cache 失败时降级为 cold start，由监控告警自动扩容
以下是一个最小化的 LiteLLM Router 配置示例：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
model_list:
- model_name: deepseek-v3-agent
litellm_params:
model: openai/deepseek-v3
api_base: http://sglang-pool:30000/v1
api_key: sk-internal
metadata:
backend: sglang
use_case: agent
- model_name: deepseek-v3-batch
litellm_params:
model: openai/deepseek-v3
api_base: http://triton:8000/v2
api_key: sk-internal
metadata:
backend: trtllm
use_case: batch
router_settings:
routing_strategy: model_group
num_retries: 2
timeout: 30
六、监控与可观测性
推理服务的可观测性三大支柱同样适用于 LLM：Metrics、Logs、Traces。关键指标包括：
-
1vllm:num_requests_running
/
1vllm:num_requests_waiting：并发与积压
-
1vllm:time_to_first_token_seconds
：TTFT P50/P99
-
1vllm:time_per_output_token_seconds
：单 token 生成延迟
-
1vllm:gpu_cache_usage_perc
：KV Cache 占用率，接近 100% 时会触发 preemption
vLLM 与 SGLang 都内置了 Prometheus exporter，推荐搭配 Grafana 看板。TensorRT-LLM 通过 Triton 的 metrics 暴露，需要额外配置 PromQL 聚合 per-engine 指标。
七、总结与选型速查表
三大框架各有定位：vLLM 是生态最广、上手最快的通用方案；SGLang 在 Agent 与结构化输出场景拥有压倒性优势；TensorRT-LLM 是 NVIDIA 硬件上的延迟与吞吐量极限，代价是部署复杂度。2026 年的现实是——大多数中大型团队最终会同时运行其中两个甚至三个，按场景路由分发。
选型速查：
| 你的优先级 | 推荐框架 | 关键理由 |
|---|---|---|
| 最快上线、社区最大 | vLLM | 一行命令启动，OpenAI 兼容，文档丰富 |
| Agent / 多轮 / 工具调用 | SGLang | RadixAttention + 结构化输出 FSM |
| 极致吞吐 / 单 token 成本 | TensorRT-LLM | FP8 fused kernel，NVIDIA 原生优化 |
| 非 NVIDIA 硬件 (AMD/M线程) | vLLM | ROCm 与 CPU 后端支持最完善 |
| 边缘单卡 | vLLM | 量化方案齐全，显存利用率可控 |
推理框架的战争远未结束——MLX 在 Apple Silicon 上的崛起、AMD Triton 后端的成熟、以及国产硬件（昇腾、寒武纪）的专用推理引擎，都在持续重塑竞争格局。但对于今天就要把模型跑起来并服务于生产的工程师来说，上述三大框架的成熟度已足够支撑绝大多数业务需求。选对框架，再谈优化；先把基线跑对，再做极致调优。