by Rain Chu 7 月 14, 2026 | AI , QWEN , 模型
NVFP4 和 MTP 最近被放在一起討論，原因很簡單：本地大模型推理開始從「能不能放進顯存」進入「怎麼把記憶體搬運成本壓到最低」的階段，Unsloth 釋出的 Qwen3.6 NVFP4 quants 主打 27B 模型可在 24GB VRAM 上運行，35B-A3B 在 B200 上可達 17,561 tok/s，並宣稱相對 NVIDIA NVFP4 quant 有 2.5 倍速度提升。
這些數字很吸引人，但不能直接翻譯成「買 RTX 5090 就一定變快」。真正該看的，是 NVFP4 和 INT4 的格式差異、MTP 如何降低推理瓶頸，以及消費級 Blackwell 現階段為什麼可能吃不到企業級 B200 的完整紅利。
先講結論
NVFP4 是 4 位元浮點量化，不是傳統 4 位元整數量化
INT4 的刻度固定，NVFP4 的浮點表示更適合保留權重動態範圍
MTP 是多 Token 預測，重點是減少每個 token 都重新搬一次權重的浪費
17,561 tok/s 是特定企業級硬體條件下的吞吐量，不是一般 RTX 50 的保證值
企業部署時，驅動、CUDA、vLLM、llama.cpp、環境變數和自動更新都可能比模型本身更容易出事
如果你之前看過我整理的 Qwen 3.6、MXFP8、NVFP4 比較 ，這篇可以當成補充版，前一篇偏選型，這篇偏底層原因和部署風險。
NVFP4 和傳統 INT4 差在哪
INT4 是 4 位元整數量化。你可以把它想成一把固定刻度的尺，每一格距離都一樣。問題是神經網路權重分布通常不是均勻的，很多重要數值會擠在接近零的位置，也會偶爾出現比較大的極端值。固定刻度很省空間，但容易犧牲細微權重差異。
NVFP4 則是 4 位元浮點量化，它仍然只用 4 位元，但用浮點格式表達數值，能用有限 bit 描述更大的動態範圍，小數值區域可以保留比較細的變化，大數值區域則用比較寬的範圍表示，這就是為什麼 NVFP4 在某些模型上可以比傳統 INT4 更接近原始權重的行為。
項目 NVFP4 傳統 INT4 數值格式 4 位元浮點 4 位元整數 刻度特性 動態範圍 固定刻度 細節保留 較能保留小數值 細微權重較易流失 硬體依賴 需要 FP4 支援與 kernel 最佳化 生態成熟 實務風險 新硬體仍看驅動成熟度 穩定但精度較受限
這裡要補一個很重要的判斷：NVFP4 不是自動贏 INT4。若硬體、驅動、kernel、推理框架都沒有最佳化，NVFP4 可能反而更慢。格式更先進，不代表你手上的卡和軟體棧已經準備好了。
MTP 為什麼會讓速度暴衝
MTP 是 Multi-Token Prediction，也就是多 Token 預測。傳統自回歸語言模型通常一次產生一個 token。每產生一個 token，都要讀取大量模型權重，再做一次運算。對大模型來說，很多時間不是花在純計算，而是花在權重從顯存搬到運算核心的路上。
MTP 的核心思路，是在一次權重讀取裡嘗試預測多個後續 token。它不是讓模型魔法般跳過推理，而是把原本每一步都要重複付出的記憶體傳輸成本攤薄。當瓶頸主要在顯存頻寬和權重搬運時，這種方式就能明顯提高吞吐量。
Reddit 原始討論裡也有人問 MTP 是否已加入，Unsloth 相關回覆指出 MTP 已經在裡面，並且有說法提到 MTP tensors 已直接內建到 quants 中。這表示使用者不只是拿到一個 NVFP4 量化權重，而是拿到帶有 MTP 加速路徑的版本。
2.5 倍速度提升要怎麼看
這次最容易被誤讀的是「2.5 倍」。Reddit 討論中有人問這個速度提升是不是相對 Q4，Unsloth 回覆脈絡指出，這個比較是相對 NVIDIA 的 NVFP4 quant，而不是拿所有 Q4 或 INT4 實作一起比較。這一點很重要，因為不同量化格式、不同框架、不同 GPU、不同 batch 和 context 設定，都會影響 token/s。
另外，35B-A3B 達到 17,561 tok/s 的數字是在 B200 這類企業級硬體條件下出現。這可以說明 NVFP4 和 MTP 的上限很高，但不代表一般 RTX 50 系列能直接複製。企業採購或本地部署，最怕把資料中心卡的極限數字誤當成桌機卡的常態表現。
為什麼 RTX 50 可能反而沒有變快
同樣叫 Blackwell，不代表所有 Blackwell 都一樣。B200 屬於資料中心路線，軟體路徑和底層 kernel 通常優先被最佳化。RTX 50 消費級卡雖然也有新架構能力，但 SM120 的軟體支援成熟度可能還沒跟上。
Reddit 討論中有人提到，消費級 Blackwell 的 NVFP4 利用率仍可能不理想，也有人實測 NVIDIA NVFP4 Qwen3.6 27B 對比原本 INT4 時，token 生成速度不但沒有提升，還有下降的案例。這些不是說 NVFP4 沒用，而是說「硬體支援」和「軟體真的最佳化」中間有一段距離。
如果你正在看 RTX 5090、5080 或 5060 Ti 類配置，不要只看 NVFP4 四個字。你要確認推理框架是否真的支援你的 GPU、驅動和 CUDA 是否符合要求、實際模型是否有對應 kernel，還要看你的工作負載是 prompt processing 重，還是 token generation 重。
企業部署最容易踩到的不是模型，而是環境
這類極限加速模型最怕直接上正式環境。逐字稿和社群討論都提到一個共通風險：推理框架和底層格式更新太快，vLLM、CUDA、驅動、模型權重、環境變數任何一層沒對上，都可能變慢甚至崩潰。
我會把部署流程拆成四步。第一步先在單機沙盒測模型能不能正常跑。第二步測固定 prompt、長上下文、工具調用和 agent loop。第三步鎖定版本，關掉正式環境自動更新。第四步再進入內部 PoC。這和我之前整理的 本地大模型推理框架選型 是同一個邏輯，速度只是其中一個指標，穩定性才決定能不能上線。
正式環境不要開自動更新
先鎖定 CUDA、driver、vLLM 或 llama.cpp 版本
不要把 B200 benchmark 直接套到 RTX 50 採購決策
工具調用和 agent 流程要單獨壓測
用 24GB VRAM 跑 27B 可以測，但不代表企業就一定該選最大模型
為什麼 9B 和 GGUF 反而更實用
當大家看到 27B 可塞進 24GB VRAM，甚至 35B-A3B 跑出極限吞吐量，很容易以為模型越大越好。但真正落地時，很多企業只需要工單分類、客服輔助、內部文件查詢、簡單自動化。這些任務未必需要 27B 或 35B。
9B 模型的價值在於部署門檻更低，可以放進 12GB 或 16GB 顯卡，還能保留更多 VRAM 給上下文和工具調用。GGUF 則讓 llama.cpp 這類本地推理路線更容易接上 CPU 或低階硬體。這也是為什麼社群一邊討論 17,561 tok/s，一邊仍然敲碗 9B 和 GGUF 版本。
對中小企業來說，我會優先問三個問題。你的資料是否需要完全本地化，你的任務是否真的需要大模型，你是否有能力維護最新 GPU kernel 和推理框架。如果答案不明確，小模型加穩定部署，通常比追逐極限跑分更務實。
我的判斷
NVFP4 和 MTP 很重要，因為它們代表本地 AI 推理正在處理真正的瓶頸：顯存容量、權重搬運、吞吐量和模型品質之間的平衡。NVFP4 解決的是低 bit 量化下如何保留更多數值動態範圍，MTP 解決的是一次只吐一個 token 帶來的記憶體傳輸浪費。
但我不會把它解讀成「RTX 玩家立刻起飛」。比較健康的看法是：資料中心硬體已經看到 NVFP4 和 MTP 的上限，消費級硬體還在等軟體棧補齊。現在要採購或部署，應該把 PoC、版本鎖定、框架支援和真實任務測試放在跑分前面。
真正值得期待的是，這些技術成熟後，27B 不再只能放在機房裡，9B 和 GGUF 也能讓更小的團隊取得足夠好用的本地 AI。極限跑分很好看，但真正改變企業日常的，通常是穩定、便宜、好維護的那一條路。
延伸資源
FAQ
NVFP4 是什麼？
NVFP4 是 NVIDIA 4 位元浮點量化格式。它和 INT4 一樣節省記憶體，但用浮點方式表達數值，較適合保留神經網路權重中的動態範圍。
NVFP4 和 INT4 最大差異是什麼？
INT4 是固定刻度的整數量化，NVFP4 是 4 位元浮點量化。前者生態成熟，後者更依賴硬體 FP4 支援和軟體 kernel 最佳化。
MTP 是什麼？
MTP 是 Multi-Token Prediction，多 Token 預測。它讓模型在一次權重讀取中嘗試預測多個後續 token，降低記憶體傳輸瓶頸，提高吞吐量。
by Rain Chu 6 月 13, 2026 | Agent , AI , GGUF , Hermes , OpenClaw
原本我在 Nvidia 都搭配 vLLM 啟動，這條路理論上可以發揮 NVFP4 權重的優勢，但在 DGX Spark 的 GB10 平台上，實際遇到 CUDA Kernel 與 Marlin repack 相容性問題。
最後我改採：
Hcompany/Holo-3.1-35B-A3B-GGUF 搭配 llama.cpp CUDA Build，成功啟動模型並提供 API 服務。
這篇文章記錄完整流程，也保留幾個重要的踩坑經驗。
環境
本次環境如下：
硬體：NVIDIA DGX SparkGPU：NVIDIA GB10系統：Ubuntu Linux模型儲存位置：/mnt/ai-models推論框架：llama.cpp模型格式：GGUF量化版本：Q4_K_M DGX Spark 使用統一記憶體架構，因此 CPU、GPU 與系統服務會共用記憶體。這點對 vLLM 與 llama.cpp 都很重要。
為什麼放棄 NVFP4 + vLLM
一開始使用 vLLM 載入：
Hcompany/Holo-3.1-35B-A3B-NVFP4 後，權重其實已經完整載入：
Loading safetensors checkpoint shards: 100% Completed | 3/3Loading weights took 142.78 seconds 但載入完成後，仍然在 Marlin FP4 重新整理階段失敗：
NotImplementedError:Could not run '_C::gptq_marlin_repack'with arguments from the 'CUDA' backend 這代表模型檔案本身沒有問題，真正卡住的是 vLLM 的 CUDA Extension 在 DGX Spark GB10 上沒有完整提供所需的 Marlin CUDA Operator。
如果只是想先把 Holo 3.1 跑起來，不一定要繼續投入時間處理 NVFP4 相容性。改用 GGUF + llama.cpp 是更快、更穩定的選擇。
移除 NVFP4 模型快取
vLLM 下載的 Hugging Face 模型通常會放在：
/mnt/ai-models/huggingface/hub/ 先確認路徑：
find /mnt/ai-models/huggingface \ -maxdepth 3 \ -type d \ -name 'models--Hcompany--Holo-3.1-35B-A3B-NVFP4' \ -print 確認容量：
du -sh \ /mnt/ai-models/huggingface/hub/models--Hcompany--Holo-3.1-35B-A3B-NVFP4 確認無誤後刪除：
rm -rf \ /mnt/ai-models/huggingface/hub/models--Hcompany--Holo-3.1-35B-A3B-NVFP4 1. 安裝編譯工具
sudo apt update
sudo apt install -y \ git \ build-essential \ cmake \ ninja-build \ libcurl4-openssl-dev \ pkg-config 2. 確認 CUDA Toolkit
export CUDA_HOME=/usr/local/cudaexport PATH="${CUDA_HOME}/bin:${PATH}"
export LD_LIBRARY_PATH="${CUDA_HOME}/lib64:${LD_LIBRARY_PATH:-}"
nvcc --versionnvidia-smi nvcc --version 必須能正常回傳 CUDA 版本。
3. Clone llama.cpp
mkdir -p /mnt/ai-models/srccd /mnt/ai-models/srcgit
clone https://github.com/ggml-org/llama.cpp.gitcd
llama.cpp 如果之前已經下載過：
cd /mnt/ai-models/src/llama.cpp
git fetch origingit switch master
git pull --ff-only origin master 4. 編譯 CUDA 版本
cd /mnt/ai-models/src/llama.cpp
rm -rf buildcmake -B build \ -DGGML_CUDA=ON \ -DCMAKE_BUILD_TYPE=Releasecmake --build build \ --config Release \ -j 4 \ --target llama-server llama-cli 確認：
./build/bin/llama-server --version
./build/bin/llama-cli --version 下載 Holo 3.1 GGUF 模型
建立模型目錄：
mkdir -p \ /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF 下載主模型、視覺投影模型與 Chat Template：
hf download \ Hcompany/Holo-3.1-35B-A3B-GGUF \ q4_k_m.gguf \ mmproj.f16.gguf \ chat_template.jinja \ --local-dir \ /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF 確認：
ls -lh \ /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF 應該看到：
q4_k_m.ggufmmproj.f16.ggufchat_template.jinja 單模型模式啟動
先用最簡單的單模型方式確認服務能運作：
cd /mnt/ai-models/src/llama.cpp
./build/bin/llama-server \ -m /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF/q4_k_m.gguf \ --mmproj /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF/mmproj.f16.gguf \ --jinja \ --host 0.0.0.0 \ --port 8080 \ -c 8192 \ -np 1 \ -ngl 999 參數說明：
--mmproj 指定視覺投影模型
--jinja 使用模型附帶的 Chat Template
-c 8192 Context Length
-np 1 同時處理 1 個請求
-ngl 999 儘可能將模型層放到 GPU 官方建議參數
llama-server \
--hf Hcompany/Holo-3.1-35B-A3B-GGUF \
--n-gpu-layers 999 \
--ctx-size 65536 \
--batch-size 16384 \
--ubatch-size 2048 \
--flash-attn 1 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
--image-min-tokens 1024 \
--ctx-checkpoints 8 \
--cache-ram 32768 \
--kv-unified \
--threads 16 測試文字 API
curl -s http://192.168.0.240:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Holo-3.1-35B-A3B-GGUF", "messages": [ { "role": "user", "content": "請使用繁體中文介紹你的 UI 畫面分析能力。" } ], "max_tokens": 256, "temperature": 0.2 }' | python3 -m json.tool 在這台 DGX Spark 上，實測文字生成速度約為：
測試圖片分析 API
curl -s http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "q4_k_m.gguf", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe this image in one concise English sentence." }, { "type": "image_url", "image_url": { "url": "https://cdn.britannica.com/61/93061-050-99147DCE/Statue-of-Liberty-Island-New-York-Bay.jpg" } } ] } ], "thinking_budget_tokens": 64, "max_tokens": 1024, "temperature": 0.1 }' | python3 -m json.tool 已知問題：中文多模態輸出偶爾觸發解析錯誤
圖片推論本身可以成功，但在某些中文輸出中，llama-server 可能回傳：
Failed to parse input at pos ... 例如：
自由女神像、火炬、基座、城市天際線、高樓、水面、島嶼、樹木、旗�、船。 其中 � 是 UTF-8 無效字元替代符號。
實務上的處理方式：
1. 降低 temperature，例如 0.12. 限制輸出為簡短句子3. 提高 max_tokens，避免輸出被截斷4. Client 端遇到 500 時自動 Retry 一次5. 優先更新至最新版 llama.cpp Router Mode：支援多模型切換
確認單模型模式正常後，可以啟用 Router Mode：
cd /mnt/ai-models/src/llama.cpp
./build/bin/llama-server \ --models-dir /mnt/ai-models/llama-models \ --models-max 1 \ --models-autoload \ --jinja \ --host 0.0.0.0 \ --port 8080 \ -c 8192 \ -np 1 \ -ngl 999 啟動後會看到：
Loaded 1 local model presets from /mnt/ai-models/llama-modelsAvailable models (1) Holo-3.1-35B-A3B-GGUFstarting router server, no model will be loaded in this processrouter server is listening on http://0.0.0.0:8080 Router 會在 Client 第一次呼叫時才載入模型。
查看模型清單：
curl -s \ 'http://127.0.0.1:8080/models?reload=1' | \ python3 -m json.tool 指定模型：
curl -s http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Holo-3.1-35B-A3B-GGUF", "messages": [ { "role": "user", "content": "請使用繁體中文簡短介紹你的功能。" } ], "max_tokens": 512, "temperature": 0.2 }' | python3 -m json.tool Router Mode 的記憶體策略
我使用：
意思是：
可以讓 Client 選擇多個模型但同一時間只保留一個模型在記憶體中 這很適合 DGX Spark。因為 Holo 35B、KV Cache、圖片 Token 與系統服務都會共用統一記憶體。
如果要同時提供 Holo 與另一個 Tool Calling 模型，建議：
Holo 35B：Context 8192 或 16384用途：UI 截圖與視覺分析較小的文字 Tool Calling 模型：Context 65536用途：Hermes Agent 預設模型 不同模型需要不同 Context Length 時，可使用 models.ini：
version = 1
[*]
jinja = true
n-gpu-layers = 999
parallel = 1
[Holo-3.1-35B-A3B-GGUF]
model = /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF/q4_k_m.gguf
mmproj = /mnt/ai-models/llama-models/Holo-3.1-35B-A3B-GGUF/mmproj.f16.gguf
ctx-size = 8192
[qwen-coder]
model = /mnt/ai-models/llama-models/qwen-coder-14b-q4_k_m.gguf
ctx-size = 65536 啟動：
./build/bin/llama-server \ --models-preset /mnt/ai-models/llama-models/models.ini \ --models-max 1 \ --models-autoload \ --host 0.0.0.0 \ --port 8080 讓 llama.cpp 開機就執行
一、確認執行檔路徑
先執行：
ls -lh /mnt/ai-models/src/llama.cpp/build/bin/llama-server 再確認模型目錄：
ls -lah /mnt/ai-models/llama-models 測試版本：
/mnt/ai-models/src/llama.cpp/build/bin/llama-server --version 如果這三個指令正常，就可以建立服務。
二、建立 systemd 服務
建立服務檔：
sudo nano /etc/systemd/system/llama-router.service 貼上：
[Unit]
Description=llama.cpp Router Server
Documentation=https://github.com/ggml-org/llama.cpp
After=network-online.target local-fs.target
Wants=network-online.target
RequiresMountsFor=/mnt/ai-models
[Service]
Type=simple
User=gwoyju
Group=gwoyju
WorkingDirectory=/mnt/ai-models/src/llama.cpp
Environment="LD_LIBRARY_PATH=/usr/local/cuda/lib64"
Environment="CUDA_HOME=/usr/local/cuda"
ExecStartPre=/usr/bin/test -x /mnt/ai-models/src/llama.cpp/build/bin/llama-server
ExecStartPre=/usr/bin/test -d /mnt/ai-models/llama-models
ExecStart=/mnt/ai-models/src/llama.cpp/build/bin/llama-server \
--models-dir /mnt/ai-models/llama-models \
--models-max 1 \
--models-autoload \
--jinja \
--host 0.0.0.0 \
--port 8080 \
-c 8192 \
-np 1 \
-ngl 999
Restart=on-failure
RestartSec=10
TimeoutStopSec=30
KillSignal=SIGTERM
LimitNOFILE=65535
[Install]
WantedBy=multi-user.target 儲存後離開：
WantedBy=multi-user.target 讓服務可以隨一般多使用者開機流程啟動；Restart=on-failure 會在程式異常退出時重新啟動服務。
為什麼需要 RequiresMountsFor
你的模型與程式都放在：
如果外接 SSD 尚未掛載完成，直接啟動 llama-server 會失敗。
這一行：
RequiresMountsFor=/mnt/ai-models 會要求 systemd 先準備好該掛載點，再啟動 Router。
三、啟用開機自動執行
重新讀取服務設定：
sudo systemctl daemon-reload 設定開機自動啟動，並立即啟動：
sudo systemctl enable --now llama-router 查看服務狀態：
systemctl status llama-router --no-pager 正常情況應該看到：
以及：
router server is listening on http://0.0.0.0:8080 四、查看即時日誌
查看最近 100 行日誌：
journalctl -u llama-router -n 100 --no-pager 持續追蹤日誌：
journalctl -u llama-router -f 離開即時日誌：
五、測試 Router API
確認 Router 已啟動：
curl -s http://127.0.0.1:8080/health 查看模型清單：
curl -s \ 'http://127.0.0.1:8080/models?reload=1' | \ python3 -m json.tool 測試 Holo 3.1：
curl -s http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Holo-3.1-35B-A3B-GGUF", "messages": [ { "role": "user", "content": "請使用繁體中文簡短介紹你的功能。" } ], "max_tokens": 256, "temperature": 0.2 }' | python3 -m json.tool 第一次呼叫時會需要等待模型載入。後續請求會比較快。
六、常用管理指令
啟動服務
sudo systemctl start llama-router 停止服務
sudo systemctl stop llama-router 重新啟動
sudo systemctl restart llama-router 查看狀態
systemctl status llama-router --no-pager 取消開機自動啟動
sudo systemctl disable --now llama-router 七、確認開機後是否真的自動啟動
重新開機：
重新 SSH 登入後執行：
systemctl status llama-router --no-pager 確認 Port：
測試模型清單：
curl -s http://127.0.0.1:8080/models | \ python3 -m json.tool 八、改用 models.ini
準備讓不同模型有不同 Context Length：
Holo 35B：8192Hermes 預設 Tool Calling 模型：65536 這種情況建議不要在服務中使用：
而是改用：
假設設定檔位於：
/mnt/ai-models/llama-models/models.ini 服務中的 ExecStart 改成：
ExecStart=/mnt/ai-models/src/llama.cpp/build/bin/llama-server \
--models-preset /mnt/ai-models/llama-models/models.ini \
--models-max 1 \
--models-autoload \
--host 0.0.0.0 \
--port 8080 改完後重新載入設定：
sudo systemctl daemon-reload
sudo systemctl restart llama-router 查看日誌：
journalctl -u llama-router -f 九、避免 Ollama 開機後搶占記憶體
你之前遇過記憶體不足。如果目前 DGX Spark 主要改用 llama.cpp，建議停用 Ollama 的開機自動啟動：
sudo systemctl disable --now ollama 確認：
systemctl status ollama --no-pager 未來需要恢復：
sudo systemctl enable --now ollama 十、限制只允許內網連線
目前使用：
代表區域網路內其他裝置可以存取 API。Router Mode 目前仍屬於實驗性功能；llama.cpp 啟動日誌也提醒，不建議直接暴露在不受信任的網路環境。
假設區域網路是：
可以設定 UFW：
sudo ufw allow from 192.168.0.0/24 \ to any port 8080 proto tcp 查看規則：
不要直接把 Port 8080 暴露到公網。
建議你現在直接執行的版本
建立 /etc/systemd/system/llama-router.service 後，執行：
sudo systemctl daemon-reload
sudo systemctl enable --now llama-router
systemctl status llama-router --no-pagerjournalctl -u llama-router -n 50 --no-pager 這樣 DGX Spark 每次重新開機後，llama.cpp Router Server 就會自動啟動，並等待 Hermes Agent 或其他 Client 指定要載入的模型。
參考資料
https://huggingface.co/collections/Hcompany/holo31
https://build.nvidia.com/spark/llama-cpp/instructions
近期留言