本文是「上下文窗口」系列第三篇。前两篇分别讲了《标称1M的token，为什么32K就开始变笨》（为什么会变笨）和《KV Cache：每读1个token，就要交一笔“显存税”》（为什么会爆显存）。这一篇不重复论证，直接回答一个更实际的问题：到底该设多大。
两位读者间隔两天，问了同一个问题：
“Mac 24GB，到底该开16K还是32K？”
“现在的模型动不动就说支持1M上下文，是不是就该一直开满？”
答案我已经在评论区打完字了，只是散在各处。这篇把它整理成一套能直接照抄的判断框架。
一、上下文有三个长度，不是一个
先纠正一个直觉误区：Context越大越好。
前两篇已经用数据说清楚过：厂商标称的窗口，和模型真正“读懂”的窗口，从来不是一回事——在NoLiMa这项刻意排除关键词匹配、只测语义理解的基准测试中，32K的长度下，12个主流模型里有11个的表现跌到了短上下文性能的50%以下；而KV Cache这笔显存账，会随长度线性膨胀到硬件扛不住。这两条结论不重新展开，直接拿来当地基。
在这两条结论之上，这篇提出一个更好用的框架——任何一个模型的上下文窗口，其实是三个数字，不是一个：
- 标称长度（Advertised）：厂商发布会念的数字，128K、1M。它的含义仅仅是“技术上能塞进去”，不代表“能读懂”。
- 有效长度（Effective）：大海捞针、NoLiMa、RULER这类基准测出来的、模型表现开始明显滑坡之前的长度。这是“真正建议放心使用”的上限。
- 最佳长度（Optimal）：综合了速度、成本、显存、稳定性之后，日常真正该设的那个值。它通常比有效长度还要保守——因为有效长度只回答“模型还读得懂”，没回答“划不划算”“跑不跑得动”。
三层长度往往是层层递减的：标称1M，有效可能只有128K，而落到你的日常使用，最佳长度经常只有32K甚至更低。后面每一节，本质上都是在帮你把“最佳长度”这个数字，套到你的具体场景里去。
二、云端API：按任务场景，不按模型规格
面对一个API，第一反应不该是“这个模型支持多少”，而是“我这个任务该设多少”。按任务类型分场景，给一套可以直接抄的建议：
| 任务类型 | 建议长度 | 为什么 |
|---|---|---|
| 日常聊天 | 8K～16K | 没必要背着几百页历史对话，多背的都是白付费 |
| 写作/总结单篇长文 | 16K～32K | 覆盖绝大多数文档，还没进入U形曲线最吃亏的中段 |
| 代码Agent | 32K～64K | 需要跨文件理解，但推理能力和检索能力是两件事，别无脑往上加 |
| RAG检索类任务 | 64K～128K | 真正决定效果的是检索准不准，不是Context开多大——这条对应前一篇讲过的“新模型捞针能力已经不差” |
| 法律/论文/合同/整本书级长文档 | 128K以上 | 就算窗口够大，也建议先分章节处理，一次性塞满不如分块问得准 |
这张表背后有一条硬规律：任务越接近“综合推理”“多步分析”，越不该无脑加长上下文；越接近“从一堆材料里找一个具体的点”，越可以放心用长窗口。这也是前一篇里讲过的机制——长上下文里干扰项越多、格式越相似，模型越容易自信地编答案。加长窗口能扩大你能塞的材料范围，但不会让模型的推理能力跟着变强。
把厂商的收费拐点，当成性价比参考线
2026年两个真实的定价规则：Gemini3.1Pro（即前两篇提到的Gemini3Pro系列）上下文超过200K开始阶梯涨价，GPT-5.5输入超过272K直接翻倍。
这两个数字不只是“厂商想多赚钱”这么简单。标准全量注意力机制的理论计算复杂度随长度平方增长——这是长上下文对厂商算力成本构成实打实负担的根本原因；当然，实际部署中MLA、滑动窗口注意力等架构优化（前一篇讲过的DeepSeek MLA就是典型）能显著降低真实计算和显存开销，但压力并不会被完全抹平，只是被推迟或减轻。厂商选择在哪个长度设收费闸门，某种程度上等于厂商自己交了一份“这个长度开始不划算”的答卷。你不需要知道他们后台的具体成本曲线，看价目表拐点在哪，就知道大概在哪一档之后，性价比开始变差。
需要说清楚的是：这只是一种经验性的判断框架，不是绝对规律——不同厂商的定价还会受市场策略、模型架构差异、竞争态势的影响，同样是长上下文，有的厂商靠架构优化（比如KV Cache本身压缩得狠）扛住了成本，定价就没这么陡。把它当参考线，而不是当铁律。
三、为什么Context越大，不只是变笨，还会变慢
KV Cache那篇算过一笔硬账，这里只提炼成一条因果链，不重新推导：
Context↑ → KV Cache↑ → 显存占用↑ → 首字等待时间（TTFT）和生成速度↓ → 本地部署OOM风险↑
翻译成人话：上下文每往上调一档，模型要保管的“草稿纸”就线性变厚。Prefill阶段（读入你的输入）变慢是因为要把这些草稿纸现算出来；Decode阶段（一个字一个字往外吐）变慢，是因为每吐一个字，都要把这张越来越厚的草稿纸整个翻一遍。云端用户感知到的是“响应变慢、账单变贵”；本地部署用户感知到的是“内存肉眼可见地涨、模型直接加载失败”。
本地部署为什么不能照搬云端的长度设置，答案就在这条链条里。
四、本地部署：显存决定你的上限，不是模型决定
云端用户只受“有效长度”这一个约束——模型能力不够，顶多是回答质量下降。本地部署用户要同时扛住两个约束：能力上限和硬件上限，取较小值。硬件上限往往先到。
以一台MacBook Pro M4 Pro、24GB统一内存为例，这是项目里实测过的配置：
| 模型 | 量化 | 24GB Mac下的状态 | 已验证的上下文设置 |
|---|---|---|---|
| Qwen3-32B | IQ4_XS / MLX 4bit | 临界状态，需要手动把GPU内存上限从默认约16GB抬高到21GB左右，且机器需要专用 | 先设8192（8K）跑通，验证过可以再往上试16384（16K） |
| Gemma3-27B / Qwen3-27B | Q4_K_M | 同样临界，比32B多留一点余量 | 目前没有单独测过具体上限，暂不给精确数字 |
几个要点：
第一，macOS默认不会把全部内存都给GPU用。 24GB的机器，默认只放行大约16GB给Metal，很多人第一反应“明明24GB怎么27B都加载不了”，就是卡在这一步。需要手动执行sudo sysctl iogpu.wired_limit_mb=21504把上限抬到21GB左右（留约3GB给系统），重启会失效，想长期生效需要建一个LaunchDaemon常驻。这条属于系统级内存参数调整，执行前建议先了解它的影响范围（把过多内存划给GPU可能导致系统本身卡顿甚至无响应）；如果不确定，优先尝试LM Studio等推理框架里自带的参数调节，而不是直接改系统参数。
第二，上下文长度是你手动签的一张显存支票。 llama.cpp和LM Studio这类推理框架，会按你设置的上下文长度，把对应的KV Cache显存提前划走——不管你实际用不用得到那么长。把Context Length拉满再抱怨内存不够，等于自己签了张空头支票怪银行。
第三，落地动作就三个，KV Cache那篇已经给过：
- 按需设置，别拉满。日常总结任务8K～16K够用，代码和长文任务再往上试。
- 把KV Cache量化打开：llama.cpp用
--cache-type-k q8_0 --cache-type-v q8_0（V的量化要同时开Flash Attention），LM Studio在加载参数里也有对应开关。8-bit能把同样长度的KV Cache砍掉一半，日常任务质量基本无感。 - 长对话/Agent场景，定期用摘要换草稿纸——让模型总结当前进展、状态，带着摘要开新会话，而不是让KV Cache背着几万token的历史一路涨上去。
所以，本地部署不是“模型支持多长你就能开多长”，是“你的显存装得下多长，你就只能开多长”。
五、社区案例：Qwen3.6-35B的“复读机”翻车，是不是长上下文的锅
这一节的数据全部来自公开的社区报告，不是本号实测，先说明白这一点。
Qwen3.6-35B-A3B官方标称原生支持262,144（约256K）token上下文，可扩展到1,010,000。听起来是一款长上下文能力很能打的模型。但社区里反复出现同一类反馈：长对话跑到一定长度后，输出会陷入逐句循环，同一句话反复重复，怎么都停不下来——俗称“复读机”。公开的报告里，触发的长度并不统一：LM Studio的bug追踪上有用户记录约20K附近就开始高概率触发；另一份社区教程记录的是128K附近出现同类问题，靠调整--repeat-penalty、--min-p等采样参数缓解，配合关闭过度的重复惩罚冲突后基本能解决。
这个案例值得放进这篇文章，是因为它补了一个前两篇没覆盖到的角度：前面讲的“变笨”，是模型读了但理解跑偏；这里的“复读”，更接近生成阶段的稳定性问题（可能涉及采样参数、重复惩罚设置、位置编码扩展方式等具体机制），而不一定代表模型理解能力本身下降。 换句话说，即便你的任务量刚好卡在“有效长度”以内，也不代表长上下文下什么故障都不会发生——这也是为什么“最佳长度”往往要比“有效长度”更保守一档：留出的不只是显存和成本的余量，也是稳定性的余量。
写在最后
把这篇的判断压缩成一张决策树，日常直接照抄：
| |
一句话总结这篇：上下文窗口的最佳值，从来不是宣传页上的数字，而是任务复杂度、硬件资源、成本预算、响应速度这几个变量共同决定的。调到刚好够用，通常比一味追求更大，更稳、更快、也更省。
找机会再讨论一下新一代模型（DeepSeek V4、Gemini3.5这类支持超长上下文的新模型）该怎么设，留到下一篇专门拆。
数据来源
- NoLiMa基准、RULER基准、Chroma《Context Rot》报告、斯坦福《Lost in the Middle》论文：详见本系列第一篇《标称1M的token，为什么32K就开始变笨》
- Qwen3官方技术报告、DeepSeek-V2论文（MLA架构）、vLLM《PagedAttention》论文：详见本系列第二篇《KV Cache：每读1个token，就要交一笔“显存税”》
- 《别再被的模型名劝退了（下）》：24GB MacBook Pro M4 Pro实测数据、Qwen3-32B部署流程
- Qwen3.6-35B-A3B模型卡（Hugging Face）：huggingface.co/Qwen/Qwen3.6-35B-A3B
- Qwen3.6-35B-A3B长上下文循环输出问题（LM Studio bug tracker）：github.com/lmstudio-ai/lmstudio-bug-tracker/issues/1913