本地 coding 模型細就實用？GPT-OSS 20B 贏咗一星期測試，但結論有條件

XDA 作者 Abhinav Raj 用一張 16GB RTX 4070 Ti Super，經 Ollama 跑 Qwen3-Coder 30B、Devstral Small 2 24B 同 GPT-OSS 20B，連續一星期叫佢哋寫程式、搵 bug 同重構舊 code。最後 GPT-OSS 20B 三輪全勝，亦成為佢唯一打算長留嘅本地模型。結果幾搶眼，不過先要搞清楚，呢度講嘅「最細」其實只係下載檔案佔位最少，模型點運算同實際食幾多記憶體係另一回事。

三款模型個「大小」唔可以直接排能力

按 XDA 測試時記錄，gpt-oss:20b、devstral-small-2:latest 同 qwen3-coder:30b 分別佔 13GB、15GB 同 18GB。Ollama 而家嘅 registry 顯示相應版本約為 14GB、15GB 同 19GB，映像更新後有少少出入都唔奇。Qwen 同 Devstral 嘅預設版本用 Q4_K_M 量化；GPT-OSS 就原生用 MXFP4，兩種方法點壓縮權重唔一樣，所以單靠檔案 GB 數比較模型「大細」，本身已經唔算同一把尺。

參數數目同樣會令人睇錯。Qwen 有 30.5B 總參數，不過每個 token 只啟用約 3.3B；GPT-OSS 20B 實際有約 21B，逐個 token 啟用約 3.6B。即係 GPT-OSS 下載檔細過 Qwen，運算時啟用嘅參數反而多少少。Qwen 喺 XDA 測試入面反應最快，MoE 架構同量化都有可能係原因；文章冇公開 token/s、CPU、系統 RAM 同 GPU offload 狀況，所以暫時解釋唔到速度差距有幾多來自模型、有幾多來自硬件調度。

圖片：Wikimedia Commons — Alex P. Kok（CC BY-SA 4.0）

測試唔只睇程式行唔行到

第一輪要三款模型由零寫一隻 Pygame 貪食蛇。XDA 作者話 Qwen 交出嚟嘅畫面最完整、反應亦最快，不過條蛇可以穿牆；GPT-OSS 就自行補上撞牆死亡、禁止即時掉頭，同避免食物生喺蛇身上等規則。呢啲要求冇寫入 prompt，GPT-OSS 就靠對遊戲邏輯嘅判斷贏咗第一輪。呢種評分幾貼近日常用法，因為開發者好多時只會描述目的，未必逐個 edge case 寫晒出嚟。

第二輪由 Claude Fable 5 喺三款模型各自生成嘅程式入面，加入三個邏輯 bug，再只提示佢哋「有 bug，要修好」。按 XDA 記錄，Qwen 改啱三處 code，但只準確講中其中一個原因；Devstral 搵到一個，另外兩個原封不動；GPT-OSS 就逐個指出根源，亦冇亂改其他行。第三輪要整理一份 120 行 Python 網店訂單程式，Qwen 一開始就撞上 scope error，Devstral 去到報表階段漏傳參數，GPT-OSS 嘅輸出則同原本結果完全一致。

呢個賽果偏向獎勵邏輯推理

三輪結果足以話明，GPT-OSS 20B 喺呢位作者、呢組 prompt 同單檔 Python 工作之下最穩。不過 Qwen3-Coder 同 Devstral Small 2 官方都主打 agentic coding，包括探索大型 codebase、調用工具同跨檔案修改；今次主要考一隻細遊戲、三個人工植入 bug 同一份 120 行程式，冇測 repository 導航、測試套件、git diff、長時間工具調用或者多檔案依賴。GPT-OSS 擅長嘅推理工作喺呢套題目佔得幾重，賽果自然有利佢。

文章亦冇交代完整 prompt、temperature、seed、context 設定、GPT-OSS reasoning effort、每秒 token 數，同每項工作有冇重跑。模型生成本身有隨機性，一次成功或者失手未必重現得到。作者自己亦承認，一星期、單一硬件同一個人操作只算訊號，未足以當通用排名。真係要替公司揀模型，至少要攞自己個 codebase、測試套件同常見 ticket 重跑幾次，再計成功率、改壞現有功能嘅次數同完成時間。

16GB 跑得到，長 context 仍然係硬限制

GPT-OSS 官方話 20B 版本經 MXFP4 後可喺 16GB 記憶體內運行，XDA 作者亦話佢喺 16GB 顯示卡上有剩餘空間。不過「模型載入到」唔等於可以盡用 128K context。Ollama 對少過 24GiB VRAM 嘅系統預設只開 4K context；官方建議 coding agent 用至少 64K，但 context 愈長，KV cache 食嘅記憶體愈多。如果權重要落部分去 CPU，速度亦可能大跌。想分析成個 repository，16GB 卡同一個短 Python 檔係兩個好唔同嘅負載。

對 freelance developer、中小企或者處理內部程式碼嘅團隊，本地模型最實際嘅價值係 prompt 同 code 可以留喺自己部機。Ollama 表明純本地運行時睇唔到用家嘅 prompt 或資料，亦可以關掉雲端功能。不過 IDE plugin、網上搜尋、遙距 tool server 同錯誤回報仍可能將資料送出去，部署時要逐樣檢查。模型權重免訂閱費，硬件、電力、更新同安全隔離就照樣有成本；安裝 Ollama 只係起步，仲要處理權限、測試同錯誤回復。

一般開發者點揀先實際

已有 16GB 顯示卡、主要寫單檔工具或處理清晰 bug 嘅開發者，GPT-OSS 20B 值得先試，今次結果亦支持佢喺反應速度同程式碼可靠度之間有幾好平衡。Qwen3-Coder 30B 嘅回應速度吸引，但要用測試套件看實改動；Devstral Small 2 則應該放入真正 agent 工作再評，單靠呢三題就淘汰佢會太早。現有 PC 跑本地 coding model，揀到一款完整放入記憶體、又能穩定處理日常工作嘅模型，通常實用過勉強搬一款更大模型入 CPU；最後仍要由自己份 code 同測試結果話事。

參考來源

• XDA Developers — I used three local coding models for a week of real work, and the smallest one won — original report
• Introducing gpt-oss — 核對 GPT-OSS 20B 架構、MXFP4、128K context、16GB 記憶體要求同授權。
• Qwen3-Coder-30B-A3B-Instruct model card — 核對 Qwen 總參數、啟用參數、context、模型定位同 Apache 2.0 授權。
• Devstral Small 2 24B Instruct model card — 核對 Devstral 型號、agentic coding 定位、官方硬件描述、context 同授權。
• Ollama model registry：Qwen3-Coder tags — 核對 Ollama 版本大小、Q4_K_M 量化同 context 資料。
• Ollama Context length 文件 — 核對唔同 VRAM 容量嘅預設 context，同長 context 對記憶體嘅影響。
• Ollama FAQ — 核對純本地運行嘅資料處理方式，同關閉雲端功能方法。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。