摘要

本文将对当前大语言模型（LLM）推理领域两大高性能开源框架——vLLM 与 SGLang 进行全面的性能对比与深度解析。我们将从设计哲学、核心架构、吞吐量、延迟、内存效率、易用性、生态支持等多个维度展开评测，并结合实际应用场景（如 API 服务、批量推理、长上下文处理）给出选型建议，旨在帮助开发者和研究者根据自身需求做出最佳技术决策。

1. 引言：LLM 推理优化的挑战与框架演进

1.1 大模型推理的瓶颈：计算、内存与 I/O

随着大语言模型参数量突破千亿，推理过程面临三大核心瓶颈：

• 计算瓶颈：自回归生成（Autoregressive Generation）的串行特性限制了 GPU 算力的有效利用。
• 内存瓶颈：KV Cache（键值缓存）随序列长度线性增长，成为显存占用的主要部分，尤其在处理长上下文时。
• I/O 瓶颈：模型权重加载、中间结果交换带来的延迟，在多用户并发场景下尤为突出。

1.2 推理优化技术概览

为应对上述挑战，业界涌现出多项关键技术：

• PagedAttention：由 vLLM 提出，将 KV Cache 划分为固定大小的“块”（Block）进行管理，类似操作系统虚拟内存分页，极大减少了内存碎片。
• Continuous Batching：动态批处理技术，允许不同请求在生成过程中加入或退出批处理，提高 GPU 利用率。
• RadixAttention：SGLang 的核心创新，通过构建前缀共享的基数树（Radix Tree）来复用公共提示词的 KV Cache，特别适合具有固定模板的批量任务。

1.3 vLLM 与 SGLang 的诞生背景与定位

• vLLM：由加州大学伯克利分校团队开发，于 2023 年中开源。其定位是高性能、通用的 LLM 推理与服务引擎，旨在成为部署 LLM API 服务的“事实标准”。它通过 PagedAttention 解决了内存效率问题，并通过 Continuous Batching 优化了吞吐。
• SGLang：由 SGLang 团队开发，于 2024 年初发布。其定位是面向复杂、交互式提示模式的 LLM 编程语言与运行时。它不重复造轮子，而是作为“调度层”或“加速层”，可以后端对接 vLLM、TensorRT-LLM 等引擎，通过 RadixAttention 对特定模式（如多轮对话、思维链）进行极致优化。

1.4 本文评测目标与方法论

本文旨在超越简单的基准数字对比，深入剖析两大框架的设计哲学如何影响其在不同场景下的表现。我们将采用“理论分析 + 实测数据 + 场景匹配”的方法，为读者提供一个立体、实用的选型框架。

2. vLLM 深度剖析

2.1 核心设计哲学：以 PagedAttention 实现高效 KV Cache 管理

vLLM 的核心思想是将操作系统的虚拟内存管理理念引入 LLM 推理。它将每个请求的 KV Cache 在逻辑上视为连续空间，在物理上划分为离散的、固定大小的块。块管理器（Block Manager）负责这些块的分配、释放与映射，实现了：

• 近乎零碎片化：块可被不同请求的任意序列位置复用。
• 高效的内存池：显存利用率显著提升，尤其在处理变长序列和突发请求时。

2.2 架构总览

2.2.1 调度器（Scheduler）与块管理器（Block Manager）

• 调度器：采用迭代级调度策略。在每个生成步（iteration），根据请求的当前状态（等待、运行、完成）和可用资源，动态决定哪些请求进入下一个批处理。
• 块管理器：维护逻辑块与物理块的映射表。当请求需要扩展序列时，分配新的空闲块；当请求完成或序列缩短时，回收块至内存池。

2.2.2 内存池（Memory Pool）与 Paged KV Cache

内存池预分配一组物理块。Paged KV Cache 使得一个请求的 KV 值可以存储在非连续的物理块中，通过映射表关联，从而支持灵活的块分配与共享（未来版本）。

2.2.3 模型执行引擎

负责加载模型权重，接收调度器组织好的批处理数据（包含 tokens 和块映射信息），执行前向计算，并返回生成的 logits 或 tokens。

2.3 关键性能特性

2.3.1 高吞吐量：Continuous Batching 与迭代级调度

vLLM 实现了高效的动态批处理。与静态批处理相比，它允许：

• 新请求随时加入。
• 已生成完成的请求随时退出。
• 批处理大小在每个迭代步都可能变化，最大化 GPU 利用率。

2.3.2 内存效率：近乎零碎片化的 KV Cache 管理

实测表明，在混合了长短序列的负载下，vLLM 的显存利用率可比原生 PyTorch 实现提升 2-4 倍，显著提高了单卡可服务的并发用户数或可处理的序列长度。

2.3.3 对长上下文的支持

PagedAttention 天然适合长上下文场景。处理超长文本时，vLLM 只需按需分配块，避免了为整个长序列一次性分配巨大连续显存的开销和碎片问题。

2.4 主要应用场景与接口

2.4.1 OpenAI 兼容的 API 服务器

vLLM 的命令行工具和 Python API 可以一键启动一个与 OpenAI API 格式完全兼容的服务，方便现有应用无缝迁移。

# 启动服务
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3.1-8B-Instruct \
    --served-model-name llama-3.1-8b

# 客户端调用
from openai import OpenAI
client = OpenAI(api_key="token-abc123", base_url="http://localhost:8000/v1")
response = client.chat.completions.create(
    model="llama-3.1-8b",
    messages=[{"role": "user", "content": "Hello!"}]
)

2.4.2 离线批量推理

提供高级批处理接口，适合对大量文档进行摘要、分类、翻译等任务。

from vllm import LLM, SamplingParams
llm = LLM(model="Qwen/Qwen2.5-7B-Instruct")
prompts = ["Translate to English: 你好世界", "Summarize: ..."]
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)
outputs = llm.generate(prompts, sampling_params)

2.4.3 与其他框架的集成

通过其 API 服务器，可以轻松与 LangChain、LlamaIndex 等应用框架集成。

3. SGLang 深度剖析

3.1 核心设计哲学：通过 RadixAttention 实现极致的前缀共享与复用

SGLang 的核心洞察是：许多 LLM 应用（如 RAG、多轮对话、思维链）中存在大量可复用的计算，尤其是提示词（Prompt）部分。RadixAttention 通过构建一个共享的 KV Cache 基数树，使得相同的前缀只需计算一次，后续请求可直接复用。

3.2 架构总览

3.2.1 前端：灵活的 DSL 与编程接口

SGLang 提供了一种领域特定语言和 Python 装饰器，让用户能够以更结构化的方式描述复杂的提示逻辑。
https://gitee.com/blog-updates/1768826889/blob/master/4XkL9mQwR7tN3pFvY2aH.md

import sglang as sgl

@sgl.function
def multi_turn_chat(s, question):
    s += "System: You are a helpful assistant.\n"
    s += "User: " + question + "\n"
    s += "Assistant:"
    s += sgl.gen("response", max_tokens=100)
    return s

# 运行函数
state = multi_turn_chat.run(question="What is AI?")
print(state["response"])

3.2.2 运行时：RadixAttention 缓存与调度

• RadixAttention 缓存：维护一个全局的基数树。树的每个节点对应一个 token 序列前缀，并缓存其对应的 KV 值。
• 运行时调度器：解析程序 IR，识别可共享的前缀，查询缓存，将未命中的前缀部分和生成部分派发给后端引擎。

3.2.3 后端：与多种推理引擎对接

SGLang 自身不实现底层计算，而是作为协调层，支持 vLLM、TensorRT-LLM、LiteLLM 等多种后端，兼具灵活性与性能。

3.3 关键性能特性

3.3.1 极致的提示词与生成解耦

在 RAG 场景中，系统提示词、检索到的文档内容（前缀）与用户问题（可变后缀）被清晰分离。SGLang 可以缓存“系统提示词+文档”这个长前缀，当不同用户提问时，只需计算问题部分，极大加速批量问答。

3.3.2 基于 Radix Tree 的 KV Cache 共享与复用

对于具有固定模板的批量任务（如给 1000 条新闻生成标题），模板部分作为公共前缀在 Radix Tree 中只计算和存储一次，为每个请求节省了大量计算和内存。

3.3.3 对复杂推理模式的加速

思维链（CoT）、函数调用（Function Calling）等模式通常包含多次模型调用和固定的推理模板。SGLang 可以将这些模板和中间状态缓存起来，加速多次调试或批量执行。

3.4 主要应用场景与接口

3.4.1 交互式、多轮对话场景

其 DSL 能自然表达对话流，且能缓存历史对话轮次，加速后续交互。

3.4.2 提示词工程与 A/B 测试

快速迭代不同的提示词模板，并利用缓存公平地对比不同模板在相同输入下的性能。

3.4.3 需要大量重复前缀的批量任务

这是 SGLang 的“杀手级”场景。例如：

• 批量定制邮件：模板相同，仅姓名、产品信息不同。
• 代码补全：相同的文件前缀，补全后续不同行。
• 评估基准测试：对大批量测试用例运行相同的评估提示词。

4. 性能横评：基准测试设计与环境

(下文将基于此大纲展开详细的性能数据对比、场景选型指南与总结。)