Measuring the real concurrency ceiling of an LLM agent runner

개요

LLM 에이전트 러너의 동시성 한계를 테스트하기 위한 벤치마크 결과, 로컬 모델 서버인 Ollama가 병목 현상의 주된 원인이며, 코딩 작업의 동시성 문제는 실제 시스템 용량이 아닌 스케줄링 정책에 의해 제한됨을 밝혔다.

주요 내용

- 벤치마크 설정: N개의 동시 채팅 세션을 러너에 실행시키고, 각 턴마다 로컬 Ollama(hermes3)와 상호작용하는 전체 파이프라인(의도 분류, 응답 생성, 메모리 추출)을 테스트했다.
- 측정 지표:
* ttfa (Time to First Activity): POST 요청부터 러너 내부 첫 이벤트 발생까지의 시간.
* first-Ollama: POST 요청부터 모델 큐에 첫 요청이 도달하기까지의 시간.
* done: POST 요청부터 사용자가 응답을 받기까지의 총 시간.
* wall (drained): POST 요청부터 백그라운드 메모리 추출 작업까지 완료되는 총 시간.
- 테스트 결과 (N=4 기준):
* ttfa는 0.0s로 일정했으며, 러너의 이벤트 루프는 병목이 아니었다.
* CPU 사용률은 최대 63%, RAM은 5.9GB 이상으로 하드웨어 한계도 아니었다.
* done 시간은 N=1 대비 4.8배 증가하여, 동시 요청이 순차 처리보다 느린 현상이 발생했다.
* 병목 지점은 Ollama의 내부 요청 큐였으며, wall (drained) 지표는 사용자가 응답을 받은 후에도 백그라운드 메모리 추출이 Ollama를 포화시킴을 보여주었다.
- 코딩 작업 동시성 문제:
* 코딩 작업은 Ollama 대신 Claude API를 사용하며, MAX_CONCURRENT_JOBS 환경 변수와 무관하게 repoHasRunningJob(job.repo) 조건으로 인해 각 저장소(repository)당 하나의 작업만 실행되는 정책적 제한이 있었다.
* 이는 동일 저장소에서 브랜치를 따는 AI 에이전트 간의 병합 충돌을 방지하기 위한 합당한 이유에서 비롯된 정책이었으나, 시스템 능력의 한계가 아닌 정책에 의한 제약이었다.
- 스마트 병렬 처리 규칙 (Disjoint Path Rule):
* 병합 충돌 없이 코딩 작업 동시성을 개선하기 위해, 기존의 "저장소당 하나의 작업" 규칙을 파일 경로 중복 여부로 대체했다.
* 두 작업이 동시에 실행되려면 Disjoint Named Paths, No Dependency Edges, Historical Touched Files의 세 가지 조건을 모두 만족해야 한다.
* 모호한 경우, 스케줄러는 안전을 위해 순차 실행을 기본값으로 한다.

시사점

LLM 에이전트 러너의 실제 병목 지점은 추정과는 달리 로컬 모델 서버(Ollama) 또는 스케줄링 정책에 있음을 벤치마크를 통해 명확히 확인할 수 있었으며, 동시성 문제를 해결하기 위해서는 단순히 코드 최적화나 하드웨어 증설보다는 실제 병목 요인을 정확히 측정하고 정책을 개선하는 것이 중요함을 시사한다.