为什么 Ollama 连上 Continue 后总是提示 Context Window 溢出？

上周五下午 4 点，我正打算在 VS Code 里用 Continue 插件跑个本地的代码重构。环境很简单：Mac M2 芯片，Ollama 跑着 DeepSeek-Coder-V2，插件配置也按照官方文档走了一遍。

结果离谱的事情发生了。我只要选中超过 50 行的代码点一次 Cmd+L（对话），Continue 还没来得及生成代码，直接弹窗报错：Context length exceeded。

明明 DeepSeek-Coder-V2 支持的上下文那么大，怎么我这边 50 行代码就崩了？

那个被我忽略的 contextLength 坑

我当时第一反应是 Ollama 挂了，重启了三次，没用。然后我开始怀疑是插件的锅，去翻配置。

在 config.json 里，默认的配置大概长这样：

{
  "models": [
    {
      "title": "DeepSeek-Coder",
      "model": "deepseek-coder-v2",
      "provider": "ollama"
    }
  ]
}

我寻思这配置没问题啊，provider 是 ollama，模型名字也对。结果我在 PromptCube 社区发帖求助时，一个老鸟直接甩给我一句话：“你检查一下 Ollama 默认的 context window，它默认只有 2048 或 4096，根本没用上模型的最大上限。”

我赶紧在终端执行 ollama run deepseek-coder-v2 进去看，发现确实如此。Ollama 为了保证在低配机器上能跑起来，给很多模型设了保守的默认值。

怎么彻底修好这个报错

解决办法得在 Continue 的 config.json 里强行覆盖这个参数。

我把配置改成了这样：

{
  "models": [
    {
      "title": "DeepSeek-Coder",
      "model": "deepseek-coder-v2",
      "provider": "ollama",
      "contextLength": 32768 
    }
  ]
}

注意，那个 contextLength 必须手动写死。改完重启 VS Code，再试一次同样的 50 行代码。

瞬间顺畅了。

为了验证到底快了多少，我随手测了一下响应速度。之前报错的时候是 0 秒直接崩，现在 100 行代码的分析，首 token 响应大概在 1.2 秒，整体生成速度每秒 15 个 token 左右。

对比一下我之前试过的几种配置方案：

| 配置方式 | 响应状态 | 内存占用 (M2) | 上下文支持 |
| :--- | :--- | :--- | :--- |
| 默认配置 | 经常溢出 | ~8GB | 极低 (2K-4K) |
| 手动指定 32k | 稳定 | ~11GB | 足够 (32K) |
| 强行拉到 128k | 极其卡顿 | ~22GB | 很高但慢得离谱 |

看来贪多没用，本地部署得找个平衡点。

别在配置文件的细节上死磕

说真的，很多新手在搞【本地大模型部署Ollama】的时候，最容易在这种“文档没写清楚”的小地方浪费一整天。

我自己之前就是典型的死脑筋，总觉得只要模型下载成功了，剩下的就是点开即用。其实本地 AI 开发最折腾的就是这套链路：模型 → 推理框架 → 插件 → IDE。任何一个环节点不对，结果就是对着报错发呆。

后来我发现，与其自己对着 JSON 文件猜，不如直接去看看别人的工作流交流。在那里面能看到很多人分享的 config.json 优化版本，比如怎么配置不同的模型分别处理代码补全（Autocomplete）和对话（Chat），而不是用同一个模型干所有活，那样效率低得吓人。

避坑指南：关于 Continue 插件配置的几个碎碎念

除了上下文长度，我还发现了几个很烦人的点：

1. 模型名称必须完全一致：你在 ollama list 里看到的名称是什么，config.json 里就得写什么。多一个空格或者大小写不对，Continue 就会告诉你 Model not found。
2. 内存竞争：如果你在跑 Ollama 的同时还开了 Chrome 几十个标签页，M 芯片的统一内存会触发 Swap，这时候你会发现 AI 生成速度从 15 token/s 掉到 2 token/s。建议给 Ollama 留出足够的呼吸空间。
3. 版本更新太快：Continue 几乎每天都在更新。有时候某个功能今天能用，明天重启就没了，这时候得赶紧去刷刷行业动态，看看是不是官方又改了 API 接口。

如果你是纯小白，我建议先从最简单的模型跑通，再尝试复杂的【Continue插件配置】。

以后怎么高效折腾本地 AI？

我现在的习惯是：遇到报错 → 搜官方文档 → 没结果 → 直接去 PromptCube 搜具体的报错信息。

因为那里聚集了大量真正在写代码的开发者，很多人会分享非常具体的AI编程实战经验。比如某次我搞不定本地 RAG 的索引速度，在社区看到一个方案，通过调整向量数据库的参数，把检索时间从 3 秒压到了 0.4 秒。这种实测数据比任何官方宣传语都管用。

本地部署的乐趣就在于这种“调优”的过程。虽然踩坑很烦，但当你配置好一个流畅的本地 AI 编程环境，不用担心隐私泄露，也不用担心 API 没钱的时候，那种掌控感确实很爽。