영상 모델 옆에 옴니 모델은 앉지 못합니다
멀티모달 워크로드를 사내 GPU에 올릴지 검토하는 플랫폼 엔지니어와 아키텍트를 위한 글입니다. 읽고 나면 하나의 옴니 모델과 여러 전문 모델을 잇는 파이프라인 중 무엇을 고를지가 품질 취향이 아니라 카드 한 장에 무엇이 들어가느냐의 산술이라는 것과, 그 산술에 넣을 숫자를 알게 됩니다.
결론부터 말하겠습니다. NVIDIA H200 한 장에서 영상 모델과 음성 전문가들을 다 올리면 72.37GiB로 카드의 51.8%를 씁니다. 같은 카드에 영상 모델과 옴니 모델을 올리면 130.29GiB, 93.2%가 되어 생성 중에 쓸 여유가 9.5GiB밖에 남지 않습니다. 영상 생성만으로 상주량보다 3.57GiB를 더 쓰는 것을 감안하면 이 조합은 사실상 들어가지 않습니다. 옴니가 그 자리값으로 사 준 것은 전사 문자 오류율 1.34%p였습니다.
스테이지가 늘어날수록 문제는 연산이 아니라 자리싸움이 됩니다.
같은 카드, 같은 파형, 두 가지 접근
멀티모달 생성은 지금 두 갈래입니다. 하나는 텍스트와 이미지와 소리와 영상을 한 모델이 다 받고 다 내놓는 옴니 방향이고, 다른 하나는 일마다 전문 모델을 두고 이어 붙이는 파이프라인 방향입니다. 어느 쪽이 나은지는 벤치마크 점수표로 답이 안 나옵니다. 두 접근의 비용 구조가 아예 다르기 때문입니다.
그래서 한 카드 위에 둘 다 올리고 똑같은 일을 시켰습니다. 음성 합성 모델이 한국어 문단을 읽어 파형을 만들고, 그 파형을 전사 전문 모델과 옴니 모델이 각각 받아 적습니다. 여기에 사람이 실제로 말한 49초짜리 녹음을 하나 더 넣었습니다. 이 녹음에는 정답 원고가 있어서 두 모델의 전사를 같은 기준으로 채점할 수 있습니다.
쓴 모델은 영상이 Wan 2.2 T2V A14B, 음성 합성이 Qwen3-TTS 1.7B, 전사가 Qwen3-ASR 1.7B, 옴니가 Qwen3-Omni-30B-A3B입니다. 넷 다 Apache 2.0이라 국내에서 가중치를 받아 돌리는 데 라이선스 제약이 없습니다. 앞선 글에서 다룬 대로 영역 제한이 걸린 모델들은 애초에 후보가 아니었고, 이 선택이 곧 그 글의 실무적 귀결입니다.
환경은 H200 NVL 한 장에 VRAM 139.8GiB, torch 2.11.0에 transformers 5.14.1, diffusers 0.39.0입니다. 이 글의 모든 수치는 이 한 조합에서 나왔습니다. 가중치는 전부 사내 레지스트리에서 받았습니다.
프로브 대역폭으로 용량 계획을 세우면 안 됩니다
첫 숫자는 측정하려던 것이 아닌데 눈에 걸렸습니다.
레지스트리에서 전사 모델 3.81GiB를 파일 9개로 받는 데 초당 540MiB, 옴니 모델 65.69GiB를 24개로 받는 데 297MiB, 영상 모델 117.53GiB를 49개로 받는 데 308MiB가 나왔습니다. 스레드는 셋 다 16개로 같았습니다.
이 값들은 실행할 때마다 흔들립니다. 같은 옴니 모델을 다른 시각에 받으면 470MiB가 나오기도 했습니다. 공유 오브젝트 스토어라 그때그때 다릅니다. 그러니 파일이 많을수록 느려진다는 식의 규칙을 세우기는 어렵고, 확실한 것은 범위입니다. 실제 다중 파일 풀은 초당 260에서 550MiB 사이였습니다.
중요한 것은 그 위입니다. 저희가 전에 단일 객체 하나를 당겨 대역폭을 재봤을 때는 916MiB/s가 나왔습니다. 그 숫자로 용량 계획을 세웠으면 실제 소요를 두세 배 낮춰 잡았을 겁니다. 프로브는 도달 가능한지를 답하지 얼마나 걸리는지를 답하지 않습니다.
음성 계층: 옴니가 2.26배 느리고 17배 큽니다
49.34초짜리 한국어 녹음을 받아 적는 같은 일을 두 모델에게 시켰습니다.
| 전사 전문가 | 옴니 | |
|---|---|---|
| 모델 | Qwen3-ASR 1.7B | Qwen3-Omni 30B-A3B |
| 상주 VRAM | 3.83GiB | 65.72GiB |
| 49.3초 전사 | 2.107초 | 4.755초 |
| 실시간 대비 | 23.4배 | 10.4배 |
| 문자 오류율 | 7.59% | 6.25% |
옴니는 지연이 2.26배, 상주 메모리가 17.16배입니다. 음성 합성 모델까지 더한 전문가 두 벌의 상주량이 7.8GiB이니, 옴니 한 벌은 음성 계층 전체의 8.43배를 혼자 씁니다. 그러고서 얻은 것이 문자 오류율 1.34%p 개선입니다.
콜드 로드 시간은 일부러 뺐습니다. 재보니 어느 모델을 먼저 올리느냐에 따라 값이 뒤집혔습니다. 한 실행에서는 전사 모델이 1.45초에 옴니가 9.23초였고, 다른 실행에서는 전사 모델이 89.63초에 옴니가 19.39초였습니다. 첫 로드가 CUDA 컨텍스트 초기화와 차가운 파일 캐시를 같이 뒤집어쓰기 때문입니다. 로드 시간은 모델의 성질이 아니라 그 순간 캐시 상태의 성질이라, 모델을 고르는 근거로 쓸 수 없습니다.
두 모델이 틀리는 방식도 달랐습니다. 전문가는 “클로드”를 “클라우드”로 계속 잘못 들었고, 옴니는 그 고유명사는 맞혔지만 “매 턴마다”를 “매 토큰마다”로 바꿔 적었습니다. 도메인 용어를 지켜야 하는 작업이라면 이 차이가 오류율 숫자보다 중요할 수 있습니다.
한 가지는 정직하게 덧붙여야겠습니다. 남은 오류의 상당 부분이 인식 실패가 아니라 표기 관습입니다. 정답 원고는 “열 배”와 “오 분”이라고 적혀 있는데 두 모델 모두 “10배”와 “5분”으로 받아 적었습니다. 그러니 1.34%p라는 간격은 방향을 보여 주는 값이지 확정적인 우열은 아닙니다. 카드를 17배 더 쓸 이유로 삼기에는 얇습니다. 다만 이 격차 자체는 서로 다른 두 실행에서 소수점까지 같게 나왔습니다.
채점 방식도 밝혀 둘 필요가 있습니다. 두 모델 다 답 주위에 군더더기를 답니다. 전문가는 대화 템플릿 조각을 앞에 붙이고, 옴니는 받은 지시문을 그대로 되풀이한 다음 답을 시작합니다. 이 군더더기를 한쪽에서만 걷어내면 순위가 통째로 바뀝니다. 옴니 쪽 지시문 반향을 남겨 둔 채로 세면 옴니 오류율이 14.29%가 되어 전문가가 두 배 정확하다는 정반대 결론이 나옵니다. 그래서 같은 종류의 군더더기를 양쪽에서 같은 기준으로 걷어낸 뒤에 셌고, 위 표의 값이 그 결과입니다. 모델 두 개를 비교하는 벤치마크에서 전처리 비대칭은 모델 차이보다 큰 값을 만들어 냅니다.
영상 계층: 한 스테이지가 카드의 46%입니다
영상 모델은 디스크에서 VRAM으로 올리는 데 185.31초가 걸렸고 상주량은 64.57GiB였습니다. A14B라는 이름과 달리 전문가 두 벌을 각각 들고 있어서, 실제로 앉는 양은 그 두 배에 인코더와 디코더가 얹힌 값입니다.
생성은 480x832 해상도에 20스텝으로 고정하고 프레임 수만 늘려 가며 쟀습니다. 2.06초 영상이 49.2초, 3.06초가 79.6초, 5.06초가 152.3초였습니다. 프레임을 2.5배로 늘리면 시간은 3.1배가 되어 영상 1초당 단가가 23.9초에서 30.1초로 올라갑니다. 어텐션이 프레임 수에 제곱으로 붙는 탓이라 긴 클립일수록 손해입니다. 15초를 한 번에 뽑는 것보다 5초를 세 번 뽑아 잇는 쪽이 쌉니다.
재현성은 좋았습니다. 같은 설정을 반복해도 편차가 0.09초 안이었고 버리려고 돌린 워밍업조차 정상 실행과 거의 같았습니다. 디퓨전은 정해진 스텝을 정직하게 다 도는 구조라 흔들릴 여지가 별로 없습니다. 토큰 수에 따라 시간이 널뛰는 언어 모델과 달리 용량 계획을 세우기가 오히려 쉽습니다.
왼쪽은 같은 파형을 받아 적는 두 접근의 지연과 상주 메모리이고, 오른쪽은 영상 스테이지를 더했을 때 카드 한 장에 무엇이 들어가는지입니다. 모두 같은 H200 한 장에서 잰 값입니다.
그래서 산술은 이렇게 끝납니다
이제 두 선택지를 같은 자로 잴 수 있습니다.
전문가 파이프라인을 전부 상주시키면 영상 64.57GiB에 음성 두 벌 7.8GiB를 더해 72.37GiB, 카드의 51.8%입니다. 절반 넘게 남으니 생성 중 활성 메모리까지 감당하고도 여유가 있습니다. 스테이지 경계 비용은 0이 됩니다.
옴니로 음성 계층을 대신하면 영상 64.57GiB에 옴니 65.72GiB를 더해 130.29GiB, 93.2%입니다. 남는 것이 9.5GiB인데 영상 생성이 상주량 위로 3.57GiB를 더 씁니다. 산술로만 겨우 들어가고 운영 여유는 없습니다.
여기서 흔한 직관이 뒤집힙니다. 모델을 하나로 접었으니 자리를 덜 차지하리라고 생각하기 쉽지만, 이 조합에서는 반대였습니다. 음성 전문가들이 워낙 작아서 파이프라인 쪽 자리값이 이미 반올림 오차 수준이기 때문입니다. 카드를 실제로 잡아먹는 것은 스테이지 개수가 아니라 영상 모델 하나입니다.
그러면 판단은 이렇게 정리됩니다. 음성과 언어처럼 전문 모델이 작은 계층에서는 파이프라인이 거의 언제나 유리합니다. 옴니가 이기려면 정확도 이득이 상주량 열몇 배를 정당화할 만큼 커야 하는데, 이번 측정에서는 1.34%p였습니다. 반대로 각 계층의 전문 모델이 옴니와 비슷한 덩치라면 이야기가 달라집니다. 그때는 경계마다 내렸다 올리는 비용이 생기고, 같은 모델을 그대로 다시 올리는 데만 195.28초가 들었으니 요청마다 3분씩 앞에 붙는 셈입니다.
서빙과 오케스트레이션이 알아야 할 것
Metis처럼 추론을 서빙하는 계층에서 지금까지의 배치 단위는 대체로 모델 하나였습니다. 그런데 멀티모달 워크로드는 모델 하나가 아니라 스테이지 묶음으로 들어오고, 그 묶음이 한 카드에 같이 앉느냐가 응답 시간을 분 단위로 바꿉니다. 스케줄러가 알아야 할 것은 개별 모델의 크기가 아니라 묶음 전체의 상주 요구량입니다. 같은 파이프라인에 속한 스테이지를 같은 카드에 모으는 것은 최적화가 아니라 정확성 요건에 가깝습니다.
Paxis처럼 여러 모델을 잇는 워크플로를 실행하는 계층에는 순서 문제가 남습니다. 같은 스테이지를 쓰는 작업을 모아 처리하면 교체가 줄고, 작업마다 스테이지를 오가면 교체가 늘어납니다. 195초라는 숫자를 아는 스케줄러와 모르는 스케줄러의 처리량 차이는 모델을 더 좋은 것으로 바꿔서 얻을 수 있는 차이보다 큽니다.
정리하면
같은 카드에서 같은 파형으로 재보니 옴니 모델은 전사 오류율을 1.34%p 낮추는 대신 지연 2.26배와 상주 메모리 17배를 요구했습니다. 음성 전문가 두 벌을 합쳐도 7.8GiB라 파이프라인 쪽 자리값은 사실상 무시할 수 있고, 카드를 채우는 것은 영상 모델 하나였습니다. 그래서 영상과 음성을 함께 서빙한다면 파이프라인이 카드 한 장에 들어가고 옴니는 들어가지 않습니다.
옴니 모델이 상주 슬롯을 아껴 준다는 기대는 각 계층의 전문 모델이 옴니만큼 클 때만 성립합니다. 음성처럼 전문 모델이 작은 계층에서는 그 기대가 그대로 뒤집힙니다.
이 글의 모든 수치는 2026년 8월 9일 NVIDIA H200 NVL 한 장, torch 2.11.0과 diffusers 0.39.0이라는 하나의 조합에서 측정한 값입니다. 옴니와 전사 전문가는 같은 프로세스 안에서 같은 파형을 받았습니다. 측정 스크립트와 원본 결과는 사내 저장소에 그대로 두었습니다.
