Sol 6.1做规划、本地Qwen 27B写代码，API费用省77%
Sol 6.1 今天发布了，我想知道的第一件事是：当智能模型本身已经很便宜时，“架构师/编辑”的职责分工是否仍然划算。
简单版：就API支出而言，划算。我用三种方式分别构建了三个小型3D游戏（台球、保龄球、桌上足球）：
| 游戏 | 仅用Sol | Sol规划，本地Qwen 3.8 27B编码 | 仅用Qwen 27B |
|---|---|---|---|
| 台球 | $0.39 · 2.9分钟 | $0.05 · 18.6分钟 | $0.00 · 43.1分钟（尝试） |
| 保龄球 | $0.14 · 1.7分钟 | $0.06 · 13.7分钟 | $0.00 · 34.7分钟 |
| 桌上足球 | $0.22 · 2.0分钟 | $0.06 · 11.1分钟 | $0.00 · 36.4分钟 |
| 总计 | $0.75 · 6.6分钟 | $0.17 · 43.4分钟 | $0.00 · 114.2分钟 |
也就是说，比仅用Sol省了77%。本地用的是一块RTX 3090（24 GB）。
它的原理相当无聊：一次编码运行中，绝大多数token都是代码本身，规划和审查只占很小一部分。因此，只要昂贵模型只负责拆分任务并阅读返回结果，输出的大头就落在那个你不按token计费的模型上。
这和aider的architect模式是同一个思路，区别只是把编辑端放在你自己的GPU上，而且可以并行跑好几个。
需要注意的地方：
* 速度慢。三个游戏用了43分钟，仅用Sol时不到7分钟。本地GPU决定了节奏。
* 节省不恒定。台球省87%，保龄球省57%。每个游戏只跑了一次，所以77%不是我声称的固定值。
* 这只是API支出。GPU和电费仍然是我自己的。
* 规划者只检查承诺的文件是否存在，不检查它们是否正确。其余的得靠审查来兜底。
我运行这个的工具是Atomic Agent，开源，里面有个叫Fusion的模式就是这样（免责声明：我参与开发）。但这种分工本身适用于任何能分别设置规划模型和编辑模型的工具。
好奇是否有人摸到过这个下限：在往返沟通把节省消耗殆尽之前，你用过的最小本地模型是什么，它在一个强大规划者手下还能撑住当“手”？
―― 高票评论（帖子共21条讨论）――
[+8] u/Kimi_Antonelli_12：与其用本地模型跑在24 GB上，我发现通过OpenRouter通常有更好的免费选项。
[+4] u/MrKyleOwns：大概还是比你自己写的代码强 lol
[+5] u/Aeroxin：我想知道这和“6.1 Sol做规划 + 6 Luna做编码”相比会怎样。
[+3] u/Individual_Code_7081：本地27B编码慢了3-7倍，但成本省了很多
[+3] u/mrASSMAN：27B其实并不是免费的，不是吗……你没有算电费
（更抽象地说，如果它拖慢了你的工作，时间就是钱）
[+2] u/GapNew4766：有几个人问规划/执行分工是怎么设置的，写在这里了：https://atomicagent.io
[+1] u/pseudoreddituser：多等15分钟根本抵不上省下的35美分
[+1] u/m3kw：把规划的成本贴出来
[+-2] u/Reasonable-Sign8458：你还漏了一个问题
代码简直是垃圾