先講結論：82GB 的 MoE 大模型塞進兩張 32GB 的 5090，開 MTP（Multi-Token Prediction）投機解碼，實測 decode 平均 75.4 t/s，draft 接受率 69.4%。比原本 NVFP4 引擎跑約 10 t/s 快了 7 倍。過程中踩了三個坑，全部記錄在下面。

1. 目前設備

兩張卡沒有 NVLink / P2P DMA，tensor split 的跨卡通訊走 host 記憶體（走 PCIe），這是後段效能數據需要留意的點。

2. 軟體版本與 AI 模型

llama.cpp build

version: 0.3.0-dev (build 10715, commit 92cedc867)
built with GNU 11.4.0 for Linux x86_64
(Compiled by the Unsloth team)

用 Unsloth 官方 prebuilt 的 cuda13-portable linux-x64 版，不是自己編。

模型

模型架構 qwen4exp，embedding_length = 2560，target block_count = 48，head 是 49 層（48 主 + 1 nextn）。

️ 版本相容性是這題的第一個坑

Unsloth 的 MTP head 用的是新式 per-block tensor 命名（blk.48.nextn.hc_head_down/up/norm）。我原本的 build 是 10702，只認舊式的 top-level output_hc_norm.weight，結果直接 fatal：

E llama_model_load: error loading model: check_tensor_dims:
  tensor 'output_hc_norm.weight' not found

換成 quimmedes 的舊 schema head 也不行，變成 tensor 數量對不上：

W model has unused tensor blk.48.indexer.q_proj/k_proj/q_norm/k_norm — ignoring
E llama_model_load: wrong number of tensors; expected 35, got 34

三个 head 全部跟 build 10702 不相容。 正解是照 README 用 b10715（unslothai/llama.cpp PR#144）。head 和 build 必須一起對，不能只換一邊。

驗證 head 跟 target 配對的方法（用 python gguf.GGUFReader 讀兩邊 metadata 比）：同 general.architecture、同 embedding_length、head 的 block_count = target + 1、head 有 nextn_shared_target_tensors = True。

3. GPU / CPU 實際記憶體佔用

VRAM（雙卡 tensor split，1:1）

進程 llama-server 在兩卡各佔 29.0 GB / 29.6 GB。

RAM

注意：模型檔 77 GB > RAM 60 GB，所以開機載入時一定會有磁碟 I/O（走 page cache 分頁）。RAM 剩很多是因為 --n-cpu-moe 0 沒有把 MoE expert 留在 CPU，模型權重全在 VRAM。

️ VRAM 幾乎打滿，這是第三個坑

兩卡各只剩 3 GB 上下。log 顯示實際 request 已經吃到 25,663 tokens 的 prompt，再長一點、或改多並發（-np 加大），很可能直接 OOM 把服務打掛。這套配置目前是**單併發（-np 1）**才跑得動。

4. 參數指令

從運行中進程的 /proc/<pid>/cmdline 直接抓出來的，不是我貼的範例：

# Unsloth cuda13-portable prebuilt 需要 CUDA 13 runtime（第二個坑，見下方）
export LD_LIBRARY_PATH="/path/to/cuda-13/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

llama-server \
  -m  /models/Qwen3.8-Flash-Next-UD-IQ4_XS/UD-IQ4_XS/Qwen3.8-Flash-Next-UD-IQ3_XXS-00001-of-00003.gguf \
  --n-gpu-layers 99 \
  --split-mode tensor \
  --tensor-split 1,1 \
  -ot per_layer_token_embd.weight=CPU \
  --n-cpu-moe 0 \
  --load-mode none \
  --ctx-size 69632 \
  --flash-attn on \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --batch-size 2048 \
  --ubatch-size 512 \
  -np 1 \
  --kv-unified \
  --jinja \
  --reasoning-preserve \
  -t 32 \
  --host 0.0.0.0 \
  --port 12435 \
  --alias qwen38-nvfp4-mtp \
  --no-webui --no-mmproj \
  --spec-type draft-mtp \
  -md  /models/mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf \
  --spec-draft-n-max 2 \
  --n-gpu-layers-draft 99

關鍵參數說明：

️ 第二個坑：Unsloth prebuilt 的 CUDA runtime 依賴

這是讓我卡最久的一個。換好 build 10715 之後，執行直接炸：

W common_fit_params: ... llama_params_fit is not implemented for SPLIT_MODE_TENSOR, abort
E llama_prepare_model_devices: LLAMA_SPLIT_MODE_TENSOR needs >= 1 devices

看起來像雙卡設定寫錯，其實是這支 prebuilt 看不到任何 GPU。查下去發現：

ldd libggml-cuda.so:
    libcudart.so.13 => not found      ← 缺
    libcublas.so.13 => not found      ← 缺
    libcuda.so.1 => /lib/... (OK)     ← 只有 driver API

cuda13-portable 的 libggml-cuda.so 需要 CUDA 13 的 runtime libs，而本機只裝了 driver（595.84）沒有 CUDA 13 toolkit runtime。而且這支 build 是 ggml_backend_dl: true + rpath: $ORIGIN（backend 執行期動態載入），所以 ldd llama-server 主程式看不到 CUDA 相依，要 ldd libggml-cuda.so 才看得出來。

解法不用裝 CUDA toolkit，只要把路徑指過去（我直接借用原本另一個引擎在用的同一組 CUDA 13 libs）：

export LD_LIBRARY_PATH="/path/to/cuda-13/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

加上之後 ldd 的 not found 變成 0 個，雙卡就抓到了。

關於 borrow_shared_tensor 錯誤行

用 shared head 啟動時 log 會出現：

E llama_model_load: error loading model: borrow_shared_tensor: this model is a draft head without its own 'token_embd.weight'; load it as a draft of its target model, not on its own
W operator(): failed to measure the memory of the extra model, fitting without it

這是正常行為（README L107-119 有說明）。shared-Q8_0 是靠借用 target model 的 tensor 來省 1.3GB VRAM，所以單獨載入時會報這個。看到不用緊張，MTP 照樣跑。

5. 效能數據

全部數字從 server log 統計得出（13 次完整生成樣本，累計 46,358 個 decode tokens），不是跑基准測試，是實際使用流量。

Decode 速度

MTP 投機解碼成效

接受率 69.4% 高於 README 標示的 66%（README 那個數字是greedy 下的保證值）。

Prompt Processing

pp 變異很大（202~1476），因為短 prompt 沒有足夠 batch 效應。

對照：換腦前後

約 7 倍。

️ 關於 MTP 划算的條件（重要）

Unsloth MTP README 的數據，跟我自己觀察一致的：MTP 只在單併發下賺。

而且 README 的數字是 greedy decoding 下才有；temperature 拉高後接受率會掉（我實際用非 greedy，接受率就在 55~82% 跳）。

所以這套配置是「單流高吞吐」取向。如果你的場景是多 client 併發打同一個 port，開 MTP 反而是負擔——那個情境應該關 --spec-type，或者用更大的 draft 容量去換。我目前 -np 1 就是這個理由。

總結踩過的三個坑

1. build 和 head 必須一起對：build 10702 + unsloth 新式 head = output_hc_norm.weight not found；舊 head + 新 build = wrong number of tensors。照 README 用 b10715（PR#144）。
2. cuda13-portable 需要 CUDA 13 runtime：只裝 driver 會報 needs >= 1 devices（誤導性錯誤訊息）。查 ldd libggml-cuda.so（不是 ldd 主程式），用 LD_LIBRARY_PATH 補路徑。
3. VRAM 只剩 3 GB/卡：77GB 模型對半切進 2×32GB，KV cache 量化到 q4_0 才擠進 69K context。想加併發或加長 context 之前先算 VRAM，-np 1 是目前的上限。

驗證 MTP 有真的在跑（給同樣配置的人）

grep 'draft acceptance' server.log
# 出現 "draft acceptance = 0.69 (N accepted / M generated), mean len = 2.39" 才是真的在跑

如果出現 draft-mtp 相關的 no nextn 之類錯誤，代表 head 或 build 不對。

先講結論：82GB 的 MoE 大模型塞進兩張 32GB 的 5090，開 MTP（Multi-Token Prediction）投機解碼，實測 decode 平均 75.4 t/s，draft 接受率 69.4%。比原本 NVFP4 引擎跑約 10 t/s 快了 7 倍。過程中踩了三個坑，全部記錄在下面。

1. 目前設備

兩張卡沒有 NVLink / P2P DMA，tensor split 的跨卡通訊走 host 記憶體（走 PCIe），這是後段效能數據需要留意的點。

2. 軟體版本與 AI 模型

llama.cpp build

version: 0.3.0-dev (build 10715, commit 92cedc867)
built with GNU 11.4.0 for Linux x86_64
(Compiled by the Unsloth team)

用 Unsloth 官方 prebuilt 的 cuda13-portable linux-x64 版，不是自己編。

模型

模型架構 qwen4exp，embedding_length = 2560，target block_count = 48，head 是 49 層（48 主 + 1 nextn）。

️ 版本相容性是這題的第一個坑

Unsloth 的 MTP head 用的是新式 per-block tensor 命名（blk.48.nextn.hc_head_down/up/norm）。我原本的 build 是 10702，只認舊式的 top-level output_hc_norm.weight，結果直接 fatal：

E llama_model_load: error loading model: check_tensor_dims:
  tensor 'output_hc_norm.weight' not found

換成 quimmedes 的舊 schema head 也不行，變成 tensor 數量對不上：

W model has unused tensor blk.48.indexer.q_proj/k_proj/q_norm/k_norm — ignoring
E llama_model_load: wrong number of tensors; expected 35, got 34

三个 head 全部跟 build 10702 不相容。 正解是照 README 用 b10715（unslothai/llama.cpp PR#144）。head 和 build 必須一起對，不能只換一邊。

驗證 head 跟 target 配對的方法（用 python gguf.GGUFReader 讀兩邊 metadata 比）：同 general.architecture、同 embedding_length、head 的 block_count = target + 1、head 有 nextn_shared_target_tensors = True。

3. GPU / CPU 實際記憶體佔用

VRAM（雙卡 tensor split，1:1）

進程 llama-server 在兩卡各佔 29.0 GB / 29.6 GB。

RAM

注意：模型檔 77 GB > RAM 60 GB，所以開機載入時一定會有磁碟 I/O（走 page cache 分頁）。RAM 剩很多是因為 --n-cpu-moe 0 沒有把 MoE expert 留在 CPU，模型權重全在 VRAM。

️ VRAM 幾乎打滿，這是第三個坑

兩卡各只剩 3 GB 上下。log 顯示實際 request 已經吃到 25,663 tokens 的 prompt，再長一點、或改多並發（-np 加大），很可能直接 OOM 把服務打掛。這套配置目前是**單併發（-np 1）**才跑得動。

4. 參數指令

從運行中進程的 /proc/<pid>/cmdline 直接抓出來的，不是我貼的範例：

# Unsloth cuda13-portable prebuilt 需要 CUDA 13 runtime（第二個坑，見下方）
export LD_LIBRARY_PATH="/path/to/cuda-13/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

llama-server \
  -m  /models/Qwen3.8-Flash-Next-UD-IQ4_XS/UD-IQ4_XS/Qwen3.8-Flash-Next-UD-IQ3_XXS-00001-of-00003.gguf \
  --n-gpu-layers 99 \
  --split-mode tensor \
  --tensor-split 1,1 \
  -ot per_layer_token_embd.weight=CPU \
  --n-cpu-moe 0 \
  --load-mode none \
  --ctx-size 69632 \
  --flash-attn on \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --batch-size 2048 \
  --ubatch-size 512 \
  -np 1 \
  --kv-unified \
  --jinja \
  --reasoning-preserve \
  -t 32 \
  --host 0.0.0.0 \
  --port 12435 \
  --alias qwen38-nvfp4-mtp \
  --no-webui --no-mmproj \
  --spec-type draft-mtp \
  -md  /models/mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf \
  --spec-draft-n-max 2 \
  --n-gpu-layers-draft 99

關鍵參數說明：

️ 第二個坑：Unsloth prebuilt 的 CUDA runtime 依賴

這是讓我卡最久的一個。換好 build 10715 之後，執行直接炸：

W common_fit_params: ... llama_params_fit is not implemented for SPLIT_MODE_TENSOR, abort
E llama_prepare_model_devices: LLAMA_SPLIT_MODE_TENSOR needs >= 1 devices

看起來像雙卡設定寫錯，其實是這支 prebuilt 看不到任何 GPU。查下去發現：

ldd libggml-cuda.so:
    libcudart.so.13 => not found      ← 缺
    libcublas.so.13 => not found      ← 缺
    libcuda.so.1 => /lib/... (OK)     ← 只有 driver API

cuda13-portable 的 libggml-cuda.so 需要 CUDA 13 的 runtime libs，而本機只裝了 driver（595.84）沒有 CUDA 13 toolkit runtime。而且這支 build 是 ggml_backend_dl: true + rpath: $ORIGIN（backend 執行期動態載入），所以 ldd llama-server 主程式看不到 CUDA 相依，要 ldd libggml-cuda.so 才看得出來。

解法不用裝 CUDA toolkit，只要把路徑指過去（我直接借用原本另一個引擎在用的同一組 CUDA 13 libs）：

export LD_LIBRARY_PATH="/path/to/cuda-13/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"

加上之後 ldd 的 not found 變成 0 個，雙卡就抓到了。

關於 borrow_shared_tensor 錯誤行

用 shared head 啟動時 log 會出現：

E llama_model_load: error loading model: borrow_shared_tensor: this model is a draft head without its own 'token_embd.weight'; load it as a draft of its target model, not on its own
W operator(): failed to measure the memory of the extra model, fitting without it

這是正常行為（README L107-119 有說明）。shared-Q8_0 是靠借用 target model 的 tensor 來省 1.3GB VRAM，所以單獨載入時會報這個。看到不用緊張，MTP 照樣跑。

5. 效能數據

全部數字從 server log 統計得出（13 次完整生成樣本，累計 46,358 個 decode tokens），不是跑基准測試，是實際使用流量。

Decode 速度

MTP 投機解碼成效

接受率 69.4% 高於 README 標示的 66%（README 那個數字是greedy 下的保證值）。

Prompt Processing

pp 變異很大（202~1476），因為短 prompt 沒有足夠 batch 效應。

對照：換腦前後

約 7 倍。

️ 關於 MTP 划算的條件（重要）

Unsloth MTP README 的數據，跟我自己觀察一致的：MTP 只在單併發下賺。

而且 README 的數字是 greedy decoding 下才有；temperature 拉高後接受率會掉（我實際用非 greedy，接受率就在 55~82% 跳）。

所以這套配置是「單流高吞吐」取向。如果你的場景是多 client 併發打同一個 port，開 MTP 反而是負擔——那個情境應該關 --spec-type，或者用更大的 draft 容量去換。我目前 -np 1 就是這個理由。

總結踩過的三個坑

1. build 和 head 必須一起對：build 10702 + unsloth 新式 head = output_hc_norm.weight not found；舊 head + 新 build = wrong number of tensors。照 README 用 b10715（PR#144）。
2. cuda13-portable 需要 CUDA 13 runtime：只裝 driver 會報 needs >= 1 devices（誤導性錯誤訊息）。查 ldd libggml-cuda.so（不是 ldd 主程式），用 LD_LIBRARY_PATH 補路徑。
3. VRAM 只剩 3 GB/卡：77GB 模型對半切進 2×32GB，KV cache 量化到 q4_0 才擠進 69K context。想加併發或加長 context 之前先算 VRAM，-np 1 是目前的上限。

驗證 MTP 有真的在跑（給同樣配置的人）

grep 'draft acceptance' server.log
# 出現 "draft acceptance = 0.69 (N accepted / M generated), mean len = 2.39" 才是真的在跑

如果出現 draft-mtp 相關的 no nextn 之類錯誤，代表 head 或 build 不對。

@Xiaote 妳說對了，這是我跑完後覺的怪怪的，目前NCCL還在弄...弄出來會更新上去（如果成功的話）希望能PP破2500 TG破百