过去的一周我一直在折腾HiCache L3在7900XTX里的实现问题：

能不能让 Qwen 这类 Hybrid 模型，把长期不用的上下文从显存 / 内存下沉到 NVMe SSD，需要时再恢复回来？也就是让HiCache的L3真正发挥作用。但是目前的状况是L3只写不读，功能失效。

我的目标其实很简单：

显存贵，DDR5 也越来越贵，SSD 相对便宜。

如果能把SSD拉入KV池的媒介列，然后把缓存做成：

VRAM → 小量 RAM 缓冲 → 大容量 NVMe

那么多 Agent、长上下文的本地推理成本会低很多。这意味着什么？随着AI模型的进步，模型给定的上下文可能越来越多，显存要求也越来越大。但是众所周知显卡和内存目前的价格有多离谱和疯狂，如果能用相对便宜的SSD提供替代解决方案，那么就给很多目前受限制的个人消费级PC提供了新的可能。

我个人觉得这个思路像“混合硬盘”：

快的介质做缓存，慢但便宜的大容量介质做仓库。

只是这里存的不是普通文件，而是模型的 KV Cache 和 MAMBA / Linear Attention 状态。

但是，目前卡在了SGLang的HiCache L3这一步。@enigma 大佬在他的含金量很高的帖子 https://lcz.me/topic/1620 里也碰到了和我一摸一样的问题，L3只写不读。

我花了大概一个星期时间，烧了几十亿Token（不算本地算力），感觉几乎走到了最后一步，虽然不成功，但是想记录下来，给感兴趣的人分享一下过程和思路。

一、我们的环境（我们=我和我的AI Agent）

测试平台：

• 2 × RX 7900 XTX 24GB
• ROCm 7.x
• SGLang
• Qwen Hybrid 模型
• TP=2
• GPTQ 4bit
• File backend 作为 L3 / NVMe cache

这个环境本身就有一点特殊。

SGLang upstream 后来逐步淘汰了旧 GPTQ 路径，原因也很好理解：

软件要往前走，就要不断简化旧代码、适配新的硬件和新的量化后端。

问题是，7900 XTX / RDNA3 恰好还依赖这条老 GPTQ 路线。

所以不是 RDNA3 kernel 不能跑，而是 upstream “轻装上阵”时，把这条 legacy 路径一起拿掉了。

最后我们确认：

底层 gptq_gemm_rdna3 kernel 其实还在，只是 Python 注册、白名单和旧 GPTQ dispatch 被移除了。

把这部分接回来以后，latest main 可以重新在 7900 XTX 上启动 GPTQ。

事实上，从某个以前的版本上找到适配模块，也确实嫁接成功了。

二、旧版本为什么 L3 一直跑不通

我们最早是在较老的 SGLang 版本上做 HiCache。

L1 / L2 都能正常工作：

GPU → RAM → GPU

MAMBA state 也可以正常写进 SSD。

问题出在真正的 L3 restore。

旧架构里：

Host cache node 被淘汰以后，会被直接从 radix tree 删除。

于是出现一个很尴尬的情况：

SSD 上的数据还在，
但是指向它的 node / metadata 已经没了。

结果就是：

数据在 SSD 上，但新请求已经不知道该去哪里找它。

我们把这个问题称为：

L3 payload orphan

这也是旧路线最后的结构性 blocker。

三、latest main 出现了一个非常关键的新设计：buffer_only

后来我重新看 SGLang 最新 main，发现 upstream 已经换了思路。

新增的 buffer_only 模式，本质上就是：

RAM 不再承担完整 L2 Cache，
只做 GPU SSD 之间的临时 staging buffer。

也就是说，架构从：

GPU → 大 RAM Cache → SSD

变成更接近：

GPU → 小 RAM staging → SSD

这正好符合我们最开始的目标。

更重要的是：

它不再依赖 Host node 长期存活。

所以旧版本那个 “Host node 一删，SSD payload 变孤儿” 的问题，被新架构绕过去了。

四、MAMBA 居然真的走到了 L3 restore

这部分是这几天最大的突破。

我们已经实测证明：

• MAMBA 可以写进 L3
• storage key 正确
• L3 read 命中
• Host staging 正常
• MAMBA payload 可以 H2D
• device slot 可以 commit
• server 不再像旧版本那样直接崩

一度我们甚至拿到了完整的链路：

L3 key
→ Host staging slot
→ Device slot
→ MAMBA commit
→ Decode

这已经说明：

MAMBA 并不是“完全不能做 L3”。

真正的问题已经缩到最后一层。

五、最后卡在哪里？

最后经过大量 trace，我们把问题压到了一个非常具体的位置：

Node Identity Split

同一个 request：

• prefix match 认为自己挂在旧 node，例如 node 19
• L3 restore 后，MAMBA payload 被 materialize 到一个新 node，例如 node 32
• payload 在 device slot 27
• 但 decode 最后使用的是另一个 slot，例如 slot 28

也就是说：

数据恢复成功了，但 request 仍然握着旧的“身份”。

恢复后的新 node 和 request 当前 anchor 没有重新对齐。

简单说就是：

仓库把货送回来了，
但系统把货放到了新货架，
而取货单还指向旧货架。

这已经不是简单的 memcpy、slot clear 或同步问题了。

它开始涉及：

• radix node identity
• request re-anchor
• scheduler admission
• MAMBA CoW / handoff

也就是从“小修 wiring”进入了架构语义层。

六、所以最后我们选择停手

我们一开始给自己定了一个原则：

优先找最短路径。
如果只是几个局部 wiring bug，就修。
如果开始进入 scheduler / radix tree / request lifecycle 的重构，就停。

现在正好到了这个边界。

所以最终结论不是：

“失败了。”

而是：

我们已经证明 latest main 的 buffer_only 架构，确实可以把 Hybrid 模型的 MAMBA state 推到 NVMe L3 restore 的最后一公里。

真正还缺的是：

L3 restore 后，request-side node identity 如何重新和 materialized node 对齐。

七、这件事为什么值得继续关注

我觉得这个方向对本地 AI 很有价值。

未来模型上下文从 256K 走到 512K、1M，并不奇怪。

但显存和大容量 DDR5 都很贵。

如果 cache hierarchy 能真正变成：

VRAM
↓
小量 RAM staging
↓
大容量 NVMe

那么多 Agent 长期共存会现实很多。

尤其是 4 卡、8 卡、本地工作站这类机器：

计算能力可能够，
真正限制多 Agent 的反而会变成上下文驻留成本。

所以我很看好 L3 / NVMe cache 这条路线。

当前最终状态

已经验证：

• 双 7900 XTX + latest SGLang main
• GPTQ RDNA3 路径恢复
• Hybrid FULL + MAMBA
• buffer_only
• MAMBA L3 write
• MAMBA L3 read
• Host staging
• H2D
• device commit
• 双请求 ownership
• abort / cleanup
• 85 分钟 soak
• 无资源泄漏

最后剩余 blocker：

L3 restore 后的 node re-anchor / identity handoff

所以暂时收工。

如果 upstream 后续补上 MAMBA buffer_only 的 re-anchor / state handoff，这套东西很可能就真的能完整闭环。

届时我会继续回来测试。

即使L3不工作，但是在上一篇帖子里我介绍了， 我目前7900XTX双卡在SGLang+HiCache L1/L2 上跑Hermes双Agent 256K 上下文非常流畅丝滑，几乎不输云端模型体验。具体技术细节，推荐大家参考 https://lcz.me/topic/1620 里面干货满满。