Qwen3.8-27B 显存指南：RTX 5090 如何选择量化、双卡与 262K 配置

单张桌面版 RTX 5090 部署 Qwen3.8-27B，应先从量化权重、单请求和较短上下文开始；262K 则需要单独计算缓存，并验证完整长输入。 两张卡扩大了可用空间，但显存不会自动合并，原始 BF16 权重加上完整长度的 BF16 缓存甚至会超过两张 32GB 卡的容量之和。

这个模型的原生上下文上限是 262,144 tokens，即常写的 262K，也有人写作 256K；它包含输入和生成的输出。模型采用混合注意力，64 层里只有 16 层使用全注意力，另外 48 层使用线性注意力，因此不能照搬普通 64 层 Transformer 的缓存公式。官方模型卡与配置

以下数据截至 2026 年 9 月 6 日，包括发布者的文件大小、依据配置进行的计算，以及上游公开的运行记录。配置示例供本地验证使用，不代表本站在 NVIDIA 显卡上的实测结果。

先把模型文件和实际显存分开算

峰值显存可以拆成：驻留显存的权重 + 全注意力 KV 缓存 + 线性注意力状态 + 推理框架与计算缓冲区 + 可选的视觉、推测解码开销。只减去下载文件大小，剩下的空间还不能全部交给上下文。

下表中的 GB 按十进制计算，GiB 按 1,073,741,824 字节计算。预算计算统一使用 GiB；不要直接把文件网站上的 GB 数字减去显卡监控工具中的 GiB。BF16 一行是权重索引记录的张量字节总量，其余是对应模型文件的大小，都不是运行时最低显存承诺。

数据分别来自官方 BF16 权重索引、官方 FP8 文件列表及 Unsloth GGUF 固定版本。GGUF 数据对应版本 4ca7207，其他发布者的同类量化、旧版文件或不同打包方式可能有不同体积。

量化名称不是一个通用开关。GGUF 需要支持对应模型架构与量化格式的运行时；官方 FP8、不同发布者的 NVFP4 权重也有各自的加载要求。不能把 GGUF 文件交给 NVFP4 示例，再期待修改一个参数就能运行。选择之前先确定使用哪套推理框架，再核对完整模型名称、文件版本和支持情况。

长上下文究竟增加多少显存

按官方配置，全注意力部分有 16 层、4 个 KV 头，每个头的维度为 256。一个请求每存储一个 token，F16/BF16 KV 缓存的有效数据量为：

text
2（K 与 V）× 16 层 × 4 个 KV 头 × 256 维 × 2 字节
= 65,536 字节 = 64 KiB / token

据此得到下表。这里计算的是单条序列、全注意力部分的缓存数据量，尚未包含分配对齐、框架开销和线性注意力状态。

q8_0 不是严格的每值 1 字节：每 32 个值还带有缩放信息，共占 34 字节；q4_0 每 32 个值占 18 字节。因此完整长度下分别是 8.5 GiB、4.5 GiB，而不是简单的 8 GiB、4 GiB。上述两列假设 K、V 都使用相应精度，依据 llama.cpp 的量化块定义计算。

另外 48 层并非不占显存。它们需要保存线性注意力状态；SGLang 文档给出的一个 GDN 状态槽约占 153.9 MB（fp32）或 78.4 MB（bf16），实际保留多少槽、是否使用推测解码，都会改变总开销。这些数值不能直接当作所有框架固定只需预留的空间。

并发也要纳入计算。若两个请求各自保留 131,072 tokens，未发生实际缓存共享时，仅全注意力 F16 缓存合计就达到 16 GiB。模型只加载一份，并不代表第二个长请求几乎不增加显存。

单张 RTX 5090：先选预算，再选上下文

本文指的是 32GB GDDR7 桌面版 RTX 5090，不包括笔记本型号或其他地区型号。NVIDIA 官方规格

先查看当前环境实际提供多少显存：

bash
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv

输出通常以 MiB 为单位，除以 1024 后再与本文的 GiB 比较。桌面显示、驱动和其他进程会占用空间；空闲显存应在准备启动推理的同一使用状态下读取。

以 UD-Q4_K_M 为例，全长 262,144 tokens 的预算如下：

由此可见，“4 位模型能加载”与“4 位模型可以稳定处理 262K”是两件事。权重量化缩小常驻模型，缓存量化缩小随 token 数增长的存储；前者不会自动量化后者。

如果日常任务只需要几万 tokens，优先围绕真实需求配置上下文。 先用较保守的权重和缓存精度完成一次代表性任务，再决定把空间用于更高精度的权重、更长上下文，还是更多并发。不要为了模型支持的最大数字，一开始就承担完整缓存和长输入计算成本。

对于 GGUF，可用 UD-Q4_K_M 权重搭配下面的 32K、单请求配置起步。将 MODEL 改成已下载模型文件的真实路径；需要安装支持 Qwen3.8-27B、CUDA 及相关缓存类型的 llama.cpp 版本。

bash
MODEL="/path/to/your/model.gguf"

llama-server \
  --model "$MODEL" \
  --n-gpu-layers 99 \
  --ctx-size 32768 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0

参数依据 llama-server 文档组合，未在本站硬件上验证。--n-gpu-layers 99 用于请求尽量将模型层放入 GPU，是否全部卸载成功要看启动日志。安装版本的 llama-server --help 才是当前二进制可用参数的依据。

如果目标是更长输入，按 32768、65536、131072、262144 逐级提高 --ctx-size，每级都发送与该级目标相符的长输入，并预留输出空间、记录显存峰值。保留其他参数不变，才能判断失败主要由哪一项变化触发。

双 GPU：容量之和只是第一道检查

两张卡必须由运行时显式分配任务，不能按“一张 24GB 加一张 24GB，任何 48GB 以内的配置都能跑”来选模型。例如 Q8_0 权重 27.052 GiB，加全长 F16 KV 的 16 GiB，合计 43.052 GiB；虽然低于两张 24GB 卡的名义容量之和，某张卡仍可能因分层不均、主卡缓冲区或其他开销而溢出。

BF16 的约 51.75 GiB 权重加 16 GiB KV 则达到 约 67.75 GiB，连两张 32GB 卡的总容量都已经超过。若坚持全部权重驻留 GPU、使用完整长度和 F16/BF16 KV，这个组合无法仅靠双 5090 解决。

GGUF 分层分配

llama.cpp 的 layer 模式会将模型层及相应 KV 缓存分配到不同 GPU；row 模式的中间结果与 KV 分配方式不同，不能把两者当成等价参数。llama-server 参数说明

在两张显存相近、均有足够空闲空间的卡上，可将前面的命令改为以下起点：

bash
MODEL="/path/to/your/model.gguf"

CUDA_VISIBLE_DEVICES=0,1 llama-server \
  --model "$MODEL" \
  --n-gpu-layers 99 \
  --split-mode layer \
  --tensor-split 1,1 \
  --ctx-size 32768 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0

1,1 表示等比例分配的起点，不是每张卡占用一定完全相同。混用不同容量的显卡时，应按实际空闲空间调整比例，并检查每张卡的日志与峰值；不要只看两卡总利用率。

vLLM 张量并行

vLLM 的 Qwen3.8-27B 配方报告过双 RTX 5090、张量并行度为 2 的运行结果。其消费级显卡测试使用 0.26.1rc1.dev608+g99a10304d，不是只凭文档页面的宽泛最低版本就能完全复现。

这些数字说明对应软件和模型组合下的启动分配结果，不表示模型上下文上限提高到九十多万，也不证明完整 262K 输入的速度或质量。一个缓存池还可能用于容纳多条序列，不能把池容量直接读成单请求支持长度。

桌面 RTX 5090 没有 NVLink，跨卡运行需要考虑 PCIe 拓扑和通信。双卡首先解决容量问题，是否加速、加速多少取决于运行时、分配方式和实际负载，不能预期速度自动翻倍。

单卡 262K 已有公开方案，但要按具体组合复现

公开资料中的“单张 5090 能跑”有不同含义。vLLM 官方配方中的单卡 Inferact NVFP4 示例使用 32,768 上下文、FP8 KV、--enforce-eager 和 qwen3 推理解析器；该测试环境在未启用 eager 模式时出现过 CUDA Graph 捕获阶段显存不足。这是一个有明确条件的 32K 基线，不能直接改成 262,144 就当作已验证配置。

MiaAI-Lab 的单卡长上下文方案则报告了另一套组合：

• RadixArk NVFP4 权重。
• vllm==0.27.1，并回移植 #40914 补丁。
• turboquant_4bit_nc 缓存，5.5 GiB 的 KV 缓存池。
• 最大上下文 262,144，max-num-seqs 为 1，批处理 token 上限为 512。
• 开启多 token 预测（MTP），推测 token 数为 3。

这给出了可追溯的复现入口，但它的缓存实现不能用前表中的 llama.cpp q4_0 数据直接替代。作者还提醒，未修补的路径可能出现乱码，MTP 与并发组合可能崩溃。因此适合在独立环境中按其固定版本复现，并用自己的文本检查质量；不宜把其中几个参数抽出来套到任意 NVFP4 模型上。

同样，SGLang 的消费级显卡配方注明的验证负载是输入 8,192 tokens、输出 1,024 tokens、并发 1。页面讨论最大上下文，不代表每个配置都经过完整 262K 负载验证。比较框架时，应先对齐模型文件、缓存精度、输入输出长度、并发和版本，再比较结果。

用一次完整长输入判断配置是否真的可用

启动成功、缓存池分配成功、请求被接受、长文本处理完成，是不同的检查点。要验证接近 262K 的任务，可按以下顺序操作。

1. 固定测试条件。 记录显卡型号、每卡空闲显存、运行时版本、完整模型版本、缓存精度、上下文限制和并发数。第一轮先使用纯文本、单请求；需要图像或 MTP 时，再单独加入这些功能。
2. 先用同一模型的分词器计算输入。 把对话模板、系统消息和用户材料都算在内，并预留输出。例如预留 4,096 个输出 tokens 时，输入及模板应控制在 258,048 tokens 以内，最好再留余量。中文字符数、文本文件大小都不能代替 token 数。
3. 确认没有静默截断。 禁用客户端自动裁剪历史，检查服务日志和可用的 usage 数据；若长度对不上，先查模板、截断和请求构造，不要把短输入成功当作长上下文成功。
4. 同时观察预填充和生成阶段。 用 nvidia-smi -l 1 观察每卡显存，记录处理输入期间的峰值、开始输出的时间，以及完成输出时是否报错。只发一句“你好”无法覆盖长输入带来的计算缓冲区峰值。
5. 检查信息是否仍然可用。 在材料开头、中间、结尾放置不同且可核验的内容，要求模型分别找出并关联它们，再用真实业务问题验证。能输出流畅文字，不足以说明读到了全文；简单找回几条信息，也不能替代实际任务质量评估。

更换为更低精度的缓存后，用相同输入和问题与原配置比较。尤其关注数字、跨段关联和关键细节，不要把“没有显存错误”当作缓存量化没有损失的证明。若需要提高并发，应在单请求已经通过后增加请求数，并重新检查峰值与质量。

显存不足时，按失败发生的位置调整

CPU 卸载可帮助显存较小的设备运行更大的权重，但会用到系统内存，并可能因 CPU 计算和数据传输降低速度。它适合愿意用延迟换容量的任务，不能作为“全模型在 GPU 上运行”的等价结果。

视觉任务还需要另算空间。Unsloth 的 mmproj-F16.gguf 文件约为 0.864 GiB，需与模型匹配；这只是视觉投影器文件大小，图像处理缓冲区也会增加峰值。纯文本配置通过后，再加入实际数量与尺寸的图片验证。对应 GGUF 与投影器文件

最终应保存的是一套能完成你的输入长度、输出长度和并发需求的配置，而不仅是一个可启动的命令。如果主要问题已从“这块显卡能否装下 27B”变成“是否值得换一个模型”，可以继续阅读 Qwen3.8 Flash Next 与 Qwen3.8-27B 的选择指南。