TAO: Tool-Aware Joint Scheduling for LLM-Based Agentic Serving

논문 링크

TAO: LLM 기반 에이전트 서빙을 위한 도구 인지 통합 스케줄링

원문: Shuhuai Li 외, “TAO: Tool-Aware Joint Scheduling for LLM-Based Agentic Serving” (arXiv:2610.37230v1, preprint). 아래 서술은 첨부된 원문 텍스트만 근거로 한다.

도입

에이전트는 모델 추론과 외부 도구 실행을 번갈아 수행한다. 도구가 도는 동안 그 세션의 GPU 수요는 중단 가능해지며, 이 빈 구간을 어떻게 쓰고 세션이 돌아왔을 때 어느 노드에 붙이느냐가 응답 시간을 좌우한다. 이 논문은 두 문제를 하나의 스케줄링 문제로 묶는 프레임워크 TAO를 제안한다.

1. 문제: 도구가 도는 사이에는 GPU가 쉰다

1.1 세션과 CGDC

에이전트의 상호작용 전체를 하나의 세션(session) 으로 부르자. 세션은 모델 요청과 도구 호출을 오가며 이어지는 작업 단위다. 모델 요청 중에는 세션이 GPU 노드 하나를 점유하고, 도구 실행 중에는 추론 서비스 밖에서 결과를 기다린다.

논문은 이런 배치를 CGDC(Clustered GPUs with Distributed CPUs)라고 부른다. GPU는 노드에 몰려(clustered) 추론 용량을 공유하고, 도구는 그 바깥의 분산 CPU에서 돌아가며, 도구의 CPU·RAM은 GPU 수용 예산과 분리해 관리된다. 즉 GPU 예산에 들지 않는 시간이 존재하는 구조다.

역할 분담도 미리 정해져 있다. 스케줄러는 각 세션의 상태를 기록하고 세션 수용을 제어하며, 서빙 엔진은 물리적 KV 캐시의 상주와 evict을 관리한다(근거: §2.1).

1.2 비싼 것은 “KV 캐시를 다시 쓰지 못하는 것”

한 세션의 다음 요청은 앞선 턴이 만든 KV prefix를 그대로 쓸 수 있으면 prefill 계산을 통째로 건너뛴다. 그런데 그 prefix가 살아 있는지는 “어느 노드에 붙였느냐"와 “얼마나 지났느냐"로 정해진다. 도구가 끝나 돌아온 세션을 같은 노드에 다시 넣으면 캐시가 살아 있어 빠르고, 다른 노드로 보내거나 용량 압박으로 밀려나면 prefill를 다시 계산해야 한다.

반대로 활성 추론 세션을 쫓아내면 즉시 재계산이 필요하다. 재계산과 복원이 반복되면 재구축해야 할 상태에 용량을 낭비한다(근거: §2.1, §2.2).

1.3 interrupt와 restart

도구 경계에서 스케줄러가 할 수 있는 동작은 두 가지다.

• interrupt(중단): 도구 실행 중인 세션의 모델 수용을 해제해 노드 자원을 돌려준다.
• restart(재개): 도구가 끝난 세션을 적절한 노드에 다시 배정해 기존 상호작용을 이어간다.

두 동작은 세션의 상태 전이일 뿐 추론 엔진 구현과 분리된다. 논문의 출발점은 이 두 판단이 결국 같은 세션 평가로 환원된다는 점이다. interrupt 여부는 세션 값을 정렬해 정하고, interrupt된 세션은 새 도착 세션과 함께 대기 풀에 들어간다. 논문은 이 대기 풀에서의 통합 평가와 재개 결정을 함께 다룬다(근거: §2.2).

1.4 기존 스케줄러가 놓치는 두 가지

기존 서빙 시스템은 대체로 “먼저 평가하고 그 다음에 결정한다(evaluate-then-decide)” 패턴을 따른다. 세션 수준에서 노드 특징을 평가한 뒤, 어디에 언제 서빙할지를 정한다.

원문 Figure 1. 왼쪽 패널은 CGDC 구조를, 오른쪽 패널은 논문이 공략하는 두 문제를 보여준다.

• 문제 1 — 평가에서 도구 복귀 준비도를 놓친다. 도구 타이밍은 기존에도 쓰이지만 KV 재사용이나 토큰 수의 대리값으로만 쓰인다. 도구 소요시간을 예측해 KV 보존 시간을 정하거나, 도구 실행 중 세션의 토큰 수요를 시간에 따라 할인하는 식이다. 이런 값은 고정 점수 규칙이나 손으로 고른 임계값에 섞여 들어간다.
• 문제 2 — 결정을 세션별 휴리스틱으로 내린다. llm-d와 SGLang의 세션 단위 점수·라우팅 규칙은 개별 세션에게 추론 기회를 하나씩 배정한다. 그런데 세션들은 같은 노드 용량을 놓고 경쟁하므로, 한 세션을 받아들이는 순간 다른 세션들에는 더 값진 조합이 들어갈 자리가 사라질 수 있다. 오른쪽 패널의 “Short but Low Cache”, “Urgent but Tool Running”, “Session Still Waiting in Pool” 같은 표기가 이 착시를 가리킨다(근거: §1, §2.2).

2. 작은 예시: 세션 하나가 12초 동안 기다리는 동안

개념을 잡기 위해 가상의 코딩 세션 S를 따라가자. 이 절의 수치는 이해를 위한 가상 예시이며 원문 미보고다.

이 예에서 두 가지가 드러난다. 하나는 “살아 있는 캐시가 있는 노드로 돌아가느냐"가 응답 속도를 좌우한다는 점이고, 다른 하나는 “도구가 언제 끝나느냐"를 알면 그 직전에 S를 GPU 배치 후보로 올려 기다림을 없앨 수 있다는 점이다. 논문은 이 두 가지를 각각 ‘캐시 크레딧’과 ‘복귀 준비도’라는 값으로 만든다.

3. 방법

3.1 두 단계 파이프라인: 평가 → 결정

TAO는 두 단계로 동작한다. 먼저 대기 풀의 각 세션–노드 쌍에 값을 붙이고(평가), 그 값을 근거로 동적 계획법이 대기 중인 세션을 한 번에 선택·배치한다(결정). 평가와 결정을 분리해 둔 덕분에 값 함수를 바꿔도 스케줄링 절차는 그대로 유지된다(근거: §3.1).

  flowchart LR
    OBS["관측: 노드 b1의 잔여 KV와<br/>세션 S의 남은 도구 시간"] --> VAL["값 계산: k=감쇠된 캐시 크레딧, r=1(곧 복귀), t=토큰 수"]
    VAL --> DP["DP: 용량 상태별 최선 값을 저장하며<br/>S를 b1에 배정"]
    DP --> CHK["적용 직전 생존 상태와 재대조<br/>(선택 세션의 서명·자격 변경 시 계획 폐기)"]
    CHK --> RUN["b1이 S의 prefix를 재사용<br/>prefill 계산 생략, 첫 토큰 생성"]
    DP -. "b1 잔여 용량 부족" .-> BFD["BFD 폴백: b2에 배치<br/>prefill 재계산 필요"]
    BFD --> CHK

이 다이어그램의 구체적 수치는 2절 예시와 마찬가지로 원문 미보고다. 각 상자는 상태 변화다. 첫 상자는 관측값(잔여 캐시 토큰 수와 남은 도구 시간)이고, 두 번째 상자는 그것을 값으로 바꾼 결과이며, 세 번째 상자는 값에서 배정을 복원하는 과정이고, 마지막 상자는 실제 실행에서 일어나는 일이다. 점선은 용량이 부족해 다른 경로로 빠지는 경우다. 서빙 엔진의 역할(물리적 KV 할당·재사용·evict)은 사라지지 않는다. 스케줄러는 그 위에 “캐시가 어디에 남았고 언제 되찾을 수 있는가"를 값으로만 읽는다. 줄어드는 것은 캐시 재사용으로 사라지는 prefill 재계산과, 준비도로 사라지는 복귀 대기다.

3.2 세션–노드 쌍에 붙이는 값 세 개

각 세션 i와 노드 b 쌍에 논문은 세 값을 붙인다(근거: §3.2, 식 (2)).

• k_{i,b} — 노드 b에 남아 있는 세션 i의 캐시 크레딧. 관측이 오래될수록 작아진다.
• r_i — 복귀 준비도. 도구가 곧 끝나 세션 i가 곧 GPU를 다시 요구할 가능성이 있는지를 나타내는 0/1 신호.
• t_i — 세션 i의 토큰 수. 누적 컨텍스트 크기를 나타낸다.

핵심 설계는 이 셋을 가중합으로 섞지 않고 사전식(lexicographic) 순서로 비교한다는 점이다. 먼저 캐시 크레딧을 보고, 같으면 준비도를, 그것도 같으면 토큰 수를 본다. 순서 자체는 고정돼 있고 값만 시간에 따라 변한다. 논문은 이 순서를 세 가지 이유로 정당화한다(근거: §3.2). 첫째, prefix 재사용은 prefill 재계산을 그대로 없애므로 캐시 크레딧이 최우선이다. 둘째, 감쇠로 크레딧이 비슷해지면 준비도가 ‘곧 돌아오는 세션’과 ‘아직 멀리 있는 세션’을 구분한다. 셋째, 크레딧과 준비도가 동률이면 더 큰 누적 컨텍스트를 선호하되, 최적화기가 그 컨텍스트가 차지하는 용량 비용까지 함께 계산해 전체 배정 집합을 정한다.

배정의 제약은 다음과 같다(식 (1)). 세션 i는 노드 하나에만 들어갈 수 있고($\sum_b x_{i,b} \le 1$), 노드 b의 잔여 용량 C_b를 넘을 수 없으며($\sum_i w_i x_{i,b} \le C_b$), 자격이 없는 쌍에는 배정할 수 없다. 목표는 모든 쌍의 값을 사전식으로 합쳐 최대화하는 배정이다(식 (3)).

3.3 크레딧은 관측 나이에 따라 감쇠한다

노드가 관측한 캐시 토큰 수 k⁰를 그대로 쓰면 오래된 관측이 굳은 신호처럼 남는다. 논문은 관측 후 지난 시간 τ에 따라 $2^{-\tau/h}$를 곱해 크레딧을 계산한다(근거: §3.3, 식 (4)).

반감기 h는 10초로 두고, 계산한 크레딧은 평가에 쓰기 전에 반올림한다. 근거는 실측이다. 노드당 4×H100을 갖춘 두 노드의 DeepSeek-V4 Flash 트레이스에서 관측된 캐시 토큰 잔존량의 구간별 중앙값이 시간이 갈수록 뚜렷하게 줄어든다(원문 Figure 3). 중앙값은 채워진 구간을 대상으로 한 기술적 지수 적합으로 그려졌고 각 점에는 부트스트랩 95% 신뢰구간이 붙는다. 오래된 관측에 큰 가중치를 주면 틀린 결정을 하게 되므로 감쇠가 필요하다.

반감기는 스케줄러 파라미터일 뿐 트레이스에서 적합한 시간 상수와는 구별된다. 실제 캐시의 물리적 보관과 evict은 서빙 엔진이 그대로 담당한다.

3.4 준비도는 “곧 돌아오나"를 0/1로 알려 준다

준비도는 GPU가 곧 다시 필요한 세션을 찾아낸다. 도구 인터페이스가 진행이나 종료 시한을 노출하면 그것을 먼저 쓴다. Claude Code의 Monitor는 백그라운드 작업 이벤트를 전달하고, OpenCode는 Bash 타임아웃 뒤 종료 사실을 보고한다(근거: §3.4). 직접 타이밍 증거가 없으면 과거 도구 소요시간 기록으로 남은 시간을 추정한다. 추정 순서는 도구별 이력 → 전역 이력 → 5초 기본값이다. 완료된 호출들의 표본 수, 평균, 표본 분산, 관측 범위를 모아 유한표본 마진을 얹은 보수적 추정치를 만들고, 여기서 이미 흐른 시간을 빼고 0 이하로 자른다(식 (5), Appendix A).

남은 예측 시간이 수평선 H=1초 안으로 들어오면 r=1이 된다. 판단은 세 가지를 함께 쓴다(식 (6)). 도구 완료를 이미 관측했다면 r=1. 예측 시한이 지났는데 완료가 아직 관측되지 않으면, 무한정 ‘준비됨’으로 남아 있는 대신 임시 탐색(probe) 기회만 준다. 그 외에는 예측 타임스탬프가 30초 이내에 갱신된 경우에만 판단한다. 관측된 완료를 예측보다 우선한다.

이 신호는 스케줄링 주기(1초)와 연결된다. 준비도 1인 세션은 GPU 배치 후보로 끌어올려지고, 도구가 끝나자마자 첫 토큰을 내보낼 수 있게 된다.

3.5 동적 계획법으로 한 번에 선택·배치한다

값을 다 매기면 결정 문제는 “여러 배낭에 물건을 나눠 담는” 문제로 바뀐다. 각 노드 b는 잔여 용량 C_b를 가진 배낭이고, 각 세션 i는 수용 비용 w_i와 노드별 값 v_{i,b}를 가진 물건이다.

기존 방식의 문제는 이 문제를 세션별로 따로 풀었다는 점이다. 세션 하나하나를 순서대로 좋아 보이는 노드에 넣으면, 먼저 넣은 세션이 나중에 더 값진 조합이 들어갈 자리를 막는다.

논문은 용량을 일정 단위(양자 Δ)로 잘게 쪼갠 뒤, 후보를 하나씩 늘려가며 “지금까지 후보 j개로 각 용량 상태에서 얻을 수 있는 최선의 값"을 저장하는 DP로 동결·이산화된 스냅샷 위의 정확한 최적해를 구한다(근거: §3.5, 식 (7)).

여기서 $\bar{w}_i = \lceil w_i/\Delta\rceil$, $\bar{C}_b = \lfloor C_b/\Delta\rfloor$이고, $u_{j,b}$는 후보 j를 노드 b에 넣었을 때의 값과 개수를 담은 항이다. 각 후보마다 “건너뛰기"와 “b에 배정하기"를 모두 시도하므로 가능해는 빠짐없이 다뤄진다. 다만 반올림 때문에 이산화 전에는 실현 가능했던 계획이 배제될 수 있다.

계산은 격리된 비동기 워커에서 돌아가고, 적용 직전에 살아있는 상태(선택된 세션의 서명과 자격이 그대로인지)와 다시 대조한 뒤, 현재 용량이 허용하는 가장 긴 계획 접두사만 적용한다. 서명이 바뀌면 계획 전체를 버린다. 준비와 풀의 준비 비용은 4-복제 스윕에서 전체 실행 시간의 0.12% 미만이다(근거: §3.5, Appendix I).

노드별 캐시 관측은 O(nm) 전처리로 감쇠한 뒤 값에 접어들고, 캐시가 같은 노드들은 g ≤ m개의 용량 차원으로 묶을 수 있다(물리적 KV 블록을 옮기지 않는다). 상태 예산이 소진되면 best-fit-decreasing(BFD) 배치로 폴백한다. 수용 비용 w_i는 세션의 총 토큰 수에서 공유 토큰 용량을 뺀 메모리 수요로, C_b는 노드의 잔여 용량으로 매 스케줄링 시점마다 갱신된다(Appendix B.1).

DP가 실제로 다르게 고르는 것

원문 Figure 10. 각 프로그램은 서로 다른 색(hue)으로 구분되고, 반투명 구간은 그 프로그램의 수용 가중치, 진한 오버레이는 보존된 캐시 크레딧이다. 가로 축은 수용 가중치(천 토큰)이고 각 노드의 가로 막대 높이는 그 노드의 한계다.

• (a) short-first affinity greedy: 노드 1이 캐시 13.6k를 남기고 여유 8.4k, 노드 2는 여유 20.1k.
• (b) 동적 계획법: 캐시 16.8k(+3.2k, +23.2%)를 남기며, 노드 1의 여유는 1.4k로 줄고 노드 2의 여유는 27.1k로 늘어난다.

같은 총 안전 토큰 잔량을 유지하면서 DP가 더 많은 캐시 크레딧을 살린다. 정확한 값은 16,791토큰 대 13,624토큰이다(근거: Appendix H).

원문 Figure 11. 각 세션의 폭은 수용 가중치(512-토큰 예비량 포함)이고, 그 옆 숫자는 프로그램 ID와 캐시 크레딧이다.

• (a) short-first affinity greedy: 프로그램 6개를 수용하고, 긴 컨텍스트의 프로그램 177은 미룬다. 캐시 10,397토큰.
• (b) 동적 계획법: 프로그램 177을 포함해 7개를 수용한다. 캐시 14,949토큰.

즉 휴리스틱은 짧은 프로그램으로 자리를 채워 값진 세션을 밀어내는 반면, DP는 그 세션까지 받아들인다(근거: Appendix H).

4. 결과

4.1 지표와 비교 조건

지표는 셋이다. 지연(latency) 은 작업 종단 간 평균 시간(모델 추론 + 도구 실행 포함), TTFT 는 첫 토큰까지의 평균 시간, 디코드 처리율 은 초당 생성 토큰 수(TPS)다. 컴포넌트 분석에서는 prefix-cache 히트율, 도구 종료부터 첫 토큰까지의 지연, pause 대기를 추가로 잰다. pause 대기는 interrupt된 세션이 tool call 지연까지 포함해 기다린 시간이다.

비교 대상은 네 가지다. vLLM의 round-robin(RR)과 캐시 인지(CA) 스케줄러, KV 인지 스케줄러 Dynamo, 토큰 수 스케줄링에 BFD 배치를 쓰는 ThunderAgent. 배포는 DeepSeek-V4 Flash가 2노드×(노드당 H100 4장), Qwen3-32B가 4노드×(노드당 H100 2장), GLM-4.7이 1노드×8×H100(TP8)다. 워크로드는 mini-SWE-agent 하네스를 쓴 SWE-bench Lite(SWE-Lite)이며, DeepSeek은 Claude Code로 Terminal-Bench 2.0을, Qwen은 SWE-verified를 추가로 돈다(근거: §4.1).

논문은 12개의 모델–워크로드–동시성 설정에서 지연 최대 26.8% 감소, TTFT 최대 36.3% 감소, 디코드 처리율 최대 29.5% 증가를 보고하며, 비교 기준은 지표별 최선 평가 baseline이다(근거: 초록).

4.2 메인 결과: 어디서 이겼고 어디서 졌나

DeepSeek-V4 Flash의 SWE-Lite 결과에서 각 칸은 해당 지표의 최선 경쟁치 대비 개선 폭이다(근거: 원문 Table 1).

동시성이 높아질수록 개선 폭이 커진다. 64 workers에서 TAO의 지연은 185.410초로 최선 경쟁치 253.228초를 크게 웃돌고, TTFT는 0.224초 대 0.351초, 디코드 처리율은 2,021.523 대 1,561.307 tok/s다. 16 workers에서 이 격차는 각각 113.264초 대 116.011초, 0.135초 대 0.146초, 934.967 대 889.590 tok/s로 좁다. 즉 세션이 노드 용량을 놓고 경쟁할수록 “한 번에 최적 배치"와 “캐시·준비도를 반영한 값 매기기"의 효과가 두드러진다(근거: §4.2).

나머지 설정의 개선 폭도 함께 보면 전체 그림이 선명해진다. 아래 값은 Table 1의 Rel. Imprv. 행을 그대로 옮긴 것으로, 음수는 TAO가 밀린 칸이다(근거: 원문 Table 1).

Table 1의 36개 칸 가운데 5개 칸에서 TAO가 최선 경쟁치에 밀린다. DeepSeek Terminal-Bench는 지연과 TTFT를 세 동시성 모두에서 앞섰지만 디코드는 16 workers(−8.8%)와 64 workers(−6.2%)에서 뒤졌다. Qwen3-32B SWE-Lite는 96 workers 디코드(−5.1%)와 160 workers 지연(−0.2%)에서 밀렸고, SWE-verified는 128 workers 지연(−2.5%)에서만 밀렸다. 결론은 “모든 지표에서 모든 조건을 이긴다"가 아니라 “대부분의 조건에서 여러 지표를 함께 좋게 만든다"에 가깝다.

대형 모델 확장 실험인 GLM-4.7(1노드 8×H100, TP8, 300개 작업)은 SWE-Lite 160 workers에서 지연 15.5% 감소, TTFT 14.1% 감소, 디코드 20.5% 증가를 기록했고, SWE-verified 500개 작업 전 구간에서는 지연 16.2~18.9% 감소, 클라이언트 TTFT 15.7~38.4% 감소, 디코드 22.8~24.7% 증가를 기록했다. 비교 대상은 각 지표에서 SOTA인 ThunderAgent다(근거: 원문 Table 2, §4.2).

4.3 서빙 역학: 동시에 몰아넣지 않기

원문 Figure 4. GLM-4.7이 SWE-Lite 300 작업을 160워커(TP8)로 실행할 때의 실행 중 요청 수 추적이며, 각 실행은 첫 클라이언트 요청 시점을 0으로 맞춘다. TAO는 60.0분에 워크로드를 끝냈고 ThunderAgent는 70.9분, vLLM CA는 164.3분, vLLM RR은 176.8분, Dynamo는 189.4분이었다. TAO는 실행 중반 내내 동시 실행 요청 수를 낮게 유지하면서 작업을 더 일찍 끝낸다. 즉 동시 요청 수를 낮게 유지하면서 추가 세션을 안정적으로 받아들이는 방식이다. 96·128워커의 대응 추적(TAO 53.9분·59.2분, ThunderAgent 60.1분·66.2분)은 Appendix D에 있다(근거: §4.2, Appendix D).

4.4 어느 부분이 실제로 기여했나

구성요소 제거 실험. SWE-Lite, DeepSeek-V4 Flash, 2노드×4×H100, 32 workers 기준이다(근거: 원문 Table 4, §4.4).

가장 큰 하락은 마지막 줄이다. DP를 단순한 BFD 배치로 되돌리면 디코드가 1417.97 → 1233.72 tok/s로 떨어지고 TTFT 평균은 0.154 → 0.195초로 늘어난다. 값 매기기만 잘해서는 배치가 근시안적이면 성능이 크게 떨어진다는 뜻으로, “평가"와 “결정"이 서로 다른 역할을 한다는 설계 근거를 뒷받침한다. 준비도 제거는 디코드를 1363.06까지 낮추고 도구 종료→첫 토큰을 0.227초로 늘린다. 캐시 값 제거의 효과는 상대적으로 작다(1398.35). 제거 효과가 단조롭지 않은 점도 눈에 띈다. “캐시 값·준비도 모두 제거” 행(1373.51)이 “준비도만 제거” 행(1363.06)보다 디코드가 높게 나온다. 다만 마지막 DP→BFD 행과의 간격에 비하면 이 불규칙성은 크지 않다.

캐시 인지 평가. 218개 작업의 고정 워크로드 리플레이에서 DP 배치는 ThunderAgent 대조군과 동일하게 고정한 채 값 매기기만 바꿔 비교했다. 캐시 토큰 정렬은 prefix-cache 히트율을 0.19%p 높이고 평균 pause 대기를 4.5% 줄였다. 여기에 캐시 크레딧 감쇠를 더하면 히트율은 0.31%p, 디코드 처리율은 1.68% 올랐다. Figure 5는 물리적 prefill 감소, TTFT 감소, pause 대기 감소를 함께 보여준다(근거: §4.3, 원문 Figure 5).

도구 준비도. 짝을 맞춘 32-워커 SWE-Lite 실행에서 준비도를 켜면 디코드 처리율이 4.03% 오르고, 도구 종료부터 첫 토큰까지의 지연이 10.88% 줄며, 평균 pause 대기가 1.067초에서 0.972초로 내려간다. Figure 6의 왼쪽 CDF는 도구 종료 이후 첫 출력 토큰까지의 분포를, 오른쪽은 예측 오차 분포를 보여준다. 10,967건 완료 도구 예측의 평균 절대 오차는 0.410초이고 오차 0.5초 이내가 82.9%다(복귀 지연 CDF에는 10,481건과 10,673건의 관측이, 예측 패널에는 10,967건의 예측이 들어간다)(근거: §4.3, 원문 Figure 6).

동시 배치. 다중 후보가 있는 23개 리플레이 스냅샷 가운데 6개(26.1%)에서 사전식 목적이 개선됐고 나머지 17개는 short-first 휴리스틱과 같았다. 단일 후보 사례를 포함한 복원 가능한 35개 전체에서는 6개(17.1%)가 개선되고 29개(82.9%)가 일치한다. 즉 이 기준에서 DP가 더 나빠진 경우는 없었고, 충돌이 심한 스냅샷에서 이득을 냈다(근거: §4.3, Appendix H).

4.5 혼합 워크로드와 보조 평가

혼합 워크로드(근거: 원문 Table 3). Terminal-Bench + SWE-Lite 혼합(389개 작업)에서 32·64·128워커 모두 지연(+12.2/+23.2/+13.8%)과 디코드(+12.2/+8.6/+4.4%)가 개선됐고, 32워커 TTFT만 −5.5%로 밀렸다. AutomationBench(800개 작업)는 32·64워커에서 세 지표가 모두 개선됐다. 반면 128워커에서는 세 지표가 모두 뒤졌다. 지연 563.114초 대 523.676초(−7.0%), TTFT 19.123초 대 3.166초(−504.0%), 디코드 1,013.157 대 1,140.862 tok/s(−11.2%)다. 워크로드에 따라 이득과 손실의 방향이 달라진다.

저동시성 폴백(근거: Appendix E.1, Table 5). DeepSeek-V4 Flash를 단일 TP8 노드에 두고 4~64워커를 훑었다. 4~8워커에서 TAO의 평균 작업 지연은 최선 baseline의 2.3% 이내로 붙고 디코드 처리율은 최선의 92% 이상을 유지하며, 평균 TTFT는 최선보다 15~20ms 높다. 32·64워커에서는 ThunderAgent가 크게 밀린다(64워커 기준 지연 475.033초 대 226.268초, TTFT 9.332초 대 0.423초). 스케줄링 여지가 적어져도 TAO가 붕괴하지 않는다는 확인이다.

InferenceX 리플레이(근거: Appendix F, Table 7, Figure 9). AgentX 트레이스 393개와 100만 토큰 컨텍스트 한도, 1,800초 프로파일링 창으로 구성된 고정 코퍼스를 DeepSeek이 2노드×4×H100에서 서비스한다. TAO는 16·32·64워커 모두 디코드 처리율 1위(+4.2/+1.8/+10.1%)이며 TTFT는 16워커에서만 1위이고 32·64워커에서는 캐시 인지 스케줄러가 더 낮다. Figure 9에서 TAO의 prefix-cache 히트율은 모든 워커 수에서 1위다.

다른 KV 관리 엔진과의 합성(근거: Appendix E.2, Table 6). TokenCake 위에 TAO를 얹으면 16·32워커에서 디코드 처리율이 785.159 → 886.772 tok/s, 1,292.584 → 1,347.373 tok/s로 늘고, 64워커에서는 지연 509.018 → 274.892초, TTFT 1.590 → 0.593초, 디코드 790.491 → 1,414.547 tok/s로 개선된다. 다만 저자들은 이 실행에서 프로그램의 pause·resume·migration이 한 번도 발생하지 않았음을 함께 보고하며, 메커니즘에 대한 귀속은 별도 실행이 필요하다고 인정한다.

긴 도구 지연에 대한 민감도(근거: Appendix G, Table 8). MiniSWE로 녹인 SWE-Lite 세션(모델 요청 6,995건, 도구 기록 6,942건)에 세션마다 고정 추가 지연 1~5초, 2~10초, 4~20초를 주었다. 준비도를 끈 대비 TAO는 makespan을 20.72/16.42/19.28%, 평균 세션 지연을 21.57/20.57/17.91% 줄였다. 지연이 길수록 준비도가 실제 배치 결정을 바꾸는 비율이 1.65% → 3.94% → 7.93%로 커진다. 이력 기반 예측을 알려진 진실 시간을 주는 Oracle와 비교하면 평균 절대 오차가 99.53~99.69% 줄고(0.025~0.030초) 런타임 성능도 Oracle에 근접했다.

5. 한계와 적용 판단

5.1 논문 자체가 밝히거나 구조상 따르는 한계

• 최적성은 이산화 스냅샷 위에서만 성립한다. DP는 동결·이산화된 스냅샷에서 정확하지만, 반올림은 이산화 전에는 실현 가능했던 계획을 배제할 수 있다(근거: §3.5).
• 전역 온라인 최적성을 보장하지 않는다. 비동기 적용의 손실은 값 변동 ε_{s,t}, 실현 가능성 변화로 생기는 기회 A_{s,t}, 실행 손실 T_{s,t}로 묶어 조건부 상계로 제시된다(식 (12)). $$\max_{x \in X^\Delta_t} U_t(x) - U_t(y_t) \le A_{s,t} + 2\epsilon_{s,t} + T_{s,t}$$ 이 상계의 비교 기준은 계획 시점이 아니라 적용 시점에 관측된 동일 상태의 신선한 스냅샷 최적해다. 따라서 end-to-end 지연이나 전역 최적 온라인 정책 대비 regret은 보장하지 않는다. 준비도의 0/1 점프는 지수 감쇠 가정에 자동으로 들어맞지 않아 별도의 점프 허용치가 필요하다(근거: Appendix B.2, Appendix C).
• 준비도 예측은 보정된 확률이 아니다. 유한표본 마진을 얹은 스케줄링 휴리스틱일 뿐 개별 호출에 대한 calibrated coverage를 제공하지 않는다. 도구별·전역 이력이 모두 없으면 5초 기본값에 의존한다(근거: Appendix A).
• 자원 경계 가정. 외부 도구의 CPU·RAM은 GPU 수용 예산 밖에서 별도로 관리된다고 가정한다. 추가 자원 제약이나 상호작용 의존적 값이 필요한 상황은 이 수용 모델의 확장이 필요하다(근거: §2.1, §3.4 — 후자는 리뷰어 해석).
• 오버헤드 회계는 부분적이다. 기록된 스케줄러 작업 시간은 상태 준비와 완료된 풀이라 실패한 탐색과 BFD 실행은 시간 계정에 들어 있지 않다. 즉 그 비율은 CPU 이용률이나 요청 지연 오버헤드의 측정값이 아니다(근거: Appendix I).

5.2 리뷰어 관점의 짚을 점

• 확장성은 노드 수에서 검증되지 않았다. DP의 상태 공간은 노드 수와 용량 양자화에 따라 커진다. 캐시가 같은 노드들은 g ≤ m개의 용량 차원으로 묶이고, 상태 예산이 소진되면 BFD로 폴백한다. 실측 폴백 비율은 DeepSeek 64 workers 5.24%, Qwen 스윕 3.06~8.98%다. 다만 보고된 실측은 최대 4노드(TP2×4) 배포까지이고, 노드가 훨씬 많은 배포는 검증되지 않았다(근거: §3.5, Appendix I, Table 9).
• 준비도는 신호의 품질에 전적으로 의존한다. 도구 인터페이스가 진행·시한을 노출하거나 이력 통계가 유효한 환경에서 가장 잘 작동한다. 그런 신호가 없는 도구에서는 5초 기본값에 의존하며, 이때의 정확도 보장은 제한적이다(근거: §3.4, Appendix A).
• 기아 회피 장치는 원문에 없다. 세 번째 좌표인 토큰 수 우선은 캐시 크레딧과 준비도가 모두 동률일 때만 적용된다. 이때 토큰 수가 큰 세션이 배정 우위를 갖는 것은 Figure 11의 세션 177 수용에서 드러나지만, 기아를 막는 장치는 명시되어 있지 않다. 스냅샷이 매 스케줄링 시점마다 다시 풀린다는 점이 완화 요인으로 보인다(근거: §3.2; 완화 요인은 리뷰어 해석).
• 엔진과의 결합은 아직 설계 단계다. TokenCake와의 합성은 동작했지만 pause·resume·migration이 발동하지 않아, 그 메커니즘이 실제로 기여했는지는 미확인이다(근거: Appendix E.2).

5.3 적용 판단

이 설계는 도구 호출이 잦고, 세션이 많아 노드 용량을 놓고 경쟁하며, 도구 소요시간이 예측 가능한 에이전트 서빙에 특히 적합하다. SWE-bench류 코딩 에이전트, 다중 에이전트 오케스트레이션, Looped Agent가 그 예다. 논문은 챗봇 부하에도 호환된다고 밝힌다.

반대로 도구가 거의 없거나 도구 신호 없이 예측이 어려운 워크로드에서는 값 매기기의 이점이 줄어든다. 실제로 AutomationBench 128 workers에서는 세 지표가 모두 뒤졌다. 노드 수가 매우 많은 배포에서는 DP 비용과 이득을 별도로 검증해야 한다.

이 글의 그림은 arXiv:2610.37230 원본에서 가져왔습니다 (CC BY 4.0). 크기와 형식만 바꿨습니다.