@YDM 是沒錯，但是阿貓阿狗就不會知道你是誰，光這樣就排除99.9%的麻煩了

@Geekyang 哈....我之前有個NCCL 但沒 MTP的版本.....PP 大概 2500-3000 TG大概60-70
這次是MTP但沒NCCL....
目前正在嘗試 MTP+NCCL 一起啟動看看會怎樣(還在編譯中, 成功失敗未知....畢竟沒nvlink 相容性沒nvlink好)

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

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

---

1. 目前設備

項目	規格
CPU	AMD Ryzen 9 9950X3D（16C/32T，最高 5.76 GHz）
RAM	60 GB DDR5
GPU	2 × NVIDIA GeForce RTX 5090 32GB
OS	Ubuntu 24.04.4 LTS (Noble Numbat)
Kernel	7.0.0-31-generic
NVIDIA Driver	595.84

兩張卡沒有 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 版，不是自己編。

模型

	檔案	大小	說明
Target	Qwen3.8-Flash-Next-UD-IQ3_XXS（3 分片）	77 GB（10.9 MB + 49.6 GB + 32.4 GB）	主模型
MTP draft head	mtp-Qwen3.8-Flash-Next-shared-Q8_0.gguf	2.6 GB	投機解碼 head

模型架構 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）

	GPU 0	GPU 1
已用	29,035 MiB	29,581 MiB
總量	32,607 MiB	32,607 MiB
剩餘	3,572 MiB	3,026 MiB
溫度	52 °C	44 °C
功耗	213.8 W	226.7 W
利用率	59 %	49 %

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

RAM

進程 RSS	8.6 GB
系統已用	11 GB / 60 GB
系統可用	49 GB

注意：模型檔 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

關鍵參數說明：

參數	作用
--split-mode tensor + --tensor-split 1,1	雙卡等量切分，77GB 模型對半分
-ot per_layer_token_embd.weight=CPU	embedding 丟 CPU，省 VRAM
--cache-type-k/v q4_0 + --kv-unified	KV cache 量化到 4bit，69K context 才塞得下
--ctx-size 69632	約 68K context
--spec-type draft-mtp	啟用 MTP 投機解碼
--spec-draft-n-max 2	每輪最多猜 2 個 token
--n-gpu-layers-draft 99	draft head 全數 offload 到 GPU
-np 1	只跑單併發，多併發 VRAM 撐不住且 MTP 會反虧

️ 第二個坑：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 速度

項目	實測
平均	75.4 t/s
範圍	67.7 ~ 82.2 t/s
每 token 延遲	12.2 ~ 14.8 ms
全部樣本平均	75.0 t/s

MTP 投機解碼成效

項目	實測
draft 接受率平均	69.4%
接受率範圍	55.8% ~ 82.9%
平均草稿長度	2.39（猜 2 個，平均中 2.39 個含 draft）

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

Prompt Processing

項目	實測
平均	848 t/s
範圍	202 ~ 1,476 t/s
最大單次	25,663 tokens，21.09 秒（1,216.83 t/s）

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

對照：換腦前後

引擎	decode
原 NVFP4 引擎	~10 t/s
llama.cpp b10715 + MTP	75.4 t/s

約 7 倍。

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

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

情境	MTP 表現
併發 1	1.3 ~ 1.7× 勝出
併發 8	~0.81×，反虧

而且 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 不對。

@kos-or 最近數學界對AI的數學難題突破，也提出質疑，因為有些解法被高度懷疑是從數學家還未發表的論文致敬出來的，事實上被懷疑的模型公司不置可否....機密資料上傳雲端本來就是很蠢的事哪怕DID做的完備也一樣

UPS不要省，買不起線上式的，買互動式的也可以

這不是常識嗎？不僅不要上雲，上雲的我連GOOGLE帳號跟FB....從十幾年前創建那兩個帳號就是假資料，雖然沒法100%防護，至少不會被莫名其妙的人這麼容易掌握資訊

妳都有雙DGX....建議妳裝上後，叫他自己跑分看看
AI自己跑，很快的

最長的島叫長島，最小的島叫小島.....那最痛的島叫做什麼? 我問過所有AI都沒人答對

@johnnybegood 可以分享你的啟動參數嗎？我想自己借你的啟動參數，用自己的設備實做一次...謝謝

從chatgpt release以來
AI智商x模型縮小倍數 == 大約每年是10
以這速度來看
未來人類就只剩下『職場政治』『出事背黑鍋』是 AI無法取代的
只是我們不用怕...美國那些成本高到不合理的碼農會先死
那些人就是礦場裡面的金絲雀
他們沒死之前都不用怕
看看美國碼農年初大裁員，年中大招聘就知道，暫時還死不了

所以low是甜蜜點啊....low -> non 可以節省多少時間?

剛剛快樂更新完，成功運行中，可惜這架構沒法兩張 5090做TP跑FB16全尺寸....不然會爽到不行

抄作業中....白嫖就是硬道理 感謝～ ^_^

不知道有沒人分享

每次系統再跑時最討厭的兩件事

①compacting

②self improvement

都會花很多時間

其中②

background_review.enabled 系統初始值是 true（開啟）。

來源：agent/background_review.py

這可以ai關掉，如果不想失去這功能，可以改成夜深人靜跑一次

這種30t/s光compacting的時間就整死你了，沒到100t/s真的會玩到一肚子氣，目前也無法啟動tensor parallelism ....llamacpp好像在嘗試....我丟任務給我家ai每天去追任務

lcz.me 貼文排版規則：為什麼有些貼文漂亮、有些糊成一團

背景

目標： 搞清 lcz.me（NodeBB 論壇，https://lcz.me）的貼文渲染規則，讓技術文檔貼上去排版漂亮。
起因： 大人把 qwen38-5090x2 經驗文（含 5 欄 pipe table）貼上 lcz 預覽，整篇難看，尤其是表格。
日期： 2026-08-27

---

研究方法（可複現）

lcz 是 NodeBB（不是 Discourse），匿名可用的存取方式：

# 分類主題列表（注意：page 參數無效，用 nextStart/after 游標分頁）
curl -s "https://lcz.me/api/v3/categories/7/topics?pageSize=25" -H "User-Agent: Mozilla/5.0"

# 單篇貼文 raw 內容
curl -s "https://lcz.me/api/v3/posts/{pid}" -H "User-Agent: Mozilla/5.0"

# SSR 渲染 HTML（抓渲染後長相，不用開瀏覽器）
curl -s "https://lcz.me/t/{tid}" -H "User-Agent: Mozilla/5.0"

• 分類 7 = LLM 討論區
• 對照組：tid=1345（88 行 pipe table 的 R9700 實測）、tid=1349（高讚口語流貼文）、tid=917（漂亮且有表格）、8/26 後 23 篇新貼文
• 判定渲染結果：直接比對 SSR HTML 裡 <table> / <pre> 的數量與 class

---

核心結論

1. lcz 完整支援 pipe table 與 code fence

tid=1345 的 SSR 渲染出 20 個 <table class="table table-bordered table-striped"> + 50 個 <pre>，
右對齊（style="text-align:right"）、加粗（<strong>）都正常。不是「lcz 不會畫表格」。

2. 難看的原因：表格太寬，不是語法錯

lcz 帖子正文寬度約 850px。5 欄 pipe table 加中文表頭 → 每格擠成 3~4 字一行、
整張表撐出橫向捲軸，看起來糊成一團。1~2 欄 key-value 表（硬體/配置）則正常。

3. 版上「漂亮貼文」的排版慣例（實測對照組歸納）

慣例	說明	反例（難看）
pipe table 只用 2~3 欄	2 欄最常見：項目/配置、場景/實測	5 欄以上 pipe table（無一篇這樣做）
寬數據表放 code block	用 ``` 等寬文字手動對齊（如 1345 逐 task 數據）	把逐 task 大表寫成 pipe table
章節號用阿拉伯數字	## 1. 硬體、## 2. 數據	## 一、硬體
code fence 標語言	bash / text	裸 ```
短段落 + 口語 + 重點加粗	高讚貼文特徵（1349 零表格零 code fence）	大段不分行文字

4. 重寫對照（本次案例）

原稿	重寫後
5 欄逐 task 抽樣 pipe table（9 筆）	code block 等寬對齊，9 筆數據整齊不擠
## 一、硬體	## 1. 硬體與軟體
裸 ```	bash / text
硬體 1 欄 key-value 表	保留（2 欄化，本來就對）

重寫版：how_to/qwen38-5090x2-experience-lcz-20260827.md（大人實測：格式正確，已貼上 lcz）。

---

️ 教訓

1. 先查渲染規則再排版：貼文難看 ≠ 平台不支援。用 SSR HTML 抓一篇「漂亮對照組」看實際渲染，比猜快。
2. 寬表一律進 code block：lcz 上 >3 欄的數據表，用等寬文字對齊是版上通行做法。
3. pipe table 的寬度上限 ≈ 3 欄：中文表頭會更吃寬度，2 欄最安全。
4. 匿名 API 可用端點：/api/v3/categories/{cid}/topics（after 游標分頁）、/api/v3/posts/{pid}（raw）、SSR 主題頁。/search.json 匿名被擋。
5. NodeBB page 參數無效：分頁用回應裡的 nextStart / after 游標（與 lcz-forum-backup-lessons.md 血淚教訓 #1 一致）。

---

專案狀態：2026-08-27 完成研究並實測驗證（大人貼上 lcz 確認格式正確）。本檔為快照，lcz 若改版渲染規則需重新驗證。

我建議各位在發文前，發個範例文章給AI分析，請她照格式轉成md，妳再複製張貼，這樣就很快了，我都是用這懶人法發文的

漫畫重要的是創意，舉個例子，一拳超人原著板，那鬼畫符能看嗎？但是就是爆款....這跟AI不AI沒關....

如果是聊天的話，我推薦gemma4 31B 真好聊，但做事會被她氣死