LLM WikiAccess-protected knowledge portal

WIKI

AOSpec: 에이전트 LLM 서빙에서 행동과 관측을 동시에 투기하여 TAO 루프 지연을 줄이는 방법

AOSpec 에이전트 LLM 서빙에서 행동과 관측을 동시에 투기하여 TAO 루프 지연을 줄이는 방법 요약 에이전트 LLM 서빙의 기본 구조는 TAO 루프 Think→Act→Observe 다. LLM이 추론을 마치면 도구를 호출하고 Act , 도구가 실행되는 동안 GPU는 유휴 상태로 대기한 뒤, 결과를 받아 다시 추론을 이어간다 Observe . 이 직렬 구조에서 도구 실행 대기 시간은 사용자가 체감하는 지연의 상당 부분을 차

경로human/study/content/ai-frontier/144-aospec-action-observation-co-speculation-agent-serving.md
카테고리Study
태그#action #agent #ai-review #observation #serving #speculation #study

# AOSpec: 에이전트 LLM 서빙에서 행동과 관측을 동시에 투기하여 TAO 루프 지연을 줄이는 방법

요약

에이전트 LLM 서빙의 기본 구조는 TAO 루프(Think→Act→Observe)다. LLM이 추론을 마치면 도구를 호출하고(Act), 도구가 실행되는 동안 GPU는 유휴 상태로 대기한 뒤, 결과를 받아 다시 추론을 이어간다(Observe). 이 직렬 구조에서 도구 실행 대기 시간은 사용자가 체감하는 지연의 상당 부분을 차지한다.

2026년 8월 arXiv에 제출된 AOSpec(arXiv:2608.00881)은 이 문제를 공동 투기(co-speculation)로 접근한다. LLM이 도구 호출(action)을 생성하는 도중에 두 가지를 동시에 예측한다: (1) 어떤 도구 호출이 완성될 것인지(Action Speculation), (2) 그 도구가 어떤 결과를 반환할 것인지(Observation Speculation). 두 투기가 모두 맞으면 실제 도구 응답을 기다리지 않고도 다음 LLM 생성 단계를 앞당길 수 있다.

저자는 Hao Mark Chen, Jinnan Guo, Wayne Luk, Hongxiang Fan이다.

왜 TAO 루프의 직렬성이 문제인가

에이전트 워크로드의 시간 분포

일반 LLM 완성 요청과 달리 에이전트 워크로드는 다음 단계를 반복한다:

  1. Think: LLM이 맥락을 처리하고 다음 행동을 결정한다 (GPU 연산)
  2. Act: LLM이 도구 호출 문자열(함수명 + 인수)을 생성한다 (GPU 연산)
  3. 대기: 외부 도구가 실행된다 (GPU 유휴 — 파일 검색, API 호출, 코드 실행 등)
  4. Observe: LLM이 도구 결과를 컨텍스트로 받아 추론을 이어간다 (GPU 연산)

Claude Code나 GitHub Copilot 같은 코딩 에이전트 워크플로에서 도구 실행 대기 시간이 전체 요청 지연의 40–60%를 차지하는 경우가 많다. 도구 자체가 빠르더라도 — 예컨대 파일 읽기 수 밀리초 — 사용자 관점 TTFT(Time to First Token)는 이 대기 시간이 끝날 때까지 멈춘다.

기존 접근법의 한계

선행 연구들은 이 문제의 일부만 다뤘다:

AOSpec의 차별점은 행동(action)과 관측(observation)을 함께(co-) 투기한다는 것이다.

AOSpec의 핵심 구조

Action Speculation

LLM이 도구 호출 토큰을 생성하기 시작하면, 함수명과 인수 일부만 보고도 전체 호출을 예측할 수 있는 경우가 많다. 예를 들어 read_file(path= 다음에 어떤 경로가 올지는 현재 대화 맥락에서 높은 확률로 좁혀진다.

AOSpec의 Action Speculator는 생성 중인 토큰 스트림을 실시간으로 관찰해 완성된 도구 호출을 조기에 예측하고, 이를 즉시 실행 큐에 올린다. 이 점은 SPORK와 유사하지만, AOSpec은 여기서 멈추지 않는다.

Observation Speculation

도구 결과도 많은 경우 예측 가능한 구조를 갖는다. 파일 내용, API 응답, 코드 실행 결과는 이전 대화 이력과 맥락에서 근사값을 추정할 수 있다.

AOSpec의 Observation Speculator는 Action Speculation이 도구를 예측하는 동시에, 그 도구의 반환값을 별도로 추정한다. 이 추정값을 사용해 LLM이 도구 완료를 기다리지 않고 다음 Think 단계를 위한 KV 캐시를 미리 구성할 수 있다.

검증과 롤백

투기가 맞으면 지연 없이 결과를 확정한다. 틀리면 실제 도구 결과를 받아 해당 부분 KV 캐시를 폐기하고 정상 경로로 돌아간다. 이 롤백은 정확성에 영향을 주지 않는다 — 최종 LLM 출력은 항상 실제 도구 결과에 의존한다. 토큰 수준 투기 디코딩과 동일한 무손실(lossless) 보장 구조다.

TAO 루프 비교 다이어그램

표준 TAO 루프
↓
Think
LLM 추론 (GPU)
↓
Act
도구 호출 생성 (GPU)
↓
대기
도구 실행 (GPU 유휴)
↓
Observe
결과 처리 (GPU)
↓
다음 Think…
vs
AOSpec TAO 루프
↓
Think
LLM 추론 (GPU)
↓
공동 투기 구간
Act
도구 호출 생성 (GPU)
Action Speculator
도구 호출 예측
Observation Speculator
반환값 예측
↓
도구 실행 + 검증
투기 결과 확인
↓
Observe (단축)
KV 캐시 재사용 또는 갱신
↓
다음 Think (앞당겨짐)
표준 TAO 루프 vs AOSpec 공동 투기 비교

에이전트 서빙 투기 기법 지형도

AOSpec은 에이전트 LLM 서빙에서 투기 기법이 어느 계층에서 동작하는지를 기준으로 위치를 파악할 수 있다:

계층대표 연구투기 대상
토큰 수준EAGLE-3, DSpark다음 토큰
도구 호출 이름SPORK함수명 + 인수
샌드박스 기동SpecBoxMCP 컨테이너 워밍업
행동 + 관측AOSpec도구 호출 + 반환값
계획 수준IdleSpec다음 계획 단계

AOSpec은 도구 결과(observation) 수준까지 투기 범위를 확장한 첫 번째 연구다.

운영 함의

도구 결과 예측 가능성이 핵심

AOSpec의 이익은 observation의 예측 가능성에 달려 있다.

실제 배포에서는 도구별로 Observation Speculator의 적중률을 모니터링하고, 예측률이 낮은 도구에서는 speculation을 비활성화하는 것이 합리적이다. 적중률이 낮으면 KV 캐시 폐기 오버헤드가 이득보다 커질 수 있다.

토큰 수준 투기 디코딩과의 조합

AOSpec은 기존 토큰 수준 투기 디코딩(EAGLE, DSpark)과 직교적으로 동작한다. 두 기법을 함께 적용하면:

에이전트 서빙 스택(vLLM, SGLang)이 이 두 기법을 계층적으로 통합한다면 에이전트 워크플로의 종단 지연을 더 크게 줄일 수 있다.

멀티스텝 에이전트에서 효과 누적

멀티스텝 에이전트(코딩 에이전트, 리서치 에이전트)에서 AOSpec의 이익이 누적된다. 단계가 많을수록 절약된 대기 시간이 더해지기 때문이다. 반대로, 단일 도구 호출로 끝나는 단순 쿼리에서는 이익이 제한적이다.

Open Questions

References