vLLM SGLang 对比：从前缀缓存到 GPU 成本，推理框架怎么选

vLLM SGLang 对比：你的负载该选谁？

常规部署默认选 vLLM；如果负载以共享上下文为主，优先测试 SGLang。 这个建议依据的是文档中的部署方式和缓存控制能力，并不意味着某个引擎在所有场景下都更快。

如果你要承载大量短对话，共享系统提示词值得作为评估 SGLang 的理由，但还不足以据此排除 vLLM：两者都能复用提示词计算。如果你正在创业，想上线一个简单的 API，又没有太多时间投入基础设施，就先用 vLLM。只有在服务表现或成本改善得到验证后，再考虑更换。

RAG，即检索增强生成，会把检索到的文档加入模型提示词。前缀缓存能否发挥作用，取决于提示词开头是否重复，而不是应用有没有贴上 RAG 的标签。

核验日期：2026 年 10 月 14 日。本次核验确认的最新稳定版本为 10 月 5 日发布的 vLLM 0.31.0 和 10 月 2 日发布的 SGLang 0.5.21。下文的功能说明以项目当时的在线文档为依据；实际使用时，请针对固定的版本验证所需功能组合。本文没有进行推理性能实测。

许可证信息已对照 vLLM 许可证和 SGLang 代码仓库核验。模型权重许可、基础设施和工程投入需要另行计算。这两个项目的开源引擎都没有可供直接比较的托管式按 token 计费价格。

两个引擎各自做什么，限制又在哪里？

vLLM：通用模型服务的默认起点

vLLM 是一个推理与模型服务引擎，负责加载模型权重，并根据硬件资源调度请求。 文档列出的核心机制包括连续批处理和 PagedAttention。连续批处理允许在已有请求完成时加入新请求；PagedAttention 则以块为单位管理模型的键值缓存，无需为每个请求预留一大段连续内存。KV 缓存保存注意力计算的中间状态，让模型继续生成时不必重新计算全部历史内容。vLLM 文档

选择它作为起点，是因为部署所需的组成部分很清楚：一个模型、一个官方服务镜像、一套 API，以及明确的平台安装说明。对正在搭建客服接口的产品团队而言，这是一套容易管理、也方便测量容量的基线。

它的限制在于：具体配置组合仍需验证。 GPU 在支持列表里只是第一步；模型架构、量化方式、注意力后端和所需功能必须能够协同工作。评测服务还要留意一个具体的缓存例外：vLLM 文档说明，请求如果要求返回提示词的对数概率，就会绕过前缀缓存，重新计算提示词。因此，即便使用同一份文档，评分接口的表现也可能与聊天接口不同。vLLM V1 指南

引擎费用为 $0。通用模型服务或混合硬件集群可以优先选它；如果现有 SGLang 部署已经满足服务目标，也没有缺失的必需功能，就不必为此迁移。

SGLang：重复智能体上下文值得优先评估

SGLang 是面向语言模型和多模态模型的开源推理框架，智能体负载是它明确关注的方向之一。 RadixAttention 围绕共享前缀组织可复用的提示词状态，HiCache 则在 GPU 缓存之后增加主机内存和存储层。它的实际吸引力在于，保留并复用多次请求中的上下文，有一套清晰的工具和文档可用。SGLang 代码仓库、HiCache 设计文档

设想一个智能体反复读取同一套客服政策，再根据不同客户的问题展开分支。相比一批只是并发量很高、提示词却互不相关的请求，这种场景更值得测试 SGLang。

它的限制在于缓存的共享范围，以及不同后端的功能差异。 HiCache 的 GPU 层和主机内存层归属于单个推理实例。只有选用的存储后端配置为共享用途时，存储层才会共享。扩大主机缓存，并不会自动得到一个全机群共享的缓存。增加层级，也意味着需要管理更多内存预算、数据传输和配置。HiCache 的共享范围

引擎费用为 $0。如果重复上下文的占比高到值得专门调优，可以选它；如果提示词很少共享完全相同的前缀，就不必仅因为应用叫“智能体”而更换引擎。

前缀缓存与 RadixAttention：为什么优先测试 SGLang？

面对反复复用上下文、存在分支的负载，SGLang 值得优先评估；vLLM 本身也已经具备关键的缓存能力。 这里不能把 PagedAttention 与“能否缓存”直接对立起来：PagedAttention 解决内存如何组织的问题，前缀缓存解决计算如何复用的问题。vLLM 的 Automatic Prefix Caching 明确覆盖了对长文档的重复提问和多轮对话。vLLM 前缀缓存

Prefill（预填充）是生成开始前读取提示词的计算过程；Decode（解码）是生成新 token 的过程。缓存命中可以省去重复的 prefill，但生成一份新回答所需的 decode 工作仍然存在。因此，如果输出很长、共享输入很少，两个引擎的前缀复用都可能收效有限。

对于短对话产品，只要模型要求的提示词格式允许，就把固定的政策和工具说明放在前面，把每次变化的请求内容放在后面。保持序列化方式和文档顺序稳定。靠近开头的时间戳一旦变化，后面原本完全相同的内容也可能无法复用。可以把它理解为一条共同路线：路径一旦分叉，后面即使出现相同的风景，也不代表前面走的是同一条路。

长上下文 RAG 还要多问一步：这些上下文是可以复用，还是仅仅很长？ 围绕一本内容不变的手册反复提问，非常适合缓存。而搜索产品如果每次请求都拼接不同片段、采用不同顺序，可能只能保留较短的系统前缀。在投入分层存储之前，应当分别测量这两类负载。

SGLang 文档说明，RadixAttention 默认开启，由 --disable-radix-cache 控制；HiCache 则需要额外配置。无论使用哪个引擎，都应检查实际生效的配置，不能仅凭项目名称推断缓存行为。SGLang 服务端参数

智能体功能：JSON 不分胜负，适配器与草稿方案需要实测

仅凭 JSON 输出需求，无法判定哪个引擎更好。 两者都支持受 Schema 约束的生成。让模型决定字段的值，同时约束输出结构，并在执行操作前验证结果。

结构化 JSON 输出

vLLM 通过 response_format 和 structured_outputs 选项支持 JSON Schema。SGLang 同样支持 JSON Schema，默认语法后端为 XGrammar。这些能力会约束解码过程，不只是给模型一句“请返回 JSON”的指令。vLLM 结构化输出、SGLang 结构化输出

以客服智能体为例，Schema 可以要求输出操作类型和工单标识，但无法确认工单是否属于发起请求的用户，也无法判断所选操作是否合理。这些校验应留在应用代码中。测试时，要把实际使用的 Schema、推理模式和流式输出放在一起验证；引擎分别支持每个功能，并不能证明组合起来就能正确运行。

结论：常规 JSON 需求打平。 除非有代表性的 Schema 请求暴露出明确差异，否则继续使用已经在运维的引擎即可。

推测解码

两个项目都把推测解码作为调优选项，但开启它不等于一定提速。 草稿机制先提出候选 token，再由目标模型验证。如果候选内容被有效接受，就能减少串行生成的工作；但生成草稿、验证草稿和占用内存本身也都有成本。

vLLM 文档列出了 EAGLE、多 token 预测、独立草稿模型、n-gram 和后缀方法。SGLang 文档也列出了 EAGLE、多 token 预测、草稿模型和 NGRAM 方案。相比功能表上有没有打勾，草稿与目标模型是否匹配、使用什么硬件、流量处于什么水平，更能决定实际效果。vLLM 推测解码方法、SGLang 推测解码方法

结论：优先选择已为你的模型验证过草稿方案的引擎。 先建立基线，再启用推测解码，比较响应延迟和总服务容量。如果生产负载下的收益抵不过额外开销，就保持关闭。

Multi-LoRA：为不同租户定制模型行为

两者都能提供多个 LoRA 适配器服务；这些小规模微调权重可以在共享基础模型上实现定制。 vLLM 通过 --lora-modules 注册适配器，并提供并发和秩的控制选项。SGLang 提供 --lora-paths 和 --max-loras-per-batch；文档中的默认值是每批 8 个适配器，这并不代表客户总数上限。vLLM LoRA、SGLang LoRA

如果写作产品需要为不同租户定制行为，应按预期的适配器使用分布进行测试，包括冷适配器和频繁切换。SGLang 的重叠加载选项可以隐藏传输开销，但文档也提醒，这可能削弱多适配器的 prefill 批处理效果，并增加首 token 延迟。配置开关更多，并不自动意味着容量更大。

结论：继续使用适配器方案已验证的引擎。 单凭 multi-LoRA 还不足以构成迁移理由。如果瓶颈是适配器加载行为，或负载高度依赖缓存，则值得试用 SGLang。使用 TPU 时，应以对应后端的功能矩阵为准：SGLang-JAX 指南仍将 multi-LoRA 标为开发中。SGLang TPU 功能矩阵

硬件支持：混合硬件集群优先从 vLLM 开始

两个项目都声明支持 NVIDIA、AMD、TPU 和 CPU，但实际支持边界取决于后端与模型的组合。 项目层面的硬件列表，不代表每套 GPU 部署配置、每种适配器或解码方法都能原样迁移。

• NVIDIA： vLLM 提供 CUDA GPU 安装文档；SGLang 的仓库列出了数据中心和 RTX 系列。所用版本的镜像必须与主机驱动兼容。vLLM GPU 安装、SGLang 硬件列表
• AMD： 两者都有 ROCm 部署文档。SGLang 列出了 Instinct MI300X、MI325X、MI350X 和 MI355X，并提供独立安装指南。应使用匹配的 ROCm 镜像和模型部署配置。SGLang AMD 指南
• Google TPU： vLLM 链接到独立的 tpu-inference 安装流程。SGLang 的 TPU 指南使用独立的 SGLang-JAX 后端，列出了 v6e 和 v7。这些都是单独的部署方式，需要分别核对功能支持情况。vLLM TPU 安装、SGLang TPU 指南
• CPU： vLLM 的 CPU 部署文档涵盖 Intel/AMD x86、ARM AArch64 等平台。SGLang 的 CPU 服务指南则明确面向第四代及更新 Xeon Scalable 处理器上的 Intel AMX。“支持 CPU”并不意味着两者覆盖范围相同。vLLM CPU 指南、SGLang CPU 指南

一个具体的运维差异，就可能决定下一次部署选谁：vLLM 0.31.0 除默认 CUDA 13.0 镜像外，还发布了 CUDA 12.9 镜像。SGLang 当时的安装指南要求 CUDA 13，并说明 CUDA 12 镜像系列停留在 0.5.19。 如果现有机群暂时无法升级到兼容的驱动环境，应先查清这一点，再比较吞吐量。vLLM 发布文件、SGLang 安装指南

兼容 OpenAI 的接口：客户端好迁移，完整业务仍要验证

使用 OpenAI 风格聊天补全接口的客户端，可以对接这两个引擎。 两者的文档都包含 /v1/chat/completions 和 /v1/completions，能减少应用接口层的改造工作。但这不代表每个端点、扩展、工具解析器或模型行为都可以互换。vLLM 服务接口、SGLang API

聊天模板负责把带角色标签的消息转换成模型预期的 token 序列。比较引擎时，要保持模板一致，否则你可能在不知不觉中比较了两份不同的提示词。模型修订版本、分词器、采样设置和输出上限也要对齐。

对于现有的 vLLM 客户端，迁移或升级前应检查旧的约束输出字段。文档说明，guided_json 及相关字段已在 0.12.0 中移除；当前代码应采用受支持的 structured_outputs 或 response_format 格式。过时的请求体很容易被误判为引擎不兼容。vLLM 迁移说明

结论：基础客户端接口打平；默认运维选型仍推荐 vLLM。 验收测试应覆盖完整的智能体交互轮次，包括流式工具参数、错误和重试，不能在成功返回一次文本后就结束。

在 GPU 云上部署 vLLM 和 SGLang

先固定容器版本，用小模型做冒烟测试，再换成生产模型和对应的内存预算。 以下示例根据项目文档中的 Docker 和启动命令改写，适用于已安装 Docker、NVIDIA 容器运行时和兼容驱动的 Linux NVIDIA GPU 主机。命令经过文档核对，但没有在租用 GPU 上实际执行。vLLM Docker、SGLang 快速入门

下方的 Qwen/Qwen3-0.6B 仅用于检查调用链路是否通畅，并不是针对智能体回答质量的模型推荐。两个引擎使用同一个端口，每次只运行其中一个。上下文上限是示例中明确设定的值，并非模型宣称的最大值。

vLLM 容器

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:v0.31.0 \
  --model Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 8192 \
  --enable-prefix-caching

SGLang 容器

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  lmsysorg/sglang:v0.5.21 \
  python3 -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 --port 8000 \
  --context-length 8192

初始化完成后，在 GPU 主机上运行以下请求：

curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [{"role": "user", "content": "Say hello."}],
    "max_tokens": 64
  }'

这些示例将主机端口绑定到回环地址。在向远程用户提供服务之前，应在服务前面接入带身份验证的应用网关。对 vLLM 尤其要注意这一点：其文档明确说明，--api-key 并不会为 HTTP 服务上的所有路由提供身份验证。vLLM 身份验证范围

Runpod 文档提供的 vLLM worker

Runpod 在 Hub 中提供了可直接部署、附带完整文档的 vLLM worker。 这条云端部署捷径，也是本文默认运维建议的依据之一。worker 的封装是独立的部署产物，应核对其中打包的引擎版本，不要默认它与上游最新版本一致。Runpod 部署指南

对于 SGLang，本文介绍的可复现云端部署方式，是在兼容的 GPU 主机上运行其官方容器。上面的 Runpod 捷径，特指 Runpod 文档中的 vLLM worker。

价格怎么比：相同 GPU 配置，账单相同

租用容量相同，两个引擎都不会天然更便宜。 2026 年 10 月 14 日，Runpod 在线价格页列出的 Pods 80 GB A100 PCIe 价格为 $1.79/小时。这是独占 GPU 的价格，并非 Serverless worker 的计费标准。下文使用它作为统一的基础设施成本输入。Runpod 价格

按每月 730 小时编制预算，持续配置一张 GPU，无论运行 vLLM 还是 SGLang，费用都是 $1,306.70/月；两张则是 $2,613.40/月。这些数字不含存储、网络、冗余和工程投入。

统一采用一组假设的客服负载：每月 50,000 次请求，每次包含 2,000 个输入 token 和 200 个输出 token。合计为 1 亿个输入 token，以及 1,000 万个实际交付的输出 token。如果一张 GPU 就能在规定响应时间内承载这组负载，那么两个引擎的 GPU 成本都是每 1,000 个实际交付的输出 token 花费 $0.13067。这里的分母是输出 token 数，但账单也包含读取输入的计算成本。

这只是成本计算，并非实测容量。如果一张 GPU 承载不了这组负载，上述单卡结果就不适用。

成本出现分野的时刻，是其中一种配置为了达到相同服务目标，必须增加一个副本的时候。如果 SGLang 需要一张 GPU、vLLM 需要两张，SGLang 就能节省 $1,306.70/月。如果实测容量关系反过来，vLLM 也能省下同样金额。如果两者都只需要一张，基础设施成本节省就是零。

假设迁移需要 8 小时，人工单价按 $100/小时估算，迁移成本就是 $800。减少一张上述 GPU，大约 0.61 个月即可收回这笔投入，尚未计入后续运维差异。如果既没有减少副本，也没有带来可计价的服务改善，“更快”可能完全没有财务回报。

价格上的赢家，是以更低总运行成本达到目标的配置。 在测出实际负载的安全服务容量之前，不能负责任地给出某个引擎专属的流量成本分界点。

吞吐量怎么测：看延迟达标时能完成多少有效工作

本文没有得出适用于所有场景的吞吐量赢家。 项目方发布的结果，只对应其使用的模型、硬件、精度、请求长度和版本。内核性能提升不等于端到端服务性能提升，prefill 吞吐量也不等于输出 token 吞吐量。不能据此笼统地断言“SGLang 更快”或“vLLM 更快”。

可以从项目自带的工具入手：vLLM 基准测试 CLI 和 SGLang 服务基准测试指南。对比既要覆盖热缓存和冷缓存，也要体现产品实际产生的负载形态。

分别测量四类场景：共享稳定系统提示词的短对话；围绕同一篇长文档反复提问；检索片段不断变化的长 RAG 提示词；以及业务中实际混合使用的 Schema、工具调用和适配器。除并发量外，还应保留请求到达的时间特征。同时涌入的突发请求与平稳持续的请求流，可能暴露不同的瓶颈。

记录完成的请求数、实际交付的输出 token 数、错误和首 token 延迟。同时检查 p95 和 p99 延迟，即第 95 和第 99 百分位，因为漂亮的平均值可能掩盖严重的长尾延迟。未通过应用 Schema 或正确性校验的输出，应计为失败，不能算作有效服务容量。

在这些验收条件内持续达标、且成本最低的部署才是赢家。其他模型或旧版本上的速度优势，只是值得进行这次对比的理由，并不是这次对比的答案。

如何切换引擎：保持接口约定，保留回滚路径

只有实测收益超过迁移和运维成本，才值得更换模型服务层。 如果只替换生成后端，应用数据和检索存储通常可以留在原处。迁移工作主要集中在模型封装、请求扩展、输出解析和部署行为上。

不要为了获得前缀缓存或 JSON 约束，就替换运行良好的 vLLM 部署：它已经具备这两项能力。同样，也不要仅因为本文默认推荐 vLLM，就替换运行良好的 SGLang 部署。团队已有的运维经验，也是成本比较的一部分。

如果还没确定是否需要共享的生产模型服务，可以先读 Ollama 与 vLLM 对比。那篇文章讨论的是更前一步的选择：采用方便的本地模型工作流，还是搭建能处理并发请求的模型服务层。

下一步，采集有代表性的峰值流量，设定可接受的响应时间和错误率上限，然后在同一套硬件上对比固定版本的两个引擎，再决定是否扩容。

常见问题

使用 AI 业务工作流审查清单，判断哪项工作流值得部署共享模型服务，并订阅邮件，跟进后续工具变化。