<![CDATA[淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM]]>上篇在這裏

然而上篇單純是使用vLLM, 今天就來嘗試一下llama.cpp這個引擎, 之後有機會的話也想碰一下SGLang

以下正文, 關於K Quant以及Autoround可以參考這篇文章

這篇也會提到關於MoQ的技術, 由於篇幅有點長, 所以會分段發

啓動咒語 (MoQ 4.95作爲例子)

docker run -d --restart unless-stopped --gpus all --name llama-cpp-server -p 8081:8080 -v "$PWD/models:/models:ro" ghcr.io/ggml-org/llama.cpp:full-cuda13 /app/llama-server --model /models/Jianqiao1/Qwen3.6-27B-MTP-MoQ-GGUF/Qwen3.6-27B-MTP-MoQ-4.95.gguf --host 0.0.0.0 --port 8080 --ctx-size 200000 --n-gpu-layers 999 --parallel 1 --ubatch-size 512 --cache-type-k q8_0 --cache-type-v q8_0 --flash-attn on --threads 8 --spec-type draft-mtp --spec-draft-n-max 3 --jinja --spec-default
  • llama.cpp相比vLLM在KV Cache上面比較靈活, 可以分開設定data type
  • 啓動flash attention, llama.cpp在flash attention上的開發進度比vLLM好, 不過llama.cpp好像也不支持flashinfer
  • 其他就基本設定

llama.cpp基本測試

顯存變動 => 測試完立即記錄
顯存變動2 => 測試完等5分鐘記錄, 測試是否有顯存回收 不過好像沒有回收到就是了

Model 測試階段 設定上下文長度 測試上下文深度 顯存變動 顯存變動2 API pp tok/s API tg tok/s TTFR
MoQ 4.95 zero-like 512 0 16185, 32623 16185, 32623 n/a n/a n/a
MoQ 4.95 half 100000 98304 20369, 32623 20391, 32623 982.37 52.56 101.23s
MoQ 4.95 full 200000 196608 24669, 32623 24691, 32623 632.23 40.22 312.73s
Unsloth Q5_K_M zero-like 512 0 19259, 32623 19259, 32623 n/a n/a n/a
Unsloth Q5_K_M half 100000 98304 23443, 32623 23563, 32623 921.55 50.48 107.96s
Unsloth Q5_K_M full 200000 196608 27743, 32623 27863, 32623 610.53 33.82 323.88s
AutoRound Q5_K_M zero-like 512 0 18975, 32623 18975, 32623 n/a n/a n/a
AutoRound Q5_K_M half 100000 98304 23159, 32623 23181, 32623 922.93 44.01 107.76s
AutoRound Q5_K_M full 200000 196608 27459, 32623 27481, 32623 611.04 38.01 323.57s

測試完的Nvidia-smi作爲證明
a1439400-6e17-4f97-bad5-512672f5c9a1-image.jpeg :

]]>https://lcz.me/topic/647/淺談-llama.cpp-配合-rtx-pro-4500-簡單測試-qwen-3.6-27b-moq-autoround以及普通ud-q5kmRSS for NodeWed, 01 Jul 2026 08:03:37 GMTSun, 21 Jun 2026 14:16:25 GMT60<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 23:12:29 GMT]]>@stxpnet

這個就是用比較接近現實的問題來測試, 不過不排除Qwen或者MoQ在訓練的加入這些原資料就是了

stxp大你那篇就是實戰, 用那個會比單純看這個好點

]]>https://lcz.me/post/7757https://lcz.me/post/7757Sun, 21 Jun 2026 23:12:29 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 23:09:42 GMT]]>@imbiplaza-ASUS

Blackwell架構開始成熟, 推理引擎開始更多優化, 估計之後2到3年也會這樣吧

]]>https://lcz.me/post/7756https://lcz.me/post/7756Sun, 21 Jun 2026 23:09:42 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 19:25:09 GMT]]>c2f23ff6-a2d2-47d8-b780-e6a93a51a087-image.jpeg 只有这个分辨率,lmstudio我没找到，我的显卡也只能跑 4.5的moq. 晚点我详细试试

]]>https://lcz.me/post/7741https://lcz.me/post/7741Sun, 21 Jun 2026 19:25:09 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 16:18:12 GMT]]>我看到越来越多无审查的NVFP4。。。。陆陆续续下载了，单单看 t/s 的增长, 很爽

]]>https://lcz.me/post/7722https://lcz.me/post/7722Sun, 21 Jun 2026 16:18:12 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 15:24:12 GMT]]>這篇大約就講到這裏

之後看看有沒有時間嘗試一下在llama.cpp上面用NVFP4, 不過llama.cpp好像沒針對Blackwell的NVFP4做什麽優化啊...

]]>https://lcz.me/post/7717https://lcz.me/post/7717Sun, 21 Jun 2026 15:24:12 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 15:16:12 GMT]]>MoQ技術探討

其實MoQ在這裏并不是第一次出現, @stxpnet stxp大大有在這裏發過帖子探討模型輸出的代碼素質, 各位可以看完再繼續

MoQ (Mixture of Quantization, 混合量化)最好被理解為一種 量化配方 (recipe), 而不是單一的量化格式, 理論上他也能用在vLLM身上

  • 訓練後量化 (Post-training quantization): 從 BF16/FP16 權重開始, 訓練完成後壓縮權重

  • 混合精度量化 (Mixed precision quantization): 不同的張量 (tensor) 會採用不同的格式, 不是像普通的K Quant那樣, 強迫整個模型使用單一格式

  • 顯著權重選擇: 比較重要的權重會保持在較高的精度, 較不敏感的張量則會被壓低精度, 這個就十分類似Autoround

  • 混合量化類型: MoQ支持混合多種格式, 例如 Q5_K, Q4_K, IQ4_XS, BF16或誇張點, FP32

  • 校準數據: 通常會由一個校準數據集 (calibration set) 或重要性矩陣 (importance-matrix) 風格的訊號來決定哪些權重可以承受較低的精度, 相對來説代表這個更像坊間為Qwen 3.6 27B加入Opus Reasoning訓練集

  • 部分層會受特別關照: 正規化層 (norms), 嵌入層 (embeddings), 輸出頭 (output heads), 循環網路/狀態空間模型組件 (recurrent/SSM pieces) 或與 MTP 相關的網絡會保留較高精度, 因為這些地方的微小誤差對預測結果 (logits) 會比單純壓縮網絡内部造成較大的影響

  • 運行時解壓縮 (Runtime Dequantization): llama.cpp在推論期間進行解壓, 理論上就會按照原先定好的量化類型進行解壓 (第四點)

資料來源: https://x.com/bnjmn_marie/status/2060051274545111177?s=20

簡單一個類比就是:

MoQ 就像是在有嚴格重量限制的情況下打包行李出門旅行, 正常人不會把所有物品都換成最輕的版本, 會先把易碎或至關重要的物品放在合適的硬殼箱裡, 之後較耐用的物品用較輕的袋子裝, 而在損壞較大也無大礙的地方就隨便裝
普通的 Q5_K_M 則是規定所有東西都必須使用同一種行李箱
MoQ 則是每件物品都在能提供足夠保護的前提下, 使用最便宜/最輕的容器

這個模式基本上追隨Autoround的思路

]]>https://lcz.me/post/7712https://lcz.me/post/7712Sun, 21 Jun 2026 15:16:12 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 14:56:13 GMT]]>Bit Per Weight探討

Model Local GGUF size Approx file bpw Note
Unsloth Q5_K_M 19,834,053,760 bytes 5.81 基準Q5_K_M GGUF
AutoRound Q5_K_M 19,535,700,032 bytes 5.72 減少約1.5%, 基本忽略不計
MoQ 4.95 16,540,767,424 bytes 4.84 減少約16.6%

儘管MoQ的BPW比Autoround Q5KM還低, 但是KLD其實也沒差太遠, PPL相差則可接受範圍, 權重在顯存也比Autoround少大約2GB, 預留更多KV Cache空間, 應該也能當成主力使用

不過我應該要用Q4_K_M來比較才對, 畢竟他們的BPW比較類似, oh well it happened

]]>https://lcz.me/post/7708https://lcz.me/post/7708Sun, 21 Jun 2026 14:56:13 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 14:40:03 GMT]]>KLD, PPL測試

llama.cpp本身支持這兩個數據, 前者可以當作跟基準模型的偏差值, 後者可以當成困惑度, 視作模型對於下個要預測的Token精準度就好 (越低代表模型預測能力越好)

因爲VRAM大小沒辦法測試原生BF16/Q8, 所以單純以UD Unsloth Q5KM作爲基準模型

上下文512, 32分塊, 測試文本沿用vLLM的在Readme提及的預設長篇Sherlock小説

模型 PPL
Unsloth Q5_K_M 1.2398 +/- 0.01457
MoQ 4.95 1.2796 +/- 0.01553
AutoRound Q5_K_M 1.3137 +/- 0.01656
模型 基準 Mean KLD 99.9% KLD Same top-p
MoQ 4.95 Unsloth Q5_K_M 0.085771 5.087046 95.870%
AutoRound Q5_K_M Unsloth Q5_K_M 0.138661 7.634626 94.645%
]]>https://lcz.me/post/7706https://lcz.me/post/7706Sun, 21 Jun 2026 14:40:03 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 14:29:00 GMT]]>MTP測試

模型 測試階段 Generated draft tokens Accepted draft tokens Acceptance Mean acceptance length Acceptance rate per position (first 3)
MoQ 4.95 half 56 44 78.571% 3.32 (0.895, 0.842, 0.579)
MoQ 4.95 full 51 45 88.235% 3.65 (0.941, 0.882, 0.824)
Unsloth Q5_K_M half 53 45 84.906% 3.50 (0.944, 0.889, 0.667)
Unsloth Q5_K_M full 57 43 75.439% 3.15 (0.900, 0.650, 0.600)
AutoRound Q5_K_M half 61 42 68.852% 3.00 (0.857, 0.667, 0.476)
AutoRound Q5_K_M full 51 45 88.235% 3.65 (1.000, 0.882, 0.765)
]]>https://lcz.me/post/7705https://lcz.me/post/7705Sun, 21 Jun 2026 14:29:00 GMT<![CDATA[Reply to 淺談 llama.cpp 配合 RTX Pro 4500 簡單測試 Qwen 3.6 27B, MoQ, AutoRound以及普通UD Q5KM on Sun, 21 Jun 2026 14:30:44 GMT]]>跨平臺llama-benchy的數據

tokenizer沿用vllm的kaitchup/Qwen3.6-27B-autoround-nvfp4-linearattn-mtp-BF16

測試咒語

~/llama-benchy/.venv/bin/llama-benchy --base-url http://127.0.0.1:8081/v1 --model Qwen3.6-27B-MTP-MoQ --served-model-name /models/Jianqiao1/Qwen3.6-27B-MTP-MoQ-GGUF/Qwen3.6-27B-MTP-MoQ-4.95.gguf --tokenizer ~/vllm/models/kaitchup/Qwen3.6-27B-autoround-nvfp4-linearattn-mtp-BF16 --pp 1024 --tg 64 --depth 98304 196608 --runs 1 --latency-mode generation --concurrency 1 --skip-coherence --post-run-cmd 'nvidia-smi --query-gpu=timestamp,memory.used,memory.total --format=csv,noheader,nounits' --save-result llama-benchy-moq-longctx.json --format json
模型 測試階段 上下文長度 Avg latency TTFR Prefill tok/s Generation tok/s Peak tok/s
MoQ 4.95 half 98304 107.74 ms 101.23s 982.37 52.56 56
MoQ 4.95 full 196608 107.61 ms 312.73s 632.23 40.22 42
Unsloth Q5_K_M half 98304 156.26 ms 107.96s 921.55 50.48 53
Unsloth Q5_K_M full 196608 148.79 ms 323.88s 610.53 33.82 41
AutoRound Q5_K_M half 98304 117.32 ms 107.76s 922.93 44.01 46
AutoRound Q5_K_M full 196608 114.29 ms 323.57s 611.04 38.01 41

不得不説這個比上篇的vllm差很多啊, 100K上下文vLLM也有60 tks, 是我的設定有問題還是本來就這麽差

MoQ的各個速度都很高, 而且在長上下文的表現還不錯, 可能是因爲Bit per weight相對更小的關係

]]>https://lcz.me/post/7701https://lcz.me/post/7701Sun, 21 Jun 2026 14:30:44 GMT