GoodServe: 이종 GPU 클러스터에서 에이전트 LLM 추론을 굿풋 최적화하는 Predict-and-Rectify 라우팅

이종 GPU 클러스터에서의 에이전트 추론 문제

대기업 AI 인프라팀이 LLM 서빙 클러스터를 운영할 때, 모든 GPU가 같은 사양인 경우는 드물다. H800이 주력이어도 기존 A800, A40, V100이 섞여 있거나, 예산에 따라 여러 세대가 공존한다. 이런 이종(heterogeneous) GPU 클러스터에서 요청을 어느 인스턴스로 보낼지 결정하는 라우팅은 생각보다 어려운 문제다.

단순 랜덤 라우팅이나 라운드로빈은 빠르지만 SLO(Service Level Objective)를 보장하지 못한다. 특히 에이전트 LLM 워크로드는 기존 챗봇보다 훨씬 다루기 어렵다. 도구 호출·코드 실행·멀티턴 대화가 뒤섞이는 에이전트는 출력 토큰 수를 미리 알 수 없다. 처음엔 짧을 것 같던 요청이 도구 응답 파싱 단계에서 수천 토큰을 생성하기도 한다.

2026년 5월, 상하이교통대학(SJTU)과 홍콩중문대학교 선전(CUHK-SZ) 연구팀은 이 문제를 다룬 논문 GoodServe를 arXiv에 공개했다(2605.16867). 핵심 아이디어는 "예측하고, 라우팅하고, 이상이 생기면 바로잡는다"는 Predict-and-Rectify 접근이다.

Goodput이란 무엇인가

SLO 기반 LLM 서빙에서 처리량(throughput)과 지연(latency)은 따로 최적화할 수 없다. Goodput은 이 둘을 함께 다루는 지표다.

Goodput = SLO를 만족하면서 처리한 요청 비율 × 단위 시간당 요청 수

SLO를 어기며 빠르게 처리하거나, SLO를 지키지만 처리량이 낮으면 goodput이 떨어진다. 에이전트 서빙에서는 TTFT(Time To First Token)와 TPOT(Time Per Output Token) 두 가지 SLO가 동시에 적용되는 경우가 많다.

이종 GPU 클러스터에서는 GPU별 처리 속도가 다르기 때문에, 같은 요청이라도 어느 인스턴스로 보내느냐에 따라 SLO 달성 여부가 달라진다. H800에서 200ms 안에 첫 토큰이 나오는 요청이 V100에서는 600ms가 걸릴 수 있다.

GoodServe의 세 가지 핵심 설계

GoodServe — Predict-and-Rectify 라우팅 아키텍처

① 출력 길이 예측기: MoE 앙상블 MLP

에이전트 추론에서 라우팅 결정의 핵심 어려움은 출력 토큰 수를 미리 모른다는 점이다. 챗봇은 대화 스타일이 어느 정도 예측 가능하지만, 에이전트는 도구 결과에 따라 응답 길이가 10배 이상 달라질 수 있다.

GoodServe는 이를 위해 MoE(Mixture-of-Experts) 스타일 앙상블 MLP를 설계했다. 여러 개의 단순한 MLP를 전문가처럼 조합해 요청의 디코드 길이를 예측한다. 각 MLP는 서로 다른 특성(입력 길이, 도구 유형, 컨텍스트 패턴 등)에 특화되어 있고, 앙상블 가중치를 통해 최종 예측을 만든다.

논문이 보고한 예측 정확도 비교:

방법	예측 오차 (상대 기준)
GoodServe MoE 앙상블	기준 (가장 낮음)
LLM 기반 예측	1.4× 더 높음
히스토리 기반 예측	3.8× 더 높음

LLM 기반 예측이 오히려 더 부정확한 이유는, 예측 자체에 LLM을 사용하면 추론 비용이 높고 응답 지연이 발생하기 때문이다. GoodServe는 가볍고 빠른 MLP를 여러 개 앙상블하는 방식으로 두 가지를 동시에 해결한다.

② 인스턴스 효율 추정기: EMA 블랙박스 프로파일링

출력 길이를 예측했더라도, 각 GPU 인스턴스의 실제 처리 속도는 시간에 따라 달라진다. 현재 배치 크기, 다른 요청과의 간섭, 메모리 압박 등에 따라 같은 H800 인스턴스라도 처리 속도가 변동한다.

GoodServe는 지수이동평균(EMA) 스무딩 기반의 블랙박스 프로파일링으로 이를 추적한다. 특정 GPU 내부 구현에 의존하지 않고, 최근 요청 처리 속도를 지수 가중치로 부드럽게 추적한다. 급격한 스파이크에 과잉 반응하지 않으면서도 지속적인 부하 변화에 따라 추정값이 이동한다.

이 추정기는 이종 GPU 환경에서 특히 중요하다. H800과 V100의 처리 속도 차이는 정적인 사양 수치와 다를 수 있다. 실제 운영 중 누적된 부하 분포에 따라 어느 GPU가 현재 시점에 요청을 더 잘 소화할 수 있는지가 달라지기 때문이다.

③ Just-Enough 인스턴스 선택

예측된 출력 길이와 각 인스턴스의 효율 추정값을 합산해, GoodServe는 "충분히 여유 있는 최소 인스턴스"를 선택하는 휴리스틱을 적용한다.

핵심 아이디어는 두 가지다.

필요 이상의 과잉 할당 방지: 출력이 짧을 요청을 H800에 보내는 것은 낭비다. 그 슬롯은 긴 요청이 필요로 할 수 있다.
SLO를 맞출 수 없는 인스턴스에 배정 방지: 현재 V100이 너무 바쁘다면, 해당 인스턴스에 새 요청을 넣으면 TTFT SLO를 어길 가능성이 높다.

"just-enough"는 수요 측(요청의 예측 부하)과 자원 측(현재 인스턴스 여유) 모두를 고려해 딱 필요한 만큼의 여유를 가진 인스턴스를 선택한다는 의미다.

Rectify: 런타임 마이그레이션

예측이 완벽할 수는 없다. 처음에 짧은 응답으로 예측했던 요청이 실제로 훨씬 길어지면, 처음에 배정된 인스턴스가 SLO를 어길 위험이 생긴다.

GoodServe는 이를 해결하기 위해 주기적인 SLO 위반 위험 모니터링을 수행한다. 현재 실행 중인 요청들을 추적하며, 남은 처리량과 예상 완료 시간을 기반으로 SLO 위반 위험을 평가한다. 위험이 감지된 요청은 더 여유 있는 인스턴스로 런타임 마이그레이션이 트리거된다.

이 마이그레이션이 가능한 이유는 LLM 서빙의 KV 캐시 전송 메커니즘 덕분이다. 이미 생성된 토큰에 해당하는 KV 캐시를 새 인스턴스로 전송하면, 디코드 단계를 이어받아 계속할 수 있다. 물론 KV 캐시 전송에는 비용이 들기 때문에, GoodServe는 예측 단계에서 라우팅 결정을 최대한 정확하게 유지해 마이그레이션 빈도를 낮추는 것을 목표로 한다.

실험 결과

논문은 4가지 GPU 유형이 섞인 이종 클러스터에서 평가를 수행했다.

GPU	메모리	TP 수준
H800	80GB	TP=1
A800	80GB	TP=1
A40	48GB	TP=1
V100	32GB	TP=2

대규모 시뮬레이션에서는 512-인스턴스 클러스터 환경을 모델링했다. 이 규모에서 GoodServe의 라우팅 오버헤드는 초당 10,000 요청 부하에서도 5ms 수준으로 무시할 만한 수준이었다.

Goodput 기준 핵심 결과:

GoodServe는 기존 라우팅 방법 대비 최대 27.4% goodput 향상을 달성한다.

다양한 SLO 스케일(엄격한 SLO / 완화된 SLO) 조건에서 GoodServe는 일관적으로 경쟁 방법보다 높은 goodput을 보였다. 특히 예측 정확도가 낮은 히스토리 기반 라우팅과의 격차가 높부하 조건에서 크게 벌어졌다.

운영자를 위한 시사점

GoodServe는 연구 논문 단계(2026년 5월 arXiv)이며, 공개된 프로덕션 구현체는 아직 없다. 그러나 이 연구는 이종 GPU 클러스터를 운영하는 팀에게 몇 가지 실용적 관점을 제공한다.

출력 길이 예측의 가치: 에이전트 워크로드에서 요청별 출력 토큰을 추적하고 있다면, 그 데이터를 라우팅 결정에 활용할 수 있다. 간단한 분위수 기반 예측만으로도 무작위 라우팅보다 SLO 달성률이 높아질 수 있다.

이종 GPU의 부하 분산 전략: GPU 사양이 다르면 라운드로빈은 최악의 선택이다. 처리 속도를 실시간으로 추적해 느린 GPU에는 짧은 요청을, 빠른 GPU에는 긴 요청을 보내는 단순한 규칙만으로도 개선이 가능하다.

KV 캐시 이식성: 런타임 마이그레이션이 가능하려면 KV 캐시를 인스턴스 간에 전송할 수 있어야 한다. vLLM 0.26+ 등 최신 서빙 프레임워크는 KV 캐시 오프로드와 전송을 지원하기 시작했다. 인프라 설계 시 이 기능의 지원 여부를 확인할 필요가 있다.

Open question: GoodServe의 MoE 예측기는 에이전트 워크로드의 특성을 학습한다. 워크로드 분포가 크게 변하거나, 사용하는 모델이 바뀌면 예측기 재훈련이 필요한지 논문에서 명확히 다루지 않았다. 실제 배포 시 모델·워크로드 변화에 따른 예측기 갱신 정책이 필요할 수 있다.

요약

항목	내용
논문	arXiv:2605.16867, May 2026, SJTU + CUHK Shenzhen
핵심 문제	이종 GPU 클러스터에서 에이전트 추론 요청을 SLO를 지키며 효율적으로 라우팅
예측기	MoE 앙상블 MLP, 히스토리 기반 대비 오차 3.8× 감소
효율 추정	EMA 스무딩 블랙박스 프로파일링
라우팅	Just-enough 인스턴스 선택 (수요·자원 양측 정보 통합)
마이그레이션	SLO 위반 위험 감지 시 런타임 KV 캐시 이전
결과	최대 27.4% goodput 향상, 512인스턴스·10K req/s에서 5ms 오버헤드

에이전트 AI가 인프라를 복잡하게 만드는 이유 중 하나는, 요청의 실행 경로가 런타임 전까지 확정되지 않는다는 점이다. GoodServe는 이 불확실성을 예측 모델로 좁히고, 남은 불확실성은 런타임 보정으로 처리하는 실용적 구조를 제안한다.