AI基础设施的下一个挑战：智能体如何不丢失记忆

下一个AI挑战不是速度，而是连续性。

键值（KV）缓存已经从一个冷门的推理优化技术，变成AI基础设施领域最热门的话题之一。其基本原理很简单：当大语言模型处理提示词并生成响应时，它执行的一些计算在对话不断延伸时本来需要重复进行。KV缓存则将部分先前计算的结果保留下来，让模型可以重复使用，而不必重新计算。结果就是减少了冗余计算，提升了推理速度。

这解决了模型内部的一个重要问题。但AI工作负载正开始在更大规模上制造类似的问题。

智能体所做的不仅是生成响应。它们可以收集信息、调用工具、查询企业数据、创建文件、做出决策，并完成通向更大目标的多个步骤。在这个过程中，它们积累了宝贵的工作状态：上下文、记忆、工具输出、中间结果、生成的文件、检查点，以及对企业数据的引用。

问题在于，当这项工作需要停止并重新开始时会发生什么。智能体可能会因为等待批准而暂停，转移到不同的计算资源上，从故障中恢复，或者在数小时甚至数天后重新回到某个任务。如果没有办法保存它已经学到和完成的内容，它可能需要重新检索相同的数据、重建上下文、重新运行工具，或者重复工作流程的部分环节。

随着智能体从回答提示词演变为执行持续数小时、数天甚至数周的工作流程，反复重建这种状态会变得越来越低效。任务越长、越复杂，累积的状态就越有价值。

这正是下一个缓存机遇所在：保存并快速恢复智能体已经积累的工作状态，使其能够从中断处继续，而不是重新构建已经完成的工作。

聊天机器人往往可以承受冷启动的代价。但一个正在研究复杂课题、迁移代码库、分析数千份文档，或执行多步骤业务流程的长时间运行的智能体，可能就无法承受这种代价。支撑这些智能体的基础设施将越来越需要让其累积的状态变得持久、可访问且能够快速恢复。

这里有一点常常在关于缓存的讨论中被忽略：大规模缓存智能体状态，只有在其底层存在一个连贯的数据结构时才能真正发挥作用。如果智能体的缓存状态被困在会话结束时运行的某个节点或区域上，那么这种缓存就毫无价值。基础设施的要求不仅仅是更快的缓存，而是一个一致的、可寻址的命名空间，这样无论智能体在本地、边缘还是云端重新启动，缓存的智能体状态及其引用的数据都能够被访问到。

通往智能体缓存的道路，要从AI基础设施已经面临的一个问题开始：让数据始终靠近计算运行的地方。在《利用Qumulo云数据平台加速AI数据工作流》一文中，我们描述了一种多层缓存方法，将针对频繁访问数据的边缘读写缓存，与基于NVMe实例存储的集群持久化缓存相结合，再加上基于机器学习的预测性读缓存——在实际部署中，这一方案将S3 API成本降低了高达90%，同时将GPU执行时间减少了高达40%。这是应用于数据访问的缓存。缓存智能体状态是建立在其之上的自然的下一层，并继承了相同的要求：缓存必须能够从工作负载实际运行的任何地方访问到，而不仅仅是从它最初启动的地方。

这正是我们所称的"云数据结构"所扮演的角色——一个严格一致的全局命名空间，将本地集群、亚马逊云科技（AWS）、微软Azure、谷歌云和甲骨文云基础设施（OCI）等云端实例，以及边缘部署连接在一起，使任何工作负载、模型或智能体都能访问相同的数据集，无论其计算当天恰好在哪里运行。具备网络感知能力的服务质量机制会在后台处理广域网上的传输工作，随着工作负载默认跨越混合云和多云环境，这项能力的重要性只会越来越高，不会减弱。

我们要坦率地说明这个话题目前所处的位置：这在某种程度上是具有前瞻性的推测，因为"缓存智能体"这个说法目前还不会在每一个AI基础设施会议上被提及。但让KV缓存的价值变得显而易见的经济逻辑——降低延迟、降低推理成本——同样清晰地适用于智能体所携带的更广泛的运行环境。那些已经在构建多地点AI基础设施的组织（混合云与本地部署、设计上就采用多云架构）将首先遇到"智能体的记忆存放在哪里"的问题，因为它们已经在不止一个地方运行智能体了。

我们在地理分布式训练工作中也见过类似的情况。在《利用Qumulo和亚马逊SageMaker HyperPod进行地理分布数据的基础模型训练》一文中，挑战不仅仅是将数据一次性传送到训练集群。更重要的是在整个长时间运行的任务生命周期中，跨地理分布式计算资源保持数据集的一致性和可访问性，这在结构上与智能体持久化状态将面临的问题是一样的，因为智能体正从单次会话转向长时间运行、可恢复的工作。

AI基础设施领域下一个炒作周期，不会是关于让模型运行得更快。它将是关于确保智能体在不同地点之间转移时不会丢失自我。如今正在构建智能体系统的企业，应该向其基础设施团队提出一个听起来近乎过于简单的问题：如果这个智能体的会话在一个节点上结束，并在下周于另一个节点上恢复，它的状态是否会随之而来？对大多数组织来说，目前诚实的答案是"不会"。这个差距正是AI基础设施投资接下来要发展的方向。

有必要具体说明一下，当智能体状态从一开始就是基础设施设计的一部分，而不是事后添加的内容时，会发生什么变化。模型服务缓存可以承受短暂和局限于区域的特性，因为冷缓存只会让下一次请求付出一些延迟的代价。智能体状态则没有这种奢侈。一个任务执行中的智能体如果失去了上下文、工具调用历史或生成的中间文件，不仅仅是运行得更慢，它可能会产生错误的答案、重复昂贵的步骤，或者直接失败。这就把要求从"通常是热的缓存"提升到了"从智能体可能恢复的任何地方都持久且可访问的状态"。

这在成为模型问题之前，首先是一个数据基础设施问题，这也是为什么我们认为这场讨论将转向数据层。那些已经在运行不关心请求由哪个区域或集群提供服务的工作负载的团队，将更容易实现过渡，因为底层的数据结构使这种区分对应用程序而言变得不可见。我们如今已经在大规模训练和归档工作负载中看到了这种需求的早期版本，正如Qumulo《业界最快的基于云的AI工作负载文件解决方案》一文中所描述的，其目标是一样的：让位置成为一个实现细节，而不是限制工作负载能力的约束条件。

结论：面向智能体的基础设施不仅仅是让智能体更快地访问模型和数据。更重要的是确保它们创建的状态是持久的、可移植的，并且无论智能体在哪里恢复运行都能够获取到。随着智能体试点项目走向生产环境，将状态与特定节点、区域或云绑定的基础设施将成为一种限制。

Q&A

Q1：KV缓存和智能体缓存有什么区别？

A：KV缓存是模型内部的推理优化技术，用于避免大语言模型重复计算已处理过的内容。智能体缓存则是更大规模的概念，保存的是智能体在完成任务过程中积累的上下文、工具调用结果、中间文件等工作状态，让智能体可以从中断处继续，而不是重新构建已完成的工作。

Q2：为什么智能体需要持久化状态？

A：因为智能体执行的任务往往需要数小时、数天甚至数周才能完成，过程中可能因等待批准、切换计算资源或故障恢复而中断。如果没有持久化状态的能力，智能体重新启动时就需要重新检索数据、重建上下文、重新运行工具，效率低下且成本高昂。

Q3：什么是云数据结构，它解决了什么问题？

A：云数据结构是一个严格一致的全局命名空间，将本地集群、多个云平台（如AWS、Azure、谷歌云、OCI）以及边缘部署连接起来。它解决的问题是让智能体的缓存状态及其引用的数据无论在哪个位置都能被访问到，而不会被困在会话结束时所在的节点或区域。