<![CDATA[（2026/9/8 更新）SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區]]>SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區（9/8 更新）

(以下全是AI Report，Terry哥一句，夠我折騰一日，生產部署最終定型，我已經很滿意現在的體驗了)
(注：我完全不知道報告中的名詞是什麼意思，我也不知道Deepseek V4 Flash調試了什麼，反正我就不斷追問，要他成功在SGLang部署後加速)

呢篇係我 W7800 報告（lcz.me/topic/1538）嘅 SGLang 部份。
9/5 我試咗 SGLang 官方版本，當時結論係「列咗名但未 ready」（FP8 0.62 t/s、INT4 全失敗）。但 Terry 喺我報告下面提示「你可以嘗試下 SGLang，論壇有帖子，體驗會好很多」，加上論壇 #1252 / #1532 / #1340 / #30599 前人嘅經驗，我決定深入一層：用社區嘅 gfx1100-support fork，做完整嘅三引擎對比 + 投產評估。
以下全部係 2026-09-07 23:35 → 09-08 15:36（HKT，+08:00）實測，數據全部有 log 溯源（私有雲 Share/w7800-abc-sglang-20260908/ 00–05 六份文件）。

先講結論（TL;DR，有興趣再睇下面技術棧）

最終 DSH 實測（production 真實 agent workload，最有用嘅數字）

Segment 時段 gen mean median max
單發（1 stream） 15:34:56–15:36:14 50.9 t/s 53.9 79.5
雙發（2 streams aggregate） 15:31:31–15:34:52 83.4 t/s 84.9 92.5

雙發 per-stream ≈ 41-42 t/s（83.4÷2）→ 單→雙每條跌 ~17%（細 context 並發代價細，scaling ~1.6×）。

全部主要結論（快速了解）

  1. gfx1100 單卡最佳 spec = MTP-3（EAGLE steps=3, topk=1）：+27-39%、16k 深度唔崩，冇嘢贏到佢。
  2. KV dtype 定案：bf16（唯一可行）。fp8 走不通——受控 bench 行到（conc8 132 t/s、KV 減半），但映射 384K CTX pool 嘅 VRAM 分配可能超過 48GB → production 兩次永久 wedge（原因可能 VRAM 唔夠）→ 實證不可行，唔上 production。
  3. DFlash 喺 ROCm/gfx1100 單卡 = 死症（今早無人區測試：5 個組合全部 ≈ 無 spec）—— 同 draft model / attention 無關。
  4. 三引擎 ABC：單流同級（llama.cpp kernel 效率最高）；並發 SGLang 贏（89.7 vs 66.8 vs 42.2 t/s）；深度 SGLang ≈ llama.cpp、vLLM 明顯衰減。
  5. 投產定案：SGLang fork + MTP-3 + bf16 KV + HiCache size 12 + caps(4/6) + cache-report；cache hit 65-77%、decode 中位 57-60 t/s、應付到 11-subagent 並行審計。
  6. 並發守則：≤4 REQ 同時 + 每 turn ≤60-80K tokens + retry 設上限；單卡深 context 並發 = 2 條舒服、4 條極限。
  7. 前人貢獻：fork / model / draft / vLLM wheel 全部前人做好，我哋只實測 + 開 DFlash 無人區 + 投產（詳見 §2）。

一、背景：點解要試 SGLang

9/5 我試咗 SGLang 官方版本（AMD 官方話支援 Radeon），結果：

  • 官方 FP8 量化：server 起得到，但 decode 只有 0.62 t/s（比 llama.cpp 慢 ~100 倍）
  • 三條 INT4 路線：全部失敗
  • 最新 python-native 版本：decode 只有 4.9 t/s
  • 對照組 Qwen3-8B dense：30.2 t/s 完全正常

當時我嘅結論係「SGLang 官方喺 W7800 用唔到，正路係 Instinct」。但 Terry 喺我報告下面話「你可以嘗試下 SGLang，論壇有帖子，體驗會好很多」，我查咗論壇，發現前人已經行過好多路：

  • #1252：vLLM on RDNA3 實測（Triton attention 長 context 慢、vLLM MTP 16k 崩到 13.8 t/s）
  • #1532（flyer666）：SGLang + HiCache 三級架構 + 為 HiCache 加 RAM（32→64GB）
  • #1340：4090 48GB + SGLang DFLASH2，DSH 寫碼均速 110 t/s
  • #30599 系列：vLLM/SGLang 喺 RDNA3 可作 production

呢啲前人嘅經驗俾咗我信心：SGLang 唔係「用唔到」，係「官方版本未 ready，但社區 fork 行到」。所以我決定用 StevenChenSE 嘅 gfx1100-support fork 做完整測試。

二、前人嘅貢獻（我哋依靠佢哋省咗唔少時間）

呢個係我特別想標注嘅部份。我哋成個 SGLang 研究，唔係由零開始，係站喺前人嘅肩膀上面。以下係我哋參考過嘅前人，同佢哋幫我哋避咗咩坑、省咗咩時間：

前人 佢哋俾咗咩 我哋靠佢哋避咗咩坑 / 省咗咩時間
terry（lcz.me） 喺我 W7800 報告下面提示「你可以嘗試下 SGLang，論壇有帖子」 直接觸發咗成個 SGLang 研究。唔係佢提示，我可能仲喺 llama.cpp 度兜圈
lcz.me #1252 vLLM on RDNA3 實測：Triton attention 長 context 慢、vLLM MTP 16k 崩到 13.8 t/s 我哋唔使自己再花幾日去驗證「vLLM 係咪答案」。直接知道 vLLM 長 context 唔掂，將精力集中喺 SGLang fork
lcz.me #1532（flyer666） SGLang + HiCache 三級架構 + 為 HiCache 加 RAM（32→64GB） 我哋 HiCache size 12 天花板嘅結論同佢一致（30Gi RAM 唔夠 full-L2）。唔使自己再撞牆，直接知道要加 RAM 先做到 full-L2
lcz.me #1340 4090 48GB + SGLang DFLASH2，DSH 寫碼均速 110 t/s 俾咗我哋 DFlash 嘅開法同信心去試。正正因為有呢個「110 t/s」嘅參考，我哋先會去開 DFlash 無人區（雖然我哋單卡 W7800 上 DFlash 無加速，但開路本身就有價值）
lcz.me #30599 系列 建議 vLLM/SGLang 喺 RDNA3 可作 production 俾咗「SGLang 可以投產」嘅方向性信心，唔使自己盲猜
StevenChenSE（SGLang gfx1100-support fork） 成個 fork：wave32 對齊 decode graph、rdna_unified_verify、SSM state buffer、triton attention 呢個係我哋嘅地基。冇呢個 fork，SGLang 喺 gfx1100 根本行唔到。MTP-3 深度唔崩都係靠佢嘅 unified verify + SSM buffer
Vishva007 Qwen3.8-27B-W4A16-AutoRound-GPTQ model（13.5GB） 俾咗一個 48GB 放得落、SGLang 行到嘅量化版本。我哋只需 patch MTP config 就 load 到，唔使自己量化
z-lab Qwen3.8-27B-DFlash2 draft model（3.8GB，public） 俾咗 DFlash 無人區測試嘅 draft。唔使自己訓練 draft model
incoai / syvai 其他 DFlash draft 變體 俾咗我哋做「換 draft 有冇用」嘅對照組。結論：無用，DFlash 死症同 draft 無關
vLLM 官方 官方 ROCm wheel（wheels.vllm.ai/rocm）+ #41394 原生 RDNA3 kernel 俾咗 B leg 嘅對照組。W4A16 行原生 RDNA3 kernel，唔使自己編

一句講晒：我哋成個研究，最貴嘅嘢（fork、model、draft、vLLM wheel）全部係前人做好嘅。我哋只做咗「喺自己部機上面實測 + 開 DFlash 無人區 + 投產」呢幾步。呢個就係開源社區嘅力量。

⚠️ 一個重要提醒：fork README 嘅數據係雙卡 ROCm 7.14 環境、且論壇帖註明「以下數據為 LLM 生成」——單卡唔好直接套用。我哋全部數據係單卡 W7800 + ROCm 7.2.4 實測。

三、三引擎 ABC 對比（llama.cpp vs vLLM vs SGLang）

三 engine 同一張卡、同一個 Qwen3.8-27B base，全部 text-only chat（thinking off）、temp 0、相同 prompts（p0=204 tok、p2=1364 tok、deep=16,300 tok）：

leg engine 版本 量化/model
A llama.cpp（production config） master 8b4b355（2026-09-04） Q6_K GGUF（~21GB）+ MTP n=2
B vLLM（官方 ROCm wheel） vllm 0.28.0+rocm723 + torch 2.12.0 W4A16 GPTQ（~13.5GB）
C SGLang（community gfx1100 fork） StevenChenSE/sglang @1442c18 + sgl_kernel AOT 自編 同上 W4A16 model

1) 單流 decode（wall-rate，含 prefill）

場景 A llama.cpp (Q6_K+MTP) B vLLM (W4A16) C SGLang (W4A16)
p0 204tok gen256 31.0 t/s 36.0 t/s 33.5 t/s
p2 1364tok gen256 34.4 t/s 29.8 t/s 32.7 t/s

（decode-only 估算：A ~33 / B ~37 / C ~35 t/s —— 三 engine 單流同級，B 喺短 prompt 微贏、A 喺長 prompt 反超。考慮 A 每步要讀 21GB、B/C 只讀 13.5GB：llama.cpp kernel 效率最高、vLLM/SGLang 喺 ROCm 有 overhead。）

2) 並發（12 reqs，conc=4）

指標 A llama.cpp (2 slots) B vLLM C SGLang
aggregate gen 42.2 t/s 66.8 t/s 89.7 t/s
per-req median wall 23.4s 15.3s 10.0s

→ C（Radix 前綴樹 + continuous batching）並發最好；B 次之（prefix caching）；A 受 production -parallel 2 限制，並發係 llama.cpp 最弱項。

3) 深度行為（16.3k context）

指標 A B C
cold prefill 16k 494 t/s 424 t/s 659 t/s
decode @16k（cache warm, gen128） 30.9 t/s 20.8 t/s 29.5 t/s
短→16k decode 留存率 ~90% ~57% ~85%

→ B（vLLM）長 context decode 衰減明顯（Triton attention 喺 ROCm 深度慢，同 lcz #1252 觀察一致）；A（llama.cpp MTP）同 C（SGLang）深度表現接近、都遠好過 B。

4) Prefill（mtok=1）

A B C
p0 204tok 359 685 603
p2 1364tok 534 846 796
deep 16k 494 424 659

ABC 一句講晒：單流三 engine 同級（llama.cpp kernel 效率最高）；並發 SGLang 贏（89.7 vs 66.8 vs 42.2）；深度 SGLang 同 llama.cpp 接近、vLLM 明顯衰減。SGLang 嘅優勢喺並發 + 深度，正正係 agent workload 最需要嘅。

四、MTP-3 加速奧義（gfx1100 單卡最強 spec）

SGLang fork 支援 EAGLE spec decode。我哋用同一個 model 做 draft（MTP 模式，唔使另外 draft model），實測：

場景 無 spec MTP-3（EAGLE steps=3, topk=1） 提升
p0 204tok gen256 33.5 t/s 42.7 t/s +27%
p2 1364tok gen256 32.7 t/s 45.6 t/s +39%
conc4 agg 89.7 t/s 100.1 t/s +12%
16k deep decode 29.5 t/s 40.9 t/s +39%

MTP-3 係 gfx1100 單卡最強 spec：+27-39%、16k 深度唔崩（vLLM MTP 喺 16k 會崩到 13.8 t/s，SGLang fork 嘅 unified verify + SSM buffer 解決咗呢個問題）。

點解 steps=3 最優（我哋窮舉咗 steps=4）：

實驗 Config 結果 判定
MTP steps=3 EAGLE steps=3 42.7 / 100.1 ✅ 最優
MTP steps=4 EAGLE steps=4 29.4 / 66.8 ❌ 更差（draft 接受率/verify 開銷抵銷）

五、DFlash 無人區測試（今早 07:05–09:00，幫其他人免去無謂想像）

呢個係我特別想寫嘅部份。DFlash 喺 ROCm/gfx1100 係無人區——冇人寫過、冇人實測過。我哋今早花咗兩個鐘，把成個無人區開路、畫晒地圖，希望其他人唔使再無謂想像「DFlash 喺 AMD 上面會唔會快」。

5.1 DFlash2 leg：3 個 blocker，全部開路

參考 lcz.me #1340（4090 48GB + SGLang DFLASH2，DSH 寫碼均速 110 t/s）。Draft 用 z-lab/Qwen3.8-27B-DFlash2（3.8GB，public）。Config：--speculative-algorithm DFLASH --speculative-draft-model-path <draft> --speculative-dflash-block-size 8 --speculative-draft-model-quantization unquant。

行到嘅過程，3 個 blocker 全部實測開路：

# Blocker 症狀 解法
1 冇 aiter draft RMSNorm 6-arg 同 4-arg fallback 撞 裝 amd-aiter + SGLANG_USE_AITER=1 ✅
2 fork 嘅 layernorm.py forward_aiter record 順序 bug UnboundLocalError 本地 patch（reorder）✅
3 真兇：aiter 嘅 tuned_gemm.py skinny_gemm solidx==2 → wv_splitk_small_fp16_bf16 喺 gfx1100 M=1（decode）crash incompatible args 本地 patch：soliidx==2 改用 torch.matmul ✅

第 3 個 patch 係真突破：tuned_gemm.py solidx==2 → torch.matmul，解鎖咗 gfx1100 上面所有用 aiter tuned-gemm 嘅 decode 路徑（唔止 DFlash）。呢個 + layernorm.py reorder fix 都係值得 upstream 嘅。

5.2 DFlash 行到，但無加速

場景 無 spec DFlash2 MTP-3
p0 204tok gen256 33.5 33.3 42.7
p2 1364tok gen256 32.7 34.2 45.6
conc4 agg 89.7 69.1 100.1
16k decode 29.5 30.2 40.9

結論：DFlash 喺 ROCm（無 flashinfer、aiter 要 patch）—— draft 接受率/verify 開銷抵銷，≈ 無 spec；MTP-3 先係 gfx1100 嘅 spec decode 之王（+27-39%、深度唔崩）。

5.3 flashinfer / aiter attention 探索（兩層都撞牆，全部有記錄）

我哋試過用 aiter 做 attention backend（代替 triton）：

  1. --attention-backend aiter + EAGLE draft → draft graph capture 撞 aiter_meta arch assert（gfx1100 唔喺 whitelist）→ 加咗 gfx1100 入 whitelist → 真 kernel hipErrorLaunchFailure（aiter_meta PA kernel 唔支援 gfx1100 launch）
  2. 強行 draft attention 用 triton → 主 model prefill 用 aiter 嘅 mha_batch_prefill_bf16 → JIT build 失敗（aiter batch-prefill FA 唔支援 gfx1100）

結論：aiter 嘅 attention kernel 係 Instinct-first（gfx942/950/1151），gfx1100 兩層都唔行。fork 揀 triton attention（wave-aware split-K）做 RDNA3 主線係正確決定。aiter 喺 gfx1100 可用範圍 = 我哋已經 patch 咗嘅 tuned_gemm（soliidx==2→torch）+ norm kernel；attention 層唔值得再深入。

5.4 創意 sweep：DFlash/attention 全部組合窮舉（08:05–08:35）

目標：搵到 spec decode 加速（組合 grid × 轉換 grid）。全部 quick protocol（warmup + p0×3 + p2×3 + c4）：

實驗 Config p0 (204) p2 (1364) conc4 agg 判定
baseline 無 spec triton attn 33.5 32.7 89.7 —
MTP-3（贏） EAGLE+同 model 42.7 45.6 100.1 ✅ 贏
C1 DFlash(z-lab) blk8 + triton draft 33.2 33.2 69.2 ❌ 無增益
C4 DFlash blk12 20.5 20.5 — ❌ 更差
C2a DFlash(incoai draft) 31.4 31.4 67.9 ❌ 無增益
C2b DFlash(syvai W4A16 draft) — — — 🔒 marlin repack ROCm compile fail
T2 DFlash + aiter wvSpltK (torch fallback) 32.6 32.0 68.1 ❌ 無增益
T1 NGRAM spec — — — 🔒 缺 sgl_kernel op
T3 MTP-3 + fp8_e4m3 KV 41.0 40.3 103.4 ⚠️ 受控 bench 行到（production 384K CTX 映射 VRAM 唔夠 → wedge）

DFlash 無人區地圖（畫晒）：

  1. DFlash 喺 ROCm 單卡 = 死症（5 個組合全部 ≈ 無 spec，draft 接受率/verify 開銷抵銷；block 越大越蝕）—— 同 draft model / attention 無關
  2. NGRAM blocked：fork 嘅 ROCm sgl_kernel 缺 reconstruct_indices_from_tree_mask（upstream 未 port 到 ROCm build）
  3. syvai W4A16 DFlash draft（DFlash2DraftModel arch + compressed-tensors）要 marlin repack，ROCm 7.2.4 clang compile fail
  4. ⚠️ fp8_e4m3 KV：受控 bench 行到但 production 走不通—— MTP-3+fp8 受控 bench：p0 41.0 / p2 40.3 / conc4 103.4 ≈ bf16 同速、KV 慳一半；但映射 384K CTX pool 嘅 VRAM 分配可能超過 48GB → production 兩次永久 wedge（有/無 HiCache 都死）→ fp8 走不通，唔上 production

5.5 今早最後一擊：spec 參數 / 量化窮舉（08:43–09:00）

實驗 Config 結果 判定
A EAGLE3 spec（tree verify） 起機即死 🔒 draft 缺 set_embed（fork 未實現 EAGLE3）
B MTP steps=4 29.4 / 66.8 ❌ 差過 steps=3（42.7/100.1）→ steps=3 最優
C AWQ target（fp16，MTP-3） 10.6 / 11.6 / 43.3 ❌ AWQ kernel 喺 gfx1100 冇優化，慢一大截
D fp8 KV + MTP-3：conc8 / deep / prefill 132.0 / 29.3 / ~290 ❌ 384K CTX 映射 VRAM 唔夠 → production 兩次 wedge，走不通

fp8 KV 完整畫像（對比 bf16 KV + MTP-3）：

指標 bf16 KV fp8 KV
單流 p0/p2 42.7 / 45.6 41.0 / 40.3
conc4 100.1 103.4
conc8 —（未測，KV 爆） 132.0
16k deep decode 40.9 29.3
16k prefill 659 ~290

→ fp8 KV 走不通：受控 bench 行到（conc8 132、KV 減半），但映射 384K CTX pool 嘅 VRAM 分配可能超過 48GB → production 兩次永久 wedge（有/無 HiCache 都死）→ 唔上 production。bf16 KV 係唯一可行選項（deep 40.9 t/s）；要並發多都只能用 bf16（受 187K pool 限制）。

DFlash 無人區一句講晒：我哋今早把 DFlash 喺 ROCm/gfx1100 嘅成個無人區開路——3 個 blocker 全部開路（包括一個值得 upstream 嘅 aiter patch）、5 個 DFlash 組合全部實測（全部無增益）、NGRAM/EAGLE3 確認 blocked、aiter attention 兩層撞牆。結論：DFlash 喺 gfx1100 單卡 = 死症，MTP-3 先係正路。 希望呢份地圖幫其他人免去無謂想像，唔使再花兩個鐘去撞同一批牆。

六、投產（llama.cpp → SGLang fork，9 次 config 演變全部有記錄）

6.1 Config 演變

時間 Config Pool tokens 結果
09:06 bf16 KV + MTP-3 + triton 187K 穩定（baseline）
09:2x + parsers（qwen3 / qwen3_coder）+ thinking off 187K 必修（唔加 = thinking 混 content + tool call 變文字）
10:53 + caps（running 4 / queued 6） 187K 300s timeout 死症 → fast-fail 503
11:32 + HiCache size 12 187K cache hit 65→77%；size 16 失敗（30Gi RAM 唔夠）
12:16 + cache-report 187K DSH 命中顯示由 0 → 真數字（config flag，唔使改 code）
12:5x fp8 KV 版試 375K（≈384K CTX） 兩次 wedge（有/無 HiCache 都死；384K CTX 映射 VRAM 可能唔夠）→ 走不通，唔上 production
13:5x bf16 + chunked 16384 187K 巨 prefill drain 快但 VRAM 峰值高（46.9GB）
14:1x bf16 + chunked 8192 + ctx 131072 187K 定型 ✅
— DSH contextWindow 定案 80000→100000 100K 做 threshold compression（context 到 100K 就壓縮；hot-reload，唔使重啟）

6.2 最終定案 config（現役 ~/start-server.sh）

export SGL_DTYPE=bfloat16 SGL_PHASE_TIMING=0
export SGL_RDNA_CUSTOM_AR=1 SGL_RDNA_NO_FUSED=1 SGL_RDNA_GEMMA_TRITON=1 SGL_RDNA_VLLM_VERIFY=1
export TVM_FFI_DISABLE_TORCH_C_DLPACK=1
python -m sglang.launch_server \
  --model-path .../Qwen3.8-27B-W4A16-AutoRound-GPTQ \
  --host 0.0.0.0 --port 8080 --served-model-name qwen3.8-27b \
  --tp-size 1 --quantization gptq --dtype bfloat16 --mamba-ssm-dtype bfloat16 \
  --kv-cache-dtype bf16 --attention-backend triton \
  --chunked-prefill-size 8192 \
  --context-length 131072 --mem-fraction-static 0.88 \
  --speculative-algorithm EAGLE \
  --speculative-draft-model-path <同一 model> \
  --speculative-num-steps 3 --speculative-eagle-topk 1 \
  --reasoning-parser qwen3 --tool-call-parser qwen3_coder \
  --default-chat-template-kwargs '{"enable_thinking": false}' \
  --max-running-requests 4 --max-queued-requests 6 \
  --enable-hierarchical-cache --hicache-ratio 1.0 --hicache-size 12 \
  --hicache-write-policy write_through --hicache-io-backend kernel --hicache-mem-layout page_first \
  --enable-cache-report

每個 flag 點解要（實測教訓）：

Flag 原因
--reasoning-parser qwen3 --tool-call-parser qwen3_coder 唔加 = thinking 混入 content + tool call 變純文字（DSH 唔 parse 到）。呢兩個 parser 係 production 必備
--default-chat-template-kwargs {"enable_thinking": false} llama 時期 --reasoning off 嘅對應；唔加 default thinking ON → 思考文字混答案
--max-running-requests 4 --max-queued-requests 6 硬 cap：超過 6 條排隊即刻 reject（fast fail），防止 prefill flood 餓死 decode（今日 300s timeout 事故）
--kv-cache-dtype bf16 深度 decode 快（40 t/s vs fp8 29）；fp8 走不通（384K CTX 映射 VRAM 唔夠 → 兩次 wedge）→ 並發多都只能用 bf16
MTP-3 (EAGLE steps3) 單卡實測最強 spec（+27-39%，16k 深度唔崩）
--enable-hierarchical-cache --hicache-size 12 HiCache 三級架構，cache hit 65→77%；size 12 = 30Gi RAM 天花板
--enable-cache-report 純文字 request 回 cached_tokens（DSH 命中顯示由 0 → 真數字）

6.3 全日實戰數據（09:40–15:30 監察）

指標 數值
Decode gen tps mean ~53 / median ~58（單 session 50-61）
MTP accept rate / len ~0.74 / ~3.2（最後 config accept 0.65-0.9）
Cache hit（Radix+HiCache） 全日 65%，HiCache 後 77%
Pool bf16 187K tokens（fp8 可 375K 但 wedge）
最深 KV 176K tokens
並發 1-8 reqs 目擊；2 條深 stream 60-70 t/s，4 條深跌個位數
Prefill 全日 new 3.4M + cached 6.4M tokens
溫度/功耗 junction 41-101°C，max 280W
health 飽和期 45% polls 餓死（/v1/models 全程即答）
503 fast-fail 16 次（caps 生效證據）

DSH 量（production 實測，真實 agent workload）—— 完整數據見上面「先講結論」，呢度補返 context：

Segment 時段 batches gen mean median max KV 範圍
單發（1 stream） 15:34:56–15:36:14 22 50.9 t/s 53.9 79.5 11-21K
雙發（2 streams aggregate） 15:31:31–15:34:52 66 83.4 t/s 84.9 92.5 15-32K
  • 雙發 per-stream ≈ 41-42 t/s（83.4÷2）→ 單→雙每條跌 ~17%，細 context 並發代價細（scaling ~1.6×）

6.4 並發容量實測 + 安全指引（今日最寶貴數據）

測試：DSH 7-agent bug audit × 7 HTML（+ 主 session = 8 條 stream，全部深 context）

並行 heavy agent 結果
2–4 條 舒服（decode 60-70 t/s）
4 條深 stream（149K KV） 跌到個位數（6 t/s）—— 唔建議
8+ 條 / 巨 turn（100K+/turn） prefill queue 爆 → 300s timeout（舊）／503 fast-fail（caps 後）

操作守則（定案）：

  • 同時 ≤4 REQ（例：每個 agent ≤2 REQ × ≤2 對話）—— decode aggregate ~40 t/s OK
  • 每 REQ 每 turn ≤ ~60-80K tokens（大過就 prefill >300s 必死）—— agent 每 turn 唔好重讀大 file / 歷史要 summarise
  • DSH idle timeout 300s 係硬 wall；turn 大就要諗（timeout 提高或 turn 縮細）
  • DSH 端 context 管理定案：contextWindow = 100K，到 100K 就做 threshold compression（hot-reload，唔使重啟）—— 呢個係 DSH 自己嘅 context 壓縮閘口，同 sglang server 嘅 --context-length 131072 係兩層（DSH 100K 先壓縮、sglang 131K 係硬上限）

七、最終定論（成個研究閉環）

  • gfx1100 單卡最佳 spec = MTP-3（EAGLE, steps 3, topk 1），冇嘢贏到佢
  • KV dtype 定案：bf16（唯一可行）；fp8 走不通（384K CTX 映射 VRAM 唔夠 → 兩次永久 wedge）
  • DFlash / NGRAM / EAGLE3 / AWQ / aiter attention 全部實測排除（死症/未支援）
  • 兩個 upstream patch（aiter solidx==2 + layernorm reorder）+ fp8 KV 實證（受控 bench 行到但 384K CTX 映射 VRAM 唔夠 → 走不通）—— 發帖價值最高嘅三個貢獻
  • 由 llama.cpp 2-slot 轉 SGLang fork + MTP-3 + HiCache 後：cache hit 65-77%、decode 中位 57-60 t/s、應付到 11-subagent 並行審計；最大教訓係「單卡深 context 並發係 2 條舒服、4 條極限」，同埋 parser/cache-report 呢啲 config flag 唔開就係啞功能。

八、坑位總表（全部實測，按撞到順序）

# 坑 / 經驗 教訓
1 uv venv 入面冇 pip 全部用 uv pip install --python <venv>/bin/python
2 torchcodec 係 CUDA-only，裝咗會死（libnvrtc.so.13 缺失） pip uninstall -y torchcodec + pip install decord2（自動 fallback）
3 moe_q_gemm_rdna3 喺 ROCm 7.2.4 clang 下 compile 唔過（最大坑） 用同簽名 link stub 頂（dense model 唔會 call；MoE+GPTQ 喺呢個 build 唔可用）
4 import sglang 缺 modules import 循環法：報邊個裝邊個（orjson psutil pybase64 requests starlette tqdm IPython pydantic aiohttp gguf soundfile decord2）
5 多 engine VRAM 爭用 測邊個先殺晒其他 engine（注意 pkill/pgrep -f self-match 坑）
6 fork README 話「唔支援 fp8 KV」 受控 bench 行到但 384K CTX 映射 VRAM 唔夠 → production 兩次 wedge → 走不通（README 喺 production 層面講得啱）
7 llama-bench 唔適合 SGLang 用 OpenAI /v1/chat/completions 協議量
8 DFlash：aiter 必需、layernorm bug、tuned_gemm solidx==2 crash 3 個 blocker 全部 patch（見 §5.1）
9 aiter attention 喺 gfx1100 兩層撞牆 aiter 係 Instinct-first，gfx1100 唔行；triton attention 先係正路
10 thinking 混入 content、tool call 變文字 --reasoning-parser qwen3 --tool-call-parser qwen3_coder 必須顯式 set（auto 只 log 唔 parse）
11 純文字 request prompt_tokens_details=None → DSH 命中顯示 0 開 --enable-cache-report（內置 flag，唔使改 code）
12 prefill flood 餓死 decode（8 stream 事故：300s idle timeout） 單 request 100K+ turn 純 prefill >300s 必死；並發 caps + retry 上限先有得救
13 retry 死循環 DSH retry 會將成段 context 掟返 queue → queue 永遠清唔完；retry 要設上限（DSH=5）
14 cache hit「0」誤解 純睇 #cached-token: 0 行 = 嗰啲係新內容 chunk；整體 hit 65-77%
15 HiCache size 16 失敗 30Gi RAM 機 Not enough host memory；size 12 = 天花板
16 monitor JS escape Python triple-quote embed JS：\n 要寫 \\n，否則成頁 SyntaxError 冇 status
17 health 飽和期 0 sglang /health 要過 scheduler；飽和時餓死但 /v1/models 即答 —— monitor/alerter 用 /v1/models 先準
18 queue full = caps 生效 running 實際係跟 KV admission（深 context 下 ~2 條），queue 6 滿即 503 fast-fail（比 timeout 好）
19 fp8 KV + MTP-3 喺 gfx1100 兩次永久 wedge detokenizer 心跳停，無 HiCache 都中；384K CTX 映射 VRAM 可能唔夠；bf16 只會短暫餓死並自癒 → fp8 走不通，唔上 production
20 gpu_watchdog 喺 sglang 下盲（llama /slots 冇咗） power-based busy 偵測 + sglang-compatible temp probe

九、數據來源標注（好重要，發帖時跟）

來源 定義 例子
DSH 量（production 實測） DSH client 喺真實 agent workload 中量度（wall + usage tokens，含真實 prompt/生成），係「有實際生產效力」嘅數字 —— 論壇上最有用嗰種 2-stream 細 context aggregate mean 83.4 / max 92.5 t/s（2026-09-08 15:31-15:34）；單 session 50-61 t/s
sglang log 量（server tick） server 每個 Decode batch 嘅 instant gen throughput 全日 mean 50 / median 52；單 req max 70.5；多 req max 124.1
Synthetic bench（AB 測試） 固定 prompt/generation 嘅受控測試 ABC report 入面 p0/p2 wall-rate 42.7/45.6；llama-bench 對照

⚠️ 發帖時要寫明數字係邊種來源 —— DSH 量嘅數字含真實 workload 噪聲（tool call、prefill、thinking off 等），synthetic 先係純 engine 速度。兩種都係有效數據，但唔可以混埋當同一基準。

十、開放項 / 建議

  1. fp8 已確認走不通（384K CTX 映射 VRAM 唔夠 → 兩次 wedge）；如要再試要加 VRAM（同 HiCache full-L2 一樣，要加 RAM/VRAM）
  2. HiCache full-L2（≥187K）要加 RAM（同 flyer666 32→64GB 結論一致）
  3. 上游貢獻材料（未發）：aiter solidx==2 patch、layernorm reorder fix、MTP-3 開法（作者未寫低）、fp8 KV 實證（受控 bench 行到但 384K CTX 映射 VRAM 唔夠 → 走不通）、DFlash/NGRAM/ROCm blockers
  4. ~/.dsh/AGENTS.md 基建段未更新（llama→sglang production）—— 用戶確認後更新

呢篇 SGLang 部份由 DSH（DeepSeek Harness）根據 9/7-9/8 嘅完整調試日誌整理而成。所有數據皆實測，可溯源。

]]>https://lcz.me/topic/1559RSS for NodeWed, 09 Sep 2026 21:49:40 GMTTue, 08 Sep 2026 08:40:05 GMT60<![CDATA[Reply to （2026/9/8 更新）SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區 on Wed, 09 Sep 2026 03:46:50 GMT]]>以后的论坛模式变为：
step1:让ai去读论坛内容，按学到的知识配置跑起来后ai发贴
step2:发完贴攒一波评论
step3:让ai读自己贴子评论后逐一测试。选出最终配置后总结发贴
step4： 《 ==等抄作业的人学习自己的第二贴

左脚踩右脚螺旋飞升！

]]>https://lcz.me/post/16828https://lcz.me/post/16828Wed, 09 Sep 2026 03:46:50 GMT<![CDATA[Reply to （2026/9/8 更新）SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區 on Wed, 09 Sep 2026 01:56:56 GMT]]>@terry
238533.jpg

4卡能跑DEEPSEEK V4 FLASH真的不錯🤖🤖🤖🤖不過家裡空間有限😅如果QWEN 3.8 27B都不能滿足我的需求，我再考慮呢4卡或其他方案😃謝謝你的意見！

]]>https://lcz.me/post/16812https://lcz.me/post/16812Wed, 09 Sep 2026 01:56:56 GMT<![CDATA[Reply to （2026/9/8 更新）SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區 on Tue, 08 Sep 2026 18:08:34 GMT]]>@Wing-Wah-Law 这玩意如果真能弄起来，它是比两个DGX Spark更有生产力的，毕竟它可以四开ComfyUI，但是成本高，也折腾。总体上不算事特别难，你应该能搞得定。就是有钱有闲。

]]>https://lcz.me/post/16768https://lcz.me/post/16768Tue, 08 Sep 2026 18:08:34 GMT<![CDATA[Reply to （2026/9/8 更新）SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區 on Tue, 08 Sep 2026 14:01:28 GMT]]>@terry 哈，Terry兄☝🏻我的目標真是Deepseek V4 Flash🐣🐥

對我個人而言，多買三張就不是投資，是墜入顯卡KK園詐騙陷阱了🪤

]]>https://lcz.me/post/16695https://lcz.me/post/16695Tue, 08 Sep 2026 14:01:28 GMT<![CDATA[Reply to （2026/9/8 更新）SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區 on Tue, 08 Sep 2026 13:57:37 GMT]]>補充一個Rocm燒CPU的小修復，我回家才發現的：

【分享】ROCm 7.2.4 + SGLang：idle 冇 request 燒 ~3 core CPU / 83°C → self-build libhsa + 1ms throttle 修好（3→1 core、83→64°C）

環境：AMD Radeon PRO W7800（gfx1100）· ROCm 7.2.4 · Ubuntu 24.04 · SGLang（Qwen3.5/3.8 hybrid 27B GPTQ W4A16）

症狀

  • idle（GPU 0%、冇 request）長期燒 ~2.9 core / CPU 83°C / 風扇全速
  • --sleep-on-idle 已開（官方 PR #6026）→ python 主 loop 已 park，照燒

斷症

  • perf：燒喺 libhsa-runtime64.so（ROCm rocr runtime）
  • rocr 源碼：Runtime::Load() 起兩個 AsyncEventsInfo thread 行 AsyncEventsLoop，
    signals 嗰個 hardcode 唔用 interrupt wait → 純 CPU-poll = ROCm runtime 層面問題
  • 關聯：#1730（python 側，--sleep-on-idle 已修）、ROCm PR #7952（throttle，7.2.4 未有）、#5534

修法（self-build rocr，唔使升 ROCm）

  1. git clone --depth 1 --branch rocm-7.2.4 https://github.com/ROCm/ROCr-runtime rocr-src
  2. Patch runtime/hsa-runtime/core/runtime/runtime.cpp 嘅 AsyncEventsLoop：
    純 CPU-poll 分支掃完一輪冇嘢處理又冇 interrupt wait → 瞓 1ms：
    if (!interrupt_wait && !finish) { os::Sleep(1); }
    （插喺 "if (interrupt_wait) { WaitForInterrupt(); init_age = false; }" 之後）
  3. Build 陷阱（最嘥時間位）：
    a. trap_handler 要 clang：apt clang-18 讀唔到 ROCm LLVM22 bitcode + 冇 ld.lld
    b. 正解 = ROCm bundled AMD clang 22（/opt/rocm/llvm/bin/clang，version 啱 bitcode）
    c. ROCm 個 llvm 冇 ClangConfig/LLVMConfig cmake → 自製 shim：
    ClangConfig.cmake:
    add_executable(clang IMPORTED)
    set_target_properties(clang PROPERTIES IMPORTED_LOCATION "/opt/rocm/llvm/bin/clang")
    add_executable(Clang::clang ALIAS clang)
    LLVMConfig.cmake:
    add_executable(llvm-objcopy IMPORTED)
    set_target_properties(llvm-objcopy PROPERTIES IMPORTED_LOCATION "/opt/rocm/llvm/bin/llvm-objcopy")
    add_executable(LLVM::llvm-objcopy ALIAS llvm-objcopy)
    d. export PATH=/opt/rocm/llvm/bin:$PATH
    cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/opt/rocm
    -DClang_DIR=<shim>/clang -DLLVM_DIR=<shim>/llvm .
    cmake --build build -j8 → build/rocr/lib/libhsa-runtime64.so.1.18.0
  4. Swap + rollback：
    sudo cp /opt/rocm/lib/libhsa-runtime64.so.1.18.70204 ~/libhsa.orig
    sudo cp build/rocr/lib/libhsa-runtime64.so.1.18.0 /opt/rocm/lib/libhsa-runtime64.so.1.18.70204
    sudo systemctl restart <engine service>
    Rollback：
    sudo cp ~/libhsa.orig /opt/rocm/lib/libhsa-runtime64.so.1.18.70204 && sudo systemctl restart <service>

結果

  • idle CPU：~3 core → ~1 core（scheduler 1002→502 ticks/5s；main 500→~0）
  • CPU temp：83°C → 64°C
  • decode 冇影響：512 token @39.9 t/s、short 0.2s、health 200

剩餘觀察

  • 最後 ~1 core = rocr::core::InterruptSignal::WaitRelaxed（engine 側主動 ACTIVE busy-wait，
    perf caller 喺 /dev/dri/renderD128 mmap；disable-overlap/HiCache/poller 無關）→ 似 engine/HIP 主動等，未解
  • 另外加咗 idle 15 分鐘自動停 engine 做保險；冇佢都已經好咗 66%

有同樣症狀（ROCm + SGLang/vLLM idle 燒 CPU）可試；唔得 rollback 一條 cp 搞掂。

]]>https://lcz.me/post/16693https://lcz.me/post/16693Tue, 08 Sep 2026 13:57:37 GMT<![CDATA[Reply to （2026/9/8 更新）SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區 on Tue, 08 Sep 2026 12:52:31 GMT]]>相当残暴，如此看来，双卡W7800，挺好玩的。4卡没准也能动动，这可是可以单卡Comfyui的神器，4卡DeepSeek V4 Flash，单卡Qwen3.8 27B，神器。

]]>https://lcz.me/post/16679https://lcz.me/post/16679Tue, 08 Sep 2026 12:52:31 GMT<![CDATA[Reply to （2026/9/8 更新）SGLang 投產實測：W7800 48GB 上嘅 gfx1100 fork + MTP-3 + DFlash 無人區 on Tue, 08 Sep 2026 08:47:00 GMT]]>Screenshot_20260908_164319_com_android_chrome_ChromeTabbedActivity.jpg

一杯奶茶就換來巨大生產力🤖祝各位壇友事事順利✨Terry兄財源滾滾✌️

]]>https://lcz.me/post/16630https://lcz.me/post/16630Tue, 08 Sep 2026 08:47:00 GMT