最佳用於程式開發的開源 LLM：我們測試中的 48 倍成本差距

簡短答案：GLM-5.2 目前是最強的開源 coding LLM——在長時間使用下，其輸出品質接近 Claude Sonnet 級別，也是我們會交付最棘手問題的模型。不過它也很慢、很吃 token，所以若要做快速的 API coding agent，請選 Kimi K2.7 Code；若要最低成本，選 DeepSeek V4 Flash；若要在你自己的 24GB GPU 上使用，選 Qwen3.6-27B。

這是將相同的兩個編碼任務交給五個開源旗艦模型，並以 Claude Opus 4.8 作為封閉原始碼參考後得出的結論。它們全都產生了正確的程式碼。真正拉開差距的是它們為此消耗了多少 token，而這個差異在成本上高達 48 倍。

關於用語有一點說明：這些模型幾乎全部在技術上都屬於 open-weight 模型：權重是免費的，但訓練資料不是。我們之所以說「open source」，是因為這是大家搜尋的用語。這個區別只會影響下面的一個 FAQ 答案。

我們如何測試

兩個任務，每個模型皆使用相同提示，於 2026 年 7 月 17 日以預設設定送出：

• 任務 1: 編寫一個具有棘手邊界情況的持續時間解析函式（12 個測試案例）
• 任務 2: 修正一個有錯誤的區間合併函式（6 個測試案例）

我們在本地對程式碼進行評分，並為每次執行記錄三個數字：通過率、輸出 tokens，以及實際耗時。成本是 tokens 乘以各家供應商的標價，而我們在同一天已完成驗證。兩個任務只能算是探測，而不是基準測試，但這類例行請求正是你會發送數百次的那種。

結果

每個模型都通過了每個測試案例。因此，下面的表格只關乎一件事：效率：

token 欄位就是故事本身。GLM-5.2 和 MiniMax M3 是「思考」模型：預設情況下，它們會先長時間推理再回答。這些推理會被計為輸出。對於相同的正確函式，GLM-5.2 產生的 token 數量是 Kimi K2.7 Code 的 3 倍。

有 token 上限時情況更糟。當我們把回應限制為 2,048 tokens 時，兩個 thinking models 都把整個額度用在推理上，最後完全沒有輸出任何 code。你付了錢，卻什麼都得不到。GLM-5.2 需要把上限提高到 16,384 tokens 才能完成，而且它兩次失敗嘗試本身就花了約 $0.045。如果你在 coding agent 中使用 thinking model，請提高 max_tokens，或在例行編輯時關閉 thinking。

作為比較，Claude Opus 4.8 只用了 539 個 tokens 就解決了這兩個任務。開放模型在正確性上已經追上；但在簡潔性方面，封閉式基準仍然領先 4 倍。

依部署層級分類的最佳開源編碼模型

依模型將在哪裡執行來選擇。價格以每 1M tokens 計算，已於 2026-07-17 驗證。

最強模型，如果你能等得起：GLM-5.2

在高難度、多步驟的程式設計工作中，GLM-5.2 的輸出品質是目前開放模型中最接近 Claude 級別的——它在代理式基準測試（SWE-Bench Pro、Terminal-Bench 2.1）中領先，而在我們自己的長期使用中，它是我們最信任能處理其他模型常常出錯問題的那一個。更多內容請見我們的 GLM-5.2 API 指南。

那種品質的代價就是耐心。它是我們測試中最慢、最吃資源的模型（Task 1 為 99.3s 和 5,695 tokens），而且緩慢的服務表現更多反映了供應商端受限的 GPU 容量，而非模型本身。輸入 $1.40 / 輸出 $4.40，1M context，純 MIT。把困難問題和大量 token 預算交給它；快速編修則分流到其他地方。

最適合快速 API 編碼代理：Kimi K2.7 Code

我們測試過最具 token 效率的開放模型：它的錯誤修復只用了 259 個 tokens，簡潔程度如 Claude。它也以 60.7% 領先 Kilo 的任務完成基準測試。

價格：$0.95 in / $4.00 out，快取命中時 $0.19。唯一真正的限制是上下文：262K tokens，而本清單的其他項目提供 1M。若要了解它與最接近的競爭對手相比表現如何，請參閱 Kimi K2.7 Code vs GLM-5.2。

最佳價值：DeepSeek V4 Flash

$0.14 輸入 / $0.28 輸出，遠遠是這裡最便宜的模型，而且它仍然通過了我們丟給它的所有測試，在開源模型中速度最快。它公布的分數（79.0% SWE-Bench Verified、91.6% LiveCodeBench）只比它的「大哥」低兩個百分點以內。context 為 1M tokens，license 為標準 MIT。

從這裡開始。只有在多檔案工作開始顯露差距時，才升級到 V4 Pro。

最適合 24GB 消費級 GPU：Qwen3.6-27B

一個精簡的 27B，在 SWE-Bench Verified 上拿下 77.2%，來自一個可裝進單張消費級顯示卡的模型所提供的旗艦級鄰近分數，這就是為什麼它會在 r/LocalLLaMA 的討論串中反覆成為答案，而這些討論串通常以「I have 24GB of VRAM.」開頭。

它更快的兄弟型號 Qwen3-Coder-Next（總計 80B，每個 token 僅 3B active，Apache 2.0）是社群中的速度首選：有位使用者 在單張 RX 9070 XT 上、以完整 262K context，將其以約 20 tokens/s 的速度執行。如果你更想透過 API 來呼叫，它可經由 Alibaba Cloud 以 $0.30/$1.50 起跳。

最佳單 GPU 自架：Gemma 4 31B

根據 Google 的 model card，31B 可在一張 80GB H100 上以 256K context 執行，並採用 Apache 2.0。12B 變體可在 16GB 的 VRAM 中執行。

一個尺寸陷阱：MoE models 宣稱只有較小的「active」參數數量，但你仍然必須儲存完整權重。DeepSeek V4 Flash 每個 token 啟用 13B，但總權重達 284B，即使是 4-bit 也約有 142GB。那是多 GPU 專案，不是一張單卡就能搞定。

長時間自主運作的最佳平價之選：MiniMax M3

1M context 僅需 $0.30/$1.20，專為多小時的 agent 會話打造——MiniMax 已展示過一次 12 小時無人看管的研究執行。它延續了你在結果表中看到的思考模型冗長輸出風格，因此請相應預算 token。當在長時間執行中品質比成本更重要時，上面的 GLM-5.2 就是升級選擇。

排行榜沒告訴你的事

基準測試數字現在已相當接近：Stanford's AI Index 發現，第一名與第十名模型之間的差距在一年內從 11.9% 縮小到 5.4%。成績表仍然隱藏的三件事：

每項任務成本勝過每個 token 成本。 GLM-5.2 的 $4.40 輸出價格看起來接近 Kimi 的 $4.00。經過實際 token 計算後，同樣的工作成本高出 3.5 倍。Kilo 的即時統計顯示了極端情況：DeepSeek V4 Pro 在 $0.87 的標價下，平均每次完成基準測試嘗試的成本為 $15.91。

相同的模型，不同的執行框架，不同的結果。 一個模型放在設計良好的 agent 迴圈中（結構化工具、重試、合理的 token 限制）所表現出的行為，和同一個模型在原始聊天呼叫中的表現完全不同。我們的 GLM zero-code 失敗是設定互動問題，而不是能力不足。

每個基準測試衡量的是不同的工作。 LiveCodeBench 是演算法生成；DeepSeek V4 Pro 以 93.5% 的成績勝出，超過閉源模型已公布的分數。SWE-Bench Verified 是倉庫層級的錯誤修復；Claude Mythos 5 仍以 95.5% 領先，而開源模型約在 80% 左右。在相信排名之前，先將基準測試對應到你的實際工作。

更換 Claude 訂閱方案

推動開源的一個常見誘因：在工作日進行到一半時碰到 Claude 的訂閱限制。這筆帳算得通。我們的雙任務探測在 DeepSeek V4 Flash 上花費了 $0.00066；即使一天有幾百次這樣的呼叫，總成本仍然低於一美元。

切換也比以前少了許多繁瑣的設定。DeepSeek 發佈了一個與 Anthropic 相容的 endpoint（api.deepseek.com/anthropic），因此 Claude Code 只要透過變更環境變數就能驅動它；相同的設定也適用於 GLM-5.2。而且，如果你想把 Claude 留給棘手的問題，同時將例行工作路由到開放模型，像 AIReiter 這樣的平台可透過相同的 Anthropic 相容介面，以定價的 20% 提供 Claude。

Kimi K3：值得關注的選擇

Moonshot 於 2026 年 7 月 16 日推出了 Kimi K3，而在前端工作方面，它已經超越了最強的封閉模型：在 Frontend Code 排行榜上以 1,679 分名列第 1，勝過 Claude Fable 5 的 1,631 分，而早期實測報告也指向相同的方向。

它沒有在這裡上榜，原因只有一個：權重將於 7 月 27 日開放。在那之前，它在 $3/$15 是一個封閉 API。等它們一上線，K3 就會成為截至目前發布的最大 open-weight 模型，而上面的前端數據顯示，它有望角逐這份榜單的榜首。我們會另行追蹤 K3 open-weights 發布。

如何選擇

1. 會在哪裡執行？ 低於 16GB VRAM：使用 API（Gemma 4 12B 可在本地執行，但預期品質會明顯下降）。24GB：Qwen3.6-27B。一張 H100：Gemma 4 31B。API：在 DeepSeek V4 Flash 直到證明不足為止。2. 是什麼類型的工作？ 快速編輯偏好簡潔模型：Kimi K2.7 Code 或 DeepSeek。棘手問題和長時間的 agent 執行偏好 GLM-5.2（或預算有限時選 MiniMax M3），並搭配充足的 token 預算。3. 授權限制？ MIT（GLM、DeepSeek）和 Apache 2.0（Qwen、Gemma）沒有額外限制。Kimi 的修改版 MIT 增加了一條署名規則，且只會在非常大規模的商業用途時才會觸發。

常見問題

2026 年最適合程式編寫的最佳開源 LLM 是什麼？

GLM-5.2 具有最高上限——在困難問題上的輸出接近 Claude Sonnet 級別，但代價是速度較慢。Kimi K2.7 Code 在 API agents 的 token 效率上勝出，Qwen3.6-27B 適合本地硬體，DeepSeek V4 Flash 則在成本方面表現最佳。

我可以免費在本地執行這些模型嗎？

權重是免費的；硬體不是。27B 模型需要 24GB GPU，Gemma 4 31B 需要 80GB，而擁有萬億參數的旗艦模型只能透過 API 或叢集使用。

開源與開放權重有什麼差別？

Open-weight 意味著權重是公開的，但訓練資料和程式碼是私有的，這描述了這裡幾乎每個模型。完整的 open source 模型（OpenCoder、StarCoder2、IBM Granite Code）則會公開所有內容，但在能力上仍稍有落後。

有沒有一個開源 LLM 在程式編寫方面和 Claude 一樣好？

在演算法基準測試上，確實如此：DeepSeek V4 Pro 的 93.5% LiveCodeBench превос過已公開的封閉模型分數。在倉庫層級修復方面，Claude 仍然領先（95.5% vs ~80% SWE-Bench Verified）。在我們的測試中，開放模型在正確性上與 Claude 持平，但使用的 token 數量多出 4–13 倍。

哪個開源 LLM 最適合 C++ 或小眾語言？

Kimi 的 K2 系列在小眾語言方面擁有最強口碑（Moonshot 特別點名 Zig）。至於 C++，社群共識則偏向 DeepSeek V4 Pro 和 Qwen3 Coder Next。不管你選哪一個，都要在自己的程式碼庫上測試；小眾語言的品質差異，遠比 Python 基準測試所顯示的更大。