在本地部署大模型时，很多人会把 Ollama 的上下文窗口从 4K 提高到 16K、32K，甚至更长，希望一次性处理完整文档、代码仓库或多轮对话。窗口变大确实能减少内容截断，但它并不是“免费升级”：更长的上下文通常意味着更高的显存或内存占用、更慢的提示词处理速度，以及更严格的硬件要求。📚
上下文窗口究竟控制什么
上下文窗口表示模型在一次推理中能够参考的 Token 总量，通常需要同时容纳系统提示词、历史消息、当前输入和模型输出。因此，把 num_ctx 设置为 32768，并不代表用户可以稳定输入完整的 32768 个 Token，还应预留回答空间。
Ollama 可以通过应用设置、服务环境变量、API 的 options.num_ctx，或者 Modelfile 中的 PARAMETER num_ctx 调整窗口。不同版本的默认策略可能变化，应以当前安装版本和 上下文长度官方说明 为准，而不要照搬旧教程中的默认值。
为什么窗口越大越占内存
模型推理时不仅要加载权重，还要保存已经处理过的 Token 对应的 Key-Value Cache，也就是常说的 KV Cache。该缓存让模型生成下一个 Token 时不必重新计算全部历史内容，但其容量会随着上下文长度增加。一般来说，在模型、精度、层数和并行设置不变时，预留的上下文越长，KV Cache 所需空间越大。🧠
实际占用还受到模型架构影响，例如注意力层数量、KV 头数量、隐藏维度、缓存精度以及是否采用分组查询注意力等。因此，不能仅凭“7B 模型”或“32K 窗口”准确推断显存需求，更不应把其他用户的测试结果当作固定标准。
如果模型权重和 KV Cache 可以完整放入显存，推理通常更稳定；一旦显存不足，部分计算可能转移到系统内存，速度往往明显下降。若系统内存也紧张并开始使用交换空间，延迟还会进一步增大，严重时可能出现加载失败或进程被终止。
对推理速度的影响
提示词处理阶段
Ollama 接收到长文档后，需要先完成提示词预填充。输入 Token 越多，预填充耗时通常越长；传统全注意力模型还需要处理大量 Token 之间的关联，其计算增长不一定保持简单的线性关系。实际表现则会受到 Flash Attention、滑动窗口注意力和模型架构优化影响。⏱️
逐 Token 生成阶段
生成答案时，模型需要读取已有上下文对应的缓存。上下文越长，每个新 Token 需要访问的数据通常越多，因此生成速度可能逐步下降。对于短回答，用户首先感受到的往往是首个 Token 等待时间增加；对于长回答，则可能同时看到每秒 Token 数降低。
CPU 与 GPU 的差异
纯 CPU 推理通常更容易受到内存带宽限制，扩展窗口后的等待时间会更加明显。GPU 推理虽然具有更高吞吐能力，但显存容量往往是主要瓶颈。统一内存设备的可用空间较灵活，却仍会受到总内存、带宽和其他应用占用的共同影响。
上下文长度并非越大越好
首先，运行参数不能突破模型本身真正支持的上下文能力。即使软件允许填写更大的数值，超出模型训练或适配范围后，也可能出现信息遗漏、位置理解变差、重复输出等问题。模型声明的最大窗口可以通过模型信息和 GGUF 元数据进行核对，相关字段示例可参考 模型详情 API 文档。
其次，超长上下文不等于模型能够平均利用其中的每一处信息。把大量日志、网页和历史聊天全部塞入提示词，可能稀释关键证据。对于知识库问答，先检索再生成通常比无差别扩大窗口更节省资源；对于代码任务，也可以优先加入相关文件、接口定义和报错位置。
如何找到合适的设置
- 从实际任务出发：普通对话不必盲目追求超长窗口；文档分析、代码代理和长流程任务再逐级提高。
- 采用阶梯测试：依次测试 4K、8K、16K、32K，记录首 Token 延迟、生成速度、GPU 显存和系统内存占用。
- 保留输出余量：不要让输入内容填满整个窗口，应为系统提示词、工具返回结果和最终回答预留空间。
- 检查加载位置：运行 ollama ps，观察 PROCESSOR 和 CONTEXT，确认模型是否完整加载在 GPU，以及实际分配的上下文长度。🔍
- 固定测试条件：比较不同窗口时，应保持模型、量化版本、提示词、输出长度和并行请求数一致。
一个实用原则是：选择能够覆盖大多数真实输入的最小窗口，而不是硬件勉强能够启动的最大窗口。
并发场景需要额外谨慎
单次对话能够运行，不代表多用户并发时仍然稳定。多个会话可能分别需要上下文缓存，内存压力会随并发增加。部署接口服务时，应同时测试峰值请求数、长提示词比例和模型驻留策略，避免仅根据单用户测试决定生产参数。
如果扩展之后出现突然变慢，可以先缩短窗口，再检查是否发生 CPU/GPU 混合加载；随后关闭不必要的并发任务，并确认环境变量、API 参数和 Modelfile 是否存在覆盖关系。具体配置方式可查阅 Ollama FAQ 与 Modelfile 参考文档。
总结
扩展 Ollama 模型的上下文窗口，可以提升长文档、多轮对话和代码分析能力，但代价主要体现在 KV Cache 增长、预填充时间延长、生成速度下降，以及显存不足时的 CPU 卸载风险。⚙️ 最合理的做法不是直接拉满参数，而是根据模型上限、硬件容量和真实输入长度逐级测试，并通过检索、摘要和内容裁剪减少无效 Token。只要把上下文长度视为需要权衡的资源参数，而不是单纯的功能开关，就能在回答完整度、推理速度与内存占用之间取得更稳定的平衡。
