2026 年 8 月最佳本地程式碼 LLM（依 VRAM 分類）：Qwen3-Coder 30B、gpt-oss-20b、Qwen 2.5 Coder 7B

2026年8月最適合編碼的本地LLM，首先由你的VRAM決定。如果你有24GB的顯示卡——RTX 3090或4090——請執行Qwen3-Coder-30B-A3B-Instruct：總參數30B，但每個token僅啟動3.3B，擁有262,144個token的上下文視窗，以及我們能驗證的最佳全能本地編碼數據。在16GB上，則是gpt-oss-20b，這是O​penAI的Apache-2.0 Mixture-of-Experts模型，可完全放入GPU，約佔14GB，速度約為每秒140個token。在8GB上，則是Qwen2.5-Coder-7B，這是在約4.7GB下穩定可靠的主力模型。本頁其餘部分將說明理由、實測數據，以及上述每個選擇在哪些特定情況下並不適用。

第一頁做對了什麼——以及它略過了什麼

目前針對「best local llm for coding」的排名，混雜著一篇真正有用的文章，以及大量憑藉網域權威而排上來的內容。Tembo 的指南（2026 年 6 月 5 日）架構正確——它按 8GB / 12–16GB / 24GB 等級分類，並以 Qwen Coder 系列為結論——但它沒有公布本地模型的基準測試分數、每秒 token 數、上下文視窗大小，也沒有按 RAM 給出 Apple Silicon 的推薦。GitHub 上的評估框架（gauravvij/local-llm-coding-eval）有真實數據，但沒有結論，而且只在 CPU 上執行。其餘都是單一作者的觀點文章（XDA、Yahoo Tech）和內容單薄的列表文章（apidog、Security Boulevard、SitePoint），它們的排名是基於網域權威，而非實用性。

他們全都跳過的，按它們讓你付出的代價高低排序：

• 代理能力差距。程式碼生成與驅動代理完成多檔案變更，並非同一種技能。第一頁幾乎沒提到這點；這正是你會保留某個模型，還是解除安裝某個模型的差別。

• 上下文視窗。 代理式編碼在載入檔案和測試輸出時會消耗大量 token。若不先問清「30B 可放入 24GB」是在多大的上下文長度下成立，這種說法就毫無意義。

• 量化數學。沒有人解釋過，4-bit 量化所需的 GB 數大約等同於參數量，或者 Q3 是以細微的語法錯誤為代價來換取 VRAM。

• 實測速度。很少有評測會為其推薦的模型列出每秒 tokens 數，而有列出的數據也差異極大，因為上下文和量化設定會徹底改變一切。

• 當選擇本地模型是錯誤的決定時。一項 2026 年針對 15,000 行 Flutter 應用程式（EPAM）的實地測試仍顯示，雲端前沿模型在最困難的多步驟重構中勝出。那些清單式文章都不會告訴你何時該停手。

大多數清單文章略過的VRAM計算

讓本文其他所有數字都變得易懂的經驗法則：在 4 位元量化下，模型所需的記憶體約略等於其參數量的 GB 數——7B ≈ 5GB、30B ≈ 18GB+，且尚未計入 KV 快取開銷。Q4 是程式碼生成的最佳甜蜜點；Q3 或更低雖能節省 VRAM，但可量測地會引入細微的語法錯誤。此外，KV 快取會隨你的上下文視窗增長，這就是為什麼「30B 能放進 24GB」唯有在你實際指定了上下文長度時才成立。

混合專家（Mixture-of-Experts）改變了運算方式，這對下方兩個重要選擇至關重要。總參數量决定佔用空間，活躍參數量决定速度。這就是為什麼 Qwen3-Coder-30B-A3B（總計 30B，活躍 3.3B）和 gpt-oss-20b（總計 20.9B，活躍 3.61B）運行起來的感覺都比其磁碟體積所暗示的要快得多，也是為什麼 DeepSeek V4 Flash——總計 284B，活躍 13B——雖然 API 便宜，但不太適合本機部署。

24GB VRAM：Qwen3-Coder 30B

Qwen3-Coder-30B-A3B-Instruct是我們目前能推薦的最強全方位本地編碼模型。它由阿里巴巴 Qwen 團隊於 2025 年 7 月以 Apache 2.0 授權發布，是一個混合專家（Mixture-of-Experts）模型，總參數量為 30B，每個 token 啟動 3.3B 參數，具備 262,144 token 的上下文窗口，4-bit 量化後約佔 17–20GB —— 在 24GB 顯示卡上仍為長時間編碼工作所需的 KV 快取保留了充足空間。

在我們最信賴的獨立本機評測框架（gauravvij/local-llm-coding-eval，四個模型透過 Ollama 在本機 CPU 上執行）中，qwen3-coder:30b 在程式碼生成、工具選擇與代理準確度上分別獲得 80%、77% 與 80%——是四個模型中結果最均衡的，也是唯一一個能同時在三項任務上都表現出色的模型。第三方追蹤平台彙整的數據顯示，其 SWE-bench Verified 約為 50.3、Aider Polyglot 為 66.2、LiveCodeBench v6 為 58.9；請將這些視為彙整數據，而非 Alibaba 的官方數字——後者才是 Qwen 針對此模型所發布的全部內容。

測量速度會因硬體而有大幅差異。最有用的數據點：{{1}}社群版 TurboQuant 設定在 8GB RTX 3060 Ti 上以完整 262K 上下文執行，產生速度約為每秒 29 個 token；{{/1}}{{2}}oMLX 基準測試則量測了 M4 Pro（48GB）上的 4-bit MLX 版本，在 1K 上下文時為每秒 73.6 個 token，降至 64K 時為每秒 13.5 個 token。{{/2}}{{3}}在一般 Ollama 設定的 24GB 顯示卡上，你預期會得到每秒數十個 token 的範圍，而非數百個——{{/3}}{{4}}這就是在家運行接近前沿等級程式碼模型的取捨。{{/4}}

誠實的提醒：它不是最快的本地編碼模型，而且存在更新的 Qwen3-Coder-Next，主要針對託管和 CLI 使用，而非量化本地安裝。但對於在單張顯示卡上進行的代理式、儲存庫規模工作，Qwen3-Coder-30B 是當前的首選。

16GB VRAM：gpt-oss-20b

在 16GB 顯示卡上，答案是gpt-oss-20b — 而且差距懸殊。它由 O​penAI 於 2025 年 8 月 5 日以 Apache 2.0 授權釋出，是一款混合專家模型，總參數 20.9B，每個 token 活躍參數 3.61B，具備 131,072 token 的上下文視窗，其原生 MXFP4 量化版本約為 14GB。這就是決定性的事實：它在 16GB 顯示卡上能 100% 在 GPU 內執行，完全不會溢出到系統 RAM。

GPU 常駐（on-GPU residency）之所以比任何基準測試都重要：能完全放入 VRAM 的模型，比需要卸載（offload）的模型快 3–11 倍。一項獨立基準測試記錄到 gpt-oss-20b 在 RTX 4080 上達到 139.93 tokens/秒——大約是相同記憶體佔用下稠密替代模型的 2.8 倍——而 2026 年一位測試者的評分給出 52.1 的「智慧指數」，稱其在 16GB 級別中對專業程式設計與除錯而言無可匹敵。它的體積相當緊湊，因此請單獨運行，並將上下文長度維持在適中範圍；在視窗頂端，品質會下降。

16GB 上的代理式替代方案是 Devstral 24B（devstral-small-2:24b），它在 16GB 等級的本地編碼模型中，發布了唯一的公開 SWE-bench Verified 分數——46.8%——但速度很慢，經常需要 CPU 卸載，約為 18 tokens/秒。如果你的工作是跨多檔案的代理式編輯，而且能接受這樣的速度，Devstral 就值得佔有一席之地；如果你想要速度加上乾淨的程式碼，gpt-oss-20b 是更好的預設選擇。Dense 14B 模型——Qwen3-Coder 14B 或 Qwen2.5-Coder 14B（Q5）——是舒適且便宜的備選方案。

8GB VRAM：Qwen 2.5 Coder 7B

在8GB記憶體下，誠實的答案是 Qwen2.5-Coder-7B：7B參數，Q4_K_M格式下約4.7GB，原生上下文32,768個token，可擴展至128K，並且在7B級別中擁有最強的程式碼補全基準成績。它是一款較舊的模型——於2024年11月發布——但這並無妨，因為在8GB記憶體範圍內，尚無更新的模型能取代其地位。社群測試顯示，在RTX 4060或3070上，速度約為每秒50個token；2026年3月一項獨立的RTX 4060測試則測得每秒28–35個token，而這項差異幾乎完全取決於上下文設定。

在 8GB 記憶體上，有三件事格外重要。首先，把上下文限制在 4–8K：KV 快取才是讓 8GB 顯示卡 OOM 的元兇，而不是模型權重——一項基準測試顯示，光是限制上下文長度，速度就從每秒約 3.6 個 token 躍升到約 37 個 token。其次，用 ollama ps 確認模型 100% 在 GPU 上運行；只要有任何一部分在 CPU 上跑，速度就會崩潰。第三，用 Q4_K_M，別用 Q3——Q3 的語法錯誤造成的損失，比省下的 VRAM 還多。

2026年值得注意的進展是，Qwen3-Coder-30B-A3B-Instruct現在可以透過 TurboQuant KV-cache 壓縮塞進 8GB 記憶體——社群配置在 RTX 3060 Ti 上、完整 256K 上下文下測得約 7.5GB 和每秒約 29 個 token。它確實可行，但設定相當繁瑣，因此我們不建議將其作為預設選項。如果你想要更新的開箱即用選項，Qwen3 8B（約 5.2GB，混合思考模式）在一般推理上比 Qwen2.5-Coder-7B 略勝一籌，但在純程式碼方面仍稍微落後。

那 Apple Silicon 呢？

統一記憶體讓取捨有了變化：容量增加，但生成速度下降。48GB 的 M4 Pro 能容納 16GB Windows 顯示卡無法容納的模型，但在長上下文下生成 token 的速度慢得多。我們手上的數據：在 M4 Pro 上，Qwen3-Coder-30B-A3B-Instruct 的 4-bit MLX 版本在 1K 上下文時占用 16.6GB，在 64K 時占用 25.5GB，而生成速度隨上下文增長從每秒 73.6 個 token 降至 13.5 個（oMLX 基準測試）。gpt-oss-20b 可輕鬆放入 16GB 統一記憶體，是 Mac 的好選擇。如果你想在 Apple Silicon 上使用多模態功能，Gemma 4 12B 在約 16GB 的統一記憶體中即可運行，並支援 256K 上下文——如果你的編碼工作伴隨大量圖片文件，這是最強大的本機選項。

獨立的數字：codegen 並非關鍵技能

我們找到最清晰的數據是一個值得完整引用的本地基準測試。gauravvij/local-llm-coding-eval 透過 Ollama 在 CPU 上、無雲端環境下本地運行四個模型——涵蓋程式碼生成、函式呼叫，以及多步驟代理任務——其結果與「codegen 分數越高就越好」的直覺相悖：

• Qwen3.6 27B（qwen3.6:27b，密集，約17GB）：80.0% 程式碼生成，84.6% 工具，100% 智能體——最佳全能型選擇。

• Qwen3.6 35B A3B（qwen3.6:35b-a3b，MoE，~18GB）：70.0% 程式碼生成、84.6% 工具、100% 代理。

• Qwen3-Coder-30B-A3B-Instruct（qwen3-coder:30b、MoE、約17GB）：80.0% 程式碼生成、76.9% 工具、80% 智能體 — 最均衡的。

• DeepSeek-Coder-V2 33B (deepseek-coder:33b, 密集, ~18GB): 90.0% 程式碼生成 — 四個中最好的 — 但 10% 智能體，在多步驟工作上墊底。

最後一行就是全部的教訓。一個在純程式碼生成上表現頂尖，但在代理任務上卻崩潰的模型，就是你會在第一次「讀取這個檔案、修改這個函式、執行測試」循環後解除安裝的模型。評判一個本地程式碼模型，要看代理（agentic）那一欄，而不是程式碼生成那一欄。

在本地運行是錯誤的選擇

本地優先（Local-first）是隱私、離線工作、零邊際 token 成本，以及在延遲比上限品質更重要的自動完成情境下的正確預設。但在特定、可辨識的情境下，它是錯誤的選擇——而這正是讀者跳過的那一段。

• 最困難的代理式工作仍會擊敗你。EPAM 在 2026 年針對一個 15,000 行的 Flutter 應用程式進行的實地測試發現，雲端前沿模型（GPT-5.3-codex）在最複雜的多步驟重構上仍優於本地模型。如果你每天就是花八小時重構舊有程式碼，那麼本地模型尚未準備就緒。

• 您的上下文需求超過了您的顯示卡所能負荷。載入整個儲存庫的程式碼代理會突破 16GB 顯示卡所能容納的 KV 快取。Qwen3-Coder-30B 的 256K 上下文是它能稱霸 24GB 級別的原因——較小的顯示卡從一開始就輸了這場比賽。

• 你不能一直盯著硬體。硬體是實打實的金錢：一張24GB的顯示卡屬於700–1,600美元等級，再加上電力和維護費用。在低使用量下，呼叫API比耗電成本更便宜。

• DeepSeek V4 Flash 就是證明。在總參數 284B 的規模下，DeepSeek V4 Flash 的 4-bit 權重本身就約 140GB——絕對不是消費級顯卡能跑的模型，沒有商量餘地。其 13B 活躍參數的設計，正是其 API 又快又便宜的原因：每 1M tokens 僅 $0.15 / $0.29（MIT 授權，1M 上下文）。對這個模型來說，「本地執行」是錯誤的問題；API 才是重點。

• 團隊需要一致性。如果四位工程師各自對不同模型執行不同的量化，「在我的機器上可以運作」就會成為建置風險。共享的 API 端點提供一個確定性的目標。

如果你想要同一個問題的API端答案——即當本地端不是正確的選擇時，哪個雲端程式碼模型是預設——我們在最佳程式碼LLM指南中另外討論了它，而我們的AI程式碼代理文章則涵蓋了像Cline和OpenCode這樣能與這些本地端模型搭配運作的框架。

購買前如何測試卡片

要決定這件事，最省錢的作法是在投入硬體之前，先用自己的提示詞實際跑一遍。Ollama 或 LM Studio 都能在幾分鐘內讓這三個候選的任何一個跑起來，而真正有參考價值的測試，是你自己 repo 裡的實際檔案，而不是 benchmark。Router 在另一個相關決策上也有其價值：當你在本地候選模型與雲端托管的前沿模型之間做比較時，一個統一端點就能讓你把同一個提示詞同時送給兩邊，不必在 API key 之間來回切換。在 OrcaRouter 上，DeepSeek V4 Flash 以供應商列表價格原價提供、不加價轉傳——每 1M tokens $0.15 / $0.29，0% 加成——並具備自動容錯切換，這使它成為一個便宜且誠實的標尺，用來回答「我的本地模型真的比 $0.15 的 API 更好嗎？」

一個誠實的提醒：OrcaRouter 並不託管 Qwen3-Coder-30B-A3B-Instruct 或 gpt-oss-20b。如果你的目標是純離線，路由器對你而言就無關緊要——自行架設即可。如果你的目標是在花錢買顯卡之前，用同一個開放權重模型與前沿模型進行 A/B 比較，那麼路由器的工作是比較，而不是託管。

底線

你的VRAM首先決定一切，模型品質其次。在24GB上，執行Qwen3-Coder-30B-A3B-Instruct——這是最強大的全方位本地編碼模型，具備智能體工作所需的256K上下文。在16GB上，執行gpt-oss-20b——這款罕見的模型既快速又能完全在GPU上運行。在8GB上，執行Qwen2.5-Coder-7B，並將上下文控制在適中範圍。判斷任何一款時，請以智能體（agentic）欄位為準，而非程式碼生成（codegen）欄位，並接受最困難的多檔案重構仍屬於雲端。以上數據截至2026年8月10日為最新——在花錢之前，請重新核實陣容與定價，因為這個領域每週都在變動。