FlashEvolve: 에이전트 진화를 위한 비동기 실행 프레임워크

LLM 기반의 에이전트 진화는 워크플로의 단계 간 의존성과 샘플 길이의 불균형으로 인해 wall-clock 비용이 크게 증가한다. FlashEvolve는 워커와 큐를 활용한 비동기 실행으로 단계 간 중첩 실행을 가능하게 하여 진화 루프의 처리량과 토큰 효율을 높이고, artifact의 버전 차이에 따른 스테일니스 관리와 패치 기법으로 품질 저하를 방지한다. GEPA 계열 워크로드에서 제안(Proposal) 처리량이 크게 증가하고, API 기반 서비스에서도 개선 효과가 확인된다.

1. 문제 정의: 에이전트 진화 루프는 Generate/Propose/Evaluate 등의 LLM-heavy 단계로 구성되며, 이들 간의 순차적 의존성은 실행 시간을 증가시킨다. 또한 각 단계 내부의 길이-긴-tail 샘플은 배치의 실제 효율을 떨어뜨린다. 2) 해결 원리: 비동기 워커와 큐를 이용해 각 단계와 진화 단계를 중첩 실행하고, artefact의 pool 버전 정보를 이용해 아이템의 스테일니스를 판단한다. 3) 핵심 정책: Full Async은 최대 처리량을 추구하나 오래된 업데이트의 주입이 가능하고, Guarded Async는 Δmax를 넘으면 폐기한다. Reflective Async는 낡은 아이템을 패치하고 재사용 가능한 정보를 추출한다. 4) 추가 기법: Speculative Stage Completion은 초기 출력을 조기 전달해 대기 시간을 감소시키고, Validation-set Reordering은 Prefix를 더욱 discriminative하게 만들어 초기 신호의 품질을 높인다. 5) 효과: Adaptive Workflow Control로 각 단계의 생산 속도를 균형화하고, 워크플로의 전반적 처리량과 품질을 동시에 개선한다.

대상 아키텍처는 비동기 워커-큐 구조로 구성되며, 각 단계 i에 Ki개의 워커를 배치한다. 아이템 i가 생성될 때는 artifact state와 vi를 포함하고, pool 업데이트 후 v로 버전이 증가한다. 버전 차이 Δi = v − vi를 추적하고, 정책에 따라 아이템의 진행 여부를 결정한다. 수식적으로 Δi가 Δmax 이하면 아이템을 계속 진행하고, 그보다 크면 폐기한다. Reflective Async는 낡은 아이템에 대해 반영 작업을 수행하여 현재 풀에 맞춰 패치가 가능한 경우에는 패치를 적용한다. Speculative Stage Completion에서 αspec ∈ (0,1]인 경우, 요청의 일부가 먼저 완료되면 임시 큐 아이템으로 다음 큐로 전달하고, 이후 전체 평가 완료 시 확정한다. Validation-set의 순서는 과거 성공 기록을 바탕으로 재정렬되어 초기 프리픽의 신호를 강화한다. Adaptive Control은 각 Stage의 생산 속도를 계산하고 중간값의 절반보다 낮으면 Ki를 증가시키고, 중간값의 두 배보다 높으면 Ki를 감소시키며, 각 단계의 최소/최대 Ki 범위를 유지한다. 구현은 파이썬 기반의 경량 스레드와 in-process 큐를 사용하며, 동일한 DSPy 클라이언트를 통해 vLLM(OpenAI 호환 엔드포인트)을 호출한다. 벤치마크 비교를 위해 오픈 소스 Baseline과 동일한 LLM 서빙 스택을 사용한다. 수집되는 지표는 LLM Throughput(token/s), Proposal Throughput(proposal/min) 및 30분/180분 간의 Validation Score 등이다.

주요 벤치마크에서 FlashEvolve의 향상치를 제시한다. 로컬 vLLM에서 GEPA 대비 LLM Throughput은 평균 3.4× 증가, Proposal Throughput은 평균 3.5× 증가, API 기반 서빙에서 각각 2.9× 및 8.4× 향상이다. 4개 데이터셋(IFBench, HotpotQA, HoVer, AIME)에서 FlashEvolve의 LLM Throughput은 2688, 93, 1255, 998(token/s)로 나타났고, Proposal Throughput은 8.9, 8.8, 5.9, 11.4(제안/min)로 기록된다. 30분 예측에서 FlashEvolve의 평균 Evolution Rate은 1.43×로 나타났으며, IFBench의 경우 2.27×, HoVer는 1.15×의 개선을 보였다. 180분 장기 실행에서는 IFBench에서 39.3분에 91%의 점수에 도달하고 HotpotQA에서 56.1분에 66.41%의 점수를 유지한다. ACE/Formula FiNER 및 Formula에서의 벤치에서도 FlashEvolve가 개선된 점수를 기록했다. ACE FiNER/Formula에서 각각 더 높은 검증 점수를 달성했고, Meta-Harness에 대해서도 4.7×의 속도up를 보였다.

아키텍처 수준의 상세를 담은 기술 요소들. (1) 비동기 실행 구조: 각 스테이지에 입력 큐와 워커 풀을 두고, 큐 아이템은 artifact 상태와 버전 vi를 포함한다. pool 업데이트마다 버전이 증가하며, vi와 v를 비교해 아이템의 신선도를 판단한다. (2) 수학적 기반: Δi = v − vi, Full Async은 Δi 무시, Guarded Async은 Δi ≤ Δmax를 만족해야 진행, Reflective Async은 낡은 아이템을 반영(worker)하여 패치 후 진행 여부를 재평가한다. (3) 스펙ulative 완료: αspec ∈ (0,1], rollout에서 일부 샘플은 먼저 전달되고, 평가에서도 임계점을 넘어가면 수정된 아이템으로 반영한다. (4) 검증 세트 재정렬: 프리픽의 샘플들을 pass history에 따라 재배열하여 초기 평가 신호의 품질을 높인다. (5) 적응형 워크플로 제어: 생산 속도를 이용한 Ki 조정 규칙(Ki는 중앙값의 반/배에 따라 증가/감소)으로 각 단계의 처리율을 균형화한다. (6) 구현 세부: Python으로 경량 스레드 및 in-process 큐를 사용하며, 동일한 vLLM 서버 및 DSPy 클라이언트를 통해 오프라인/온라인 양쪽에서 비교 가능하도록 구성한다.