OpenAI SemiAnalysis 관점: Vera Rubin NVL72, GB200 능가하지만 TCO 근거는 더 좁다

NVIDIA의 Vera Rubin NVL72가 최초의 측정된 실리콘 결과를 공개하며, 동일한 상호작용성에서 메가와트당 GB200 NVL72 처리량의 10배를 주장했다. OpenAI SemiAnalysis와의 연결고리는 Triton에 있다. Rubin 지원을 통해 널리 쓰이는 AI 소프트웨어에서 이 아키텍처의 활용 가능성을 드러낸다.

이 수치는 인상적이지만, Rubin을 2025년 초반 GB200 소프트웨어 기준선과 비교한 결과다. SemiAnalysis는 2026년 7월 Blackwell 결과와 비교했을 때 우위가 더 작았다고 분석했지만, Rubin은 테스트된 상호작용성 범위 전반에서 여전히 앞섰다.

이 구분이 실제 경쟁의 본질을 규정한다. Rubin은 단순히 구형 GPU를 대체하는 더 빠른 GPU가 아니다. 모델 규모, 메모리 트래픽, 토큰 수요가 함께 증가하는 상황에서도 반응성 높은 추론을 유지하도록 설계된 랙 규모 시스템이다.

이 결과는 GB200 운영자, 경쟁 가속기 공급업체, 맞춤형 커널을 유지보수하는 개발자에게 압박을 가한다. 동시에 중요한 검증 공백도 남긴다. 초기 테스트는 엔지니어링 샘플 랙, 이전 세대 추론 모델, 단일 턴 워크로드를 사용했다.

Rubin의 첫 결과가 NVL72 비교를 바꾸다

Rubin의 초기 우위는 실제로 보이지만, 10배 수치는 보편적 성능 비율이 아니라 최적 조건의 비교다.

CoreWeave는 2026년 7월 21일 최초의 측정된 Vera Rubin NVL72 실리콘 벤치마크를 공개했다. 엔지니어들은 동일한 주요 추론 최적화를 활성화한 상태에서 Rubin과 GB200 NVL72로 DeepSeek R1을 실행했다.

테스트는 사용자당 초당 토큰으로 표현한 상호작용성에 따라 메가와트당 출력 토큰 처리량을 측정했다. 추론 서비스는 총 용량과 허용 가능한 응답 속도 사이의 균형을 맞춰야 하므로 이는 중요하다.

동일한 상호작용성에서 측정된 실리콘 결과는 메가와트당 출력 토큰 처리량이 최대 10배 더 높았음을 보여줬다. 비교에는 2025년 GB200 NVL72 기준선이 사용됐다.

CoreWeave에 따르면 두 시스템 모두 NVFP4 정밀도, speculative decoding, 광범위한 expert parallelism, 그리고 분리형 prefill 및 decode를 사용했다. 서빙 소프트웨어는 TensorRT-LLM과 NVIDIA Dynamo가 제공했다.

NVFP4는 모델 저장 공간과 연산량을 줄이기 위한 NVIDIA의 4비트 수치 형식이다. Speculative decoding은 최종 검증에 앞서 후보 토큰을 생성하며, 예측이 성공할 경우 출력 속도를 높인다.

분리형 서빙은 서로 다른 GPU 그룹에 prefill과 decode를 나눠 배치한다. Prefill은 프롬프트를 처리하고, decode는 한 번에 하나씩 토큰을 생성해 응답을 만든다.

이러한 최적화가 중요한 이유는 벤치마크 결과가 실리콘만큼이나 소프트웨어 품질을 측정하는 경우가 많기 때문이다. 오래된 커널, 스케줄러, 병렬화 방식은 GPU 용량의 상당 부분을 사용하지 못하게 할 수 있다.

SemiAnalysis는 CoreWeave의 집계 방식에 맞추기 위해 자체 InferenceX 데이터를 조정했다. 원래 벤치마크는 출력 토큰만 보고하면서 prefill 및 decode GPU 모두의 전력을 계산했다.

2026년 7월 GB300 NVL72 결과와 비교하면, Rubin은 사용자당 초당 100토큰까지 거의 두 배의 처리량을 제공했다. 약 200토큰/초에서는 우위가 약 4배로 확대됐다.

초당 300토큰에서 보고된 비율은 5.4배에 이르렀다. 다만 SemiAnalysis는 GB300이 실현 가능한 성능 곡선의 한계에서 작동하고 있었다고 지적했다.

GB200은 테스트된 구성에서 그 상호작용성 수준에 도달하지 못했다. Rubin은 초당 350토큰까지 계속됐고, 이 지점에서 메가와트당 초당 70,703개의 출력 토큰을 생성했다.

이는 CoreWeave의 주장을 무효화하지 않는다. 초기 Rubin은 측정된 Blackwell 시스템보다 더 높은 상호작용성을 분명히 유지한다. 다만 구매자가 이 헤드라인에서 무엇을 추론해야 하는지는 달라진다.

10배라는 수치는 하나의 워크로드, 운영 지점, 소프트웨어 기준선, 집계 방식을 설명한다. 모든 Rubin 배포가 즉시 GB200 랙 10개를 대체한다는 뜻은 아니다.

더 강력한 결론은 더 좁지만 더 유용하다. Rubin은 Blackwell의 처리량이 급격히 떨어지는 작은 배치와 더 빠른 개별 응답 환경으로 서빙이 이동할 때도 효율성을 유지한다.

이러한 특성은 코딩 에이전트, 검색 시스템, 보안 애플리케이션에 직접적인 영향을 준다. 이 서비스들은 순차적인 모델 호출을 많이 생성하므로, 대규모 배치로 지연 시간을 숨기기 어렵다.

이제 피크 FLOPS보다 메가와트당 성능이 더 중요한 이유

전력 용량이 실질적 한계가 됐기 때문에, 유용한 메가와트당 토큰 수가 이론적 연산 처리량보다 더 중요할 수 있다.

가속기의 피크 FLOPS 수치는 특정 조건에서 가능한 최대 부동소수점 연산을 측정한다. 완성된 랙이 추론 모델을 얼마나 효율적으로 서빙하는지는 보여주지 않는다.

추론은 가중치, 활성화 값, KV-cache 데이터를 메모리와 연산 장치 사이에서 이동시킨다. KV cache는 이전 토큰의 어텐션 정보를 저장해 모델이 전체 시퀀스를 다시 계산하지 않도록 한다.

더 긴 컨텍스트는 이 캐시를 키운다. Mixture-of-experts 모델은 토큰을 특화된 서브네트워크 사이로 보내므로 GPU 간 통신 트래픽도 발생한다.

Rubin은 이러한 제약을 완전한 NVL72 시스템으로 해결한다. 이 랙은 Rubin GPU 72개, Vera CPU 36개, ConnectX-9 네트워킹, BlueField-4 프로세서, NVLink 6 스위치를 결합한다.

NVIDIA는 랙 전체에 걸쳐 20.7테라바이트의 HBM4 메모리를 제공한다고 명시한다. 또한 총 NVLink 6 스위치 대역폭은 초당 260테라바이트라고 설명한다.

각 GPU에는 초당 3.6테라바이트의 all-to-all scale-up 대역폭이 제공된다. Scale-up 네트워킹은 하나의 대규모 컴퓨팅 도메인 안에서 가속기들을 연결해 하나의 통합 장치처럼 동작할 수 있게 한다.

따라서 Rubin은 여러 계층에서 추론 효율을 높인다. 더 빠른 텐서 연산은 행렬 계산을 처리하고, HBM4는 가중치를 공급하며, NVLink는 전문가들 사이에서 토큰을 이동시킨다.

Vera CPU는 데이터 이동과 CPU 사용량이 많은 에이전트 작업을 관리한다. 여기에는 도구 호출, 코드 컴파일, 오케스트레이션, 샌드박스 실행이 포함될 수 있다.

NVIDIA의 NVL72 사양은 랙 수준 NVFP4 추론 성능 3,600페타플롭스를 제시한다. 회사는 GB200 NVL72와 비교해 토큰 비용이 10분의 1이라고도 주장한다.

이 수치들은 여전히 워크로드에 따라 달라지는 회사의 주장이다. 그럼에도 랙 아키텍처는 상호작용성이 증가할수록 Rubin의 우위가 커지는 이유를 설명한다.

대규모 배치는 많은 사용자가 각 가중치 로드를 공유하기 때문에 GPU가 계속 바쁘게 작동하도록 돕는다. 빠른 대화형 서비스는 배치 기회를 줄여 메모리 대역폭과 스케줄링에 대한 압박을 높인다.

GPU당 초당 22테라바이트에 이르는 Rubin의 HBM4 대역폭은 이러한 조건에서 더 큰 여유를 제공한다. SemiAnalysis는 이를 Blackwell Ultra의 전역 메모리 대역폭보다 2.8배 높다고 추정한다.

더 높은 대역폭이 메모리 지연 시간을 자동으로 줄이는 것은 아니다. 초당 더 많은 데이터를 이동시키지만, 개별 접근에는 여전히 비슷한 시간이 걸릴 수 있다.

따라서 높은 상호작용성에서 Rubin의 더 넓은 우위는 여러 메커니즘이 함께 작동한 결과다. 어느 하나의 피크 사양만으로는 이를 온전히 설명할 수 없다.

전력 지표에는 인프라 선택도 포함된다. 냉각 장비, 네트워킹, 호스트 프로세서, 스토리지, 전력 변환 손실은 모두 GPU 패키지 외부에서 전기를 소비한다.

NVIDIA는 섭씨 45도의 액체 냉각수가 유입되는 환경을 위해 Rubin을 설계했다. 호환되는 시설에서는 이 온도가 기존 칠러 없이 드라이 쿨링을 지원한다.

회사는 폐쇄 루프 방식이 물 사용량과 냉각 오버헤드를 줄일 수 있다고 말한다. 이러한 이점은 시설 설계에 좌우되며, 모든 기존 데이터센터에 적용된다고 가정해서는 안 된다.

SemiAnalysis는 액체 냉각 시스템 전반에 동일한 전력 사용 효율성 가정을 적용했다. 이 보수적인 선택은 Rubin의 시설 설계가 실리콘 비교를 부풀리는 것을 막는다.

결과는 여전히 Rubin에 유리하다. 더 중요한 점은 랙 아키텍처가 가속기 경제성과 분리될 수 없게 된 이유를 보여준다는 것이다.

구매자는 GPU FLOPS만 비교해 Rubin을 평가할 수 없다. 중요한 단위는 고정된 전력 한도 안에서 요구되는 응답 속도를 제공하는 서빙 시스템이다.

OpenAI SemiAnalysis 소프트웨어 지원이 Rubin에 더 이른 출발선을 제공하다

Rubin은 중요한 Blackwell 커널을 재사용할 수 있어, 개발자가 아키텍처별 튜닝을 시작하기 전 배포 작업을 단축할 수 있다.

OpenAI SemiAnalysis 관점은 OpenAI의 하드웨어 파트너십을 뜻하지 않는다. 이는 PyTorch, vLLM, CUDA 및 기타 공개 프로젝트와 함께 OpenAI Triton에서 Rubin 지원이 등장한 것을 가리킨다.

Triton은 Python과 유사한 문법으로 GPU 커널을 작성하기 위한 오픈소스 언어이자 컴파일러다. 커널은 GPU에서 연산 작업을 실행하는 특화 프로그램이다.

OpenAI는 저수준 CUDA 코드보다 고성능 커널 개발에 더 쉽게 접근할 수 있도록 Triton 프로그래밍을 도입했다. PyTorch 컴파일러와 추론 프로젝트는 이제 많은 연산에 Triton이 생성한 커널을 활용한다.

NVIDIA는 Rubin 지원과 업데이트된 PTX 명령어를 포함한 CUDA 13.4 개발자 프리뷰를 출시했다. PTX는 GPU 연산을 기술하기 위한 NVIDIA의 중간 명령어 언어다.

CUDA 프리뷰를 통해 개발자는 새로운 Rubin 기능을 살펴보고 소프트웨어 이식을 시작할 수 있다. NVIDIA는 이 프리뷰가 사전 출시 소프트웨어이며 프로덕션 벤치마킹에 적합하지 않다고 경고한다.

SemiAnalysis에 따르면 Rubin 관련 변경 사항은 PyTorch, vLLM, OpenAI Triton 리포지터리에도 반영됐다. 이러한 공개 노출은 프레임워크 개발자에게 광범위한 클라우드 제공 전에 적응할 시간을 준다.

Rubin의 streaming multiprocessor는 SM107 타깃을 사용한다. 더 중요한 점은 CUTLASS, DeepGEMM, FlashMLA 같은 라이브러리 전반에서 주요 Blackwell SM100 계열 커널을 실행할 수 있다는 것이다.

Blackwell은 Hopper로부터 같은 편의성을 물려받지 못했다. Tensor Core 프로그래밍 모델은 개발자가 하드웨어의 잠재력에 근접하기 전에 상당한 커널 재작성을 요구했다.

Rubin은 그 투자의 더 많은 부분을 보존한다. 팀은 기능하는 Blackwell 커널로 시작해 더 일찍 배포하고, 이후 가장 가치 있는 연산을 최적화할 수 있다.

호환성을 최대 성능과 혼동해서는 안 된다. SemiAnalysis는 실질적인 속도 한계에 도달하려면 아키텍처별 튜닝이 여전히 필요하다고 말한다.

Rubin은 Blackwell의 228 KiB에서 공유 메모리를 선택 가능한 328 KiB 모드로 늘렸다. Tensor Memory도 256 KiB로 확대돼 커널에 누산기와 스케일링 정보를 위한 더 많은 공간을 제공한다.

이 아키텍처는 inline Tensor Memory Accelerator descriptor 업데이트를 추가했다. TMA는 일반 실행 장치가 모든 전송을 직접 관리하지 않고도 다차원 데이터를 이동시키는 하드웨어 메커니즘이다.

Mixture-of-experts 레이어에서 각 전문가는 별도의 가중치 행렬을 가진다. Blackwell은 활성 전문가가 바뀔 때 descriptor를 다시 작성하고 동기화해야 할 수 있다.

Rubin은 전송 명령어와 함께 새 주소를 전달할 수 있다. 그러면 하나의 descriptor가 중간 메모리 재작성 없이 여러 전문가를 처리할 수 있다.

이는 저배치 decode 중 디스패치 오버헤드를 줄인다. 또한 실제 추론 성능 향상이 더 큰 행렬 엔진뿐 아니라 작은 데이터 이동 개선에서 나온다는 점을 보여준다.

NVIDIA의 아키텍처 공개 자료에 따르면 Rubin은 Blackwell과 비교해 FP8 및 FP4 Tensor Core 처리량을 두 배로 높였다. 또한 의존 관계에 있는 thread block 간 더 세밀한 동기화를 추가했다.

이 기능들은 개발자가 더 큰 융합 커널을 구축하는 데 도움을 준다. 융합은 여러 연산을 결합해 반복적인 실행 호출과 불필요한 메모리 이동을 줄인다.

소프트웨어 우위는 출시 준비 상태를 넘어선다. 호환 가능한 도구를 통해 더 많은 개발자가 Rubin의 동작을 검토하고, 결함을 보고하며, 일반적인 모델 아키텍처를 최적화할 수 있다.

그러나 공개 지원은 아직 초기 단계다. CUDA의 프리뷰 제한은 사용 가능한 코드가 곧 성숙한 프로덕션 스택을 의미하지는 않음을 보여준다.

PyTorch 및 vLLM 통합은 기능을 구현할 수 있지만, 상당한 최적화 작업은 여전히 남아 있을 수 있다. 운영자는 “Rubin에서 실행된다”와 “Rubin을 효율적으로 활용한다”를 구분해야 한다.

과거의 양상은 이런 신중함을 뒷받침한다. GB200 추론 성능은 커널, 스케줄러, 분산 서빙 레시피가 성숙하면서 첫해 동안 개선됐다.

Rubin은 더 강력한 호환성 기반에서 출발한다. 그러나 궁극적인 우위는 프레임워크 유지관리자들이 새 명령어를 신뢰할 수 있는 모델 수준의 성능 향상으로 전환하는지에 달려 있다.

3비트 LUT Tensor Core는 메모리 병목을 겨냥한다

Rubin의 가장 흥미로운 추론 기능은 Tensor Core 내부에서 가중치를 압축해, 별도의 역양자화 과정 없이 메모리 트래픽을 줄인다.

Rubin은 행렬 곱셈-누산 명령어에 룩업 테이블 B 피연산자 모드를 추가했다. SemiAnalysis는 이를 내부 비균일 코드북을 사용하는 NVIDIA 최초의 Tensor Core 형식으로 설명한다.

이 모드에서는 저장된 각 가중치가 3비트 인덱스가 된다. 이 인덱스는 가중치 블록 전체가 공유하는 룩업 테이블에서 8개의 8비트 E4M3 값 중 하나를 선택한다.

Tensor Core는 행렬 연산 내부에서 선택된 값을 재구성한다. 소프트웨어는 곱셈 전에 별도의 압축 해제 가중치 행렬을 만들 필요가 없다.

공유 코드북을 포함하면, SemiAnalysis는 저장 공간이 가중치당 3.125비트라고 계산한다. 코드북은 512개 가중치가 공유하는 64비트로 구성된다.

이 설계는 NVFP4 및 MXFP 형식과 다르다. 이 형식들은 블록 스케일링을 사용해 저정밀 값 그룹에 균일한 스케일을 적용한다.

룩업 테이블은 8개 값을 불균일하게 배치할 수 있다. 밀집된 가중치 군집 근처에 항목을 집중시키거나, 비대칭적인 양수 및 음수 분포를 표현할 수 있다.

이러한 유연성은 비슷한 비트 수에서 균일 반올림보다 더 많은 정보를 보존할 수 있다. 그렇다고 더 나은 모델 품질이 보장되는 것은 아니다.

하나의 코드북은 512개 가중치를 포괄하는 반면, NVFP4는 훨씬 작은 그룹별로 스케일을 조정할 수 있다. 결과는 캘리브레이션 데이터, 코드북 피팅, 모델 민감도에 따라 달라진다.

일부 레이어에는 더 높은 정밀도도 필요할 수 있다. 공격적인 양자화 레시피는 메모리를 절약할 수 있지만 추론 정확도를 떨어뜨리거나 출력의 안정성을 해칠 수 있다.

그럼에도 하드웨어 메커니즘은 핵심적인 추론 제약을 해결한다. 낮은 배치 디코딩 중에는 GPU가 모델 가중치가 HBM에서 도착하기를 기다리는 경우가 많다.

각 가중치의 저장 크기를 줄이면 메모리는 초당 더 많은 가중치를 전달할 수 있다. 또한 시스템 전체에서 해당 비트를 이동하는 데 드는 에너지도 줄어든다.

SemiAnalysis는 용량 효과를 설명하기 위해 가상의 2조8천억 파라미터 모델을 사용했다. 이 계산에서는 Rubin 형식의 원시 가중치 페이로드가 약 1.09테라바이트에 달했다.

이 비교는 KV 캐시, 활성화값, 복제, 서빙 오버헤드를 제외했다. 따라서 이는 전체 배포 메모리가 아니라 가중치 저장량을 보여준다.

Rubin GPU당 HBM4가 288기가바이트일 경우, 압축된 가중치에는 약 4개의 패키지가 필요하다. 예시의 다른 저정밀 표현 방식에는 약 6개가 필요했다.

참여 GPU 수가 줄면 통신과 복제를 줄일 수 있다. 더 긴 컨텍스트, 더 큰 배치 또는 KV 캐시에 더 많은 메모리를 남길 수도 있다.

하지만 LUT 모드에는 구현 제약이 있다. SemiAnalysis는 B 행렬을 전치할 수 없으며, 이 기능을 직접 사용할 수 있는 연산이 제한된다고 지적한다.

공개 벤치마크 역시 이 기능을 사용하지 않은 것으로 보인다. 따라서 Rubin의 초기 우위를 3비트 룩업 테이블 추론 덕분이라고 볼 수는 없다.

이는 고무적이면서도 불확실하다. Rubin에는 향후 소프트웨어가 활용할 수 있는 추가 실리콘 역량이 있지만, 정확도와 프로덕션 가치는 아직 검증되지 않았다.

NVIDIA는 런타임 2:4 활성화 희소성도 추가했다. 이 방식은 4개 값마다 2개를 유지하고, 지원되는 연산에서 나머지 2개를 건너뛴다.

기존 가중치 희소성과 달리, 런타임 활성화 희소성은 모델을 영구적으로 프루닝하고 재학습할 필요가 없다. 하드웨어가 모델 실행 중 중간값을 압축할 수 있다.

그러나 NVIDIA는 이후 연산 전에 선택된 활성화값의 절반을 버리는 방식에 대한 정확도 근거를 공개하지 않았다. CoreWeave 결과도 이 기능을 사용하지 않은 것으로 보인다.

이처럼 아직 사용되지 않은 기능들은 Rubin의 최적화 여지를 나타낸다. 이를 보장된 미래 성과로 간주해 현재 TCO 계산에 포함해서는 안 된다.

구매자는 처리량과 함께 모델 수준의 품질 테스트를 요구해야 한다. 낮은 비트 형식은 결과 모델이 동일한 정확도와 신뢰성 목표를 충족할 때만 서빙 비용을 낮춘다.

Rubin은 TCO 테스트에서 승리하지만, 기준선에 따라 격차가 달라진다

Rubin은 더 높은 소유 비용에도 불구하고 제공된 토큰당 비용이 더 저렴해 보이지만, 완전히 튜닝된 Blackwell 시스템과 비교하면 우위는 줄어든다.

총소유비용은 하드웨어, 전기, 시설, 네트워킹, 유지보수, 운영 비용을 결합한다. 이는 와트당 성능만 보는 것보다 더 폭넓은 관점을 제공한다.

SemiAnalysis는 정규화된 출력 처리량에 자사의 운영자 소유 비용 모델을 적용했다. 이 분석은 희소성, 계약 조건, 제공업체 마진이 포함될 수 있는 클라우드 임대 요금을 제외했다.

분석 결과, Rubin은 측정된 모든 상호작용 수준에서 2026년 7월 GB200 및 GB300 결과보다 출력 토큰당 비용이 더 낮았다. 응답 속도가 높아질수록 우위도 커졌다.

현재 GB200 기준선과 비교하면 Rubin은 사용자당 초당 100토큰까지 약 1.5배 더 저렴했다. 상대적 우위는 사용자당 초당 200~250토큰 부근에서 약 3배에 달했다.

Rubin을 2025년 GB200 소프트웨어 기준선과 비교하면 더 큰 결과가 나왔다. Rubin은 사용자당 초당 150토큰 부근에서 최대 약 8배 더 저렴했다.

이 오래된 기준선은 NVIDIA의 마케팅 헤드라인과 실질적인 구매 비교 사이의 격차 대부분을 설명한다. 튜닝된 2026년형 GB200은 초기 배포 상태보다 더 뛰어난 성능을 낸다.

SemiAnalysis는 또한 Rubin의 GPU당 소유 비용이 GB200 및 GB300보다 높다고 추정한다. 처리량 향상은 이 더 높은 시스템 부담을 상쇄해야 한다.

검토된 워크로드에서는, 특히 까다로운 상호작용 목표에서 이를 해낸다. Blackwell이 더 큰 배치를 효과적으로 활용할 수 있는 느린 응답 속도에서는 경제성이 덜 결정적이다.

이는 워크로드별 구매 결정을 만든다.

고도의 상호작용형 추론의 경우

• Rubin은 테스트된 구성에서 GB200이 도달할 수 없는 응답 속도를 유지한다.

• 배치 크기가 작아질수록 메모리 대역폭과 랙 패브릭의 가치가 커진다.

• 코딩 에이전트와 실시간 검색 서비스가 이 프로필에 부합한다.

처리량 중심 추론의 경우

• 성숙한 Blackwell 소프트웨어는 Rubin의 상대적 우위를 좁힐 수 있다.

• 기존 인프라와 예약된 용량은 이론적인 효율성 우위보다 더 큰 비중을 가질 수 있다.

• 마이그레이션 비용도 운영자의 TCO 모델에 포함할 필요가 있다.

장문 컨텍스트 모델의 경우

• Rubin의 더 큰 메모리 풀은 운영자에게 가중치와 KV 캐시를 위한 더 많은 공간을 제공한다.

• 초기 단일 턴 벤치마크는 이 우위를 직접 측정하지 않는다.

• 멀티턴 에이전트 테스트가 더 대표적인 신호를 제공할 것이다.

벤치마크는 8,000토큰 입력과 1,000토큰 출력을 갖는 DeepSeek R1 671B를 사용했다. 이 모델과 시퀀스 형태가 모든 2026년 프로덕션 워크로드를 대표하지는 않는다.

SemiAnalysis는 더 새로운 수조 파라미터 모델이 Rubin의 용량과 대역폭에 유리할 것이라고 주장한다. 이 주장은 비교 결과가 나올 때까지 기술적 기대에 머문다.

CoreWeave는 스케일아웃 패브릭이 없는 Dell 엔지니어링 샘플 랙에서도 테스트를 수행했다. 스케일아웃은 여러 랙을 연결하는 반면, 내부 NVLink 백플레인은 스케일업 연결을 제공한다.

성공적인 테스트는 랙 내부의 전문가 병렬 연산을 뒷받침한다. 하지만 대규모 멀티랙 배포 전반의 성능, 신뢰성 또는 효율성을 입증하지는 않는다.

경쟁도 또 다른 제약을 더한다. AMD의 MI455X는 가속기당 432기가바이트의 HBM4를 제공하며, Rubin은 288기가바이트다.

72개 가속기 기준으로 AMD의 Helios 설계는 31.1테라바이트의 메모리를 제공한다. Rubin은 NVL72 랙 전체에서 20.7테라바이트를 제공한다.

AMD의 용량 우위는 대형 모델과 장문 컨텍스트에서 중요할 수 있다. NVIDIA는 확립된 소프트웨어 생태계, NVLink 패브릭, 더 이른 랙 규모 운영 경험으로 대응한다.

Google의 TPU 시스템은 또 다른 통합 경로를 제공한다. 하나의 운영자 아래 맞춤형 가속기, 인터커넥트, 컴파일러, 클라우드 서비스를 결합한다.

따라서 TCO 경쟁은 Rubin과 GB200에만 국한되지 않는다. 구매자는 동일한 모델, 정확도 목표, 지연 시간, 컨텍스트 길이, 전력 산정을 기준으로 전체 서빙 레시피를 비교해야 한다.

Rubin은 현재 가장 강력한 초기 공개 결과를 보유하고 있다. 하지만 이 증거만으로는 프로덕션 추론 전반에 적용되는 하나의 고정 비용 비율을 확립할 수 없다.

다음 벤치마크가 입증해야 할 것

세 가지 신호가 Rubin의 초기 엔지니어링 성과가 지속적인 프로덕션 우위가 될지를 결정할 것이다.

첫 번째 신호는 NVIDIA가 약속한 2026년 3분기 InferenceX 제출이다. SemiAnalysis는 NVIDIA가 해당 벤치마크를 통해 독립적으로 검증 가능한 Rubin 수치를 제공하기로 약속했다고 말한다.

신뢰할 수 있는 제출은 문서화된 서빙 구성에서 최신 모델을 테스트해야 한다. 상호작용성, 출력 처리량, 전력 경계, 최적화 설정을 함께 보고해야 한다.

2026년 7월 GB200 및 GB300 시스템과의 결과는 현재 비교를 강화할 것이다. 오래된 GB200 기준선을 반복하면 핵심 방법론적 우려는 해소되지 않는다.

두 번째 신호는 멀티턴 에이전트 워크로드다. 단일 턴 추론은 에이전트 세션 전반에서 반복되는 도구 호출, 증가하는 KV 캐시, 변화하는 프롬프트 길이를 재현할 수 없다.

SemiAnalysis는 인프라 및 오픈소스 서빙 기여자들과 함께 AgentX 시나리오를 개발하고 있다. 해당 Rubin 분석은 장문 컨텍스트 에이전트 작업을 유력한 아키텍처 강점으로 지목한다.

메모리 용량과 대역폭이 지배적인 경우 Rubin은 우위를 더 넓힐 것으로 예상된다. 우위가 변하지 않거나 축소된다면, 이 랙의 장문 컨텍스트 사례는 설득력이 약해진다.

세 번째 신호는 성숙한 공개 소프트웨어다. 개발자는 CUDA, PyTorch, vLLM, Triton, TensorRT-LLM, Dynamo 전반의 프로덕션 릴리스를 주시해야 한다.

기능적 호환성은 최적화된 성능보다 먼저 도래할 것이다. 결정적인 증거는 Rubin 특유의 메모리 이동, 동기화, 저정밀 기능을 활용하는 안정적인 커널에서 나올 것이다.

3비트 LUT 추론은 특히 면밀히 검토할 필요가 있다. 공개 테스트는 NVFP4 대비 정확도, 캘리브레이션 방법, 영향을 받는 레이어, 엔드투엔드 처리량을 보고해야 한다.

활성화 희소성도 같은 수준의 검증이 필요하다. 품질 저하 때문에 운영자가 더 큰 모델을 사용하거나 실패한 요청을 다시 처리해야 한다면, 높은 산술 처리율은 큰 의미가 없다.

Feynman은 더 장기적인 소프트웨어 문제도 제기한다. NVIDIA는 다음 아키텍처를 SM140으로 명시했으며, Rubin은 SM107을 사용한다.

SemiAnalysis는 Feynman에 더 광범위한 커널 재작성이 필요할 것으로 예상하며, 이는 어려웠던 Hopper에서 Blackwell로의 전환과 유사하다. 따라서 Rubin의 호환성 우위는 한 세대만 지속될 수도 있다.

인프라 구매자에게 당장의 결정은 Rubin의 사양이 더 나은지 여부가 아니다. 더 낫다.

더 어려운 질문은 특정 워크로드가 배포 변경을 정당화할 만큼 충분한 이점을 얻는지다. 운영자에게는 자신의 모델, 컨텍스트 분포, 응답 목표, 기존 전력 용량을 기반으로 한 테스트가 필요하다.

개발자에게 유용한 조치는 지금 커널 지원과 벤치마크 레시피를 추적하는 것이다. 초기 프로파일링은 애플리케이션이 연산, HBM 트래픽, 네트워킹 또는 스케줄링 중 무엇에 의해 제한되는지 드러낼 수 있다.

AI 제품 팀은 사용자 수준의 결과를 주시해야 합니다. 더 빠른 토큰은 작업 완료 시간을 줄이고, 에이전트 신뢰성을 높이거나, 더 많은 동시 고객을 지원할 때에만 의미가 있습니다.

OpenAI SemiAnalysis 스레드는 결국 세 가지 계층을 연결합니다. 오픈 커널 도구, 독립적인 성능 분석, 그리고 NVIDIA의 랙 규모 하드웨어입니다. 이 계층들 중 어느 하나도 Rubin만으로는 검증할 수 없습니다.

Rubin은 최신 모델, 멀티턴 에이전트, 그리고 독립적으로 재현 가능한 테스트에서 우위를 유지할 수 있을까요? 하나의 헤드라인 수치가 아니라 이러한 증거가 다음 추론 인프라 투자 결정을 내려야 합니다.