最近兩個模型比較熱門：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。
