학습 없이 LLM을 비동기 에이전트로 만드는 AsyncLLM 프레임워크

LLMs are General Asynchronous Agents

HF Daily2609.35427

George Yakushev, Denis Mazur, Vladimir Bartenev2026-09-28조회 4

무엇인가

현대 LLM 에이전트는 읽고, 생각하고, 답하거나 도구를 호출하는 순차적 상호작용 주기를 따른다. 전형적인 Thought-Action-Observation 루프다. 그런데 음성 비서, 자율주행, 임베디드 에이전트, 시스템 모니터링은 생각하는 도중에도 새 입력이 들어온다. 실시간 음성 비서는 말하면서 동시에 듣고 끼어들기를 처리해야 하고, 스트리밍 비디오는 모든 프레임을 실시간으로 처리할 수 없어 중요한 프레임만 골라내야 한다. 지금까지는 이 문제를 응용마다 별개의 연구 문제로 다뤘다. full-duplex 음성 모델, 로봇 제어용 VLA의 actor-thinker 이중 구조, 비동기 함수 호출, 병렬 서브에이전트가 각각 따로 설계되고 학습됐다. 이 논문은 비동기를 도메인별 기술의 모음이 아니라 일반 능력으로 취급할 수 있는지 묻는다. 도구 사용이나 few-shot 학습이 그랬던 것처럼, LLM이 적절한 프레이밍만 주어지면 인간의 비동기성을 모방할 수 있다는 가설이다.

어떻게 동작하나

제안하는 AsyncLLM은 Python asyncio의 async/await 프로그래밍 모델 위에 세워진다. 개발자나 에이전트 자신이 여러 개의 추론 코루틴을 정의하면 이들이 동시에 실행된다. 각 코루틴은 자기만의 CacheBlock에 메모리 상태를 쓰고, cache view를 통해 다른 코루틴의 블록을 읽는다. CacheBlock은 토큰 덩어리에 대한 attention KV 캐시와 Gated Delta Network(GDN)의 순환 상태를 담는다. 토큰을 주고받으며 통신하면 메모리 뷰가 바뀔 때마다 이전 토큰을 다시 인코딩해야 하지만, 메모리 블록을 직접 공유하면 즉시 동기화된다. 여러 블록에 attention하는 것은 그 블록들을 순차적으로 인코딩한 하나의 KV 캐시에 attention하는 것과 수학적으로 동등하다. 다만 여러 코루틴이 서로를 보면서 동시에 블록을 갱신하면 그 결과는 어떤 순차 추론과도 동등하지 않고, 저자들은 그럼에도 LLM이 읽을 수 있는 상태로 남는다고 말한다. create_block, clear, merge_blocks 같은 연산과 asyncio의 Event, Lock, Queue를 조합해 끼어들기나 GUI 팝업 같은 신호에 반응하는 에이전트를 표현한다.

무엇과 다른가

핵심 기술은 여러 캐시 블록을 동시에 보면서 forward pass를 돌리는 것이다. 전통적인 RoPE attention에서는 뒤따르는 블록의 키를 새 위치로 회전해야 하지만 그러면 매 forward마다 과거 KV 전체를 재배열해야 한다. 이 논문은 과거 KV를 0-based 위치에 고정해 두고 현재 쿼리만 각 블록의 상대 위치에 맞춰 회전하는 방식을 쓴다. 식 (1)의 관계, 즉 위치 i의 쿼리와 위치 j의 키에 대한 회전 내적이 위치 i−j의 쿼리와 위치 0의 키에 대한 내적과 같다는 성질이 그 근거다. 선형 attention과 GDN은 더 까다롭다. 각 블록을 초기 상태에서 최종 상태로 가는 아핀 전이 (Â, B̂) 쌍으로 요약하고, 두 블록 L과 R을 합성할 때 (Â_LÂ_R, B̂_LÂ_R + B̂_R)로 곱한다. 이러면 헤드당 O(토큰 수)가 아니라 O(블록 수) 행렬 연산으로 상태를 복원할 수 있고, 블록 순서가 달라지면 같은 행렬을 다른 순서로 곱하기만 하면 된다. KDA처럼 스칼라 감쇠 α를 대각 게이트 Diag(α)로 바꾼 변형도 같은 계산이 그대로 성립한다. 멀티모달 모델의 MRoPE는 시간축 상대 위치만 맞춰 쿼리를 회전하고 높이·너비 축은 그대로 두며, 이미지 토큰이 섞인 블록은 토큰 수가 아니라 실제 시간 위치 범위를 별도로 추적한다. 추론 엔진은 mini-SGLang 위에 만들어졌고, Paged Attention 페이지를 참조하는 가벼운 CacheBlock, 긴 prefill을 쪼개 디코딩과 같은 배치에 넣는 chunked prefilling, 빠른 응답 코루틴이 배경 작업에 막히지 않게 하는 균형 배치 스케줄링을 갖췄다.

어떻게 쓰나

실험은 주장을 하나씩 분리해 검증한다. 먼저 추론 도중 사용자 정정이 들어오는 가장 단순한 비동기 상황을 본다. MATH-500-Sharded는 500개 수학 문제를 불완전한 프롬프트와 정정으로 쪼갠 데이터셋으로, k번의 추론 스텝 뒤에 정정이 주어진다. 시각 입력 변화는 시각 QA와 수학 데이터셋에서 만든 513개 이미지 쌍으로 평가한다. 원본 이미지에 문제를 풀 수 없게 만드는 현실적인 오류를 편집해 두고, 에이전트가 그 이미지로 추론을 시작한 뒤 k 디코딩 스텝 후에 수정된 이미지로 교체하며 입력이 바뀌었다고 알린다. Qwen 3.x 하이브리드 MLLM 기반 AsyncLLM 에이전트는 텍스트와 이미지 양쪽에서 비동기 입력에 반응했다. 시각 쪽 정확도가 더 빨리 떨어지는데, 저자들은 시각 과제가 평균적으로 추론을 덜 요구해서 큰 k가 이미 답을 낸 뒤에 도착하는 경우가 있기 때문이라고 분석한다.

전제와 한계

연속 비디오 스트림에서는 SoccerNet-Caption 축구 해설 데이터셋과 ProactiveVideoQA를 쓴다. 에이전트는 다섯 개의 동시 컴포넌트로 구성된다. 매 프레임마다 새 이벤트가 있는지 판단하는 event probe, 트리거가 걸리면 프레임 쌍을 받아 영상 이벤트를 재구성하는 배경 thinker, 추론에 새 이벤트가 생겼는지 보는 output probe, thinker의 내부 상태에서 설명을 생성하는 description writer, 결과를 모으는 비-LLM output compiler다. probe는 별도 서브모듈을 학습시키는 대신 미리 채운 프롬프트로 베이스 LLM을 한 번 forward하는 학습 없는 방식이다. 비디오 스트리밍 전용으로 학습된 Mage-VL과 비교해 Qwen3.5+ 기반 AsyncLLM이 두 벤치마크 모두에서 앞섰다. 지표는 event probe ROC AUC, TriggerAcc, TimVal이고 ProactiveVideoQA에서는 권장 지연 가중치 ω=0.5의 Proactive AUC도 보고한다. SoccerNet 공식 프로토콜은 설명 품질을 측정하지 않지만 ProactiveVideoQA에서는 더 큰 Qwen3.5+ 모델이 설명도 더 정확했다. 저자들은 이를 Mage-VL의 약점이 아니라 범용 MLLM을 AsyncLLM에 넣었을 때 생기는 부수 효과로 본다. 추론 속도는 별도 표에 보고된다.

환경에 영향을 주는 에이전트는 Doom 기반 ViZDoom의 HealthGathering과 DeadlyCorridor(프레임 스킵 4)에서 평가한다. 배경 thinker가 행동 방침을 정하고 더 빠른 action 서브루틴이 early-exit probe로 행동을 프레임 단위로 변환한다. 순차 에이전트와 probe-only 에이전트를 베이스라인으로 두었는데, AsyncLLM 에이전트는 같은 모델의 순차 에이전트보다 훨씬 빠르게 반응하면서 추론에서 얻는 이득을 유지했다. 시스템 모니터링은 DevOps-Gym의 Monitoring 서브셋 34개 태스크에서 평가한다. 로그를 실시간으로 보고 메모리 누수나 파일 디스크립터 폭주 같은 이상을 탐지하는데, 정확도는 순차 베이스라인과 비슷하면서 응답이 유의하게 빨랐다. 이 태스크에서 AsyncLLM 에이전트는 평균 2.06개의 활성 코루틴을 가진다. 저자들은 주의를 분산시키지 않게 하는 프롬프트 문단을 넣지 않으면 Qwen 3.6-35B-A3B가 무관한 문제를 과하게 생각하다 실시간 로그를 따라가지 못해 정확도가 10% 미만으로 떨어졌다고 밝힌다.

개발자 입장에서 이 논문이 주는 실용적 신호는 두 가지다. 첫째, 실시간 음성·영상·모니터링 에이전트를 만들 때 태스크별 데이터와 파인튜닝 없이 기존 하이브리드·멀티모달 LLM을 비동기 에이전트로 재활용할 수 있다는 가능성이다. 에이전트 정의를 async/await 코드로 표현하고, 나아가 API로 에이전트 정의 자체를 넘기는 실시간 비동기 API도 구상할 수 있다. 둘째, KV 캐시와 GDN 순환 상태를 블록 단위로 합성하는 알고리즘 자체다. 자체 추론 엔진이나 에이전트 런타임을 만드는 팀이라면 캐시 뷰 합성, 블록별 아핀 전이, MRoPE 위치 범위 추적 같은 구현 세부가 참고 대상이다. 다만 실제 도입 전에는 자신의 워크로드에서 배치 스케줄링과 GPU 처리량이 감당 가능한지, 사용하는 모델의 하이브리드 attention 변형이 지원되는지 확인해야 한다.

저자들이 명시한 한계도 분명하다. 에이전트가 스스로 코루틴을 정의하고 수정하는 능력은 아직 신뢰할 수 있는 수준이 아니라고 밝힌다. 환경 설명만으로 자기 적응형 에이전트를 만드는 것은 미래 세대 LLM의 가능성으로 남겨 둔다. 또 이런 범용 비동기 에이전트가 특정 도메인에 맞춰 학습된 모델을 항상 능가하지는 않는다고 인정한다. 비디오게임 실험 결과도 해당 환경의 최신 성능이 아니라 기본 능력을 보여준 것에 불과하다. 에이전트가 스스로 코루틴을 정의한 실험은 HealthGathering에서는 좋은 초기 결과를 냈지만 DeadlyCorridor에서는 열등했다. 향후 연구 방향으로는 도구 사용 에이전트를 학습시키듯 일반 비동기 에이전트를 학습시키는 것, 그리고 주어진 시나리오에 맞게 스스로 코루틴을 개선하는 능력을 더 파고드는 것을 제안한다.