AI 에이전트가 답을 빠르게 생성한다고 해서 사용자가 맡긴 작업도 빨리 끝나는 것은 아닙니다. 모델을 호출해 다음 행동을 정하고, 도구의 결과를 받은 뒤 다시 모델을 호출하는 동안 추론 서버의 대기열에 여러 번 들어가기 때문입니다. 여러 에이전트를 병렬로 실행한 뒤 결과를 합치는 작업이라면 마지막 호출 하나가 늦어지는 것만으로 전체 완료가 밀릴 수 있습니다.
UC 버클리, Google DeepMind, 상하이교통대 연구진이 NSDI 2026에서 발표한 Agentix는 이 반복 대기를 프로그램 단위로 관리합니다[1]. 새로 들어온 호출만 보는 대신 그 호출을 보낸 프로그램이 이전까지 사용한 실행 시간을 함께 봅니다. 오래 실행된 프로그램이 다음 호출을 보낼 때마다 새 작업과 같은 우선권을 얻는 문제를 줄이는 방식입니다.
논문은 추론 시스템의 프로토타입과 실험 결과를 제시합니다. Google의 실제 에이전트 서비스에 배포됐다는 근거는 아닙니다. 또한 보고된 처리량 개선에는 프로그램 단위 우선순위 외에 캐시와 메모리 이동 최적화가 함께 들어 있으므로, 큰 배수 하나를 스케줄링 알고리즘만의 효과로 읽어서는 안 됩니다.
개별 요청 대기열에서 사라지는 작업의 맥락
일반적인 추론 서버는 요청의 도착 시각, 입력 길이, 생성 중인 토큰과 캐시 점유량을 확인할 수 있습니다. 그러나 프로그램 식별자가 없다면 처음 시작한 짧은 작업의 호출과, 이미 열아홉 번 실행한 긴 작업의 스무 번째 호출을 구분하기 어렵습니다. API로 전달된 요청의 모양은 같아도 사용자가 기다리는 작업에서 차지하는 위치는 다릅니다.
먼저 도착한 호출을 계속 실행하는 정책에서는 긴 디코딩이 배치의 자리를 차지해 짧은 호출을 지연시킬 수 있습니다. 실행 중인 호출을 잠시 멈추고 다른 호출을 넣는 선점은 이 문제를 줄입니다. 다만 새 호출을 무조건 높은 우선순위에 넣으면 긴 프로그램이 후속 호출을 보낼 때마다 다시 앞자리를 얻습니다.
따라서 현재 호출 안에서 발생하는 대기와 여러 호출에 걸쳐 누적되는 대기를 나눠야 합니다. 전자는 긴 호출을 적절히 선점하는 것으로 개선할 수 있지만, 후자는 프로그램의 이전 실행까지 알아야 처리할 수 있습니다. 호출별 지연만 줄였는데도 짧은 사용자 작업이 늦게 끝나는 이유가 여기에 있습니다.
이 차이는 GPU 활용에도 영향을 줍니다. 어떤 호출이 끝나야 그 결과에 의존하는 다음 호출이 도착하기 때문입니다. 필요한 호출을 계속 미루면 배치에 넣을 수 있었던 후속 작업도 아직 준비되지 않습니다. Agentix는 대기 감소를 처리량과 별개의 목표로만 보지 않고, 실행 가능한 작업이 도착하는 시점 자체를 바꾸는 수단으로 다룹니다.
다음 호출까지 이어지는 실행 이력
Agentix는 프로그램이 시작할 때 세션을 만들고, 프로세스 테이블에 실행과 대기 이력을 저장합니다. 프로그램은 추론 서버 밖에서 실행되며 실제 제어 흐름에 따라 호출을 보냅니다. 서버가 앞으로 실행될 모든 분기와 반복을 미리 전달받아야 하는 구조는 아닙니다.
순차적으로 동작하는 프로그램에서는 완료된 LLM 호출의 실행 시간을 누적합니다. 다음 호출이 도착하면 이 값을 우선순위 계산의 출발점으로 사용합니다. 이미 많은 연산을 받은 프로그램이 API를 한 번 더 호출했다는 이유만으로 이전 이력을 지우고 다시 높은 우선권을 얻지 않도록 하는 것입니다.
이 방식은 남은 실행 시간을 정확히 예측하지는 않습니다. 지금까지 조금 실행한 프로그램이 앞으로 길어질 수도 있고, 오래 실행한 프로그램이 마지막 호출 하나만 남겼을 수도 있습니다. 관측한 실행량을 활용하는 정책이지 미래를 알고 가장 빨리 끝날 작업을 항상 고르는 정책은 아닙니다. 논문 부록에서도 미래 실행을 아는 시뮬레이션 정책과의 성능 차이가 남습니다.
운영 환경에서는 무엇을 하나의 프로그램으로 볼지도 정해야 합니다. 사용자 대화 전체를 묶을지, 개별 조사 요청을 묶을지에 따라 누적 이력이 달라집니다. 정상 종료뿐 아니라 오류와 취소에도 세션을 정리해야 하며, 재시도가 같은 작업의 연속인지 새로운 작업인지 일관되게 구분해야 합니다. 식별자 설계가 우선순위의 의미를 바꾸는 셈입니다.
순차 호출과 병렬 프로그램의 다른 계산
PLAS는 순차 프로그램이 지금까지 사용한 실행 시간을 기준으로 호출을 분류합니다. 이미 받은 서비스가 적은 작업을 우선하는 방식이지만, 개별 호출이 끝나도 프로그램의 기록을 유지한다는 점이 중요합니다. 짧은 호출을 여러 번 생성하는 긴 프로그램이 매번 신규 작업으로 취급되는 현상을 막습니다.
병렬 프로그램에서는 모든 호출의 실행 시간을 단순히 더하는 것만으로 완료 시간을 설명하기 어렵습니다. 여러 분기가 동시에 진행되고 결과를 합치는 지점에서 가장 늦은 분기를 기다릴 수 있기 때문입니다. 총 연산량과 순차 의존성 때문에 반드시 기다려야 하는 시간은 서로 다릅니다.
ATLAS는 프로그램에서 관측된 가장 긴 실행 경로의 누적 시간을 하나의 값으로 관리합니다. 실행 중인 호출은 현재 프로그램 값을 받아 시작하고, 완료 시 더 긴 경로가 관측되면 값을 갱신합니다. 미래의 전체 의존 관계를 미리 알아내는 방식이 아니라 실행이 진행되면서 얻은 정보로 프로그램의 진행 상태를 근사합니다.
같은 프로그램에서 갈라진 호출들이 비슷한 우선순위를 받으면 일부 분기만 뒤에 남아 결과 합치기를 지연시키는 상황도 줄일 수 있습니다. 그렇다고 병렬 분기를 늘리는 만큼 처리 자원이 생기는 것은 아닙니다. 활성 호출 수가 늘면 KV 캐시도 늘어나므로, 동시에 진행할 수 있는 분기 수는 배치와 메모리 여유의 제약을 받습니다.
선점 효과를 좌우하는 KV 캐시 이동
Agentix는 우선순위 값을 여러 단계의 대기열로 나눠 사용합니다. 호출에 일정 실행 시간을 주고, 이를 사용하면 낮은 우선순위로 이동시킵니다. 미세한 우선순위 변화마다 실행 대상을 바꾸면 문맥 교체가 잦아져 오히려 비용이 커질 수 있기 때문입니다.
긴 프로그램이 계속 밀리는 문제에는 누적 대기 시간과 실행 시간의 비율을 사용합니다. 비율이 기준을 넘으면 호출을 승격해 진행 기회를 줍니다. 이 기준을 바꾸면 짧은 작업을 먼저 끝내는 효과와 오래 기다린 작업을 보호하는 정도가 달라집니다. 다만 이것이 고객별 요금제나 자원 사용량까지 포함한 완전한 공정성 정책을 뜻하지는 않습니다.
선점된 호출의 KV 캐시는 사라지지 않습니다. GPU 메모리에 둘 수 없으면 호스트 메모리로 옮기고 나중에 다시 가져와야 합니다. 작은 블록을 각각 전송하면 복사 호출과 전송 설정 비용이 반복됩니다. Agentix는 블록을 모아 전송하고, 여러 디코딩 단계를 진행한 뒤 스케줄러를 실행하는 최적화를 함께 적용합니다.
따라서 대기열 순서만 바꾸고 기존의 비효율적인 캐시 이동을 그대로 두면 논문과 다른 결과가 나올 수 있습니다. 반대로 비교할 최신 엔진이 이미 캐시와 전송 경로를 개선했다면 추가로 얻을 효과가 작아질 수 있습니다. 같은 메모리 한도와 요청 조건에서 전체 구현을 비교해야 스케줄링 변경의 실익을 알 수 있습니다.
긴 프롬프트는 재사용하고 짧은 호출은 분산하는 정책
프로그램의 후속 호출에는 이전 대화와 도구 결과가 누적되는 경우가 많습니다. 해당 접두부의 KV 캐시를 가진 엔진으로 보내면 프리필 계산을 반복하지 않을 수 있습니다. 모든 호출을 대기열 길이만 보고 분산하면 부하는 고르게 보여도 재사용할 수 있었던 계산을 다시 수행하게 됩니다.
Agentix는 짧은 프롬프트를 다르게 처리합니다. 시험한 트레이스에서는 여러 프로그램이 공유하는 시스템 프롬프트가 짧은 요청의 상당 부분을 차지해 다른 엔진에서도 캐시를 재사용할 가능성이 있었습니다. 이에 짧은 호출은 부하가 적은 엔진으로 보내고, 긴 호출은 해당 프로그램이 사용하던 엔진에 유지하는 정책을 사용합니다.
구현의 구분 기준은 2,048토큰입니다. 이 값은 해당 트레이스에서 정한 것으로 GPU의 고정 특성이나 모든 에이전트의 공통 기준이 아닙니다. 도구 명세가 길거나 검색 결과가 크게 바뀌는 서비스에서는 같은 프로그램이어도 접두부 재사용률이 다를 수 있습니다. 프로그램 식별자는 캐시 지역성을 추정하는 수단이지 동일한 프롬프트를 보장하는 정보는 아닙니다.
다중 엔진 실험은 프로그램 단위 스케줄러를 유지한 상태에서 라우팅 정책을 비교합니다. 본문의 결과는 단순한 분산 정책 대비 최대 1.4배 처리량을 보고하며, 접두부 정보를 더 자세히 관리하는 비교 방식과 가까운 성능을 보입니다. 이 배수를 기본 vLLM과의 전체 시스템 비교에 다시 더해 해석해서는 안 됩니다.
처리량 배수에 앞서 확인할 실험 조건
평가에는 80GB A100 GPU를 사용합니다. Llama 3.1 8B는 한 장, 70B는 네 장, Falcon 180B는 여덟 장에서 실행합니다. ShareGPT의 대화 전체, BFCL의 함수 호출 작업, LATS의 트리 탐색 프로그램을 재생하고 세 종류를 같은 비율로 섞은 조건도 시험합니다. 도착 시각은 개별 호출이 아니라 프로그램을 단위로 포아송 분포에 따라 만듭니다.
프로그램당 평균 호출 수는 ShareGPT 약 6.66회, BFCL 10.75회, LATS 159.7회로 차이가 큽니다. 호출 횟수뿐 아니라 프리필과 디코딩 길이, 병렬 분기와 캐시 재사용 가능성도 다릅니다. 특히 세 종류를 같은 비율로 섞은 실험은 이질적인 프로그램을 처리하는 능력을 확인하는 조건이며, 실제 상용 서비스의 요청 비율을 측정한 결과는 아닙니다.
주요 지연 지표는 프로그램의 응답 시간을 생성 토큰 수로 나눈 뒤 평균한 값입니다. 병렬 프로그램에서는 완료를 결정하는 경로의 응답 시간을 전체 스레드의 생성 토큰으로 나눕니다. 개별 스트리밍 응답의 토큰 간 지연과는 다르며, 사용자가 요구하는 절대 완료 시간과도 별도로 확인해야 합니다. 토큰 수가 다른 작업을 비교할 때는 정규화 방식이 결과 해석에 영향을 줍니다.
비교 기준은 vLLM 0.6.1과 여기에 청크 프리필, 접두부 캐시, 다단계 스케줄링을 켠 최적화 구성입니다. 혼합 작업에서 보고한 최대 처리량 개선은 기본 vLLM 대비 15배, 최적화 구성 대비 5배입니다. 앞의 수치에는 비교 시스템에 빠져 있던 최적화의 영향도 들어 있으므로, 현재 운영 중인 모든 추론 엔진을 스케줄러 하나로 15배 빠르게 만들 수 있다는 의미는 아닙니다.
긴 지연과 일괄 처리 결과도 별도로 봐야 합니다. 논문은 비교한 꼬리 지연 조건 여덟 개 중 일곱 개에서 개선된 P95/P99 결과를 보고합니다. 모든 프로그램을 처음에 함께 제출하는 오프라인 시험에서는 전체 완료 시간이 10~40% 줄었습니다. 이 결과가 개별 긴 프로그램의 개선을 항상 보장하거나 첫 토큰 응답 시간을 대신하는 것은 아닙니다.
실제 서비스에 적용하기 위한 측정 순서
에이전트의 대기 시간 중 추론 서버 밖에서 발생하는 부분은 이 스케줄러가 줄일 수 없습니다. 검색 API, 데이터베이스, 브라우저 작업이나 사람의 입력을 기다리는 시간이 길다면 내부 대기열의 큰 개선이 사용자 완료 시간에는 작게 반영될 수 있습니다. 먼저 모델 실행, 서버 대기, KV 이동, 외부 도구 시간을 구분해야 하는 이유입니다.
세션을 운영하는 방식도 검증 대상입니다. 재시도 때마다 새로운 식별자를 만들면 누적 이력이 사라지고, 서로 독립적인 요청을 계속 같은 세션에 넣으면 오래된 작업으로 취급될 수 있습니다. 사용자가 식별자를 바꿔 우선순위를 조작하지 못하도록 인증과 자원 사용 기록도 연결해야 합니다. 이는 구조에서 도출되는 운영상의 과제이며 논문의 처리량 그래프가 검증한 기능은 아닙니다.
도입 시험에서는 현재 엔진의 최적화를 유지한 채 프로그램 단위 추적부터 추가하는 편이 합리적입니다. 동일한 출력 품질과 메모리 한도에서 작업 완료 수, 절대 완료 시간, 스트리밍 지연을 함께 비교하면 반복 대기가 실제 병목인지 확인할 수 있습니다. 짧은 작업이 빨라지는 동안 긴 작업의 진행이 과도하게 늦어지지 않는지도 같은 부하에서 점검해야 합니다.
Agentix의 핵심은 프롬프트 하나보다 큰 단위의 실행 이력을 추론 인프라가 이해해야 한다는 데 있습니다. 미래 실행을 정확히 알지 못해도 이전 호출의 연산량을 다음 결정에 반영할 수 있음을 보여 줍니다. 그 효과가 실제 수용 가능한 서비스 용량으로 이어지는지는 프로그램 구성, 선점에 필요한 메모리 이동, 추론 서버 밖에서 남는 대기 시간에 달려 있습니다.
출처와 저작권 안내
이 글은 NSDI 2026 최종 논문을 바탕으로 독립적으로 작성한 편집 분석입니다. 수치는 원문의 시험 결과이며 도입 조건과 운영상의 해석은 이를 바탕으로 한 분석입니다. 원문 저작권은 USENIX 출판 조건에 따라 저자에게 있으며 © 2026입니다. 도판은 모두 새로 제작했으며 원문의 그림, 표 배치와 출판사 이미지를 복제하지 않았습니다.