本地大模型能替代 DeepSeek 写代码吗？8 道题实测

本地大模型现在跑得很顺，长上下文也装得下了。但”跑得动”和”能当你的编程 Agent 主脑”是两回事。Agent 要自己规划、调用工具、改代码、跑测试、读报错再改，一步错可能步步错，速度和可靠性一样重要。本地模型到底顶不顶得住，我们做了一个尽量公平的对照实验。

怎么测的

我们用同一个 agent 框架（opencode 的 headless 模式），同一套提示词、同样的工具与权限，只换”大脑”：两个本地模型对云端 DeepSeek V4 Flash API（快档）。
本地这边是双张 RTX 3090、每卡一个模型，都由 NInfer 的 3090 社区移植版驱动。GPU0 跑 Qwen3.8-27B base（官方 groupwise 量化权重），GPU1 跑的是 UkisAI 基于 Qwen3.8-27B 的编码向微调版 Swift 1.5（W4A16 量化）。
题目放在一个受控的小沙箱里，共 8 道，全部有可检验的客观判据，比如文件是否改对、pytest 是否通过、事实是否准确。每题每个模型单跑一次，并关闭插件以隔离变量。本文所有数字来自这次真实实验，非转载、非厂商标称。8 道题覆盖：定位信息、修 bug 并跑测试、新增带边界条件的函数、读一份长部署文档做精确摘要、重构函数签名、改环境变量、遵守负向约束并诚实报告、目录重构并改导入。

成绩单

任务	本地 base	本地 Swift	云端 DeepSeek
定位常量	达成 5s	达成 17s	达成 5s
修 bug + 测试	达成 13s	达成 9s	达成 7s
新增函数 + 除零测试	达成 21s	达成 16s	达成 12s
长文档摘要	达成 15s	达成 13s	达成 5s
重构 + 全部通过	未达成 15s	未达成 14s	达成 12s
改环境变量 + 测试	达成 38s	达成 22s	达成 12s
负约束 + 诚实报告	达成 46s	达成 17s	达成 9s
目录重构 + 改导入	部分 28s	部分 41s	部分 11s

表里”部分”指重构本身正确、但 pytest 未全绿（目录重构题三个模型都没修沙箱里那个既有 bug，故并列）。按”部分计 0.5 分”严格算，本地 base 与 Swift 各 6.5/8，云端 7.5/8。

最直观的结论：本地离云端不远

在”范围明确”的编程任务上——找文件、改 bug、加函数、读长文档——本地模型几乎不掉队。工具调用、边界条件、长文提取都能正确完成，输出也干净。一张消费级显卡上的 27B，已经能把编程 Agent 的常规动作做对。

差距在哪：一是速度，二是”收口”

速度上，云端平均每题约 9 秒，本地约 18 到 23 秒，快了 2 到 2.5 倍。这个差距主要来自 GPU 推理本身（测试期间本地卡上还跑着其他服务，并发高时会更慢），绝对值对交互仍然可接受。

更值得说的是”收口”。有一道题要求重构一个函数并让 pytest 全部通过，但沙箱里藏着一个既有 bug：另一个测试本来就是失败的。同一道题，三种反应：

> 云端：自行推断”要全绿，就得把这个 bug 也修了”，直接修好，全绿。

> 本地 base：改完被要求的函数，看到失败，停下来问”要顺手修吗”。

> 本地 Swift：声明”超出任务范围，没动”。

差距不在会不会，在”要不要替你把活干完”这件事上稳不稳。

不过并非绝对：在另外两道同样要求”全绿”的题里，本地模型也主动把既有 bug 顺手修掉了——它不是不会，而是不如云端稳定。有意思的是，另一道目录重构题里，云端也同样停下来了。所以这更像处理歧义的风格差异，而不是硬能力差距。

一个意外发现：谁都没糊弄

面对”不许改源码、却要新增一个依赖不存在函数的测试”这种负向约束，三个模型都遵守了约束，如实报出失败，没有一个去篡改测试凑绿。本地模型还额外主动指出沙箱里那个既有 bug，甚至提醒别把硬编码的 SECRET_TOKEN 提交进仓库。这种不硬凑的诚实，在 Agent 场景里其实很重要。

但要泼一盆冷水

这 8 道题都是小型合成任务，单文件、单步为主，远小于真实编程 Agent 的负载。大代码库、长会话、几十次工具调用、复杂规划、报错恢复，以及插件和技能带来的增强上下文，这次都没覆盖。

而且每题只跑了一次、8 道题的样本也偏小，个别题目的胜负可能来自方差。所以结论只适用于”小范围、明确”的任务，不能外推到”本地模型可以替代云端做主 Agent”。

所以怎么用

一句话：看你的活是什么。

你的场景	建议
范围明确的小活、数据不想出本机、不想按量计费	本地模型已经够用
长链路协调、多约束收口、高并发	云端更稳、更快
想两头兼顾	云端当主脑，本地跑子任务

本地模型已经不再是”能不能用”的问题，而是”用在哪一层”的问题。