抡锤者

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

@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，我们会跟进再做一次隔离验证。

先感谢 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的朋友们提供一点参考和帮助。

感谢版主和 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 长上下文容量不足而无法实际应用的问题。