大模型推理框架选型决策指南：vLLM、SGLang、TensorRT-LLM、TGI 与 LMDeploy 五大框架场景适配与生产部署对比

在大模型落地部署的环节中，推理框架的选择直接决定了服务的吞吐量、延迟、显存利用率和运维复杂度。当前主流的推理框架包括 vLLM、SGLang、TensorRT-LLM、TGI（Text Generation Inference）以及近两年崛起的 LMDeploy。每个框架都有其独特的设计哲学和适用场景——vLLM 凭借 PagedAttention 占据生态优势，SGLang 的 RadixAttention 在结构化输出场景表现优异，TensorRT-LLM 追求极致性能但部署门槛高，TGI 背靠 HuggingFace 生态开箱即用，而 LMDeploy 则在国产 GPU 和端侧推理方面独树一帜。

本文将从架构设计、吞吐量性能、显存效率、部署复杂度、量化支持、多卡并行能力和场景适配七个维度，对这五大推理框架进行深度横向对比，并给出不同业务场景下的选型决策建议。无论你是需要部署开源大模型服务、还是在端侧做推理优化，都能从中找到适合自己的框架选型方案。

一、五大推理框架架构设计与核心特性对比

理解推理框架的架构设计是选型的第一步。不同框架在 KV Cache 管理、调度策略和计算优化方面采用了截然不同的技术路线，这直接影响了它们在不同负载下的表现。

1.1 vLLM：PagedAttention 驱动的通用推理引擎

vLLM 的核心创新是 PagedAttention，它借鉴了操作系统的虚拟内存分页机制来管理 KV Cache。传统推理框架在分配 KV Cache 时需要预分配连续的显存空间，导致大量显存碎片化。vLLM 将 KV Cache 划分为固定大小的 block（通常每 block 存放 16 个 token 的 KV），通过 Block Table 实现逻辑块到物理块的映射，使得显存利用率从传统方案的 20%-40% 提升到 80% 以上。

1
2
3
4
5
6
7
8
9
10
11
# vLLM 基础部署

pip install vllm



# 启动 OpenAI 兼容 API 服务

python -m vllm.entrypoints.openai.api_server \

  --model meta-llama/Meta-Llama-3.1-8B-Instruct \

  --tensor-parallel-size 2 \

  --gpu-memory-utilization 0.9 \

  --max-model-len 8192 \

  --enable-prefix-caching \

  --port 8000

vLLM 支持 Continuous Batching（连续批处理）、Prefix Caching（前缀缓存）和 Speculative Decoding（投机解码）等高级特性。其社区活跃度最高，API 兼容性最好，是目前生产环境中最广泛使用的大模型推理框架。

1.2 SGLang：RadixAttention 与结构化输出专家

SGLang 的核心创新是 RadixAttention——一种基于基数树（Radix Tree）的 KV Cache 复用机制。与 vLLM 的 Block-level 缓存不同，RadixAttention 在更细粒度上复用 KV Cache，特别适合多轮对话和 Few-shot 推理场景。当多个请求共享相同的前缀（如系统提示词、Few-shot 示例），RadixAttention 能够自动识别并复用已计算的 KV Cache，显著降低重复计算开销。

1
2
3
4
5
6
7
8
9
10
# SGLang 部署

pip install "sglang[all]"



# 启动服务（支持结构化输出）

python -m sglang.launch_server \

  --model-path meta-llama/Meta-Llama-3.1-8B-Instruct \

  --tp 2 \

  --port 30000 \

  --enable-radix-cache \

  --json-model-responses

SGLang 在结构化输出（JSON/正则约束解码）方面有独特优势，通过

参数可以强制模型输出符合 JSON Schema 的结果，这对函数调用和工具使用场景至关重要。

1.3 TensorRT-LLM：NVIDIA 生态的极致性能方案

TensorRT-LLM 是 NVIDIA 官方推出的推理优化引擎，基于 TensorRT 构建。它通过算子融合（Operator Fusion）、Kernel 自动调优（Kernel Auto-Tuning）和 INT8/FP8 量化等技术，在 NVIDIA GPU 上实现了当前最高的推理吞吐量。但代价是部署复杂度高——需要先将模型转换为 TensorRT 引擎格式，且不同 GPU 架构需要分别编译。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# TensorRT-LLM 编译流程

# 1. 获取模型权重

git clone https://github.com/NVIDIA/TensorRT-LLM.git

cd TensorRT-LLM



# 2. 转换模型为 TensorRT 引擎

python examples/llama/convert_checkpoint.py \

  --model_dir /models/llama-3.1-8b \

  --output_dir /models/llama-3.1-8b/trt_ckpt \

  --dtype float16 \

  --tp_size 2



# 3. 编译 TensorRT 引擎

trtllm-build \

  --checkpoint_dir /models/llama-3.1-8b/trt_ckpt \

  --output_dir /models/llama-3.1-8b/trt_engine \

  --gemm_plugin float16 \

  --max_batch_size 256 \

  --max_input_len 4096 \

  --max_output_len 2048

1.4 TGI：HuggingFace 生态的开箱即用方案

TGI（Text Generation Inference）是 HuggingFace 官方推出的推理框架，最大优势是与 HuggingFace Hub 的深度集成。只需指定模型名称即可自动下载和部署，无需手动编译或转换。TGI 内部使用 Flash Attention、Continuous Batching 和 Paged Attention 等优化技术，性能虽不及 TensorRT-LLM 但胜在易用性。

1
2
3
4
5
6
7
8
# TGI Docker 部署

docker run --gpus all -p 8080:80 \

  -v /data:/data \

  ghcr.io/huggingface/text-generation-inference:latest \

  --model-id meta-llama/Meta-Llama-3.1-8B-Instruct \

  --num-shard 2 \

  --max-input-tokens 4096 \

  --max-total-tokens 8192

1.5 LMDeploy：国产 GPU 与端侧推理的新锐力量

LMDeploy 由 OpenMMLab 团队开发，最初为 InternLM 系列模型设计，现已支持主流开源模型。其最大特色是对国产 GPU（如海光 DCU、华为昇腾）的良好支持，以及 TurboMind 引擎在量化推理方面的高效表现。LMDeploy 支持 W4A16 量化推理，在几乎不损失精度的情况下将显存占用降低到原来的 1/3。

1
2
3
4
5
6
7
8
9
# LMDeploy 安装

pip install lmdeploy



# 启动 API 服务（支持 W4A16 量化）

lmdeploy serve api_server meta-llama/Meta-Llama-3.1-8B-Instruct \

  --tp 2 \

  --port 23333 \

  --quant-policy 4 \

  --cache-max-entry-count 0.9

二、性能基准测试：吞吐量、延迟与显存占用横向对比

为客观评估五大框架的性能差异，我们使用 Llama 3.1 8B 模型在 2×A100 80GB GPU 上进行标准化基准测试。测试场景涵盖纯 Prefill、纯 Decode 和混合负载三种模式。

2.1 吞吐量对比（Tokens/s）

注：测试模型为 Llama 3.1 8B FP16，输入长度 1024 tokens，输出长度 256 tokens。数据仅供参考，实际性能受硬件和配置影响。

2.2 显存占用对比

从数据可以看出，TensorRT-LLM 在吞吐量方面领先，比 vLLM 高约 15%-20%。但 LMDeploy 通过 W4A16 量化将模型权重从 15.2GB 压缩到 5.8GB，为 KV Cache 释放了更多显存空间，在显存受限的场景下优势明显。

2.3 延迟对比（单请求 TTFT）

首 Token 延迟（Time To First Token, TTFT）是交互式应用的关键指标。在输入长度为 1024 tokens 的场景下：

TensorRT-LLM 在延迟方面全面领先，得益于其算子融合和 Kernel 优化。SGLang 的 TTFT 优于 vLLM，主要因为 RadixAttention 在存在前缀复用时可以跳过 Prefill 计算。

三、量化支持与精度损失分析

量化是降低推理成本的关键技术。不同框架对量化方案的支持程度差异显著，这直接影响选型决策。

3.1 各框架量化方案对比

vLLM 在量化支持方面最为全面，支持在线动态量化且兼容 AWQ、GPTQ 等主流量化算法。TensorRT-LLM 虽然 FP8 支持优秀，但量化模型需要离线编译，灵活性不足。LMDeploy 的 TurboMind 引擎在 W4A16 量化方面做了深度优化，量化后推理速度反而可能超过 FP16。

3.2 量化后精度损失实测

使用 Llama 3.1 8B 在 MMLU 数据集上测试不同量化方案的精度表现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 量化精度评估脚本（以 vLLM AWQ 为例）

from vllm import LLM, SamplingParams



# 加载 AWQ 量化模型

llm = LLM(

    model="TheBloke/Llama-3.1-8B-Instruct-AWQ",

    quantization="awq",

    dtype="float16",

    gpu_memory_utilization=0.9

)



sampling_params = SamplingParams(

    temperature=0.0,

    max_tokens=512

)



# MMLU 评测

prompts = [

    "Question: What is the capital of France?\nAnswer:",

    "Question: Which planet is closest to the Sun?\nAnswer:",

]



outputs = llm.generate(prompts, sampling_params)

for output in outputs:

    print(f"Prompt: {output.prompt}")

    print(f"Generated: {output.outputs[0].text}\n")

实测数据显示，W4A16 量化在 MMLU 上精度损失约 1-2%，W8A8 几乎无损，FP8 在 H100 上精度与 FP16 持平。对于绝大多数生产场景，W4A16 量化是性价比最高的选择。

四、多卡并行与分布式推理能力

当模型参数量超过单卡显存容量时，多卡并行推理成为刚需。不同框架在张量并行（TP）和流水线并行（PP）方面的支持程度不同。

4.1 张量并行配置对比

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# vLLM: 4卡张量并行

python -m vllm.entrypoints.openai.api_server \

  --model meta-llama/Meta-Llama-3.1-70B-Instruct \

  --tensor-parallel-size 4 \

  --gpu-memory-utilization 0.9



# SGLang: 4卡张量并行

python -m sglang.launch_server \

  --model-path meta-llama/Meta-Llama-3.1-70B-Instruct \

  --tp 4



# LMDeploy: 4卡张量并行

lmdeploy serve api_server meta-llama/Meta-Llama-3.1-70B-Instruct \

  --tp 4



# TGI: 4卡分布式部署

docker run --gpus all -p 8080:80 \

  -v /data:/data \

  ghcr.io/huggingface/text-generation-inference:latest \

  --model-id meta-llama/Meta-Llama-3.1-70B-Instruct \

  --num-shard 4

vLLM 通过 Ray 后端支持多节点推理，适合超大规模集群部署。TensorRT-LLM 在 NCCL 通信方面做了深度优化，多卡扩展效率最高。SGLang 在 PD 分离架构方面走在前列，适合 Prefill 和 Decode 负载差异大的场景。关于 PD 分离架构的深入分析，可以参考我们之前的 PD 分离架构实战详解一文。

五、场景适配：不同业务需求下的框架选型决策

性能基准只是选型的一个维度，实际决策需要综合考虑业务场景、团队能力和硬件环境。以下是五种典型场景的选型建议。

场景一：高并发 API 服务（如 ChatGPT 类应用）

推荐框架：vLLM 或 SGLang

高并发 API 服务需要处理大量并发请求，吞吐量和尾延迟是关键指标。vLLM 凭借 PagedAttention 和成熟的 Continuous Batching 实现，在高并发场景下表现稳定。SGLang 的 RadixAttention 在多轮对话场景中能显著降低重复计算，如果服务中存在大量相同系统提示词，SGLang 是更优选择。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# vLLM 高并发部署最佳实践

from vllm import LLM, SamplingParams



llm = LLM(

    model="meta-llama/Meta-Llama-3.1-8B-Instruct",

    tensor_parallel_size=2,

    gpu_memory_utilization=0.9,    # 留 10% 给系统

    max_num_batched_tokens=16384,  # 控制单批处理量

    max_num_seqs=512,               # 最大并发序列数

    enable_prefix_caching=True,    # 开启前缀缓存

    swap_space=4,                   # CPU 交换空间 (GB)

)



# 批量推理

sampling_params = SamplingParams(

    temperature=0.7,

    top_p=0.9,

    max_tokens=1024,

)

场景二：低延迟实时对话（如语音助手）

推荐框架：TensorRT-LLM

实时对话场景对首 Token 延迟（TTFT）极其敏感，用户期望在 100ms 内看到响应。TensorRT-LLM 通过算子融合和 Kernel 自动调优，将 TTFT 降到 62ms，远低于其他框架。但需要接受其较高的部署复杂度和维护成本。

场景三：结构化输出与函数调用

推荐框架：SGLang

当模型需要输出符合特定 Schema 的 JSON 数据时，SGLang 的结构化输出能力远超其他框架。它通过约束解码（Constrained Decoding）确保输出始终符合指定的 JSON Schema，不需要依赖后处理或重试机制。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# SGLang 结构化输出示例

import requests



# 定义输出 JSON Schema

schema = {

    "type": "object",

    "properties": {

        "name": {"type": "string"},

        "age": {"type": "integer"},

        "skills": {"type": "array", "items": {"type": "string"}}

    },

    "required": ["name", "age", "skills"]

}



response = requests.post("http://localhost:30000/generate", json={

    "text": "Generate a JSON profile for a software engineer",

    "sampling_params": {"temperature": 0.0, "max_tokens": 256},

    "json_schema": schema

})



# 输出保证符合 schema

print(response.json())

场景四：显存受限环境（如单卡 24GB GPU）

推荐框架：LMDeploy（W4A16 量化）

在消费级 GPU（如 RTX 4090 24GB）上部署 70B 模型几乎不可能，但通过 W4A16 量化可以将权重压缩到约 35GB，配合 LMDeploy 的 TurboMind 引擎，在双 4090 上运行 70B 模型成为可能。LMDeploy 的量化推理速度接近甚至超过 FP16 原始精度，是显存受限场景的最佳选择。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# LMDeploy W4A16 量化部署

# 1. 量化模型

lmdeploy lite auto_awq \

  /models/llama-3.1-70b \

  --calib-dataset 'pileval' \

  --calib-samples 128 \

  --calib-seqlen 2048 \

  --w-bit 4 \

  --work-dir /models/llama-3.1-70b-4bit



# 2. 启动量化推理服务

lmdeploy serve api_server /models/llama-3.1-70b-4bit \

  --tp 2 \

  --quant-policy 4 \

  --cache-max-entry-count 0.9 \

  --port 23333

场景五：快速原型验证与开发

推荐框架：TGI

当团队需要快速验证模型能力、不追求极致性能时，TGI 的开箱即用特性是最优选择。只需一个 Docker 命令即可启动服务，且自动处理模型下载、权重转换和推理优化。HuggingFace Hub 上的任何模型都可以直接通过 TGI 部署。

六、选型决策矩阵与总结

基于以上分析，我们整理了一份选型决策矩阵，帮助快速定位适合的框架：

最终选型建议：

• 大多数生产场景：选择 vLLM——它在性能、易用性、社区支持和功能完整性方面取得了最佳平衡。如果没有特殊需求，vLLM 是最安全的选择。关于 vLLM 的深度调优，可以参考vLLM 推理参数调优全攻略。
• 追求极致性能且有 NVIDIA H100/A100：选择 TensorRT-LLM——值得为其部署复杂度付出额外成本。
• 结构化输出和多轮对话场景：选择 SGLang——RadixAttention 的优势在这些场景中无法替代。
• 显存受限或使用国产 GPU：选择 LMDeploy——W4A16 量化和国产 GPU 适配是独特优势。
• 快速验证和原型开发：选择 TGI——用最少的配置获得可用的推理服务。

推理框架的选择不是一劳永逸的决策。建议在实际部署前，使用自己的模型和负载进行基准测试，并结合团队的技术栈和运维能力做出最终选择。随着 vLLM 和 SGLang 的快速迭代，以及 LMDeploy 在量化推理方面的持续优化，推理框架的竞争格局仍在不断演进。保持关注各框架的最新进展，定期评估是否有更优的替代方案，是推理服务长期运营的关键。