编辑：前沿在线 编辑部 最近半年跑了十多家智算中心并做了调研，一个很直观的感受是：大家都在拼命堆算力，GPU、NPU 的规模翻着番涨， 但真到了生产环境跑推理，卡脖子的往往不是算力本身。 聊到推理成本， 几乎所有团队都绕不开 KV Cache 的问题 。 长上下文模型和智能体用得越多，这个问题就越突出。 已经算过的上下文数据存不下、调不动，最后算力只能反复做重复计算，钱投进去了，产出没跟上。 最近在 华为全联接大会 2026 上 ， OceanStor M900 AI 记忆存储 在主论坛重磅发布。 这款产品之所以在AI基建领域引起讨论，核心不是存储本身的参数升级，而是它刚好踩中了现在全行业都在面对的痛点： KV Cache 越来越大，原有存储体系接不住了。 为什么 KV Cache 突然成了问题？ 先简单说下 KV Cache 是什么。 大模型推理的时候，每做完一次计算，都会把对应的中间结果存下来，后面再用到这段上下文的时候，就不用重新计算，直接调用就行。 这部分存下来的中间数据，就是 KV Cache。 它就是一个提升推理效率的缓存机制 ，一直都存在，只是过去没人太当回事。 前几年对话式 AI 为主的时候，一轮对话结束，上下文清空，KV Cache 量小，用完就扔，基本都放在显存里，占不了多少空间。 但这两年情况变了。 一边是 Agentic AI 开始落地，智能体跑任务是多轮连续的 ，写代码、查资料、调工具，一跑就是几十步，上下文保存的时间变长； 另一边是大模型的上下文窗口越做越大 ，百万词元已经成了主流配置。两个因素加在一起，KV Cache 的数据量直接就涨了上去。 过去它更多只是推理框架里的一个缓存机制， 现在实实在在的影响着整个集群的资源分配。 现有存储的两头堵困境 问题是， 现有的存储体系，从设计之初就不是为这么大量的 KV Cache 准备的 。现在行业普遍遇到的是两头堵的情况。 一头是显存不够用。 显存离计算最近，速度最快，但容量小、成本高。 KV Cache 全都堆在显存里，占掉大量空间之后，留给模型权重、计算中间态和并发请求的显存就少了，推理的并发量和效率自然受影响。 在我们走访的十余家智算中心里，长上下文推理场景下，KV Cache 占用的显存比例普遍偏高。 更麻烦的是， 超节点集群里每个节点的显存都是独立的，没法跨节点共享，很容易出现资源错配 。有的节点被上下文占满接不了新任务，有的节点还有富余却用不上。 最终反映到算力利用率上，我们接触到的千卡级推理集群，实际跑推理的有效算力大多不到五成，其中很大一部分浪费，就来自缓存没命中导致的重复计算。 另一头是传统存储跟不上。 既然显存放不下，放到传统的外部存储行不行？实际跑下来效果并不好。 传统存储本来就是为数据持久化设计的，容量大但延迟高，数据读写要经过 CPU 转发、多层协议转换，通常是毫秒级的延迟。 但 KV Cache 是典型的热数据，要高频反复调用，对延迟的敏感度极高。用传统存储存 KV Cache，数据供给的速度追不上计算的节奏，GPU/NPU 就只能等着， 直接表现就是首 Token 时延慢、Token吞吐率上不去，大量算力空转。 两个问题加在一起，就形成了现在的尴尬局面： 算力越堆越贵，却因为存储的问题，大量算力都浪费掉了。 行业的两种解决思路 问题摆在这里，行业也试了不少办法。 早期大多是打补丁的思路， 比如扩显存、加缓存层、用软件调度优 化，但都只能缓解局部问题，到了超大规模集群的场景，还是解决不了根本问题。 过去一年多，全球的头部厂商都在往这个方向布局，慢慢形成了两种不同的技术路径。 第一种还是围绕计算节点做延伸 ，通过更大的本地缓存、更高速度的节点互联，让每个计算单元能用到更多的 KV Cache。 这种方式对现有架构改动小，部署快，但本质上还是没跳出单个节点的框架 ，集群大了之后，调度和容量还是会碰到天花板。 第二种思路是把 KV Cache 从计算节点里独立出来，专门做一层共享的 AI 记忆数据基础设施。 所有节点的 KV Cache 统一管理，形成一个共享的资源池，整个集群的计算单元都可以调用，不用每个节点各自存一份。 不只是华为，英伟达、阿里云等厂商也都在从各自的技术栈出发，探索类似的方向。这条路架构上更彻底， 能从根本上解决规模和调度的问题，但对厂商的全栈技术能力要求也更高。 华为 AI 记忆存储的落地路径 这次华为发布的 OceanStor M900 AI 记忆存储 ，走的就是第二条路线， 把 AI 记忆存储作为独立的一层来做 。根据华为官方发布的技术参数，它主要从三个维度解决问题。 首先是容量。 它通过灵衢高速互联网络把显存、内存、AI 记忆存储等资源整合起来，实现全局池化和分级存储，打破节点的物理边界，把承载的介质从显
