SGLang HiCache 三层 KV 缓存实测：32GB Blackwell 单卡跑通 Qwen3.8-27B

清风明月

背景

看到论坛 neo 大佬分享的 SGLang HiCache 三层 KV 缓存（VRAM→RAM→NVMe），很感兴趣。核心卖点是：显存里的 KV Cache 放不下时，把暂时不用的 KV "搬到内存/磁盘"，需要时再取回来——重启后 190K 上下文直接加载免 prefill。

我的环境：RTX PRO 4500 Blackwell 32GB + 64GB RAM + X570 主板。之前一直用 llama.cpp 跑 Qwen3.8-27B（Q4 量化，150K ctx，MTP 投机解码）。今天折腾了一下午，把 SGLang HiCache 跑通了，记录一下过程和踩的坑。

结论先行

SGLang 0.5.18 + RadixArk Qwen3.8-27B-NVFP4 + HiCache L2 32GB 在 32GB Blackwell 单卡跑通

关键数据：

模型权重：20.14 GB（NVFP4）
GPU KV cache：101K tokens（fp8，~3.1GB）
HiCache L2：32GB host RAM
系统总内存占用：~46GB / 64GB
推理正常，reasoning_effort 可调

踩坑记录（重要）

坑1：Unsloth NVFP4 不兼容 SGLang

Unsloth 的 NVFP4 用 compressed-tensors 格式 + FP8 lm_head，SGLang 加载报错。必须用 RadixArk/Qwen3.8-27B-NVFP4（NVIDIA Model Optimizer/modelopt 格式）。

hf download RadixArk/Qwen3.8-27B-NVFP4 --local-dir ~/models/sglang/Qwen3.8-27B-NVFP4

坑2：reasoning_parser 必须显式设

不加 --reasoning-parser qwen3 的话，thinking 标签会残留在 content 里，reasoning_content 字段为 None。加了之后正确分离：

reasoning: "The user said hi - a simple greeting..."
content: "Hi there! How can I help?"

完整部署步骤

1. 安装 SGLang

python3.12 -m venv ~/.sglang-venv
source ~/.sglang-venv/bin/activate
pip install --upgrade pip && pip install uv
uv pip install --prerelease=allow sglang

2. 下载模型

hf download RadixArk/Qwen3.8-27B-NVFP4 --local-dir ~/models/sglang/Qwen3.8-27B-NVFP4

约 21GB，3 个 safetensors 分片。

3. 启动命令

python -m sglang.launch_server \
  --model-path ~/models/sglang/Qwen3.8-27B-NVFP4 \
  --served-model-name qwen3.8-27B-NVFP4 \
  --host 127.0.0.1 --port 8000 \
  --enable-hierarchical-cache \
  --hicache-size 32 \
  --tp 1 \
  --mem-fraction-static 0.85 \
  --max-running-requests 1 \
  --context-length 131072 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder

参数说明：

--hicache-size 32：L2 缓存分配 32GB host RAM
--context-length 131072：128K 上下文上限
--mem-fraction-static 0.85：GPU 内存分配比例
--reasoning-parser qwen3：分离 thinking 和 content
--tool-call-parser qwen3_coder：支持工具调用

4. systemd 服务

[Unit]
Description=SGLang Qwen3.8-27B-NVFP4 with HiCache L2/L3 KV Cache
After=network.target

[Service]
Type=simple
WorkingDirectory=%h
ExecStart=%h/.sglang-venv/bin/python -m sglang.launch_server \
  --model-path %h/models/sglang/Qwen3.8-27B-NVFP4 \
  --served-model-name qwen3.8-27B-NVFP4 \
  --host 127.0.0.1 --port 8000 \
  --enable-hierarchical-cache --hicache-size 32 \
  --tp 1 --mem-fraction-static 0.85 --max-running-requests 1 \
  --context-length 131072 \
  --reasoning-parser qwen3 --tool-call-parser qwen3_coder
Environment=CUDA_VISIBLE_DEVICES=0
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=default.target

内存分配实测数据

组件	大小
模型权重 (NVFP4)	20.14 GB
Mamba SSM state	2.67 GB (18 slots)
Mamba conv state	0.05 GB
KV Cache (fp8, 101K tokens)	3.10 GB
GPU 剩余	~4.69 GB
HiCache L2 (host RAM)	32 GB
系统总占用	~46 GB / 64 GB

HiCache 的实际价值

坦白说，HiCache 在单用户场景下最大的价值不是"跑更大上下文"，而是多会话 KV 复用免 prefill。

GPU 上直接跑 ~101K tokens（全速）
超出部分由 HiCache L2 从 RAM 换入（有延迟）
重启服务后，之前的 KV 从 L2 恢复，不用重新 prefill
多会话切换时，不活跃会话的 KV 换到 RAM，活跃的留在 VRAM

对比 llama.cpp 的 150K 全 VRAM 方案：

llama.cpp 速度更快（全在 GPU 上，零搬运延迟）
SGLang HiCache 胜在会话复用（重启免 prefill）

上下文性能预期

上下文范围	性能
<101K tokens	全速（KV 全在 GPU）
101K-128K	HiCache L2 换入，decode 有额外延迟
128K+	明显变慢（每步 PCIe 搬运 ~100ms+）

建议设 128K 上限，日常控制在 100K 以内。

NVMe L3 缓存

L3（NVMe 磁盘缓存）在命令里加 --hicache-storage-backend file 即可开启。实测 NVMe 顺序读 ~3.5-7GB/s，延迟 ~100μs，对 decode 来说太慢了——从 NVMe 取 KV 做 prefill 比直接重算慢不了多少，实际价值有限。L2 RAM 缓存才是重点。

MTP 投机解码可行性分析

有人会问：SGLang 能不能也上 MTP 加速？答案是32GB 单卡上标准版不行，但有专门的轻量化 checkpoint 可以。

为什么标准 RadixArk 版不行

RadixArk 版权重 20.14GB，GPU 剩余 ~4.69GB。MTP 额外需要：

Draft KV cache: ~0.3-0.5 GB
Draft Mamba state: ~0.15 GB
MTP head 权重: ~0.1 GB
总计: ~0.5-0.75 GB

理论上 4.69GB 够放，但实际上 Unsloth 官方明确说了：

"SGLang 0.5.18（NEXTN/MTP 在 32 GB 上无法有效适配）。在 32 GB 下，额外尺寸会占用 KV pool，因此无法容纳原生 256k。"

根因是 MTP 会和 HiCache 的内存分配冲突——HiCache 需要预留 host memory pool，MTP 需要额外的 draft model 状态，两者抢同一块剩余空间。

gittensor 优化版：技术可行但没必要

社区有人（gittensor-model-hub）做了一个专门适配 RTX 5090 32GB 的优化 checkpoint：

权重压到 ~18.8GB（比标准版小 1.3GB）
配合 DSpark 推测解码，RTX 5090 上跑到 180 tok/s
理论上在你的 RTX PRO 4500 上也能装下

但没必要，三个原因：

llama.cpp 已经有 MTP 了——我的标准版 UD-Q4_K_XL + MTP n=2 跑到 67 t/s，这是验证过的稳定方案。SGLang + MTP 在 896 GB/s 带宽上不会更快（RTX 5090 1792 GB/s 才能跑到 180 t/s）。
HiCache 价值被 MTP 吃掉——加 MTP 后 GPU 内存更紧张，HiCache L2 分配空间被压缩，多会话复用的优势打折扣。
社区 checkpoint 质量不确定——gittensor 不是官方也不是大厂，模型质量和长期维护都不确定。你之前定的铁律是"模型必须官方源版本"。

结论

32GB 卡上 SGLang + NVFP4 的最优定位就是多会话 KV 复用，不追求 MTP 加速。MTP 投机解码留给 llama.cpp（那边已经验证稳定）。

两者互补：

llama.cpp + GGUF + MTP：日常推理主力（67 t/s，稳定）
SGLang + NVFP4 + HiCache：多会话 KV 复用（~55 t/s，重启免 prefill）

社区实测对比（来自抡锤者论坛）

论坛版主 Terry 用 4090D 48GB 跑了类似方案，形成直接对比：

维度	Terry (4090D 48GB)	本机 (RTX PRO 4500 32GB)
模型格式	FP8 (28.5GB)	NVFP4 (20.1GB)
HiCache L2	24GB（64GB 系统不够开 32）	32GB
GPU KV	270K tokens	101K tokens
上下文	262K（满配）	128K
MTP	NEXTN 5步/6draft	无
性能	63-76 t/s (thinking-off)	~55 t/s

关键发现：

32GB 卡红利最大：Terry 原话"对于 32G 显存的卡，开内存缓存意义非常重大"——因为 FP8/NVFP4 权重加载后显存所剩无几，HiCache 让 KV 有地方放
HiCache 有性能代价：论坛用户折騰实测开 --hicache-size 后 tok/s "掉得太厉害，直接打折"——RAM 换入延迟不是无感的
48GB 可以 MTP + HiCache 全开：Terry 4090D 上 MTP accept len 3.8-4.2，同时 HiCache 24GB，但 32GB 卡两者只能二选一

总结

SGLang HiCache 是个不错的方案，但 32GB 单卡有几个硬约束：

必须用 NVFP4（FP8 权重太大）
必须用 RadixArk 版（Unsloth 版不兼容）
GPU KV cache 只有 ~101K tokens，HiCache L2 是补充不是主力
reasoning_parser 必须显式设
MTP 投机解码不可用（标准 checkpoint 太大，轻量化版没必要）
HiCache 有实测性能代价（tok/s 会打折），核心价值在多会话复用而非速度

32GB 卡的最优组合：llama.cpp + GGUF + MTP 做日常推理（67 t/s），SGLang + NVFP4 + HiCache 做多会话 KV 复用（重启免 prefill）。两者互补，不互相替代。

48GB 卡（4090D/RTX Pro 5000）可以全开：FP8 + MTP + HiCache + 262K 上下文，体验接近在线模型。

如果你有 48GB+ 的卡，HiCache 的价值会更大——更多 KV 留在 GPU 上，L2 作为冷备，MTP 也能跑得动。32GB 单卡的话，这个组合已经够用了。

terry

非常好的分享，我没加MTP，可以补上，50系列的卡有NVFP4，其实40系列跑4比特量化版本也很好。FP8还是有点不划算，但我搭配了Hicache用着也还行。

ran z

请教一下，20.14 GB（NVFP4）直接塞显存就行了，为啥还要搞HiCache呢？只是可用多会话吗？谢谢！

清风明月

@ran-z HiCache 的实际价值
坦白说，HiCache 在单用户场景下最大的价值不是"跑更大上下文"，而是多会话 KV 复用免 prefill。

GPU 上直接跑 ~101K tokens（全速）
超出部分由 HiCache L2 从 RAM 换入（有延迟）
重启服务后，之前的 KV 从 L2 恢复，不用重新 prefill
多会话切换时，不活跃会话的 KV 换到 RAM，活跃的留在 VRAM
对比 llama.cpp 的 150K 全 VRAM 方案：

llama.cpp 速度更快（全在 GPU 上，零搬运延迟）
SGLang HiCache 胜在会话复用（重启免 prefill）

ran z

【比着葫芦画葫芦失败】SGLang 0.5.18 + Qwen3.8-27B-NVFP4 在 WSL2 上 decode 崩溃（mrope CUDA illegal memory access），通过dsh由deepseek v4 flash处理，结果失败，请楼主指点
环境
项目详情
硬件：i9 14900k 192G ddr5 RTX 5090
系统 Windows 11 + WSL2，NVIDIA 驱动 610.74（WDDM 模式）
框架 sglang 0.5.18（发帖时为最新版，PyPI / tuna 上无 0.5.19+）
模型 RadixArk Qwen3.8-27B-NVFP4
现象
decode 阶段 CUDA illegal memory access，崩在 _compute_mrope_positions_decode（vision token 的 3D 位置编码路径）。纯文本输入也会崩，可稳定复现。

已排除项（逐项对照过楼主参数）
楼主（原生 Linux + systemd + RTX PRO 4500）的完整启动参数我已全套对齐复测，仍崩在同一位置：

--hicache-size 32 --mem-fraction-static 0.85 --max-running-requests 1 --context-length 131072 --reasoning-parser qwen3 --tool-call-parser qwen3_coder
参数逐项调过：hicache-size 96→32、mem-fraction-static 0.60 / 0.72 / 0.85，均无效
进程保活（setsid）无关；缺 libssl（JIT 链接）无关
--language-model-only：sglang 目前只支持 MuseGlimmer，对本模型不可用
根因（已锁定）
模型自带 README 写明：

"Dense Multimodal … Input Type(s): Text, image, and video"
"Attention weights use FP8, while MTP and vision tensors retain the source BF16"
"Preferred Operating System(s): Linux"
即 config 带 vision: true，sglang 0.5.18 将其按多模态模型处理，decode 走 mrope 路径。楼主原生 Linux 环境走这条路径不炸；WSL2 + WDDM 驱动下同一路径直接崩。这是环境差异，参数抄得再准也绕不过去。

我看到的三条路
升级 sglang（>0.5.18）：修复多模态 mrope decode——目前不可行，0.5.18 就是已发布最新版（0.5.19 / 0.6.0 / 0.5.20 均不存在），只能等上游发版
换纯语言版 checkpoint：找一个无 vision_config 的 Qwen3.8-27B NVFP4/FP8，sglang 就不会走多模态 mrope decode——当前 WSL2 上最可行
原生 Linux 跑：README 官方支持的 OS，但成本高（需双系统或其他 Linux 机器）
想请帮忙的
有没有无 vision 的 Qwen3.8-27B NVFP4 / FP8 checkpoint？RadixArk 或社区是否出过纯语言版？
有没有人在 WSL2 上跑多模态 sglang 踩过同样的 mrope 崩溃？有 workaround 吗（除了换环境）？
上游 sglang 有没有已知计划修多模态 mrope decode？
现状
先用 llama.cpp 顶着：Q5_K_P + 262K ctx（llama-server 监听 8080），稳定可用；SGLang HiCache 方案等上述解法落地后再开。

iamvirus

期望27b看到10-32-64-90-128K下的prefill速度和nomtp速度。这样才有参考意义！这个单卡prefill应该击败双r9700，现在双r9700 FP8 VLLM 10k-3000 90K-2000+的速度了，跑agent的subgent已经很有生产力了。

Xiaote

@ran-z 这个崩点我查了 SGLang 的 issue 库，属于已知 bug 类别，不是配置问题——你的排查方向没错，别再抠参数了。

同类报告：

sgl-project/sglang #13060：Qwen3-Omni 在 _compute_mrope_positions_decode 同点崩溃 = SGLang 解析 M-RoPE（3D 位置编码）配置的已知问题，纯文本也崩是正常的（跟视觉 token 无关）
#30055：Qwen3.5 + HiCache 触发 CUDA illegal memory access——你开着 --hicache-size 32，正好踩这个组合
#19383：Qwen3.5-397B-A17B-NVFP4 TopKTopPSampling 崩 = NVFP4 kernel 专属 bug 类别

按顺序二分定位（每次只动一个变量）：

先关 HiCache（去掉 --enable-hierarchical-cache 或 --hicache-size 0）——#30055 就是 HiCache 路径触发的；关了不崩 = 锁定 HiCache 与 mrope 的交互，等 SGLang 修复，别硬刚
换 FP8 权重（RadixArk 有 FP8 版）——NVFP4 kernel 覆盖差（#19383 同族），FP8 稳得多，Qwen3.8 FP8 跑 SGLang 论坛里成功案例一堆
升级 SGLang 到 main 分支或最新 release——PyPI/tuna 的 0.5.18 是"发帖时最新"，mrope/HiCache 修复基本都在 main 或 0.5.19+；用官方镜像 lmsysorg/sglang:latest 最省事
还崩就加 --disable-cuda-graph 试（WSL2 上 CUDA graph 捕获偶发 illegal access 是老坑）

最后提醒：楼主是在原生 Linux 跑通的，你在 WSL2——SGLang 这种服务端推理在 WSL2 上本身多一层兼容风险（共享内存、CUDA graph）。上面 4 步都不行，双系统/原生 Linux 跑同配置是终局验证：原生不崩 = 锁死 WSL2 环境问题，别在 WSL2 上继续耗。

清风明月

@ran-z 我之前也曾经在WIN11上试过，有各种限制，所以后来把操作系统换成桌面版ubuntu26.04 LTS了，这点属于环境不同，可能结果也不同，你可以换这个操作系统试，不用担心不会用，我在操作系统里的所有操作都可以让hermes给我完成。现在感觉比win11要好用多了。

imbiplaza ASUS

我都是用非nvfp4,win11
重度用家。。。

清风明月

@ran-z ● 介绍下你自己
Initializing agent...

────────────────────────────────────────
─ Hermes ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

我是你的个人 AI 助手，跑在本地 Qwen3.8-27B（llama.cpp，4500 显卡，67 t/s）。

核心能力：

日常事务：文件管理、系统运维、下载/安装、网络配置
代码工作：写/改/调试，复杂项目委托 OpenCode 执行
创作：小说（Dramatica-Flow 完整管线）、AI 视频（ComfyUI + H3）、AI 音乐
基础设施：两台 VPS 管理（cc/bwg，1Panel + 证书 + 部署）
记忆系统：Mnemosyne 本地持久记忆 + Upstash 云端备份，跨会话保持上下文

工作风格：你拍板我执行，不废话不绕弯，实测验证不猜。

有什么要干的？
────────────────────────────────────────
● 显示本机软硬件环境
────────────────────────────────────────

┊ $ echo "=== CPU ===" + 26 commands 0.3s [exit 1]
┊ $ lscpu | grep "型号名称" + 3 commands 0.1s
─ Hermes
硬件

CPU: AMD Ryzen 7 3700X 8核 (3.6/4.4 GHz)
内存: 64GB DDR4 (60Gi 可用) + 127Gi Swap
GPU: NVIDIA RTX PRO 4500 Blackwell 32GB GDDR7
驱动 595.84, 当前占用 25.9GB, 93% 利用率, 51°C
主板: Gigabyte X570 GAMING X

存储

系统盘: NVMe 1.8TB (LVM) 已用 261G / 1.5T 可用 15%
数据盘: NVMe 938GB /mnt/ssd1 已用 538G / 353G 可用 61%
RAID: md0 RAID1 1.8TB /mnt/raid1 已用 586M 1%

系统

OS: Ubuntu 26.04.1 LTS, kernel 7.0.0-30-generic
主机名: aqbjqtd-X570-GAMING-X
Python: 3.14.4
Docker: 29.1.3
CUDA: 12.9 (编译) + 13.3 (运行时, ComfyUI 用)

ran z

懂了，得换系统才能跑，目前win11+wsl2的方案看来还是白费。
感谢楼主！
屏幕截图 2026-09-01 141900.png

imbiplaza ASUS

现在升级了llm46fan 大大的模型，win11 重度用户

清风明月

@imbiplaza-ASUS 不客气！