GPU 不再重复读取文本：比利时初创公司 Corbenic 将 SSD 转化为 AI 内存，14 倍加速源于减少读取
进入一个对手众多的市场
Corbenic 公布这一消息的时机堪称完美：随着数据中心预计在 2026 年吞掉超过 70% 的高端内存芯片，让现有硬件榨出更多性能无疑很有吸引力。但 Corbenic 自己的论文显示，其宣传的 14 倍加速更多来自少读文本，而非加载缓存。而且这个领域里，Nvidia、Phison 和一个资金充裕的开源项目早已提供了类似方案。 Galahad 的做法略有不同：在标准推理服务中，模型回答关于某文档的第二个问题时，会从第一个 token 开始重新计算该文档的注意力状态，这一步叫做 prefill。vLLM、SGLang 等引擎在注意力状态还在 GPU 内存中时已经会复用它，但 Corbenic 的论文指出，一旦内存吃紧，这些状态就会被清除，进程重启后也会丢失。 Galahad 的 KV 组件 Taliesin 会把每段文本的状态写入磁盘，并以其精确输入字节、模型和租户的指纹作为索引，当同样的字节再次出现时就直接加载。Schelpe 强调，只有在 GPU 内存被清空或服务器重启后，存储的副本才会发挥作用。“所以选择不是在 SSD 和 RAM 之间，而是在 SSD 和让 GPU 重新计算所有内容之间，”他告诉 TechRadar Pro，并补充道，这种加载“只发生一次，在回答的第一个字之前。”
他主动指出了两个限制：短文本不会被存储，因为重新计算它们本身已经很快；而网络存储比本地 NVMe 驱动器慢得多。论文在此基础上设定了一条故障关闭规则：“没有内存就服务，绝不用错误的内存服务”，因此任何未能通过检查的记录都会被简单地重新计算。
据 Schelpe 称，不需要特殊硬件，只需 Linux、一张 Nvidia GPU 和一块标准的 NVMe SSD。被问及 CXL 时，他说：“我们尝试过更快的存储，但它并没有让 Galahad 变得更快，”这与论文中 H100 的测试结果一致，在该测试中，RAM 磁盘和本地磁盘提供了近乎相同的吞吐量。
对于 Phison 的 Pascari 等企业级驱动器，其制造商一直在宣传闪存有 AI 内存瓶颈的解决方案，他对此态度谨慎：“我们还没有测量过它们，所以我不会引用具体数字。”
Schelpe 告诉 TechRadar Pro，从快速 SSD 加载存储的状态比重新读取“快得多”，而这“正是我们 14× 加速的来源：在 vLLM 上每个问题耗时 0.59 秒。” 论文本身的表格讲述了一个更复杂的故事。
0.59 秒的结果来自一项召回测试，其中 100 个事实隐藏在 96,726 个 token 的列表中，运行于 Gemma 4 31B 上，并使用了 Taliesin 和 Blaise。Blaise 是第二个组件，它将文档作为文本保存，并向模型仅提供问题所需的片段，大约 668 个 token 而不是整个语料库。论文本身将 llama.cpp 上的收益从 3.1 倍提升到 14.5 归功于 Blaise。
单靠 Taliesin 还不够。vLLM 每道题耗时 15.56 秒，比 8.11 秒的基准测试更慢；SGLang 则是 22.02 秒，远逊于 10.29 秒的基准。只有 llama.cpp 在单独使用 KV 缓存复用时取得了提速，从 9.25 秒降至 3.01 秒。这些对比在两个方向上都存在严重失衡：基准测试使用的是 12,000 token 的窗口，仅能看到语料的最后 12%，且只回答了 100 题中的 10 题；而 Taliesin 让模型关注全部内容，回答了 98 题。
Schelpe 将 Galahad 置于检索增强生成（RAG）流程的对立面，例如 RAGFlow，后者将文档切块，并将检索排名最高的片段传给模型。“当检索失误时，模型根本看不到答案，”他说，并引用了一项基准测试作为佐证：Galahad 答对了 100 题中的 100 题，而 RAGFlow 只答对了 77 题。
面对 TechRadar Pro 关于“为何无人想到这一策略”的提问，Schelpe 表示，竞争对手一直追随“越大越好”的理念，认为做这种创新“并没有真正的荣耀可言”，他还说自己幸运的是没有背负同样的思维包袱。Corbenic 的首页也用同样的标语强调了这一点：“别再造更大的模型了，去构建模型下方的层。”
但这一前提并不十分牢固。LMCache 是一个 Apache 2.0 许可的项目，在 GitHub 上拥有约 10,900 个 star，它早已将 KV 缓存迁移至 CPU 内存、本地 SSD 和远程存储。其博客上一篇 2024 年的文章 将其定位为“让 LLM 每段文本只读一次”。就在 Galahad 发布前九天，三星 工程师详细阐述了一个针对该项目的可重启恢复的 NVMe 层；其商业支持者 Tensormesh 也于 5 月从 AMD Ventures、CoreWeave 和 Nvidia 旗下 NVentures 等投资者手中融资 2000 万美元。
Nvidia 的 Dynamo 框架可以将 KV cache 从 GPU 显存分层下放到主机 DRAM、本地 NVMe 和网络存储，并在 CES 2026 上发布了 BlueField-4 上下文内存平台（现已更名为 CMX），专门用于把 KV cache 推送到 NVMe SSD 上。Nvidia 甚至宣称存储将成为 AI 的下一个前沿阵地。WEKA 推出了同样用途的 Augmented Memory Grid，华为也在推销 Unified Cache Manager 以避免重复计算，而 Phison 的 aiDAPTIV+ 早已把 KV cache 放到闪存上，应用在 Thunderobot AI Master M7000 这类消费级笔记本中。
主打安全，但仍需独立测试验证
Galahad 与那些背靠雄厚资金的竞争对手的真正区别其实更窄一些。其论文直接点名对比了 LMCache 和 Mooncake，并将差异化定位在精确性上：以 bit 级完全一致的 logits 作为验收标准，任何不匹配都视为缓存未命中。"要精确，不要近似。"Schelpe 说。不过这一对比最大的冲击对象是 CacheBlend 这类技术——LMCache 用它通过选择性重算来复用非前缀片段——而不是针对单纯的缓存下放。
Corbenic 的发布稿实际上以安全而非速度为卖点，称 Galahad 是"工作内存的安全保险库"：对存储的状态进行加密、隔离各客户的数据，并能记录活动日志，让开发者可以把服务器保存的内存回滚到更早的时间点。
这项技术背后的顾虑确实存在。研究者已在NDSS 2025 会议上展示，vLLM 和 SGLang 中的 KV cache 共享机制可能让一个用户通过时序侧信道重构出另一个用户的提示词，而 Galahad 库通过拒绝在没有租户身份和模型指纹的情况下启动来应对这一风险。Schelpe 还特别强调数据始终保留在本地：“这里没有共享缓存网络，也没有任何数据被发送给我们。”
另一方面，Corbenic 是一支小型比利时团队，注册于特拉华州。其 Galahad 主要论文中的每一个数据，均源自创始人在租用云 GPU 上自行进行的实验，论文对此也做了披露。原始日志承诺会公开但尚未发布，Blaise 的选择方法因专利申请中而暂不公开，相关论文均为自出版的 arXiv 预印本，而非经过同行评审的研究。
其竞争对手包括专有和开源方案，其中大多数已经过更充分的测试，如果 Galahad 无法找到愿意集成它的行业合作伙伴，这些竞品很可能会获得更广泛的采用。
但这并不意味着该理念有误。让 GPU 在每次请求时反复阅读相同的合同、手册和代码，确实是真正的浪费。Schelpe 将竞争格局界定得合情合理，他称“真正的竞争对手是：购买更多 GPU”。在当前内存和存储价格居高不下的背景下，能让现有服务器发挥更大作用的软件自然会找到买家，他表示早期反响积极，“已经收到了一些不错的请求，也积累了一些经验教训”。
Galabad 现在需要的是第三方基准测试：在相同的 Nvidia 硬件上与 LMCache 进行正面对决，各自开启运行时自身的 prefix cache，并在非其构建针对的文档上测试 Blaise 的检索能力。在此之前，最稳妥的看法是：Galabad 是对 KV 持久化的一种严谨、精确的实现，其最引人注目的数字更多来自“读得少”，而非“记得多”。
