本地模型用於編碼的可行性

Thoughtworks 傑出工程師 Birgitta Böckeler 近日釋出技術筆記，重新審視了本地執行 AI 模型進行編碼的可行性。她此前因失望而長期未使用本地模型，但近期眾多關於模型進步的聲稱促使她再次投入實驗。本文是她基於 M3 Max（48GB RAM）和 M5 Pro（64GB RAM）兩款 Apple Silicon 機器，為期約四周的實踐經驗總結。

Böckeler 主要關注代理編碼（agentic coding）場景，而非簡單的自動補全。她評估了影響模型可行性的眾多因素，包括 RAM、處理能力、記憶體頻寬、引數量、推理能力、工具呼叫能力、模型格式、量化級別、架構（如 MoE）以及上下文視窗大小等。她強調，這些因素相互交織，使得評估最佳配置變得複雜。

RAM 是最核心的約束條件。模型權重必須適配可用記憶體，否則會崩潰或速度極慢。在 48GB 機器上，她主要使用 15-25GB 的模型，30GB 模型則逼近極限；64GB 機器上她曾執行 48GB 模型，但隨後崩潰。處理速度方面，兩個機器的表現均比一年前有巨大提升，但會隨對話長度增加而下降。記憶體頻寬方面，兩臺機器均約 300 GB/s，未明顯成為瓶頸。

引數量方面，更大引數通常帶來更好質量，但也需要更多 RAM。她嘗試了 Qwen3 和 Gemma 4 系列，其中 Qwen3.6 35B MoE 在引數數量與 RAM 消耗間取得了最佳平衡。推理功能預設開啟，但她發現小模型常陷入推理死迴圈，關閉後不僅速度更快，效能也持平或略優。工具呼叫是代理編碼的關鍵，模型常產生格式錯誤的呼叫，但通常能自我修正。格式方面，GGUF 和 MLX 的體感速度差異不大。量化方面她僅嘗試了 Q4/4BIT。上下文視窗至少需要 32K-64K，這進一步消耗 RAM。

她使用的具體模型包括：Qwen3.6 35B-A3B MoE Q4 GGUF（22 GB）、Qwen3.6 Coder Next 80B MoE GGUF（45 GB）、Gemma 4 12B Q4 GGUF（7.5 GB）、Gemma 4 26B 4BIT MLX（15.6 GB）和 Gemma 4 31B 4BIT MLX（29 GB）。執行時方面，她主要使用 LM Studio，因其使用者體驗良好；同事中最常提到的替代方案是 oMLX。

Böckeler 總結道，本地模型在自動補全場景下已較為可用，但用於代理編碼時質量仍參差不齊，遠不及大型雲模型。後續筆記將詳述具體編碼任務的體驗。