各位好，分享下我部機嘅 SGLang + HiCache 完整實測。雙 4080 SUPER 32G（64G 總顯存）跑 Qwen3.8-27B-FP8，開 256K context。呢個部署最特别嘅地方：成個調校過程（kernel tuning、P2P 排查、參數定案）全部係我用 GLM Zcode + GLM 5.3 嘅 agent 搞掂，我基本只負責出指令同審 log——正正係 terry 話過嗰句「讓你的 Agent 去操作」嘅實例。

先講結論（TL;DR）

• 2× RTX 4080 SUPER 32G，TP2，各食 ~30G VRAM
• SGLang v0.5.18 + HiCache（hicache-ratio 2，RAM 層 748K tokens，總 cache ~1.12M tokens）
• 256K context、FP8 KV、NEXTN/MTP 投機解碼（accept rate ~0.61，單流 peak 過 200 t/s）
• Decode：1 用戶 65.6 t/s → 4 用戶 aggregate 179 t/s（temp 0 實文測試）
• Prefill 天花板 ~1,950 t/s（NVIDIA 驅動封咗 Ada GeForce 嘅 P2P，NCCL 要行 host RAM，呢個係硬頂）
• HiCache 實測：50K prompt 27.8s → 2.4s（11.6x）；32K 16.4s → 0.5s（32x）
• 生產 log 17 分鐘窗口：HiCache 命中 62/146 個 prefill batch，单次最大命中 86,528 tokens
• 全部調校由 GLM Zcode + GLM 5.3 agent 執行：W8A8 FP8 GEMM 手動 tune 5 個 shape、P2P/ACS/IOMMU 排查、參數 A/B——agent 做嘢，人審 log

一、硬件配置

GPU 空載 ~185W（cap 320W），52-57C。

二、成個部署點樣搞：GLM Zcode + GLM 5.3 agent

呢部機嘅 SGLang 部署、調校、排查，流程全部係 agent 做：

1. 起手俾指令：「幫我部雙 4080S 部署 Qwen3.8-27B-FP8，SGLang，要 256K context，要 HiCache」
2. agent 自己拉 image、寫啟動腳本、對齊 param（--hicache-ratio 2、--page-size 64、--max-mamba-cache-size 32 全部係佢測出嚟嘅）
3. 之後嘅優化全部係 agent 主導：
   • W8A8 block-FP8 Triton GEMM 手動 tune：寫咗 5 個 weight shape（qkv_proj / o_proj / gate_up / down_proj + 2 個小 shape）嘅 benchmark script，每個 shape 掃幾百組 block config，寫返成 tuned config JSON 掛進 image。結果 GEMM 快 1-5%，decode 整體 +3%——GEMM 只係 prefill 時間嘅 ~25%，所以唔係大頭
   • P2P 排查：agent 自己試晒 ACS（setpci 清 root port offset 0x2a6）、iommu=pt、amd_iommu=off，最後 cudaDeviceCanAccessPeer 仍然 False → 結論係 NVIDIA 驅動層面封晒所有 Ada GeForce 卡（4080/4080S/4090）嘅 P2P，係 SKU policy 唔係硬件問題，主板/ACS/IOMMU 全部排除
   • DSpark 投機解碼實驗：deadlock 同 HiCache、block-7 喺 32G OOM、block-3 比 NEXTN 慢 → 放棄，用 checkpoint 自帶嘅 NEXTN head
   • 踩坑清單（agent 試出嚟先寫返入 README 嘅）：--hicache-io-backend kernel 同 hybrid Mamba 模型會 crash（sglang #24121），要行 direct；chunked-prefill 加大無用；MSCCL++ allreduce TP2 唔支援

人嘅角色：審 log、拍板、出下一個指令。呢個同 forum 前人嘅做法一致——terry 講過「把地址粘贴给你的AI Agent...千万不要自己动手去配置」，我部機正正係咁。

三、軟件棧

• Docker: lmsysorg/sglang:v0.5.18
• 模型: Qwen3.8-27B-FP8（29GB，含 vision tower）
• 啟動參數：

python3 -m sglang.launch_server \
  --model-path /models/Qwen3.8-27B-FP8 \
  --host 0.0.0.0 --port 30000 \
  --tp 2 \
  --kv-cache-dtype fp8_e4m3 \
  --context-length 262144 \
  --mem-fraction-static 0.88 \
  --max-running-requests 8 \
  --cuda-graph-max-bs 8 \
  --chunked-prefill-size 4096 \
  --page-size 64 \
  --max-mamba-cache-size 32 \
  --enable-hierarchical-cache \
  --hicache-ratio 2 \
  --hicache-io-backend direct \
  --hicache-write-policy write_through \
  --speculative-algorithm NEXTN \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --enable-metrics \
  --default-chat-template-kwargs {"reasoning_effort": "medium"}

容量拆解：GPU KV pool ~374K tokens + HiCache RAM 層 748K tokens = 總 cache ~1.12M tokens（約 4 條 262K 並行）。MTP 投機要食一部份容量（開 MTP 前係 ~2.0M），接受呢個 trade-off。

四、實測數據（2026-09-09 HKT，全部本機實跑）

Decode（實文測試，temp 0）

scaling 曲線好順：1→4 用戶 aggregate 2.7x，8 用戶見頂 ~213 t/s（PCIe TP + KV pool 限制）。

Prefill

~2K t/s 就係呢部機 TP2 嘅硬頂——因為 NVIDIA 封咗 P2P，NCCL allreduce 全部行 host RAM。要突破就得上 NVLink 卡（A6000/H100 級）或者 community hack 4090 驅動（生產環境唔建議）。

TTFT（冷，流式首 token）

HiCache 效果（呢部機最大嘅賣點）

生產 log 實證（17 分鐘 agent 真實 workload 窗口，09:32→09:50 HKT）：

• 146 個 prefill batch 入面 62 個命中 cache（42%）
• 单次最大命中 86,528 tokens（長 conversation 直接搬返 VRAM）
• 519 個 batch 只有 14 個 queue>0——8 路並發都基本唔塞
• NEXTN accept rate 平均 0.61，decode gen throughput 中位 70.9 t/s、p90 103 t/s、peak 295 t/s

五、同 forum 前人 post 對照

• #1559（W7800 48G SGLang 投產實測）：佢單卡 bf16 KV，cache hit 65-77%、decode 中位 57-60 t/s。我雙卡 FP8 KV 單流 65-70 t/s、並發高一檔（TP2 分攤 VRAM 先頂得住 256K）。佢嗰邊 gfx1100 靠社區 fork，我呢邊 Ada 卡官方 SGLang 直接就行，但 P2P 被封係 Ada 獨有嘅痛
• #1542 / #1532（terry / flyer666 7900XTX 雙卡）：佢哋話雙卡 TP + HiCache 係補齊 7900XTX 最後短板，4 併發 200 t/s。我部機 4 併發 179 t/s（實文 temp 0）、8 併發 213 t/s，數量級對得上。flyer666 講 HiCache 要夠內存，我 125G 配 748K token RAM pool，agent 長 session 唔會觸頂
• #1559 嘅 MTP 結論：佢 gfx1100 上 MTP-3 係最大加分項；我呢度 NEXTN（checkpoint 自帶 head）accept rate 0.61，decode 中位拉上 70 t/s，peak 295——方向一致，投機解碼喺 27B 呢個級別都係值得開

六、幾句心得

1. 4080 SUPER 32G × 2 跑 27B FP8 + 256K ctx + HiCache 係啱啱好嘅甜點：64G VRAM 再大 10% 都冇咁舒服，29G 模型 + KV pool 374K + MTP 全部塞得入
2. Ada 卡做 TP2 嘅真瓶頸係 P2P 被封：GEMM tune 完 +3% 都冇用，allreduce 行 RAM 就係 ~2K t/s 天花板。呢個要買卡之前就知道
3. HiCache write_through + direct backend 係 agent 場景正解：prefix 重覆率極高，直接寫穿命中最穩；kernel backend 有 crash bug 唔好碰
4. agent 代操係真嘅可行：GLM Zcode + GLM 5.3 做晒 kernel tuning、P2P 排查、參數 A/B，人只需要審 log 拍板。成個調校過程 log 完整可溯源，agent 仲會自己寫 README 記坑——呢個就係本地機 + 本地 agent + 本地模型嘅完整閉環
5. 256K context 代價：GPU 各食 ~92%，冇得再調 mem-fraction；MTP 食走一部份 cache 容量（1.12M vs 2.0M tokens）

完整 benchmark log、SGLang server log、tuning script、README 全部留底，想對數據嘅朋友留言，我貼 log 片段。

用呢部機做本地 coding agent（多 subagent 並行）實戰：4-6 併發流暢、單流打字速度肉眼可接受、長 conversation 第二次開始 TTFT 全部 <1s。洋垃圾 X99 平台 + 兩張 32G 卡 + 本地 agent 全程調校，呢個價位我目前見到性價比最高嘅 256K 長上下文投產方案，歡迎各位大佬補充同指正。