新闻动态
News
首页 > 新闻动态 > 新闻资讯
返回

真正的大数据:上下文记忆如何重塑 AI 基础设施


在 AI 时代,存储,如同 GPU 一样,不能再仅以性能或容量来衡量。真正更重要的,是我们能用这些海量容量做些什么?  

图片

至少在过去十年里,我们一直把数据存储和计算机内存容量当成是理所当然的事情。

现在,人们很轻易地就会嘲笑那句常被归到比尔・盖茨头上的名言“640KB 内存对任何人来说都应该够用了”。

毕竟,如今花 2000 美元就能买到一部新款 iPhone,其内存(RAM)高达 12GB,几乎是 640KB 的近 8000 倍,还配有 2TB 的固态硬盘。

毕竟,如今 2TB 的存储容量大约是 20 世纪 80 年代中期个人电脑刚开始配备内置硬盘时,所谓“大容量”硬盘的 10 万倍。

事实上,唾手可得的存储和内存,加上无处不在的高速互联网,可以说导致了运维上的惰性

像 Apache Kafka 这样的主流数据系统,为了确保高可用性,可能需要将数据保存三份副本。

即使内存优化轻而易举,应用程序开发者也几乎不愿花费太多精力去优化内存使用效率——反正“多买点存储就行了”,或者“直接换用内存更大的云实例就好了”

但那样的好日子即将结束。

AI 推理工作负载正在催生一种全新的数据类型,其规模将急剧飙升:这就是我们在与 AI 模型交互过程中产生的上下文记忆(context memory),也称为工作记忆(working memory)

这一问题的重要性已不容忽视——就在前段时间的 CES 展会上,英伟达首席执行官黄仁勋发布了一款即将推出的 AI 超级计算机。

它可配置高达 18PB 的固态硬盘(SSD)容量,即在其 1152 块 GPU 中,每块 GPU 最多可配备 16TB 的存储空间,并新增了一层专门的上下文记忆存储层,专门用于管理在推理过程中即将产生的海量推理上下文数据

对于正在扩展至数万乃至数十万块 GPU 规模的“AI 工厂”而言,仅用于推理的存储需求就可能激增至 EB 级别。而与此同时,整个行业正面临高速内存和 SSD 容量(即构建上下文记忆存储的基础组件)的严重短缺——因为芯片硬件厂商的产能根本无法跟上迅猛增长的需求



01.
上下文记忆存在于 KVcache 中


对于大语言模型(LLMs)及其他基于 Transformer 架构的 AI 模型而言,上下文记忆存在于 KV Cache(Key-Value Cache,键值缓存)中。以下是其工作原理的简要说明:

  • 当用户或智能体调用一个模型时,模型必须首先计算初始上下文(例如当前提示词、上传的文档、检索到的内容或对话历史),然后才能生成第一个 token,(对于大语言模型而言,一个 token 通常约等于一个单词)。这一阶段称为预填充(prefill)。该过程为计算密集型,这也是为什么你可能会注意到在模型开始生成回复之前,会明显感觉到存在一段延迟的原因。

  • 在解码(decode)阶段,模型每生成一个后续 token 时,都会基于此前所有 token 的键(keys)和值(values)来生成下一个 token,并相应地将新生成的键值对追加到 KV 缓存(KV cache)中。这一步骤为内存带宽密集型,涉及 GPU 计算单元与内存之间持续的但相对小规模的交互,毕竟所有的键和值都存储在内存中。

  • 如果没有 KVcache,大语言模型(LLMs)在生成每个 token 时都必须重新执行一遍预填充(prefill)阶段。由于上下文在每一轮推理中不断增长,这就导致:每一个新增的 token,都将需要更长的计算时间、消耗更多的计算资源,并生成更大的缓存

当你听到大语言模型(LLM)的“上下文窗口”(context window)时,指的就是这一点:模型在技术上最多能处理的 token 数量。  

然而即便在窗口范围内,当用户会话长度超出上下文窗口,或者仅仅超出了可用内存或 GPU 容量时,模型性能仍可能下降。此时,系统可能会将较早的上下文内容清除,为新内容腾出空间,从而导致模型出现“失忆”现象。

如今,上下文记忆的主要生产者(也就是相应 KV cache 容量的巨大消耗者)之一,可能是代码生成类工作负载——用户可能会将整个代码库上传到提示(prompt)中,作为上下文窗口的一部分。视频模型同样会产生巨量上下文记忆,因为每一帧画面通常由多个(有时甚至是数百个)token 组成。

相信不久之后,智能体工作流也将成为上下文记忆的重要来源。这一点在多智能体系统中尤为明显,因为协调智能体需要跨任意数量的其他智能体维护全局上下文记忆。

再往远处畅想,用于机器人等场景的多模态模型,也可能产生极其庞大的上下文记忆。


02.
从640KB内存,到EB级上下文记忆


让我们回到之前提到的观点:过去四十多年来,内存和存储容量已实现了惊人的增长

惊叹现代智能手机的硬件参数,与比尔盖茨那句“640KB 就足够”的话相比较,这个事儿固然很有趣,但是如下这个数据才真正至关重要:一个上下文窗口为 128K 个 token 的大语言模型(例如 Llama 3),其键值缓存(KV cache 或 KV$)在单次对话中就会生成约 61GB 的数据

现在,61GB 乍听起来可能不算多,但问题就在于积少成多。

以下是我们工程团队最近提出的一个假设场景,以目前仍相对标准的 128K 个 token 上下文窗口为起点:

你究竟需要多大容量?

如下是一个示例公式,可帮助客户估算 KVCache 所需的容量:

总容量 = 用户数量 × 单用户的平均 KVcache 容量 × 留存系数

其中,“留存系数”指为每位用户保存的历史对话数量。

让我们以 Llama 3.1 405B 模型为例,并规划支持 10 万用户或者智能体:

  • 每次提示的平均 KVcache 容量:随着大上下文窗口(例如 128K 个 token)在文档分析或长时间对话等任务中逐渐成为标准,每位用户的缓存需求急剧增长。一个 128K-token 的上下文大约占用 61GB 空间。我们假设更典型的单次提示平均为 64K 个 token,对应约 30GB

  • 留存系数:我们取 15,以提供良好的用户体验(即为每位用户保留最近 15 次对话的上下文)。

  • 容量计算:100,000 用户 × 30GB × 15 = 45,000,000GB = 45PB

无论从架构设计还是成本控制角度来看,将数 PB 甚至数 EB 的 KVcache 完全保留在 GPU 显存中,甚至系统 CPU 内存中,都是不太现实的。

尽管如今要持久化存储如此海量(甚至更多)的上下文记忆,听起来有些不切实际,毕竟仅有少数大型的模型厂商能够实现这个规模,但是在未来,这一切将会变得更加合情合理。

没有人希望自己的 AI 模型忘记自己刚刚问过的最后 5 个问题,每个人都希望能随时继续上一次的对话。

即使应用场景本身保持不变,用户数量的增加、模型规模的扩大、上下文窗口的延长,以及人们希望将更多上下文记忆保存更长时间的需求,都将在未来几年推动上下文记忆存储需求迎来爆发式增长。


03.
将所有上下文记忆都存在 SSD 上


正是由于即将产生并存储的上下文记忆规模极其庞大,英伟达的黄仁勋才会在 CES 展会上站在那台庞大的超级计算机前,在全球瞩目之下,深入阐述 KVcache 的重要性,并详细介绍了英伟达为确保其下一代系统能在生产环境中有效管理 KVcache ,所付出的巨大努力。

显然,从每 TB 或 PB 的成本来看,SSD 的成本远低于 GPU 显存

尽管从外部存储读取 KVcache 的速度,不如直接从 GPU 显存中读取当前或“热”会话那么快,但经过良好设计的存储系统——例如新近发布的上下文记忆存储架构(CMS,context memory storage )——仍然能够以接近实时的速度将上下文数据输送给 GPU。

事实上,由于这种架构能有效缓解“冷启动”问题,对于需要访问历史对话或上下文的工作负载而言,其整体性能很可能会得到提升。

展望未来,分层的 KVcache 存储架构预示着一个新前景:通过突破当前 AI 的一些架构瓶颈,我们将能够实现更多可能:

  • 多智能体工作流和机器人模型可以获得对有状态上下文的高速访问,从而执行复杂的多轮任务,并从历史交互中学习,而无需反复进行耗时的预填充(prefill)计算

  • 状态空间模型(State-space models)可以通过调用外部存储的上下文来弥补其缺乏注意力机制的不足,从而将其卓越的计算效率拓展到更多新型应用场景中

  • 小型模型可以利用历史上下文来弥补其因参数量较少而导致的固有精度劣势——这种精度与规模之间的权衡是小型模型的天然特性。

我们能够通过低延迟的 GPU 连接,将越多的上下文卸载到 SSD(或其他闪存存储)中,就越能在算力资源利用、模型与应用架构以及数据中心设计等方面,实现更具创造性的突破。


04.
供应链,遇上需求……更遇上机遇


当然,所有这些 AI 投入都伴随着代价:DRAM 和 NAND 闪存产能的需求永无止境

很久以来第一次,“只要多买点存储”不再是一个可行的策略——成本正在上涨,一些制造商甚至开始砍掉消费级产品线,转而全力聚焦数据中心级产品的生产,而超大规模云厂商则在制造商一有产能释放时,便迅速抢购一空。

机遇则在于如何从现有硬件中榨取更多容量:  

提升数据缩减效率,跨系统、应用和用户之间实现存储资源共享,并寻找更优、更现代的替代方案,取代那些浪费容量的传统系统方案。  

今天的巧妙工程设计,即使在未来 DRAM 和 NAND 产能重新变得充裕之后,也依然会持续带来丰厚回报。

现在也是时候认真思考如何保护上下文记忆的安全了。

试想一下,在我们此前提到的例子中——为 10 万名用户存储的 45PB AI 交互数据和模型“思维过程”——其中可能包含大量敏感的个人数据和知识产权。  

任何以未加密和/或隔离薄弱的方式(即便是临时性地)存储如此海量数据的做法,无异于主动带来数据泄露风险

当所有规划中的 AI 数据中心最终被填满时,它们应当以尽可能优化的方式运行——这意味着要实现最高的能效和最少的空间浪费,从而使运营方能够灵活应对不断变化的算力需求和业务场景。  

在这一布局中,为处理 KVcache 和上下文记忆而扩展存储容量将是至关重要的一环,但前提是我们必须明白:存储基础设施并不仅仅是可无限扩展的“傻瓜式”比特池。

在 AI 时代,存储,如同 GPU 一样,不能再仅以性能或容量来衡量。真正更重要的,是我们能用这些海量容量做些什么。  

正如 1981 年那区区 640KB 的 PC 内存推动了数字革命一样,即将上线的 EB 级上下文记忆也将成为驱动 AI 革命的关键力量。我们对它的优化程度越高,所能获得的成果就越大。

2026 年 2 月 24 日至 26 日,VAST Data 首届用户大会 VAST Forward 正在美国犹他州盐湖城正在举办 ,观众可亲身体验 VAST 在 AI 与数据基础设施领域的行业领先理念

上一篇:NVIDIA GTC 2026 重磅回归,诚邀全球 AI 先