雙 4080 SUPER 32G + SGLang HiCache 實測：Qwen3.8-27B-FP8，256K context，agent 全程代操（GLM Zcode + GLM 5.3）
-
雙 4080 SUPER 32G + SGLang HiCache 實測：Qwen3.8-27B-FP8，256K context，agent 全程代操（GLM Zcode + GLM 5.3）
各位好，分享下我部機嘅 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
一、硬件配置
項目 配置 主板 華南金牌 H12D-8D V2.0（X99 雙路平台，單路用，2× PCIe 4.0 x16 實測跑滿 16GT/s） CPU AMD EPYC 7K62 48C/96T @ 3.3GHz（單路） 內存 125GB DDR4-2400（4× 32GB SK Hynix ECC），HiCache host 層食咗 ~36GB 顯卡 2× NVIDIA RTX 4080 SUPER 32GB（PCIe Gen4 x16，無 NVLink、無 P2P，TP 走 PCIe + NCCL） 存儲 KIOXIA EXCERIA Basic 1.8TB NVMe 系統 Ubuntu 24.04，NVIDIA driver 595.84 / CUDA 13.2，Docker 部署 網絡 LAN 192.168.0.122 + Tailscale（100.82.33.33，OpenAI-compatible API 尾網直達） GPU 空載 ~185W（cap 320W），52-57C。
二、成個部署點樣搞：GLM Zcode + GLM 5.3 agent
呢部機嘅 SGLang 部署、調校、排查，流程全部係 agent 做：
- 起手俾指令：「幫我部雙 4080S 部署 Qwen3.8-27B-FP8，SGLang，要 256K context，要 HiCache」
- agent 自己拉 image、寫啟動腳本、對齊 param（
--hicache-ratio 2、--page-size 64、--max-mamba-cache-size 32全部係佢測出嚟嘅） - 之後嘅優化全部係 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）
並發 每用戶 總吞吐 1 用戶 65.6 t/s 65.6 t/s 2 用戶 51.7 t/s 103 t/s 4 用戶 44.7 t/s 179 t/s 8 用戶（agent workload） ~27 t/s ~213 t/s scaling 曲線好順：1→4 用戶 aggregate 2.7x，8 用戶見頂 ~213 t/s（PCIe TP + KV pool 限制）。
Prefill
場景 吞吐 1× 32K ~1,930 t/s 2× 32K ~1,950 t/s 4× 32K ~1,970 t/s 1× 128K ~1,530 t/s ~2K t/s 就係呢部機 TP2 嘅硬頂——因為 NVIDIA 封咗 P2P，NCCL allreduce 全部行 host RAM。要突破就得上 NVLink 卡（A6000/H100 級）或者 community hack 4090 驅動（生產環境唔建議）。
TTFT（冷，流式首 token）
Prompt TTFT 128 tok 82ms 2K 1.65s 4K 1.78s 8K 3.63s 16K 7.44s 32K 16.35s 64K 39.0s HiCache 效果（呢部機最大嘅賣點）
場景 冷 命中 加速 50K prompt 重覆 27.8s 2.4s 11.6x 32K prompt 重覆 16.35s 0.51s 32x 5.6K prefix 重覆 2.88s 0.32s（cached_tokens=5568） 8.9x 生產 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 呢個級別都係值得開
六、幾句心得
- 4080 SUPER 32G × 2 跑 27B FP8 + 256K ctx + HiCache 係啱啱好嘅甜點：64G VRAM 再大 10% 都冇咁舒服，29G 模型 + KV pool 374K + MTP 全部塞得入
- Ada 卡做 TP2 嘅真瓶頸係 P2P 被封：GEMM tune 完 +3% 都冇用，allreduce 行 RAM 就係 ~2K t/s 天花板。呢個要買卡之前就知道
- HiCache write_through + direct backend 係 agent 場景正解：prefix 重覆率極高，直接寫穿命中最穩；kernel backend 有 crash bug 唔好碰
- agent 代操係真嘅可行：GLM Zcode + GLM 5.3 做晒 kernel tuning、P2P 排查、參數 A/B，人只需要審 log 拍板。成個調校過程 log 完整可溯源，agent 仲會自己寫 README 記坑——呢個就係本地機 + 本地 agent + 本地模型嘅完整閉環
- 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 長上下文投產方案，歡迎各位大佬補充同指正。
-
雙 4080 SUPER 32G + SGLang HiCache 實測：Qwen3.8-27B-FP8，256K context，agent 全程代操（GLM Zcode + GLM 5.3）
各位好，分享下我部機嘅 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
一、硬件配置
項目 配置 主板 華南金牌 H12D-8D V2.0（X99 雙路平台，單路用，2× PCIe 4.0 x16 實測跑滿 16GT/s） CPU AMD EPYC 7K62 48C/96T @ 3.3GHz（單路） 內存 125GB DDR4-2400（4× 32GB SK Hynix ECC），HiCache host 層食咗 ~36GB 顯卡 2× NVIDIA RTX 4080 SUPER 32GB（PCIe Gen4 x16，無 NVLink、無 P2P，TP 走 PCIe + NCCL） 存儲 KIOXIA EXCERIA Basic 1.8TB NVMe 系統 Ubuntu 24.04，NVIDIA driver 595.84 / CUDA 13.2，Docker 部署 網絡 LAN 192.168.0.122 + Tailscale（100.82.33.33，OpenAI-compatible API 尾網直達） GPU 空載 ~185W（cap 320W），52-57C。
二、成個部署點樣搞：GLM Zcode + GLM 5.3 agent
呢部機嘅 SGLang 部署、調校、排查，流程全部係 agent 做：
- 起手俾指令：「幫我部雙 4080S 部署 Qwen3.8-27B-FP8，SGLang，要 256K context，要 HiCache」
- agent 自己拉 image、寫啟動腳本、對齊 param（
--hicache-ratio 2、--page-size 64、--max-mamba-cache-size 32全部係佢測出嚟嘅） - 之後嘅優化全部係 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）
並發 每用戶 總吞吐 1 用戶 65.6 t/s 65.6 t/s 2 用戶 51.7 t/s 103 t/s 4 用戶 44.7 t/s 179 t/s 8 用戶（agent workload） ~27 t/s ~213 t/s scaling 曲線好順：1→4 用戶 aggregate 2.7x，8 用戶見頂 ~213 t/s（PCIe TP + KV pool 限制）。
Prefill
場景 吞吐 1× 32K ~1,930 t/s 2× 32K ~1,950 t/s 4× 32K ~1,970 t/s 1× 128K ~1,530 t/s ~2K t/s 就係呢部機 TP2 嘅硬頂——因為 NVIDIA 封咗 P2P，NCCL allreduce 全部行 host RAM。要突破就得上 NVLink 卡（A6000/H100 級）或者 community hack 4090 驅動（生產環境唔建議）。
TTFT（冷，流式首 token）
Prompt TTFT 128 tok 82ms 2K 1.65s 4K 1.78s 8K 3.63s 16K 7.44s 32K 16.35s 64K 39.0s HiCache 效果（呢部機最大嘅賣點）
場景 冷 命中 加速 50K prompt 重覆 27.8s 2.4s 11.6x 32K prompt 重覆 16.35s 0.51s 32x 5.6K prefix 重覆 2.88s 0.32s（cached_tokens=5568） 8.9x 生產 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 呢個級別都係值得開
六、幾句心得
- 4080 SUPER 32G × 2 跑 27B FP8 + 256K ctx + HiCache 係啱啱好嘅甜點：64G VRAM 再大 10% 都冇咁舒服，29G 模型 + KV pool 374K + MTP 全部塞得入
- Ada 卡做 TP2 嘅真瓶頸係 P2P 被封：GEMM tune 完 +3% 都冇用，allreduce 行 RAM 就係 ~2K t/s 天花板。呢個要買卡之前就知道
- HiCache write_through + direct backend 係 agent 場景正解：prefix 重覆率極高，直接寫穿命中最穩；kernel backend 有 crash bug 唔好碰
- agent 代操係真嘅可行：GLM Zcode + GLM 5.3 做晒 kernel tuning、P2P 排查、參數 A/B，人只需要審 log 拍板。成個調校過程 log 完整可溯源，agent 仲會自己寫 README 記坑——呢個就係本地機 + 本地 agent + 本地模型嘅完整閉環
- 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 長上下文投產方案，歡迎各位大佬補充同指正。
-
现阶段 4080 32gb 价钱只高过3090 一点点
感觉比3090 划算多了
64gb
也不需要nvlink 就有2000prefill@applejuice 不止一点点了， 4080s 32g 也 15000+了
-
@franklee006 非常好的分享，也说明洋垃圾在硬件上是够的。但你用的不是x99平台，是EPYC平台。
@terry 单卡没差别
但是我觉得我们这种双卡跑大模型 平台还是越新越好而且我发现内存 越快也越好
我一开始内存 插错槽
decode/prefill 性能比x99 更差
过后插对槽, decode/prefill 性能立刻提升20-30%
所以内存速度应该有分别@johnnybegood 过分了 甚至主板那些也起价
-
@terry 单卡没差别
但是我觉得我们这种双卡跑大模型 平台还是越新越好而且我发现内存 越快也越好
我一开始内存 插错槽
decode/prefill 性能比x99 更差
过后插对槽, decode/prefill 性能立刻提升20-30%
所以内存速度应该有分别@johnnybegood 过分了 甚至主板那些也起价
