NVIDIA가 옴니 모델 또 풀었는데, 진짜 봐야 할 건 벤치마크가 아님

며칠 전 NVIDIA가 Nemotron 3 Nano Omni라는 옴니 모달 모델을 공개함. 30B total / 3B active MoE, 텍스트·이미지·오디오·비디오를 한 번의 forward pass로 처리. open weights에 build.nvidia.com에서 NIM 엔드포인트로 호출 가능하고, OpenRouter 무료 티어에도 올라와 있음.

다들 "비디오 throughput 9.2배", "6개 리더보드 1위" 같은 헤드라인을 강조하는데 솔직히 그쪽은 별로 안 흥미로움. 진짜 메시지는 어떻게 조립했는가 쪽임. NVIDIA가 새 인코더를 발명한 게 아니고, 이미 best-of-breed로 알려져 있던 부품들을 골라 얇은 projector로 묶어버린 거거든요. 에이전트 만드는 입장에서 이게 왜 의미 있는지 풀어봅니다.

본문에 자주 나올 용어 몇 개 짚고 가기.

• MoE (Mixture of Experts): 전체 파라미터는 크게 두지만 토큰마다 일부 expert만 활성화시키는 구조. 30B 중 3B만 실제로 돈다는 게 이 얘기.
• Mamba / SSM: Transformer의 attention과 다른 방식으로 시퀀스를 처리하는 state-space 계열. 긴 컨텍스트를 선형 시간에 다룸.
• encoder: 이미지·오디오 같은 비-텍스트 입력을 LLM이 알아먹는 토큰 공간으로 변환하는 부품.
• projector: 인코더 출력을 LLM 입력 공간으로 매핑하는 얇은 MLP. 보통 2-layer.

합쳐진 부품들#

NVIDIA가 가져다 쓴 건 세 개임.

언어 백본은 NemotronH라는 회사 자체 하이브리드. Mamba-2 selective SSM 23 layer + MoE 23 layer (128 experts, top-6 routing) + grouped-query attention 6 layer. 30B 중 3B active, 컨텍스트 256K. attention layer를 6개로 박은 게 의미심장한데 뒤에서 다시 얘기함.

비전 인코더는 C-RADIOv4-H. 이게 살짝 특이함. 처음부터 contrastive로 학습한 인코더가 아니라, CLIP·DINOv2·SAM 같은 expert teacher들로부터 distill해서 한 백본에 합친 형태. 즉 한 인코더가 CLIP의 언어 정렬, DINOv2의 segmentation feature, SAM의 localization을 다 들고 있는 셈. 이런 distillation 기반 통합 인코더가 production에 들어간 건 좀 신기한 일임.

오디오 인코더는 Parakeet-TDT-0.6B-v2. FastConformer 24 layer + RNN-Transducer head. Hugging Face Open ASR 영문 부문에서 한참 1위 자리에 있던 그 모델임. Cache-Aware 변형이라 streaming 입력에서도 동작.

이 셋을 2-layer MLP projector로 LLM 입력 공간에 붙였음. 인코더 자체는 거의 그대로 두고, 묶는 부분만 얇게.

백본만 봐도 흥미로움#

순수 Transformer는 시퀀스 길이에 quadratic — 비디오 토큰 깔리면 메모리 폭발. 순수 Mamba는 빠른데 정확한 토큰 recall이 필요한 일에서 약하다는 게 그동안의 평가. 둘을 섞은 hybrid에서 SSM은 길게 깔린 컨텍스트를 싸게 처리하고, attention layer는 정확도가 진짜 필요한 6개 위치에만 박아둠.

256K 컨텍스트에 비디오 프레임 토큰까지 들어찼는데 OOM이 안 난다는 건 이런 분배 때문임. 이 부분은 공식 모델 카드 기준이라, 실제 GPU에서 비디오 길이 늘리면 어떻게 바뀌는지는 직접 돌려봐야 알 듯.

MoE 쪽도 흥미로운데, 128 expert에 top-6 routing이라는 건 토큰마다 6개 expert만 켜진다는 얘기. 3B active 숫자가 여기서 나옴. Qwen·DeepSeek이 MoE로 LLM 단가 떨어뜨린 트릭을 그대로 멀티모달에 적용한 형태로 보면 됨.

인코더 선택의 진짜 무게#

C-RADIO가 가진 native 1920×1080 입력은 컴퓨터 사용 에이전트에서 결정적임. 보통 VLM은 384×384, 잘해야 768×768 입력인데, 이 해상도로는 Salesforce 같은 실제 SaaS UI의 라벨을 못 읽거든요. 라벨이 깨지면 에이전트가 환각 시작하고, 한 번 환각 들어가면 click 시퀀스 전체가 망가짐. 풀HD 입력 가능하다는 건 "이제야 GUI를 진짜로 본다"는 의미에 가까움.

이게 진짜 production에서 어떻게 도움이 되는지는 한 컴퓨터 사용 에이전트 회사가 OSWorld 벤치에서 "significant leap"을 봤다는 보고가 있는데, 정확한 수치는 공개 안 됨. 그냥 발표 그대로 믿기엔 좀 그렇고, third-party 재현 결과 좀 모이고 나서 평가해야 할 듯.

Parakeet 쪽은 streaming이 핵심. 라이브 콜 듣는 에이전트라면 음성 끝나길 기다렸다가 ASR 돌리는 구조로는 절대 못 씀. Cache-Aware FastConformer는 chunk 단위로 들어오는 오디오에 대해 부분 출력을 만들 수 있게 설계됨. ASR 25개 언어 지원이라는데 한국어 정확도는 직접 안 써봐서 모르겠음. Parakeet 자체가 영어 중심 모델로 알려져 있어서 그쪽은 좀 의심스러움.

3B active의 경제학#

이 부분이 백엔드 입장에서 제일 와닿음.

공식 가이드 기준으로 FP8 양자화면 32GB GPU 한 장에 들어가고, INT4면 24GB 컨슈머 카드에 들어감. 즉 RTX 4090에서 돈다는 얘기. 직접 돌린 건 아니라 비디오 입력을 늘렸을 때 메모리가 어떻게 잡히는지는 모르겠는데, 텍스트+이미지 정도는 컨슈머 GPU에서 무난할 듯. NVIDIA가 DGX Spark·DGX Station 같은 워크스테이션 환경을 first-class로 명시한 걸 보면, 로컬 개발자 워크플로우를 진지하게 타겟한 흔적이 보임.

이게 에이전트 fleet 비용 모델을 다시 짜게 만듦. 기존엔 customer support 세션 하나당 비전 모델 forward, ASR forward, LLM forward — 모달리티별로 forward 따로. 한 세션에 3 forward * N modality. 이걸 1 forward × 3B active로 줄이면 단가가 그냥 다른 차원으로 내려옴.

물론 "단가 떨어진다"는 게 9.2배 throughput 수치 그대로 적용된다는 보장은 없음. 발표된 비교는 "at the same interactivity threshold" 조건부, 즉 사용자 체감 latency가 동일한 시점에서의 시스템 capacity 비교임. 이게 슬쩍 중요한 단서. apples-to-apples 비교라는 점에선 honest한 측정인데, 실제 워크로드에서는 모달리티 비율·prompt 패턴 따라 결과가 또 다를 수 있음.

한계 / 의심 가는 부분#

공식 발표 기반이라 거를 부분 몇 가지.

6개 리더보드 1위라는 표현은 카테고리 자체가 "open omni model"인데, 이 카테고리 비교군이 아직 작음. Gemini 같은 closed 모델 대비 절대 우위가 아니라, 같은 클래스 안에서의 1위. 이걸 헷갈리게 적은 글들이 좀 있어서 본인 손으로 카테고리 확인하는 걸 추천.

OSWorld 컴퓨터 사용 벤치에서의 "significant leap"은 숫자가 안 나와서 평가 보류. third-party 결과 나오기 전엔 그대로 받아들이긴 좀 그럼.

ASR 25개 언어 지원 중 한국어 품질은 직접 안 써봐서 모르겠음. Parakeet 영문 성능과 한국어 성능 사이에 갭이 꽤 있을 가능성이 큼. 후기 좀 모인 다음에 평가해야 할 듯.

마지막으로 NeMo-AutoModel 같은 NVIDIA 자체 툴체인 의존도가 좀 있어서, 다른 추론 엔진(vLLM, TGI 등)에서 어디까지 잘 도는지는 별도 확인 필요. open weights라고 다 똑같이 잘 도는 건 아님. Hugging Face 모델 카드에 BF16/FP8 두 버전이 같이 올라와 있는데, 양자화 변형끼리도 미세하게 동작 다른 경우가 종종 있음.

정리하며#

이 모델 자체보다 흥미로운 건 NVIDIA가 던진 조립법 메시지임. 새 인코더 만들지 말고, 모달리티별 SOTA 컴포넌트 골라서 projector로 묶어라. 적어도 2026년 시점에서 multimodal 시스템을 만드는 가장 합리적인 디폴트는 이 방향으로 보임.

본인 에이전트 만들 때 매번 vision tower 새로 학습할 이유 거의 없음. RADIO나 SigLIP 같은 distilled 인코더 가져다 쓰고, projector랑 작은 백본만 조인트 reasoning 잘하게 다듬는 게 leverage가 훨씬 큼. NVIDIA가 reference architecture를 production-quality 코드로 한 번 풀어놓은 거에 가까움. 안 따라할 거면 적어도 "내 vision tower가 RADIO보다 나은 이유"는 설명할 수 있어야 함. 못 하면 그냥 RADIO 쓰는 게 정답.

aickyway에서도 이미지 생성 파이프라인에 이런 조합 패턴이 들어가 있는데, 인코더는 사놓은 best-of-breed 그대로 두고 우리 프롬프트 변환 레이어만 손댄 게 결과적으로 가장 안정적이었음. 만들고 싶은 욕심을 버리는 게 leverage라는 말은 multimodal에서 특히 잘 맞는 듯.

직접 OpenRouter 무료 티어에서 텍스트 prompt 몇 개 던져볼 생각인데, 응답 톤이랑 한국어 처리 품질 어떤지 돌려본 후에 짧은 후기로 다시 돌아오겠음. 멀티모달 입력 테스트는 그 다음 단계.