最近两个模型比较热门：Qwen3.5-27B 和谷歌的小模型 Gemma 4 31B。我也做了一些实际测试，整体来看，Qwen3.5-27B 表现非常不错，基本可以胜任本地自动化编程任务。
一、硬件部分
1. GPU（核心）
建议显存 24–32GB。虽然目前有 AMD、Intel、英伟达、DGX 以及苹果 Mac Studio / Ultra 等多种选择，但对于 20GB 级别的稠密模型来说，英伟达消费级显卡在性价比和生态上仍然是首选！例如 RTX 3090、4090。
- 实际体验：
- 推理速度低于 15 token/s 时，本地编程实用性明显下降
- RTX 3090 初始速度约 30–40 token/s（取决于模型）
- 长上下文（150K–180K）下降至约 20 token/s
- 关键结论：
推理速度主要取决于显存带宽，与其它 GPU 算力关系不大。 RTX 4090 相比 3090 提升大约只有 ~10%
2. CPU 和内存
要求相对较低：
- CPU 性能影响不大
- 内存建议 ≥ 32GB， 我现在内存64GB大致有10-20GB空置。
- 内存带宽影响也有限
3. 操作系统
- Linux 稍快，但使用不够方便。
- Windows 与 WSL 差异不大，部署难度接近
4. 显示输出优化
建议将显示器连接主板 iGPU 输出，可释放约 0.3–1GB 显存用于模型推理。
二、模型选择
首选模型：Qwen3.5-27B
- 综合能力接近主流在线付费模型
- 40B 以下模型大多数无需再测试（完败给Qwen3.5-27B）
可选量化模型：
- unsloth Qwen3.6-27B-UD-Q4_K_XL.gguf（约 17GB， ctx-size=160K）
- unsloth Qwen3.6-27B-Q5_K_M.gguf（约 19GB， ctx-size=110K） Q5_K_M 模型质量要好不少，但是只适合不太复杂的情况。最理想情况是跑Q6或者Q8。
注意：
- 上面两个模型，需预留 ≥4GB 显存用于 KV cache（长上下文）
- 因为GPU存储的限制，更大的模型基本只能用于对话，不适合长文本编程。
三、软件部分
1. 推理框架
- 首选：llama.cpp（Linux / Windows 均可）
- 建议单用户使用
llama.cpp的一些优化分支（提升速度 / 减少缓存）仍不成熟，例如：
- TurboQuant 分支：
- 支持超长上下文（3090卡：ctx-size >180K）
- 但速度下降约 50%
2. 编程工具
可选方案很多，本地 LLM 基本都能接入：
- Claude Code（更稳定）
- Open Code（灵活性更强）
- VS Code (更直观，有利个人参与)
3. 多 Agent 协作
Hermes 在以下方面很有帮助：
- 软件设计
- 任务规划
- 测试管理
推荐工作流：
- Hermes：负责规划与拆解任务
- Claude Code：执行代码生成
优点：
- 两者共享本地模型，理解一致
- 协作效率较高
局限：
- 高层设计仍建议借助云端模型辅助
- 有运行到死胡同现象，人需要干预，让推理死胡同中跳出来。这在小模型上比较常见，Qwen3.6-27B还能忍受。就是云端模型也有这个现象。
四、测试结果
1. 推理与长文本能力
- Qwen3.5-27B 在推理和长上下文测试中表现稳定
- 之前需要与 Claude 4.5 多轮交互的问题，现在基本一次完成
四、测试结果
1. 推理与长文本能力
- Qwen3.5-27B 在推理和长上下文测试中表现稳定
- 之前需要与 Claude 4.5 多轮交互的问题，现在基本一次完成，但现今云端模型仍然有优势 （都这么说）。
2. 编程测试
进行了从 0 开始的项目复刻测试：
- DOOM（Python）：
- 约 150 个文件
- 用时 3 -4天（未使用 Hermes）
- RuneScape 类项目：
- 约 50 个文件
- 用时 1 天（使用 Hermes）
测试均取得良好开端！
五、整体感受
本地模型已经进入“可用阶段”，不再是“能跑但不好用”的状态。RuneScape有一个Bug我让Hermes查，Hermes奔溃。让云端Claude查，查了一段时间也查不出，进入死胡同。Open code 也崩溃了。最后是当地Claude Code和我一起查出 （Claude Code看不到机器上的一些运行数据，我需要查到后给它）
当前瓶颈：
- 24GB 显存在复杂任务下开始吃紧。跑大模型显存总在吃紧状态，我以前编的软件，自己做的也都在100个文件以下，24GB大致凑合用。
现在上下文长度常在 100K–150K 波动，实在没有办法，就用TurboQuant。
