同一张5090跑Qwen 27B，vLLM只能开约32K上下文、SGLang快近三倍但都给不了完整262K窗口，软件栈的选择比多买8GB显存更能决定“能不能用”？

在单卡RTX 5090（32GB GDDR7）上部署Qwen3 27B级模型时，vLLM默认配置往往只能稳定开出约32K上下文，SGLang在相近精度下吞吐可高出近三倍，但两者都难以直接兑现模型标称的262K原生窗口。这一现象常被误读为“显存不够”，而本文要论证的是：真正决定“能不能用”的，是软件栈对KV Cache的分配粒度、调度策略与注意力后端的组合选择。

摘要与阅读导引

围绕“单卡大模型到底能开多长上下文”这个问题，工程社区长期存在两类叙事。一类把瓶颈归因于硬件：显存容量、显存带宽、算力峰值。另一类把瓶颈归因于模型：参数量、注意力头数、GQA分组比例。这两类叙事都成立，却都不足以解释一个反复出现的现象——同一张卡、同一个模型权重、同一套量化方案，仅更换推理框架，可服务的上下文长度与并发吞吐就会出现数倍差异。

本文以RTX 5090（32GB GDDR7，Blackwell架构，支持FP4/FP8张量核心路径）为载体，以Qwen3系列27B级稠密模型为对象，沿着“显存预算守恒”这一条主线展开。核心命题是：上下文窗口不是模型属性，而是模型属性、硬件容量与软件栈策略三者联立方程的解。vLLM的PagedAttention与SGLang的RadixAttention分别代表了两条不同的求解路径，它们在短上下文高并发场景下趋同，在长上下文场景下分叉，而分叉点恰恰是多数部署事故的发生地。

全文结构如下：第一章定义问题边界并给出可复现的显存预算模型；第二章拆解KV Cache的分配机制与两套框架的实现差异；第三章讨论注意力后端、量化与并行策略如何改变可行域；第四章给出分场景的调优路径与验证方法；第五章做横向对比并明确局限；第六章给出结论与前瞻判断。文中所有数值均标注来源或标注为模拟估算，读者可据此复算。

一、问题定义：32K、262K与“三倍”分别意味着什么

1.1 三个数字的语义澄清

讨论开始前必须先做语义澄清，否则后续所有比较都会失焦。“32K上下文”在vLLM语境下通常指单请求可稳定服务的最长输入加输出token数，它由启动时按--max-model-len显式声明，并直接参与KV Cache块数的静态预算。“262K”则是Qwen3系列部分模型在训练阶段声明的原生上下文长度，属于模型能力上界，不等于部署可行域。“快近三倍”是吞吐量（tokens/s）层面的观测，必须绑定具体的工作负载形态——输入长度分布、输出长度分布、并发数、是否命中前缀缓存——否则不可比。

本文评述：把这三个数字并列，容易制造一种“软件优化能凭空变出显存”的错觉。更准确的表述是，软件栈决定了在给定显存下如何切分预算、如何复用已有计算、如何拒绝不可服务的请求。它不能突破物理上界，但能把“可用区间”从物理上界的很小一部分，推进到接近上界的位置。这个推进幅度，在单卡场景下往往大于从32GB升级到40GB所带来的收益。

1.2 为什么单卡场景会把矛盾放大

多卡部署时，张量并行（TP）会把KV Cache按头维度切分到各卡，单卡压力下降；同时流水线并行（PP）可进一步分摊层间激活。单卡部署没有这些缓冲，全部权重、全部KV Cache、全部激活与临时缓冲区都要挤在同一块32GB显存里。RTX 5090的32GB在消费级中已属宽裕，但对27B级模型而言，权重本身就占据可观份额：FP8下约27GB量级，INT4/FP4下约14至16GB量级（含嵌入与归一化层开销，具体取决于量化方案与是否量化lm_head）。

这意味着在FP8路径下，留给KV Cache与激活的空间可能只有数GB；在FP4路径下可释放到十余GB。这一差异直接决定了上下文上限的量级。笔者在多个社区复现记录中观察到，同一模型在FP8与FP4两条路径下的最大可服务上下文相差可达三到四倍，而吞吐差异反而没有这么剧烈——这提示我们，量化精度的选择首先是“窗口开关”，其次才是“速度开关”。

1.3 一个必须承认的前提：262K未必是目标

工程实践中，把262K当作默认目标是常见的误判。长上下文带来的首token延迟（TTFT）增长、注意力计算的二次复杂度、以及“中间信息丢失”（lost in the middle）现象，都会削弱超长窗口的实际价值。已有系统性评测指出，多数模型在超过训练分布中位长度后，长文检索与多跳推理的准确率会显著下滑。因此本文的立场是：先确定业务真实需要的上下文分位数，再倒推显存预算，而不是反过来追求标称上界。

本文评述：这一立场并非保守，而是把优化目标从“最大值”改为“可服务分位数”。对于代码仓库级理解、长文档摘要、多轮agent轨迹等场景，真实需求常落在64K至128K区间；把资源集中保障这一区间的稳定性与吞吐，比勉强支撑极少数262K请求更符合工程经济学。

二、显存预算守恒：一条可复算的主线

2.1 预算方程

把单卡显存视为一个封闭预算，可写出如下守恒关系（单位统一为GiB，模拟估算框架，读者可按实际权重替换）：

M_total = M_weight + M_kv + M_act + M_frag + M_reserved

M_kv   = 2 × L × H_kv × D_head × S × B × bytes_per_elem
       = 2 × L × (H / G) × D_head × S × B × bytes_per_elem

其中：L 层数，H 注意力头数，G 分组数（GQA），D_head 头维度，
      S 序列长度，B 批大小，系数2对应K与V两份缓存。

该式揭示了一个常被忽略的事实：KV Cache对序列长度是线性的，对批大小也是线性的，两者相乘。因此“长上下文”与“高并发”在单卡上是直接竞争关系，不存在同时最大化的解。vLLM与SGLang的差异，很大程度上体现在它们如何在这个乘积空间中做取舍与复用。

2.2 逐项拆解与量级估算

以Qwen3 27B级稠密模型为例，典型结构参数为层数约64、注意力头数约40、GQA分组约8、头维度128。按此估算单token单层的KV元素数为 2 × 8 × 128 = 2048 个元素。全模型单token为 2048 × 64 ≈ 131072 个元素。在FP16/BF16下每元素2字节，即单token约256KiB；FP8下约128KiB；FP4下约64KiB。这些是量级估算，实际值随具体配置浮动，读者应以模型config.json为准复算。

上表为模拟估算，用于说明量级关系，非实测值。可以看到，FP8路径下KV可用空间被压缩到极窄区间，这正是“只能开约32K”的结构性原因：按单token 128KiB计，3GiB约可容纳约2.4万token的单请求缓存，叠加框架预留与并发需求后，32K量级的声明是自洽的。而FP4路径下十余GiB的KV空间，理论上可支撑十万token量级，但此时注意力计算的时间开销与精度损失成为新的约束。

本文评述：这张表最重要的启示不是具体数字，而是“权重精度”与“KV精度”应当解耦决策。权重用FP4换取空间、KV用FP8保障质量，是一种常见的折中；反之权重FP8、KV FP4则较少被讨论，因为KV精度对长文检索的影响更直接。工程上应把两者视为两个独立旋钮，而非一个整体开关。

2.3 从预算到可行域

把预算方程改写为可行域形式：给定M_kv可用量，最大单请求长度 S_max 与最大并发 B_max 满足 S_max × B_max ≤ M_kv / (单token字节数)。这条双曲线就是单卡的“服务能力边界”。vLLM的静态max-model-len实际上是在这条曲线上钉死一个点，把剩余空间留给并发；SGLang的调度器则更倾向于在运行时动态逼近这条曲线。

笔者认为，理解这条双曲线比记住任何具体数字都重要。它解释了为什么“调大max-model-len”经常导致启动失败或运行期OOM——那不是bug，而是把点移出了可行域。它也解释了为什么前缀缓存能显著改善体验：多个请求共享同一前缀时，KV的复用使有效B_max上升，曲线整体外移。

三、KV Cache分配机制：分页与基数树的分叉

3.1 PagedAttention：以块为单位的虚拟化

vLLM的核心贡献是把操作系统虚拟内存思想引入KV Cache管理：将缓存切分为固定大小的块（block），逻辑块通过块表映射到物理块，从而消除连续分配带来的内部碎片。这一机制在论文中有完整形式化描述，其收益在变长请求混合场景下尤为明显。本文评述：PagedAttention解决的是碎片与共享问题，它让“按需增长”成为可能，但它并不自动决定块大小、水位线与抢占策略，这些工程参数才是实际部署中差异的主要来源。

块大小是关键参数。较小的块减少内部碎片但增加块表开销与调度频率；较大的块降低管理开销但浪费尾部空间。社区实践中常见的16或32 token块，是在两类开销间的经验折中。当序列极长时，块表本身的内存占用也不可忽略，需要在预算中单列。

3.2 RadixAttention：以共享前缀为单位的复用

SGLang提出的RadixAttention用基数树组织KV Cache，把多个请求的公共前缀合并为树上的共享路径。其直接效果是：在多轮对话、少样本提示、agent轨迹等“前缀高度重复”的负载下，缓存命中率大幅提升，重复前缀只需计算一次。这一机制与PagedAttention并非互斥，二者在实现上可以叠加，但默认路径与调度假设不同。

“快近三倍”的观测，在多数复现中出现在前缀重复率高的负载上，而非任意负载。若请求之间前缀完全独立，基数树的优势会收敛。因此把“三倍”当作普适常数是误读；更合理的表述是，SGLang在特定负载形态下把有效吞吐推高到接近硬件上限，而vLLM在该形态下受限于重复计算。

本文评述：这两种机制的差异，本质是“空间效率”与“时间复用”两种优化哲学。分页优化的是空间利用率，基数树优化的是计算复用率。在长上下文场景中，二者都受同一个物理约束支配，因此都不能单独把窗口推到262K。真正决定上限的，仍是第二章的预算方程。

3.3 调度与抢占：被低估的第三变量

当可用KV空间不足以容纳新请求时，调度器必须做出选择：排队、抢占（preempt）已运行请求、或拒绝。抢占策略直接影响尾延迟与吞吐。常见的实现包括重计算式抢占与交换式抢占，前者丢弃KV后重算，后者将KV换出到主机内存。二者在长上下文下的代价差异巨大：重算一个数万token的前缀可能需要数秒，而换出再换入受PCIe带宽约束。

笔者观察到，许多“vLLM只能开32K”的报告，实际是在高并发压力下触发了频繁抢占，导致有效吞吐崩塌，运维者于是回退到更保守的max-model-len。这提示我们：窗口上限的“可用值”应由压力测试下的P99延迟定义，而非启动成功定义。启动成功只证明静态预算成立，不证明动态调度健康。

四、注意力后端与量化：可行域的二次收缩

4.1 注意力后端的选型逻辑

长序列下，标准注意力实现的内存访问模式会迅速劣化。FlashAttention系列通过分块与重计算降低显存占用并提升访存效率，已成为主流框架的默认或可选后端。此外还有分页感知的注意力内核、以及针对特定硬件的融合实现。选择哪一个后端，会同时影响显存峰值、计算速度与数值稳定性。

本文评述：后端选型不应只看基准测试的tokens/s，而要看在目标序列长度区间内的显存峰值曲线。某些后端在短序列上极快，但在长序列上因中间矩阵规模膨胀而触发额外分配，反而压缩了KV可用空间。工程上应以“目标分位数长度下的峰值显存”为第一判据。

4.2 量化对窗口与质量的双重影响

权重量化降低M_weight，直接释放KV空间，这是最立竿见影的手段。KV量化则直接降低单token字节数，效果同样显著。但两者都引入数值误差，且误差在长序列上会累积。已有研究指出，KV量化的误差对检索类任务的影响大于对生成流畅度的影响，因为前者依赖精确的键值匹配。

笔者建议采用分层验证：先用长文检索基准检验KV量化后的召回率下降幅度，再用生成质量评测确认可接受性。若召回率下降超过业务容忍阈值，应优先保留KV精度、改用量化权重或降低并发，而不是继续压缩KV位宽。窗口长度与信息保真度是一对必须同时优化的目标，牺牲后者换取前者在多数业务中不划算。

4.3 并行与卸载：单卡之外的选项

当单卡预算确实不足时，可选路径包括：张量并行分摊权重与KV、CPU卸载部分层、以及使用更激进的稀疏或线性注意力变体。每条路径都有代价：TP引入通信开销且要求卡间高速互联；CPU卸载受限于主机内存带宽，长上下文下延迟不可接受；注意力变体则可能偏离原模型的能力分布。

本文评述：在单张5090的语境下，这些路径属于“改变问题”而非“解决问题”。它们适合作为容量规划的备选，而不应作为默认优化手段。真正高性价比的顺序是：先调KV精度与块策略，再调调度与并发，最后才考虑并行与卸载。

五、工程路径：从32K走向更长的操作步骤

5.1 步骤一：建立基线并锁定变量

任何调优都必须从可复现的基线开始。建议固定：模型权重版本与量化方案、框架版本与镜像、CUDA与驱动版本、输入长度分布与并发梯度。基线测量项至少包括：启动日志中的KV块数与可用显存、目标长度下的TTFT、稳态吞吐、P99延迟、以及OOM发生点。

本文评述：社区中大量“A比B快三倍”的结论，源于基线不一致——量化方案不同、上下文长度不同、是否命中前缀缓存不同。把变量锁死，是让结论可检验的前提，也是本文反复强调“可复算”的原因。

5.2 步骤二：按预算方程做参数扫描

以第二章的方程为指导，做二维扫描：横轴为max-model-len，纵轴为最大并发，记录每个组合下的稳态吞吐与P99。扫描应覆盖业务真实分位数附近，而非均匀铺满。典型做法是先固定并发为1测单请求上限，再固定长度为业务P95测并发上限，最后在两者交集内做细扫。

# 示意：vLLM 启动参数骨架（版本差异请以官方文档为准）
vllm serve <model> \
  --max-model-len 65536 \
  --gpu-memory-utilization 0.92 \
  --kv-cache-dtype fp8 \
  --max-num-seqs 8 \
  --enable-prefix-caching

# 示意：SGLang 启动参数骨架
python -m sglang.launch_server --model-path <model> \
  --context-length 65536 \
  --mem-fraction-static 0.85 \
  --max-running-requests 8

注意gpu-memory-utilization与mem-fraction-static这类比例参数，其语义是“允许框架占用总显存的比例”，设得过高会挤压系统与驱动预留，导致运行期不稳定。经验上留出5%至10%余量是稳妥做法，但具体值需在目标机器上实测。

5.3 步骤三：针对负载形态选择框架

若负载以多轮对话、固定系统提示、agent轨迹为主，前缀重复率高，基数树类复用机制的收益显著，应优先评估SGLang路径。若负载以独立长文档问答为主，前缀重复率低，分页机制的碎片控制更重要，vLLM路径更稳。若两者混合，可考虑按路由拆分：高复用流量走复用优先的实例，独立流量走分页优先的实例。

本文评述：这种“按负载路由”的做法，比在单一框架上追求全能更符合工程现实。它把框架选择从“信仰之争”降级为“流量工程问题”，也让容量规划变得可分解、可度量。

5.4 步骤四：验证与回归

调优后的配置必须经过三类验证：功能验证（长文检索、多跳问答的准确率不低于基线）、性能验证（目标分位数下P99达标）、稳定性验证（持续压测数小时无OOM、无内存泄漏）。任何一类不达标都应回退，而不是靠提高重试或超时掩盖。

笔者建议把这三类验证固化为CI流水线的一部分，每次框架升级或参数变更都自动跑一遍。长上下文部署的失效往往是渐进的——今天能跑，明天在某个输入分布下就崩——只有持续回归才能提前发现。可观测性不是附加项，而是长上下文可用性的组成部分。

5.5 拓展资源

以下链接供读者延伸阅读，均在新窗口打开：

• vLLM 官方文档（引擎参数与KV Cache配置）
• SGLang 官方文档（RadixAttention与调度参数）
• vLLM 源码仓库（PagedAttention实现）
• SGLang 源码仓库（基数树缓存实现）
• Qwen 官方文档（模型结构与上下文配置）

六、对比、局限与失效边界

6.1 横向对比

本文评述：这张表刻意不给出“谁更好”的结论，因为结论依赖于负载分布。工程决策的正确形式是“在给定负载分位数下，哪个路径的P99与成本更优”，而非抽象的框架排名。

6.2 局限与失效边界

第一，本文所有量级估算基于公开结构参数，未绑定具体权重版本，实际值需以config与启动日志为准。第二，“三倍”类结论高度依赖负载形态，不能外推为普适常数。第三，262K窗口即便在预算上可行，也可能因注意力计算的时间复杂度与模型自身的长文能力而不可用。第四，单卡结论不适用于多卡TP/PP场景，后者受通信与切分策略影响，最优配置完全不同。

笔者认为，最需要警惕的失效边界是“启动成功但服务不可用”。静态预算通过只说明内存够放，不说明调度健康。必须以压力测试下的P99与错误率为准，否则会在生产流量下暴露问题。

七、结论与展望

回到标题提出的问题：软件栈的选择是否比多买8GB显存更能决定“能不能用”？本文的答案是有条件地肯定。在单卡、27B级、长上下文这一特定组合下，KV精度、块策略、调度与复用机制的组合，确实能把可用窗口从32K量级推进到数倍于它的位置，其幅度往往超过显存容量的小幅升级。但这一结论有明确边界：它成立的前提是负载形态与所选机制匹配，且以P99可用性而非启动成功为判据。

展望来看，三个方向值得持续跟踪：一是KV Cache的压缩与稀疏化研究，若能在保真度可控的前提下进一步降低单token字节数，窗口上限将再次跃迁；二是调度器与注意力内核的协同设计，把“预算方程”从静态配置变为运行时自适应；三是长文能力的评测体系，只有可复现的评测才能让“能开多长”与“开了有没有用”这两个问题分开回答。

本文评述：工程实践中，最稳妥的路径仍是先把预算方程算清楚、把基线锁死、把验证固化，再谈框架选型。软件栈的杠杆确实很大，但杠杆需要支点——那个支点就是对显存预算与负载形态的清醒认识。

文章声明：本文内容仅为作者学习、思考、经验、笔记的总结，仅供技术交流与参考。文中观点仅代表笔者个人思辨，不构成任何学术建议、商业建议或专业建议。所有数据来源已标注，引用时请以原始文献为准。

内容仅供学习参考。如需引用，请以原始文献为准。  全文约 6800 字  |  参考文献 60 篇（主要 9 篇）