目录
让跑在自己电脑上的模型写代码。这件事本身几年前就能做，但能做的只是补全——把写了一半的那行补完，仅此而已。“读一遍仓库、改动多个文件、跑一遍测试”这种智能体式的用法，对本地来说太重了。
而从 2025 年底到 2026 年，这一块开始松动了。本文只用一手资料，把现在实际能做到哪一步、又会卡在哪里理清楚。先说结论——能跑。但有一道关口：只要有一个设置没改，它就会一声不吭地坏掉。
📌 关于本文中的数字：基准成绩和模型规格全部取自开发方自己的公布（Mistral AI 官方、Qwen 官方模型卡、Ollama 官方文档、Cline 官方文档、Anthropic 官方）。没有从汇总文章里转手引用——因为在查证过程中，我不止一次遇到汇总文章把某个尺寸模型的分数安在另一个尺寸头上。
1. 变化在哪里——开源模型够到了智能体这一档
最能说明这个变化的，是模型开发方自己开始把“智能体式编程”写进卖点里。
Qwen 的官方模型卡里写着“支持 Qwen Code、CLINE 等绝大多数平台，并具备专门设计的 function call 格式”，也就是说编辑器扩展被指名道姓地写了进去（Qwen3-Coder-30B-A3B-Instruct model card）。这意味着模型这一侧是奔着特定的编程智能体去做的。
Mistral AI 也走在同一个方向上。2025 年 12 月 9 日发布的 Devstral 2 是明确标榜“智能体式编程”的专用模型，而且把小一号的 Devstral Small 2（24B）以 Apache 2.0 开放了出来（Introducing: Devstral 2 and Mistral Vibe CLI）。
只有补全的年代
把写了一半的那行补完。小模型就够用，上下文也可以很短。在本地跑得毫不吃力
一旦变成智能体式
就需要准确地给出工具调用，以及稳稳地撑住长上下文。够到这条线的开源模型已经出现了
2. 工具分两类——Continue 和 Cline 是两回事
把这两者混为一谈就上手，期待和结果就会对不上。它们都是 VS Code 扩展，也都能接 Ollama，但设计思路截然不同。
| Continue | Cline | |
|---|---|---|
| 性格 | 补全、聊天、编辑的组合包 | 自主行动的编程智能体 |
| 角色怎么分 | 每个角色分配不同的模型——chat / edit / apply / rerank / autocomplete |
一个模型从规划一路做到执行 |
| 配置要求 | 低。补全用几 GB 的模型就够 | 高。需要长上下文和准确的工具调用 |
| 适合的用法 | 一边写一边让自己的手更快 | 整件任务交出去 |
Continue 那种“每个角色一个模型”的设计，和本地非常合拍。因为补全可以用又小又快的模型，聊天可以用大模型，分开来使。官方的 Ollama 指南也点名列出了轻量模型用于补全，比如 qwen2.5-coder:1.5b 和 starcoder2:3b（Continue — Ollama guide）。
⚠️ 不过，官方文档推荐的模型有时候是旧的。上面那份指南给聊天推荐的是 llama3.1:8b 和 deepseek-r1:32b，和今天能选到的东西相比落后了好几代。文档里的步骤仍然可用，但模型名不要照单全收，最好按后面“4. 挑模型”重新选一遍。
3. 第一个坑——上下文长度由显存决定
这是本文最重要的一章。不知道这一点，就会掉进“明明搭建成功了，智能体却跑到一半开始胡来”的状态。而且不会报错。
原因出在 Ollama 的默认上下文长度上。它不是固定值，而是按显存大小自动决定的（Ollama — Context length）。
| 显存 | 默认上下文长度 |
|---|---|
| 不足 24 GiB | 4k |
| 24〜48 GiB | 32k |
| 48 GiB 以上 | 256k |
一般的游戏本或游戏主机（显存 8〜16GB）会落在最上面那一行。也就是 4k。系统提示词、文件内容、工具调用的一来一回加起来，智能体轻轻松松就把这点额度用超，于是对话会从最前面开始被悄悄削掉。忘记指令、反复做同一个操作、做到一半忘了目的——原因不是模型笨，而是上下文在门口就被扔掉了。
针对这个用途，Ollama 官方明确写道：“对于网页搜索和编程工具这类负荷较高的工作，请把上下文至少设为 64000 个 token”。设置方式是在启动服务时用环境变量。
OLLAMA_CONTEXT_LENGTH=64000 ollama serve如果你用的是应用版，在设置界面的滑块上也能改。
⚠️ 但也不是加大了就万事大吉。官方同样打了预防针：“上下文长度调大后，运行模型所需的内存量也会增加”。
一旦装不进显存，模型的一部分就会被挤到 CPU 那边，速度会断崖式下降。到底有没有真的生效，用 ollama ps 确认——官方就是这么指引的。模型有没有完整装进 GPU，在这里就能看出来。
Cline 这一侧也有针对同一问题的对策。官方文档推荐“启用 Use Compact Prompt”和“把任务收窄（上下文越小，响应越快）”（Cline — Running models locally）。也就是说，智能体自身的系统提示词就很长，所以专门备了一个把它压缩掉的设置。
4. 挑模型——按显存给出的现实答案
汇总文章里的推荐最好别当真。在我查过的范围里，有把 2025 年年中的模型列为“2026 年推荐”的，也有把 480B 模型的分数写进 30B 模型那一栏的。这里只摆开发方自己公布的数据。
| 模型 | 规模 | 上下文 | 许可证 | SWE-bench Verified |
|---|---|---|---|---|
| Qwen3.6-35B-A3B | 35B（激活 3B） | 262,144（最大 1,010,000） | Apache 2.0 | 73.4 |
| Devstral Small 2 | 24B | 256K | Apache 2.0 | 68.0% |
| Devstral 2（供参考、太大了） | 123B | 256K | Modified MIT | 72.2% |
来源：Qwen3.6-35B-A3B 模型卡（Terminal-Bench 2.0 为 51.5，QwenClawBench 为 52.6）、Mistral AI 官方发布（2025 年 12 月 9 日）。这些分数都是各家自己测的，并非第三方在同一条件下横向测量的结果。
值得注意的是 Qwen3.6-35B-A3B 的“激活 3B”。35B 当中每次真正参与运算的只有 3B，这正是 MoE（Mixture of Experts）发挥作用的地方。这是一种同时追求大模型的聪明和小模型的速度的结构，可以说是很适合本地的设计。
下载体积和所需配置
在 Ollama 的模型库里，qwen3.6 并列提供 27b（18GB）和 35b（23GB）。还有面向 Mac 的 -mlx 标签。
Cline 官方给出的内存参考值是这样的——小模型 16〜32GB，中等规模的编程模型 32〜64GB，大模型加上更大的上下文则要 64GB 以上。
显存 8〜12GB
只做 Continue 的补全。智能体式要么放弃，要么和云端搭配着用
显存 16〜24GB
Devstral Small 2（24B）进入射程。因为还得留出加大上下文的余地，量化是必须的
显存 24GB 以上 / 统一内存 32GB 以上
Qwen3.6 的 27b/35b 就现实了。默认上下文也会升到 32k
Mistral 写道，Devstral Small 2 “在消费级 GPU、甚至仅有 CPU 的配置上也能运行”。不过“能跑”和“以智能体的身份跑得够快、足以实用”是两码事，这一点最好记在心里。
5. 搭建——最短路径
① 装好 Ollama，设定上下文
顺序很重要。在拉模型之前先定好上下文长度。
OLLAMA_CONTEXT_LENGTH=64000 ollama serve安装步骤本身在Ollama 完全指南里讲过了，请参考那一篇。
② 拉取模型
ollama pull qwen3.6:27b显存吃紧就选 Devstral Small 2。这两者都是奔着智能体式用法做出来的模型，这正是它们和通用聊天模型的区别所在。
③ 确认是否装在 GPU 上
ollama ps这一步别跳过。一旦被挤到 CPU 那边，体感会完全变成另一回事。“本地 LLM 太慢没法用”这类感想，多数其实源头就在这里。
④ 接上扩展
不管是 Cline 还是 Continue，都是在提供方里选 Ollama，然后填 http://localhost:11434。Cline 官方的提醒很朴素——“发送提示词之前，先确认 Ollama 已经启动”，不需要什么特别的配置。
如果用 Cline，请顺手启用 Use Compact Prompt。
6. 和云端的差距，其实越来越难量了
这一点我想坦白写出来。“本地模型追到了云端的百分之多少”这种比较，现在是拿不出漂亮结论的。原因是基准测试已经对不齐了。
开源模型这一侧会公布 SWE-bench Verified。Qwen3.6-35B-A3B 是 73.4，Devstral Small 2 是 68.0%。而另一边，前沿模型正在离开这个指标。
事实上，Anthropic 的 Claude Opus 5 发布内容里根本没有 SWE-bench Verified 的数字。列出来的是 Frontier-Bench v0.1、CursorBench 3.2、AA Coding Agent Index、FrontierCode 1.1，而且多数是相对说法而非绝对数值（比如“把 Opus 4.8 的性能提升到两倍以上”“在 Fable 5 峰值分数的 0.5% 以内”）。
⚠️ 所以看到“本地已经是 Claude 的百分之多少”这种数字，最好先怀疑一下。很可能是比较的两方并没有用同一个指标测过，或者拿来比的是好几代之前的 Claude。如今还能用 SWE-bench Verified 摆在一起比的，也就只剩开源模型彼此之间了。
即便如此仍能说清的差距
就算数字对不齐，结构上一定会拉开差距的地方还是很清楚的。
本地占优的地方
代码不出本机、没有按量计费（不必在意跑了多少次）、离线也能用、没有速率限制
云端占优的地方
跨多个文件的推理、长时间自主执行的稳定性、不需要前期投入、模型会自动变新
差距最容易出现在“跨多个文件的推理”上，是有原因的。那是一个大量消耗上下文、把几十次判断层层叠加起来的过程。单次判断的精度差，会随着每一轮来回被乘上去。修改单个文件时察觉不到的差距，到了仓库规模的作业上就变成实打实的体感。
7. “本地是免费的”，真的吗
不会收到 API 账单是事实，但这并不等于免费。只是成本换了个形状而已。
| 项目 | 本地 | 云端 |
|---|---|---|
| 前期费用 | 大显存 GPU / 大容量统一内存 | 无 |
| 用得越多越增加的费用 | 只有电费 | 按 token 计费或订阅 |
| 不易察觉的费用 | 配置和维护的功夫、跟进模型更新 | 无（由提供方承担） |
所以“哪个更便宜”会随着比较条件而反转。如果你已经有一块 24GB 级别的 GPU，本地几乎是零额外成本地跑。如果没有，那块 GPU 的钱够买好几年的订阅了。更准确的看法是：答案取决于两点——“是不是每天大量地跑”和“设备是不是已经有了”。
8. 该怎么分工的结论
能构成选择本地的理由
代码不能外流（合同、内部规定）、设备已经有了、想不计次数地反复试错、需要离线作业
不能构成理由的
“因为免费”（没把设备钱算进去）、“因为看着快”（多数情况下云端更快）
最现实的做法是两者并用。把 Continue 的补全交给本地的小模型常驻运行，成块的活儿交给云端的智能体。补全次数多而每次很轻，适合本地；智能体次数少而每次很重，适合云端——负荷的形状正好相反。
总结
- 开源模型已经够到了智能体式编程。Qwen 和 Mistral 都推出了点名编辑器扩展的专用模型
- 最大的关口是 Ollama 的默认上下文长度。显存不足 24GiB 就是 4k，智能体会悄无声息地坏掉。官方推荐是编程用途设到 64000 以上
- 调大之后要用
ollama ps确认模型是否在 GPU 上。被挤到 CPU，慢的程度就完全是另一回事了 - Continue 和 Cline 是两回事。前者按角色分配模型，属于补全型；后者是自主智能体。两者的配置要求不同
- “相当于云端百分之多少”这种比较越来越站不住脚。前沿这一侧正在不再公布 SWE-bench Verified
- 不是“免费”，而是“费用的形状不同”。设备是不是已经有了，会让答案彻底反转
FAQ
Q1. 显存 8GB 的 GPU 也能用智能体式吗？
很勉强。因为就算模型本体装得下，也不剩下加大上下文的余地。Ollama 的默认值在显存不足 24GiB 时会降到 4k，而把它调到 64000 又会增加所需内存——8GB 很难兼顾两头。现实的做法是只做 Continue 的补全，或者只把补全放本地、智能体交给云端，两者并用。
Q2. Cline 和 Continue，该从哪个开始？
如果是第一次接触本地 LLM，选 Continue。因为它配置要求低，跑不起来时也更容易定位问题。先确认补全能舒服地运行，再往智能体式推进，这样就能把问题是出在模型还是出在配置分开来想。
Q3. Mac 上也能跑吗？
能跑。统一内存可以直接当显存用，反而更容易装下大模型。Ollama 的模型库里也备了 qwen3.6 带 -mlx 的标签（面向 Apple Silicon）。不过“默认上下文长度由内存量决定”这条规则同样生效，所以还是要确认一下。
Q4. 哪个模型“最聪明”？
单看公布的分数，本文列出的这些里最高的是 Qwen3.6-35B-A3B 的 SWE-bench Verified 73.4。但这是各家自己测的，并非第三方的横向比较。在实际工作中，许可证（Devstral Small 2 和 Qwen3.6 都是 Apache 2.0）以及能不能装进你手头的显存，反而更起作用。
Q5. 为什么会“不报错却坏掉”？
因为超出上下文长度的部分不是按错误、而是按截断来处理的。模型会针对“递给它的那一段”正常作答。结果就表现为忘记指令、反复做同一个操作、丢失目的，看上去就像模型能力不够。知不知道这是该去怀疑配置的症状，定位问题的速度会差出很多。
Q6. 量化该选哪一档？
拿不准就从 Q4_K_M 这一档起步比较稳妥。各种格式的区别（GGUF / GPTQ / AWQ）和挑选方法，都整理在量化格式完全指南里。在编程用途上，“用稍小一点的模型、把量化放松些”往往比“把模型做大、量化压得更狠”更稳定——因为工具调用的格式必须一字不差地遵守。
Q7. 用在公司的代码上没问题吗？
只要全流程都在本地完成，代码就不会外流——这是本地 LLM 最大的优点。不过要检查扩展这一侧的设置。即便把提供方指向了 Ollama，遥测或者别的功能仍有可能对外通信。另外，“内部规定允不允许”是和技术无关的另一个问题，请先确认公司的规章。
相关文章
- Ollama 完全指南——安装与基本命令
- 本地 LLM 推荐模型深度对比——按用途和尺寸怎么挑
- 跑本地 LLM 需要什么样的电脑——显存与 GPU 速查
- 量化格式完全指南——GGUF/GPTQ/AWQ 怎么选
- 本地 LLM 和云端 LLM 的区别——性能差距与选择方法
