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

Wing Wah Law

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×）。

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

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

--attention-backend aiter + EAGLE draft → draft graph capture 撞 aiter_meta arch assert（gfx1100 唔喺 whitelist）→ 加咗 gfx1100 入 whitelist → 真 kernel hipErrorLaunchFailure（aiter_meta PA kernel 唔支援 gfx1100 launch）
強行 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 無人區地圖（畫晒）：

DFlash 喺 ROCm 單卡 = 死症（5 個組合全部 ≈ 無 spec，draft 接受率/verify 開銷抵銷；block 越大越蝕）—— 同 draft model / attention 無關
NGRAM blocked：fork 嘅 ROCm sgl_kernel 缺 reconstruct_indices_from_tree_mask（upstream 未 port 到 ROCm build）
syvai W4A16 DFlash draft（DFlash2DraftModel arch + compressed-tensors）要 marlin repack，ROCm 7.2.4 clang compile fail
️ 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 速度。兩種都係有效數據，但唔可以混埋當同一基準。

十、開放項 / 建議

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

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

Wing Wah Law

Screenshot_20260908_164319_com_android_chrome_ChromeTabbedActivity.jpg

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

terry

相当残暴，如此看来，双卡W7800，挺好玩的。4卡没准也能动动，这可是可以单卡Comfyui的神器，4卡DeepSeek V4 Flash，单卡Qwen3.8 27B，神器。

Wing Wah Law

補充一個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）

git clone --depth 1 --branch rocm-7.2.4 https://github.com/ROCm/ROCr-runtime rocr-src
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; }" 之後）
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
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 搞掂。

Wing Wah Law

@terry 哈，Terry兄我的目標真是Deepseek V4 Flash

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

terry

@Wing-Wah-Law 这玩意如果真能弄起来，它是比两个DGX Spark更有生产力的，毕竟它可以四开ComfyUI，但是成本高，也折腾。总体上不算事特别难，你应该能搞得定。就是有钱有闲。

Wing Wah Law

@terry

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

张光璞

以后的论坛模式变为：
step1:让ai去读论坛内容，按学到的知识配置跑起来后ai发贴
step2:发完贴攒一波评论
step3:让ai读自己贴子评论后逐一测试。选出最终配置后总结发贴
step4：《 ==等抄作业的人学习自己的第二贴

左脚踩右脚螺旋飞升！

抡锤者