AgentPerfBench로 에이전트 LLM 서빙 용량 측정하기
에이전트의 턴별 컨텍스트 증가와 처리량 포화점을 반영해 GPU 서빙 용량을 측정하는 방법을 정리한다.
2026-10-04
채팅 요청으로 잡은 용량이 빗나가는 이유
ShareGPT식 채팅 요청은 긴 에이전트 세션의 입력을 대신하지 못한다. AgentPerfBench 논문은 코딩·터미널·컴퓨터 사용 에이전트의 실제 트레이스를 이용해, 요청마다 입력 길이와 출력 길이뿐 아니라 턴이 진행되며 입력 컨텍스트가 늘어나는 과정을 측정 대상으로 삼았다.
에이전트는 이전 응답과 새 메시지를 다음 턴에 덧붙인다. 따라서 같은 세션의 뒤쪽 턴은 앞쪽 턴보다 긴 입력을 처리할 수 있다. 논문이 관찰한 긴 코딩 에이전트 세션에서는 마지막 턴의 누적 컨텍스트가 최대 120,000토큰에 이른다. 이 관계를 빼고 독립적인 단일 턴 요청만 보내면, 실제 운영 요청의 입력 형태가 벤치마크에서 사라진다.
다음 그림은 이전 응답과 새 메시지가 다음 턴의 입력 길이(ISL)에 반영되는 관계를 보여 준다.
차이는 지연에서도 드러난다. LLaMA-3.1-70B를 H100에서 측정했을 때 채팅에서 코딩 에이전트로 워크로드를 바꾸자 첫 토큰 지연(TTFT)은 239ms에서 1139ms로 4.8배가 됐다. 토큰당 출력 지연(TPOT)은 19ms에서 28ms로 1.5배가 됐다. 용량 검토에서는 평균 요청 하나의 길이만 볼 것이 아니라, 어떤 턴이 긴 입력을 서버에 보내는지 확인해야 한다.
요청을 만들 때 세션을 보존한다
논문은 ShareGPT 채팅과 SWE-Bench 코딩 에이전트, TerminalBench 터미널 에이전트, OSWorld 컴퓨터 사용 에이전트를 바탕으로 여섯 개 워크로드 프로파일을 구성했다. 실제 트레이스에서 턴별 입력 길이(ISL), 출력 길이(OSL), 턴 수의 분포를 구한 뒤 두 방식으로 요청을 만들었다.
| 방식 | 요청을 만드는 방법 | 확인할 때 적합한 대상 |
|---|---|---|
| 트레이스 재생 | 실제 기록의 턴을 재생 | 기록된 세션의 컨텍스트 증가 |
| 분포 기반 합성 | 관찰한 ISL·OSL·턴 수 분포에서 샘플링 | 관찰된 요청 특성을 따른 반복 측정 |
자체 서빙 벤치마크에서도 코딩이나 터미널 에이전트의 요청 기록이 있다면 세션 경계를 유지해 턴별 길이를 먼저 확인하는 편이 맞다. 기록된 세션을 재생하면 특정 긴 요청이 지연에 미치는 영향을 볼 수 있고, 분포 기반 합성은 관찰된 요청 특성을 따라 부하를 만들 수 있다. 어느 방식을 쓰든 매 턴을 서로 무관한 채팅 요청으로 바꾸면 논문이 지적한 컨텍스트 증가가 빠진다.
다만 논문의 실험은 컨텍스트 상한 32K에서 긴 세션을 절단했다. 120,000토큰까지 누적되는 세션이 관찰됐다는 사실과, 그 전체 길이를 서빙 실험에서 측정했다는 주장은 구분해야 한다.
동시성의 기준은 포화점 C*다
요청 하나의 지연만으로 GPU 용량을 정할 수는 없다. AgentPerfBench는 동시성 C를 바꾸는 closed-loop concurrency sweep을 수행하고, 초당 요청 처리량(req/s)이 더 증가하지 않는 동시성 C*를 포화점으로 정의한다. 실무에서는 에이전트 워크로드를 유지한 채 동시성을 올리고, 각 지점의 req/s와 지연을 함께 기록해야 한다.
이 측정이 필요한 이유는 높은 동시성이 항상 더 많은 완료 요청으로 이어지지 않기 때문이다. 논문의 포화 스윕에서 에이전트 프로파일의 처리량은 C=200에서 C=320으로 갈 때 43~76% 감소했다. 같은 구간에서 채팅 워크로드는 계속 확장됐다. 채팅 결과의 동시성 설정을 에이전트 운영값으로 옮길 근거가 없다는 뜻이다.
다음 그림은 같은 동시성 구간에서 채팅과 에이전트의 처리량 방향이 달라지는 비교를 보여 준다.
따라서 보고할 값은 임의의 높은 동시성에서 얻은 req/s 한 줄이 아니다. 어떤 워크로드로 스윕했는지, req/s가 멈추는 C*가 어디인지, 그 지점의 지연이 얼마인지를 함께 남겨야 GPU 용량 판단에 쓸 수 있다.
처리량과 함께 HBM 한계를 본다
코딩 에이전트의 긴 입력은 연산 특성과 메모리 점유도 바꾼다. 논문의 H100 분석에서 코딩 에이전트의 연산 강도(OI)는 2,409 FLOP/byte, 채팅은 181 FLOP/byte였다. H100의 능선점은 295 FLOP/byte로 제시됐다. 논문은 컴포넌트별 대역폭 관점의 상한을 다음과 같이 계산한다.
OI_j = FLOPs_j / DRAMBytes_j
P^roof_j = min(P_peak, OI_j × BW_peak)
OI_ridge = P_peak / BW_peak대역폭 관점만으로는 서빙 가능한 동시성을 설명할 수 없다. 논문의 코딩 에이전트 사례는 80GB HBM 용량 한계를 C=40에서 넘었고, C=80에서는 155GB에 도달했다. 용량을 산정할 때 req/s가 오르는지와 별도로 동시 요청의 메모리 요구량이 GPU 용량을 넘는지 확인해야 하는 이유다.
다음 그림은 연산 강도 비교와 HBM 용량 경계를 서로 다른 판단 축으로 놓는다.
측정 결과를 적용할 범위
이 결과를 그대로 운영 용량표로 옮기기 전에 실험 범위를 확인해야 한다. 논문의 서빙 실험 스택은 arXiv 2609.34683 (2026-09-28 제출), 실험 스택 vLLM v0.19.0/v0.19.1 · SGLang v0.5.9 · H100-80GB 등 4종 GPU다. GPU는 H100-80GB, A100-40GB, RTX 3090-24GB, RTX 2080Ti-22GB를 포함한다.
논문이 다룬 범위는 단일 노드의 멀티 GPU 구성으로, 텐서 병렬도는 최대 8이다. 멀티 노드 파이프라인 병렬은 포함하지 않았고, 서버 측 KV 축출, 컨텍스트 압축, 재계산도 직접 측정하지 않았다. 이런 기능을 쓰는 서빙 환경이라면 논문의 수치를 운영 한계로 단정하지 말고, 해당 환경의 에이전트 트레이스로 포화 스윕과 메모리 측정을 다시 수행해야 한다.