#!/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 的回复也很好，你们继续交流，我没空看，交流好了，有个最优参数我来抄作业。

崩点收敛到 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 上耗配置调参。

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

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

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

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 三个平台的对照了。

之前的 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 长上下文容量不足而无法实际应用的问题。

模型

服务

运行参数

--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

容量 / 显存

Token 性能（历史实测）

链式投机；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。