⚠️ 法律与用途声明:本文基于在 RTX 5090 笔记本上实际部署 vLLM 与 SGLang 的工程实践,属于经验分享与技术讨论。性能数据来自社区单点实测加本机验证,非普适结论;引用的 issue/PR 版权归各自项目方所有。读者须遵守所在地区法律法规。
本篇文章只聊一个场景:RTX 5090 笔记本,24GB 显存,sm_120。不聊数据中心 B200,不聊 H100,也不聊"理论上谁吞吐更高"。因为消费级 Blackwell 这张卡,和它的数据中心兄弟几乎是两套架构——共享一个品牌名,内部差着代。
两套引擎我都在这台 5090 笔记本上实际部署跑过,踩了不少坑。这里把踩坑过程和最终判断整理出来,给同样想在消费级卡上搭推理服务的同学一个参考。所有对比都落在这张卡的工程现实上:显存只有 24GB,带宽只有桌面版约六成,却要同时养活 LLM、VLM、embedding、甚至 ASR/TTS。在这个战场里,比的不是"谁跑得更快",而是"谁把 sm_120 的坑填得更快""谁让 24GB 能装下更多模型"。
所以不堆跑分,不罗列 feature,而是从架构设计、24G 实战、生态、趋势、国产平台五个维度,讲讲实际部署下来谁的坑更少、谁更顺手。每个维度给判断,不给"各有千秋"。
一、架构顶层设计:两种推理哲学
两个框架的差异,根子在设计哲学,不在 feature 列表长短。
vLLM 的气质是做 LLM 推理界的 Linux 内核——通用 serving 引擎,插件化,先把底座做厚。2026 路线图围着几件事转:model runner V2 默认开启,带来 dual batch overlap(双批重叠)、piecewise CUDA graph(分段图捕获)、pipeline parallelism、更多 attention backend;async scheduling 默认开;进程结构扁平化。它自己也坦承,目前只对 LLM/AsyncLLM/LLMEngine 保证向后兼容,其余零保证——而建立一个稳定的 model implementation API,正是要改的,因为这是插件生态的前提。背后还有两个特别兴趣组(SIG)在推:torch.compile SIG 做 vLLM IR、Helion 集成、编译缓存;量化 SIG 想取消显式的 --quantization 参数,搞一个单一真相源的 dispatch oracle(调度预言机)。
这些词看着吓人,拆开都好懂。model runner V2 是把"跑一个模型"这件事抽象成独立单元,方便塞新特性;piecewise CUDA graph 是把 GPU 操作分段"录"下来重放,省调度开销;dispatch oracle 的意思是,以后你不用手动指定量化方式,框架自己根据模型和硬件挑最合适的。一句话:vLLM 想让你少操心,把决策收进内核。
SGLang 的内核是 RadixAttention 加一个可编程前端,前缀树缓存是它的一等公民,不是事后打补丁。通俗解释一下 RadixAttention:你把所有请求共享的前缀(比如同一段 system prompt、同一套工具定义)挂在一棵 Radix 树上,谁来了先查树,命中就直接复用 KV,不用重算。这对多 Agent 共享 prompt 是结构性优势。2026 Q2 它的方向是 scheduler 往 stateless 重构,全栈渐进式 Rust 化(scheduler、API server、prefix tree 重写,还有原生 gRPC server 的 RFC),并明确写进了"支持 agentic workload 的灵活 session 控制"和面向 agentic 的分布式 KV cache 系统。
再看它另外两个动作。stateless scheduler,意思是调度器不持有请求的长期状态,方便水平扩展和故障恢复——这是为集群设计的。全栈 Rust 化(scheduler、API server、prefix tree、原生 gRPC),是为了拿更高的并发和更低的延迟。这些设计在单卡 24G 上你用不到全貌,但能看出它的野心:它是冲着"成百上千个 Agent session 同时跑"的明天去的。
把哲学差异翻译成一句话:vLLM 赌的是"推理是通用基础设施",要的是内核稳、生态厚、插件多;SGLang 赌的是"未来推理会 Agent 化、多模态化、session 化",前缀树和 stateless scheduler 都是给这个未来铺路。两个赌注都没错——只是你这张 24GB 的卡,暂时只站在 vLLM 的赌注这一边。
需要补一句公允话:vLLM V1 之后,prefix caching 已经接近零开销,和 SGLang 在前缀复用上的差距在快速收窄。SGLang 的结构性优势依然在,但"前缀缓存"本身,已经不再是它独占的护城河。
二、24G 实战:踩的坑比跑分重要
哲学归哲学,落到 5090 笔记本上,得看谁先把 sm_120 的坑填了。直接用 GitHub issue 当证据锚点。
SGLang 这边,坑偏"自己绊自己"。 issue #14814:5090 上跑 Qwen3-VL,自动后端选择判定 is_blackwell() 为真,挑了 trtllm_mha,随后 SM 版本检查抛错——默认路径写死了"Blackwell 即 sm100"的假设。issue #9233:sm_120 上 block FP8 缺失,FP8 权重模型跑不起来,提 issue 的人点名 vLLM 已在 PR #22131 实现,盼着 backport。issue #31578:还在为 flash_mla_sparse 申请原生 sm_120 支持。我实测下来,v0.5.2 起 SGLang 确实能在 5090 上跑起来,但属于"能跑",离"默认即最优"还差不少。
vLLM 这边,坑偏"入口"。 issue #35432:PyPI 预编译 wheel 没带 SM120/121 的 arch flag,加载就报 no kernel image is available。解法明确——别用 PyPI wheel,改用 vLLM 官方 wheel server 或 cu130 官方镜像。我踩这个坑的时候绕了半天,后来发现一个绕路就解决,但你得知道要绕。
再看一组性能阶梯。先交代来源:这是 2026 年 4 月的社区单点实测,我在自己机器上做了交叉验证,硬件 5090 Laptop 24GB / sm_120 / 约 896 GB/s / 175W TDP,模型 Qwen3.6-27B。社区帖质量较高、评论区有交叉验证,但仍是单点,不是普适结论。
| 方案 | t/s |
|---|---|
| llama.cpp(最佳 NVFP4 GGUF / UD-Q4_K_XL) | 33–36 |
| vLLM v0.17 NVFP4,无 MTP | 39 |
| vLLM v0.19.1 NVFP4 + MTP n=1 | OOM |
| vLLM v0.19.1 + Lorbus AutoRound + MTP n=1 | 65 |
| vLLM v0.19.1 + Lorbus AutoRound + MTP n=3 | 85–100(峰值 99.7) |
这组数字里藏着一个反直觉:移动版 5090 带宽只有桌面版约六成(896 vs 1500 GB/s),配对了却能冲到 99.7 t/s——靠的不是算力,是 MTP(speculative decoding 的一种),接受率预热后到 92–95%。
翻译一下:同一张移动版 5090,配错量化 39 t/s,配对了 99.7,差出两倍半。这把"配对"的钥匙不在引擎,全在那几个坑里。我在这个环节花的调试时间,比前面所有架构分析加起来都多。下面只拎最关键的三个坑,因为它们直接决定 24G 能不能跑起来。
量化别选 NVFP4,选 Lorbus AutoRound INT4。 NVFP4 把 mtp.fc 一起量化了,vLLM 加载得现场开 2.37 GiB 的 BF16 buffer,24GB 直接 OOM;AutoRound 在文件层把 MTP 头反量化成 BF16(约 280 MiB),vLLM 直接读盘。代价是走 Marlin kernel 而非原生 NVFP4 张量核,但带宽受限的移动卡上,MTP n=3 的收益远大于那点算力损失。这个坑我也是 OOM 了两回才摸清楚。
PR #36325(Blackwell TMA 修复)近乎必需,但状态存疑。 is_tma_supported 对所有 CC>=9 返回 True,可消费级 Blackwell 不真支持 TMA,descriptor buffer 会撑爆显存。必须如实说:这个 PR 当前有 merge conflict,关联 PR 已被关闭,不是"打上就好"的稳定方案,得自己 cherry-pick、自己验证。我打了之后确实能跑,但每次升级 vLLM 都得重新合一遍,心里不太踏实。
真实 KV 池只有 23,760 token(3.24 GiB)。 --max-model-len 75000 靠 chunked prefill 对超出部分重算,不是真有那么多 KV。对 Agent,工具输出累积超过 23K,TTFT 会超线性上涨——这是 24G 的真天花板,和选哪个引擎无关。实测连续对话超过 20 轮工具调用后,响应延迟会明显感觉到"变沉",根子就在这。
到了实际使用的场景,有一项能力近乎决定胜负:Sleep Mode(vLLM 侧)。它分两级:level 1 把权重卸到内存、丢弃 KV;level 2 连权重一起丢。控制就两条 HTTP——POST /sleep?level=1 和 POST /wake_up,还支持 tags=weights / tags=kv_cache 细粒度唤醒。我在自己的部署里写了 orchestrator 按需切模型:LLM 跑完了 sleep,几秒后 wake VLM,再几秒后 wake embedding——而不是重启服务干等 30 到 100 秒。起服务加 VLLM_SERVER_DEV_MODE=1 和 --enable-sleep-mode 即可;安全提醒——这些端点别暴露到局域网外。SGLang 这边目前在单卡 24G 上,还没有对等成熟的多模型睡眠/唤醒组合。
公平地说,SGLang 的 prefix tree 在多 Agent 共享上下文时,能让显存用得更省(共享的部分不重复存)。但"按需把整个模型睡着再秒级唤醒"这种实际使用中的刚需,目前 vLLM 的 Sleep Mode 更顺手。这又是两条路线的差异:vLLM 补的是"单机多模型切换",SGLang 长在"多 Agent 共享常驻"。
三、生态与成熟度:底盘厚 vs 声量响
这一节回答"敢不敢托付生产"。规模上,vLLM 由 PyTorch Foundation 托管,46.5k+ stars、1000+ 贡献者;SGLang 由 LMSYS 主导,增长极快,中文核心贡献者密集(BBuf、fzyzcjy、Lianmin Zheng 等)。
| 维度 | vLLM | SGLang |
|---|---|---|
| 托管方 | PyTorch Foundation | LMSYS |
| 体量 | 46.5k+ stars,1000+ 贡献者 | 增长快,中文贡献者密集 |
| 企业渗透 | 深,招聘市场硬通货 | 起势中 |
| 社区温度 | 稳,资料密度高 | 热,知乎/Slack 更新勤 |
| RL/多模态 | 路线图挂名(vLLM Omni) | 碾压性领先 |
社区温度上 SGLang 更热:Slack 细分到 #spec-decoding、#pd-disaggregation,给长期活跃贡献者发 coding agent 赞助(Cursor / Claude Code / Codex,联系 sglang@lmsys.org);LMSYS 在 2026-07-02 发了 agent-assisted SGLang development 博客,把内部 agent skills 开源。vLLM 则是企业侧底盘更稳,"会调 vLLM"在招聘市场是硬通货。
我自己踩坑找方案的时候,vLLM 那边资料密度明显更高,几乎每个报错都能搜到前人的解法;SGLang 那边在消费级单卡场景的资料还比较稀疏,不少问题得自己去 Slack 问。但对个人玩家,SGLang 的 Slack 和公众号是淘金好去处,踩坑能很快找到同路人。真到要交付的团队,vLLM 的资料密度和稳定性更让人睡得着觉。
四、发展趋势:各赌一个未来
把时间轴拉长看,两个框架其实是在赌两件不同的事。
vLLM 往"通用底座"深挖。model runner V2、async scheduling、进程扁平化,都是为了把内核做厚做稳;torch.compile SIG 和量化 SIG(dispatch oracle)在把"编译"和"量化选择"变成框架内部自动决策,让使用者少操心。它的多模态牌(vLLM Omni)目前还只在路线图上挂着个名字。
SGLang 往"Agent 与多模态的原生主场"长。差异化在 SGLang-Omni(Qwen3-Omni 的 Thinker-Talker、Fish Audio S2 Pro)、diffusion 和多模态生成上投入。RL 生态更是碾压性领先:Miles、slime(清华)、verl(字节)、AReaL(蚂蚁/清华)都把 SGLang 当一等公民 rollout backend。它的 stateless scheduler、Rust 化、分布式 KV,都是奔着集群规模的 agentic 负载去的——设计瞄准的是明天,不是今天。
从选型角度看,这意味着你得选"你相信哪个未来"。如果你的系统是"一个常驻模型 + 大量工具调用 + 单用户长上下文",今天的主场在 vLLM;如果你瞄准的是"集群规模、多 Agent session 共享、多模态交织"的明天,SGLang 的设计更对路,只是 24GB 单卡短期摸不到它的主场。
一个判断:SGLang 的设计先进性是真的,但它兑现的主场在集群。如果你只有一张 24G 的消费卡,这些先进性大部分还在"看得见摸不着"的阶段。这不是 SGLang 的错,是场景和野心的错位。
五、大陆与国产平台:两条都通,路径不同
国产硬件这条线值得单独看,尤其对国内团队。
昇腾这边,vllm-ascend 是 vLLM 官方 project 下的社区维护插件,文档已经进了 docs.vllm.ai,版本紧跟上游(2026 年 7 月已对齐 v0.23.0);SGLang 则是原生支持昇腾,新模型免改代码拉起,还推出了兼容 DeepEP 北向接口的大 EP 推理加速库。两条路都通,一个走"插件跟随上游",一个走"原生集成",风格和它们在 CUDA 上的哲学一脉相承。
此外,阿里云 CAP 文档里有官方 Qwen 系列的双框架性能对比,可以直接拿来参考;GPUStack 提供两者的统一部署入口,适合不想二选一、想在一个面板里管两套引擎的团队。对国内开发者,这两条国产路径意味着:无论主力选谁,昇腾卡都不至于让你重新选型。
从部署落地的角度看,如果你在做面向国内市场的产品,把推理栈同时和 vLLM、SGLang 两条昇腾路径都验证一遍是值得的。今天 CUDA 上的差距,在昇腾上未必同样成立;国产硬件的适配进度,有时会让两个框架的优劣排序重新洗牌。
六、5090 laptop 24G 选型决策
把上面所有维度收束到这张卡上,结论很明确:主力上 vLLM,把 SGLang 装成第二引擎做 A/B。
理由不是性能(单用户场景下,两引擎的差异会被 Agent 逻辑本身的开销淹没),而是三条工程现实:sm_120 的坑,vLLM 填得更快更全;Sleep Mode 对实际使用场景近乎决定性,而它是 vLLM 的强项;踩坑资料的密度,SGLang 那边在消费级单卡上差一个数量级。
落地清单给三条。模型别只盯 27B 稠密,认真看 Qwen3 系 MoE(比如 A3B 这类低激活参数),移动版 5090 带宽只有桌面版六成,MoE 的低激活量是结构性利好。量化优先 AutoRound INT4,除 MTP 那个 OOM 理由外,社区 KLD 对比显示它在工具调用和结构化输出上显著优于朴素 Q4_K_M、接近 fp8,而 Agent 对这两项最敏感。上下文走双端点:64–75K 加 MTP 的快端点跑交互,关掉 MTP 的长上下文端点跑文档,配合 prefix caching 和周期性 summarize-truncate。再盯一眼 TurboQuant(Hadamard 旋转实现近无损 INT4 KV cache),PR #40108 / #40092 现在还停滞,一旦落地 75K 能直接翻倍。
再补一句给犹豫"要不要直接上 SGLang"的朋友:不是 SGLang 不好,是它在 24G 单卡这个场景,还没把力气使完。把它装成第二引擎跑 A/B,等它把 Sleep Mode 对等能力和 sm_120 适配补上,再重新评估——选型本来就该是动态的。
七、别信跑分,包括这篇
方法论这节,分量比结论重。别信任何第三方 benchmark,包括这篇引用的。公开评测的数字几乎全部产自 H100/H200/B200 的多并发吞吐场景,和你"单用户、长上下文、大量工具调用、模型常常驻但间歇使用"的实际负载,近乎正交。
你真正该测的是:拿自己的 Agent trace 回放,看 TTFT 的 p95(不是均值)、prefix cache 命中率、tool call 格式成功率,以及连续跑 72 小时之后的显存碎片与稳定性。这一项在消费级卡上翻车概率远高于预期,而且没有任何人会替你测。
所以留个开放问题给你:你自己的 Agent trace,p95 TTFT 是多少?这个数,比上面五个维度的对比都更能告诉你该选谁。
时间:2026-07-29 | 文档版本:v2.1.0
本文为在 RTX 5090 笔记本 24GB / sm_120 上实际部署 vLLM 与 SGLang 的工程实践记录。性能数据来自社区单点实测加本机验证,非普适结论;PR #36325 等状态存疑项请自行验证;引用的 issue/PR 版权归各自项目方所有。评论区欢迎拍砖与补充实测。
参考来源
[1] vLLM issue #35432 — PyPI wheel 未带 SM120/121 arch flag https://github.com/vllm-project/vllm/issues/35432
[2] vLLM PR #22131 — sm_120 block FP8 实现 https://github.com/vllm-project/vllm/pull/22131
[3] vLLM PR #36325 — Blackwell TMA 修复(状态存疑,需自行验证) https://github.com/vllm-project/vllm/pull/36325
[4] vLLM PR #40108 / #40092 — TurboQuant INT4 KV cache(停滞) https://github.com/vllm-project/vllm/pull/40108
[5] SGLang issue #14814 — is_blackwell 误判 trtllm_mha https://github.com/sgl-project/sglang/issues/14814
[6] SGLang issue #9233 — sm_120 block FP8 缺失 https://github.com/sgl-project/sglang/issues/9233
[7] SGLang issue #31578 — flash_mla_sparse 原生 SM120 支持申请 https://github.com/sgl-project/sglang/issues/31578
[8] LMSYS 博客:agent-assisted SGLang development(2026-07-02) https://blog.lmsys.org
vLLM 官方 wheel server、cu130 官方镜像、vllm-ascend、GPUStack、阿里云 CAP 双框架对比文档,可在各自官网按名称检索,本文不逐一附链以避免链接失效。