동적 배치 튜닝이 정적 스케줄링을 이기지 못한 이유: 멀티테넌트 vLLM 서빙 제어루프의 정직한 실패 분석

Kubernetes 위에서 H200 같은 고사양 GPU를 여러 테넌트가 나눠 쓰는 vLLM 서빙 클러스터를 운영하는 분이라면, 그리고 Kueue의 정적 어드미션 제어를 “이 정도면 충분하다”고 여겨왔던 분이라면 이 글이 유용합니다. 반대로 “LLM 에이전트가 실시간으로 서빙 파라미터를 조정하면 무조건 더 낫다”고 가정하고 있었다면 더더욱 읽어볼 가치가 있습니다. 이 논문은 그 가정이 항상 참은 아니라는 것을, 그것도 꽤 구체적인 이유와 함께 보여주기 때문입니다.

문제의식: 어드미션은 정적인데 부하는 실시간이다

공유 GPU 위에서 여러 테넌트의 LLM 추론을 서빙하는 문제는 이제 흔한 운영 과제가 됩니다. H200 같은 대용량 가속기 한 장에 트래픽의 버스트성, 시퀀스 길이, SLO가 서로 다른 여러 테넌트가 동시에 올라탑니다. Kubernetes 기반 플랫폼에서는 보통 Kueue 같은 쿼터·큐 기반 스케줄러가 어떤 작업을 풀에 들여보낼지 결정하지만, 일단 들어온 요청들이 엔진의 유한한 용량을 실제로 어떻게 나눠 쓰는지를 좌우하는 배치 크기와 최대 동시 시퀀스 수 같은 서빙 시점 파라미터는 대개 배포 시점에 정적으로 고정됩니다.

이 논문은 여기서 자연스럽게 따라오는 질문을 던집니다. Kueue가 관리하는 멀티테넌트 H200 GPU 풀에서 여러 테넌트가 vLLM 추론 서버를 공유할 때, 실시간 GPU 메모리·지연 텔레메트리를 관측하는 LLM 에이전트가 테넌트별 배치 크기와 최대 동시 시퀀스 수를 온라인으로 재조정하면 정적 Kueue 어드미션 제어 대비 처리량, p99 지연, 비용의 파레토 프론티어를 실측으로 개선할 수 있을까요. 저자들은 이 질문에 답하기 위해 단일 H200에서 돌아가는 완전한 실측 프로토콜을 설계했지만, 목표 Kubernetes 클러스터 컨텍스트에 접근할 수 없어 실행 자체가 무산됐다는 사실을 서두에서부터 분명히 밝힙니다. 그래서 이 논문에는 실제 하드웨어에서 측정한 처리량이나 지연 수치가 단 하나도 등장하지 않습니다. 대신 논문은 세 가지를 내놓습니다. 온라인 배치·동시성 튜닝 문제의 제어루프 정식화, 클러스터 접근이 복구되는 즉시 실행 가능한 재현 가능 프로토콜, 그리고 세 가지 제어 법칙의 구조를 스트레스 테스트하는 결정론적 큐잉 시뮬레이션입니다.

제어루프로 정식화한 튜닝 문제

논문은 온라인 테넌트별 배치·동시성 튜닝을 마르코프 결정 과정과 유사한 구조를 가진 이산 시간 폐루프 제어 문제로 정식화합니다. 상태는 테넌트별 큐 깊이, GPU 메모리 사용률, 최근 지연 백분위수(p50/p95/p99), 현재 동시성 상한으로 구성되고, 액션은 제한된 폭의 테넌트별 동시성 증감분입니다. 보상 함수는 처리량에서 SLO를 넘긴 p99 지연에 대한 페널티와 비용 항을 뺀 형태로, 안전 범위 안에서 처리량-지연-비용을 함께 최적화하도록 설계됩니다. 이 정식화 위에서 저자들은 에이전트가 실제 배포에 통합되는 방식도 함께 제안합니다. 에이전트는 Kueue의 잡 어드미션을 대체하지 않고 그 안쪽에서 사이드카처럼 동작하며, 이미 어드미션된 작업들이 엔진 용량을 나누는 방식만 조정합니다. 핵심은 손대는 레버가 vLLM 엔진 내부의 max_num_seqs가 아니라 클라이언트 측 테넌트별 어드미션 동시성이라는 점입니다. 프로덕션 vLLM은 엔진 파라미터를 재시작 없이 실시간으로 바꿀 수 있는 노브로 노출하지 않기 때문에, 실제로 조정 가능한 지점은 서버에 들어오는 동시 요청 수뿐이라는 실무적 제약을 그대로 반영한 설계입니다.

LLM 에이전트가 GPU 텔레메트리와 테넌트별 큐 깊이를 관측해 제한된 폭의 동시성 조정값을 산출하고, 이를 통해 배치 구성을 재조정하는 제어루프 구조입니다. 개념적 아키텍처 다이어그램이며 하드웨어에서 실측된 결과가 아닙니다.

시뮬레이션이 던진 경고: 순진한 동적 제어는 정적보다 나빴다

실측 프로토콜이 실행되지 못한 자리를 메우기 위해 저자들은 Python 표준 라이브러리만으로 작성한 시드 고정 이산 시간 큐잉 시뮬레이션을 만듭니다. 두 테넌트가 유한한 슬롯 풀을 공유하는 단순화된 모델 위에서, 세 가지 정책을 20개 시드·1800초씩 돌려 평균을 냅니다. 정적 정책은 테넌트별 동시성 상한을 4로 고정하고, 순진한 동적 정책은 GPU 메모리 사용률과 6초 윈도우 p99 지연을 3초마다 관측해 두 테넌트를 한꺼번에 ±1씩 조절하며, 차별화 에이전트 정책은 테넌트별 백로그 비율을 각자 독립적으로 반영하는 방식으로 더 정교한 에이전트 추론을 흉내 낸 대리 모델입니다.

결과는 예상을 벗어납니다. 정적 정책이 처리량(0.686 req/s)과 드롭 수(평균 1.9건) 모두에서 가장 우수했고, 순진한 동적 정책은 처리량이 0.515 req/s로 떨어지면서 평균 309.5건이나 요청을 드롭했습니다. 차별화 에이전트 대리 모델은 순진한 동적 정책보다는 나았지만(처리량 0.601 req/s, 드롭 154.7건) 여전히 정적 정책을 따라잡지 못했고, p99 지연 역시 두 동적 변형 모두 정적 정책(11.75초)보다 높게 나타났습니다(각각 12.79초, 13.25초).

정적 정책이 가장 높은 처리량과 가장 적은 드롭을 기록했고, 두 동적 변형 모두 시뮬레이션에서 성능이 낮았습니다. 20개 시드 평균을 낸 결정론적 큐잉 시뮬레이션 결과이며 실제 GPU에서 측정한 값이 아닙니다.

정적 정책의 p99 지연이 가장 낮았고, 두 동적 컨트롤러 모두 이 시뮬레이션 영역에서 꼬리 지연을 줄이지 못했습니다. 20개 시드 평균의 시뮬레이션 결과이며 하드웨어 실측치가 아닙니다.

저자들은 이 결과를 단순 버그가 아니라 모델의 실제 동역학이라고 검증하며 네 단계로 원인을 추적합니다. 첫째, 서비스 시간이 지수분포를 따르기 때문에 원래부터 꼬리가 두껍습니다. 평균 2.5초짜리 지수분포는 큐잉이 전혀 없어도 p99가 11.5초 근처에 형성되는데, 이는 정적 정책이 기록한 11.75초와 거의 차이가 없습니다. 즉 관측되는 꼬리 지연 대부분은 혼잡이 아니라 서비스 시간 자체의 분산에서 나옵니다. 둘째, 스로틀 임계값이 3초 기준의 두 배인 6초로 설정되어 있는데, 이는 이 내재적 p99인 11.5초보다 훨씬 낮습니다. 몇 건 안 되는 완료 요청으로 추정하는 짧은 윈도우 p99는 노이즈가 크고 이 내재적 꼬리 쪽으로 편향되어, 실제로는 가볍게 부하가 걸린 상황에서도 임계값을 자주 넘깁니다. 셋째, 이렇게 발생한 오탐 스로틀이 두 테넌트를 함께 묶어 낮추기 때문에 혼잡하지 않은 테넌트까지 함께 제한받고, 3초짜리 하드 타임아웃 아래서 불필요한 스로틀 하나하나가 곧바로 드롭으로 전환됩니다. 넷째, 확장 규칙으로 회복은 되지만 스로틀-드롭 비용이 확장 이득보다 비대칭적으로 크기 때문에 순 처리량이 떨어집니다.

실패에서 뽑아낸 설계 요구사항

이 진단이 말해주는 바는 동적 튜닝 자체가 쓸모없다는 것이 아닙니다. 노이즈가 크고 꼬리 쪽으로 편향된 신호, 테넌트를 함께 묶는 스로틀링, 하드 타임아웃이 결합하면 순진한 고정 임계값 제어가 정적 제어보다 실제로 더 나빠질 수 있다는 사실입니다. 여기서 저자들은 효과적인 에이전트 컨트롤러가 갖춰야 할 네 가지 설계 요구사항을 도출합니다. 혼잡 신호는 짧은 윈도우의 원시 백분위수 대신 더 긴 텔레메트리 이력과 신뢰도 추정을 바탕으로 견고하게 추정해야 합니다. 결정은 테넌트를 하나로 묶은 전역 신호가 아니라 테넌트별로 차별화되어야 합니다. 스로틀링과 확장 사이의 비대칭적 비용을 명시적으로 고려해야 하고, 고정된 숫자 임계값으로는 표현할 수 없는 버스트 패턴 인식이나 테넌트별 SLA 메타데이터 같은 추가 맥락도 활용해야 합니다. 실제로 차별화 에이전트 대리 모델이 순진한 컨트롤러 대비 손실의 절반가량을 회복한 것은 이 방향이 유효할 가능성을 시사합니다. 다만 결합도와 신호 종류를 동시에 바꿨기 때문에 어느 쪽이 회복에 기여했는지는 이 실험만으로 분리해낼 수 없다고 저자들은 선을 긋습니다.

회사·사회·과학에 남기는 것

ThakiCloud 입장에서 이 연구가 당장 남기는 것은 검증된 비용 절감이 아닙니다. 우리 멀티테넌트 H200 클러스터에 곧바로 적용 가능한 재현 가능 실측 프로토콜, 그리고 순진하게 접근하면 오히려 손해를 볼 수 있다는 구체적 경고입니다. 클러스터 접근이 복구되면 이 프로토콜에 실제 LLM 에이전트 결정 함수만 대체해 넣으면 되도록 하네스 자체는 이미 완성돼 있습니다. 더 넓게 보면 공유 GPU 풀의 자원 낭비를 줄이는 방법론이 다듬어질수록 소규모 조직도 공유 클러스터에서 SLA를 지킬 수 있는 실용적 경로가 열립니다. 이는 추론 인프라의 에너지·비용 효율 전반에 도움이 됩니다. 과학적으로는 LLM 에이전트가 실시간 시스템 텔레메트리를 관측해 서빙 하이퍼파라미터를 온라인으로 재조정하는 제어루프를 명시적으로 정식화하고, 그 실패 모드를 재현 가능한 시뮬레이션으로 정량 진단했다는 점이 기여입니다. 이 논문은 ThakiCloud가 같은 Kueue·GPU 기반 위에서 이어온 연구 계보의 일부이기도 합니다. 저지 모델 샘플링 예산을 스케줄링하는 ABJ-Gate, 어드미션 시점의 TEE 원격 증명을 다루는 Attested Confidential Sovereign Inference, 드문 이산 사고에 대한 이진 원격·조치 결정을 다루는 “Escalate or Act?”와 비교하면 이 논문은 초 단위로 연속 재조정되는 실시간 다목적 제어라는 질적으로 다른 문제를 다룬다는 점에서 이들과 구별됩니다.

한계

이 논문이 스스로 밝히는 한계는 명확합니다. 가장 중요한 것은 어떤 형태로든 실제 하드웨어 검증이 없다는 점으로, 목표 클러스터 컨텍스트에 접근할 수 없어 실측 프로토콜이 실행되지 못했고 논문에 실린 어떤 수치도 GPU에서 측정된 것이 아닙니다. 시뮬레이션은 토큰과 KV 캐시를 단일 스칼라 슬롯 수로 단순화했을 뿐 프리필/디코드나 메모리 압력 동역학을 모델링하지 않으며, 메모리 사용률 신호조차 슬롯 점유율의 대리값일 뿐 실제 디바이스 메모리 측정치가 아닙니다. 테스트한 테넌트 유형도 두 가지 합성 트래픽 패턴에 그쳐 다른 트래픽 혼합에서는 발견된 실패 모드가 일반화되지 않을 수 있습니다. 시뮬레이션 속 에이전트 정책 역시 실제 LLM이 아닌 손으로 작성한 대리 모델이며 결합도와 신호 종류를 동시에 바꿨기 때문에, 4장에서 도출한 설계 요구사항을 실제 LLM 에이전트가 충족한다는 검증된 근거는 아직 없습니다. 20개 시드에 대한 평균과 표준편차만 보고했을 뿐 통계적 유의성 검정은 수행하지 않았다는 점도 저자들은 분명히 밝힙니다. 이런 이유로 이 논문은 검증된 결과가 아니라 정식화와 프로토콜, 그리고 경고성 시뮬레이션으로서 스스로를 자리매김합니다.

논문 상세 페이지는 다음에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-21-agent-dynamic-batch-tuning-vllm