24GB 显卡的极限玩法：SGLang 部署激进量化的 Qwen3.8-27B，128K 上下文实测

[teaikeji]

一张 RTX 3090 要塞下 27B 模型、128K 上下文，还要保住推理质量，量化要压到什么程度？这篇文章记录了一次把”省显存”做到极致的部署实战——连 embedding（模型的”门面”）和 lm_head（模型的”出口”）都量化了。为了让这套激进量化在 SGLang 上真正跑起来，我不得不给推理框架打了三个补丁，其中两个已经以 PR 形式提交给上游。

一、为什么值得较真

先看算术题：一张 RTX 3090 有 24GB 显存，而 Qwen3.8-27B 的 BF16 原始权重要占 54GB，两张卡都塞不下。本地跑，量化是唯一的路。

但量化还有道隐形算术题：权重每省下 1GB，都能变成几十万 token 的 KV 缓存，也就是更长的上下文。显存就是上下文，上下文就是模型的天花板。

常规 W4A16 量化能把 27B 压到 19GB 左右，剩 5GB 给 KV 和运行开销，大概 8 万 token 上下文。这已经不错了，但还不够。于是有人开始动心思：那些”看起来”不该量化的地方，是不是也能省？

二、两个主角

SGLang：斯坦福 NLP 团队（后来独立成项目）开发的高性能推理框架，核心卖点是 Radix Attention（前缀复用）、Cuda Graph（图捕获）、连续 batching。它和 vLLM 是本地部署大模型的两大主力，SGLang 在前缀缓存和 MoE 调度上更激进。对 24GB 单卡玩家，SGLang 还有个关键价值：显存预算拆解得极其透明——权重、KV 池、Mamba 缓存、运行余量各占多少，启动日志里写得明明白白，可以像查水电表一样逐项优化。

Qwen3.8-27B：Qwen 家族里”能效比”极高的一款——27B 体量、接近满血 32B 的推理能力，靠 MoE 稀疏结构在单卡上跑得动。上一轮横评里它 27B 级别没有对手：MLM U-Pro 85.63 分，比 Nemotron 的 81.94 高一大截，模型还更小。所以问题聚焦成一个：怎么把 Qwen3.8-27B 压进 24GB，并把上下文顶到最大。

三、激进量化：连”门面”和”出口”都不放过

传统 W4A16 有个心照不宣的默契：主干压到 4bit，但 embedding 和 lm_head 保持 BF16。理由：embedding 是”门面”（token 变向量），lm_head 是”出口”（向量变概率），量化它们被认为会伤精度。

但”省显存”的诱惑太大。这两层加起来占总权重的 5%~10%，在这张卡上就是 3~4GB，省下来等于把上下文从 10 万顶到 12 万以上。

于是有了 born2bewild/Qwen3.8-27B-W4A16-AutoRound-fast 这个模型（技术原创来自 syvai 团队，born2bewild 是整合成单仓发布的打包者）。量化方案：

• 主干：W4A16 AutoRound（业界公认最无损的量化算法之一）
• lm_head：INT4，group128，GPTQ 校准
• embedding：INT8
• MTP（多 token 预测）头：INT4
• delta / GDN 线性注意力层：保留 BF16

整包只有 15.81GB，比 RedHatAI 官方量化版（约 19GB）净省 3.6GB。官方给的精度数据：perplexity 只增加 0.6%，GSM8K 数学成绩不变。相当于把”装修”全拆了重做，但承重墙一根没动。

四、部署实战：碰壁才是常态

下载下来启动 SGLang，迎面一堵墙：SGLang 不认识被量化的 embedding 层。启动能过、KV 池也能建，但一推理输出全是乱码。原因：SGLang 的 compressed-tensors 量化支持只覆盖 transformer 里的 Linear 层，embedding 和 lm_head 这两个”非标准”层压根不在量化处理名单里。配置里写着”embedding INT8、lm_head INT4″，框架却按 BF16 读权重，读到的是一堆压缩比特流，自然输出垃圾。

这是典型的”模型能力跑在框架能力前面”的错位。模型都这么新了，框架还没跟上。

解法不是绕路，而是给框架补齐能力。我打了三个补丁：

• 补丁一：让 SGLang 识别并正确反量化 INT8 的 embedding
• 补丁二：让 SGLang 识别并正确反量化 INT4 的 lm_head
• 补丁三：修掉配置里 quant_config 缺失导致链路断掉的框架原生 bug

其中补丁三是框架的原生 bug，补丁一、二是能力扩展。能力扩展的代码我严格对齐 vLLM 官方合并的 kernel 语义，并用独立 oracle 验证了 INT8/INT4 两种 group128 布局的反量化逐字节一致（max_diff=0）。两段对照测试代码（一个 INT8、一个 INT4）连同三个补丁，以 PR 形式提交给了 SGLang 官方仓库：

PR #36137：feat(quant): support compressed-tensors quantized lm_head and embed_tokens，Files changed 页签能看到全部改动，共 236 行。官方合并前，你也可以按同样思路本地打补丁。

五、测试数据：省下的显存全变成了上下文

补丁打完重启容器，数字全部兑现：

• 上下文：从 10 万冲到 12.8 万，context-length 直接设到 131072（128K）
• KV 缓存池：165,318 tokens（对比 RedHatAI 量化版的 104,845）
• 显存分布：权重 15.36GB + KV 缓存 + Mamba 缓存 + 运行余量，24GB 井井有条
• 速度：中等长度输出实测 47.3 t/s，和 RedHatAI 量化版（约 46 t/s）完全持平——3.6GB 显存是”白捡的”，速度一分没少
• 质量：和 RedHatAI 版（lm_head 保持 BF16）做同题对比，代码生成（快速排序）、数学推理（组合数）、中文写作，三组都一致。lm_head 的 INT4 量化在真实任务上没有任何可感知的退化

最终生产配置：GPU0 跑 born2bewild（128K），GPU1 保留 RedHatAI 做对照与冗余，两张 3090 各司其职。

六、推荐结论

• 强烈推荐给：24GB 单卡、上下文需求大于 10 万 token 的用户——这是目前唯一能把 27B 顶到 128K 且质量无损的路径；长文档、长代码仓库、agent 多轮工具调用场景——上下文是硬约束，多 2 万 token 就是质的区别；愿意花半天打补丁跟上游的用户——回报率极高
• 不建议：对 embedding 量化有洁癖、追求”官方原教旨”的（RedHatAI 官方版同样优秀，只是上下文少 2 万）；纯聊天、上下文需求不高的（省下的显存对你没价值，不必折腾）

三句掏心窝的话：

• AutoRound + 激进量化是本年度 24GB 单卡的最大红利，同时解决了”能不能跑”和”能跑多大”
• lm_head/embedding 量化是大趋势，vLLM 官方已合并 NVFP4 embedding 量化先例，主流框架都在往这走
• “框架跑在模型前面”会越来越常见，遇到这类问题，敢给上游提 PR 是性价比最高的解决方式

补一句：我的 PR 还在 open 状态等官方评审。生产环境用请务必先本地验证（好在补丁改动小、可读性高）。一旦官方合并，这套方案就能开箱即用。

七、方法论沉淀

这次部署是一次”显存预算链”的完整实践：先算清每 MB 去向，再找最大可压缩项，动手压缩，最后用数据验证没付出代价。

• 先预算后动手：权重、KV、缓存、余量逐项列出，找到瓶颈再优化
• 量化到头发丝，但承重墙不动：主干无损、门面激进、敏感层保护
• 框架跟不上就给框架打补丁：与其绕路，不如把能力补回框架本身
• 所有优化必须用数据兑现：省了显存，还要证明速度没掉、质量没伤

每压榨出 1GB 显存，都是在给模型买回几千字上下文。把这件事做到极致时，那张 3090 上跑着的已不只是模型，而是一整套”显存经济学”。

本文所有测试数据均来自双 RTX 3090（24GB）实机部署实测。PR：github.com/sgl-project/sglang/pull/36137。模型：huggingface.co/born2bewild/Qwen3.8-27B-W4A16-AutoRound-fast。

[作者]

帖子