ARTICLE · 1292477
DeepSeek都1M了,你发个长文档还报错?
AI运维实战 · 第06期 DeepSeek都1M了，你发个长文档还报错？256K不是256K——一个被所有人忽略的数字陷阱，不管你用什么软件跑模型都躲不开 |
AI运维实战 系列 第01期 CUDA error 802 ｜ 第02期 Fabric Manager ｜ 第03期 vLLM显存OOM参数怎么算 ｜ 第04期 GPU监控双通道 ｜ 第05期 vLLM参数全集 |
热点背景 DeepSeek V4 发布，上下文窗口一口气拉到 1M（100万 token），输出上限 384K。消息一出，所有人都在讨论"终于能把整本书喂给AI了"。但私信里问得最多的反而是："我选了 256K 的模型，为什么发个长文档就报 Context length exceeded？"——这个问题不分运维和普通人，用 WorkBuddy、Ollama、LM Studio、ChatBox 的人都踩过。今天用一个生活类比，讲透这个被所有人忽略的数字陷阱。 |
你遇到过这个报错吗？ "Context length exceeded"——你明明选了 256K 的模型，发了一篇长文档就报这个错。明明没超 256K，凭什么？答案藏在那个你没注意过的数字里：256072 而不是 262144。不管你用 WorkBuddy、Trae、Ollama、LM Studio 还是 ChatBox，这篇都值得存。 |
各位，我是跟 GPU 死磕了十五年的女运维。
DeepSeek V4 把上下文拉到 1M 了，很多人觉得"那我本地跑个 256K 的模型总够了吧"——结果发一篇长文档，秒报上下文超限。
私信里被问得最多的就是这句："我选了 256K，为什么发个长文就报 Context length exceeded？"
这个问题不分运维和普通人——用 WorkBuddy 跑本地模型的开发者遇到，用 Trae 写代码的程序员遇到，用 Ollama 在笔记本上跑模型的爱好者遇到，甚至用 LM Studio 的学生也遇到。
问题出在哪？一个被所有人忽略的数字：256072，而不是 262144。
今天不讲前端怎么配参数——讲一个普通人也能听懂的道理：256K 的模型，不等于你可以塞进去 256K 的内容。为什么？因为它就像你的工资，看着月薪两万，真正能花的没那么多。
一、月薪两万的故事：为什么 256K 不是 256K
想象你月薪 20,000 块。你算了一下：房租 12,000，生活费 8,000，加起来 20,000，正好花完。
但你忘了：物业费、水电、网费、手机话费——这些是固定开销，每月雷打不动要从工资里扣。等你把这些交完，实际能自由支配的只有 17,000 左右。
大模型的 256K 上下文，一模一样：
工资（月薪） | 大模型类比 | Token 数 |
月薪总额 | max-model-len（总预算天花板） | 256,072 |
房租水电 | 系统开销（System Prompt、模板等） | ~6,000+ |
你花的钱 | 你发的消息（Input） | 看你怎么填 |
存下来的钱 | 模型回答（Output） | 看你怎么留 |
看到没？256K 是总预算，不是你能塞内容的上限。你要从里面扣掉系统开销（房租水电），剩下的才是你能用来发消息和让模型回答的空间。
那为什么是 256072 而不是整 262144（256×1024）？因为工程师替你预留了那 6072 个 token 的"物业费"——System Prompt、聊天模板、特殊符号……这些你看不到，但它们确实占地方。
一张图看懂：256K 预算怎么分 ┌──────────────────────────────────┐ │ 系统开销 ~6,000 占 2.3% █ │ │ 你的消息 131,072 占 51% █████│ │ 模型回答 65,536 占 26% ███ │ │ 安全余量 53,464 占 21% ██ │ └──────────────────────────────────┘ 总预算 256,072 = 系统开销 + 你的消息 + 模型回答 + 安全余量 |
一句话记住：256K 是天花板，你发的消息 + 模型回答，加起来不能顶到天花板，而且最好留 20% 空隙。
二、为什么你一发长文档就报错？三种最常见的"超预算"
下面三种情况，你是不是都遇到过？
情况一：输入拉满 256K → 爆了 |
你在软件里看到"256K"按钮就点了，然后发了一篇长文档。 256,000（输入）+ 64,000（输出）= 320,000 → 超出 256,072 达 25% 报错：Context length exceeded 类比：房租+生活费花了两万，物业费没算，月薪不够付。 |
情况二：多轮对话聊着聊着就超了 |
第一轮你发了 100K 的文档，模型回答了 30K。第二轮你想接着问，结果报错。 因为第一轮的内容（100K+30K=130K）会算进第二轮的输入预算。第二轮你只有 256072-130000=126,072 的空间了。 类比：你上个月的花呗账单，这个月还要还——历史记录是会累积的。 |
情况三：输入没超但输出太大，卡死或变慢 |
输入只发了 4K，但把最大输出设成了 200K。 数学上：4,000 + 200,000 = 204,000 < 256,072，没超。但模型要为这 200K 的输出预留巨大的显存空间，结果推理速度暴跌，甚至直接 OOM（内存溢出）。 类比：你说"这个月我要存一万八"，银行就提前锁住一万八不让你花——虽然你最后没存那么多。 |
三种情况的根源都是同一个：把总预算当成了输入上限，忘了加法和余量。
三、实操指南：常用软件怎么设才不报错
道理讲完了，下面是实操作——不管你用什么软件跑模型，核心规则一样：输入 + 输出 < 256072，最好留 20% 余量。以下是四款最常用的本地模型软件的设置位置和推荐值。
WorkBuddy：接自己的模型，一步到位
WorkBuddy 不光能用内置模型，还能接入你自己的模型——不管你是在 Ollama 上跑的本地模型，还是从 DeepSeek、硅基流动等平台申请的 API，都能接进来。配好了就不用再烧积分，本地跑一分钱不花。
关键是怎么配上下文长度不报错。下面是完整步骤：
WorkBuddy 自定义模型配置：四步走 | |||||||||||||||
第一步：找到添加模型入口 打开 WorkBuddy → 点左下角头像 →「设置」→ 左侧切到「模型」标签页 → 点右上角「+ 添加模型」 也可以在对话输入框右下角点当前模型名 → 拉到最底部点「配置自定义模型」  WorkBuddy 设置→模型 界面，点「+添加模型」开始配置 第二步：选提供商 下拉菜单里选「自定义 / Custom」。如果列表里已有你要的厂商（如 DeepSeek、GLM），也可以直接选，接口地址会自动填好 第三步：填四个关键字段  WorkBuddy 添加模型配置页：选「自定义」→ 填接口地址、API Key、模型名称 第四步：保存 + 完全重启 点「保存」→ 完全退出 WorkBuddy（只关窗口没用，右下角托盘图标也要右键退出）→ 重新打开 重启后回到对话页面 → 点右下角模型名 → 拉到最底部「自定义模型」分组 → 选你刚加的模型 → 发条消息验证能不能回  保存后回到对话页面，点右下角模型名切换到刚添加的自定义模型 |
上下文长度怎么填不报错？ WorkBuddy 自定义模型里的「上下文长度」就是你的总预算（Input + Output + 开销）。填的时候记住： 日常聊天：填 32768（32K），够了 长文档总结：填 131072（128K），输出设 32768（32K） 千万别无脑填最大值！本地模型填太大直接 OOM 崩掉，云端 API 填太大烧钱飞快 |
WorkBuddy 最常见的三个坑：① 接口地址漏了 /v1 → 404 连不上；② 只关窗口没退出托盘 → 模型不生效；③ 选成了内置模型不是自定义那个 → 积分照扣。验证方法：发条消息看积分变不变，没变说明走的是你自己的模型。
Trae：写代码的人都在用的 AI IDE
Trae（原来叫 TraeCode）是字节跳动出的 AI 编程 IDE，跟 VS Code 类似但内置了 AI 对话和代码生成。它也支持接入你自己的模型——本地 Ollama 跑的也行，云端 API 也行。程序员如果积分烧得太快，接个本地小模型做代码补全，90% 的零碎活儿就不花积分了。
Trae 自定义模型配置：五步走 | |||||||||||||||
第一步：进入模型管理面板 在 IDE 窗口中：设置 →「模型」（或对话输入框右下角点当前模型名 → 打开模型列表 → 点「添加模型」）  Trae IDE 设置→模型 面板，点「添加模型」按钮开始配置 第二步：选「自定义模型」 在添加模型窗口中，选择「自定义模型」选项（不是预设服务商那个） 第三步：填基础配置（四件套）  Trae 添加自定义模型窗口：选「自定义模型」→ 填 API 格式、请求地址、模型 ID、API 密钥 第四步：展开高级配置（关键！） 点击「高级配置」展开，找到上下文窗口设置： 输入（Input）：选 131072（128K）或手动输入 输出（Output）：选 32768（32K） 如果留空，Trae 会用内置默认值，但你最好手动设——别让它替你猜 第五步：点添加模型，验证连接 Trae 会自动调接口测试 API 密钥是否有效。连接成功 → 模型出现在列表里 → 在对话时选中就能用。连接失败会显示错误信息，按提示排查  添加成功后，在 AI 对话框的模型选择器中选中刚添加的自定义模型即可使用 |
Trae 接本地模型的省积分策略 别指望本地小模型完全替代官方大模型。聪明的做法是按任务分： 代码补全 / 改注释 / 写简单函数 → 本地 qwen2.5-coder:7b（免费） 复杂逻辑 / 跨文件重构 → 本地 14B 或走 API（少量付费） 架构设计 / 复杂 debug → 官方大模型（该花的花） |
Trae 最常见的坑：① 模型 ID 大小写打错了（gemma2:4b 和 Gemma2:4b 是两个东西）→ 用 ollama list 复制粘贴；② 「完整URL」开关不小心打开了，地址又没填全 → 保持关闭，填到 /v1 就行；③ 模型不支持图片输入却开了多模态 → 一堆 400 报错，按模型实际能力勾选。
Ollama：命令行玩家的选择
Ollama 默认上下文只有 2048 token，这是很多人"聊两句就忘"的原因。要通过 num_ctx 参数手动调大。
# 方式一：命令行临时指定（推荐新手） ollama run qwen2.5 --num-ctx 32768 # 方式二：写进 Modelfile（持久生效） PARAMETER num_ctx 32768 PARAMETER num_predict 8192 注意：num_ctx 是输入+输出+开销的总预算，不是输入上限。32768 表示总上下文 32K，日常够用了。 |
Ollama 最常见的坑：不设 num_ctx，默认 2048，发几条消息就报 "context window exceeded"。记住：每次启动都带上 --num-ctx。
LM Studio：可视化操作，适合普通用户
LM Studio 是最适合普通人的本地模型软件——全图形界面，不用敲命令。但它的上下文设置藏得比较深。
LM Studio 设置步骤（图文） |
① 加载模型后，看右侧面板 右侧有一排标签页，找到 "Prompt Format" 或 "Advanced" ② 找到 Context Length 滑块 拖到 131072（128K），不要拖到最大值 262144 ③ 找到 Max Tokens（输出上限） 设为 32768（32K），留足回答空间 ④ 检查总和 131072 + 32768 = 163,840，远小于 256,072 的 80%，安全。 |
LM Studio 最常见的坑：界面上的"Context Length"最大值写着 262144，你一拖到底，然后设了 Max Tokens 65536——加起来 327,680，超了一倍。软件不会拦你，发消息时直接报错。
ChatBox：手机也能用的轻量客户端
ChatBox 手机端和电脑端都能用，连接 Ollama 或 OpenAI 兼容 API。它的设置最简单，但也最容易踩坑。
ChatBox 设置要点 |
设置 → 模型 → 找到 Max Tokens（输出上限）和 Context Length（上下文长度） 日常聊天：Context 8K + Max Tokens 2K，省显存，速度快 长文总结：Context 32K + Max Tokens 8K，够总结一篇长文了 注意：ChatBox 的 Context Length 是发给后端的总预算，不是你输入框的大小！ |
四、一张表存手机：不同场景怎么配
不管用什么软件，核心规则只有一个：输入 + 输出 < 256072 的 80%。以下是五种常见场景的推荐值——截图存手机，直接对号入座：
五、冷知识：为什么是 256072 不是 262144
如果你够细心，会发现 256 × 1024 = 262,144，但 max-model-len 设的是 256,072，少了 6,072 个 token。这不是手滑打错，是工程师替你刻意留的物业费：
原因一：系统开销（占大头） |
每个请求除了你发的消息和模型回答，还有看不见的固定开销：System Prompt（系统提示词）、聊天模板格式化、特殊符号……这些东西加起来大约 5,000-6,000 token。你不发消息它们也在那。 |
原因二：防 OOM 的保险 |
如果精确设为 262,144，你恰好输入满 256K 时，加上系统开销就会溢出。少设 6,000 多个 token，等于给显存上了一道保险——宁可少用一点，也不能崩。 |
这就好比你租房，合同写"可用面积 100 平米"，但实际扣掉公摊、走廊、管道井，套内只有 92 平米。256072 就是那个"套内面积"。
六、三句话口诀：发消息前默念一遍
自检三步走 ① 输入 + 输出 < 256072？是 → 不会报错；否 → 必爆 ② 输入 + 输出 < 256072 的 80%（约 20万）？是 → 安全；否 → 可能卡 ③ 多轮对话？历史消息也算输入，别只算当轮 |
记不住？存这张图：
一句话记住 256K 是天花板你发的消息 + 模型回答 = 两个箱子箱子加起来不能顶到天花板而且最好留 20% 空隙，不然就报错 |
总结一下今天讲的：
① 256K 是总预算天花板，不是你能塞内容的上限。输入+输出+系统开销，三者之和不能超
② 256072 不是 262144：少 6072 个 token 是工程师替你预留的系统开销和保险
③ 多轮对话的历史消息也算输入预算，不是只算当轮
④ 不管用什么软件（WorkBuddy/Trae/Ollama/LM Studio/ChatBox），规则一样：输入+输出 < 总预算的 80%
⑤ 口诀：总和 < max-model-len 不报错，总和 < 80% 不卡顿
第03期讲了 max-model-len 怎么算出来，第05期讲了 参数全集。这篇把"256K 不是 256K"这个坑讲透了——从原理到软件实操，希望下次你再看到那个报错，能一秒知道问题出在哪。
你踩过"上下文超限"的坑吗？ 评论区说说——是 Ollama 默认 2048 被坑了？LM Studio 拉满 262K 爆了？Trae 模型 ID 大小写打错了？还是 WorkBuddy 忘了完全重启？说说你的经历，我帮你看看怎么配。 |
下期预告 上下文配好了，但模型回答速度慢？下期讲 vLLM 吞吐优化——GPU 利用率上不了 80% 的时候，问题往往不在显存，而在调度策略。关注别错过。 |
关注我，AI运维不踩坑 我是尴尬的女运维，十五年踩坑选手 AI运维实战 · GPU集群 · 故障复盘 传统运维转AI运维，每篇都讲人话 关注后回复"AI运维"，获取GPU部署检查清单 |
— 尴尬的女运维 · AI运维实战 — 原创声明：本文由「尴尬的女运维」基于 vLLM 官方文档等公开资料整理，并加入作者独立解读、实测与踩坑总结；原创部分版权归本号所有，引用内容版权归原厂所有。 数据来源：docs.vllm.ai / github.com/vllm-project/vllm / ollama.com / lmstudio.ai / docs.trae.ai / forum.trae.cn 更多内容，下期见 |
