认识vLLM和SGLang

vLLM 是目前更通用、更稳妥的 LLM serving 默认选择；SGLang 更适合复杂推理流程、长前缀复用、结构化输出和 agent 场景。两者都支持 OpenAI-compatible API，但真正选型要基于自己的模型、GPU、上下文长度、并发和请求模式做压测。

对比维度	vLLM	SGLang	笔记结论
核心定位	高性能 LLM 推理与服务引擎	高性能 LLM/VLM 推理框架 + 可编程生成运行时	vLLM 更像“模型服务器”，SGLang 更像“模型服务器 + 复杂 LLM 工作流框架”
主要用途	把开源大模型部署成 OpenAI-compatible API	部署模型，同时优化复杂 prompt、多轮、分支、结构化生成	普通服务优先 vLLM，复杂推理流程重点看 SGLang
代表技术	PagedAttention、continuous batching、KV Cache 管理	RadixAttention、prefix cache、structured generation	vLLM 强在通用吞吐，SGLang 强在前缀复用和复杂生成
API 兼容	OpenAI-compatible API 较成熟	支持 OpenAI-compatible API，也支持 native /generate	两者都能接 OpenAI SDK、LangChain、LlamaIndex 等生态
上手难度	较低，vllm serve model 即可启动	中等，基础启动简单，但高级能力更多	新手先跑 vLLM 更顺
典型启动命令	vllm serve Qwen/Qwen2.5-7B-Instruct	python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct	都可以几行命令启动服务
适合模型	Llama、Qwen、DeepSeek、Mistral、GLM 等主流 LLM/VLM	Llama、Qwen、DeepSeek、Kimi、VLM、MoE 等	两者模型覆盖都很广，具体模型要查兼容列表
普通聊天服务	很适合	适合	如果只是 chat API，vLLM 通常更省心
RAG 场景	很适合	很适合，尤其长前缀/共享上下文较多时	RAG 都能做；长上下文复用多时 SGLang 值得测
Agent 场景	可用	更强调复杂 agent/workflow	多轮、工具调用、分支推理多时，SGLang 更有优势
结构化输出	支持 JSON schema、guided decoding、tool calling 等	强调 JSON schema、regex、EBNF、structural tag 等	两者都能做，SGLang 在这块更像核心卖点
Prefix Cache	支持 prefix caching	RadixAttention 是核心能力之一	大量请求共享 system prompt/few-shot/context 时，SGLang 需要重点压测
长上下文	支持，依赖模型和显存配置	支持，且重视长上下文复用	长上下文不是只看最大长度，还要看 TTFT、显存和缓存命中
多卡能力	tensor parallel、pipeline parallel、多节点等	tensor/data/pipeline/expert parallel、PD 分离等	生产多卡两者都能做，部署复杂度需实测
量化支持	支持 AWQ、GPTQ、FP8、bitsandbytes 等多种方式	支持多种量化和 KV cache dtype	量化格式兼容性要按具体模型确认
LoRA 支持	支持 LoRA / multi-LoRA serving	支持 LoRA / adapter 相关能力	多租户微调模型服务时都可调研
监控	支持 Prometheus metrics 等生产接口	支持 metrics，需要启动参数开启	上生产都需要配合监控系统
生态成熟度	更主流，社区资料和集成更多	增长很快，前沿特性活跃	稳妥选型先 vLLM，性能/复杂场景再测 SGLang
生产部署	常用于线上 LLM serving	也在快速进入生产场景	两者都不是“玩具框架”，都值得进入 PoC
M1 Mac 可用性	可通过 vLLM-Metal/MLX 路线尝试，主线仍偏 Linux + NVIDIA	Apple Silicon 支持更实验性，主线仍偏 Linux + NVIDIA	M1 适合学习体验，不适合代表真实性能
本地学习建议	可以先用小模型跑 OpenAI API	可以跑通服务和结构化输出概念	M1 上建议 0.5B/1.5B/3B 量化模型起步
选型倾向	默认首选、通用稳定、接入简单	前缀复用、结构化输出、复杂 workflow 时重点考虑	真正结论要靠同模型、同 GPU、同 prompt 分布压测

vLLM

vLLM 是一个 大语言模型推理与服务框架。它的目标不是训练模型，而是把 Qwen、DeepSeek、GLM 等开源模型高效地跑起来，并提供类似 OpenAI 的 API 服务。

一、vLLM 解决了什么痛点？

直接用 Hugging Face Transformers 跑模型也能生成文本，但不适合高并发线上服务。主要问题有三个：
第一，请求长度不一样。有人只问一句话，有人塞一整篇文档，普通 batch 很难排得高效。
第二，KV Cache 非常吃显存。LLM 生成时，为了避免重复计算历史 token，会把 attention 的 key/value 缓存在显存里。上下文越长、并发越高，KV Cache 越大。
第三，显存容易碎片化。传统方式如果按连续空间管理 KV Cache，会出现大量浪费。vLLM 的核心技术 PagedAttention 就是为了解决这个问题。

PagedAttention

PagedAttention 是 vLLM 最有代表性的设计。官方早期博客里把它类比成操作系统里的分页机制：不要强迫一条序列的 KV Cache 在显存里连续存放，而是拆成很多固定大小的 block。

概念	简易理解
token	文本被模型处理后的基本单位
KV Cache	模型记住前文计算结果的缓存
block	一小段 KV Cache
PagedAttention	用“分页”的方式管理 KV Cache
block table	记录逻辑 token 块对应到哪些物理显存块

这样做的好处是：

好处	说明
减少显存浪费	KV Cache 不需要连续分配，碎片更少
提高并发能力	同样显存下可以容纳更多请求
支持动态请求	请求长短不同也更容易调度
支持共享前缀	多个输出或相同 prompt 可以共享一部分缓存

所以 vLLM 之所以快，是因为把显存里的 KV Cache，管理得更细。

Continuous Batching

传统 batch 是凑一批请求，一起跑完，再处理下一批。LLM serving 不能这么简单，因为每个请求生成长度不同。有的请求 20 个 token 就结束，有的请求要生成 1000 个 token。
vLLM 使用 continuous batching，意思是：服务运行时持续维护一个动态 batch。某些请求结束后，新的请求可以补进来，不需要等整批请求全部结束。

举个例子：

普通 batch：
等一批人上车 -> 车开走 -> 所有人下车 -> 下一批再上车

continuous batching：
车一直运行 -> 有人到站下车 -> 新乘客马上补上

它的意义是提高 GPU 利用率。GPU 最怕空转，continuous batching 就是尽量让 GPU 一直有活干。

推理过程

一次 vLLM 请求大概会经历这几个阶段：

用户请求
  -> OpenAI-compatible HTTP API
  -> tokenizer / chat template
  -> scheduler 调度
  -> prefill 阶段：处理 prompt
  -> decode 阶段：逐 token 生成
  -> KV Cache / PagedAttention 管理显存
  -> 返回完整或流式结果

阶段	解释	常见瓶颈
Prefill	读取 prompt / system prompt / RAG 文档	长上下文、长文档
Decode	一个 token 一个 token 生成答案	长输出、高并发

如果你的业务是 RAG，用户每次带很长文档，prefill 成本很高。

如果你的业务是长文生成，每次输出几千 token，decode 成本很高。

二、简单入门

vLLM 最常见的使用方式是启动 OpenAI-compatible server：

vllm serve Qwen/Qwen2.5-1.5B-Instruct

常用的启动参数：

参数	作用	说明
--host	监听地址	线上常用 0.0.0.0
--port	服务端口	默认常见是 8000
--max-model-len	最大上下文长度	越大越吃 KV Cache
--gpu-memory-utilization	vLLM 可使用的 GPU 显存比例	太高可能 OOM，太低吞吐下降
--tensor-parallel-size	张量并行 GPU 数	多卡加载大模型时常用
--dtype	推理精度	如 auto、float16、bfloat16
--quantization	量化方式	AWQ、GPTQ、FP8 等要看模型支持
--api-key	API 鉴权	不能单独当完整安全方案，最好放反向代理后面
--enable-lora	启用 LoRA	多 LoRA 服务时用
--enable-auto-tool-choice	启用自动工具选择	tool calling 场景用

调用方式示例：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-1.5B-Instruct",
    "messages": [
      {"role": "user", "content": "解释一下 vLLM 是什么"}
    ],
    "temperature": 0,
    "max_tokens": 256
  }'

官方文档列出的 OpenAI-compatible API 包括 Chat Completions、Completions、Responses、Embeddings、音频转写/翻译等，具体能力取决于不同模型。

SGLang

SGLang 是一个面向 大语言模型和多模态模型 的高性能推理服务框架。它既能像 vLLM 一样把模型部署成 OpenAI-compatible API，也提供一套更偏“可编程 LLM workflow”的能力。

一、它和 vLLM 最大的区别

vLLM 更像一个成熟通用的 LLM server engine。
SGLang 更像一个 LLM runtime + prompt/workflow 编排框架。
也就是说，SGLang 的重点不只是“这次生成快不快”，还包括：

能力	意义
RadixAttention	复用共享前缀，减少重复 prefill
Structured Outputs	约束模型输出 JSON、regex、EBNF 等格式
Native /generate API	除 OpenAI API 外，也提供更灵活的原生接口
Frontend Language	用 Python 风格写多轮、分支、并行、选择等 LLM 程序
PD Disaggregation	把 prefill 和 decode 拆开优化，适合大规模服务
Multi-LoRA / MoE / Expert Parallelism	面向复杂生产和前沿模型部署

核心机制：RadixAttention

SGLang 最有辨识度的技术是 RadixAttention。它的核心目标是提高 prefix cache 命中率。
很多 LLM 请求会共享大量前缀，比如：

system prompt 相同
few-shot 示例相同
RAG 模板相同
agent 工具说明相同
多轮对话前半段相同

普通推理系统如果没有很好地复用这些内容，每次都要重新 prefill。
SGLang 会把这些可复用前缀组织成类似 radix tree 的缓存结构，让不同请求共享已经算过的 KV Cache。

概念	解释
Prefix	prompt 开头的一段相同内容
KV Cache	模型对上下文的中间计算缓存
Radix Tree	用来组织相同前缀的数据结构
RadixAttention	SGLang 用来复用共享前缀 KV Cache 的机制

推理过程

一次 SGLang 服务请求大概是：

用户请求
  -> OpenAI-compatible API 或 /generate API
  -> tokenizer / chat template
  -> scheduler 调度
  -> 查找 Radix Cache 是否能复用前缀
  -> prefill 阶段处理未缓存 prompt
  -> decode 阶段生成新 token
  -> structured output / tool parser 等约束
  -> 返回结果

这里要重点看两个指标：

指标	含义
#cached-token	本次请求命中的缓存 token 数
token usage	KV cache 池的使用情况

如果你的请求大量复用前缀，但日志里 #cached-token 很低，说明 prompt 构造、调度策略或缓存配置可能没吃到优势。

二、简单入门

sglang serve \
  --model-path qwen/qwen2.5-0.5b-instruct \
  --host 0.0.0.0 \
  --port 30000

• 调用示例:

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen/qwen2.5-0.5b-instruct",
    "messages": [
      {"role": "user", "content": "用三句话解释 SGLang 是什么"}
    ],
    "temperature": 0,
    "max_tokens": 256
  }'

• 常用启动参数

参数	作用
--model-path	模型 ID 或本地路径
--host / --port	服务监听地址和端口
--tp-size	tensor parallel，多 GPU 加载大模型时用
--dp-size	data parallel，吞吐型部署可关注
--context-length	最大上下文长度
--mem-fraction-static	分给模型权重 + KV cache pool 的显存比例
--max-running-requests	同时运行的最大请求数
--chunked-prefill-size	分块 prefill 大小，长 prompt OOM 时可调低
--schedule-policy lpm	提高共享前缀场景的 cache 命中机会
--quantization	量化方式，如 awq、gptq、fp8 等
--dtype	权重精度，如 auto、float16、bfloat16
--kv-cache-dtype	KV cache 精度，如 fp8_e4m3、bfloat16
--enable-lora	启用 LoRA adapter
--grammar-backend	结构化输出后端，默认常用 XGrammar
--enable-metrics	开启 Prometheus metrics
--api-key	简单 API 鉴权，生产建议放在网关/反代后面

• 结构化输出

SGLang 支持 JSON schema、regex、EBNF 等约束输出。这个能力适合 agent、工具调用、表单抽取、数据库写入等场景。

response = client.chat.completions.create(
    model="qwen/qwen2.5-0.5b-instruct",
    messages=[{"role": "user", "content": "返回中国首都信息，必须是 JSON"}],
    temperature=0,
    max_tokens=128,
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "capital_info",
            "schema": {
                "type": "object",
                "properties": {
                    "country": {"type": "string"},
                    "capital": {"type": "string"}
                },
                "required": ["country", "capital"]
            }
        }
    }
)

一些参数调试方案：

如果 prefill 阶段 OOM，优先调低 --chunked-prefill-size。
如果 decode 阶段 KV cache 满或并发过高，降低 --max-running-requests 或调整 --mem-fraction-static。
如果日志里 token usage 很低但队列很多，说明调度可能偏保守。
如果业务有大量相同前缀，试 --schedule-policy lpm，同时关注 metrics 里的 cache hit rate、TTFT、TPOT 和吞吐。