推理引擎横评

选引擎不是在项目名里投票

一旦模型不再只在单机脚本里跑，推理引擎就会变成核心组件。

这时候最容易犯的错误，是只盯着 benchmark 排名或者 GitHub 星数。

真正重要的问题是：

你的主要瓶颈到底是什么。

是高并发下的 KV Cache 管理。

是多模型服务化与运维观测。

是 NVIDIA 硬件上的极致延迟。

还是长上下文、多轮复用和前缀共享。

不同引擎并没有在同一层面上竞争。

它们各自把优化重点放在了不同位置。

vLLM 的强项是把 KV Cache 当作一等公民

vLLM 之所以会快速流行，一个根本原因是它把 KV Cache 的管理问题正面做深了。

这不是简单的“能缓存”。

而是缓存如何分块、如何复用、如何在在线请求持续进入时保持显存利用率和吞吐稳定。

它的代表性设计就是 PagedAttention。

PagedAttention 解决了什么

传统连续分配方式下，KV Cache 很容易因为不同请求长度差异而产生内存碎片和浪费。

PagedAttention 的直觉很像虚拟内存分页。

把每个请求的 KV Cache 拆成更细粒度的块。

这样引擎就能用更灵活的方式管理历史状态。

它带来的不是一句抽象的“更快”。

而是在线服务中更高的显存利用率和更稳的并发表现。

特别是请求长度分布差异很大时，这个价值会非常明显。

Continuous Batching 为什么重要

推理服务里的真实流量，不会整齐地一批一批到达。

如果你只能按固定 batch 边界处理请求，就会浪费很多 GPU 空窗。

vLLM 和 TGI 都强调 continuous batching。

它的价值是把“请求异步到达”转成“GPU 尽量持续有活干”。

在线服务吞吐之所以会显著上去，往往正是因为这类调度，而不是因为单个模型前向突然神奇变快。

vLLM 的部署路径

如果你的目标是尽快起一个 OpenAI 兼容服务，vLLM 的路径通常非常直接。

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90

离线批量推理则更像 Python 库用法。

from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen/Qwen2.5-7B-Instruct",
    tensor_parallel_size=2,
    max_model_len=8192,
)
params = SamplingParams(temperature=0.0, max_tokens=128)
outputs = llm.generate(["解释 PagedAttention。"], params)
print(outputs[0].outputs[0].text)

如果你的主要诉求是通用开源模型的高吞吐在线服务，vLLM 往往是第一候选。

TGI 的气质更偏“服务平台”

这里说的 TGI，也就是 Text Generation Inference，更像 Hugging Face 提供的一套偏生产服务化的推理工具箱。

TGI 的优势不只是推理本身。

它在服务化、指标、启动参数治理和 Hugging Face 生态衔接上做得很完整。

如果你的模型与 HF Hub 工作流结合很紧，TGI 往往会显得很顺手。

它同样支持 continuous batching。

官方架构文档也明确提到 paged attention 支持和 router/model server 分层。

因此 TGI 很适合被理解为“平台化味道更重”的推理服务工具。

TGI 的典型部署命令

官方文档目前推荐的入门方式仍然是 Docker。

model=Qwen/Qwen2.5-7B-Instruct
volume=$PWD/data

docker run --gpus all --shm-size 1g -p 8080:80 \
  -v $volume:/data \
  ghcr.io/huggingface/text-generation-inference:3.3.5 \
  --model-id $model \
  --max-concurrent-requests 128 \
  --max-total-tokens 8192

这里最值得重视的不是镜像标签。

而是 --max-concurrent-requests 和 --max-total-tokens 这类参数。

它们实际上在定义服务的背压边界与内存预算。

如果没有把这条线守住，系统高峰时就容易把等待队列和显存一起拖垮。

TensorRT-LLM 的思路完全不同

如果说 vLLM 和 TGI 更像“通用服务引擎”，那么 TensorRT-LLM 更像一条偏编译与硬件深度优化的路线。

它的重点不只是把模型跑起来。

而是把模型尽量编译到适合 NVIDIA GPU 的高性能执行形式。

这意味着：

• 对硬件与软件栈要求更明确。
• 前期准备通常更重。
• 一旦条件匹配，延迟与吞吐上限可能很强。

所以 TensorRT-LLM 更适合“硬件已经确定、追求极致性能”的环境。

编译式部署意味着什么

很多团队第一次碰到 TensorRT-LLM，会不适应它的节奏。

因为它不像“pip install 然后 serve”那么轻。

你通常要先准备 checkpoint。

再构建引擎。

再用服务端加载这个引擎。

这就是编译式部署的代价。

它换来的，是更强的内核融合、图优化和硬件贴合度。

TensorRT-LLM 的常见命令

官方快速开始文档里，最短路径是直接 trtllm-serve 一个 Hugging Face 模型。

trtllm-serve "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

如果你已经有 TensorRT-LLM checkpoint，并想构建专用引擎，常见命令会更像这样。

trtllm-build \
  --checkpoint_dir /models/qwen3-8b-fp8 \
  --output_dir /engines/qwen3-8b \
  --max_batch_size 16 \
  --max_input_len 4096 \
  --max_seq_len 8192

然后再把构建好的结果挂到服务上。

trtllm-serve /engines/qwen3-8b

如果你的集群本来就是 NVIDIA GPU 主导，而且对极限性能、FP8/INT4、编译优化非常敏感，TensorRT-LLM 的价值会越来越明显。

SGLang 的独特之处在前缀复用与长上下文

SGLang 常被拿来和 vLLM 一起比较。

二者确实都很关注服务性能。

但 SGLang 在前缀复用、程序化推理和长上下文场景上有自己很鲜明的方向。

其中一个关键词就是 RadixAttention。

它的直觉不是单纯把 KV Cache 管理得更整齐。

而是进一步利用“很多请求共享前缀”的事实。

例如多轮对话、模板化提示、相似系统提示词，都会带来大量可复用前缀。

如果能够高效命中这些前缀缓存，TTFT 和整体吞吐都会受益。

SGLang 的启动方式

官方文档给出的常见方式也很直白。

python3 -m sglang.launch_server \
  --model-path Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 30000

如果是面向 OpenAI 风格接口的调用，同样可以直接走兼容层。

curl http://127.0.0.1:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "请解释 SGLang 为什么强调前缀复用。"}
    ],
    "temperature": 0,
    "max_tokens": 128
  }'

如果你的请求里有大量共享前缀，或者你在做多轮程序化 agent 流程，SGLang 的优势会更容易体现。

选型时最容易忽视的其实是运维面

推理引擎不是 benchmark demo。

你最终还要面对：

• 监控和指标暴露。
• backpressure 与限流。
• 模型热更新。
• 量化格式支持。
• LoRA 多 adapter 支持。
• 多机并行和副本管理。

有些引擎在单机性能上很强。

但你要的可能是“明天能上线并稳定值班”。

有些引擎入门复杂。

但一旦部署标准化，长期收益很大。

因此别把选型问题缩成“谁 token/s 更高”。

一个务实的场景化选择方法

如果要给一个非常实用的粗分法，可以这样看。

• 通用在线服务、高吞吐、社区生态活跃：先看 vLLM。
• Hugging Face 工作流紧密、希望服务参数治理完整：先看 TGI。
• NVIDIA 硬件稳定、愿意为极限性能接受编译复杂度：先看 TensorRT-LLM。
• 前缀复用、多轮长上下文、程序化推理场景明显：先看 SGLang。

这不是绝对结论。

但比抽象排名更接近真实工程决策。

本篇要点

• vLLM 把 KV Cache 管理与 continuous batching 做成核心能力，适合通用高吞吐在线服务。
• TGI 更偏服务平台化，和 Hugging Face 生态衔接顺畅，参数治理与指标暴露较完整。
• TensorRT-LLM 走编译式和硬件深度优化路线，适合 NVIDIA 环境下追求极致性能的部署。
• SGLang 在前缀复用和长上下文场景上有鲜明优势，RadixAttention 是其代表性设计。
• 推理引擎选型必须回到请求形状、硬件环境、运维能力与上线目标，而不是只看 benchmark。

下一篇

上一篇把大模型能力压进了小模型，这一篇则比较了真正承载在线流量的执行底座。下一篇会更贴近交付现场，直接讨论 DeepSeek、Qwen、Mistral 这几类开源模型如何拿权重、起服务、兼容 OpenAI API，以及上线前该先检查哪些性能项。

参考资料

• vLLM Serve CLI
• vLLM Paged Attention
• Hugging Face TGI Documentation
• Hugging Face TGI Launcher Arguments
• TensorRT-LLM Quick Start Guide
• TensorRT-LLM trtllm-build
• SGLang OpenAI API Completions