這篇解什麼問題
Apple 的 MLX（GitHub: ml-explore/mlx，官方文件、2023-12 的 Awni Hannun 公告，沒有正式 arXiv 論文）跟 llama.cpp 生態的 GGUF，理論上該是「同一個模型、同一個量化位元，只是換一套推理引擎跑」。如果真是這樣，兩者的差異應該只剩延遲。這篇筆記要驗證：backend 差異真的只影響速度，還是連輸出正確性都會變？
我怎麼做
挑同一顆模型 gemma-3-4b-it、同一個量化等級（4-bit），兩套 backend 各跑一次同樣的 5 題 prompt：
- GGUF：
unsloth/gemma-3-4b-it-GGUF（Q4_K_M）+llama-cpp-python - MLX：
mlx-community/gemma-3-text-4b-it-4bit+mlx_lm
兩者都套用同一份 Gemma chat template，greedy decoding（temperature=0，結果可重現，不是隨機 noise）。
結果與數據
| backend | quant | total | T2 (Python) | 延遲 |
|---|---|---|---|---|
| GGUF | Q4_K_M | 4.60 | 1.00 | 14.4s |
| MLX | 4bit-MLX | 3.93 | 0.33 | 13.6s |
延遲幾乎相同（14.4s vs 13.6s，4B 模型在 M1 上兩個 backend 吞吐量差異可忽略）。但總分差了 0.67 分，而且全部集中在 T2 Python 生成：GGUF 版本的 flatten_dict 遞迴邏輯完全正確（3/3 test），MLX 版本的同一個函式遞迴拼接字串寫壞了（sep + sep + k 而非正確的 prefix 拼接），只過 1/3 test。這不是模型「隨機發揮失常」——兩次都是 greedy decoding，同樣的輸入必然得到同樣的輸出，兩個 backend 的數值精度差異足以讓模型走上不同的推理路徑。
把這個發現放到週三主文的 4 模型 × 2 backend 矩陣裡看更完整：gemma3、qwen3 偏好 GGUF，llama3.1 反而偏好 MLX，差異一律集中在 T1（繁中）和 T2（Python）這類自由生成任務，結構化任務（T3 SQL、T4 JSON）兩個 backend 從來沒有差異。
一句話結論
「同一個模型、同一個量化等級」不等於「同一個輸出」——backend 的數值實作差異在自由生成任務上會產生功能性的正確性差異，而且這個效應是模型特定的，選 backend 之前一定要拿你真正要跑的任務實測過，不能只看延遲。