選本地 AI 模型，可以先用 llmfit 掃描硬體，縮小模型與量化版本的候選範圍，再下載到 Ollama 實測。
這樣能少走一輪「下載十幾 GB、發現太慢、刪掉重來」的流程。模型能載入，只是第一關，速度、上下文與日常工作是否順暢，才決定它值不值得留下。
內容目錄
llmfit 是什麼？下載模型之前的硬體配對工具
llmfit 是在終端機使用的模型選型工具，它偵測 CPU、RAM、GPU 與顯示記憶體，再搭配模型資料庫，估算哪些模型適合目前硬體。預設開啟互動介面，也能輸出命令列與 JSON 結果。
先分清楚兩個角色：llmfit 幫你篩選與規劃，Ollama 負責管理模型與執行推理，只做規格估算，不需要先下載模型或啟動 Ollama，使用模型下載、已安裝模型偵測或實測功能時，才需要對應的執行服務。
同一個模型換後端，也可能改變速度與記憶體需求，若還不熟悉 MLX、llama.cpp 與 Ollama 的差異，可以先對照站上的本地大模型推理框架比較，之後再看 llmfit 的估算會比較有方向。
先安裝 llmfit，再確認掃到的是哪台電腦
macOS 已有 Homebrew 的話，可依官方 README 使用以下安裝方式。
brew install AlexsJones/llmfit/llmfit
llmfit進入畫面後，先核對上方 CPU、記憶體、GPU 和後端是否正確。規格辨識錯誤，後面的排序也會跟著失準。若想先看純文字硬體資訊，可以執行：
llmfit systemWindows 的官方文件提供 Scoop 安裝方式，Linux 也有預編譯版本與其他安裝選項，請依 llmfit 安裝文件選擇。各平台對 GPU、驅動與執行後端的支援不同，不能只看 RAM 一項。
如果模型跑在遠端 Ubuntu 或 GPU 伺服器，硬體掃描應在那台推理主機上執行。在筆電上掃描，只會得到筆電的資源條件。遠端呼叫的設定，可接著看Ollama 遠端連線教學。
搜尋模型時，先看量化、速度與記憶體
在互動介面按 / 可以搜尋名稱，輸入 Qwen3 就能縮小候選範圍。按 f 循環切換適配程度，按 Enter 查看細節，按 q 離開。快捷鍵可能隨版本調整，完整操作可查官方 TUI 指南。
Best Quant：目前條件下的量化建議
量化把模型權重用較少位元表示，以降低儲存與記憶體需求。從 16 位元換成 4 位元，單純權重位元數會降為四分之一，但實際檔案還有比例因子、混合精度與其他資料，因此不能直接保證整個模型只剩四分之一大小。
Best Quant 是 llmfit 在自己的記憶體與品質假設下選出的起點。Q4、Q8 不是完整的版本名稱，Q4_K_M、Q4_0、不同模型作者的轉檔和不同後端，也不能直接視為同一個結果。低位元通常更省空間，但品質損失與速度仍要看模型及任務。
tok/s：生成速度，不是每秒幾個中文字
token 是模型切分文字的單位，可能是一段字詞、字元或符號，不固定等於一個英文單字，也不固定等於一個中文字。tok/s 適合比較相同模型與測試條件下的生成吞吐，不能直接當成中文閱讀速度。
還要區分「多久開始回答」和「開始後輸出多快」。模型載入、輸入處理、思考與輸出都可能影響等待時間。一個模型生成速度高，仍可能在讀長文件時等很久。
Fit Analysis：留意整體占用與剩餘空間
磁碟上的模型檔案大小，不等於推理時全部記憶體需求。除了權重，還有上下文的 KV cache、執行暫存，以及作業系統與其他程式的用量。24GB 統一記憶體也不能整份都交給模型。
因此，Perfect、Good 等標示可以協助篩選，但不能保證你的日常工作沒有記憶體壓力。請以實際要使用的上下文規劃，並同時觀察 macOS 的記憶體壓力與 swap，或其他系統的記憶體監控。
Estimate Basis：速度數字怎麼算出來？
llmfit 的估算文件說明，生成階段的基本模型會參考記憶體頻寬、需讀取的權重與效率係數。簡化理解是「頻寬 ÷ 權重大小 × 效率」，預設效率係數為 0.55，也能調整。MoE、分流執行與不同後端另有處理。
這個公式適合解釋為什麼頻寬與模型大小影響逐 token 生成，但它不是所有場景的完整效能模型。長輸入處理、批次、核心實作、上下文與量化都會改變結果，不應把固定誤差區間當成保證。
目前文件也區分本機實測、相同硬體的社群實測、校準與純估算。看見 tok/s 時，先看它的資料依據與後端，再比較數字，避免把公式推算和真機測量混在一起。
Qwen3-30B-A3B 與 Qwen3-32B：名字接近，運作不同
依 Qwen 官方模型卡，Qwen3-30B-A3B 有 30.5B 總參數，每個 token 約啟用 3.3B 參數，包含 128 位專家、每次選用 8 位。相對地，Qwen3-32B 是 32.8B 參數的密集模型。兩者不能只按名稱中的 30B 和 32B 推斷速度。
MoE 讓每次計算只用部分專家，因此有機會降低生成所需計算與資料讀取。但啟用 3.3B，不代表整個模型只有 3.3B 的儲存或總記憶體需求。所有專家的權重仍要有地方保存，是否分流到其他記憶體、如何載入，取決於實作。Apple Silicon 的 CPU 與 GPU 共用統一記憶體，也不能照搬獨立顯卡的記憶體分區說法。
另一個容易看錯的是 Quality 分數。llmfit 會使用模型參數、家族資訊、量化與任務對齊等條件評分，這不是拿你的文件與問題跑出的正確率。較高分不能直接證明「一定更聰明」，模型是否適合寫程式、繁中摘要或資料抽取，仍需要各自測試。
實測案例：39.7 tok/s 的預估，對上 39.5 tok/s
YAHA 學堂公開的 M4 Pro、14 核 CPU、24GB 統一記憶體案例，先依 GGUF 的設定重新規劃，再用 Ollama 測試 Qwen3 模型。以下保留該次報告的數值，並非本文重新執行的 benchmark。
| 模型 | 數值 | 口徑 |
|---|---|---|
| Qwen3-30B-A3B | 39.7 tok/s | llmfit 依 GGUF 設定估算 |
| Qwen3-30B-A3B | 39.5 tok/s | 作者報告的 Ollama 生成速度 |
| Qwen3-32B | 0.12 tok/s | 作者報告的 Ollama 生成速度，出現 CPU/GPU 混合載入 |
39.7 與 39.5 相差約 0.5%，表示這次估算相當接近。但只有一個相近案例，不能推成 llmfit 對所有機器都能維持 1% 內的誤差。密集模型的低速也只能代表該次設定，不能推成所有 24GB Mac 都跑不了 32B。
該案例還報告了一次回答耗時約 41 分鐘。整段耗時與生成速率是不同指標，可能包含載入、輸入處理與思考 token，不適合只用畫面上的幾句話反算。案例最實用的提醒，是下載約 18GB、20GB 的兩個模型前，先確認你需要的版本與負載。
用 plan 固定條件，避免拿 MLX 預估對比 GGUF
Apple Silicon 上可能自動選到 MLX 路線，實際卻用 Ollama 執行 GGUF。要比較，先把模型、量化、後端與上下文對齊。plan 的主要用途是反向估算指定模型配置需要的硬體，不是實際跑一次模型。
依目前 CLI 文件的參數形式，可先查目錄，再以查到的完整模型名稱規劃。下面以 Qwen3-30B-A3B、8192 tokens、Q4_K_M 為示例，若安裝版目錄的名稱不同，請替換成搜尋結果的名稱。
llmfit search "Qwen3-30B-A3B"
llmfit info "Qwen/Qwen3-30B-A3B"
llmfit plan "Qwen/Qwen3-30B-A3B" --context 8192 --quant Q4_K_M --json8192 是 tokens，不是 8192 個中文字。Ollama 實際執行時也要設定相同上下文，而且要確認下載的量化相符。若只想先看 llama.cpp 路線的推薦，可用以下文件已列出的方式，避免把自動選擇的 MLX 結果直接拿來比較。
llmfit recommend --force-runtime llamacpp --json --limit 5再用 Ollama 測試，別同時把兩個大模型塞進記憶體
macOS 使用 Homebrew 安裝 Ollama，可以依套件方式啟動背景服務。若你已經用 Ollama 官方 App 執行服務，就沿用現有方式，不需再開另一份伺服器。
brew install ollama
brew services start ollama確認選型後，先下載一個候選即可。以下 qwen3:30b 對應 Qwen3 的 30B MoE 路線，實際檔案大小與量化請以當時的模型標籤頁與本機資訊核對，標籤會隨版本更新。
ollama pull qwen3:30b
ollama show qwen3:30b
ollama run qwen3:30b --verbose進入互動後，可以先設定與規劃相同的上下文，再輸入自己每天真的會問的問題。若要比較不同模型，也固定提示內容、輸出要求與思考模式。
/set parameter num_ctx 8192回答結束後，--verbose 會顯示耗時資訊。生成速度看 eval rate，不要和輸入處理速率混淆。若用 API 紀錄，官方用量文件提供 eval_count 與以奈秒計的 eval_duration，生成 tok/s 可用 eval_count ÷ eval_duration × 10⁹ 計算。
在另一個終端機查看載入狀態，測完再卸載目前模型，接著才測第二個候選。卸載記憶體中的模型不會刪掉已下載的檔案。
ollama ps
ollama stop qwen3:30b依 Ollama FAQ，PROCESSOR 的 100% GPU 表示全 GPU 載入，混合 CPU/GPU 百分比表示部分分配到兩邊。這欄不是即時 GPU 使用率，也不是「百分之多少運算時間」的統計。若速度驟降，應一起檢查上下文、後端日誌、記憶體壓力及 swap，不能只憑一個百分比斷定原因。
挑兩個候選，用自己的任務決定要留下哪個
- 先用 llmfit 排除明顯太緊的配置，保留少量候選。
- 把量化、後端、上下文與思考模式記下來，再下載測試。
- 同一段繁中摘要、程式修改或資料抽取需求，分別跑候選模型。
- 記錄開始等待時間、生成速度、正確性，以及同時開著工作軟體時是否順暢。
- 確認適合後再接到日常介面，避免一次下載很多版本卻沒有比較紀錄。
如果最後想把本地模型放進可管理對話與文件的介面，可以接著看LibreChat 與 Ollama 串接教學。先把模型選對，再加操作介面，會比邊排查模型、邊排查前端容易。
llmfit 能幫你省下試錯的下載量，最後的選擇仍應由實際任務決定。先找出跑得動而且有餘裕的配置，再挑回答品質合用的模型，比只追參數量更實際。
llmfit 與本地模型選型常見問題
llmfit 的 tok/s 是實測嗎？
不一定。可能是公式估算、經校準的估算，或本機與社群測量。應查看資料依據，並用相同量化、後端與上下文實測。
Qwen3-30B-A3B 只要 3GB 記憶體嗎？
不是。官方列出 30.5B 總參數與每 token 啟用約 3.3B 參數。啟用參數影響計算，全部權重、上下文及執行暫存仍需儲存與記憶體。
Quality 分數比較高，就一定回答比較正確嗎？
不能這樣判斷。這是 llmfit 的選型評分，不是你的任務測驗。請用相同問題比較正確性、格式與延遲。