抡锤者

MK CHAO

@kos-or 我都是個人使用沒有往這個方向測試耶，而且這個方案會把兩張顯卡的效能完全榨出來，基本沒有什麼餘裕了

MK CHAO

雙 RTX 5070 Ti + WSL2 跑 capy-flash v0.6.0：Qwen3.8-27B NVFP4 開到 256K，解碼 145 t/s

先講結論：在沒有 AVX-512 的 5700X3D 上，capy-flash 的 27B dense 路線完全可行，256K context 開得起來、也用得動，長 context 解碼仍在 145 t/s 上下。以下全部是同機實測，不是引用發佈方數字。

一、測試平台

項目	規格
CPU	AMD Ryzen 7 5700X3D（Zen 3，無 AVX-512）
GPU	2 × RTX 5070 Ti 16GB（無 P2P，PCIe 4.0 x8/x8）
RAM	112GB DDR4-2400（四條混插，JEDEC）
OS	Windows 11 + WSL2 Ubuntu 24.04
驅動	617.14
引擎	capy-flash v0.6.0（release tarball，sm120a）
模型	Qwen3.8-27B QUASAR-QAT NVFP4（16.2 GiB，含 vision + MTP）

之所以特別註明「無 AVX-512」：官方文件寫 Flash-Next NVFP4 需要 AVX-512 做 CPU expert 計算，但 27B 不需要——權重完整放在兩張卡上。這點對老平台很關鍵。

二、256K 可以開，而且真的能用

KV 262,144 tokens, int8 | pages 4096/4096 | runtime 5.03 GiB | 每卡剩 ~172 MiB

深度實測（MTP ×3，thinking off，單請求）：

提示詞 tokens	Prefill	Decode	草稿接受率
197,783	2,422 t/s	146.5 t/s	93.3%
213,772	2,319 t/s	150.8 t/s	93.3%
249,852	2,100 t/s	145.6 t/s	93.3%

短至中等深度：

提示詞 tokens	Decode
772	181.8 t/s
12,044	156.3 t/s
48,109	195.5 t/s
96,198	180.7 t/s
142,784	209.4 t/s
155,704	172.4 t/s

代價：冷的 25 萬 prompt，TTFT 約 2 分鐘；每卡只剩 170MB 餘裕，不能同時跑 ComfyUI / 另一個引擎。

三、MTP vs DFlash2：短輸出會騙人

同一個 40k 提示詞、各生成 500+ tokens（這才是公平樣本）：

後端	Decode	接受率
MTP ×3	151.7 t/s	52.3%
DFlash2 ×7	133.2 t/s	26.2%

但如果你只讓它生成 20 個 token，DFlash2 會出現 314.9 t/s 的數字——那是短輸出的假象，接受率在長生成時會掉到 26%。論斷投機解碼一定要用長輸出。

四、實戰 Agent 負載（DSH，114 筆請求）

項目	結果
結束原因	114/114 全部正常 `stop_token`，零截斷
Decode 中位數	99.7 t/s（52.7–142.4）
提示詞深度	最深 ~129K
Prefix cache	正常命中（單筆 126k tokens 命中）
工具呼叫	正常（單筆最多 8 個 tool call）
Vision	通過（四象限色塊全對，編碼 0.044 秒）

速度隨深度下滑：60–80K 約 120–140 t/s，90–130K 約 75–95 t/s。

五、三個踩過的坑（照順序踩）

1. 內附 libcudart 直接 segfault

用 tarball 內附的 lib/libcudart.so.13 啟動，會在 initializing CUDA 後直接 SIGSEGV，log 沒有其他線索。
解法：改用系統 CUDA 13.0 runtime，排在最前面：

export LD_LIBRARY_PATH=/usr/local/cuda-13.0/targets/x86_64-linux/lib:$FFMPEG_LIB

2. 缺 FFmpeg 8 共享庫

Ubuntu 24.04 只有 FFmpeg 6，但這個 release 連結 libavformat.so.62 / libavcodec.so.62 / libswscale.so.9 / libavutil.so.60。
解法：抓 BtbN 的 ffmpeg-n8.1-latest-linux64-gpl-shared，解到私人目錄後加進 LD_LIBRARY_PATH，不要污染系統套件。

3. 8 GiB host-KV 鎖定被 OOM 殺

--profile 27b 預設會鎖 8 GiB host KV，在 WSL 的 cgroup 裡被 OOM kill（oom_score_adj: 200）。
解法：縮小可選的 host tier：

--host-kv-mib 2048 --host-state-slots 4

六、256K 下的隱形殺手：KV lease 長不下去

這是這次最有價值的發現。設定 50K 輸出上限時，答案常常在 12K–17K 就自己停住，回報 output_limit，看起來像被截斷。

引擎 log 寫得很清楚：

[engine] warning: Device KV lease of lane 0 cannot grow ...
still short 1 main page for its smallest step,
so the answer ends early with output_limit

原因是 256K 的 KV 池先把 VRAM 佔滿，答案變長時要擴 KV 卻擴不出來，只好硬收。
解法：

--kv-lease-window 0

一開始就把整個輸出空間保留好，不必中途擴張。加上之後 114 筆請求、0 次警告、0 次截斷，速度也沒有下降（改前 133–136 t/s、改後中位 99.7 t/s，差異來自深度與內容而非這個參數）。

代價：長提示＋長輸出超過 256K 總量時會直接拒絕（context_capacity），而不是默默截斷。

七、關於思考長度

同一顆模型在一般請求的思考中位數只有 206 tokens，但遇到難題會單筆吃 79,458 tokens 才產出答案。所以：

設「思考上限」會硬切推理，難題正確率有下降風險（此引擎沒有鬼打牆偵測，無法區分這兩者）；
比較安全的做法是輸出上限留 92K 給長推理，撞上限就人工中止重問。

八、幾個誠實的邊界

這不是跟 Strata/Flash-Next 的公平比較。 capy-flash 27B 是 27B dense，Flash-Next 是 125B MoE；引擎、模型、量化全都不同。
測試機沒有 AVX-512、RAM 是 DDR4-2400，所以官方在 DDR5-5600 平台上的 175 t/s 不該直接對照；我們在 40k 提示的長生成是 151.7 t/s。
只有一台機器、單一使用者，--max-concurrency 1，多用戶數字未驗證。
DFlash2 在 27B 這條線沒有想像中強，至少在英文技術內容上是 MTP 較穩。官方也提過 DFlash2 的接受率對內容極敏感（非英文散文可能掉到 20%）。
26B/27B 以上量化選擇未做同題品質 A/B，本文只有速度與穩定性。

九、目前使用的啟動設定

ninfer-serve <27B-quasar-nvfp4.ninfer> \
  --profile 27b --host 0.0.0.0 --port 8080 --model-id capy-27b \
  --max-context 262144 \
  --kv-lease-window 0 \
  --spec mtp --draft-tokens 3 --lm-head-draft \
  --host-kv-mib 2048 --host-state-slots 4

載入約 40 秒，模型 id 需完全一致（capy-27b），送錯名稱會回 404。

十、測試結果

three.js水車小屋測試
Prompt：請用three.js建造一個麥塊風格的水車小屋，要有櫻花樹的場景
每個方塊請要有各自的材質，不要用單色的方塊，方塊內容要細緻，場景也盡可能精雕細琢，要有日出日落的變換
水車小屋，河道，水田，牧場，地形高低起伏，櫻花飄落
請把 three.js 完全內嵌進 HTML，做成html單檔

一次完成，沒有任何破圖，做出來效果還是相當不錯的

MK CHAO

@marsempire Github已經更新到0.4.1，應該你提到的東西都改好囉

MK CHAO

@marsempire gpu_split是因為我是個用兩張不同型號顯卡一起跑的怪咖，我現在是5070TI+3070TI，不用這種參數沒辦法把顯存逼到極限啦....
剩下的問題我晚點再改吧
剛剛更新了效能分析的功能，有點燃燒殆盡了...

MK CHAO

@marsempire Github已更新，再麻煩重新下載安裝看看是不是還有切視窗的問題喔

MK CHAO

@marsempire 我自己的沒有這個問題，想確定一下你的螢幕解析度還有是否有使用桌面放大功能呢？
參數部分都要到all model那邊才會保存，主介面的回存功能我有空會更新

MK CHAO

@Quanta-Magic 我覺得你問錯地方了，這邊都是愛折騰的，你問10個可能9個已經有本地的Qwen3.8了，哈哈哈。

MK CHAO

@csmkaka 相見恨晚阿，我趕快去搞一個

MK CHAO

@terry 有想到什麼需求也可以跟我說一下，我看看有沒有力氣改
這些功能都是我自己想到的

MK CHAO

@royleecn 更新了喔，還新增了不少功能唷

MK CHAO

9/4 更新版本 0.4.1
更新效能圖表工具，適應不同解析度，更多的細節參數設定等等

8/31更新新版本

增加了LOG讀取來做速度分析的功能及設定思考等級的功能喔~

請有需要的各位多多取用

常常下載了新的模型卻不會寫啟動參數嗎?

俺也一樣!

所以就讓AI與我合力做了這款llama-launcher
https://github.com/pttocean-afk/llama-launcher

支援快速設定、高速啟動、即時LOG、遠端啟動等功能
希望能回饋版上的各位

如果有任何想要改善的部分也歡迎跟我說

主畫面.png

遠端啟動介面.png

MK CHAO

@fafafa 不過20系列對有些編碼的支援度不太好喔，看你要不要找30系列的，他們會便宜不是沒道理。

MK CHAO

@fafafa 你可以去看一下我異構卡的那篇，基本上不會掉到2080TI的速度啦...

MK CHAO

顯存不太夠-->換更大顯存-->很像可以跑更好的模型-->顯存不太夠
無~限~循~環~

MK CHAO

@terry 不好意思看了你的影片才來加入論壇找解決方案，沒注意到是AI。

這邊附上圖，這大概是20K上下文左右的速度，約30T/S左右

如果馬上換成Qwen3.6-35B-A3B-UD-IQ4NL的話，約100T/S左右

MK CHAO

@Xiaote 感謝大神回復
如此看來只有升級硬體一途了，當初轉手玩ai手上都是遊戲硬體，看來能做出這樣的結果已經很不錯，有時間會測試-fa參數再來報告。
MTP已經有試過了，上下文會大幅縮小，而且提升非常有限，並不划算。
我的主機板是X570，3070TI跑起來是Pcie4.0x8，目前可能是因為非對稱卡的關係P2P暫且是搞不起來，也許這個也是影響速度的一大因素啦..

MK CHAO

小弟淺見
沒意外會變慢，但是可以跑的解析度跟時間長度會更好，各有優劣。

MK CHAO

最近看到 LCZ 上有雙 RTX 5070 Ti 跑 Qwen3.8-27B 的分享，對方使用 tensor split + MTP，在特定條件下可達 50–75 tok/s。這裡整理自己的非對稱雙卡實測，想請教有經驗的玩家：在 5070 Ti + 3070 Ti 上，是否有更適合的 split mode、CUDA 參數或其他穩定優化方向？

一、硬體與軟體

GPU 0：RTX 5070 Ti 16GB
GPU 1：RTX 3070 Ti 8GB
系統：Windows 原生 llama.cpp
llama.cpp runtime：b10509
GPU split：16,8
split mode：layer
main GPU：GPU 0
--parallel 1
MTP：關閉
Vision/mmproj：本篇主測試關閉
電腦平時仍有 Windows 桌面常駐程式，因此 GPU 0 不會完全零占用；GPU 1盡量保持乾淨

兩張卡不是同型號，VRAM、記憶體頻寬與運算能力都不同，因此沒有照搬雙5070 Ti的tensor-split 1,1。

二、Qwen3.8-27B IQ4_NL：Vulkan 224K Thinking-On 真實Coding Agent

啟動條件

Model: Qwen3.8-27B-IQ4_NL.gguf
Runtime: Windows b10509 Vulkan
Context: 229,376 tokens（224K）
Split: layer / 16,8
KV: IQ4_NL K/V
Thinking: On
Vision: Off
MTP: Off
Parallel slots: 1

這不是固定短prompt benchmark，而是實際 DSH coding-agent 工作流，共117筆已完成樣本，包含工具操作與上下文逐步累積。

Decode 曲線

實際使用Context	樣本數	Decode中位數
0–16K	4	31.53 t/s
16–32K	2	30.41 t/s
32–64K	3	26.27 t/s
64–96K	12	23.23 t/s
96–128K	26	22.30 t/s
128–160K	62	19.72 t/s
160–192K	5	17.74 t/s
192–224K	3	16.87 t/s

穩定性

最高完成Context：210,515 tokens（205.58K）
最低健康Decode：16.71 t/s
Pipeline fallback：0
Vulkan OOM：0
Decode failure：0
llama.cpp truncation：0

DSH在約204.8K壓力門檻先做tool-result pruning，實際曾將server可見Context從210,515降到137,108；壓縮後下一輪Decode從16.87恢復到20.18 t/s。這次長Context工作全程可以正常完成。

三、同一模型改用Windows CUDA

Q4_0 KV結果

Model: Qwen3.8-27B-IQ4_NL.gguf
Runtime: Windows b10509 CUDA
Split: layer / 16,8
KV: Q4_0 K/V
Thinking: Off（速度邊界測試）
MTP: Off

Max Context	啟動／請求	8K附近暖機Decode
128K	正常	37.83 t/s
160K	正常	38.49 t/s
192K	正常，最高確認	38.51 t/s
224K	CUDA1 compute-buffer OOM	—
256K	CUDA1 compute-buffer OOM	—

192K、Q4_0 KV的原始Decode曲線：

1K   38.31 t/s
8K   36.84 t/s
16K  35.14 t/s
32K  32.37 t/s
65K  27.81 t/s
98K  24.32 t/s
131K 21.69 t/s
164K 19.55 t/s

CUDA + IQ4_NL KV

同一模型在CUDA改用IQ4_NL K/V可以載入，但實際進入病態慢速路徑：

8K左右Decode約3.66 t/s
Prompt processing也會隨長度明顯下滑
沒有看到熱降頻，較像CUDA backend/kernel路徑問題

因此目前實用分工是：

Vulkan：IQ4_NL KV
CUDA：Q4_0 KV

四、另一顆Qwen3.6 35B-A3B MoE對照

本機另有：

Qwen3.6-35B-A3B-UD-IQ4_NL

它是MoE，不是Dense，GGUF約16.8 GiB；Qwen3.8-27B IQ4_NL約15.2 GiB。雖然MoE權重檔較大，但它的KV架構較省，且每token只啟用部分expert。

Windows CUDA、Q4 KV、262K設定下，曾做過真實BunnyGO工作流曲線：

使用Context	Decode中位數
0–10K	118.27 t/s
10–30K	111.22 t/s
30–60K	93.85 t/s
60–90K	80.96 t/s
90–120K	70.07 t/s
120–150K	59.11 t/s
150–180K	51.19 t/s
180–200K	48.46 t/s

這顆目前比較適合高速文書、Wiki審查與大量Agent任務；Qwen3.8則保留給coding、複雜推理和重要review。

五、目前採用的方案

Qwen3.8-27B IQ4_NL
→ Coding主力
→ Vulkan / 224K / IQ4_NL KV / Thinking On / layer 16,8

Qwen3.6-35B-A3B UD-IQ4_NL
→ 高速任務主力
→ CUDA / Q4 KV / 可到262K / layer 16,8

六、想請教的問題

在 RTX 5070 Ti 16GB + RTX 3070 Ti 8GB 這種非對稱雙卡上，split-mode tensor是否值得嘗試？還是layer + 16,8通常更適合？
如果改用tensor split，是否有建議的比例？不確定1,1在非對稱卡上會不會讓3070 Ti成為瓶頸。
Qwen3.8-27B IQ4_NL在CUDA上使用IQ4_NL KV會固定進入慢速路徑，是否有人在較新的llama.cpp版本、CUDA版本或特定參數下成功改善？
對長Context coding agent來說，MTP在雙卡非對稱配置下是否真的值得？目前觀察到MTP會增加VRAM與配置複雜度，因此暫時關閉。
有沒有適合這種非對稱雙卡、要求單slot長Context與穩定性的llama.cpp參數建議？

抡锤者

MK CHAO

帖子