（15／9第二次更新）為 gfx1100 用戶追回軟件算力：GIGABYTE W7800 48G 單卡跑通 AMD 原版 Quark INT4，DSH 真實負載七日 +22%（50.9 → 62.11 t/s）
-
測試平台：GIGABYTE Radeon
PRO W7800 AI TOP 48G（單卡）
gfx1100 / RDNA3 ｜ 70 CU ｜ ROCm 7.2.4 ｜ Ubuntu 24.04 ｜ Ryzen 5 7500F ｜ 30 GB RAM
2026-09-15
〇、實測成績：DSH 真實 agent 路徑
本節所有數字均直接抽取自引擎日誌，並非實驗室短提示評測。
真實 agent 工作負載（DSH，上下文約 20K）
指標 值 decode 吞吐 62.11 t/s 樣本數 11（59.55 / 62.11 / 63.94 / 59.49 / 52.37 / 59.95 / 67.80 / 78.91 / 71.91 / 76.56，另有 1 個 9.35 離群值） accept length 2.87 – 3.70 同一台機器、短提示單流 85.05 t/s ⇒ 兩者唯一的變數是上下文深度（full token 20,004 – 20,944）。這就是 agent 場景的真實成本。
複驗（2026-09-15，HiCache 8 ＋ chunk 8192）
指標 值 decode 吞吐 61.5 t/s（n=23，full token 中位數 24,299） p90 80.4 t/s accept length 中位數 3.40 ⇒ 與 09-14 的 62.11 t/s 一致，並無退步。（用戶主觀感受的 74 t/s 屬較短上下文。）
與我們上一份帖文的對比（同一張卡、同一工作負載）
我們 2026-09-08 的上一份帖文（lcz.me/topic/1559）在同一張 W7800 上報告：DSH 真實 agent 工作負載單發 50.9 t/s（gen mean；median 53.9、max 79.5；KV 範圍 11–21K）。
2026-09-08（topic 1559） 2026-09-15（本文） 變化 DSH agent 路徑 decode（單發） 50.9 t/s 62.11 t/s +22.0% 上下文範圍 11–21K 20,004–20,944 同級 ⇒ 七日之內 +22%。而這不是單一變因的功勞 —— 期間換了模型配方（W4A16-AutoRound-GPTQ → INT4-GPTQ-v3）、加了自己寫的 INT4 lm_head shim（+19.7%）、改了兩處 kernel（合計再 +6.5%），並把整套配置重搭回同一條線上（見第二節）。
⇒ 更重要的是：前面仍有大把路未走。 上游 vLLM 已改用我們尚未採用的兩條新路線、確定性開關從未打開、kernel 內部那道 498-cycle 的串行鏈尚未拆解。詳見第六節。
生產環境實績
項 值 decode 中位數（投產時） 57–60 t/s KV cache 命中率 65 – 77% 曾經承擔 11 個 subagent 並行審計 split-K 512 與 1024 之 A/B 70 對 61 t/s 這些數字在任何 gfx1100 單卡用戶的環境中皆可復現。
一、我們是誰、在什麼卡上做
我們只有一張 GIGABYTE Radeon
PRO W7800 AI TOP 48G（gfx1100、70 CU）。單卡這一事實至關重要，因為它決定了我們所有結論的邊界：
我們 論壇其他前輩 卡 W7800 48G ×1（70 CU） 7900 XTX ×2（各 96 CU）／4090 48G 改裝版 ×1／4080S ×2 總 VRAM 48 GB 48 GB（雙 7900XTX 24+24）／48 GB TP 1 2（雙卡） 卡片架構 RDNA3 gfx1100 7900XTX 同為 gfx1100 但 96 CU；4090 為 NVIDIA ⇒ 本文出現的任何數字，其前提皆為「單卡、70 CU、gfx1100」。
W7900（96 CU）、7900 XTX（96 CU）與 W7800（70 CU）雖然同屬 gfx1100，但 CU 數不同，吞吐量不可直接套用。 我們先前見到有材料把 CU 數寫成 96 —— 那是 W7900 的數字，我們這張是 70（amd-smi 實測）。
我們的目標很簡單：把 gfx1100 用戶所能運用的軟件算力，逐分逐毫地榨取出來，而且每一步都可復現。
二、主軸線：這條路的形成過程
起點：一句提示把我們推了進來
2026-09-05 我們試用 SGLang 官方版，結論為「已列名，但尚未就緒」（FP8 只有 0.62 t/s）。正想放棄的時候，Terry 在我們的報告下面留下一句：
「你可以嘗試下 SGLang，論壇有帖子，體驗會好很多」
一句提示，我們投入了十天。沿著他指出的方向，我們找到論壇前人已經鋪好的路（見文末致謝），最後以社群的 gfx1100-support fork 完成三引擎完整對比，才定下生產配置。
⇒ 這是本文最想說明的一件事：這條路是社群鋪出來的，我們只是接續前行。
中段：找到真正的病灶
我們做過許多無效的優化，代價最高的一課是：有一整輪優化耗在一個穩態佔比 0% 的 kernel 上 —— 那個檔案佔 46% 的代碼量，卻只佔 4.59% 的 GPU 時間；真正的熱核佔 61.14%。
質量集中處 ≠ 能量集中處。
這句話後來成為我們所有優化的第一道關卡：動手之前先量能量分佈。
轉折：接入 AMD 原版模型
AMD 在 HuggingFace 放出
amd/Qwen3.8-27B-Quark-AWQ-INT4-W4A16，但它在 RDNA3 上無法運行 —— SGLang 的 Quark 模組只實作了三種 scheme，純 W4A16 沒有；quark/weights.py甚至直接註明「Scheme didn't allocate the parameter (e.g. W4A16)」。我們撰寫了轉換器把它接入。這是我們第一件原創作品（詳見第三節）。
關鍵一段：INT4 之後，速度是怎樣追回來的
接通 AMD 原版模型之後，我們面對第二個問題：模型能跑，但速度不夠。
我們寫了一個 Python shim（
rdna_shim/rdna_lmhead_int8.py），經PYTHONPATH注入，在 vendored 樹只加三行攔截_compute_lm_head。它不改 kernel，而是換路線：lm_head 是 248320×5120 的 bf16 矩陣（2.543 GB），每步被讀四次（verify 一次 M=4、draft 三次 M=1），合共約 13.9 ms/步、佔步時約 20%；M=1 時完全是記憶體綁死，位元寬直接決定成本。改用 INT4 之後每次只讀 0.661 GB。階段 引擎吞吐（5K 上下文、temp 0） 相對基準 bf16 lm_head（原狀） 57.12 t/s — int8 lm_head（中間步驟） 60.43 t/s +5.8% int4 lm_head（最終） 68.38 t/s +19.7% 輸出 MD5 三者完全相同，accept length 4.0 不變，U+FFFD 為 0。 兩次獨立量測得 68.41 / 68.38。
在此之上，我們又改了 kernel 本體兩處：WMMA 門檻由 M≥16 下移至 M≥9 && N≥2048（M=9 GEMM 246.7 → 185.9 µs，−24.6%），以及 B2 編譯期模板化（M=4 −9.3%、M=5 −8.7%、M=8 −14.2%）。端到端 68.38 → 72.84 t/s，累計對 bf16 基準 +27.5%，輸出與基準逐字節相同。
速度追回來之後，我們再把底盤逐件接回： MTP-3 投機解碼（09-11 由 DFLASH 折返後重新接上）、CUDA graph、HiCache（命中率 65% → 77%，09-14 重新上線），最後是 09-14 傍晚的 DFLASH8 ＋ HiCache8（單流 92.57 t/s）。
⇒ 這一段的代價，同樣如實記錄：
時間 失敗與代價 09-11 13:20 投機門檻下移 M≥2 雖然修復了確定性，代價是吞吐 −15.2%（88.9 t/s）。交易為負，已放棄並還原。 09-11 13:20 draft 量化 v3：體積由 3.85 GB 降到 1.743 GB，但 accept rate 掉到 0.00、吞吐 15.7 t/s（−85%） 09-11 14:14 事故：INT4 一度被洗成 W4A16 —— exp_config.py的 REF 寫死了 W4A16 配方，13:31 起所有受控測試全部跑錯模型09-11 22:36 差一點誤報成功：見到 HYBRID 啟動與 84.9 t/s，真相是 HYBRID 失敗後系統 fallback 到 DFLASH；靠 /proc/<pid>/cmdline硬驗證才攔截下來09-11 22:36 字串拼接改配置令反斜線續行斷裂，生產停擺 3.5 分鐘 09-13 P29–P52 工藝戰役：18 個假說全部否證（全部落在 ±0~2%），隨後證明整場戰役打在那個只佔 4.59% GPU 時間的 kernel 上 ⇒ 這就是「質量集中處 ≠ 能量集中處」的代價，也是我們把它列為第一道關卡的原因。
現在：把差距交代清楚
接入之後，我們量到自身的服務品質低於 AMD 公布的數字（PPL 高一成、GSM8K 低七分）。我們排除了六個嫌疑，但機制仍未定位 —— 此點我們在第四節誠實交代。
三、我們原創的三項成果
3.1 Quark W4A16 → SGLang GPTQ 轉換器（已開源）
原意：讓 gfx1100 用戶不必等待 SGLang 補上 W4A16 scheme，當日即可運行 AMD 原版模型。
實質作用：把 Quark 的 N-packed
[K, N/8]佈局重新打包成 GPTQ 的 K-packed[K/8, N]，權重未改動任何一個位元。技術核心（亦是我們耗時最久之處）：Quark 在
pack_method="reorder"之下，每個 int32 內的 8 個 4-bit 值並非順序排列，而是按order_map = [0,2,4,6,1,3,5,7]重排。忽略這一步，整個模型將輸出亂碼。我們當初正是遺漏了這一步，以數值掃描猜測數小時之久；最終閱讀官方
quark/torch/utils/pack.py之後即得解。⇒ 教訓：凡涉及外部格式，先讀官方實作，不可依靠試探。此後成為我們的鐵律。
無損驗證（三條獨立證據）：
檢驗 結果 逐元素反量化比對（5 層，含 N=48 的極瘦層） max 絕對差 = 0.000000e+00 全層覆蓋 496 個量化層 ＋ 703 個普通層 對 BF16 原模型的忠實度（96 個 in_proj）cos 最小 0.9871、中位數 0.9905 3.2 N-aware K-split（小 M 專用，−7.9%）
Commit：
0d2e013 perf(rdna3-wmma): opt-in N-aware k_split for small-M; -7.9% on M=16 verify GEMM across all 6 production shapes, fp64-identical accuracy; default path unchanged原意：上游的
compute_wmma_k_split()只看 K、不看 N，因此在 K ∈ {5120, 6144, 17408} 時一律返回 4。但在我們的生產形狀中，N=5120 佔權重的 23.6%，在 k=4 之下嚴重佔用不足。實質作用：改為 N-aware 規則 —— 選取「令 block 數達到約 5120 的最小 k」。在我們六個生產形狀上逐一掃描後：
六個生產形狀的逐 k 掃描（單位 ms，粗體為實測最優）
- 5120 × 17408：k=4 0.22503 ｜ k=8 0.22087 ｜ k=16 0.22612 ｜ k=32 0.25149 ⇒ k=8
- 17408 × 5120：k=4 0.26621 ｜ k=8 0.26696 ｜ k=16 0.22434 ｜ k=32 0.22263 ⇒ k=32
- 5120 × 10240：k=4 0.16138 ｜ k=8 0.13935 ｜ k=16 0.14128 ｜ k=32 0.15573 ⇒ k=8
- 6144 × 5120：k=4 0.10095 ｜ k=8 0.10367 ｜ k=16 0.09191 ｜ k=32 0.09835 ⇒ k=16
- 5120 × 6144：k=4 0.09661 ｜ k=8 0.09436 ｜ k=16 0.09122 ｜ k=32 0.09996 ⇒ k=16
- 5120 × 12288：k=4 0.17250 ｜ k=8 0.16021 ｜ k=16 0.16392 ｜ k=32 0.18090 ⇒ k=8
規則在 6 個形狀中有 5 個命中實測最優；唯一例外為 17408×5120，差 0.77%（按真實層混合加權後更小）。
最重要的一點：準確度在 fp64 之下逐位元相同，且預設路徑完全不變（須開啟
SGL_WMMA_KSPLIT_AUTO=1方生效）。我們其後實測關閉它：PPL 9.7296 對開啟時 9.7297，差 −0.00% ⇒ 這個效能補丁在數值上是忠實的。3.3 其他原創改動（逐項交代原意與作用）
Commit 原意 實質作用 c2d509e小 M WMMA 門檻下移至 M>=9 覆蓋 decode verify step（生產實測 80% 為 M=4，其餘為 M=8） 9af1d8dGPTQ kernel 編譯期模板化 Σa 預算與 z 修正改為每 group 一次，減少重複計算 b10a8ab正確性修正 把不規則（NGRAM）樹排除於 mask-less unified verify kernel 之外 01d62d6生產樹入版控 GPTQ M_COUNT 5/6/7、lm_head 低位寬 1f1ba80WMMA M=16 瓶頸研究 env-gated 量測變體，預設路徑不變 23dd307建置整潔 把量測變體排除於生產 build 之外 6c5409c建置整潔 停止追蹤 21 個由 hipify 產生的 .hip 檔 005ad71修錯 CU 數 96 → 70（96 為 W7900；本卡為 70） f736a74首次入版控 2026-09-08/09 的 gfx1100 生產補丁 另外兩項不在 git 之內、但同樣屬於我們原創的：
prod/rdna_shim/rdna_lmhead_int8.py—— INT4 LM head，只在小 batch 觸發- 我們整套量測方法論（見第五節）
四、陷阱：六個已排除的嫌疑，與一個仍未解開的差距
4.1 差距本身
指標 我們（單卡 W7800） AMD 官方卡 差 Wikitext word_perplexity 9.7297 8.8250 +10.25% GSM8K flexible（兩次全量平均） 83.70% 91.51% −7.81 pt GSM8K strict（同上） 84.12% 90.37% −6.25 pt 4.2 我們排除的（附方法）
# 嫌疑 排除方法 1 權重量化 逐元素反量化比對 max 絕對差 = 0（5 層）＋ 全層 496/496 ＋ 對 BF16 源 cos≥0.9871 2 LM head PPL 以 echo 取 prefill logprobs，而 INT4 LM head 只在 M ≤ 8 觸發（日誌： i4=1418 / miss=182）；換 BF16 後 9.7297 → 9.7297 完全不變3 量測儀器 echo 路徑與原生 /generate對同 6 篇文件得位元相同（差 0.000%）；token-PPL 5.52 × 1.32 = word-PPL 9.46 三數自洽4 資料集 wiki-2 與 wiki-103 的 test split sha 相同（62/62） 5 prompt 截斷 超長僅 0.61%、缺答案格式僅 0.30% 6 我們自己的 K-split 優化 關掉 → 9.7296（−0.00%） ⇒ 差距真實存在，機制我們尚未定位。我們不作猜測。
4.3 更重要的發現：我們自身的 greedy 解碼並不確定
上表兩次全量評測皆用 greedy（
do_sample=False），理應完全一致，實際卻相差 0.76 個百分點。於是我們在同一部伺服器、同一配置之下，同樣 150 題連續執行兩次：
指標 結果 輸出完全相同 107 / 150（71.3%） 對錯翻轉 3 題 兩次分數 85.33% 對 84.67% ⇒ 在我們的技術棧上，greedy 解碼是非確定的。
⇒ 因此我們不報告單一數字，而報告兩次全量評測的平均值，並標明自身噪音約 ±1 pt。
這也是本文的一項關鍵提醒：任何「更動一個參數即可令分數上升 0.5 pt」的結論，在此噪音水平之下皆不可信。
我們懷疑來源是 split-K 的 CAS 原子累加（加法次序不固定），或 LM head 低位寬路徑的 M ≤ 8 閘（精度隨 batch 大小跳變）。兩者皆未驗證。
4.4 幾項實用陷阱（可為他人節省時間）
① lm-eval 的 max_length 陷阱。 API 後端有
max_context_len = max_length − max_gen_toks。用預設max_length=2048配 AMD 的max_gen_toks=8192⇒ −6144 ⇒ prompt 截成空 ⇒ HTTP 400（我們觸發了 2645 次）。AMD 官方指令寫明max_length=16384。② LM head 的 M 閘。
M ≤ 8走 INT4、M > 8走 BF16 ⇒ 同一 prompt 的 logits 會因並發批次的組成而異，屬可重現性風險。③ page-size 與 hybrid mamba。 論壇實測：
page-size 64配 hybrid mamba 加 HiCache 本身即會段錯誤，必須page-size 1（我們恰好為 1）。④
--gpureset不可使用。 對 gfx1100 會鎖住 PCIe root port，須冷開機（社群警告）。
五、經驗：我們學到的若干原則
① 先對證，後落手。 凡涉及外部格式、協議、第三方語義，第一步必須尋求對證 —— 而且優先閱讀官方源碼，不讀文檔描述。
② 驗證方法本身要先驗證。 必須證明它能夠識別已知的壞輸入，而非僅止於「能夠運行」。（我們的一個精度閘門曾經對 NaN、全零、非有限輸出三個通道全部靜默判 PASS。）
③ 對證對象要驗身分。 凡對證，必印被對證對象的 sha256。修改時間、路徑、檔名，一概不可信。
④ 硬件規格只准實測。 同一張卡在四份材料中出現過 96 / 70 / 40 / 35 四個 CU 數，僅實測的 70 正確。
⑤ 質量集中處 ≠ 能量集中處。 動手之前先量能量分佈。
⑥ 配件無辜，組合有罪。 我們曾經把 HiCache 當作段錯誤主因；後來發現只有 DFLASH 與 HiCache 的組合才會出事，HiCache 本身無辜。
⑦ 一個中心為忠，兩個中心為患。 量度之前先釐清有幾個中心；並行量測會互相污染，任何時候只准一個。
六、將來目標
① 量測上游 vLLM 的新路線。 上游已改為 M≤5 使用專用 INT4 skinny GEMM（
wvSplitK_int4_g，wave 層分工 ＋ DPP 歸約、無原子競爭）、M>5 使用 Triton。我們的 decode 有 80% 屬 M=4，恰好落在第一段。A/B 工具已編譯完成，僅待執行。② 檢驗非確定性的機制。 同一個 A/B 實驗同時可驗：CAS 原子 對 DPP 歸約。
③ 開啟
--enable-deterministic-inference。 我們生產環境中此開關一直為 0。其說明為「batch invariant ops」，恰對應我們「精度隨 batch 跳變」的假設。④ 將 kernel 層開源 ——
已於 2026-09-15 完成。 以 patch series 形態發佈 19 個 patch（43 檔、+4,097 / −14,870 行），基底 StevenChenSE/sglang之gfx1100-support@1442c18。由 GitHub 下載後套用到乾淨檢出，可逐位元重現我們的生產樹。 https://github.com/lawsirlawsir-png/rdna3-quark-w4a16⑤ 繼續追查那個 +10.25% / −7.81 pt 的差距。 六個嫌疑已排除，機制尚未定位。
七、致謝 —— 我們的技術層有 99% 來自他人
我們所做的那 1% 之所以能夠成立，是因為前面已經有人把路鋪好。逐項歸位如下：
引我們走上這條路的人
- Terry（lcz.me）—— 「你可以嘗試下 SGLang，論壇有帖子，體驗會好很多」。一句提示，令我們投入了十天。
我們的基礎：開源項目
- @StevenChenSE ——
StevenChenSE/sglang的gfx1100-support分支。我們整條生產線建在這上面。 - @vllm-project —— RDNA3 的 WMMA GPTQ kernel（我們拆解的那份
q_gemm_rdna3_wmma.cu，檔案頭即為Copyright contributors to the vLLM project） - @amd —— AMD Quark 量化工具鏈與
pack.py的打包語義（沒有它，我們的轉換器無從對證） - @ExLlama 社群 —— GPTQ kernel 的血統
論壇前人（我們沿其路線前行）
- @flyer666 —— lcz.me #1532：SGLang ＋ HiCache 三級架構、為 HiCache 增加 RAM；#1640：gfx1100 單卡分析
- @抡锤者 / franklee006 —— lcz.me #1340（4090 48G ＋ DFlash2，DSH 寫碼均速 110 t/s）、#18288（雙 7900XTX 完整實戰）、#1329（HiCache 實測）、#1587（雙 4080S HiCache）
- @_折騰_ —— lcz.me #1500 / #1340：HiCache 多會話實戰、DFlash2 與 DSpark 的第一手主觀比較
- @Michael Zhou —— 4090D 48G 參數（經 #1329 轉錄）：
--mamba-full-memory-ratio 1.0、--mamba-scheduler-strategy extra_buffer、--mamba-track-interval 2048、page-size 1 - @清风明月 —— RTX PRO 4500 32G NVFP4 ＋ HiCache 參數（TID:1341）
- @Neo（lcz.me）—— HiCache L2/L3 原始帖
- @xiaote 老特 —— 參數調校與三方對照建議
- lcz.me #1252、#30599 系列 —— vLLM／SGLang 在 RDNA3 的早期實測
技術文章
- 智源 FlagOpen / FlagGems —— C++ Wrapper 與 Triton 算子呼叫鏈的實測文章（小算子 wrapper 開銷 60–100 µs 的量級，與我們量到的每步固定開銷同階）
若有遺漏，敬請在下方指出 —— 這是我們的疏失，絕非本意。
八、技術附錄（供其他 AI 與工程師取用）
本節供機器讀取，人類讀者可直接略過。
8.1 生產配置指紋
啟動腳本 sha256 : 7f52d3b0bfe876ad34d5c55c25e5e9a42b83afbae01b8a85891eac905f27a114 生產 .so sha256 : 7847e12eaf3d8b104f0227ab779dcfdef4248e843668d461334522598f2f5625 （29,823,720 bytes = BLOCK_KN_SIZE 512）8.2 生效參數
--model-path .../Qwen3.8-27B-INT4-GPTQ-v3 --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 NEXTN （內部解析為 EAGLE／MTP-3：steps 3 / topk 1 / draft 4） --cuda-graph-max-bs 32 --sleep-on-idle --max-running-requests 4 --max-queued-requests 6 --enable-hierarchical-cache --hicache-ratio 1.0 --hicache-size 8 --hicache-write-policy write_through --hicache-io-backend kernel --hicache-mem-layout page_first --enable-cache-report --default-chat-template-kwargs {"enable_thinking": false} （無 --page-size ⇒ page_size = 1）8.3 環境變數（全部，實讀自 /proc/pid/environ）
SGL_RDNA_CUSTOM_AR=0 SGL_RDNA_NO_FUSED=1 SGL_RDNA_GEMMA_TRITON=1 SGL_RDNA_VLLM_VERIFY=1 SGL_RDNA_LMHEAD_INT4=1 SGL_RDNA_LMHEAD_INT4_GS=128 SGL_RDNA_LMHEAD_INT8=0 SGL_WMMA_KSPLIT_AUTO=1 SGL_DTYPE=bfloat16 SGLANG_PHASE_TIMING=1 SGLANG_ENABLE_HEALTH_ENDPOINT_GENERATION=0 SGLANG_ENABLE_DETERMINISTIC_INFERENCE=0 SGLANG_MAMBA_SSM_DTYPE=bfloat16 SGLANG_CPROFILE_SPEC=0 TVM_FFI_DISABLE_TORCH_C_DLPACK=1 PYTHONPATH=.../prod/rdna_shim8.4 關鍵量測（附儀器）
量 值 儀器 decode（DSH agent 路徑 ~20K ctx） 62.11 t/s 引擎 log gen throughput，running-req=1，n=11 decode（短提示單流） 85.05 t/s 同上 每步固定開銷（gap > 20 µs） 2.4% 09-11 decode 段 817.12 ms 逐段 GPU busy（滿載） 89.2 – 94% 同兩次 GPU 滿載溫度 EDGE / HOTSPOT / MEM 79 / 99 / 94 °C amd-smi（門檻 100/110/105） 節流 無（GFX CLK 2148 ＝ MAX_CLK） amd-smi metric 每 token 有效權重頻寬 ~385 GB/s（74 t/s × 19 GB ÷ accept 3.65） 推導 8.5 生產 kernel 的 ISA 拆解（M≥16 WMMA 路徑）
反匯編自生產 .so 的
.hip_fatbin內嵌 ELF，目標gemm_q4_wmma_kernel_16x16_1w<__hip_bfloat16>：指令 靜態條數 v_wmma1 s_waitcnt49 └ lgkmcnt(0)27 ds_load_u16_d16＋_hi8 ＋ 8 ＝ 16（對應源碼 for (i=0..15) b_frag[i] = b_tile[i][lane_lo]）ds_bpermute8 global_atomic_cmpswap8 編譯器（AMD ROCm LLVM fork，clang 22.0.0git）並非無能 —— 它在其他位置懂得使用
lgkmcnt(1)×98、(2)×20、(7)×24 等局部等待。是這段存取模式令它只能選擇最保守的方案。8.6 上游 vLLM 的新路線（我們尚未採用）
vllm/model_executor/kernels/linear/mixed_precision/rdna_hybrid_w4a16.py：M <= MAX_SKINNY_BATCH_SIZE (=5) : HIP skinny GEMM (wvSplitK_int4_g) M > MAX_SKINNY_BATCH_SIZE : Triton W4A16 fused dequant GEMM我們的 decode 有 80% 屬 M=4，恰好落在第一段；而我們目前兩段皆使用 GPTQ kernel。
8.7 已發佈的技術層（供取用）
轉換器 : tools/convert_quark_int4_to_gptq_v3.py（Quark W4A16 → GPTQ，無損） 補丁 : patches/0001..0019.patch（基底 StevenChenSE/sglang gfx1100-support @ 1442c18） shim : shim/rdna_lmhead_int8.py（INT4 LM head，端到端 +19.7%） repo : https://github.com/lawsirlawsir-png/rdna3-quark-w4a16 (tag v1.0.0) 驗證方式：以 HTTPS 下載全部 19 個 patch → 套用到 1442c18 的乾淨檢出 → git am 全數通過 → 與生產建置來源 git diff --quiet 無輸出（9,034 檔相同）。
8.8 硬體身份（實測）
MARKET_NAME : AMD Radeon PRO W7800 48GB SUBVENDOR_ID : 0x1458 (GIGABYTE) DEVICE_ID : 0x7449 SUBSYSTEM_ID: 0x2428 NUM_COMPUTE_UNITS: 70 TARGET_GRAPHICS_VERSION: gfx1100 PCIE : Gen 4 x16（MAX_PCIE_WIDTH 16 / MAX_PCIE_SPEED 16 GT/s） vBIOS : W7800 48G/F1/1133 -
測試平台：GIGABYTE Radeon
PRO W7800 AI TOP 48G（單卡）
gfx1100 / RDNA3 ｜ 70 CU ｜ ROCm 7.2.4 ｜ Ubuntu 24.04 ｜ Ryzen 5 7500F ｜ 30 GB RAM
2026-09-15
〇、實測成績：DSH 真實 agent 路徑
本節所有數字均直接抽取自引擎日誌，並非實驗室短提示評測。
真實 agent 工作負載（DSH，上下文約 20K）
指標 值 decode 吞吐 62.11 t/s 樣本數 11（59.55 / 62.11 / 63.94 / 59.49 / 52.37 / 59.95 / 67.80 / 78.91 / 71.91 / 76.56，另有 1 個 9.35 離群值） accept length 2.87 – 3.70 同一台機器、短提示單流 85.05 t/s ⇒ 兩者唯一的變數是上下文深度（full token 20,004 – 20,944）。這就是 agent 場景的真實成本。
複驗（2026-09-15，HiCache 8 ＋ chunk 8192）
指標 值 decode 吞吐 61.5 t/s（n=23，full token 中位數 24,299） p90 80.4 t/s accept length 中位數 3.40 ⇒ 與 09-14 的 62.11 t/s 一致，並無退步。（用戶主觀感受的 74 t/s 屬較短上下文。）
與我們上一份帖文的對比（同一張卡、同一工作負載）
我們 2026-09-08 的上一份帖文（lcz.me/topic/1559）在同一張 W7800 上報告：DSH 真實 agent 工作負載單發 50.9 t/s（gen mean；median 53.9、max 79.5；KV 範圍 11–21K）。
2026-09-08（topic 1559） 2026-09-15（本文） 變化 DSH agent 路徑 decode（單發） 50.9 t/s 62.11 t/s +22.0% 上下文範圍 11–21K 20,004–20,944 同級 ⇒ 七日之內 +22%。而這不是單一變因的功勞 —— 期間換了模型配方（W4A16-AutoRound-GPTQ → INT4-GPTQ-v3）、加了自己寫的 INT4 lm_head shim（+19.7%）、改了兩處 kernel（合計再 +6.5%），並把整套配置重搭回同一條線上（見第二節）。
⇒ 更重要的是：前面仍有大把路未走。 上游 vLLM 已改用我們尚未採用的兩條新路線、確定性開關從未打開、kernel 內部那道 498-cycle 的串行鏈尚未拆解。詳見第六節。
生產環境實績
項 值 decode 中位數（投產時） 57–60 t/s KV cache 命中率 65 – 77% 曾經承擔 11 個 subagent 並行審計 split-K 512 與 1024 之 A/B 70 對 61 t/s 這些數字在任何 gfx1100 單卡用戶的環境中皆可復現。
一、我們是誰、在什麼卡上做
我們只有一張 GIGABYTE Radeon
PRO W7800 AI TOP 48G（gfx1100、70 CU）。單卡這一事實至關重要，因為它決定了我們所有結論的邊界：
我們 論壇其他前輩 卡 W7800 48G ×1（70 CU） 7900 XTX ×2（各 96 CU）／4090 48G 改裝版 ×1／4080S ×2 總 VRAM 48 GB 48 GB（雙 7900XTX 24+24）／48 GB TP 1 2（雙卡） 卡片架構 RDNA3 gfx1100 7900XTX 同為 gfx1100 但 96 CU；4090 為 NVIDIA ⇒ 本文出現的任何數字，其前提皆為「單卡、70 CU、gfx1100」。
W7900（96 CU）、7900 XTX（96 CU）與 W7800（70 CU）雖然同屬 gfx1100，但 CU 數不同，吞吐量不可直接套用。 我們先前見到有材料把 CU 數寫成 96 —— 那是 W7900 的數字，我們這張是 70（amd-smi 實測）。
我們的目標很簡單：把 gfx1100 用戶所能運用的軟件算力，逐分逐毫地榨取出來，而且每一步都可復現。
二、主軸線：這條路的形成過程
起點：一句提示把我們推了進來
2026-09-05 我們試用 SGLang 官方版，結論為「已列名，但尚未就緒」（FP8 只有 0.62 t/s）。正想放棄的時候，Terry 在我們的報告下面留下一句：
「你可以嘗試下 SGLang，論壇有帖子，體驗會好很多」
一句提示，我們投入了十天。沿著他指出的方向，我們找到論壇前人已經鋪好的路（見文末致謝），最後以社群的 gfx1100-support fork 完成三引擎完整對比，才定下生產配置。
⇒ 這是本文最想說明的一件事：這條路是社群鋪出來的，我們只是接續前行。
中段：找到真正的病灶
我們做過許多無效的優化，代價最高的一課是：有一整輪優化耗在一個穩態佔比 0% 的 kernel 上 —— 那個檔案佔 46% 的代碼量，卻只佔 4.59% 的 GPU 時間；真正的熱核佔 61.14%。
質量集中處 ≠ 能量集中處。
這句話後來成為我們所有優化的第一道關卡：動手之前先量能量分佈。
轉折：接入 AMD 原版模型
AMD 在 HuggingFace 放出
amd/Qwen3.8-27B-Quark-AWQ-INT4-W4A16，但它在 RDNA3 上無法運行 —— SGLang 的 Quark 模組只實作了三種 scheme，純 W4A16 沒有；quark/weights.py甚至直接註明「Scheme didn't allocate the parameter (e.g. W4A16)」。我們撰寫了轉換器把它接入。這是我們第一件原創作品（詳見第三節）。
關鍵一段：INT4 之後，速度是怎樣追回來的
接通 AMD 原版模型之後，我們面對第二個問題：模型能跑，但速度不夠。
我們寫了一個 Python shim（
rdna_shim/rdna_lmhead_int8.py），經PYTHONPATH注入，在 vendored 樹只加三行攔截_compute_lm_head。它不改 kernel，而是換路線：lm_head 是 248320×5120 的 bf16 矩陣（2.543 GB），每步被讀四次（verify 一次 M=4、draft 三次 M=1），合共約 13.9 ms/步、佔步時約 20%；M=1 時完全是記憶體綁死，位元寬直接決定成本。改用 INT4 之後每次只讀 0.661 GB。階段 引擎吞吐（5K 上下文、temp 0） 相對基準 bf16 lm_head（原狀） 57.12 t/s — int8 lm_head（中間步驟） 60.43 t/s +5.8% int4 lm_head（最終） 68.38 t/s +19.7% 輸出 MD5 三者完全相同，accept length 4.0 不變，U+FFFD 為 0。 兩次獨立量測得 68.41 / 68.38。
在此之上，我們又改了 kernel 本體兩處：WMMA 門檻由 M≥16 下移至 M≥9 && N≥2048（M=9 GEMM 246.7 → 185.9 µs，−24.6%），以及 B2 編譯期模板化（M=4 −9.3%、M=5 −8.7%、M=8 −14.2%）。端到端 68.38 → 72.84 t/s，累計對 bf16 基準 +27.5%，輸出與基準逐字節相同。
速度追回來之後，我們再把底盤逐件接回： MTP-3 投機解碼（09-11 由 DFLASH 折返後重新接上）、CUDA graph、HiCache（命中率 65% → 77%，09-14 重新上線），最後是 09-14 傍晚的 DFLASH8 ＋ HiCache8（單流 92.57 t/s）。
⇒ 這一段的代價，同樣如實記錄：
時間 失敗與代價 09-11 13:20 投機門檻下移 M≥2 雖然修復了確定性，代價是吞吐 −15.2%（88.9 t/s）。交易為負，已放棄並還原。 09-11 13:20 draft 量化 v3：體積由 3.85 GB 降到 1.743 GB，但 accept rate 掉到 0.00、吞吐 15.7 t/s（−85%） 09-11 14:14 事故：INT4 一度被洗成 W4A16 —— exp_config.py的 REF 寫死了 W4A16 配方，13:31 起所有受控測試全部跑錯模型09-11 22:36 差一點誤報成功：見到 HYBRID 啟動與 84.9 t/s，真相是 HYBRID 失敗後系統 fallback 到 DFLASH；靠 /proc/<pid>/cmdline硬驗證才攔截下來09-11 22:36 字串拼接改配置令反斜線續行斷裂，生產停擺 3.5 分鐘 09-13 P29–P52 工藝戰役：18 個假說全部否證（全部落在 ±0~2%），隨後證明整場戰役打在那個只佔 4.59% GPU 時間的 kernel 上 ⇒ 這就是「質量集中處 ≠ 能量集中處」的代價，也是我們把它列為第一道關卡的原因。
現在：把差距交代清楚
接入之後，我們量到自身的服務品質低於 AMD 公布的數字（PPL 高一成、GSM8K 低七分）。我們排除了六個嫌疑，但機制仍未定位 —— 此點我們在第四節誠實交代。
三、我們原創的三項成果
3.1 Quark W4A16 → SGLang GPTQ 轉換器（已開源）
原意：讓 gfx1100 用戶不必等待 SGLang 補上 W4A16 scheme，當日即可運行 AMD 原版模型。
實質作用：把 Quark 的 N-packed
[K, N/8]佈局重新打包成 GPTQ 的 K-packed[K/8, N]，權重未改動任何一個位元。技術核心（亦是我們耗時最久之處）：Quark 在
pack_method="reorder"之下，每個 int32 內的 8 個 4-bit 值並非順序排列，而是按order_map = [0,2,4,6,1,3,5,7]重排。忽略這一步，整個模型將輸出亂碼。我們當初正是遺漏了這一步，以數值掃描猜測數小時之久；最終閱讀官方
quark/torch/utils/pack.py之後即得解。⇒ 教訓：凡涉及外部格式，先讀官方實作，不可依靠試探。此後成為我們的鐵律。
無損驗證（三條獨立證據）：
檢驗 結果 逐元素反量化比對（5 層，含 N=48 的極瘦層） max 絕對差 = 0.000000e+00 全層覆蓋 496 個量化層 ＋ 703 個普通層 對 BF16 原模型的忠實度（96 個 in_proj）cos 最小 0.9871、中位數 0.9905 3.2 N-aware K-split（小 M 專用，−7.9%）
Commit：
0d2e013 perf(rdna3-wmma): opt-in N-aware k_split for small-M; -7.9% on M=16 verify GEMM across all 6 production shapes, fp64-identical accuracy; default path unchanged原意：上游的
compute_wmma_k_split()只看 K、不看 N，因此在 K ∈ {5120, 6144, 17408} 時一律返回 4。但在我們的生產形狀中，N=5120 佔權重的 23.6%，在 k=4 之下嚴重佔用不足。實質作用：改為 N-aware 規則 —— 選取「令 block 數達到約 5120 的最小 k」。在我們六個生產形狀上逐一掃描後：
六個生產形狀的逐 k 掃描（單位 ms，粗體為實測最優）
- 5120 × 17408：k=4 0.22503 ｜ k=8 0.22087 ｜ k=16 0.22612 ｜ k=32 0.25149 ⇒ k=8
- 17408 × 5120：k=4 0.26621 ｜ k=8 0.26696 ｜ k=16 0.22434 ｜ k=32 0.22263 ⇒ k=32
- 5120 × 10240：k=4 0.16138 ｜ k=8 0.13935 ｜ k=16 0.14128 ｜ k=32 0.15573 ⇒ k=8
- 6144 × 5120：k=4 0.10095 ｜ k=8 0.10367 ｜ k=16 0.09191 ｜ k=32 0.09835 ⇒ k=16
- 5120 × 6144：k=4 0.09661 ｜ k=8 0.09436 ｜ k=16 0.09122 ｜ k=32 0.09996 ⇒ k=16
- 5120 × 12288：k=4 0.17250 ｜ k=8 0.16021 ｜ k=16 0.16392 ｜ k=32 0.18090 ⇒ k=8
規則在 6 個形狀中有 5 個命中實測最優；唯一例外為 17408×5120，差 0.77%（按真實層混合加權後更小）。
最重要的一點：準確度在 fp64 之下逐位元相同，且預設路徑完全不變（須開啟
SGL_WMMA_KSPLIT_AUTO=1方生效）。我們其後實測關閉它：PPL 9.7296 對開啟時 9.7297，差 −0.00% ⇒ 這個效能補丁在數值上是忠實的。3.3 其他原創改動（逐項交代原意與作用）
Commit 原意 實質作用 c2d509e小 M WMMA 門檻下移至 M>=9 覆蓋 decode verify step（生產實測 80% 為 M=4，其餘為 M=8） 9af1d8dGPTQ kernel 編譯期模板化 Σa 預算與 z 修正改為每 group 一次，減少重複計算 b10a8ab正確性修正 把不規則（NGRAM）樹排除於 mask-less unified verify kernel 之外 01d62d6生產樹入版控 GPTQ M_COUNT 5/6/7、lm_head 低位寬 1f1ba80WMMA M=16 瓶頸研究 env-gated 量測變體，預設路徑不變 23dd307建置整潔 把量測變體排除於生產 build 之外 6c5409c建置整潔 停止追蹤 21 個由 hipify 產生的 .hip 檔 005ad71修錯 CU 數 96 → 70（96 為 W7900；本卡為 70） f736a74首次入版控 2026-09-08/09 的 gfx1100 生產補丁 另外兩項不在 git 之內、但同樣屬於我們原創的：
prod/rdna_shim/rdna_lmhead_int8.py—— INT4 LM head，只在小 batch 觸發- 我們整套量測方法論（見第五節）
四、陷阱：六個已排除的嫌疑，與一個仍未解開的差距
4.1 差距本身
指標 我們（單卡 W7800） AMD 官方卡 差 Wikitext word_perplexity 9.7297 8.8250 +10.25% GSM8K flexible（兩次全量平均） 83.70% 91.51% −7.81 pt GSM8K strict（同上） 84.12% 90.37% −6.25 pt 4.2 我們排除的（附方法）
# 嫌疑 排除方法 1 權重量化 逐元素反量化比對 max 絕對差 = 0（5 層）＋ 全層 496/496 ＋ 對 BF16 源 cos≥0.9871 2 LM head PPL 以 echo 取 prefill logprobs，而 INT4 LM head 只在 M ≤ 8 觸發（日誌： i4=1418 / miss=182）；換 BF16 後 9.7297 → 9.7297 完全不變3 量測儀器 echo 路徑與原生 /generate對同 6 篇文件得位元相同（差 0.000%）；token-PPL 5.52 × 1.32 = word-PPL 9.46 三數自洽4 資料集 wiki-2 與 wiki-103 的 test split sha 相同（62/62） 5 prompt 截斷 超長僅 0.61%、缺答案格式僅 0.30% 6 我們自己的 K-split 優化 關掉 → 9.7296（−0.00%） ⇒ 差距真實存在，機制我們尚未定位。我們不作猜測。
4.3 更重要的發現：我們自身的 greedy 解碼並不確定
上表兩次全量評測皆用 greedy（
do_sample=False），理應完全一致，實際卻相差 0.76 個百分點。於是我們在同一部伺服器、同一配置之下，同樣 150 題連續執行兩次：
指標 結果 輸出完全相同 107 / 150（71.3%） 對錯翻轉 3 題 兩次分數 85.33% 對 84.67% ⇒ 在我們的技術棧上，greedy 解碼是非確定的。
⇒ 因此我們不報告單一數字，而報告兩次全量評測的平均值，並標明自身噪音約 ±1 pt。
這也是本文的一項關鍵提醒：任何「更動一個參數即可令分數上升 0.5 pt」的結論，在此噪音水平之下皆不可信。
我們懷疑來源是 split-K 的 CAS 原子累加（加法次序不固定），或 LM head 低位寬路徑的 M ≤ 8 閘（精度隨 batch 大小跳變）。兩者皆未驗證。
4.4 幾項實用陷阱（可為他人節省時間）
① lm-eval 的 max_length 陷阱。 API 後端有
max_context_len = max_length − max_gen_toks。用預設max_length=2048配 AMD 的max_gen_toks=8192⇒ −6144 ⇒ prompt 截成空 ⇒ HTTP 400（我們觸發了 2645 次）。AMD 官方指令寫明max_length=16384。② LM head 的 M 閘。
M ≤ 8走 INT4、M > 8走 BF16 ⇒ 同一 prompt 的 logits 會因並發批次的組成而異，屬可重現性風險。③ page-size 與 hybrid mamba。 論壇實測：
page-size 64配 hybrid mamba 加 HiCache 本身即會段錯誤，必須page-size 1（我們恰好為 1）。④
--gpureset不可使用。 對 gfx1100 會鎖住 PCIe root port，須冷開機（社群警告）。
五、經驗：我們學到的若干原則
① 先對證，後落手。 凡涉及外部格式、協議、第三方語義，第一步必須尋求對證 —— 而且優先閱讀官方源碼，不讀文檔描述。
② 驗證方法本身要先驗證。 必須證明它能夠識別已知的壞輸入，而非僅止於「能夠運行」。（我們的一個精度閘門曾經對 NaN、全零、非有限輸出三個通道全部靜默判 PASS。）
③ 對證對象要驗身分。 凡對證，必印被對證對象的 sha256。修改時間、路徑、檔名，一概不可信。
④ 硬件規格只准實測。 同一張卡在四份材料中出現過 96 / 70 / 40 / 35 四個 CU 數，僅實測的 70 正確。
⑤ 質量集中處 ≠ 能量集中處。 動手之前先量能量分佈。
⑥ 配件無辜，組合有罪。 我們曾經把 HiCache 當作段錯誤主因；後來發現只有 DFLASH 與 HiCache 的組合才會出事，HiCache 本身無辜。
⑦ 一個中心為忠，兩個中心為患。 量度之前先釐清有幾個中心；並行量測會互相污染，任何時候只准一個。
六、將來目標
① 量測上游 vLLM 的新路線。 上游已改為 M≤5 使用專用 INT4 skinny GEMM（
wvSplitK_int4_g，wave 層分工 ＋ DPP 歸約、無原子競爭）、M>5 使用 Triton。我們的 decode 有 80% 屬 M=4，恰好落在第一段。A/B 工具已編譯完成，僅待執行。② 檢驗非確定性的機制。 同一個 A/B 實驗同時可驗：CAS 原子 對 DPP 歸約。
③ 開啟
--enable-deterministic-inference。 我們生產環境中此開關一直為 0。其說明為「batch invariant ops」，恰對應我們「精度隨 batch 跳變」的假設。④ 將 kernel 層開源 ——
已於 2026-09-15 完成。 以 patch series 形態發佈 19 個 patch（43 檔、+4,097 / −14,870 行），基底 StevenChenSE/sglang之gfx1100-support@1442c18。由 GitHub 下載後套用到乾淨檢出，可逐位元重現我們的生產樹。 https://github.com/lawsirlawsir-png/rdna3-quark-w4a16⑤ 繼續追查那個 +10.25% / −7.81 pt 的差距。 六個嫌疑已排除，機制尚未定位。
七、致謝 —— 我們的技術層有 99% 來自他人
我們所做的那 1% 之所以能夠成立，是因為前面已經有人把路鋪好。逐項歸位如下：
引我們走上這條路的人
- Terry（lcz.me）—— 「你可以嘗試下 SGLang，論壇有帖子，體驗會好很多」。一句提示，令我們投入了十天。
我們的基礎：開源項目
- @StevenChenSE ——
StevenChenSE/sglang的gfx1100-support分支。我們整條生產線建在這上面。 - @vllm-project —— RDNA3 的 WMMA GPTQ kernel（我們拆解的那份
q_gemm_rdna3_wmma.cu，檔案頭即為Copyright contributors to the vLLM project） - @amd —— AMD Quark 量化工具鏈與
pack.py的打包語義（沒有它，我們的轉換器無從對證） - @ExLlama 社群 —— GPTQ kernel 的血統
論壇前人（我們沿其路線前行）
- @flyer666 —— lcz.me #1532：SGLang ＋ HiCache 三級架構、為 HiCache 增加 RAM；#1640：gfx1100 單卡分析
- @抡锤者 / franklee006 —— lcz.me #1340（4090 48G ＋ DFlash2，DSH 寫碼均速 110 t/s）、#18288（雙 7900XTX 完整實戰）、#1329（HiCache 實測）、#1587（雙 4080S HiCache）
- @_折騰_ —— lcz.me #1500 / #1340：HiCache 多會話實戰、DFlash2 與 DSpark 的第一手主觀比較
- @Michael Zhou —— 4090D 48G 參數（經 #1329 轉錄）：
--mamba-full-memory-ratio 1.0、--mamba-scheduler-strategy extra_buffer、--mamba-track-interval 2048、page-size 1 - @清风明月 —— RTX PRO 4500 32G NVFP4 ＋ HiCache 參數（TID:1341）
- @Neo（lcz.me）—— HiCache L2/L3 原始帖
- @xiaote 老特 —— 參數調校與三方對照建議
- lcz.me #1252、#30599 系列 —— vLLM／SGLang 在 RDNA3 的早期實測
技術文章
- 智源 FlagOpen / FlagGems —— C++ Wrapper 與 Triton 算子呼叫鏈的實測文章（小算子 wrapper 開銷 60–100 µs 的量級，與我們量到的每步固定開銷同階）
若有遺漏，敬請在下方指出 —— 這是我們的疏失，絕非本意。
八、技術附錄（供其他 AI 與工程師取用）
本節供機器讀取，人類讀者可直接略過。
8.1 生產配置指紋
啟動腳本 sha256 : 7f52d3b0bfe876ad34d5c55c25e5e9a42b83afbae01b8a85891eac905f27a114 生產 .so sha256 : 7847e12eaf3d8b104f0227ab779dcfdef4248e843668d461334522598f2f5625 （29,823,720 bytes = BLOCK_KN_SIZE 512）8.2 生效參數
--model-path .../Qwen3.8-27B-INT4-GPTQ-v3 --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 NEXTN （內部解析為 EAGLE／MTP-3：steps 3 / topk 1 / draft 4） --cuda-graph-max-bs 32 --sleep-on-idle --max-running-requests 4 --max-queued-requests 6 --enable-hierarchical-cache --hicache-ratio 1.0 --hicache-size 8 --hicache-write-policy write_through --hicache-io-backend kernel --hicache-mem-layout page_first --enable-cache-report --default-chat-template-kwargs {"enable_thinking": false} （無 --page-size ⇒ page_size = 1）8.3 環境變數（全部，實讀自 /proc/pid/environ）
SGL_RDNA_CUSTOM_AR=0 SGL_RDNA_NO_FUSED=1 SGL_RDNA_GEMMA_TRITON=1 SGL_RDNA_VLLM_VERIFY=1 SGL_RDNA_LMHEAD_INT4=1 SGL_RDNA_LMHEAD_INT4_GS=128 SGL_RDNA_LMHEAD_INT8=0 SGL_WMMA_KSPLIT_AUTO=1 SGL_DTYPE=bfloat16 SGLANG_PHASE_TIMING=1 SGLANG_ENABLE_HEALTH_ENDPOINT_GENERATION=0 SGLANG_ENABLE_DETERMINISTIC_INFERENCE=0 SGLANG_MAMBA_SSM_DTYPE=bfloat16 SGLANG_CPROFILE_SPEC=0 TVM_FFI_DISABLE_TORCH_C_DLPACK=1 PYTHONPATH=.../prod/rdna_shim8.4 關鍵量測（附儀器）
量 值 儀器 decode（DSH agent 路徑 ~20K ctx） 62.11 t/s 引擎 log gen throughput，running-req=1，n=11 decode（短提示單流） 85.05 t/s 同上 每步固定開銷（gap > 20 µs） 2.4% 09-11 decode 段 817.12 ms 逐段 GPU busy（滿載） 89.2 – 94% 同兩次 GPU 滿載溫度 EDGE / HOTSPOT / MEM 79 / 99 / 94 °C amd-smi（門檻 100/110/105） 節流 無（GFX CLK 2148 ＝ MAX_CLK） amd-smi metric 每 token 有效權重頻寬 ~385 GB/s（74 t/s × 19 GB ÷ accept 3.65） 推導 8.5 生產 kernel 的 ISA 拆解（M≥16 WMMA 路徑）
反匯編自生產 .so 的
.hip_fatbin內嵌 ELF，目標gemm_q4_wmma_kernel_16x16_1w<__hip_bfloat16>：指令 靜態條數 v_wmma1 s_waitcnt49 └ lgkmcnt(0)27 ds_load_u16_d16＋_hi8 ＋ 8 ＝ 16（對應源碼 for (i=0..15) b_frag[i] = b_tile[i][lane_lo]）ds_bpermute8 global_atomic_cmpswap8 編譯器（AMD ROCm LLVM fork，clang 22.0.0git）並非無能 —— 它在其他位置懂得使用
lgkmcnt(1)×98、(2)×20、(7)×24 等局部等待。是這段存取模式令它只能選擇最保守的方案。8.6 上游 vLLM 的新路線（我們尚未採用）
vllm/model_executor/kernels/linear/mixed_precision/rdna_hybrid_w4a16.py：M <= MAX_SKINNY_BATCH_SIZE (=5) : HIP skinny GEMM (wvSplitK_int4_g) M > MAX_SKINNY_BATCH_SIZE : Triton W4A16 fused dequant GEMM我們的 decode 有 80% 屬 M=4，恰好落在第一段；而我們目前兩段皆使用 GPTQ kernel。
8.7 已發佈的技術層（供取用）
轉換器 : tools/convert_quark_int4_to_gptq_v3.py（Quark W4A16 → GPTQ，無損） 補丁 : patches/0001..0019.patch（基底 StevenChenSE/sglang gfx1100-support @ 1442c18） shim : shim/rdna_lmhead_int8.py（INT4 LM head，端到端 +19.7%） repo : https://github.com/lawsirlawsir-png/rdna3-quark-w4a16 (tag v1.0.0) 驗證方式：以 HTTPS 下載全部 19 個 patch → 套用到 1442c18 的乾淨檢出 → git am 全數通過 → 與生產建置來源 git diff --quiet 無輸出（9,034 檔相同）。
8.8 硬體身份（實測）
MARKET_NAME : AMD Radeon PRO W7800 48GB SUBVENDOR_ID : 0x1458 (GIGABYTE) DEVICE_ID : 0x7449 SUBSYSTEM_ID: 0x2428 NUM_COMPUTE_UNITS: 70 TARGET_GRAPHICS_VERSION: gfx1100 PCIE : Gen 4 x16（MAX_PCIE_WIDTH 16 / MAX_PCIE_SPEED 16 GT/s） vBIOS : W7800 48G/F1/1133数据很扎实，尤其把每步固定开销（gap>20µs）、accept length 和吞吐一起报，比只给 t/s 可信得多。
两点建议，都能在你现有配置上做单变量 A/B：
- 你 8.6 提到上游 vLLM 的 rdna_hybrid_w4a16 路线——你 80% 的 decode 落在 M=4，正好是 MAX_SKINNY_BATCH_SIZE=5 的 HIP skinny GEMM（wvSplitK_int4_g）分支。可以只把 decode 段切过去、prefill 仍留现有 GPTQ kernel，成本最低。
- page-size=1 + write_through + hicache-size 8 在 30GB RAM 下是合理的；但命中率只有 65–77% 时，write_through 的 host 写放大可能被低估，可以对比 write_back 看 decode 段是否更平稳。
另外你把 W7800（70CU）和 7900XTX（96CU）、W7900 的边界写得很清楚，这点最容易被抄参数的人忽略。
-
，
T terry 固定了此主题
-
讀完,,讓ai翻譯,20-24k上下文,感覺生產力不夠?
直接幫你抽取出「實際開多少上下文」與「實際輸出速度（Token/s）」，對比清清楚楚：
一、他到底測了什麼？（平台環境）
- 顯示卡：AMD 專業卡 Radeon PRO W7800 48GB（單卡，跟你的 7900 XTX 一樣是 RDNA3 / gfx1100 架構，但你的 7900 XTX 運算單元比他強！他 70 CU，你的 7900 XTX 是 96 CU 滿血版）。
- 跑的模型：Qwen3.8-27B（INT4 量化版）。
- 跑的框架：SGLang（透過魔改支援 AMD ROCm / RDNA3）。
二、實際「上下文」開多少？實際「Token 速度」多少？
作者測了 兩種情境（這就是為什麼文章裡數字跳來跳去）：
- 【真實 Agent 重度工作負載】（對話很長時，也就是你目前關心的指標）
- 實際上下文深度（Context）：約 20,000 ~ 24,000 Tokens (20K~24K)
(原文數據：full token 20,004 – 20,944，複驗中位數 24,299) - 實際解碼輸出速度（Decode Throughput）：
61.5 ~ 62.11 t/s（Token/秒）
(這是在吃滿 2 萬多字上下文的情況下，每秒還能吐出 62 個字！)
- 【短提示單流測試】（問一句簡短問題時）
- 實際上下文深度（Context）：短提示（極小上下文）
- 實際解碼輸出速度（Decode Throughput）：
85.05 t/s（Token/秒）
(如果開啟他改寫的 DFLASH 投機解碼，短文最快甚至能飆到 92.57 t/s)
三、三行白話文總結他整篇在講什麼：
- 上下文越長越慢：上下文在短的時候能跑 85 t/s，但當上下文吃到 20K~24K 時，速度會掉到 62 t/s。
- AMD 顯卡跑大模型有搞頭：他證明了 AMD RDNA3（gfx1100）單張顯卡跑 27B 大模型，即使上下文塞了 2 萬字，依然能有 62 t/s 的極高實用速度。
- 對店長 7900 XTX 的意義：你的 7900 XTX 算力核心（96 CU）比這張 W7800（70 CU）高出近 37%，只要顯存放得下，在類似架構下的理論推論速度只會比他更快！
-
@CHIA AN YANG 这篇 AI 翻译有一处要纠正：7900 XTX 比 W7800 快，不是「96 CU vs 70 CU 所以快 37%」。
gfx1100 上 decode 是带宽瓶颈不是算力瓶颈：7900 XTX 960 GB/s，W7800 48G 只有 576 GB/s，光带宽就差 1.6×。所以 27B INT4 长上下文 decode 上 XTX 会更快，但幅度由带宽决定，不是 CU 数；CU 数主要影响 prefill（compute-bound）。
另外 62 t/s @ 20–24K 在单卡 gfx1100 上不算「生产力不够」，是正常区间：decode 每步要读全部权重（27B INT4 ~14GB）+ KV（fp16 20K 约 2–3GB），带宽吃满就是这个量级。想再快只能降 KV 精度、缩上下文或上投机解码，加 CU 没用。
-
讀完,,讓ai翻譯,20-24k上下文,感覺生產力不夠?
直接幫你抽取出「實際開多少上下文」與「實際輸出速度（Token/s）」，對比清清楚楚：
一、他到底測了什麼？（平台環境）
- 顯示卡：AMD 專業卡 Radeon PRO W7800 48GB（單卡，跟你的 7900 XTX 一樣是 RDNA3 / gfx1100 架構，但你的 7900 XTX 運算單元比他強！他 70 CU，你的 7900 XTX 是 96 CU 滿血版）。
- 跑的模型：Qwen3.8-27B（INT4 量化版）。
- 跑的框架：SGLang（透過魔改支援 AMD ROCm / RDNA3）。
二、實際「上下文」開多少？實際「Token 速度」多少？
作者測了 兩種情境（這就是為什麼文章裡數字跳來跳去）：
- 【真實 Agent 重度工作負載】（對話很長時，也就是你目前關心的指標）
- 實際上下文深度（Context）：約 20,000 ~ 24,000 Tokens (20K~24K)
(原文數據：full token 20,004 – 20,944，複驗中位數 24,299) - 實際解碼輸出速度（Decode Throughput）：
61.5 ~ 62.11 t/s（Token/秒）
(這是在吃滿 2 萬多字上下文的情況下，每秒還能吐出 62 個字！)
- 【短提示單流測試】（問一句簡短問題時）
- 實際上下文深度（Context）：短提示（極小上下文）
- 實際解碼輸出速度（Decode Throughput）：
85.05 t/s（Token/秒）
(如果開啟他改寫的 DFLASH 投機解碼，短文最快甚至能飆到 92.57 t/s)
三、三行白話文總結他整篇在講什麼：
- 上下文越長越慢：上下文在短的時候能跑 85 t/s，但當上下文吃到 20K~24K 時，速度會掉到 62 t/s。
- AMD 顯卡跑大模型有搞頭：他證明了 AMD RDNA3（gfx1100）單張顯卡跑 27B 大模型，即使上下文塞了 2 萬字，依然能有 62 t/s 的極高實用速度。
- 對店長 7900 XTX 的意義：你的 7900 XTX 算力核心（96 CU）比這張 W7800（70 CU）高出近 37%，只要顯存放得下，在類似架構下的理論推論速度只會比他更快！
@CHIA-AN-YANG 其實我也測出9X T／S， 不過那個數據没有用， 始終大家都是用AGENT HARNESS，我在DSH測出這個數字也非常夠用了， 我的目標是在AMD的卡上追趕NVIDIA，有60－70％的效果我個人覺得已相當不錯。
-
，系统 取消固定了此主题
不過，我真的不知道AI做了什麼的， 我不是程序員PROGRAMMER，數學也没學好。做1％工作就是這樣，小突破也不錯。我10天玩出一個花樣也算是為這社群做一次有1％原創性的貢獻。