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

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