llama.cpp GPU 效能怎麼比：CUDA、ROCm、Vulkan 複測與選卡方法

社群裡的 llama.cpp 跑分表很適合找候選顯示卡，卻不能直接當成購買排行榜。驅動、後端、提交版本、功耗、模型量化、上下文和視訊記憶體解除安裝比例任何一項不同，都可能改變結果。

本文保留原始 scoreboard 的參考入口，但不再複製數百行跑分。重點改為：如何讀指標、怎樣複測，以及什麼情況下兩組數字可以比較。

先讀懂 pp512 和 tg128

llama-bench 常見兩項：

• pp512：一次處理 512 個提示 token，接近 prompt ingestion/prefill。
• tg128：連續生成 128 個 token，接近使用者等待回答時的 decode。

兩者單位通常是 token/s，但代表不同瓶頸。批次摘要、長提示更關注 pp；聊天和程式碼補全更關注 tg。不能只取其中最大的數字宣佈某張卡“快幾倍”。

Q4_0、Q4_K_M 等表示權重量化格式。量化不同，模型大小、視訊記憶體頻寬壓力和計算路徑也不同。FA 表示 Flash Attention 是否啟用，它對長上下文和特定後端的影響可能很大。

哪些跑分可以直接比較

至少要同時滿足：

如果 scoreboard 缺少其中幾項，只能用於粗篩，不能精確計算價效比。

CUDA 完整榜單

Llama 2 7B, Q4_0, no FA

Llama 2 7B, Q4_0, with FA

建立自己的測試基線

記錄版本：

1
2

llama-bench --version
git -C llama.cpp rev-parse HEAD

記錄 NVIDIA 環境：

1

nvidia-smi --query-gpu=name,driver_version,memory.total,power.limit,temperature.gpu --format=csv

AMD Linux：

1
2

rocminfo | head -80
rocm-smi --showproductname --showmeminfo vram --showpower --showtemp

Vulkan：

1

vulkaninfo --summary

這些輸出應和跑分 CSV 一起儲存。只有 t/s 沒有環境記錄，幾周後就很難復現。

最小複測命令

假設測試同一個 model-q4_k_m.gguf：

1
2
3
4
5
6
7
8

llama-bench \
  -m ./models/model-q4_k_m.gguf \
  -p 512 \
  -n 128 \
  -ngl 999 \
  -fa 1 \
  -r 5 \
  -o csv > bench-fa.csv

關閉 Flash Attention 做對照：

1
2
3
4
5
6
7
8

llama-bench \
  -m ./models/model-q4_k_m.gguf \
  -p 512 \
  -n 128 \
  -ngl 999 \
  -fa 0 \
  -r 5 \
  -o csv > bench-no-fa.csv

先執行一次預熱，再重複至少五次。不要同時下載模型、跑遊戲或讓桌面應用佔用大量視訊記憶體。

驗證是否真的完全進視訊記憶體

測試時觀察視訊記憶體：

1

nvidia-smi dmon -s pucm

如果模型溢位到系統記憶體或只有部分層解除安裝，結果反映的是 CPU、PCIe 和 GPU 的組合，不再是單純顯示卡效能。比較兩張卡前要確保 -ngl 和實際 offload 狀態一致。

多 GPU 還需要記錄 split mode、各卡視訊記憶體、PCIe/SXM 互連和張量切分。兩張卡能裝下更大模型，不代表小模型 decode 一定比單張大視訊記憶體卡快。

CUDA、ROCm 和 Vulkan 怎麼選

CUDA

NVIDIA 通常擁有最成熟的 llama.cpp 路徑。選卡時除了 t/s，還要看視訊記憶體容量、視訊記憶體頻寬、功耗和二手卡可靠性。能裝下目標模型往往比峰值算力更重要。

ROCm/HIP

AMD 資料必須寫明 ROCm 和驅動版本。消費級 Radeon 的支援矩陣、系統版本和具體架構會影響能否正常執行。不要把某張卡在一個 Linux 組合中的成績直接推廣到 Windows。

Vulkan

Vulkan 覆蓋範圍廣，適合缺少原生 CUDA/ROCm 路徑的裝置，也適合做跨平臺基線。但不同驅動和裝置的最佳化差異很大，社群表格尤其需要複測。

用結果回答實際選卡問題

先確定目標模型和上下文，再估算權重、KV cache 和執行時餘量。視訊記憶體剛好等於模型檔案大小通常不夠。

選擇時建議按順序判斷：

1. 目標量化能否完整放入視訊記憶體。
2. 所需上下文的 KV cache 是否還有空間。
3. tg 是否滿足互動速度。
4. pp 是否滿足長提示吞吐。
5. 後端在你的作業系統上是否穩定。
6. 功耗、噪音和總成本是否可接受。

例如，一張 tg128 更高但視訊記憶體不足的卡，執行目標 30B 模型時可能不如一張速度稍低、卻能完全裝入視訊記憶體的卡。

結果表應該怎麼寫

建議至少保留：

1
2

tested_at,llama_commit,gpu,driver,backend,model,quant,ngl,flash_attention,pp512_tps,tg128_tps,power_limit,notes
2026-08-02,abcdef1,Example GPU,driver-version,CUDA,model-name,Q4_K_M,999,true,0,0,250W,replace zeros with measured median

公開結果時標明數字是實測、中位數還是引用。不要把多個作者、多個年份、多個模型的記錄混合後仍稱為“完整天梯”。

社群資料適合做什麼

GitHub Discussions 中的 scoreboard 仍然有價值：它能幫助發現某張卡是否有人跑透過、後端是否成熟，以及大致效能區間。但最終購買或部署前，應使用同一模型在候選硬體上覆測。

原始參考：

• CUDA scoreboard discussion #15013
• Apple Silicon discussion #4167
• ROCm scoreboard discussion #15021
• Vulkan scoreboard discussion #10879
• llama.cpp GitHub