聊MinIO搞MemKV，我觉得行业关注点歪了。大家盯着速度，但其实最该想的是：KV Cache这东西，压根就不该当成文件存。

有个挺魔幻的现状，不知道你们发现没？

都在喊GPU贵、HBM紧、显存墙。但钱花得最冤的地方，往往不是算力不够，而是GPU在反复干同一件事——把昨天刚算过的上下文，再算一遍。

NVIDIA搞CMX、MinIO跟MemKV，其实都在打同一个痛点——我管它叫“重算税”。

我们把“上下文记忆”放错地方太久了

Transformer推理里，上下文就是KV Cache。你不存，后面续写就得重跑全量历史；你存，就得占地方。

理想情况是住HBM，最快。但HBM寸土寸金，权重、激活、Batch调度都得抢。上下文一长、并发一高，KV Cache第一个被踢出去。

实际落地时，大家基本就在三种烂摊子里凑合：

1. 挤在节点内（G2/G3）：

放DRAM或本地NVMe。快是快，但任务一调度，上下文没跟上，还是得重算。而且本地NVMe也没便宜到哪去。

2. 丢去共享存储（G4）：

对象存储、NAS。能共享，但延迟受不了。这些协议本来是为“持久化数据”设计的，你现在拿它去喂一个几MB、马上就要decode的请求？路径太长，抖动能让你怀疑人生。

3. 干脆重算：

最省心，但也最烧钱。买的GPU周期，一半在帮模型“回忆往事”。

所以NVIDIA才在G3和G4之间插了一刀，搞了个G3.5（CMX/ICMS）。说白了，就是专门给这些“用完就可能扔、但又不能没有”的上下文，弄个Pod级的Flash池子。

MinIO MemKV 狠在哪？它敢做减法

MinIO给MemKV的定义很狠，翻译过来就三层意思：

第一，它认死理，KV Cache就是临时块数据，不给你套对象存储的壳；

第二，共享是底层做的，不用上层拿scp瞎折腾；

第三，目的很直接，就是为了省GPU钱，少空转，少烧电。

不过说句实在话，我在存储圈踩过坑，得提醒一句：减法做得越狠，复杂度转移得越隐蔽。

没有文件系统、没有对象头，意味着你得自己搞定这些：

• 容量水位和反压（池子满了别把在线业务搞挂了）；

• Eviction的可观测性（别在半夜莫名其妙触发重算尖峰）；

• 认证和网络隔离（薄不代表不用管安全）。

别神化G3.5，也别神话某款实现

我看这事就两点：

KV Cache池化、跟GPU解耦，这是大方向，不追不行。尤其是Agent多步推理起来后，长上下文是标配。

但有两个限速器：

1. 硬件节奏： BlueField-4的出货和平台成熟度，决定了你啥时候能上生产。预览期怎么吹都行，Rollout别赌供货。

2. 团队兜底能力： 你拿到的是“快搬运”，但还得配TTL、配额、隔离、监控。不然这玩意儿分分钟从性能利器变成故障放大器。

这也正是我们在RustFS上看到的趋势

我不去硬蹭DPU那套，但RustFS这边看到的趋势一模一样。

当存储开始侵入推理关键路径，大家对软件的期待就从“功能全”变成了“路径薄、抖动小、没惊吓”。

Rust给我的底气不是玄学，是把内存安全和并发坑，在编译期就拦住。这对你要跑一个7x24小时、低抖动的存储组件来说，是实打实的运维红利。

加上现在NVMe和RDMA用户态化，少一层抽象，GPU就拿数据快一层。不管叫不叫G3.5，这都是下一代存储该走的路。

最后说点实际的

如果你那边GPU利用率上不去，首字延时还抽风，又不敢随便缩TTL，别急着加卡。

先把这四件事画清楚：

放哪、怎么共享、怎么淘汰、怎么度量。

至于用MemKV、自研轻池，还是RustFS这种路子，看你团队对DPU生态的掌控力，以及你对关键路径稳定性的偏执程度。

感兴趣的，直接去GitHub拉代码跑Demo，拿你们自己的Trace压一遍。比看一百张架构图都管用。

(注：RustFS 目前处于 Beta 阶段，官方消息是预计7月份发GA版。)

---

以下是深入学习 RustFS 的推荐资源：RustFS

官方文档： RustFS 官方文档- 提供架构、安装指南和 API 参考。

GitHub 仓库： GitHub 仓库 - 获取源代码、提交问题或贡献代码。

社区支持： GitHub Discussions- 与开发者交流经验和解决方案。

​