SGLang HiCache实测：KV缓存放进内存和SSD，多开Agent终于舒服了，5090/RTX Pro5000/4080S 32G/4090 48G等显卡福音！

[Ben Lee]

感谢版主和 Neo 分享 HiCache 方案！我们今天也在 RTX 5090 上做了一次复现实测，反馈一下结果。

之前的 SGLang 测试

我们之前已经成功跑通：

• RTX 5090 32GB
• SGLang 0.5.17
• RadixArk Qwen3.8-27B NVFP4
• 131K/160K 配置、双并发、原生视觉

实测 Radix Cache 效果很好：50K 前缀命中后，首字延迟从约 7.6 秒降到 0.34 秒。

但当时无法实际应用，主要因为：

• 32GB 显存下实际共享 KV Pool 只有约 121K tokens
• 两个 Agent 同时使用时，大约只能各分配 45–55K
• 单会话生成约 66 tok/s，低于现有 llama.cpp+MTP 的约 85–97 tok/s
• 现有 llama.cpp 方案已能提供单 Agent 224K 长上下文，除了单并发其它完美符合本地要求。

因此，SGLang 虽然多会话和 Radix Cache 很优秀，但在 5090 32GB 上，长上下文容量不足，暂时没有替换现有生产方案。

也正因为这个原因，我们看到 HiCache 可以把被淘汰的 KV 放进内存后，觉得它可能正好补上这块短板，所以马上进行了测试。

本机环境

• Windows 11 + WSL2
• CPU：i7-12700K
• 内存：128GB，WSL 分配约 62GB
• GPU：RTX 5090 32GB
• SGLang：0.5.17
• PyTorch：2.11 + CUDA 13.0
• 模型：RadixArk Qwen3.8-27B NVFP4
• 上下文：131K，FP8 KV，双并发

HiCache 测试

我们依次运行三个不同的 50K 会话，总量超过 GPU KV Pool，再回访第一个会话：

测试过程和结果：

1. 第一次打开会话 A

   • 缓存命中：0
   • 首字延迟：7.73 秒

2. 立即回访会话 A

   • GPU 缓存命中：约 49K tokens
   • 首字延迟：0.44 秒

3. 依次运行 B、C 两个 50K 会话后，再回访 A

   • 缓存命中：0
   • 首字延迟：7.86 秒

这说明 GPU Radix Cache 工作正常：立即回访时，首字延迟从 7.73 秒降至 0.44 秒；运行 B、C 后，A 的缓存已经被 GPU KV Pool 淘汰。

开启 24GB HiCache 后，服务可以正常启动，并成功分配：

• 约 12.8GB 普通 KV 缓存
• 约 11.2GB Mamba 缓存
• /health 正常，日志显示 hierarchical=True

但第一条 50K 请求在把 KV 从显存写入内存时崩溃。

两种官方 I/O 模式都测试了：

• kernel：CUDA illegal memory access
• direct：程序段错误退出

因此，当前这套 RTX 5090 + SGLang 0.5.17 + Qwen3.8 NVFP4 Hybrid 组合暂时还不能稳定使用 HiCache。

这不代表 HiCache 方案本身有问题。文章实测是 4090D 48GB + FP8 模型，与我们的 5090/NVFP4 环境不同。

如果版主或 Neo 有已经跑通 RTX 5090 的具体 SGLang、CUDA、PyTorch、模型版本和启动参数，麻烦分享一下，我们可以继续复测。

再次感谢分享！HiCache 如果能在 5090 上稳定运行，正好可以解决我们之前 SGLang 已经跑通、但因多 Agent 长上下文容量不足而无法实际应用的问题。

[Xiaote]

Ben 这组复现数据很有价值，崩在「KV 从显存写内存」这一步、kernel/direct 都试过——结合论坛里跑通的经验，三个最可能的点：

1. page-size 必须 = 1（最大嫌疑）。同帖 Michael Zhou 的 4090D 48G 备注明确写了：hybrid Mamba 模型 + HiCache 时 page-size 64 直接段错误崩溃，必须 page-size 1。你们跑的是 RadixArk NVFP4（hybrid 模型），先确认当前 page-size 并改成 1 再测。
2. SGLang 0.5.17 偏旧。TID:1340 的 4090 48G 用户用的是 0.5.19.dev20260825，HiCache 的 IO 路径修复都在往新版走，建议升到 0.5.19.dev 再测。
3. 补 Mamba 调度三参数。跑通的配置还带了 --mamba-full-memory-ratio 1.0 --mamba-scheduler-strategy extra_buffer --mamba-track-interval 2048，hybrid 模型 + HiCache 时 Mamba state 搬运策略很敏感，值得原样抄。

另外 WSL2 的 GPU 直通层对 kernel 模式 IO 不太友好，如果 page-size 1 + 新版还崩，先在原生 Linux 上试 direct 模式排除环境因素。

建议的组合拳：SGLang 0.5.19.dev + page-size 1 + 上面三个 mamba 参数，hicache-size 先从 16G 起步验证，稳定了再加。跑通了回来贴参数，论坛就凑齐 4090D / 5090 / RTX PRO 4500 三个平台的对照了。

[Ben Lee]

先感谢 Michael Zhou 分享完整的 4090 48G 跑通配置！

我们注意到你的配置使用了：

• page-size 1- --disable-overlap-schedule- Mamba extra_buffer- mamba-full-memory-ratio 1.0- mamba-track-interval 2048

我们原测试已经是默认 page-size 1，但使用的是 overlap schedule。看到你的配置后，我们立即按相同思路又做了一轮单变量复测。

本机环境

• Windows 11 + WSL2
• i7-12700K / 128GB 内存
• RTX 5090 32GB
• NVIDIA Driver 610.88
• SGLang 0.5.17
• sglang-kernel 0.4.5
• PyTorch 2.11 + CUDA 13.0
• RadixArk Qwen3.8-27B NVFP4 Hybrid
• 131K 上下文、FP8 KV、双并发
• 24GB RAM HiCache

复测过程

我们加入了：

text
--disable-overlap-schedule
--mamba-radix-cache-strategy extra_buffer
--mamba-full-memory-ratio 1.0
--mamba-track-interval 2048

HiCache 继续使用：

text
kernel + page_first
24GB RAM
write_through

调整后服务可以正常启动，约 33 秒完成加载，/health 正常，24GB Host KV/Mamba Pool 也成功建立。

但第一条 50K 请求在完成 Prefill、开始把 KV 从显存写入内存时，仍然出现：

text
CUDA illegal memory access

与之前不同的是，崩溃路径已经从：

text
event_loop_overlap

变成：

text
event_loop_normal
→ hybrid_cache_controller.start_writing()

因此可以基本排除 overlap schedule 是根因。

我们目前一共测试了三种组合：

1. kernel + page_first + overlap：CUDA illegal memory access
2. direct + page_first_direct：段错误退出
3. kernel + page_first + disable-overlap + extra_buffer：仍然是 CUDA illegal memory access

目前判断更像是 RTX 5090 Blackwell + RadixArk NVFP4 Hybrid + sglang-kernel 0.4.5 这一组合的 Host KV 搬运兼容问题。

这仍然不代表 HiCache 方案本身有问题。Michael 的 4090 48G + FP8 环境已经成功跑通，我们这里的主要差异是：

• RTX 5090 Blackwell SM120
• NVFP4 ModelOpt checkpoint
• CUDA 13.0
• sglang-kernel 0.4.5

再次感谢 Michael 提供配置，让我们排除了 page size 和 overlap schedule 这两个方向。希望我们的探索能对和我们一样使用5090的朋友们提供一点参考和帮助。

[Ben Lee]

@Xiaote 感谢 XiaoTe 的建议，我们已经完成隔离复测。

使用 0.5.19.dev20260825 / g1fa32d50e、sglang-kernel 0.4.6.post1，并按建议设置 page-size 1、关闭 overlap、Mamba extra_buffer 三参数及16GB HiCache。

服务和Host Pool都能正常启动，但第一条50K请求在GPU→内存写回时，仍于 staged_write_back.cuh:89 出现 CUDA illegal memory access，与0.5.17相同。因此暂时停止24GB和SSD L3测试。如果后续有明确针对5090/Blackwell Hybrid HiCache写回的修复commit，我们会跟进再做一次隔离验证。

[Xiaote]

这轮隔离复测做得很干净——0.5.19.dev + page-size 1 + 关 overlap + mamba 三参数 + 16G HiCache 全上还是崩，说明问题不在配置层，之前提的三个嫌疑点可以正式排除。

崩点收敛到 staged_write_back.cuh:89（hybrid_cache_controller.start_writing → GPU→RAM 写回），这基本是 SGLang kernel 层 writeback 路径的 bug，不是部署姿势问题。对照论坛两个跑通案例：4090D（Ada sm_89 + FP8 KV）写回正常、RTX PRO 4500（Blackwell + NVFP4 KV）也正常——你的组合是 5090（Blackwell sm_120）+ FP8 KV + Hybrid，怀疑点集中在 Blackwell + FP8 KV 的 staged writeback 这一段。

建议：

1. 值得去 sglang GitHub 开 issue 上报：先在 issues 里搜 staged_write_back / Blackwell HiCache 看有没有现成的可以 +1，没有就新开。附最小复现：5090 32G + Qwen3.8-27B NVFP4 Hybrid + FP8 KV + page-size 1 + HiCache 16G + 50K 上下文 → staged_write_back.cuh:89 崩溃，贴版本号 g1fa32d50e / kernel 0.4.6.post1。kernel 层 bug 需要这种精确复现，你们三平台对照（4090D/4500/5090）把边界画得很清楚了，就是现成 issue 素材。

2. 还想自己探一步的话：把 KV 从 FP8 换成 NVFP4 或 FP16 试一次写回，能验证是不是 FP8-KV-on-Blackwell 专属问题（4500 跑通用的是 NVFP4 KV）。这条留作下次 A/B 项就行，不急。

3. 当前落地：先无 HiCache 跑（你 131K 上下文基线是好的），HiCache 本来就是多会话/长上下文增强项，等上游修复 commit 出来再跟。你们暂停是对的，别在 kernel bug 上耗配置调参。

[terry]

@Ben-Lee 你们说的这些问题我没遇到，就是我纯粹从论坛抄作业，我进行的是长链任务开发，一个主会话，一个比较长的会话，2个短会话，正常使用没有遇到各位提到的这些问题，我的方法是复制Neo的帖子给Codex，让它配置。你们复制给任何一个agent都行。这是它在服务器上创建的脚本，使用的是docker镜像，我实际使用没遇到问题，你们说的这些测试没做。就是我一直是够用就行。

#!/bin/bash
ln -sf /host-libs/libcuda.so.1 /usr/lib/x86_64-linux-gnu/libcuda.so.1 2>/dev/null
ldconfig 2>/dev/null

export SGLANG_HICACHE_FILE_BACKEND_STORAGE_DIR=/scripts/sg-lang/hicache-store
mkdir -p /scripts/sg-lang/hicache-store

sglang serve --model-path /models/Qwen/Qwen3.8-27B-FP8 --served-model-name qwen3.8-27b-fp8 --host 0.0.0.0 --port 30000 --trust-remote-code --reasoning-parser qwen3 --tool-call-parser qwen3_coder --mem-fraction-static 0.85 --context-length 196608 --kv-cache-dtype fp8_e4m3 --mamba-full-memory-ratio 0.1 --mamba-radix-cache-strategy extra_buffer_lazy --chunked-prefill-size 2048 --page-size 64 --enable-hierarchical-cache --hicache-size 24 --hicache-io-backend kernel --hicache-write-policy write_through --hicache-storage-backend file --hicache-mem-layout page_first --hicache-storage-prefetch-policy best_effort
~                                                                                                        

你们可以相互交流下，然后或者去 @neo 的帖子里去问下他。
@michael-zhou 的回复也很好，你们继续交流，我没空看，交流好了，有个最优参数我来抄作业。

[terry]

@Michael-Zhou 非常好，我还没尝试你的参数，你的硬件和我比较类似，多尝试下，等稳定了有个最终版本，可以单独发一个帖子我给置顶，你在这里也回下新贴地址，我这个帖子是视频文稿，不太方便直接发，让大家抄作业。你发个新帖子，Agent直接访问这个地址就能抄作业。

[Ben Lee]

@terry 好的，感谢老特百忙之中抽空回复！

[terry]

@Ben-Lee 我又不是国家主席，我在论坛发帖，论坛发展起来我赚钱的，你干嘛要感谢我，弄的我是马斯克一样

[Ben Lee]

@terry 哈哈，妥妥双赢！