背景
看到论坛 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 单卡的话，这个组合已经够用了。
最重要机制：125B 是怎么塞进 32GB 显存的
晚间更新：agent 对打补测 + 原主力退役
️ 为什么选 IQ2_XS 而不是更高质量的 IQ3_S？——内存。60GB 机器上的安全档是 IQ2_XS（专家 35.5GB）；IQ3_S 的 50GB 专家 + 系统会让 64GB 机器贴边。如果你有 96GB+ 内存，直接上 IQ3_S（质量更高，速度低一档）。社区有人实测过：更激进的量化（IQ3_S→IQ3_XXS）快 14-23%，但输出 token 是 2.7 倍（过度思考、反复返工），端到端反而慢 2.4 倍——所以别只看压缩率。
灶台（VRAM 32GB）
储物柜（SSD）
我这张卡能跑到 5090 之上，解释一下：32GB 显存对 IQ2_XS 这个体积的模型"缓存命中率"极高（95-99%），而 IQ2_XS 本身又是最轻的档——两个因素叠加。5090 那台跑的是同一量化但上下文策略不同。
结论：跨境的锅别让工具背。测速 → 换源 → 校验（SHA256 对齐官方），比折腾多线程参数高效得多。
