원본 논문 링크 : https://arxiv.org/abs/2403.16971
Abstract
- LLM 기반 agent의 통합 및 배포는 효율성 측면에서 많은 문제가 있다.
- 예를 들어, LLM agent의 스케줄링, 리소스 할당, 스케줄링으로 인한 context 유지 및 전환, multi-agent 상황에서의 효율성 저하 등이 있다.
- Agent가 많아지고 복잡해지면 이런 문제는 큰 bottleneck이 되고, 리소스 활용을 최적화하기도 어렵다.
- 위 문제를 해결하기 위해 본 논문은 LLM agent들을 OS의 개념을 활용하여 관리하는 새로운 OS 아키텍처인 AIOS를 제시한다.
- AIOS는 리소스 할당 최적화, Agent 간 context switching, Agent 동시 실행 지원, Agent Toolkit 제공, Agent 대한 액세스 제어 등의 기능을 제공하도록 설계 되었다.
- 특히 이 본 논문에서는 2가지 실험을 진행하는데, Agent 간 context switching을 도입해도 성능 저하를 가져오지 않는다는 것과 AIOS가 Agent들이 동시에 실행되는 상황에 대해 기존 시스템보다 좋은 효율성을 보여주고 있음을 실험을 통해 보여준다.
- AIOS는 LLM Agent의 성능과 효율성을 향상시킬 뿐만 아니라, 향후 AIOS 생태계의 더 나은 개발과 배포를 선도하는 것을 목표로 하고 있다.
- 코드는 다음의 링크에서 볼 수 있다. : https://github.com/agiresearch/AIOS
1 Introduction
- 자율 Agent 분야에서의 최종 목적으로 하는 것은 인간 개입을 없애거나 최소한으로 하여 독립적으로 작동하고, 결정을 내리고, 작업을 수행 할 수 있도록 하는 시스템이다. 이러한 Agent는 instruction을 이해하고, 정보를 처리하고, 결정을 내리고, 자율성을 달성하기 위한 조치를 취하도록 설계되었다.
- LLM은 이러한 Agent 개발에 새로운 가능성을 제시하였고, instruction 이해, 문제 추론 및 해결, 유저와 외부 환경과의 상호작용 측면들에서 매우 큰 성과를 보였다.
- LLM을 기반으로 하는 신흥 LLM 기반 Agent들은 가상 비서부터 복잡하고 창의적인 문제 해결, 계획 및 추론을 포함하는 보다 정교한 시스템에 이르기까지 다양한 환경에서 강력한 수행 능력을 제공할 수 있다.
- LLM 기반 Agent의 예시는 아래의 그림과 같다. 유저의 요청에 따라 여행 Agent는 작업을 실행 가능한 단계로 분해하고 사용자 설정에 따라 항공편 예약, 호텔 예약, 결제 처리, 캘린더 업데이트 등의 단계를 순차적으로 시행한다 .
- 그렇지만 Agent의 수가 늘어나고 복잡해짐에 따라 LLM과 OS의 부담은 커지게 된다. 본 논문에서는 다음의 문제들을 지적한다.
- 제한된 리소스 내에서 Agent의 요청을 예약하고 그들의 우선순위를 지정하는 것은 성능과 효율성에 큰 영향을 끼친다.
- LLM의 생성 프로세스가 긴 Context를 처리할 때, 시간이 너무 오래 걸리거나 때로는 스케줄러에 의해 생성이 중단될 수 있다.
- Agent가 사용 가능한 toolkit들에 대해 여러 Agent가 동일한 tool을 호출해야 할 수 있으므로 이 것들을 최적화해야 한다.
- 여러 Agent를 동시에 작동하려면 이들 간의 메모리 관리를 위한 강력한 시스템이 필요하다.
- 개인 정보 보호 및 액세스 제어 조치를 엄격하게 적용해야 한다.
- 위의 문제들을 해결하기 위해 논문에서는 LLM과 OS 기능들의 module isolation과 aggregation(응집)을 제공하는 AIOS를 제안한다.
- AIOS는 LLM과 관련된 작업과 LLM과 관련되지 않은 작업 간에 발생하는 충돌을 해결 하기 위해 LLM 커널 설계를 제안한다. 이 커널은 OS와 유사한 업무, 특히 LLM 에이전트와 그에 수반되는 리소스 및 toolkit의 관리와 관련된 업무를 분리한다.
- 이러한 분리를 통해 LLM 커널은 LLM 관련 활동의 관리 및 조정을 향상시키는 것을 목표로 한다. 제안된 LLM 커널 내에서 우리는 각각 LLM 작업과 관련된 고유한 기능들을 처리하는 데 전념하는 모듈들을 고안했습니다.
- 본 논문에서 제시한 AIOS의 구조는 다음 그림과 같다.
- AIOS에서 제시하는 LLM 커널 내의 모듈은 크게 6가지로 다음과 같다.
- Agent Scheduler, Context Manage, Memory Manager, Storage Manager, Tool Manager, Access Manager
- 또한 LLM 커널은 Agent가 이러한 서비스를 문제없이 활용할 수 있도록 해주는 LLM 시스템 콜 인터페이스를 가진다.
- 저자들은 이 LLM 시스템 콜을 Agent 개발자들이 보다 편리하게 사용할 수 있도록 AIOS SDK 또한 설계했다.
- AIOS를 사용하면 Agent는 LLM 추론과 OS 레벨 작업을 단계별로 나눌 수 있다. 이는 LLM Agent가 점점 더 복잡해지는 multi-modal task를 효과적으로 처리할 수 있도록 해준다.
2. Related Work
- Evolution of Operating Systems
- OS의 발전과정과 간단한 개념을 언급한다.
- Large Language Model Agents
- LLM Agent는 2가지 종류로 분류할 수 있다.
- LLM-based Single-Agent Systems : 말그대로 문제 해결을 위해 하나의 Agent만을 사용하는 것. LLM Agent는 API 호출, 웹사이트 탐색 등의 디지털 환경 뿐만 아니라 실험 수행, 로봇 조작 등 물리적 환경에서도 적용 가능하다.
- LLM-based Multi-Agent Systems : 문제 해결을 위해 여러 Agent 간의 상호 작용을 활용한다. 다중 Agent 간의 관계는 협력적, 경쟁적, 또는 협력과 경쟁의 혼합일 수 있다.
- LLM Agent는 2가지 종류로 분류할 수 있다.
3. AIOS Layers
- AIOS는 Application Layer, Kernel Layer, Hardware Layer의 세 가지 layer로 구성된다.
- 이 계층화된 아키텍처는 시스템 전반에 걸쳐 책임을 확실히 분담한다.
- 각 상위 계층은 복잡성을 추상화하고, 인터페이스나 특정 모듈을 통한 상호 작용을 촉진함으로써 모듈성을 강화하고 다양한 계층 간의 시스템 상호 작용을 단순화한다.
- Application Layer
- 여기에서는 travel Agent 또는 Math Agent와 같은 에이전트 애플리케이션이 개발 및 배포된다.
- 이 계층에서 AIOS는 에이전트 개발자의 개발 프로세스를 단순화하는 시스템 콜을 더 추상화하여 쉽게 사용할 수 있게 해주는 AIOS SDK를 제공한다.(구체적인 예시는 추후 기술)
- SDK를 사용하면 low level의 복잡한 시스템 기능을 추상화하는 풍부한 toolkit을 사용하여 에이전트 애플리케이션을 쉽게 개발할 수 있다.
- 이를 통해 개발자는 에이전트의 필수 논리와 기능에 집중할 수 있어 효율적인 개발 프로세스가 가능해진다.
- Kernel Layer
- 여기에서는 OS 커널과 LLM 커널이라는 두 가지 요소로 나누어지며, 각각은 non-LLM 및 LLM 관련 task들의 요구 사항을 수행한다.
- 이러한 구별을 통해 LLM 커널은 LLM 관련 활동을 처리하는 데 사용되고, 일반적인 표준 OS 커널 기능에는 포함되지 않는 LLM 컨텍스트 관리 혹은 Agent 예약과 같은 LLM에 밀접하게 관련된 작업에 집중할 수 있다.
- 본 논문은 기존 OS 커널의 구조는 크게 변경하지 않고, LLM 커널을 추가하여 향상시키는 데 중점을 두고 있다.
- LLM 커널에는 Agent Scheduler, Context Manage, Memory Manager, Storage Manager, Tool Manager, Access Manager를 포함한 여러 주요 모듈이 장착되어 있다. 이러한 구성 요소는 에이전트 애플리케이션의 다양한 실행 요구 사항을 해결하여 AIOS 프레임워크 내에서 효율적인 관리 및 실행을 보장하도록 설계되었다.
- Hardware Layer
- Hardware Layer는 CPU, GPU, 메모리, 디스크 및 주변 장치를 포함하여 시스템의 물리적 요소로 구성된다.
- LLM 커널의 시스템 콜은 하드웨어와 직접 상호 작용할 수 없다는 점에 유의하는 것이 중요하다.
- 대신 이러한 LLM 커널의 시스템 콜은 OS의 시스템 콜과 인터페이스하여 하드웨어 리소스를 간접적으로 관리한다.
- 이러한 간접적인 상호 작용은 추상화 및 보안을 보장하여 LLM 커널이 직접적인 하드웨어 관리 없이도 하드웨어 기능을 활용할 수 있도록 하여 시스템의 무결성과 효율성을 유지한다.
4. AIOS Implementation
- 이 섹션에서는 AIOS의 핵심인 LLM 커널에서 구현된 모듈들과 LLM 커널의 시스템 콜, 그리고 AIOS SDK에 대해 설명한다.
4.1 Agent Scheduler
- 이것은 Agent의 요청을 효과적으로 관리하기 위해 설계되었다. 아래 그림을 보자.
- 이는 Agent의 요청을 효율적인 방식으로 관리하도록 설계되었다.
- 위 그림에는 3개의 Agent(A, B, C)가 있다. Agent 스케줄러를 사용하지 않으면 각 에이전트는 순서대로 처리될 것이다. 이로 인해 뒷 순서에서 대기 중인 Agent C의 대기 시간이 늘어나게 된다..
- Agent 스케줄러는 FIFO(First-In-First-Out), RR(Round Robin) 및 기타 알고리즘 전략을 사용하여 이 프로세스를 최적화한다.
- 각 Agent들은 거의 동시에, 병렬적으로 실행되어 각각의 waiting time과 turnaround time의 균형을 유지한다. 위 그림을 보면, 스케줄러가 적용된다면 하나의 Agent가 리소스를 독점하지 않아서 idle time을 최소화한다.
- 이는 CPU의 프로세스 스케줄러와 동일한 원리이다.
4.2 Context Manager
- context manager는 LLM에 제공된 컨텍스트 관리 및 특정 컨텍스트로부터 결과를 생성하는 프로세스를 관리하는 역할을 담당한다. Context Snapshot and Restoration과 Context Window Management라는 두 가지 기능이 있다.
- Context Snapshot and Restoration
- Agent의 request는 이전에 설명했던 Agent 스케줄러에 의해 중단될 수 있다. 이 중단은 LLM에서 아직 응답이 완전히 생성되지 않은 경우에도 발생할 수 있다.
- 따라서 LLM 생성 프로세스의 중간 상태를 보존하고, 이후 스케줄러에 의해 리소스를 다시 사용할 수 있게 되는 차례가 돌아오면, 정확하게 그 중간 상태로부터 재개될 수 있도록 보장하는 메커니즘이 필요하다.
- AIOS는 이 문제를 해결하기 위해 context manager에서 Context Snapshot and Restoration 메커니즘을 제공한다.
LLM은 일반적으로 텍스트를 생성하는 디코딩 프로세스에서 beam search를 사용하고 편의를 위해 beam width를 1로 가정한다. 만약 Agent가 'Determine whether there will be a rain in the destination of flight UA057.' 이라는 요청을 했을 때, LLM은 beam width = 1을 기반으로 확장해나가면서 가능성이 가장 큰 경로를 찾게 된다. - 만약 중간 단계에서 스케줄러에 의해 이러한 생성 프로세스가 일시 중지되면 context manager는 Context Snapshot 기능을 사용하여 탐색 중인 모든 중간 확률 및 경로를 포함하여 LLM beam search tree의 현재 상태를 캡처하고 저장한다.
- 이후 다시 생성을 재개하면 Restoration 기능을 사용하여 Snapshot에서 저장된 상태를 다시 로드하므로 LLM은 정지 시점부터 생성 프로세스를 이어나가게 된다.
- 이러한 방식으로 context manager는 Agent의 요청이 일시적으로 중단되어도 중간 과정이 손실되지 않도록 보장하여 결과의 성능과 효율성을 저하시키지 않으면서 리소스 사용을 최적화한다.
- Context Window Management
- LLM의 Context Window 제한을 초과하는 긴 컨텍스트로 인해 발생하는 문제를 해결하기 위해 context manager 는 Context Window를 확장할 수 있어야 한다.
- AIOS의 context manager는 기본적인 텍스트 요약을 지원하고 Context Window를 관리하기 위해 다른 확장 기술을 사용한다.
- 방법이나 코드는 자세하게 설명하지 않고, 논문 2개를 인용했다.
- context manager는 CPU의 프로세스 간 context switching을 할 때 PCB를 활용하는 것과 같은 원리이다.
- 코드를 실제로 봐보면, 그냥 단순히 inference가 진행되는 도중의 파라미터를 save하는 것이다.
4.3 Memory Manager
- Memory Manager는 Agent의 수명 주기 내에서 short-term 메모리를 관리하여 Agent가 실행을 기다리는 동안이나 런타임 중인, 즉 Agent가 Active 상태인 동안에만 데이터가 저장되고 액세스할 수 있도록 보장한다.
- 현재 AIOS는 각 Agent의 메모리를 독립적으로 저장하는 것을 지원하며, 액세스 관리자가 승인하지 않는 한 다른 Agent는 직접 액세스할 수 없다.
- Agent 간 공유 메모리나 hierarchical cache와 같은 보다 복잡한 메모리 메커니즘은 향후에 연구할 예정이라고 한다.
- 다음에 소개되는 Storage Manager와 비교하여 Memory Manager는 빠른 데이터 검색 및 처리를 가능하게 하여 AIOS의 Storage에 과도한 부담을 주지 않으면서 사용자 쿼리 및 상호 작용에 대한 빠른 응답을 보장한다.
4.4 Storage Manager
- Storage Manager는 무기한으로 보관해야 하는 정보의 Storage를 관리하면서 데이터의 장기 보존을 담당한다.
- AIOS의 이러한 영구 저장은 로컬 파일, 데이터베이스 또는 클라우드 기반 솔루션과 같은 다양한 매체를 사용하여 향후 참조 또는 추가 분석을 할수 있게 보장한다.
- Storage Manager는 retrieval augmentation을 지원한다고 논문에는 나와있지만 아직 코드에 구현은 안되어 있다.
- 사용자 기본 설정을 저장하고 과거 interaction 로그를 유지함으로써 Storage Manager는 에이전트 지식 업데이트를 강화하고 장기적인 사용자 경험을 향상시킬 수 있다고 한다.
4.5 Tool Manager
- AIOS 시스템의 Tool Manager는 LLM의 기능을 향상시키는 다양한 API 도구를 관리한다.
- 위의 표에서 볼 수 있듯이 Tool Manager는 다양한 소스에서 일반적으로 사용되는 Tool을 통합하고 이를 웹 검색, 데이터베이스 검색, 이미지 처리 등을 포함하는 다양한 카테고리로 분류한다.
- 관리되는 Tool들은 입력 및 출력(이미지 및 텍스트)의 다양한 양식을 다룰 수 있으므로 AIOS 생태계 내에서 에이전트 개발을 촉진한다.
4.6 Access Manager
- Access Manager는 각 Agent에 대한 전용 권한 그룹을 관리하여 개별 Agent 간의 액세스 제어를 조정한다.
- Agent의 권한 그룹에서 제외된 다른 Agent는 대화 내역과 같은 해당 리소스에 대한 액세스가 거부된다.
- 시스템 투명성을 향상시키기 위해 Access Manager는 감사 로그를 컴파일하고 유지 관리한다.
- 이러한 로그에는 액세스 요청, Agent 활동 및 액세스 제어 매개변수 수정에 대한 자세한 정보가 캡처되어 잠재적인 권한 공격으로부터 보호하는 데 도움을 준다.
4.7 LLM System Call
- LLM 커널 내의 LLM 시스템 콜 인터페이스는 기본적인 LLM 호출 작업 기능을 제공하도록 설계되었다.
- 이 인터페이스는 복잡한 Agent 요청과 다양한 커널 모듈 실행 간의 연결을 하는 역할을 한다.
- 위 표는 LLM 시스템 콜들을 나열한 것이다. OS 시스템 콜과 유사하게 LLM 시스템 콜은 Agent 관리, 컨텍스트 처리, 메모리 및 저장, 액세스 제어를 포함하여 커널 모듈 전반에 걸쳐 기본 기능을 제공한다.
- LLM 시스템 콜 목록은 향후 더 확장할 것이라 한다.
4.8 AIOS SDK
- AIOS SDK는 개발자에게 AIOS 내에서 더 정교한 Agent 애플리케이션을 제작하기 위한 다목적 toolkit을 제공하도록 설계되었다.
- 이 SDK는 Agent 초기화 및 Agent lifecycle 관리부터 리소스 모니터링, Agent 강제종료 등 광범위한 기능을 포함한다.
- 이 또한 향후 계속 확장할 것이라고 한다.
- 이는 개발자에게 AIOS 프레임워크 내에서 Agent 애플리케이션의 잠재력을 최대한 활용하는 데 필요한 도구를 제공하는 것을 목표로 한다.
5 Evaluation
- 이 논문에서는 AIOS에서 여러 Agent가 병렬로 실행될 때, 단 2가지의 평가만을 진행하였다.
- Agent 요청에 대한 LLM의 결과에 대해서, Agent가 일시 중단된 후 다른 에이전트로 전환되는 context switching이 발생해도 그 결과가 일관성이 있는지 평가
- Agent 스케줄링을 하는 것의 성능이 순차적으로 Agent를 실행하는 것에 비해 더 좋은지 평가 (즉, waiting time과 turnaround time의 균형을 잘 맞추는가?)
- 결과 1
- BLEU score와 BERT score를 비교했을 때, context switching으로 Agent가 전환되면서 실행되어도 결과가 완벽하게 일치하는 것으로 나타났다.
- 결과 2
- FIFO 스케줄링을 사용한 AIOS와 스케줄링을 사용하지 않은 방식을 비교했을 때, 스케줄링을 사용하지 않으면 초기 Agent 성능이 잘 나오지만 뒤의 Agent의 waiting time과 turnaround time이 많이 길어진다. 하지만 AIOS로 FIFO 스케줄링을 사용하면 waiting time과 turnaround time의 균형을 잘 맞춰 효율성을 높인다.
6 Conclusions
- 본 논문은 AIOS 아키텍처를 제안하여 LLM 기반의 Agent의 개발과 배포를 용이하게 하는데 기여했다.
7 Future Work
- 더 발전된 스케줄링 알고리즘
- AIOS의 스케줄링 기능은 더욱 발전된 알고리즘을 도입하면 성능이 더 좋아질 수 있다.
- 향후 연구는 Agent의 request 간의 종속성 분석을 수행하여 computational resource 할당을 최적화하는 알고리즘을 개발할 수 있다.
- 또한 tool 리소스 중 일부는 로컬로 배포된 모델이기에 이는 스케줄링 기능에 통합될 수도 있습니다.
- 즉, tool의 상태에 대한 스냅샷 관리가 포함되어 Agent와 해당 tool 관리을 모두 포괄하는 통합 스케줄링 프레임워크로의 전환을 시도해 볼 수 있다.
- Context Management의 효율성
- Context Management를 지원하기 위해 보다 효율적인 메커니즘을 고안할 수 있습니다.
- 예를 들어, time-efficient한 Context Management 기술을 구현하여 컨텍스트 context snapshotting 및 restoration 프로세스를 가속화할 수 있다. 또한 스냅샷을 생성하기 전에 컨텍스트 압축 기술을 활용하여 보다 space-efficient 한 솔루션을 얻을 수 다.
- 메모리 및 스토리지 아키텍처 최적화
- Agent끼리의 협업과 통신의 맥락에서 메모리 및 스토리지 시스템은 공유 액세스 방식을 채택할 수 있다.
- 즉, Agent 간 메모리 및 스토리지 공유를 가능하게 할 수 있다. 이러한 아키텍처를 사용하면 에이전트가 공동 메모리 및 스토리지 풀에 액세스할 수 있으므로 한 에이전트가 다른 에이전트의 메모리 또는 스토리지를 활용할 수 있게 되어 에이전트의 의사 결정 가능성이 향상된다.
- 또한 향후에는 데이터 검색 및 저장 효율성을 최적화하도록 설계된 hierarchical storage 솔루션을 생각해볼 수 있다. 즉, 자주 액세스하는 데이터에 대해 더 빠른 액세스 우선 순위를 지정할 수 있고, 스토리지 할당을 줄일 수 있으며, 자주 액세스하지 않는 정보는 우선순위를 낮출 수 있다.
- 개인 정보 보호 강화
- 다양한 보안 공격에 대한 보호 조치가 필요하며 LLM jailbreaking 이나 다른 에이전트 메모리에 대한 무단 액세스와 같은 악의적인 공격에 대한 대책이 필요하다.
- 개인 정보 보호 영역에서 AIOS 내 데이터 전송을 보호하여 Agent 통신의 기밀을 유지하려면 고급 암호화 기술을 채택할 수 있다.
- 또한 워터마킹 기술을 구현하여 출력에 고유 식별자를 삽입하고 데이터 추적을 용이하게 하여 Agent 개발자의 지적 재산을 보호하는 데 도움이 될 수 있다.
<참고>
https://seonh.tistory.com/26#google_vignette
https://brunch.co.kr/@b2439ea8fc654b8/15
https://terms.tta.or.kr/dictionary/dictionaryView.do?subject=%EC%9C%A0%ED%9C%B4+%EC%8B%9C%EA%B0%84
https://velog.io/@taegon1998/5-Memory-Hierarchy
https://www.lakera.ai/blog/jailbreaking-large-language-models-guide
