用 Ollama 本地跑 Qwen3.8-27B：标签写着 256K，你拿到的可能只有 4K

2026-08-24

本地跑 Qwen3.8-27B，Ollama 是门槛最低的一条路。装好之后一条命令就能拉：

ollama pull qwen3.8

然后就能对话了。听起来没什么可写的。

但这里藏着一个几乎所有人都会踩的坑：Ollama 页面上每个标签都标着 256K 上下文，而你实际跑起来拿到的，很可能只有 4K。 而且它不报错、不警告，你只会在某天喂进去一份长文档时，发现模型好像「忘了」前面的内容。

这篇讲清楚这条规则。

这篇的依据

两个来源，采集时间 2026-08-24：

Ollama 官方库 qwen3.8 的 tags 页面
Ollama 官方文档中的 Context length 一篇（仓库里的 docs/context-length.mdx）

我们没有安装 Ollama、没有 pull 过任何标签、没有跑过这个模型。 下面的命令和规则都是官方文档里写的，不是我们的运行记录。所有涉及「跑起来会怎样」的部分，请以你自己机器上的实际情况为准。

第一步：拉哪个标签

ollama pull qwen3.8

这条命令拉到的是 latest，18GB，4 位量化。

有个细节值得知道：latest、27b 和 27b-mtp-q4_K_M 三个标签指向同一个 digest，也就是说默认版本是带 MTP 的那一份。想要不带 MTP 的版本得显式写 qwen3.8:27b-q4_K_M——那是另一个 digest。完整的十二个标签对照见 Ollama 上 qwen3.8 的十二个标签。

拉完就能对话：

ollama run qwen3.8

到这里为止都很顺。问题在下一步。

关键：默认上下文是按显存自动分档的

Ollama 官方文档里的 Context length 一篇明确写了默认规则：

显存	默认上下文
小于 24 GiB	4k
24 到 48 GiB	32k
48 GiB 及以上	256k

这是按你机器的显存自动决定的，与模型标签上标注的 256K 无关。

标签上那个 256K 是模型支持的上限，实际给你开多少是运行时决定的。两者不是一回事。

所以：

一张 24GB 显存的卡 → 你拿到 4k 上下文
一张 48GB 的卡 → 你拿到 32k
要拿满 256k → 需要 48 GiB 以上

这个分档看起来很保守，但它其实相当合理——而且和这个模型的结构算得上严丝合缝。

为什么这个分档是合理的

Qwen3.8-27B 的 64 层里只有 16 层是全注意力，KV cache 只由这 16 层产生。按 config.json 里的字段算，每 token 的 KV cache 是 64 KiB，跑满 262144 上下文就是 16 GiB。

再加上 4 位量化权重本身的 18GB——光是权重加满上下文的 KV cache 就要 34GB 上下，还没算激活值和运行时开销。

Ollama 要求 48 GiB 以上才给 256k，正好卡在这个量级上。两份完全独立的来源（模型的 config 和 Ollama 的默认策略）互相印证了同一件事：这个模型的长上下文，代价主要不在权重，在 KV cache。

反过来也解释了为什么 24GB 卡只给 4k：18GB 权重塞进 24GB 显存之后，剩下的空间本来就不多了。

怎么改

官方文档给了两个途径。

命令行：起服务时用环境变量指定。

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

桌面应用：设置里有一个上下文长度的滑块，直接拖。

文档里还给了一条明确建议：

Tasks which require large context like web search, agents, and coding tools should be set to at least 64000 tokens.

也就是说，联网搜索、agent、编码工具这类任务，至少要设到 64000。默认的 4k 对这些场景基本是不够用的。

但同一篇文档也提醒了代价：调大上下文会增加内存需求，得确认显存够。这不是一个免费的开关——你把上下文从 4k 调到 64k，就等于要求多出十几倍的 KV cache 空间。

怎么确认自己实际拿到了多少

这是最实用的一条。模型跑起来之后：

ollama ps

输出长这样（文档中的示例）：

NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
gemma4:latest    c6eb396dbd59    9.6 GB    100% GPU     131072     2 minutes from now

两列要看：

CONTEXT 是实际分配到的上下文长度。如果你以为自己有 256K，这里显示 4096，那就是被默认规则限住了。

PROCESSOR 是模型的执行位置分割。显示 100% GPU 说明完全在显卡上；如果显示成 GPU 和 CPU 的混合比例，说明一部分被卸载到了 CPU。官方文档对此的建议是尽量避免卸载到 CPU。

这条命令是本地部署最该养成的习惯。它把两个最容易出问题的点——上下文到底给了多少、模型是不是真的全在 GPU 上——一次性摆出来了。

27B 在消费级显卡上是个尴尬的尺寸

把官方的分档规则和这个模型的体积放一起看，会得出一个有点扫兴但很实际的结论。

主流消费级旗舰显卡的显存通常在 24GB 这一档。而 4 位量化的权重是 18GB。塞得进去，但塞进去之后就没剩多少了——按 Ollama 的规则，24 GiB 以下只给 4k 上下文，恰好卡在这条线上。

往上一档要到 24 到 48 GiB 才有 32k，而 32k 对 agent 类任务仍然是官方明确说不够的（建议至少 64000）。真正宽裕要到 48 GiB 以上，那已经是专业卡或多卡的范畴了。

所以「能跑」和「好用」之间隔着一段真实的距离。 一张 24GB 的卡跑这个模型，权重是装得下的，你能对话、能测试、能做原型；但要拿它跑长文档分析或者多轮工具调用的 agent，4k 上下文会很快构成瓶颈。

有几条缓解思路，代价各不相同：

换更低精度能省出权重空间，但列表里 4 位已经是最低档了，往下没有了。

手动调大上下文可以突破默认分档，但显存不会凭空变多——超出的部分会卸载到 CPU，速度代价自负。

接受 4k 做原型、上云跑生产是比较务实的路子：本地验证流程，真正跑量的时候用托管服务（可选项见 Qwen3.8 系列全家谱）。

说这些不是劝退。只是希望你在拉完 18GB 之后，别因为「怎么好像记不住东西」而怀疑模型本身——那多半是 4k 上下文在起作用，跟模型能力无关。

一个连锁反应值得注意

上下文和卸载这两件事是有联动的。

你把 OLLAMA_CONTEXT_LENGTH 调大，KV cache 需求跟着涨；显存装不下的时候，模型的一部分就会被挪到 CPU 上。结果是你如愿拿到了长上下文，代价是执行位置变了。

所以调完之后一定要再 ollama ps 看一眼 PROCESSOR。只看 CONTEXT 达标就以为成了，可能会漏掉另一半的变化。

小结

跑起来之后建议按顺序确认三件事：

拉的是哪个标签——latest 是带 MTP 的 4 位量化版，想要别的得写全名
实际上下文是多少——ollama ps 看 CONTEXT 列，别信标签上的 256K
是不是全在 GPU 上——同一条命令看 PROCESSOR 列

核心那条规则再重复一遍：Ollama 的默认上下文按显存分档，低于 24 GiB 只给 4k。标签上的 256K 是模型上限，不是你的实际配额。agent 和编码类任务官方建议至少设到 64000，但记得先确认显存扛得住。

这条规则本身也可能随版本调整，本文记录的是 2026-08-24 采集时官方文档里的分档值。但无论数值怎么变，「标签标注的是上限、实际配额由运行时决定」这个结构不会变，ollama ps 也一直是确认真实情况最快的那条命令。养成跑完就看一眼的习惯，比记住任何具体数字都管用。

想了解各标签的差异，看十二个标签的对照；想算清楚显存那笔账，看四笔账怎么分开算。更多内容在 Qwen3.8-27B 专题。