Tanpopo · Local Model Control

Performance & accuracy report ·

MLX 與 GGUF 轉換的
載入速度及運算精確度

以 4B、9B、27B 三組配對模型比較原生 MLX、llama.cpp + GGUF 與三種 MLX+GGUF 轉換策略。 報告如實列出生成速度、固定 100 題結果、Fast GGUF 容量與程序 RAM，不納入載入效率。

Test environment

測試環境

15 組配置在同一台主機串行執行；同一時間只啟動一個模型 Runtime。

硬體

主機
Mac mini（Mac16,11）
SoC
Apple M4 Pro
CPU／GPU
12 核／16 核
記憶體
64 GB 統一記憶體

系統與模型磁碟

macOS
26.6.2（25G83）
架構／Metal
arm64／Metal 4
儲存媒介
USB/SATA
儲存
1 TB USB／APFS

Runtime

Tanpopo MLX
1.5.0 · cache12
mlx-swift-lm
3.31.4
MLX Swift
0.31.6
llama.cpp
4e97ac86

測試前以 uptime、ps 與系統 CPU 取樣確認沒有其他 mlx-server／llama-server；CPU idle 維持 80.5%～83.8%，系統未回報溫控或效能限制。27B llama.cpp + GGUF 的波動結果在相同條件下重測，正式吞吐採三次中位數。

Actual product parameters

MLX+GGUF 三策略

Group 完全由模式與來源 tensor metadata 自動決定，不依模型名稱，也不需手動指定。

模式參數主要權重定位
原生MLX檔案未轉換原生 checkpointAffine 4-bit／group 64速度與品質基準
llama.cpp + GGUFllama.cpp 原生 GGUF直接使用來源 GGUF 量化GGUF Runtime 對照
MLX + Fast GGUF Mode 1mode1 + controlsK-Quant 沿用來源 4-bit block；其他張量 group 64均衡．預設
MLX + Fast GGUF Mode 2mode2 + controls低位元來源重新量化為 INT8／group 64較高精度
MLX + Fast GGUF Mode 3mode3 + controls低位元來源重新量化為 INT4／group 32最快

Mode 1 沿用的 K-Quant tensor 由來源格式保留 32 元素 sub-block；Mode 2 自動使用 group 64，Mode 3 固定使用 group 32。 三種模式均使用相同 recurrent controls，且各自建立獨立 Fast GGUF。

Steady-state generation

生成速度

每組先暖機一次，再取三次 128-token 回覆的 Runtime 生成速度中位數。

原生MLX檔案未轉換 llama.cpp + GGUF MLX + Fast GGUF Mode 1 MLX + Fast GGUF Mode 2 MLX + Fast GGUF Mode 3
模型模式中位 tok/s端到端 tok/s比較基準 (MLX)比較 llama.cpp + GGUF
Qwen 3.5 4B原生MLX檔案未轉換81.60974.953–1.43×
llama.cpp + GGUF57.16456.12670.0%–
MLX + Fast GGUF Mode 171.37666.35587.5%1.25×
MLX + Fast GGUF Mode 271.30166.30387.4%1.25×
MLX + Fast GGUF Mode 375.13769.57592.1%1.31×
Ornith 1.5 9B原生MLX檔案未轉換48.43844.358–1.39×
llama.cpp + GGUF34.96334.27072.2%–
MLX + Fast GGUF Mode 137.27934.80677.0%1.07×
MLX + Fast GGUF Mode 227.33525.92656.4%0.78×
MLX + Fast GGUF Mode 343.17739.93589.1%1.23×
Qwen 3.8 27B原生MLX檔案未轉換15.08813.844–1.48×
llama.cpp + GGUF10.1849.97867.5%–
MLX + Fast GGUF Mode 19.1428.64760.6%0.90×
MLX + Fast GGUF Mode 28.3437.92455.3%0.82×
MLX + Fast GGUF Mode 313.48212.48089.4%1.32×

「中位 tok/s」是 Runtime 回報的三次生成速度中位數；「端到端 tok/s」依請求開始到回覆完成的實際經過時間換算，包含 API、排程與資料處理開銷。

Fixed-set quality evaluation

精確度與有效答案

MMLU 固定 100 題；每個模型的五種模式使用完全相同題目。

原生MLX檔案未轉換 llama.cpp + GGUF MLX + Fast GGUF Mode 1 MLX + Fast GGUF Mode 2 MLX + Fast GGUF Mode 3
模型模式原樣結果排除截斷共同未截斷題組無法解析
Qwen 3.5 4B原生MLX檔案未轉換68／10068／10066／980
llama.cpp + GGUF73／10073／10071／980
MLX + Fast GGUF Mode 172／10072／10070／980
MLX + Fast GGUF Mode 272／10072／10070／980
MLX + Fast GGUF Mode 370／10070／9870／981
Ornith 1.5 9B原生MLX檔案未轉換79／10078／9978／990
llama.cpp + GGUF78／10078／10077／990
MLX + Fast GGUF Mode 178／10078／10077／990
MLX + Fast GGUF Mode 278／10078／10077／990
MLX + Fast GGUF Mode 377／10077／10076／990
Qwen 3.8 27B原生MLX檔案未轉換89／10089／10089／1000
llama.cpp + GGUF87／10087／10087／1000
MLX + Fast GGUF Mode 187／10087／10087／1001
MLX + Fast GGUF Mode 288／10088／10088／1001
MLX + Fast GGUF Mode 382／10082／10082／1004

計分與排除規則

所有 finish_reason=length 均視為截斷並排除分母，即使截斷前已出現可解析選項也不計分； 模型自行停止卻未作答仍算錯。本輪 1,500 次問答共有 3 次截斷，排除截斷後共 1,497 次可評分。 「共同未截斷題組」只比較同一模型下五種模式都未截斷的題目。

Storage & memory

磁碟占用與程序 RAM

磁碟分開列出原始模型與 Fast GGUF；RAM 每 200 ms 取樣，列出程序生命週期峰值與生成期間平均值。

模型模式原始模型Fast GGUFRAM 峰值RAM 平均觀察
Qwen 3.5 4B原生MLX檔案未轉換2.851 GiB–2.394 GiB2.393 GiB無 Fast GGUF
llama.cpp + GGUF2.406 GiB–3.058 GiB3.017 GiB直接執行來源 GGUF
MLX + Fast GGUF Mode 12.406 GiB2.539 GiB0.769 GiB0.681 GiBRAM 最低
MLX + Fast GGUF Mode 22.406 GiB2.539 GiB0.782 GiB0.688 GiBMode 1 接近
MLX + Fast GGUF Mode 32.406 GiB2.293 GiB1.241 GiB1.064 GiBFast GGUF 最小、速度最高
Ornith 1.5 9B原生MLX檔案未轉換4.711 GiB–4.882 GiB4.881 GiB無 Fast GGUF
llama.cpp + GGUF5.383 GiB–5.850 GiB5.809 GiB直接執行來源 GGUF
MLX + Fast GGUF Mode 15.383 GiB5.759 GiB1.752 GiB1.750 GiB各方面表現均衡
MLX + Fast GGUF Mode 25.383 GiB8.682 GiB1.254 GiB1.253 GiBRAM 最低、Fast GGUF 最大
MLX + Fast GGUF Mode 35.383 GiB4.871 GiB2.055 GiB2.020 GiBFast GGUF 最小、速度最高
Qwen 3.8 27B原生MLX檔案未轉換14.977 GiB–14.291 GiB14.291 GiB無 Fast GGUF
llama.cpp + GGUF15.334 GiB–16.377 GiB16.260 GiB直接執行來源 GGUF
MLX + Fast GGUF Mode 115.334 GiB22.708 GiB5.844 GiB5.400 GiB來源 4-bit block 與其他張量混用
MLX + Fast GGUF Mode 215.334 GiB25.972 GiB5.216 GiB4.102 GiBRAM 平均最低、Fast GGUF 最大
MLX + Fast GGUF Mode 315.334 GiB14.603 GiB6.377 GiB4.323 GiBFast GGUF 最小、速度最高

使用 MMap 技術降低 RAM 用量，原生 MLX 目前尚未支援。表中為程序 RSS，因此不等於邏輯權重總量或整台主機的統一記憶體使用量。

Experimental follow-up

Recurrent controls 量測範圍

本輪三種 Fast GGUF 模式均使用相同的 recurrent controls 設定，避免額外變因。

固定 controls 設定

MLX + Fast GGUF Mode 1、Mode 2 與 Mode 3 均傳入 --gguf-recurrent-promotion controls； 本節只記錄測試條件，不把 recurrent promotion 的效果和三種儲存策略混為同一項比較。

Methodology

測試方法與限制

速度

  • OpenAI 相容 /v1/chat/completions
  • 46 prompt tokens、128 completion tokens
  • Temperature 0、Top-K 1、thinking 關閉
  • 暖機 1 次；正式 3 次採中位 tok/s

精度

  • OpenAI Simple Evals MMLU CSV
  • 固定 100 題、seed 0
  • 每個模型與模式使用完全相同題目
  • 關閉 thinking；輸出上限 512 tokens、單題逾時 600～900 秒
  • 只接受獨立 A、B、C、D；所有 finish_reason=length 均排除

共同 Runtime

  • 原生 MLX 與 MLX+GGUF 均使用相同 Release build
  • MLX+GGUF 明確傳入 --mmap；原生MLX檔案未轉換模式未傳入
  • 三種 Fast GGUF 模式各自使用已完成的 Fast GGUF
  • Group 由 Mode 1／2／3 自動決定，未手動指定
  • KV cache 上限 4096 tokens
  • 未啟用 DFlash 與 KV Cache 量化

解讀限制

  • 本輪涵蓋 4B Q4_0、9B Q4_K_M 與 27B 混合量化來源
  • 每個模型均完成五種模式、固定 100 題與三次正式速度量測
  • 本報告不量測載入效率；磁碟只列原始模型與 Fast GGUF
  • 程序 RSS 不等於系統統一記憶體總量
  • Runtime 或 Metal 更新後應重新測試

策略量測彙總：gguf-strategy-results.csv · 精度彙總：accuracy-summary.csv · 每題結果：accuracy-results.csv · 速度與資源原始彙總：benchmark-results.csv · 重現腳本：run-benchmark.sh、 run-accuracy-benchmark.sh

Result notes

結果補充

Qwen 3.5 4B

五種模式排除截斷後為 68.0%～73.0%；原生 MLX 為 81.609 tok/s，三種 Fast GGUF 為 71.301～75.137 tok/s。

Ornith 1.5 9B

五種模式排除截斷後為 77.0%～78.8%；原生 MLX 為 48.438 tok/s，三種 Fast GGUF 為 27.335～43.177 tok/s。

Qwen 3.8 27B

五種模式排除截斷後為 82.0%～89.0%；原生 MLX 為 15.088 tok/s，三種 Fast GGUF 為 8.343～13.482 tok/s。

適用範圍

三組模型的速度、精確度、Fast GGUF 與 RAM 分布並不相同；結果只代表本次模型、Runtime 與測試條件，其他架構、量化格式或 checkpoint 需另行量測。