vLLM-Omni: 글·음성·영상·로봇 모델의 실행 단계를 하나의 서버 구조로 관리하기

배경과 문제

생성 모델 서빙은 더 이상 텍스트 디코딩 루프 하나로 설명되지 않는다. 음성 비서는 사용자 음성을 이해해 텍스트를 만들고, 그 텍스트를 음성 코덱으로 바꾼 뒤 파형으로 복원하는 여러 단계를 거친다. Qwen3-Omni 같은 옴니 모델은 thinker가 텍스트를 생성하고 talker가 음성 코덱을 만들며 code2wav가 파형을 복원하는 다단계 자기회귀 파이프라인이다. TTS 모델은 코덱 예측기 뒤에 플로우 매칭이나 보코더가 붙고, 이미지·영상 생성은 확산 트랜스포머를 여러 스텝 반복한다. 월드 모델은 예측한 프레임이 다음 스텝의 조건으로 다시 들어가고, VLA 모델은 관측과 지시를 받아 로봇 행동 청크를 반복 출력한다.

이런 다양성은 서빙 시스템에 두 가지 어려움을 만든다. 첫째, 스테이지마다 배치 방식과 메모리 사용 방식이 달라 한 요청 안에 이질적인 실행 패턴이 섞인다. 둘째, 입력과 출력의 연결이 복잡해진다. 전이중 음성 에이전트는 말하는 동안에도 사용자 음성을 계속 받아야 하고, 로봇 루프는 계속 바뀌는 센서 입력에 맞춰 행동을 스트리밍해야 한다. 기존 LLM 서빙 시스템은 자기회귀 디코딩과 KV 캐시 관리에 최적화되어 있지만, 별도의 생성기를 거쳐 음성·픽셀·행동을 출력하는 다단계 파이프라인을 기본 실행 단위로 설계하지 않았다. 확산 모델 스택은 디노이징 반복을 최적화하지만, AR 스테이지와의 데이터 전달이나 세션 단위 상호작용을 함께 다루는 공통 제어 평면이 없다.

기존 접근의 한계

실제 배포에서는 서로 다른 런타임을 임시로 이어 붙이는 경우가 많다. 이렇게 하면 요청 수락과 수명 주기 관리 로직이 서비스마다 중복되고, 스테이지 단위 스트리밍과 KV 전달을 하나의 요청으로 관리할 수 없다. Ray Serve나 Triton 앙상블 같은 범용 연결 도구는 임의의 스테이지를 이을 수 있지만, 음성의 첫 패킷 지연이나 전이중 세션 수락 같은 문제는 애플리케이션이 직접 풀어야 한다.

vLLM-Omni는 2025년 11월 vLLM 커뮤니티가 공개한 프로젝트로, 2026년 2월 첫 논문에서 스테이지 그래프, 분리된 엔진, 커넥터 기반 데이터 전달을 제안했다. 이번 기술 보고서는 스테이지 추상화를 유지하면서 오케스트레이터, 스트리밍 진행, 스테이지 복제 풀, 중간 데이터 이동, 세션을 런타임이 직접 관리하도록 확장했다. 핵심 분업은 한 문장으로 요약된다: 스테이지는 모델 구성 요소 하나와 실행 엔진 하나, 자원 예산을 가지고, 오케스트레이터는 요청 수락, 스테이지 간 진행, 클라이언트에 보이는 출력을 맡는다.

연구방법을 단계별로

vLLM-Omni의 구조는 오케스트레이터와 스테이지의 역할 분리에서 시작한다. 오케스트레이터는 다음에 어느 스테이지를 실행할지, 어느 복제본에 작업을 보낼지, 결과를 클라이언트에 보낼지 다음 스테이지로 넘길지를 결정한다. 반대로 스테이지 안의 토큰 스케줄링, 페이지 단위 KV 관리, 디노이징 스텝, 큰 텐서 복사는 하지 않는다. 토큰화와 멀티모달 전처리도 진입점에서 미리 끝내므로, 오케스트레이터의 제어 루프는 실행 준비가 끝난 요청만 받는다.

스테이지를 넘기는 방식은 두 가지다. 배치 전달은 앞 스테이지가 끝난 뒤 오케스트레이터가 다음 스테이지 요청을 만들어 제출한다. async_chunk는 받는 쪽 스테이지에 자리표시자 요청을 미리 제출해 두고, 앞 스테이지가 토큰이나 코덱 프레임을 만드는 즉시 워커가 커넥터로 청크를 발행해 뒤 스테이지가 바로 디코딩하게 한다. 연구팀은 async_chunk를 첫 오디오 패킷까지의 지연(TTFP)을 줄이는 주된 장치로 설명한다. 배치 방식에서는 talker가 발화 전체의 코덱을 다 만들 때까지 파형 디코더가 기다려야 하지만, 청크 방식에서는 코덱 예측과 파형 복원이 겹쳐서 진행된다.

실행 엔진은 스테이지 유형에 따라 전문화된다. thinker나 talker처럼 연속 배칭과 KV 캐시가 필요한 스테이지는 AR 워커가, code2wav처럼 텐서를 출력하는 스테이지는 생성 워커가 실행한다. 확산 스테이지는 별도의 확산 엔진에서 실행되며, TeaCache나 Cache-DiT 같은 스텝 캐시와 시퀀스 병렬, CFG 병렬을 적용할 수 있다. 용량은 스테이지마다 하나씩 있는 StagePool로 늘리는데, 풀은 여러 복제 엔진을 가지며 한 요청을 같은 복제본에 고정해 스트리밍 업데이트와 스테이지 내부 KV가 같은 곳에 머물게 한다.

스테이지 사이 데이터는 은닉 상태와 임베딩, 코덱 코드, 페이지 단위 KV 블록, 잠재 표현의 네 가지 페이로드로 나뉜다. 이 데이터를 실제로 옮기는 것은 OmniConnector로, put, get, cleanup, 상태 확인의 좁은 인터페이스를 제공한다. 생산자가 키 하나로 페이로드를 발행하면 공유 메모리 이름이나 원격 전송 핸들 같은 작은 메타데이터만 제어 대기열로 이동하고, 소비자는 이 메타데이터로 실제 데이터를 가져온다. 한 노드 안에서는 공유 메모리가 기본이고, 노드를 넘을 때는 Mooncake의 TCP, RDMA 경로를 쓴다.

결과와 숫자의 의미

Qwen3-Omni의 async_chunk 효과는 H100 2장의 Fixed-Len-2500/900 설정에서 동시 요청 32개일 때 두드러진다. async_chunk를 끄면 TTFT(첫 텍스트 토큰까지의 지연)가 507.8ms에서 3420.1ms로 약 6.7배 늘고, E2EL(요청 제출부터 응답 완료까지)이 72.63초에서 136.62초로 약 1.9배 늘었다. RTF(오디오 합성 시간을 생성된 오디오 길이로 나눈 값)도 0.630에서 0.927로 올라 실시간 재생 한계인 1에 가까워졌다. 연구팀은 E2EL과 RTF가 나빠진 이유를, 청크가 없으면 code2wav가 talker의 코덱 시퀀스가 끝나기를 기다려야 해서 오디오 경로의 대기 시간이 길어지기 때문이라고 설명한다. TTFT가 크게 늘어난 원인은 따로 분석하지 않았다.

H200 2장에서 Qwen3-Omni의 기본 배포(V1 러너)와 MRv2 옵트인 프로필을 비교한 결과, MRv2는 동시성 32에서 E2EL을 75.06초에서 39.53초로, RTF를 0.423에서 0.212로 대략 절반으로 줄였다. 음성 TTFP는 1064.6ms에서 500.4ms로 낮아졌지만, 텍스트 TTFT는 322.2ms에서 336.3ms로 조금 높아졌다. 주의할 점은 측정한 커밋에서 MRv2 프로필이 시작 단계에서 실패했다는 것이다. 공용 MRv2 모델 상태 코드가 융합된 Qwen3-TTS talker에만 있는 속성을 읽었기 때문이며, 연구팀은 한 줄짜리 방어 코드를 넣고 측정했다고 밝혔다.

Seed-TTS 영어 텍스트와 H200으로 측정한 Qwen3-TTS의 기본 배포는 talker와 Code2Wav 디코더를 GPU 2장의 두 스테이지로 나누는 반면, 최적화 프로필은 talker가 스트리밍 코덱 디코더를 직접 가지고 PCM을 반환하는 GPU 1장의 단일 스테이지다. CustomVoice 기본 음성 모드의 동시 요청 64개에서 처리량이 234.6 audio-s/s에서 612.1 audio-s/s로 약 2.6배 늘었고, Base 음성 복제는 170.4에서 282.1로 약 1.66배 늘었다. 같은 모델이라도 음성 생성 방식에 따라 이득이 달랐다. Qwen3-TTS Base의 낮은 TTFP는 참조 음성 캐시가 준비된 서버 조건이며, 새 서버의 동시 요청 1개에서는 기본·fused 모두 약 131ms로 표의 37.7/24.9ms와 다르다.

이미지 생성에서는 Qwen-Image 1536² 35스텝이 H100 1장에서 평균 23.60초 걸리지만, Ulysses2+CFG2 병렬로 H100 4장을 쓰면 8.22초, Cache-DiT를 추가하면 5.20초로 줄었다. 영상 생성에서는 MiniMax-H3의 V2V(영상→영상)가 103.18초로 T2V(텍스트→영상)의 31.15초보다 3배 이상 느린데, 연구팀은 이를 입력 영상 조건이 추가된 작업량과 관련지어 해석했다. 전이중 음성 MiniCPM-o 4.5는 동시성 1에서 8로 늘리자 평균 TTFP가 433ms에서 1533ms로, RTF가 0.18에서 0.90으로 올랐고, 동시성 8 출력 128개의 Whisper WER은 1.6%였다.

구체적인 예시

작동 방식을 이해하기 위한 음성 비서 예를 들면, 사용자가 질문을 하면 thinker가 텍스트 답변을 생성하고, talker가 그 답변의 음성 코덱을 만들고, code2wav가 파형을 복원한다. async_chunk를 켜면 talker가 코덱 프레임을 만드는 즉시 code2wav가 파형 복원을 시작하므로, 사용자는 전체 답변이 끝나기 전에 첫 소리를 들을 수 있다. 반대로 async_chunk를 끄면 code2wav가 talker의 전체 코덱 시퀀스를 기다려야 해서 첫 소리가 늦어진다.

로봇 정책 서빙은 채팅 API에 맞지 않아 OpenPI 호환 WebSocket 어댑터를 따로 둔다. JSON 대신 msgpack을 쓰고, 연결 직후 서버가 행동 길이(action horizon), 행동 키, 이미지 해상도를 알려 준다. 클라이언트는 첫 추론 전에 로봇 구성이 맞는지 확인할 수 있다. 로봇 정책은 처리량보다 에피소드 사이 상태가 섞이지 않는 것이 중요하므로, 보통 한 번에 한 시퀀스만 받고 세션 고정에 의존한다.

한계와 오해하기 쉬운 점

이 보고서는 vLLM-Omni의 설계와 운영 상태를 투명하게 공개한 문서에 가깝고, 다른 시스템보다 빠르다는 것을 보이는 논문은 아니다. SGLang-Omni나 M* 같은 다단계 옴니 서빙 시스템을 관련 연구에서 언급하지만, 이번 판에서는 이들과의 성능 비교를 제외했다. 따라서 vLLM-Omni를 다른 프레임워크 대신 쓸지는 이 보고서만으로 판단할 수 없다.

옵트인 프로필의 안정성이 고르지 않다. Qwen3-Omni MRv2는 한 줄 수정 없이 시작되지 않았고, 텍스트 전용 경로에서는 두 번의 실행에서 동시성 32의 세 번째 반복 중 thinker가 종료되어 128개 요청 중 32개가 실패했다. MiniCPM-o 4.5 MRv2는 출력의 13%에서 목표 문장 뒤에 관계없는 음성을 덧붙이며 멈추지 않아 WER이 12.9%로 올랐고, 연구팀은 이를 정상 성능 표에서 제외하고 본문에 실패 조건으로 공개했다. 속도만으로 품질과 안정성을 보장하지 않는다는 점을 보여준다.

표끼리 직접 비교하기 어렵다. H100과 H200, 서로 다른 날짜와 커밋, 서로 다른 GPU 수의 결과가 섞여 있다. 이미지·영상 수치는 9월 14일 고정 nightly 또는 해당 레시피 기준선이고, async_chunk·복제 실험은 7월 5~11일 nightly 평균이다. H200 음성 표는 별도 측정으로 모든 숫자가 동일 날짜·하드웨어·부하에서 나온 것은 아니다. 같은 표 안에서도 GPU 수·모델·부하가 달라지므로 비교할 행의 조건을 각각 확인해야 한다.

전이중 제어와 월드 모델 세션은 발전 중인 기능이며 모든 배포의 기본값이 아니다. OpenPI로 로봇 입출력을 연결하는 구조를 제시하지만 폐루프 로봇 성능과 여러 하드웨어의 정량 비교는 후속 과제다. 측정은 NVIDIA GPU뿐이며, ROCm, Ascend NPU, Intel XPU 지원을 설명하지만 다른 하드웨어에서의 측정은 향후 과제로 남겼다.

실제로 어떻게 활용할까

음성, 이미지, 행동 생성 모델을 서비스하는 팀이라면, 어느 스테이지를 나누고 어느 스테이지를 합칠지, 스테이지 사이에서 무엇을 스트리밍할지를 설계할 때 이 보고서의 구조를 참고할 수 있다. 예를 들어 Qwen3-TTS의 fused 프로필은 코덱 디코더가 talker와 GPU를 같이 쓸 만큼 가벼우면 둘을 합쳐 스테이지 사이 전달을 없애는 편이 낫다는 것을 보여준다. 반대로 thinker와 보코더는 메모리와 지연 프로필이 다르므로 분리해 독립적으로 확장할 수 있다.

해설이 인용한 Quickstart의 Linux·Python 3.12 환경과 모델별 배포 레시피를 출발점으로 삼을 수 있다. vLLM과 vLLM-Omni는 major·minor 버전 계열을 맞추고, 선택적 프로필의 상태를 확인해야 한다. PR 단계의 설정에서 좋은 속도가 나왔다는 사실만으로 현재 서비스에서 안정적으로 쓸 수 있다는 뜻은 아니다.