1. 为什么我决定把代码助手搬回本地
如果你每天写代码都要等云端补全转圈，或者公司内网根本连不上外部 API，那“本地部署大模型辅助编程”这件事就值得认真折腾一次。Ollama 负责在本地把模型跑起来，Continue 负责把它接进 VS Code，两者组合之后，代码补全、对话解释、单元测试生成都能在断网状态下完成。这套方案适合三类人：一是经常在离线环境或隔离网络里写代码的开发者，二是对代码隐私敏感、不想把业务逻辑传到第三方服务器的团队，三是想低成本长期使用 AI 编程辅助、不愿按量付费的个人。
我自己的主力开发机是 32GB 内存的笔记本，没有独立显卡，之前一直觉得本地跑模型是“玩具”。直到把 Ollama 的量化模型和 Continue 的自动补全调通，才发现日常编码里 80% 的补全和解释需求，本地 7B 到 14B 的模型已经能接住。这篇文章就把从零到可用的完整链路拆开讲，包括模型拉取、显存与内存占用配置、Continue 的 config.json 可复制片段，以及断网后怎么验证补全和对话真的在工作。
先明确一个判断标准：本地方案能不能满足日常编码，关键看两点——首字延迟是否低于 1 秒，生成速度是否稳定在 15 tokens/s 以上。低于这个线，补全就会打断思路；高于这个线，体验就接近云端。下面所有配置都围绕这两个指标来调。
2. Ollama 安装与模型拉取：显存占用配置实战
Ollama 是目前本地拉起大模型最省事的工具，一条命令就能把模型下载并注册成本地服务。安装包直接从官网下载对应系统版本即可，Windows 和 macOS 都有图形化安装程序，Linux 用一条 shell 脚本。安装完成后，终端执行ollama --version能看到版本号，说明服务已经就绪。
接下来是模型选择，这一步直接决定显存和内存占用。编码任务对逻辑推理要求高，我实测下来 Qwen2.5-Coder 系列在代码补全和解释上表现最稳。参数规模按你的硬件来选：8GB 显存或 16GB 内存，选 7B 的 Q4_K_M 量化版；16GB 显存或 32GB 内存，选 14B 的 Q4_K_M；32GB 以上显存或 64GB 内存，可以上 32B。量化等级里 Q4_K_M 是甜点，几乎不损失智能，占用却比 FP16 小一半以上。
拉取命令如下，以 14B 为例：
ollama pull qwen2.5-coder:14b-instruct-q4_k_m拉取完成后，别急着直接 run。默认的上下文长度只有 2048，分析一个稍大的文件就会被截断。我们需要用 Modelfile 固化参数，把上下文拉长、把 GPU 卸载层数拉满、把温度调低让代码生成更确定。新建一个名为Modelfile的无后缀文件，内容如下：
FROM qwen2.5-coder:14b-instruct-q4_k_m # 上下文设为 32k，兼顾长文件分析与响应速度 PARAMETER num_ctx 32768 # 最大化 GPU 卸载层数，让推理尽量走显卡 PARAMETER num_gpu 99 # 降低温度，代码生成更稳定 PARAMETER temperature 0.2 SYSTEM "你是一位资深工程师，擅长重构遗留代码、编写单元测试和解释复杂逻辑。回答严格基于当前上下文。"然后用这条命令构建专属模型：
ollama create my-local-coder -f Modelfile构建完成后执行ollama run my-local-coder，随便输入一段代码让它解释。如果首字延迟在毫秒级、生成速度稳定在 20 tokens/s 以上，说明 GPU 已经介入。如果速度只有个位数，大概率回退到了 CPU，需要检查显卡驱动和 Ollama 的 GPU 识别情况。显存不够时，把num_ctx从 32768 降到 16384，或者换更小的量化版本，都能明显缓解。
3. Continue 插件接入 VS Code：config.json 可复制片段
后端跑起来之后，下一步是把它接进编辑器。Continue 是我用下来对本地 Ollama 支持最顺的插件，VS Code 和 JetBrains 全家桶都能装。在 VS Code 扩展市场搜索 Continue 安装，侧边栏会出现它的图标。点击齿轮进入配置，会打开一个config.json文件，路径通常在用户目录下的.continue文件夹里。
这份配置的核心是把默认的云端模型指向本地的 Ollama 服务，地址是http://localhost:11434。下面是我实测可用的完整片段，直接替换原文件内容即可：
{ "models": [ { "title": "Local Coder", "provider": "ollama", "model": "my-local-coder", "apiBase": "http://localhost:11434" } ], "tabAutocompleteModel": { "title": "Local Autocomplete", "provider": "ollama", "model": "qwen2.5-coder:14b-instruct-q4_k_m", "apiBase": "http://localhost:11434", "parameters": { "num_predict": 128, "temperature": 0.1 } }, "context": [ { "name": "codebase", "provider": "codebase" } ] }这里有三处关键配置。第一，models里的model填的是你用 Modelfile 构建出来的my-local-coder，这样对话时用的是 32k 上下文和低温度参数。第二，tabAutocompleteModel单独指向原始模型，并把num_predict限制在 128，避免补全时生成过长内容拖慢响应。第三，context里的codebase让 Continue 能索引当前项目，对话时自动带上相关文件片段。
保存后回到编辑器，Continue 状态栏会变成绿色。此时在代码区输入几个字符，补全建议应该会以灰色文字出现，按 Tab 接受。如果状态栏是红色或黄色，说明连接失败，先确认 Ollama 服务在运行，再检查端口有没有被占用。
4. 断网验证：补全与对话是否真的可用
配置完成后，最有说服力的验证是直接断网。关掉 Wi-Fi，拔掉网线，然后做三件事。
第一件，测试自动补全。新建一个 Python 文件，输入def calculate_，停住。如果本地模型在工作，一两秒内会出现补全建议，比如def calculate_total(items):。按 Tab 接受，再继续输入函数体，观察补全是否连贯。这一步验证的是tabAutocompleteModel配置是否生效。
第二件，测试对话解释。选中一段复杂逻辑，右键选择 Continue 的 Explain 功能，或者在侧边栏聊天框输入“解释当前文件的功能”。本地模型会基于codebase索引返回解释。我实测 14B 模型解释一个 200 行的工具类大约需要 3 到 5 秒，内容准确度足够日常使用。
第三件，测试单元测试生成。找一个递归函数，在聊天框输入“为这个函数生成覆盖边界条件的 pytest 用例”。模型会输出带pytest.mark.parametrize的完整脚本。由于上下文设到了 32k，它甚至能引用同项目其他文件的定义，生成的断言比较精准。
断网状态下这三步都能完成，就说明整条链路已经闭环。所有请求都发往127.0.0.1:11434，没有任何数据离开本机。如果你在隔离网络里开发，这套方案可以直接落地。
5. 常见报错排查：401、local proxy failed 与 reading choices
本地部署虽然不涉及云端鉴权，但配置错位时仍会报错。下面是我踩过的几个高频问题，对照真实报错来排查。
报错一：401 Unauthorized或invalid api key。这通常出现在你误把 provider 配成了 OpenAI 兼容模式，但没填 key。本地 Ollama 不需要 key，检查config.json里provider是否为ollama，apiBase是否为http://localhost:11434。如果用了其他工具转发，确认转发层没有强制鉴权。
报错二：local proxy failed或connect ECONNREFUSED 127.0.0.1:11434。说明 Continue 连不上 Ollama 服务。先在终端执行ollama list，如果能列出模型，说明服务在跑；如果报错，执行ollama serve手动启动。Windows 下 Ollama 默认开机自启，但有时会被安全软件拦截，检查一下后台进程。
报错三：reading choices或unexpected end of JSON input。这多半是模型返回被截断，或者num_predict设得太小。补全场景下 128 够用，但对话场景如果也限制这么小，长回答会被切断。检查models和tabAutocompleteModel的参数是否混用了。另外，num_ctx超过模型支持上限也会导致异常，14B 模型一般支持 32k，别设成 64k。
报错四：生成速度极慢，低于 5 tokens/s。这是 GPU 没介入的典型表现。在终端运行ollama run my-local-coder时观察输出，如果有offloading to GPU字样说明正常。没有的话，检查显卡驱动版本，或者尝试在环境变量里指定架构。内存不足时也会触发交换分区，关掉一些浏览器标签页再试。
排查顺序建议从服务是否运行、端口是否可达、模型是否加载这三步走，大部分问题都能定位。
6. 本地方案够不够用：判断标准与后续接入
回到最初的问题：本地部署大模型辅助编程，到底能不能满足日常编码？我的判断标准是三条。第一，补全首字延迟低于 1 秒，否则会打断思路；第二，对话解释能在 5 秒内返回，否则不如自己看；第三，断网后功能不降级，这是本地方案的核心价值。三条都满足，就值得长期用。
如果你的机器内存只有 16GB，7B 量化模型也能跑，补全体验尚可，但复杂重构会吃力。32GB 内存配 14B 是当前性价比最高的组合，64GB 可以上 32B，逻辑推理会有明显提升。模型不是越大越好，关键是和你的硬件匹配，稳定跑起来比参数规模更重要。
对于需要长期编码辅助、甚至想把 Agent 能力接进工作流的场景，本地 Ollama 服务可以作为统一后端。你可以通过https://taotoken.net/api接入更多模型能力，API Key 在控制台创建，接入文档里有完整的 Base URL、Key 和 Model ID 三件套说明。如果只是验证模型效果，可以直接用模型对话页面快速试；如果是长期编码和 Agent 任务，Coding Plan 会更合适。本地和云端不是二选一，把本地当默认、云端当补充，才是可持续的工作流。
