NVIDIA Vera Rubin NVL72, MLPerf 첫 공개에서 최대 3.7배 처리량
AI를 활용하여 생성한 이미지입니다.
NVIDIA Vera Rubin NVL72의 MLPerf Inference v6.1 첫 프리뷰 결과에서 Qwen3-VL 기준 기존 GB300 NVL72보다 최대 3.7배 높은 처리량이 제시됐습니다. 하지만 이 수치를 모든 AI 서비스가 3.7배 빨라진다는 뜻으로 읽으면 곤란합니다. 특정 모델, 시나리오, GPU 구성과 소프트웨어 스택에서 나온 제출 결과이기 때문입니다.[1]
무엇이 공개됐나요?
NVIDIA는 2026년 9월 16일 Vera Rubin NVL72의 MLPerf Inference v6.1 프리뷰 제출 결과를 설명했습니다. Qwen3-VL의 오프라인·서버·대화형 시나리오에서 최대 3.7배, DeepSeek-R1에서는 최대 2.5배의 처리량을 제시했습니다. 결과에는 vLLM, NVIDIA Dynamo, TensorRT-LLM 같은 소프트웨어 구성이 함께 사용됐습니다.[1]
비교 대상인 GB300 NVL72도 단일 GPU의 단순한 결과가 아닙니다. NVIDIA는 72개 GPU가 들어간 한 랙에서 네 랙, 총 288개 GPU로 확장한 DeepSeek-R1 제출에서 99% 확장 효율을 기록했다고 밝혔습니다.[1] GPU 수를 네 배로 늘렸을 때 처리량이 해당 조건에서 거의 비례해 늘었다는 의미지만, 다른 모델과 네트워크에서도 같은 수치가 재현된다는 뜻은 아닙니다.
| 비교 항목 | 공개된 내용 | 읽을 때의 기준 |
|---|---|---|
| 모델 | Qwen3-VL, DeepSeek-R1 | 자사 모델과 컨텍스트 길이로 다시 측정 |
| 수치 | 최대 3.7배·2.5배 | 평균값과 최대값을 구분 |
| 확장 | 288 GPU에서 99% 효율 | 랙 간 네트워크·요청 분배 조건 확인 |
| 결과 성격 | MLPerf v6.1 프리뷰 제출 | 검증된 표와 제조사 후속 발표를 분리 |
하드웨어만의 결과가 아닌 이유
NVIDIA는 Qwen3-VL 성능이 v6.0보다 최대 1.6배 높아졌다고 설명하면서 모델 가중치와 KV 캐시의 정밀도 조정, 커널 융합, 프리필과 디코드 분리 같은 최적화를 함께 언급했습니다.[1] 따라서 Vera Rubin과 GB300의 세대 차이만 떼어 비교하면 실제 기여도를 과장할 수 있습니다. 동일한 모델, 동일한 입력·출력 길이, 동일한 소프트웨어 버전을 맞춰야 하드웨어 차이에 가까운 비교가 됩니다.
NVL72의 의미는 GPU 한 장의 사양보다 랙 전체를 하나의 추론 시스템으로 묶는 데 있습니다. NVLink와 NVLink Switch 같은 연결망, 여러 GPU에 걸친 전문가 병렬화, 요청 오케스트레이션이 함께 작동합니다.[1] 실제 서비스 비용은 GPU 처리량뿐 아니라 메모리 용량, 모델 병렬화 방식, 배치 크기, 입력·출력 토큰 길이, 네트워크 지연과 전력·냉각 설비에 의해 달라집니다.
기업이 바로 구매해야 할까요?
이번 결과만으로 구매를 결정하기보다 검증 계획을 먼저 세우는 편이 현실적입니다. 현재 서비스의 모델별 입력·출력 토큰 분포, 동시 요청 수, 첫 토큰 지연시간, 전체 응답시간, 시간대별 요청량을 기록하세요. 그 다음 기존 서버와 검토 중인 랙 구성을 같은 모델과 소프트웨어 조건으로 비교해야 합니다. 처리량 하나만 보면 대화형 서비스의 체감 지연이나 장애 시 동작을 놓칠 수 있습니다.
- 현재 모델과 양자화·정밀도 조건을 고정합니다.
- 짧은 요청과 긴 컨텍스트, 단일 요청과 동시 요청을 별도 구간으로 나눕니다.
- 평균·최대 처리량, 첫 토큰 지연, 전체 응답시간을 따로 기록합니다.
- 전력·냉각·네트워크 비용과 운영 인력을 GPU 가격 옆에 놓습니다.
- 소프트웨어 업데이트 전후의 결과와 장애 복구 시간을 남깁니다.
국내 인프라에서 함께 볼 부분
GPU를 추가하면 성능이 자동으로 늘어난다는 생각보다, GPU 사이의 데이터 이동과 데이터센터 연결망이 병목이 되는지 먼저 살펴야 합니다. NVIDIA의 다른 설명에서도 토큰당 전력 효율과 AI 공장 단위 최적화가 강조됩니다.[2] 대규모 랙을 도입할 수 있는지 판단할 때는 전력 밀도, 냉각, 네트워크, 소프트웨어 운영 역량을 한 묶음으로 계산해야 합니다.
관련 배경은 GPU 다음은 광통신, AI 데이터센터 연결망 국산화가 중요한 이유에서도 이어서 볼 수 있습니다. 연결망이 충분하지 않으면 GPU 수를 늘려도 요청이 기다리는 시간이 줄지 않을 수 있습니다.
프리뷰 결과에서 남는 불확실성
이번 글의 핵심 수치는 NVIDIA가 설명한 프리뷰 제출 결과입니다. NVIDIA는 제출 이후 소프트웨어 최적화로 더 좋아진 일부 수치를 언급했지만, 제출 후 수치는 아직 MLCommons가 검증하지 않았다고 밝혔습니다.[1] 따라서 공식 검증 결과와 제조사가 추가로 제시한 수치를 한 표에 섞어 비교하면 안 됩니다. 가격, 국내 공급 시점, 실제 시스템 구성과 전력 요구량도 이번 발표만으로는 알 수 없습니다.
큰 모델과 많은 요청, 랙 단위 확장이 필요한 사업자에게는 의미가 클 수 있지만, 소규모 추론 서비스라면 기존 서버의 배치·캐시·커널 최적화가 더 적합할 수도 있습니다. 발표의 최대 수치를 자사 평균 트래픽에 곧바로 적용하지 말고, 비용 대비 처리량과 장애 대응까지 확인한 뒤 결정하세요.
벤치마크 숫자를 자사 서비스 숫자로 바꾸는 법
공개 결과를 도입 판단에 쓰려면 먼저 비교표를 다시 만들어야 합니다. 모델 이름만 같게 두지 말고 가중치 정밀도, 입력 컨텍스트 길이, 출력 토큰 수, 배치 크기, 동시 요청 수, 소프트웨어 버전, 전력 제한, 네트워크 토폴로지를 기록하세요. 이 항목 중 하나가 달라지면 처리량이 바뀌어도 하드웨어 세대의 효과인지 운영 조건의 효과인지 나누기 어렵습니다.
대화형 서비스와 배치 작업의 목표도 다릅니다. 배치 작업은 일정 시간 동안 처리한 요청 수와 전력당 처리량이 중요할 수 있지만, 대화형 서비스는 첫 토큰 지연과 꼬리 지연이 더 직접적인 사용자 경험이 됩니다. 에이전트 서비스는 모델 응답 외에 도구 호출·재시도·검색·보안 필터가 포함되므로 MLPerf의 단일 추론 결과를 전체 요청 시간으로 바꾸어 계산하지 마세요.
랙 단위 도입에서 놓치기 쉬운 병목
- GPU 메모리에 모델과 KV 캐시가 함께 들어가는지 확인합니다.
- 랙 간 통신이 늘어날 때 네트워크 대역폭과 지연을 기록합니다.
- 전력 밀도와 냉각 용량이 실제 설치 장소에 맞는지 검토합니다.
- 한 GPU나 네트워크 경로가 장애일 때 작업을 어떻게 재배치할지 정합니다.
- 드라이버·런타임·추론 서버를 누가 업데이트하고 되돌릴지 정합니다.
“확장 효율 99%”라는 문구는 해당 제출의 네 랙·288 GPU 조건을 설명하는 지표입니다.[1] 작은 클러스터나 다른 토폴로지에서 같은 효율을 약속하는 문구로 사용하면 안 됩니다. 실제 구매 제안서에는 랙 수를 늘릴 때 전력·네트워크·운영 인력이 어떻게 증가하는지 별도 항목으로 적으세요.
제조사 발표와 독립 검증을 나눠 읽기
MLPerf의 제출 결과, 공식 검증 표, 제출 이후 제조사가 설명한 소프트웨어 개선은 서로 다른 증거입니다. 발표 자료의 문장을 인용할 때는 “NVIDIA가 제시했다”라고 주체를 표시하고, 검증된 공통 비교 결과처럼 다시 쓰지 마세요.[1] 후속 성능이 좋아졌다는 설명도 사용자의 모델·버전·입력 조건에서 재현되는지 확인하기 전에는 구매 근거의 상한으로만 두는 편이 안전합니다.
토큰당 전력 효율을 볼 때도 토큰 정의와 시스템 경계를 확인해야 합니다. GPU만 계산한 값인지, 서버·네트워크·냉각을 포함한 값인지에 따라 기업의 실제 비용과 비교할 수 있는 수준이 달라집니다. NVIDIA의 AI 인프라 설명에서 에너지 효율이 강조되더라도, 국내 데이터센터의 전력 계약과 냉각 설비에 그대로 대입할 수 있는 수치는 아닙니다.[2]
소규모 팀의 대안 비교
요청량이 많지 않거나 모델이 한 장의 GPU에 들어간다면 랙 교체보다 배치 정책, KV 캐시, 양자화, 커널, 요청 라우팅을 먼저 점검할 수 있습니다. 반대로 긴 컨텍스트와 높은 동시성 때문에 메모리·네트워크가 이미 병목이라면 랙 단위 시스템의 이점이 커질 수 있습니다. 어느 쪽이든 현재 장애율과 지연 분포를 기준선으로 남겨야 개선 여부를 말할 수 있습니다.
검증 실행 전에 정할 질문
- 우리 서비스에서 처리량과 지연 중 어느 지표가 매출·사용자 경험에 더 직접적인가요?
- 프리뷰에 사용된 모델과 같은 모델을 실제로 운영하나요?
- 전력·냉각·네트워크 공사가 서버 가격에 포함되어 있나요?
- 소프트웨어 업데이트가 성능과 안정성에 미치는 영향을 누가 검증하나요?
- 장애 때 목표 복구 시간과 성능 저하를 수용할 수 있나요?
자주 묻는 질문
3.7배면 응답시간도 3.7배 짧아지나요?
아닙니다. 공개된 수치는 특정 조건의 처리량입니다. 첫 토큰 지연과 전체 응답시간은 별도로 측정해야 합니다.
MLPerf 결과가 있으면 모든 모델 비교가 끝나나요?
아닙니다. 벤치마크의 모델·입력·소프트웨어 조건이 실제 서비스와 같은지 확인해야 합니다.[1]
작은 서비스도 NVL72가 필요한가요?
요청량과 모델 크기, 랙 확장 필요성에 따라 다릅니다. 기존 인프라 최적화와 총소유비용을 먼저 비교하세요.
도입 검토 체크리스트
- 현재 모델과 같은 조건으로 반복 가능한 테스트를 정의합니다.
- 최대 처리량과 평균 처리량을 구분합니다.
- 첫 토큰·전체 응답·동시 요청 지연을 따로 기록합니다.
- 전력·냉각·네트워크와 소프트웨어 운영 비용을 합산합니다.
- MLCommons 검증 결과와 제조사 프리뷰 수치를 분리해 표시합니다.
