看到论坛 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

内存分配实测数据

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）

上下文性能预期

建议设 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 上也能装下

但没必要，三个原因：

1. 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）。

2. HiCache 价值被 MTP 吃掉——加 MTP 后 GPU 内存更紧张，HiCache L2 分配空间被压缩，多会话复用的优势打折扣。

3. 社区 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 单卡有几个硬约束：

1. 必须用 NVFP4（FP8 权重太大）
2. 必须用 RadixArk 版（Unsloth 版不兼容）
3. GPU KV cache 只有 ~101K tokens，HiCache L2 是补充不是主力
4. reasoning_parser 必须显式设
5. MTP 投机解码不可用（标准 checkpoint 太大，轻量化版没必要）
6. 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 单卡的话，这个组合已经够用了。