EAServe는 인코딩을 EPD 파이프라인 제어점으로 재배치한 MLLM 서빙이다.

무엇인가

멀티모달 LLM(MLLM) 서빙은 텍스트 전용 LLM과 파이프라인 구조가 다르다. 텍스트 추론이 연산 집약적인 Prefill과 메모리 대역폭 집약적인 Decode로 갈라져 PD 분리가 표준 최적화가 된 반면, MLLM은 그 앞에 모달리티 인코더가 이미지·영상·오디오를 임베딩으로 바꾸는 Encode 단계를 하나 더 붙여 Encode-Prefill-Decode(EPD) 3단 파이프라인을 만든다. 문제는 이 Encode가 파이프라인의 입구를 막고 있으면서도 GPU를 거의 쓰지 못한다는 점이다. 인코더 한 번의 forward pass는 현대 GPU를 포화시키기에 너무 작고, 배치를 키우려면 더 큰 배치가 모일 때까지 기다리는 지연 비용을 치러야 한다. 논문의 측정에 따르면 지속 부하에서도 인코딩 GPU의 연산 및 HBM 대역폭 사용률은 낮게 유지되고, 다운스트림 Prefill/Decode 워커는 커지는 인코딩 큐를 기다리느라 대부분의 시간을 보낸다. 단순 마이크로배칭(B=8)은 처리량을 올리고 TTFT를 낮추지만, 빨라진 인코딩이 다운스트림을 범람시켜 평균 TPOT가 급격히 상승한다. 기존 시스템들은 부분적인 답만 내놓는다. 텍스트 전용 PD 시스템에는 Encode가 아예 없고, NVIDIA Dynamo 같은 EPD 프레임워크는 Encode를 별도 서비스로 분리하되 요청을 하나씩 통과시키는 pass-through로 운영하며 GPU 할당을 운영자에게 맡기고 다운스트림 유입을 조절하는 장치가 없다.

어떻게 동작하나

논문의 핵심 주장은 Encode를 EPD 파이프라인의 제어점(control point)으로 재배치하자는 것이다. 파이프라인의 입구라는 위치 때문에 Encode는 서로 얽힌 세 가지 차원을 자연스럽게 통제한다. 작업이 언제 다운스트림으로 들어가는가(디스패치), 각 요청의 Prefill이 어디서 실행되는가(오프로드), 그리고 같은 GPU를 어떻게 나눠 쓰는가(SM 분할)다. 이 셋은 하나만 따로 튜닝하면 나머지가 깨지고, 결합 공간이 손으로 탐색하기에 너무 크다. EAServe는 이 제어점을 중심으로 두 개의 공동 설계 레이어를 얹는다. 상단의 Hybrid Auto Selection(HAS)은 GPU 할당(alloc), 인코딩 배치 상한(B), Prefill 오프로드 비율(s)로 이루어진 결합 구성 공간을 오프라인에서 탐색하고, 하단의 세 가지 인코딩 인지 런타임 기법이 그 구성을 온라인에서 실현한다.

무엇과 다른가

HAS는 두 단계로 나뉜다. 1단계는 각 단계의 워커당 용량을 병렬로 프로파일링한다. Encode는 B를 적응적으로 두 배씩 늘려 처리량이 포화될 때의 용량 C_E를 얻고, Prefill과 Decode는 각각 격리된 워커에서 스트레스 워크로드를 돌려 C_P, C_D를 얻는다. 이 프로파일로 각 단계를 독립 오픈 큐 서버로 모델링해 이용률 ρ_σ = (Λ/n_σ)/C_σ를 계산하고(σ ∈ {E,P,D}), 병목 균형 점수 score(a) = max(ρ_E, ρ_P, ρ_D)를 매긴다. Prefill의 경우 로컬 공동 배치 워커 수 n_L과 인코딩 GPU 메모리 예산 비율 α를 반영해 ρ_P = Λ/(C_P(n_P + n_L·α))로 계산한다. 필터는 세 단계다. ρ_σ ≥ 1인 할당은 용량 부족으로 버리고, 점수가 최솟값의 1.2배를 넘는 할당을 가지치기하고, 남은 것 중 상위 K=3개만 남긴다. 이때 2단계가 탐색할 범위도 함께 시딩한다. B는 B_max(a) = ⌈Λ/n_E⌉로 상한을 두고, s는 부하 균형점 s*(a) = C_remote/(C_remote + C_local)를 중심으로 ±0.2 윈도를 잡는다. 2단계는 남은 할당들에 대해 (B, s) 표면이 비단조적이라는 점을 인정하고 이를 블랙박스로 취급해, Optuna의 TPE 기반 베이지안 최적화로 30회의 엔드투엔드 시험을 집중시킨다. 각 시험은 전체 E+P+D 시스템을 목표 도착률 Λ로 배포해 벤치마크를 돌리고 처리량과 평균 TTFT/TPOT를 기록한다. 상위 3개 구성의 격차가 1% 미만이거나 5회 연속 개선이 없으면 종료하고, 처리량 우선, 동률이면 평균 TTFT·TPOT 순으로 최종 구성을 고른다.

어떻게 쓰나

런타임 기법 중 첫째는 부하 적응형 마이크로배칭이다. 고정 타임아웃은 부하가 바뀌면 어긋나고, 큐 길이 트리거는 일시적 휴지와 버스트 종료를 구분하지 못하며, 연속 배칭은 자기회귀 디코딩에만 적용된다. EAServe는 디스패치 임계값을 도착 과정 자체에서 유도한다. 워커당 도착률 λ에 대해 배치가 채워질 확률 목표 p를 두고, 도착 간격이 지수분포라고 가정하면 κ = -ln(1 - p^(1/(B-1))), g = κ/λ가 된다. 이 임계값은 부하가 높을 때 자동으로 조여지고 낮을 때 완화되며 워크로드별 재튜닝이 필요 없다. p=0.6을 쓰고 0.5~0.7 범위에서 성능이 둔감하다고 밝힌다. 디스패치는 배치가 B에 도달하거나, 유휴 타이머가 g를 넘거나, 첫 요청 이후 경과가 하드 캡 A=1000ms를 넘을 때 일어난다. 하드 캡은 흔한 경우를 위한 것이 아니라 각 요청이 g 직전에 도착해 배치가 g(B-1)초 열려 있는 병리적 패턴에서 최악의 TTFT를 묶기 위한 안전판이다. 둘째는 s ∈ [0,1]로 표현되는 속도 제어 부분 오프로드로, 인코딩 GPU에 공동 배치된 로컬 Prefill 워커로 어느 정도의 Prefill 작업을 흘려보낼지 정한다. 셋째는 마이크로배치 단위 동적 SM 분할이다. libsmctrl로 프로세스별 TPC 마스크를 써서 SM을 공간 분할하면 마이크로초 미만으로 재구성할 수 있다. 다만 SM 분할로도 HBM 대역폭은 격리되지 않으므로, KV 캐시를 토큰 단위로 스트리밍하는 Decode는 인코딩 GPU에 공동 배치할 수 없고 전용 GPU에 남는다.

전제와 한계

실험은 8-GPU 서버에서 이미지(LLaVA-v1.6-34B), 영상(Qwen2.5-VL-32B), 오디오(Ultravox-v0.6-27B) 세 아키텍처로 수행했고, 베이스라인은 NVIDIA Dynamo와 vLLM이다. 지표는 SLO를 만족한 요청 비율인 goodput으로, TTFT ≤ T_f이고 TPOT ≤ T_p인 요청 수를 실행 시간 T로 나눈 값이다. 동일 SLO 제약에서 EAServe는 Dynamo 대비 최대 4.3배, vLLM 대비 최대 1.7배 높은 goodput을 기록했고, EPD 파이프라인 전반에 걸쳐 더 균형 잡히고 더 높은 GPU 이용률을 유지했다.

세부 실험도 구체적이다. HAS 탐색 비교는 30회 시험 예산, Λ=5 req/s, 시험당 100 요청 조건에서 Random·Coordinate 베이스라인과 겨룬다. 1단계 가지치기는 7개 실행 가능 할당 중 3개만 남겼고, HAS는 세 모달리티 모두에서 30회 예산 내 최고 처리량 구성을 찾았다. 오디오에서 이득이 가장 컸고(Whisper 인코더가 가벼워 여유가 큼), 영상에서 가장 작았다(다중 프레임 인코더가 로컬 Prefill 여유를 거의 남기지 않음). 탐색 효율은 이미지 1.7시간, 영상 1.3시간, 오디오 1.7시간에 99번째 백분위 처리량에 도달한 반면, Random은 어느 모달리티에서도 99번째 백분위에 도달하지 못했고 Coordinate는 이미지와 영상에서 실패했다. 90번째 백분위는 이미지 0.3시간(HAS) 대 5.0시간(Random), 0.6시간(Coordinate)이었다. SM 분할 절제 실험은 Ultravox-27B, Λ=10 req/s에서 분할 없음 대비 동적 분할이 P99 TTFT를 19%, P99 TPOT를 42% 줄이고 처리량은 9% 높였으며, 정적 50/50 분할 대비로는 처리량 3% 향상, P99 TTFT 11% 감소, P99 TPOT 22% 감소를 보였다. 도착 패턴 민감도는 LLaVA-34B, Λ=2 req/s에서 감마 CV=2(버스티)일 때 처리량이 3%(1.77→1.71 req/s)만 떨어지고 P99 TTFT는 62%(10.2→16.5초) 늘었으며, CV=0.5(규칙적)에서는 P99 TTFT가 35%(10.2→6.7초) 줄었다. P99 TPOT는 세 분포 모두 약 71ms로 불변이었는데, 디코드 지연이 도착 과정이 아니라 KV 캐시 접근 패턴에 달려 있기 때문이다.

실무 관점에서 이 논문이 주는 신호는 명확하다. MLLM 서빙을 이미지·영상·오디오 중 하나라도 받는 형태로 운영한다면, Encode를 요청 단위 pass-through로 두는 구성은 지속 부하에서 인코딩 GPU를 놀리면서 다운스트림 지연을 키운다. 확인해야 할 것은 세 가지다. 첫째, 인코딩 배치를 고정 타임아웃이 아니라 도착률에 연동해 조절하고 있는가. 둘째, 인코딩 GPU의 남는 용량을 로컬 Prefill로 흘려보낼 수 있는가(그리고 그 비율 s를 워크로드에 맞게 조정했는가). 셋째, 같은 GPU에 두 워커를 올릴 때 SM을 공간 분할해 인코딩 지연을 보호하고 있는가. 또한 Decode는 HBM 대역폭 공유 때문에 인코딩 GPU에 올릴 수 없다는 제약은 배치 설계 시 바로 적용되는 규칙이다. GPU 할당·B·s를 손으로 맞추는 대신 프로파일링 기반 가지치기 후 소수의 엔드투엔드 시험으로 좁히는 HAS의 접근은, 자체 서빙 스택의 구성 탐색 자동화를 설계할 때 참고할 만한 골격이다.

저자들이 밝힌 한계와 전제도 분명하다. 실험은 단일 8-GPU 서버 규모에 머물러 있고, 향후 과제로 다중 노드 데이터센터 규모 검증을 들면서 노드 간 임베딩 전송과 수천 개 후보 구성에서의 HAS 탐색 예산을 별도 연구 주제로 남겨 두었다. 또한 디스패치 규칙은 도착 간격이 메모리리스(Poisson)라는 가정에 기대며, 실제 프로덕션에서 λ가 흔들리면 윈도우 기반 도착률 추정으로 κ를 주기적으로 재계산해야 한다고 명시한다. HAS 하이퍼파라미터(1.2배 가지치기, K=3, s 윈도 ±0.2, 30회 시험 예산)는 한 번 고정해 모든 실험에 재사용했고, SM 분할은 HBM 대역폭을 격리하지 못한다는 근본 제약이 남는다.