Qwen3.8-27B 要多少显存：把这笔账拆成四份分别算

2026-08-24

「Qwen3.8-27B 要多少显存」大概是这个模型被问得最多的一个问题。

网上流传的答案通常是一个数字。但只要你把这个问题拆开一层就会发现，它至少是四笔互相独立的账，而且其中一笔的大小完全取决于你打算跑多长的上下文——同一个模型，跑 4K 和跑 256K 差出来的量级，比模型本身还大。

这篇不给你一个数字。这篇给你四个算法，外加一份可以自己去核对的官方标注值。算完之后你会知道，为什么「18GB」这个到处流传的数字，既是对的，又几乎没什么用。

这篇的依据和边界

事实来源有两个：Qwen3.8-27B 在 Hugging Face 上的 config.json，以及 Ollama 官方模型库 qwen3.8 的 tags 页。采集时间 2026-08-24。

我们没有下载权重、没有安装任何推理框架、没有跑过这个模型。 所以本文不会出现任何「实测占用多少」的说法。下面出现的数字分两类：一类是从 config 字段直接算出来的算术结果，另一类是官方页面上标注的文件体积。两类都可以自己去核对，但都不等于「你的显卡需要多大」——最后一节会说清楚为什么。

第一笔：权重体积

这是唯一一笔有现成官方数字的账。Ollama 官方库的 tags 页上，每个 tag 都标了体积：

tag	体积	标注上下文
`qwen3.8:latest` / `qwen3.8:27b`	18GB	256K
`qwen3.8:27b-mtp-q4_K_M`	18GB	256K
`qwen3.8:27b-mlx`	18GB	256K
`qwen3.8:27b-mtp-q8_0`	30GB	256K
`qwen3.8:27b-mxfp8`	32GB	256K
`qwen3.8:27b-mtp-bf16`	56GB	256K
`qwen3.8:27b-mlx-bf16`	56GB	256K

顺便一个可以自己验证的细节：latest、27b 和 27b-mtp-q4_K_M 三个 tag 的 digest 前缀都是 22130167c4c2——它们是同一份内容的三个别名。也就是说，你 ollama pull qwen3.8 拿到的默认版本是 4 位量化的。

这张表本身就能验证一个粗算法则。参数量乘以每参数字节数：

bf16 每参数 2 字节 → 27B × 2 ≈ 54GB，官方标注 56GB
8 位量化每参数约 1 字节 → 约 27GB，官方标注 30GB
4 位量化每参数约 0.5 字节 → 约 14GB，官方标注 18GB

三档都比粗算值略高一点，这很正常：量化格式里除了权重本身还有缩放因子等元数据，而且 q4_K_M 这类混合量化会把一部分层留在更高精度上。粗算能给你量级，官方标注给你准数。

还有一处容易漏算的：config.json 里 tie_word_embeddings 是 false。这意味着输出层的 lm_head 是一份独立权重，不与输入嵌入共享。按 vocab_size = 248320 和 hidden_size = 5120 算，光这一个矩阵就有约 12.7 亿参数。在做参数量核对时，这部分不能只算一次。

第二笔：KV cache——这里有个反直觉的地方

这是最容易被低估的一笔，也是这个模型最有意思的一笔。

标准的算法是：

每 token 的 KV cache = 层数 × KV头数 × head_dim × 2 × 每元素字节数

其中的 2 是因为 K 和 V 各存一份。

代进 config.json 里的值——但层数这一项不能填 64。

Qwen3.8-27B 的 layer_types 数组里，64 层分成两类：48 层是 linear_attention，只有 16 层是 full_attention（详见 64 层怎么排）。线性注意力层不产生随序列增长的 KV cache——它用的是另一套机制，下一节说。

所以真正参与 KV cache 计算的只有那 16 层：

16 × 4 × 256 × 2 × 2 = 65,536 字节 = 64 KiB / token

其中 4 是 num_key_value_heads，256 是 head_dim（这两个值以及为什么是 24 个 Q 头配 4 个 KV 头，见 GQA 那篇），最后一个 2 是 bf16 每元素 2 字节。

跑满 max_position_embeddings = 262144：

64 KiB × 262,144 = 16 GiB

这个数字值得停下来看一眼。满上下文的 KV cache，和 4 位量化的权重体积（18GB）是同一个量级。 你把权重塞进显卡只是第一步，真要跑长上下文，还得再腾出差不多同样大的一块地方。

如果框架支持 KV cache 量化（比如存成 fp8），这一项可以对半砍到 8 GiB。这是长上下文场景里最有效的一个开关。

反过来，如果你只跑 8K 上下文：64 KiB × 8192 = 512 MiB，几乎可以忽略。这就是为什么「要多少显存」不给上下文长度就没法回答。

以上都是批大小为 1 的算法。并发跑多个请求时，KV cache 按请求数近似线性叠加——这也是服务端部署和本地单人使用之间最大的差别。

第三笔：线性注意力的状态

那 48 层线性注意力不产生 KV cache，但它们不是不占地方，而是占固定大小的一块。

从 vLLM 的实现能看清这一点。它计算状态形状的函数签名是这样的（详见 64 层在 vLLM 里怎么分流）：

MambaStateShapeCalculator.gated_delta_net_state_shape(
    tp_size,
    hf_config.linear_num_key_heads,
    hf_config.linear_num_value_heads,
    hf_config.linear_key_head_dim,
    hf_config.linear_value_head_dim,
    hf_config.linear_conv_kernel_dim,
    num_spec,
)

入参里没有序列长度。 这就是关键——状态尺寸由 config.json 里那几个 linear_ 开头的字段决定（值分别是 16、48、128、128、4，见线性注意力参数），跑 4K 和跑 256K 占的是同样大小。

至于这块固定状态具体多少字节，取决于框架实际用的形状与精度，还受张量并行度 tp_size 影响。这一项我们不给数字——要准确的值，得读你所用框架那个版本的 gated_delta_net_state_shape 实现，或者启动时看框架自己报的显存分配。

但结论是明确的：这一项是常数，不随上下文变化。 长上下文的压力全在那 16 层身上。

第四笔：运行时开销

剩下的是激活值、CUDA context、框架自身的缓冲区、多模态输入的视觉塔中间结果，以及各家框架的显存预留策略。

这一笔我们不给任何数字。 它取决于框架、版本、批大小、单序列最大长度、图像视频输入的分辨率，以及你有没有开各种优化开关。任何声称能给出通用数值的说法，都值得怀疑。

实践中的处理方式是反过来的：多数推理框架有一个「显存利用率」参数（vLLM 是 --gpu-memory-utilization），你告诉它可以用这张卡的百分之多少，它自己扣掉权重和开销之后，把剩下的全部分给 KV cache。你不需要精确算出这一笔，你需要的是给它留够余量。

把四笔账放在一起

用一句话概括：

总占用 ≈ 权重体积（看量化精度）
       + 64 KiB × 上下文长度 × 并发数（KV cache，可量化减半）
       + 一块固定大小的线性注意力状态
       + 一笔说不准的运行时开销

举个怎么用这个公式的例子——注意下面是算术推演，不是实测结论：

假设你用默认的 4 位量化版本（官方标注 18GB），只跑单请求、8K 上下文，那么 KV cache 约 512 MiB，四笔里第二笔几乎不构成压力，主要矛盾是权重本身。

同样是这个 4 位版本，如果要跑满 256K 单请求，KV cache 那一笔就是 16 GiB，已经接近权重体积，总量翻倍还不止。

同一个模型，同一份权重，两种用法之间差着一个数量级的显存需求。这就是为什么「27B 要多少显存」这个问题，答案永远是「取决于你怎么用」。

最后，说清楚为什么本文不给一个数字

前面所有数字要么是官方标注的文件体积，要么是从 config 字段算出的算术值。

文件体积不等于显存占用，算术值也不等于显存占用。 中间隔着框架的实现细节、显存对齐与分页策略、以及第四笔那些说不准的开销。我们没有下载权重、没有启动任何框架、没有跑过一次推理，因此没有任何依据给出「这张卡够不够」的结论。

能诚实交付的是这个：四笔账的构成、每一笔的算法、以及可以自己去核对的官方标注值。 拿着这套算法，你可以对着自己的实际场景——你的量化精度、你的上下文长度、你的并发数——自己算出量级，然后留足余量去实测。

真正的数字只能来自你自己的那张卡。

想接着往下读，可以看 64 层在 vLLM 里怎么分流了解两类层在框架里的实现差别，或者回 Qwen3.8-27B 专题。