8.0
热点
AI SCORE
技术实践2026-08-16 13:53
262k上下文模型在33k处崩溃的根因分析
dev.to · AI#Ollama#本地模型#上下文窗口
Editor brief · 编辑速览
模型宣称支持262k token但实际运行仅33k，问题出在Ollama运行时分配、Docker环境或服务层配置，而非模型本身，很多人因此误判浪费数小时。
大多数上下文窗口调试最终都归结到一个恼人的事实：
模型卡片上写的上限并不是运行时实际能用的上限。
如果 OpenClaw 显示 262144，但 ollama ps 只显示约 33k，实际的容量上限通常是 Ollama 运行时分配、Docker 环境处理或另一个服务层配置导致的。
问题不在 Qwen、不在 Llama、不在 OpenClaw。
我在逛 r/openclaw 帖子时遇到了这种模式，有人描述得非常精准：
OpenClaw 似乎能识别模型支持 262144 tokens，但我总是在用到大约 33k tokens 后就开始出现各种问题。
这句话就是整个 bug 报告。
模型支持 262k。实际服务层只给 ~33k。这是两个不同的数字。
如果没注意到这个区别，你可能会浪费好几个小时在错误的层级上找原因。
这是第一件我希望更多人能更清楚说明的事：
广告宣称的上下文上限不等于运行时实际有效的上下文。
一个 Qwen 模型可以标注为 262144 tokens。OpenClaw 可以请求 262144。但你的实际会话仍然可能在 30k 出头的范围就挂掉，因为 Ollama 根据可用 VRAM 或启动配置只分配了约 32k。
这与 Reddit 帖子和 Ollama 文档的描述都吻合。
同一帖子中有一条回复指向了真正的线索：
当我在 OpenClaw 会话打开的同时在终端运行 ollama ps 时，它显示模型只有 33k，不管模型实际能支持多少上下文。
不是模型页面。不是 OpenClaw 界面。不是你的假设。
如果 ollama ps 显示 33k，那就是你的会话实际运行的上限。
因为 Ollama 有多个默认值，而且它们说的不是同一个故事。
Ollama 文档早就提到过默认 4096 tokens，除非你覆盖它。
但 Ollama 较新的上下文长度指南也描述了基于可用 VRAM 的实际分配行为：
所以当人们不断看到约 33k 时，这通常根本不是 OpenClaw 的 bug。
而是 Ollama 根据 VRAM 做了一次分配。
这就是为什么这个 bug 感觉很奇怪。你配置了一个数字，运行时悄悄选了另一个。
因为单次提示词（one-shot prompt）是骗子。
一个微小的直接提示几乎无法告诉你 agent 工作流是否能存活。
OpenClaw 会话堆叠的东西远不止最后一条消息：
隐藏的上下文上限不只会破坏一次对话。它们会破坏：
Ollama 自己的指南建议 agent、网页搜索和编码工作负载使用更大的上下文。这与实际情况相符。
一个悄悄分配不足上下文的后端，是一种极其隐蔽的故障来源——只有在看起来成功执行了 20 分钟后才会暴露问题。
这是人们损失最多时间的地方。
export OLLAMA_CONTEXT_LENGTH=262144
然后重启 OpenClaw。然后感觉很乐观。然后 ollama ps 仍然显示约 33k。
因为如果 Ollama 运行在 Docker 里，这个变量必须存在于运行 Ollama 的容器内部。
不在你的终端里。不在你的 shell 配置文件里。不在 OpenClaw 容器里。
如果 Ollama 看不到它，那它就不存在。
docker logs <ollama-container>
检查运行中容器的环境变量：
docker exec -it <ollama-container> env | grep OLLAMA
这通常能快速说明问题。
这就是环境变量处理通常会出问题的地方：
我的规则是：不要同时调整三个层级。
把它当作一次生产事故来处理。
1) 在 OpenClaw 中显式设置值
openclaw config set agents.defaults.contextWindow 262144
好。现在先忽略 OpenClaw 一会儿。
2) 检查 Ollama 实际加载了什么
ollama ps
如果显示约 33k，那就是你真正的上限。
不是你想要的上限。不是模型卡片。是实际的上限。
3) 直接强制设置 Ollama 服务器的上下文
对于直接服务器运行：
OLLAMA_CONTEXT_LENGTH=64000 ollama serve
如果你想要 262144，就设置那个：
OLLAMA_CONTEXT_LENGTH=262144 ollama serve
但只有在你确定硬件能支持且不会让性能变成一坨浆糊时才这样做。
4) 用 num_ctx 测试直接 API 调用
这是将请求级行为与服务级行为分离的最干净方式。
curl http://localhost:11434/api/generate -d '{
"model": "llama3.2",
"prompt": "Why is the sky blue?",
"options": {
"num_ctx": 64000
}
}'
现在你可以回答三个不同的问题：
如果直接调用 Ollama 在更大的 num_ctx 值下工作正常，但 OpenClaw 会话仍然失败，你就隔离出了问题的层级。
如果直接调用 Ollama 仍然卡在上限，服务层仍然是瓶颈。
5) 如果涉及 Docker，检查容器配置
对于 Docker Compose，在 Ollama 服务中显式声明环境变量：
services:
ollama:
image: ollama/ollama
ports:
- "11434:11434"
environment:
- OLLAMA_CONTEXT_LENGTH=64000
然后干净地重启：
docker compose down
docker compose up -d
docker exec -it <ollama-container> env | grep OLLAMA
ollama ps
如果要我把它压缩成一个快速检查清单，会是这样的：
# 1) OpenClaw 认为上下文应该是多少？
openclaw config get agents.defaults.contextWindow
# 2) Ollama 实际分配了多少？
ollama ps
# 3) 环境变量是否存在于运行的 Ollama 进程中？
docker exec -it <ollama-container> env | grep OLLAMA
# 4) 日志说了什么？
docker logs <ollama-container>
# 5) 直接请求能否覆盖上下文？
curl http://localhost:11434/api/generate -d '{
"model": "qwen2.5",
"prompt": "test",
"options": {"num_ctx": 64000}
}'
这个顺序比盯着模型卡片看然后指望它自己好起来有用得多。
更大的提示词也可能失败，因为：
另外，"支持 256k"不代表"你的机器能好好地服务 256k"。
这是人们会跳过的部分。
纸面上的巨大上下文窗口和生产环境中稳定的长期运行 agent 不是一回事。
我宁愿要一个可靠完成工具循环的 64k 配置，也不要一个"256k"配置——一旦 trace 变得有趣就卡住。
这不是本地调试的小麻烦。
如果你在 n8n、Make、Zapier、OpenClaw 或自定义 OpenAI 兼容栈中运行 agent，隐藏的服务层限制是毒药。
它们造成的是最难处理的那类故障：
这也是团队最终厌倦了维护本地服务怪癖的原因。
调试 Ollama VRAM 分配、Docker 环境传播和每个模型的上下文奇怪行为这件事，有趣的地方在于它只会有趣一次。
过了那之后，可预测的容量就开始变得越来越吸引人。
这就是像 Standard Compute 这样的直接插入式 OpenAI 兼容服务的吸引力所在：可预测的月度定价、没有按 token 计费、当你的 agent 全天候运行时没有 token 焦虑。如果你的自动化运行在 OpenClaw、n8n、Make、Zapier 或自定义工作流中，成本可预测性的重要性几乎不亚于上下文的可靠性。
当有人说"OpenClaw 在限制我的上下文"时，我不会从 OpenClaw 入手。
我会先问：
在会话活跃期间，ollama ps 显示什么？
这一个问题就能切穿大量困惑。
因为在这类 bug 中，每个层级都在讲述不同的真相：
这四个可以同时为真。
这就是为什么上下文窗口调试感觉如此滑溜。
你不是在调试一个数字。你是在调试哪个层级有资格让这个数字成真。
如果你的"262k-token"模型表现得像一个 33k 模型，那运行时它就是一个 33k 模型。
相信加载后的运行时，而不要相信营销数字。相信 ollama ps，而不是假设。把 Docker 环境变量当作需要在运行中的进程内部被证明的证据来对待。
对于业余水平的本地配置，Ollama 没问题。
但对于需要全天候运行而不必时刻照看上下文的生产级 agent，我不会信任这样一个栈——它的服务层可以悄悄违背模型卡片，然后在凌晨两点让你还在调试 token 限制。