三大推理框架概覽
| 特性 | llama.cpp | MLX | ExLlamaV2 |
|---|---|---|---|
| 平台 | 全平台 | Apple Silicon only | NVIDIA GPU only |
| 格式 | GGUF | MLX / safetensors | GPTQ / EXL2 |
| 速度 (M3 Ultra) | 中等 | 最快 | 不支援 |
| 量化 | Q2-Q8, K-quants | Q4, Q8 | 2-8 bit |
| 生態 | 最成熟 (Ollama) | Apple 官方 | 高階 GPU 用戶 |
llama.cpp
Ollama 的底層引擎，支援所有平台的 CPU/GPU 混合推理。
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j
# 下載 GGUF 模型後運行
./llama-cli -m model.gguf -p "Hello world" -ngl 99
- 優勢：生態最大、Ollama 整合、GGUF 模型最豐富
- 劣勢：在 Apple Silicon 上不如 MLX 快
MLX (Apple)
Apple 官方推出，專為 M 系列芯片優化。
pip install mlx-lm
mlx_lm.generate --model mlx-community/Qwen2.5-7B-Instruct-4bit --prompt "Hello"
- 優勢：Apple Silicon 上最快、統一記憶體利用最充分
- 劣勢：限 Apple Silicon、模型庫較小
ExLlamaV2
專為 NVIDIA GPU 設計的高效能推理引擎。
git clone https://github.com/turboderp/exllamav2
pip install exllamav2
- 優勢：NVIDIA GPU 上最快、支援 GPTQ
- 劣勢：僅 NVIDIA GPU、門檻較高
選擇建議
| 你的環境 | 推薦 |
|---|---|
| Mac M 系列 | MLX (最快) > llama.cpp (Ollama) |
| NVIDIA GPU | ExLlamaV2 > llama.cpp |
| CPU only | llama.cpp |
| 追求簡單 | Ollama (底層 llama.cpp) |
| 追求極致效能 | MLX (Mac) / ExLlamaV2 (NVIDIA) |
模型格式與量化的取捨
三個框架各自綁定不同格式，選框架某種程度上就是選格式，值得先想清楚再下載模型。
GGUF（llama.cpp）：單一檔案自帶中繼資料，支援 CPU 與 GPU 混合卸載，K-quants 提供多個壓縮層級。優點是跨平台分發方便、模型來源最廣；缺點是同一模型的檔案命名與量化標籤較繁雜，要確認自己下載的是哪一版。
MLX / safetensors（MLX）：貼合 Apple 統一記憶體架構，量化以低位元為主，生態圍繞社群轉換好的 MLX 版本。若手邊只有 safetensors，通常需要先做一次轉換。
GPTQ / EXL2（ExLlamaV2）：針對 NVIDIA GPU，EXL2 的彈性在於可以為不同層分配不同位元寬度，換取顯存與品質之間的平衡。
| 取捨 | 較低位元量化 | 較高位元量化 |
|---|---|---|
| 記憶體佔用 | 較低 | 較高 |
| 生成速度 | 通常較快 | 較慢 |
| 輸出品質 | 有機會下降 | 較接近原始 |
| 適用情境 | 記憶體吃緊 | 記憶體充足 |
實務建議是先從中等量化跑通整條流程，確認能正常載入與回覆，再依記憶體餘量與品質需求調整。不要一開始就追求最低位元，否則可能把品質問題與設定問題混在一起，難以判斷原因。另一個常見陷阱是格式不通用：拿到 GGUF 就只能在支援 GGUF 的框架使用，換框架要重新轉換，轉換前務必保留原始權重。
各框架的調優要點
llama.cpp：核心參數包括卸載到 GPU 的層數、執行緒數、批次大小與上下文長度。層數調高會更依賴 GPU，記憶體不足時要往下調；上下文長度直接影響記憶體佔用，開太大即使模型本身放得下也會失敗。長時間使用建議以伺服器模式啟動，提供 OpenAI 兼容接口，方便被其他工具呼叫。
MLX：模型需為 MLX 格式，若只有原始權重可先轉換。由於統一記憶體讓模型與上下文共享同一個池，長上下文要預留足夠餘量，否則容易在生成中途失敗。使用社群已量化好的版本可以省去轉換步驟，但要留意量化方式是否與你的需求相符。
ExLlamaV2：多數情況透過 Python API 或範例腳本使用，需先把模型轉成對應格式。顯存大小決定每層可用的位元配置，顯存越緊就越要在位元寬度上妥協。這一套適合追求單卡低延遲、且願意處理轉換流程的使用者。
三個框架的共同原則是：先用小模型驗證流程，再用目標模型調參數；每改一個參數就記錄一次結果，避免同時改動多個變數而無法歸因。
效能驗證方式
效能比較必須在同一基礎上進行，否則結論沒有意義。
- 固定提示內容與輸出長度，分別量測生成速度與第一個 token 的延遲。
- 每次只改一個變數（量化層級、卸載層數、上下文長度），比對差異。
- 監控記憶體峰值，確認沒有落入交換空間，一旦落入，速度數據不可用。
- 注意散熱與降頻：長時間連續測試的後段結果會低於前段，比較時要取相同條件。
- 跨框架比較時，使用同一模型的等效量化版本，並在相同提示下執行。
建議把測試腳本化，固定輸入與測量方式，這樣換版本或換參數時可以快速重跑並對照。
常見錯誤與檢查清單
常見錯誤
- 拿不同量化版本互相比較速度，結論無效。
- 只看生成速度，忽略第一個 token 的延遲，互動體驗其實很差。
- 在 Apple Silicon 上期待 ExLlamaV2 可用，或反過來在 NVIDIA 上期待 MLX。
- 模型已落入交換空間仍宣稱可用，實際速度與穩定性都不可接受。
- 忽略上下文長度對記憶體的影響，開大後才發現載入失敗。
- 混用不同框架的量化檔案，載入直接報錯。
檢查清單
- 已確認目標平台的框架支援範圍。
- 已確認模型格式與框架匹配，必要時完成轉換。
- 已依記憶體餘量選擇量化層級。
- 已記錄卸載層數、執行緒數與上下文長度的組合。
- 已量測生成速度與首 token 延遲。
- 已確認測試期間沒有觸發交換空間。
- 已把測試流程腳本化，方便重跑對照。