Day 16｜模型選型方法論：五個問題幫你跳脫排行榜迷失，找到適合自己任務用的 AI 模型

2026 iThome 鐵人賽

DAY 16

AI Engineering

128GB 統一記憶體的三十天：DGX Spark 地端 LLM 與生成式 AI 部署實戰系列第 16 篇

Day 16｜模型選型方法論：五個問題幫你跳脫排行榜迷失，找到適合自己任務用的 AI 模型

18th鐵人賽

ivanusto

2026-08-29 22:42:40

103 瀏覽

分享至

為什麼不能只看排行榜?

過去一週測了四款地端 AI 模型，每一款在某個排行榜上都當過第一。如果排行榜能回答「我該用哪款模型?」，這個系列可以少寫十天。它不能，原因有三個，而且每一個都在我自己的測試資料裡現形過。

第一，排行榜測試的語言不是你的語言。Day 12 到 15 反覆測試到同一件事，量化對繁中的傷害是英文的 1.6 到 2 倍，跨引擎跨量化家族都成立，甚至 Flash-Next 整代架構升級的增益幾乎沒分給繁中。英文榜上的名次，到了繁中任務會有不一樣的結果。

第二，排行榜不會去測試你實際的工作負載模樣。同一顆密集 27B，prefill 對 decode 的效率差了兩百倍，拿它做長內容的摘要是神器，但拿它去產生長內容是折磨，榜上只有一個分數。

第三，排行榜測試不到代理人的格式紀律。Day 15 的考卷讓五個配方在能力題全數滿分，卻在「只輸出一個 JSON 不要多話」這題拉出 0 / 50 到 40 / 50 的差距。agent 迴圈一天幾百輪，這種榜上沒有的規範測試會直接決定你的 token 帳單。

因此這次的文章重點不討論榜單，給大家一個閃光說的漏斗式問法，簡單採用五個問題決定你地端 AI 選模型的判斷流程。這五個問題按順序問，每一題都會刪掉一些選項，問完剩下的選項就會接近適合你的答案。

我把這個專案做了一個互動式網頁放在 GitHub 上，OpenModel Selector ｜ AI 開放模型選擇決策與硬體搭配矩陣，歡迎點選多利用測試看看吧，以下是我這協助你 AI 模型選用的五輪問題詳細說明:

問題一：你的任務是什麼形狀

先盤點自己的任務需求，把你的典型任務攤開看輸入輸出比例：

長輸入、短輸出（文件摘要、RAG 問答、程式碼庫分析）

你是 prefill 型用戶，密集模型的 prefill 效率極高，27B 級密集模型是好選擇，decode 慢無所謂，因為你不太用它。

短輸入、長輸出（寫作、翻譯長文、對話）
你是 decode 型用戶，頻寬就是你的天花板，選每 token 啟用量小的 MoE。本系列的實測序列很清楚，密集 27B 的 8-bit 只有 7.9 t/s，35B-A3B 的 Ornith 有 29.9，gpt-oss-120b 在 llama.cpp 上有 60.6。看啟用參數量，不是總參數量。

agent 迴圈（幾百輪工具呼叫）
你兩種都要，還要加上 KV 成本與格式紀律，這是最挑的一型，問題三與問題五都會與你的需求相關。

問題二：你的語言是繁體中文嗎

如果是的話，這幾個經驗談你可以參考。
量化從 8-bit 起步，繁中的量化劣化是英文的兩倍，英文社群說「4-bit 無感」時，他們沒有替你驗過你常用的語言。
低位元請認明 imatrix 系，Day 14 測到 17.77 GB 的 q4_k_m 品質贏 25.96 GB 的 NVFP4 五到十倍。自己驗，用自己的語料，這也是我把這份測試考卷開源的原因，任何 OpenAI 相容端點可在半小時考完。

問題三：它要跟誰分這 128GB

一顆模型的記憶體真實佔用量，是權重加 KV 加你要留給別人的餘裕。本系列測過的 KV 每 token 成本差距達 3.3 倍（Ornith 10.56 KB 對 27B 的 34.5 KB），這在長對話與多 session 場景是主戰場。決策上分兩型：

獨佔型
如果你的這台機器就是為了跑這一個模型（Ornith BF16 峰值 120.7 GB、Flash-Next 吃四分之三記憶體都屬此類），效能拉滿，代價是機器上別的服務你就不太能開了喔。

共存型
如果選用的模型只是你機器上的服務之一（27B 級量化檔、gpt-oss MXFP4 屬此類），留下的餘裕拿去跑 ComfyUI、第二顆小模型或你的日常工作。

沒有對錯，但先誠實回答你手上的這台機器是單功能還是多功能，很多人買 128GB 就是為了不必二選一，結果選了一顆獨佔型模型把自己逼回二選一。

問題四：授權允許你的用途嗎

Day 5 就講過 MANIFEST 要記 license，這裡就是它發揮價值的地方。本系列測過的四款模型中，gpt-oss-120b 與 Qwen3.8-27B 是 Apache 2.0 放心商用，Flash-Next 換成了 qwen-community-1.0 要先讀條款，Ornith 的授權是相對寬鬆的 MIT，很多社群人比較愛這種授權。

對用戶來說，地端部署 AI ，不代表授權問題消失，尤其 MSP 與接案場景，模型的授權是你交付成品的一部分，要看清楚條款。

問題五：生態接得住它嗎

新模型的規格再漂亮，引擎支援沒合併就是實驗品。Qwen 3.8 Flash-Next 正是現成的例子，官方基準測試資料全面領先，但 vLLM 與 llama.cpp 的支援都還在 PR 裡，初期用戶得自己編分支才跑得起來，途中還要先驗證模型在這顆晶片上是正確輸出的。
當然，願不願意當白老鼠是個人選擇，把白老鼠環境放進生產服務的話則是專業錯誤。

部署前先檢查三件事，搭配的推論引擎支援是否合併進正式版、量化生態跟上了沒 ?（社群 GGUF 的數量與品質）、以及有沒有你現在這個硬體平台的實測前例 (Mac、Dgx Spark、Windows + NVIDIA 或 AMD 顯示卡)。

附：模型住哪裡，SSD 還是 NAS

選完模型，順手把儲存分配也定了，兩個判斷問題（完整實測見系列前段）：

它放得進記憶體嗎？ 大小放得進，那 NAS 的代價只是冷啟動多十幾秒的一次性成本，那就可以放，省本機的 SSD 空間，另外，如果你是雙機 GB10、多台 MAC 要連同一模型，那放 NAS 也是可以的。
如果檔案太大，記憶體放不進（模型加執行期副本逼近記憶體容量），不要放 NAS，執行中每一次頁面回收再讀取都走網路，連 CPU 階段都會被拖垮，這時候後 SSD ，雖然會有來回載入又卸載再載入的問題，但速度會比快。

你的 loader 吃儲存速度嗎？ 用「權重位元組除以載入秒數」對比磁碟實力，差一個等級時（如 vLLM 的 3%），代表搬去 SSD 不會有感，同等級的話（如 GGUF mmap 的 73%），代表儲存速度會直接反映在啟動時間，所以放 SSD 和 NAS 的差異就很小。

實務分配的重點就是，常駐主力住本機 NVMe，實驗品與冷門檔住 NAS 集中庫，然後把 readahead 調上去（預設 128 KB 太小，這是整個儲存章節唯一一個大家用得上的話就都該做的免費加速）。

一頁清單

我把五個問題濃縮成可以放便利貼的簡短版本：

任務形狀：長進短出選密集，短進長出選 MoE（看啟用量），agent 全都要看
繁中：8-bit 起步、imatrix 優先、自己的語料自己驗
記憶體：先決定獨佔還是共存，再看權重加 KV 加餘裕
授權：MANIFEST 裡那行 license 就是答案
生態：支援沒合併的是實驗品，實驗品不進生產 Production

這五題問完還有二款以上模型活著，恭喜，剩下的差異用考卷分勝負看看吧，repo 我放在 github.com/ivanusto/llm-zhtw-agent-exam。
至於本篇文章使用的選型 repo ，我也放在 GitHub 上了，專案頁由此去 : OpenModel Selector ｜ AI 開放模型選擇決策與硬體搭配矩陣

本專案頁還有對比一些線上排行版，以及我個人的測試，和累積資料的整合，相關功能頁面都會持續更新，有這些可以多看看多比較，希望對你的地端模型建構選擇有幫助。