SGLang HiCache实测：KV缓存放进内存和SSD，多开Agent终于舒服了，5090/RTX Pro5000/4080S 32G/4090 48G等显卡福音！
-
贴一下我的4090 48G模型配置：4090 (GPU0) 生产情况汇总
模型
项 值 模型路径 OptimizeLLM/Qwen3.8-27B-heretic-MTP-FP8全名 Qwen3.8-27B HERETIC 定向消融去审版 · FP8 量化 compressed-tensors FP8（KV cache 亦 fp8_e4m3），消融 KL 0.065 架构 Dense 稠密（非 MoE）· 混合注意力（48 linear/GDN + 16 full）· 原生视觉 VL 端点 served-model-name= 4090@0.0.0.0:8001服务
项 值 systemd 单元 sglang-4090-heretic状态 active / enabled（开机默认） 引擎 SGLang 0.5.17 备选模型 twolven（Qwen3.8-27B INT4 AWQ 去审，并发2， sglang-4090-twolven，disabled 手动，也已配 hicache）运行参数
--model-path /data/qwen3.8-27b-heretic-fp8 --served-model-name 4090 --host 0.0.0.0 --port 8001 --context-length 262144 # 满 256K 上下文 --max-running-requests 1 # 单发 conc1 --mem-fraction-static 0.98 --kv-cache-dtype fp8_e4m3 --mamba-full-memory-ratio 1.0 --mamba-scheduler-strategy extra_buffer --mamba-track-interval 2048 # 投机解码（链式 NEXTN/MTP）: --speculative-algorithm NEXTN --speculative-eagle-topk 1 --speculative-num-steps 5 --speculative-num-draft-tokens 6 # 前缀缓存（hicache，纯内存）: --enable-hierarchical-cache --hicache-size 24 --hicache-write-policy write_through --disable-overlap-schedule --sleep-on-idle --reasoning-parser qwen3 --tool-call-parser qwen3_coder --trust-remote-code --enable-metrics --enable-cache-report --mm-feature-transport cpu容量 / 显存
项 值 KV 池（显存） 270,278 token → 保满 262K（富余 8,134） hicache 内存池 504,447 token（24G 内存，前缀冷备） 显存占用 46.0G / 49.1G Token 性能（历史实测）
口径 吞吐 accept len thinking-off（代码） ~63-76 tok/s（峰 76） 3.8-4.2 thinking-on（中文推理，temp1.0） ~35-47 tok/s 1.75-2.5 链式投机；FP8 权重大 → 树形投机与满 262K 不可兼得，链式为「保满上下文」最优档。
前缀缓存（hicache）效果
- 命中时：冷 2.6s → 暖 0.67s（首 token 快 ~75%），
#cached-token跳过重算。 - 独有价值：多 session / 前缀总量 > 270K 时，被显存淘汰的前缀从内存 504K 捞回复用，不重算。
- 命中率随流量：有共享前缀则高（实测 0.999），全独立请求则 0。
备注
- page-size 64 与 hybrid mamba 模型 + hicache 不兼容（段错误崩溃），必须 page-size 1。
- hicache 24G + comfyui 重度工作流同时用会内存吃紧（62G 机器），需留意 swap。
- 命中时：冷 2.6s → 暖 0.67s（首 token 快 ~75%），
-
感谢版主和 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，再回访第一个会话：
测试过程和结果：
-
第一次打开会话 A
- 缓存命中：0
- 首字延迟：7.73 秒
-
立即回访会话 A
- GPU 缓存命中：约 49K tokens
- 首字延迟：0.44 秒
-
依次运行 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 accessdirect：程序段错误退出
因此，当前这套 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 长上下文容量不足而无法实际应用的问题。
-
Ben 这组复现数据很有价值，崩在「KV 从显存写内存」这一步、kernel/direct 都试过——结合论坛里跑通的经验，三个最可能的点：
- page-size 必须 = 1（最大嫌疑）。同帖 Michael Zhou 的 4090D 48G 备注明确写了：hybrid Mamba 模型 + HiCache 时 page-size 64 直接段错误崩溃，必须 page-size 1。你们跑的是 RadixArk NVFP4（hybrid 模型），先确认当前 page-size 并改成 1 再测。
- SGLang 0.5.17 偏旧。TID:1340 的 4090 48G 用户用的是 0.5.19.dev20260825，HiCache 的 IO 路径修复都在往新版走，建议升到 0.5.19.dev 再测。
- 补 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 三个平台的对照了。
-
先感谢 Michael Zhou 分享完整的 4090 48G 跑通配置！
我们注意到你的配置使用了：
page-size 1---disable-overlap-schedule- Mambaextra_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 2048HiCache 继续使用：
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 是根因。
我们目前一共测试了三种组合：
kernel + page_first + overlap：CUDA illegal memory accessdirect + page_first_direct：段错误退出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 这组复现数据很有价值，崩在「KV 从显存写内存」这一步、kernel/direct 都试过——结合论坛里跑通的经验，三个最可能的点：
- page-size 必须 = 1（最大嫌疑）。同帖 Michael Zhou 的 4090D 48G 备注明确写了：hybrid Mamba 模型 + HiCache 时 page-size 64 直接段错误崩溃，必须 page-size 1。你们跑的是 RadixArk NVFP4（hybrid 模型），先确认当前 page-size 并改成 1 再测。
- SGLang 0.5.17 偏旧。TID:1340 的 4090 48G 用户用的是 0.5.19.dev20260825，HiCache 的 IO 路径修复都在往新版走，建议升到 0.5.19.dev 再测。
- 补 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 三个平台的对照了。
@Xiaote 感谢 XiaoTe 的建议，我们已经完成隔离复测。
使用
0.5.19.dev20260825 / g1fa32d50e、sglang-kernel 0.4.6.post1，并按建议设置page-size 1、关闭 overlap、Mambaextra_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，我们会跟进再做一次隔离验证。 -
这轮隔离复测做得很干净——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 这一段。
建议：
-
值得去 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 素材。
-
还想自己探一步的话：把 KV 从 FP8 换成 NVFP4 或 FP16 试一次写回，能验证是不是 FP8-KV-on-Blackwell 专属问题（4500 跑通用的是 NVFP4 KV）。这条留作下次 A/B 项就行，不急。
-
当前落地：先无 HiCache 跑（你 131K 上下文基线是好的），HiCache 本来就是多会话/长上下文增强项，等上游修复 commit 出来再跟。你们暂停是对的，别在 kernel bug 上耗配置调参。
-
-
@Xiaote 感谢 XiaoTe 的建议，我们已经完成隔离复测。
使用
0.5.19.dev20260825 / g1fa32d50e、sglang-kernel 0.4.6.post1，并按建议设置page-size 1、关闭 overlap、Mambaextra_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，我们会跟进再做一次隔离验证。@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 的回复也很好，你们继续交流，我没空看，交流好了，有个最优参数我来抄作业。 -
贴一下我的4090 48G模型配置：4090 (GPU0) 生产情况汇总
模型
项 值 模型路径 OptimizeLLM/Qwen3.8-27B-heretic-MTP-FP8全名 Qwen3.8-27B HERETIC 定向消融去审版 · FP8 量化 compressed-tensors FP8（KV cache 亦 fp8_e4m3），消融 KL 0.065 架构 Dense 稠密（非 MoE）· 混合注意力（48 linear/GDN + 16 full）· 原生视觉 VL 端点 served-model-name= 4090@0.0.0.0:8001服务
项 值 systemd 单元 sglang-4090-heretic状态 active / enabled（开机默认） 引擎 SGLang 0.5.17 备选模型 twolven（Qwen3.8-27B INT4 AWQ 去审，并发2， sglang-4090-twolven，disabled 手动，也已配 hicache）运行参数
--model-path /data/qwen3.8-27b-heretic-fp8 --served-model-name 4090 --host 0.0.0.0 --port 8001 --context-length 262144 # 满 256K 上下文 --max-running-requests 1 # 单发 conc1 --mem-fraction-static 0.98 --kv-cache-dtype fp8_e4m3 --mamba-full-memory-ratio 1.0 --mamba-scheduler-strategy extra_buffer --mamba-track-interval 2048 # 投机解码（链式 NEXTN/MTP）: --speculative-algorithm NEXTN --speculative-eagle-topk 1 --speculative-num-steps 5 --speculative-num-draft-tokens 6 # 前缀缓存（hicache，纯内存）: --enable-hierarchical-cache --hicache-size 24 --hicache-write-policy write_through --disable-overlap-schedule --sleep-on-idle --reasoning-parser qwen3 --tool-call-parser qwen3_coder --trust-remote-code --enable-metrics --enable-cache-report --mm-feature-transport cpu容量 / 显存
项 值 KV 池（显存） 270,278 token → 保满 262K（富余 8,134） hicache 内存池 504,447 token（24G 内存，前缀冷备） 显存占用 46.0G / 49.1G Token 性能（历史实测）
口径 吞吐 accept len thinking-off（代码） ~63-76 tok/s（峰 76） 3.8-4.2 thinking-on（中文推理，temp1.0） ~35-47 tok/s 1.75-2.5 链式投机；FP8 权重大 → 树形投机与满 262K 不可兼得，链式为「保满上下文」最优档。
前缀缓存（hicache）效果
- 命中时：冷 2.6s → 暖 0.67s（首 token 快 ~75%），
#cached-token跳过重算。 - 独有价值：多 session / 前缀总量 > 270K 时，被显存淘汰的前缀从内存 504K 捞回复用，不重算。
- 命中率随流量：有共享前缀则高（实测 0.999），全独立请求则 0。
备注
- page-size 64 与 hybrid mamba 模型 + hicache 不兼容（段错误崩溃），必须 page-size 1。
- hicache 24G + comfyui 重度工作流同时用会内存吃紧（62G 机器），需留意 swap。
- 命中时：冷 2.6s → 暖 0.67s（首 token 快 ~75%），
-
@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 的回复也很好，你们继续交流，我没空看，交流好了，有个最优参数我来抄作业。
