AIOS：大模型智能体操作系统

大鲸鱼crush
1,275 阅读10分钟

image.png

前言

本文主要介绍了AIOS及其技术架构和实现。AIOS是一种LLM智能体操作系统，将大型语言模型嵌入操作系统（OS）作为OS的大脑，实现了“有灵魂”的操作系统。

背景介绍

随着大语言模型（LLMs）的爆火，拥有大语言模型充当“大脑”的智能体（agent）出现在各种应用中。借助大语言模型的能力，智能体能够在无需人类干预的前提下，独立运行、做出决策并执行任务，解决复杂问题。

然而，假设我们有一个自己的LLM，而后有一堆需要LLM执行的任务，且我们以agent的形式完成这些任务，因为一个智能体通常只执行一个专门的任务，随着我们要执行任务的增多，智能体数量和复杂性就会指数增长。但是我们的LLM和操作系统（OS）却只有一个，类似于一个应用，当用户数增加时，其后端访问压力就会越来越大，当agent增加时，我们就需要想办法优化“后端”——LLM和操作系统。

那么现有的单个LLM和单个OS上以应用软件的形式运行agent究竟会带来什么问题呢？

  • 智能体请求在LLM上的调度优化和资源分配
    • 假设我们有大量agent，agent所执行的任务必然会有优先级之分，那么我们该如何进行调度
  • 智能体与LLM交互过程中维护上下文的困难
    • 众所周知，LLM是有上下文窗口限制的，即LLM单次输入的句子长度有限，那么多个agent该如何共用这些上下文长度
  • 以及将具有不同能力和专长的异构智能体集成带来复杂性问题
    • 目前来说，当我们需要使用多个agent时，不同agent可能有不同的输入输出，有不同的限制，那么我们将多个agent集成在一起的难度就会越来越大

由此，为了优化多agent应用与LLM之间交互时所面临的各种问题，论文提出了AIOS，即LLM智能体操作系统（图1），这里大家需要注意，这个LLM OS的出发点是优化agent应用。具体而言，AIOS旨在优化资源分配，促进智能体之间的上下文切换，实现智能体的并发执行，为智能体提供工具服务，并维护智能体的访问控制。

AIOS整体架构

image.png

如上图所示， AIOS架构分为三层：应用层、内核层和硬件层。

  • 应用层
    在应用层，可以开发和部署智能体应用程序。在这一层，AIOS提供了AIOS SDK，对系统调用进行了更高级的抽象，从而简化了智能体的开发过程。该SDK通过提供丰富的工具包，来抽象低层系统功能的复杂性，使开发者可以专注于智能体的基本逻辑和功能，从而提高开发效率。
  • 内核层
    内核层分为两个主要部分：操作系统内核和LLM内核，原始的OS内核负责硬件管理，处理无智能软件的请求，而新增加的LLM内核则专用于处理与LLM智能体、LLM相关资源和开发工具包相关的职责。
  • 硬件层
    硬件层由CPU、GPU、内存、磁盘和外围设备等组成。硬件资源仍然由操作系统管理。LLM层仍然调用OS提供的底层接口

关键的部件

在新增加的LLM内核中，关键部件如下：

  • Agent调度器 (Agent Scheduler)：优化LLM资源的使用，通过FIFO、RR等调度算法来优先处理和调度Agent请求。
  • 上下文管理器(Context Manager)：上下文管理器负责保存和恢复LLM的生成进度，允许即使在中断情况下也能无缝恢复任务。它还管理上下文窗口，确保了LLM上下文容量的最优利用。
  • 内存管理器(Memory Manager)：AIOS包括一个内存管理器，为每个代理的交互提供短期记忆。这允许代理保持本地状态并快速访问相关信息，增强了它们的响应性和性能。
  • 存储管理器(Storage Manager)：为了长期持久性，存储管理器安全地保存代理交互。这使得代理能够访问历史数据，从过去的经验中学习，并基于广泛的知识做出明智的决策。
  • 工具管理器(Tool Manager)：工具管理器负责监督代理可以使用的外部API工具。通过集成广泛的工具，AIOS赋予代理执行复杂任务和访问大量信息和功能的能力。
  • 访问管理器(Access Manager)：为了确保隐私和安全，访问管理器在代理之间实施了严格的访问控制策略。它管理权限、认证和授权，防止未经授权的访问并保护敏感数据。

智能体调度器(Agent Scheduler)

image.png

我们把每一个智能体（agent）都看成一个进程，这个调度器的作用就显而易见——进程调度器，但是调度的是agent的请求。

所解决的问题

原本，假设我们有三个agent，原本LLM在响应agent的请求时是线性响应的，如上图所示，LLM会先处理完A的请求，然后处理B，然后处理C，但是不同agent的请求所需的完成时间可能差距极大，导致一些有时限需求的agent饿死，因此引入Agent调度器，对于属于不同Agent的请求进行调度。

调度算法

在论文中，智能体调度器采用先进先出（FIFO，First-In-First-Out）、轮询调度（RR，Round Robin）和其他调度算法来优化这一过程。简而言之，论文中没有提出新的调度算法，而是直接沿用了现有的传统算法。

作用

调度器可显著平衡每个智能体的等待时间和周转时间，因为来自不同智能体的任务会交错并行执行。不同智能体的任务以交错的方式进行处理（如，A1、B1、C1、B2、A2、A3、C2、C3），确保没有单个智能体垄断处理资源，并且最大限度减少空闲时间。

上下文管理器(Context Manager)

image.png

上下文管理器负责管理提供给LLM的上下文和在给定上下文的生成过程。其关键功能为：

  • 上下文快照和恢复
  • 上下文窗口管理

上下文快照和恢复

考虑到调度算法可能随时切换不同Agent，同时，如果处理一个请求时LLM响应时间过长，调度算法也可能会不等LLM响应完就强制切换任务，导致智能体请求即使LLM尚未完全生成响应也被调度器暂停。因此，需要一种机制来保存LLM生成过程的状态，以确保在资源再次用时，能够准确地恢复。

详细机制

AIOS在上下文管理器中提供了快照和恢复机制来解决这个问题，如上图所示。采用比较简单的说法，LLM生成响应时候是逐个词的生成的，每当生成一个词的时候，LLM是针对一个词表生成一个序列，然后进行抽样。我们把这个过程建模为一个搜索树，节点代表生成的词，边代表抽样概率。因此，生成过程在中间步骤被调度器中止时，上下文管理器使用快照功能来存储LLM搜索树的当前状态，存储每一条边对应的概率和中间节点。在恢复时，恢复功能重新加载快照中保存的状态，使LLM从暂停点继续生成过程，以获得最终答案。

上下文窗口管理

LLM本身有窗口大小限制，比如可能一次最多输入8k个单词。为了处理超过LLM上下文窗口限制的长上下文，上下文管理器还需要尝试使用其他技术扩展上下文窗口，并进行管理。AIOS中的上下文管理器支持文本摘要等上下文窗口扩展技术。

内存管理器(Memory Manager)和存储管理器(Storage Manager)

image.png

上图展示了AIOS的整体存储架构，包括短期存储所需的内存管理器(Memory Manager)和长期存储所需的存储管理器(Storage Manager)

内存管理器(Memory Manager)

如上图所示，内存管理器负责管理智能体的生命周期内的短期内存，确保数据仅在智能体处于活动状态（等待执行或运行时）时，才能存储和访问数据。简单地说，如果我们把每个agent看成一个不同的应用，那么这里实现的就是一个应用数据隔离机制。

当前的AIOS支持独立存储每个智能体的内存，其他智能体经过访问管理器的授权才能访问每个智能体的内存。内存管理器能够实现快速的数据检索和处理，便于快速响应用户查询和交互。

存储管理器(Storage Manager)

存储管理器负责数据的长期保存。 在AIOS中，通过各种持久性介质（如本地文件、数据库或云存储）实现数据的永久存储，以确保数据的完整性和可用性。

工具管理器(Tool Manager)

image.png

AIOS系统中的工具管理器管理着一系列增强LLMs功能的API工具。如上表所示，工具管理器整合了各种常用工具，包含网络搜索、科学计算、数据库检索、图像处理等，涵盖不同的输入和输出形式，从而便于在AIOS生态系统中进行智能体开发。

访问管理器(Access Manager)

访问管理器通过为每个智能体管理一个专用的权限组，来协调不同智能体之间的访问控制操作。 被排除在智能体的权限组之外的其他智能将被拒绝访问其资源，如交互历史。访问管理器会维护审计日志。这些日志记录了访问请求、智能体活动以及对访问控制参数的修改信息。

实验结果

实验数据

实验使用Python 3.9、PyTorch 2.0.1和CUDA 11.8，硬件为8个NVIDIA RTX A5000 GPU的Ubuntu 22.04机器。采用开源大模型（即Gemma-2b-it、Gemma-7b-it、LLaMA-2-13b-chat-hf作为AIOS的LLM。

为了进行评估，配置了三个不同的Agent：一个数学Agent，用于解决数学难题；一个叙事Agent，用于生成新的叙事；以及一个推荐Agent，负责提供餐厅推荐。每个Agent在运行过程中都会向LLM发送2-3个请求。

一致性分析

使用BLEU分数和BERT分数作为评估指标来评估多个Agent并行运行与单个Agent依次运行时输出的一致性。结果显示，BLEU和BERT分数都达到了1.0，表明多Agent和单Agent配置下生成的输出之间完全对齐，证实了设计在有效促进并行多Agent操作方面的一致性。

性能分析

作者进行了AIOS使用FIFO调度和非调度方法（即顺序执行）的比较分析。结果表明，非调度方法对序列早期的Agent表现良好，但牺牲了序列后期Agent的等待时间和周转时间。相反，AIOS的调度机制有效地调节了等待时间和周转时间，特别是对于后续Agent的请求，当LLM较大时，这种优势尤为明显。这表明调度对于适应多个Agent的并行操作非常重要。

引用

[1] arxiv.org/abs/2403.16…
[2] zhuanlan.zhihu.com/p/691420682
[3] cloud.tencent.com/developer/a…

avatar
文章
阅读
粉丝