시리즈 안내 ⎯ Series Map Part 1: 플랫폼 개요와 아키텍처 맵 — Blackwell → Rubin 플랫폼의 핵심과 주요 사양 Part 2: Rubin GPU 엔지니어링 심층 분석 — process node, SM, HBM4, NVLink-C2C, 패키지, CPX와 Groq 3 LPX Part 3: Vera CPU와 네트워킹 실리콘 제품군 — Vera CPU, NVLink 6 Switch, ConnectX-9, BlueField-4, Spectrum-6 Part 4: 랙 조립 — 트레이, PCB, 쿨링 — HGX와 NVL72, 컴퓨트 트레이 모듈, cableless 미드플레인, PCB 업그레이드, 액체 냉각 Part 5: 랙 전력과 네트워킹 fabric — 전력 공급, HVDC, tray ↔ rack 배선, scale-up NVLink 6, scale-out InfiniBand와 Ethernet Part 6 (현재 글): 공급망 마스터 레퍼런스 — sub-system별 공급사 정리 ⚠️ 확정적인 공급사 목록이 아니라, 정보를 토대로 한 추정. 이 파트는 공개적으로 접근 가능한 리서치와 institutional 데이터 — sell-side 애널리스트 노트, 공급사 실적 발표, OCP / GTC 공시, 한국·대만 산업 리포트, 주요 기업 공시 — 를 한데 모아 정리한 educated guess다. Vera Rubin 플랫폼 전반의 벤더 관계, 점유율 분할, 매출 배분은 대부분 NDA로 제한된다. 따라서 아래 내용은 권위 있는 출처가 아니라 방향성 레퍼런스로 받아들이는 편이 안전하다 — 수치와 공급사 매핑에는 빠진 부분, 오기, 잘못된 추정이 섞여 있을 수 있고, 전체적인 산업의 흐름 자체도 빠르게 움직이고 있다. 📝 범위 — 부품 제조사로 한정. 이 파트가 다루는 대상은 Vera Rubin 플랫폼 안에 들어가는 부품을 만드는 공급사다 — 실리콘 파운드리, 메모리, PCB / CCL, copper foil, 액체 냉각, 전력 공급, NVLink optic, scale-out 네트워킹, 시스템 어셈블리 파트너 등이 여기에 해당한다. 완성된 시스템을 재판매용으로 조립하는 서버 시장 OEM / ODM (Dell, HPE, Lenovo, Supermicro 류)은 범위 밖이며, 이 파트에서는 다루지 않는다. 공급사를 sub-system별로 가로질러 보는 시각이다. 엔지니어링 맥락은 Part 2 / Part 3 (칩) 그리고 Part 4 / Part 5 (tray-to-rack 어셈블리 + 전력 + 네트워킹 fabric)를 함께 보면 좋다. Sub-System Index Silicon — Logic & Memory Substrate, PCB & CCL Liquid Cooling Rack-Level Power Delivery NVLink 6 — Scale-Up Interconnect PCIe 6.0 / Internal Interconnect Quantum-X800 — InfiniBand Scale-Out Spectrum-X — Ethernet Scale-Out System Integration & Assembly Cross-Subsystem Heatmap 1. Silicon — Logic & Memory Vera Rubin은 7개의 서로 다른 실리콘 제품으로 출하된다 — Nvidia 자체 설계 칩 6개 (Rubin GPU, Vera CPU, NVLink 6 Switch, ConnectX-9, BlueField-4, Spectrum-6) + 새로 라이선스 된 Groq 3 LPU. Groq 3 LPU (코드네임 LP30)는 Groq 3 LPX 랙 안에 들어간다 — 2026년 3월 체결, ~USD 20B. 모든 칩은 외부 파운드리에서 제조된다. 메모리는 별도의 DRAM 생태계에서 공급된다 — GPU용 HBM4, CPU용 LPDDR5X, switch host용 DDR5, Groq용 on-chip SRAM. → naming 규칙: LPU는 Groq 칩 한 개 (Groq 3 LPU = LP30)를 가리키고, LPX는 32 tray에 걸쳐 256개의 LPU를 담는 통합 랙 시스템을 뜻한다. 이 파트 전반에서 두 용어는 서로 바꿔 쓸 수 없다. Chip 아키텍처 & ISA 계보 플랫폼은 세 가지 ISA 패밀리 — Nvidia GPU, ARM (두 종류), x86 — 와 Groq의 TSP, 그리고 표준 ARM 기반 BMC까지 랙 한 대 안에 포함된다. 랙 안에 Nvidia ARM CPU 두 종이 들어간다 — Vera (새로 도입된 Olympus core, TSMC N3P)와 BlueField-4 (Grace die를 재활용했다). AMD x86 CPU — Spectrum-X switch host로 쓰인다. switch 관리에 있어 업계가 기본으로 가져가는 선택이다. 삼성에서 만드는 Groq TSP — 오늘날 플랫폼에서 유일한 non-TSMC 실리콘이다 (LP30 / LP35는 SF4X). Feynman 세대의 차세대 LP40에서는 TSMC N3P로 옮겨 간다. Rubin CPX는 로드맵에서 빠졌다 (GTC 2026). 해당 prefill / decode 워크로드는 이제 Groq 3 LPX Rack이 떠맡는다. AST2600 (ARM Cortex-A35) — 모든 레퍼런스 SMM 위에 올라가는 BMC. 사실상 업계 표준이다. Chip별 메모리 칩별 메모리 매핑 — 어떤 종류의 메모리가, 몇 개씩, 어디에서 들어오는지를 정리한다. HBM4가 플랫폼에서 가장 비싼 메모리이다 — 288 GB × 72 GPU × 18 tray = VR NVL72 랙당 ~20.7 TB HBM4. LPDDR5X는 플랫폼 내부 구성 수량이 가장 많다 — 랙 수준에서 Vera CPU와 BlueField-4 DPU를 합치면 3.4 TB LPDDR5X에 이른다. Rubin은 2027년에 6B GB 이상의 LPDDR을 소비할 것으로 추정된다 (Apple iPhone과 삼성 스마트폰의 합산 소비량을 넘는다). Groq의 SRAM-only 설계는 플랫폼에서 가장 큰 메모리 경제학적 분기점이다 — HBM 대역폭을 on-die SRAM (랙당 합쳐서 40 PB/s)으로 대체하고, 외부 DRAM은 아예 쓰지 않는다. 원래 Rubin CPX가 떠맡으려 했던 decode phase를 정조준한다. SOCAMM2 vs LPCAMM2 — SOCAMM2는 Nvidia가 독점적으로 정의한 서버용 사양, LPCAMM2는 JEDEC의 client/laptop 사양이다. Vera CPU는 Micron의 256 GB "2 TB / CPU" 경로에서도 SOCAMM2만 사용한다. 세 벤더 (하이닉스 / Micron / 삼성) 모두가 Vera Rubin용 SOCAMM2를 공급한다. Logic 파운드리 용량 현실. 진짜 병목은 logic 공정 wafer가 아니라 CoWoS-L 고급 패키징이다. Jensen Huang의 발언을 인용하자면: Nvidia는 "Vera Rubin의 전 생애 주기 동안 supply constrained 상태일 것이다". Node 로드맵 Nvidia는 N2를 건너뛰고 Feynman을 A16 (backside power, 2027 양산)에 맞춰 두었다. Apple (AAPL)은 A20 / M5용으로 TSMC 2026년 N2 capacity의 50% 이상을 이미 챙겨 둔 상태다. HBM4 메모리 (Rubin GPU용) 양산 단계의 현실: 초기 Rubin 출하분은 22 TB/s 헤드라인이 아니라 ~20 TB/s 수준에 머물 것으로 보인다. 세 벤더의 2026년 HBM capacity는 hyperscaler·Nvidia와 묶은 다년 Strategic Customer Agreement로 이미 전부 매진된 상태이고, 2026년의 상당 부분에 대한 가격도 2025년 말에 미리 정해졌다. LPDDR5X (Vera CPU용 — SOCAMM 모듈) Micron이 Vera의 LPDDR5X 중 ~30%를 가져갔고, 나머지는 삼성과 SK하이닉스가 나눠 가진다. 눈에 띄는 지점은 Micron이 HBM4에서는 사실상 제외되었지만, LPDDR에서는 의미 있는 점유율을 챙겼다는 사실 — LPDDR은 HBM과는 별개로 분류되기 때문이다. 수요 쪽 규모: Rubin은 2027년에 6B GB 이상의 LPDDR 메모리를 소비할 것으로 전망되며 — Apple iPhone과 삼성 스마트폰의 LPDDR 소비를 합친 양보다도 많다. SOCAMM2 소켓 공급사 — Lotes (3533.TW): Vera Rubin용 SOCAMM2 소켓 공급사로 확정. tray당 소요량: Vera CPU 1개당 SOCAMM2 모듈 8개 × CPU 16개 = NVL72 compute tray당 SOCAMM2 모듈 128개. 플랫폼 전체 SOCAMM2 소켓 수요는 8.7M개로 추정. 2027년 Lotes 공급 예상 ~1.6M개 — Foxconn / Quanta / Wistron / Inventec ODM 채널을 통해. 2025 full-year 매출은 AI 서버 connector 수요로 USD 1B를 돌파. 경쟁사 — Amphenol, TE Connectivity, Molex, FIT, BizLink. TSMC CoWoS-L 용량 할당 Rubin GPU는 TSMC의 9.5-reticle CoWoS-L 패키지를 쓴다. COUPE는 2027년부터 HBM4/4E 12개 통합을 받쳐 준다. 애널리스트 출하 전망: 2026년 Rubin 80만 대 → 2027년 320만 대, ASP ~USD 32K 기준 — 2027년 플랫폼 매출은 ~USD 102B 수준에 닿는다. 대안 플랫폼 구성 — HGX/DGX Rubin NVL8 & Vera CPU Rack 이 파트의 본문은 VR NVL72를 기준으로 쓰여 있지만, 추가적으로 설계된 두 가지 종류의 구성이 실리콘 공급사 폭을 넓혀 준다 — 가장 큰 변화는 x86 host 경로를 통해 Intel이 Rubin 플랫폼 안으로 들어온다는 점이다. (1) HGX/DGX Rubin NVL8 — x86 host 경로. 8-GPU 서버 레퍼런스 (vs 72-GPU NVL72 랙). Host CPU: Intel (INTC) Xeon 6 (6700P-Series) — 시스템당 2개 탑재. Host 메모리: DDR5-6400 RDIMM 32개, 최대 4 TB. GPU + HBM: NVL72와 동일 — Rubin GPU 8개, HBM4는 동일한 3-공급사 풀에서 공급 (SK하이닉스 선두, 삼성, Micron). 네트워킹 + 스토리지: ConnectX-9, BlueField-4, Micron (MU) PCIe Gen 6 E1.S 모두 그대로 이어진다. 왜 x86인가 / 왜 Intel인가? 소프트웨어 incumbency. AI 프레임워크, 오케스트레이션 스택, 레거시 enterprise 소프트웨어를 ARM (Vera 경로) 위로 옮겨 심으려면 여전히 적지 않은 시간과 노력이 든다. 반면 x86 스택은 당장 오늘부터 출하할 수 있는 상태다. Brownfield 고객 베이스. Enterprise 데이터센터, telco 인프라, hyperscaler의 레거시 컴퓨트 풀, 전통적인 HPC 고객들은 배포 안정성·OEM 검증·잘 익은 ecosystem·예측 가능한 리드타임을 이유로 Xeon 6를 선호한다. AMD scarcity at the edge. AMD EPYC는 x86 영역에서 기술적으로 어깨를 나란히 하는 옵션이지만, high-core SKU의 대부분이 hyperscaler 내부 할당에 묶인다 — 그래서 enterprise 규모에서 손에 잡히는 기본 x86 SKU는 Intel이 된다. CPU:GPU 비율의 변화. Inference와 agentic AI가 비율을 1:8에서 1:1 쪽으로 끌고 가는 흐름 속에서, x86 incumbency의 가치는 오히려 더 올라간다 — 특히 GPU 옆에 붙어 일하는 orchestration·control-plane CPU 영역에서 그렇다. (2) Vera CPU Rack — standalone. 최대 Vera CPU 256개로 구성되는 별도 랙. 메모리: SOCAMM2 전용 — LPCAMM2는 어떤 Nvidia 시스템에서도 쓰이지 않는다. 공급사 매핑은 NVL72 Vera 소켓 (§ 1 Chip별 메모리)과 같다 — SK하이닉스 192 GB (MP 2026년 4월), Micron 192 GB (MP 2026년 3월, 256 GB 샘플 경로로 2 TB / CPU까지 닿는다), 삼성 (2025년 샘플 → 2026년 초 MP). 확정 고객: Oracle (ORCL), CoreWeave (CRWV), Nebius (NBIS), Alibaba (BABA) — 이미 x86 아키텍쳐에 의존하지 않는 greenfield AI-native 진영. 옆에 놓이는 랙: Groq 3 LPX 랙은 일부...

시리즈 안내 ⎯ Series Map Part 1: 플랫폼 개요와 아키텍처 맵 — Blackwell → Rubin 플랫폼의 핵심과 주요 사양 Part 2: Rubin GPU 엔지니어링 심층 분석 — process node, SM, HBM4, NVLink-C2C, 패키지, CPX와 Groq 3 LPX Part 3: Vera CPU와 네트워킹 실리콘 제품군 — Vera CPU, NVLink 6 Switch, ConnectX-9, BlueField-4, Spectrum-6 Part 4: 랙 조립 — 트레이, PCB, 쿨링 — HGX와 NVL72, 컴퓨트 트레이 모듈, cableless 미드플레인, PCB 업그레이드, 액체 냉각 Part 5 (현재 글): 랙 전력과 네트워킹 fabric — 전력 공급, HVDC, tray ↔ rack 배선, scale-up NVLink 6, scale-out InfiniBand와 Ethernet Part 6: 공급망 마스터 레퍼런스 — sub-system별 공급사 정리 Part 4에서 이어진다. 동일한 NVL72 랙을, 이제는 전력 공급에서 시작해 네트워킹 fabric 이후까지 살펴본다. (8) 전력 공급 — AC 전원에서 칩까지의 사슬 랙당 TDP: 180~220 kW (GB200/GB300은 120~140 kW). 전력 공급 과정은 세 단계로 나뉜다. Step 1: AC 전원 → 50 V DC (rack power shelf) 랙 상단과 하단에 3~4개의 power shelf가 자리하며, 각각 110 kW를 담당한다 (N+1 redundancy 구성으로 220 kW 피크 부하에 대해 330 kW까지 공급 가능). 각 shelf는 3U 높이로, 내장 capacitor를 갖춘 18.3 kW PSU를 6개 탑재한다. Input: 두 가닥의 100A whip을 통한 3상 415~480 VAC. Output: 5,000 A 이상 정격의 liquid-cooled busbar로 공급되는 50 VDC (GB200은 2,900 A 수준이었다). 왜 liquid-cooled인가? 이 정도 전류 수준에서는 busbar 자체도 꽤 많은 열을 내뿜는데, 랙 안에는 그 열을 식혀 줄 fan이 따로 없기 때문이다. Step 2: 50 V busbar → compute tray (다이어그램의 노란 점선 경로) tray는 후면에서 rack busbar에 끼워 맞춰진다. 내부 busbar 케이블이 50 V를 두 갈래로 나눠 보낸다. Strata Module (50 V를 직접 받는다 — 전류가 너무 커서 중앙 집중식 12 V rail로는 효율이 떨어지므로, Strata가 보드 위에서 직접 강압한다). 전면의 Power Delivery Module (전면의 작은 module들을 위해 50 V → 12 V 변환을 한 곳에서 처리한다). Step 3: 50 V → 12 V → 1 V (각 보드 위에서) Strata board는 50 V → 12 V용 자체 IBC (Intermediate Bus Converter)와 12 V → ~1 V용 VRM을 갖추고 GPU/CPU die에 직접 전원을 공급한다. PDB는 Orchid·BF-4·Mgmt module을 위한 50 V → 12 V 변환을 맡으며, 짧은 내부 busbar를 통해 해당 module들로 12 V를 나눠 보낸다. 왜 tray에 12 V가 아니라 50 V를 보내는가 wire 위의 전력 손실은 전압이 아니라 전류의 제곱에 비례 (I²R) 한다. 50 V에서 4,800 W를 공급한다면 96 A로 충분하지만, 12 V로 공급하려면 400 A가 필요해진다. 즉, 강압을 늦추고 더 높은 전압을 칩 근처까지 끌고 가면, 그 구간의 전력 손실이 17배 줄어든다. Vera와 Rubin 사이의 "Power Sloshing" GB300에서 이어 온 기능 — Strata 보드의 4,800 W 전력 예산을 Rubin GPU 2개와 Vera CPU 1개가 동적으로 나눠 쓴다. GPU-heavy 부하에서는 각 Rubin이 2,300 W까지 끌어다 쓸 수 있고 (그러면 Vera에는 200 W가 남는다), GPU가 idle이거나 derate 되면 그 여유분을 Vera가 받아 가져갈 수 있다. 양쪽이 동시에 worst-case로 돌아가는 상황을 대비해 전원을 과하게 잡아 둘 필요가 없다는 뜻이다. (9) 랙 단위 전력 — HVDC, BBU/CBU, Hyperscaler 변형들 랙 수준의 레퍼런스 설계 (3U 110 kW power shelf 4개 → 50 V liquid-cooled busbar)는 § 8 Step 1에서 다뤘다. 이 섹션은 hyperscaler가 해당 레퍼런스에서 벗어나면서 시도하는 변형들을 살펴본다 — 랙당 TDP가 이미 180~220 kW에 다다랐고, 다음 한두 세대 안에 랙당 1 MW를 향해 올라간다는 흐름이 이를 끌고 가는 동력이다. 이탈 양상은 크게 두 갈래로 나뉜다: 더 높은 전압으로의 분배 — HVDC power rack이 GPU rack 안쪽의 50 V step-down shelf에 공급하는 구조. 에너지 저장의 통합 — peak shaving과 grid bridging을 위해 BBU + CBU shelf를 옆 rack으로 옮긴 구조. 1) Option A — HVDC (High-Voltage DC) Power Rack 일부 hyperscaler는 별도의 power rack을 훨씬 더 높은 DC 전압에서 운영하고, 이를 수평으로 GPU rack에 공급한다. 통용되는 전압 표준은 두 가지다. 800 VDC — Nvidia 사양. ±400 VDC — OCP (Open Compute Project) 사양. HVDC 공급의 동작 방식 AC 전원 → power rack에서 800 VDC (또는 ±400 VDC)로 변환한 뒤, 두꺼운 도체를 통해 분배. 수평 800 VDC busbar (또는 케이블)가 인접한 GPU rack들과 power rack을 연결. GPU rack 내부에서는 DC-DC step-down shelf가 800 VDC → 50 VDC로 변환해 표준 rack busbar에 공급. 그 이후의 공급 경로는 AC 레퍼런스 설계 (§ 8)와 동일하다. HVDC가 의미 있는 이유 power rack과 compute rack 사이의 긴 수평 구간에서 I²R 손실이 낮다 (tray 안에서 12 V 대신 50 V를 정당화했던 I²R 논리를 더 큰 스케일에 그대로 가져온 셈이다). Standalone power rack은 전력 인프라를 compute rack에서 떼어낸다 — 업그레이드와 교체가 수월하고, 여러 compute rack이 함께 쓰기에도 적합하다. AC → HVDC 변환 단계에서 Solid-State Transformer (SST) 를 끼워 넣을 수 있게 된다 — 랙 단위 전력 관리의 알갱이가 한층 더 잘게 쪼개진다. 다만 이를 받쳐 줄 공급망은 아직 자리 잡는 중이다. 2) Option B — Meta의 "High Power Rack" (BBU + CBU + Switching) OCP 2025에 공개된 Meta의 변형은 추가 전력 인프라를 compute rack 자체가 아니라 옆에 둔 rack에 합쳐 넣는다. 그 보조 rack에는 다음이 담긴다: BBU (Battery Backup Unit) — grid 흔들림이나 짧은 정전 상황을 버티기 위한 단기 배터리 백업. CBU (Capacitor Backup Unit) — peak shaving을 맡는 sub-second 단위의 capacitor bank (AI 워크로드의 transient 전력 스파이크를 grid에 부담을 주지 않고 받아낸다). Network switching — serviceability와 밀도를 위해 같은 보조 rack에 co-located. 왜 별도의 rack인가? BBU와 CBU shelf는 부피가 너무 커서 GPU rack에 함께 담기 어렵다. 옆 rack으로 옮겨 두면, GPU rack 혼자서는 감당할 수 없는 규모의 에너지 저장 용량을 Meta가 마련할 수 있다. GPU rack과 high-power rack은 수평 50 V busbar를 통해 이어진다. 3) 이 규모에서 에너지 저장이 중요한 이유 AI training은 많은 GPU가 같은 연산 단계를 동시에 반복하기 때문에, 전력 수요가 완만하게 증가하는 것이 아니라 짧은 순간에 동시다발적으로 급증하는 특성을 가진다 — forward-pass / backward-pass 단계에서 클러스터 안의 모든 GPU가 한꺼번에 ramping 되기 때문이다. 랙 합산 kW 수준에서, 이런 transient는 utility grid에 부담을 주고 보호 회로를 작동시킬 수 있다. CBU peak-shaving은 sub-second 단위의 스파이크를 로컬 랙 단위에서 완화시키고, BBU bridging은 더 긴 이벤트 동안 워크로드를 떨어뜨리지 않은 채로 버텨 낸다. 두 장치가 함께 맞물려 돌아가면서, AI 워크로드가 grid 안정성 문제로 번지는 일을 막아 준다. 4) 공급사 지형 랙 단위 전력 생태계 — AC/DC 변환, 50 V vs 800 VDC 분배, BBU/CBU 통합, liquid-cooled busbar, SST 로드맵, 그리고 벤더별 상업 조건·타임라인 (Lite-On, Delta, Flex, Vertiv, Eaton, Advanced Energy, Hitachi Energy, GE Vernova, TE Connectivity, Amphenol) — 은 Part 6 § 4 (Rack-Level Power Delivery)에 통합 정리되어 있다. 대부분의 비-hyperscaler 구매자에게는 표준 110 kW power-shelf 4개로 구성된 레퍼런스 설계가 그대로 출하된다. HVDC와 BBU/CBU rack 아키텍처는 사실상 hyperscaler 커스터마이즈 영역에 해당한다. (10) Tray → Rack — Tray가 어떻게 VR NVL72 랙을 구성하나 이 섹션은 bottom-up으로 풀어 간다 — 먼저 compute tray 한 대 안의 모든 internal lane을 짚어 본 뒤, 그 tray들이 랙 중앙의 NVLink switch tray와 어떻게 이어져 하나의 72-GPU 가속기로 묶이는지를 살펴본다. 1) Rack 수준 개요 랙은 18 compute tray + 9 NVLink switch tray + 4 power shelf를 19인치 캐비닛 한 대 안에 쌓아 올린다. 각 compute tray는 랙 후면의 NVLink backplane에 슬롯에 삽입된다. NVLink backplane은 compute-tray midplane과는 별개의 물리 계층이다 — passive copper backplane으로, 각 Strata module에서 NVLink Switch Tray로 NVLink 6 신호를 나른다. 9개의 switch tray (각각 칩 4개 = 합쳐서 36개의 NVLink 6 switch 칩)가 랙 중앙에 자리잡아, 모든 GPU가 다른 모든 GPU와 full all-to-all 토폴로지로 이어지도록 한다. 50 V liquid-cooled busbar가 랙 한쪽 면을 따라 수직으로 지나가며 모든 tray에 전원을 공급한다. 4개의 power shelf — 랙 상단 (U41~44)에 2개, 랙 하단 (U4~9)에 2개 — 가 위·아래 양쪽에서 그 busbar에 전원을 공급한다. 2) 단일 Compute Tray 내부 (1U · Vera CPU 2개 + Rubin GPU 4개) 한 compute tray 내부의 네트워크 lane 배선. Strata module부터 바깥 방향으로 읽는다. 단일 Strata Module 내부 — Rubin GPU ↔ Vera CPU ↔ Rubin GPU 각 Strata module은 Vera CPU 1개 + Rubin GPU 2개를 담는다. 각 Rubin은 두 개의 병렬 경로로 Vera와 이어진다. NVLink-C2C (coherent path): GPU↔CPU 쌍당 NVLink 6 C2C lane 1개 — 1.8 TB/s 속도로 coherent 메모리 트래픽을 전송한다. PCIe path: GPU↔CPU 쌍당 PCIe Gen6 lane 1개 — 관리 / secondary I/O 용도. Strata module당 GPU↔CPU 2쌍이 있다 (각 Rubin GPU에 하나씩). 두 Strata Module 사이 — Vera CPU ↔ Vera CPU 두 Vera CPU (Strata당 하나)는 tray가 하나의 coherent compute가 가능하도록 연결되어 있다. Vera ↔ Vera: NV-CLink lane 8개. Rubin GPU ↔ NVLink Switch Tray (rack-scale 경로) 각 Rubin GPU는 tray 밖, rack 단위 NVLink fabric에 직접 이어진다. Rubin GPU ↔ NVSwitch: 랙 후면의 NVLink backplane을 따라가는 NVLink 6 GPU-to-GPU lane. 이것이 all-to-all rack-scale 경로다 — 전체 토폴로지는 § 11에서 다룬다. Vera CPU ↔ Orchid Module (scale-out 네트워킹 + 로컬 스토리지) 각 tray에 4개의 Orchid module이 있고, 각각 2개씩의 ConnectX-9 (CX-9) NIC를 담는다. Orchid module당: Vera ↔ CX-9: CX-9당 16개의 PCIe Gen6 lane (module 위 두 CX-9 합쳐 32개). CX-9 ↔ CX-9 (peer link): 동일 Orchid 위 두 CX-9 사이의 1개의 PCIe Gen5 lane. 왼쪽 CX-9 ↔ E1.S NVMe SSD 슬롯: 4개의 PCIe Gen6 lane. CX-9 ↔ 1.6T OSFP cage (scale-out 네트워크): CX-9당 4개의 200G Ethernet/InfiniBand lane (Orchid당 총 8개). 단일 Orchid module의 lane 합계. 36개의 PCIe Gen6 lane (CX-9 두 개에 32개 + E1.S SSD에 4개) 1개의 PCIe Gen5 lane (CX-9 peer link) 8개의 200G Ethernet / InfiniBand lane (전면 패널 scale-out) Vera CPU ↔ BlueField-4 Module (frontend 인프라 plane) BF-4 module은 Vera CPU에서 출발하는 세 번째 주요 목적지다. BF-4를 드나드는 연결. Vera ↔ BF-4: Vera당 8개의 PCIe Gen6 lane (총 16개 — Strata당 Vera 1개 × Strata 2개). CX-9 (각 Orchid의 우측) ↔ BF-4: CX-9당 1개의 PCIe Gen5 lane (tray의 4개 Orchid 합쳐 총 4개). BF-4 ↔ Frontend Network 포트: 2개의 400G Ethernet/InfiniBand lane. BF-4 module의 lane 합계. 16개의 PCIe Gen6 lane (두 Vera로부터) 4개의 PCIe Gen5 lane (4개의 Orchid의 우측 CX-9로부터) 2개의 400G Ethernet / InfiniBand lane (frontend 네트워크) 단일 VR NVL72 Compute Tray — Module과 Lane 요약 Tray당 module: Tray당 lane 수 (모든 module 합산). Tray당 전면 패널 외부 연결: 1.6T OSFP cage 8개 (scale-out) + frontend 포트 1개 (BF-4 400G lane 2개) + BMC/management 1개. 3) NVLink Switch Tray — Compute Tray가 만나는 곳 Compute tray는 NVLink 6 copper backplane을 거쳐 랙 중앙의 NVLink switch tray에 이어진다. 각 switch tray는 PCB 한 장 위에 NVLink 6 Switch 칩 4개를 올려 둔다. Switch Tray 내부 NVLink 6 Switch 보드는 liquid-cooled 방식으로, 단일 cold-plate module이 보드 전체를 덮는다. tray는 자체 CPU를 가진 System Management Module (SMM) 을 함께 호스팅하며, SMM이 switch tray의 host 역할을 맡는다. SMM과 switch tray 사이의 연결은 flyover 케이블을 사용한다 — VR NVL72 시스템 전체를 통틀어 유일한 flyover 케이블 연결이다. 이 예외가 허용되는 이유는 (a) SMM으로 가는 PCIe link가 저속이고, (b) switch tray가 담는 module 수가 비교적 적어, 다른 부분을 cableless로 몰아붙이게 만들었던 조립 실패 패턴이 여기서는 재현되지 않기 때문이다. Backplane Lane 구조 다이어그램의 각 초록색 선은 400G NVLink 6 포트 9개, 즉 200G 기준 TX/RX lane 18개를 뜻한다. NVLink 6는 bidirectional SerDes를 채택하므로, lane당 1 differential pair (DP) — 어떤 connector와 어떤 switch 사이라도 18 DP, connector 전체로는 72 DP가 된다. connector당 케이블 수는 이전 세대인 NVLink 5 Switch Tray와 같다 — 대역폭 2배 증가는 구리가 늘어서 나온 ...

시리즈 안내 ⎯ Series Map Part 1: 플랫폼 개요와 아키텍처 맵 — Blackwell → Rubin 플랫폼의 핵심과 주요 사양 Part 2: Rubin GPU 엔지니어링 심층 분석 — process node, SM, HBM4, NVLink-C2C, 패키지, CPX와 Groq 3 LPX Part 3: Vera CPU와 네트워킹 실리콘 제품군 — Vera CPU, NVLink 6 Switch, ConnectX-9, BlueField-4, Spectrum-6 Part 4 (현재 글): 랙 조립 — 트레이, PCB, 쿨링 — HGX와 NVL72, 컴퓨트 트레이 모듈, cableless 미드플레인, PCB 업그레이드, 액체 냉각 Part 5: 랙 전력과 네트워킹 fabric — 전력 공급, HVDC, tray ↔ rack 배선, scale-up NVLink 6, scale-out InfiniBand와 Ethernet Part 6: 공급망 마스터 레퍼런스 — sub-system별 공급사 정리 1. 칩에서 Tray, 그리고 Rack까지 — 조립 개별 칩에 대한 설명이 끝났으니, 다음 질문은 그 칩들을 어떻게 조립하느냐다. 6개의 칩은 박스에 흩어진 상태로 출하되지 않는다 — 체계화된 어셈블리 구조 안으로 통합되어 출하된다. 체계: chip → module → compute tray → rack → SuperPOD Chip — 개별 실리콘 (Rubin GPU, Vera CPU 등). Module — 하나 또는 여러 개의 칩과 그에 부속된 부품 (메모리 소켓, VRM, 커넥터 등)을 담은 소형 PCB. Compute tray — 여러 module을 midplane을 통해 하나로 연결한 1U 섀시. Rack — compute tray 18개 + NVLink switch tray 9개 + power shelf 4개를 담은 19인치 캐비닛. SuperPOD — Spectrum-6 Ethernet으로 연결된 여러 개의 랙 (섹션 8에서 다룬다). 이 섹션에서는 compute tray 내부의 6가지 module 종류, 그들이 서로 어떻게 연결되고 냉각·전원을 공급받는지, 그리고 이 tray 18개가 어떻게 하나의 NVL72 rack으로 결합되는지를 차례대로 따라간다. (1) VR NVL72 랙 한 대의 해부 Nvidia가 헤드라인으로 내세우는 수치 (72 GPU 등)는 단순한 산수의 결과다. "Vera Rubin Superchip"은 단일 Strata module 위에 NVLink-C2C로 묶인 Vera CPU 1개 + Rubin GPU 2개다. tray당 superchip 2개, rack당 tray 18개 — 72-GPU 수치 뒤의 산수는 여기서 나온다. 원래의 명명은 사실 "VR NVL144"였다 — Nvidia가 한동안 GPU를 die 단위 (Rubin 패키지당 reticle-size die 2개 × 72 package = 144 die)로 세었기 때문이다. 2025년 12월에 package 단위로 환산해 "NVL72"로 되돌린 이후로, 그것이 현재까지 통용되는 표기다. (2) HGX Rubin NVL8 — 대체 form factor NVL72 tray 내부로 본격적으로 들어가기 전에 짚고 갈 점은, Rubin이 두 가지 배포 form factor로 출하된다는 사실이다. DGX (turnkey integrated appliance)와 HGX (OEM이 커스터마이즈하는 모듈형 GPU tray). 이 파트의 본문은 rack-scale VR NVL72 — DGX 스타일 제품 — 를 중심으로 다룬다. 대안 form factor는 HGX Rubin NVL8으로, GB300 → HGX B300 계보를 잇는 섀시-스케일 서버 (8 GPU)다. § 3부터는 NVL72에 집중하며, HGX는 본 섹션 안에서만 등장한다. 1) DGX vs HGX — 두 가지 설계 철학 DGX와 HGX는 하드웨어 차원에서 정반대 설계 철학을 구현한 두 모델이다. Nvidia GPU 제품이 둘 중 어느 모델을 기반으로 설계되었는지에 따라, 그 제품에서 허용되는 커스터마이징의 범위가 모두 결정된다. DGX — Turnkey AI Appliance 고정된, 완전 통합 노드: 사전 정의된 GPU 수, NVLink 토폴로지, CPU, 메모리, 네트워킹, 소프트웨어 스택까지 — 전부 Nvidia가 단일 시스템으로 튜닝해 묶어 둔 구성. 벤더 관리형 통합: Nvidia가 전체 하드웨어 + 소프트웨어 스택을 직접 정의하고, DGX 파트너는 최소한의 구성 선택권만 가진 채 "있는 그대로"로 출하된다. 목적: 고객 쪽의 통합 마찰 (integration friction)을 최소화하는 것. 부품 더미가 아니라 곧바로 동작하는 AI 슈퍼컴퓨터를 산다는 발상이다. Rubin 세대 사례: DGX Vera Rubin NVL72 랙, 그리고 그 랙들을 모아 구성한 DGX SuperPOD. HGX — 모듈형 GPU 빌딩 블록 레퍼런스 GPU tray + 레퍼런스 디자인: Nvidia가 모듈형 GPU tray (SXM Rubin GPU 4개 또는 8개 구성)와 레퍼런스 아키텍처를 출하하면, OEM이 그 tray를 자체 섀시 안에 통합한다. OEM과 클라우드 업체들의 커스터마이징: OEM (Dell, HPE, Lenovo, Supermicro)이 동일한 HGX GPU tray를 중심에 두고 자체 CPU (AMD 또는 Intel), RAM, 스토리지, 네트워크 fabric (Spectrum-X, InfiniBand, 또는 3rd-party), 관리 스택을 자유롭게 선택한다. 목표: Nvidia 브랜드 어플라이언스 형태가 아니라, 커스텀 설계 서버와 hyperscaler 랙 안에 Nvidia GPU를 확장 통합하는 것. Rubin 세대 사례: HGX Rubin NVL8 서버 (이 섹션의 주제). 한 줄 요약 DGX의 입장: "이건 완성된 Nvidia 통합 AI 노드다. 설계된 그대로 가져가라." HGX의 입장: "여기 표준 GPU tray를 줄 테니, 너의 시스템을 그 주위에 직접 구성하라." 2) Form-factor 비교 — Tray 수준 vs Rack 수준 가장 의미 있는 1:1 비교는 tray 수준에서 성립한다 — HGX Rubin NVL8 (완전한 섀시) vs VR NVL72 compute tray (랙 안의 1U tray 한 개). 맨 오른쪽 열은 참조용으로 전체 NVL72 rack을 함께 보여 준다. HGX NVL8과 VR NVL72 compute tray는 물리적 스케일이 비슷한 자리에 위치 (서버 섀시 ≈ 1U tray)하지만, 커스터마이즈 스펙트럼의 양 극단에 자리한다. HGX NVL8은 그 자체로 배포 가능한 단위다. 반면 NVL72 compute tray는 더 큰 rack-scale 설계의 한 조각에 불과하며, standalone으로는 동작하지 않는다. 따라서 의미 있는 배포 수준 비교는 HGX NVL8 ↔ NVL72 rack, 의미 있는 아키텍처 수준 비교는 HGX NVL8 ↔ NVL72 compute tray 쌍에서 성립한다. 3) NVL72가 더 빠른 NIC 없이 GPU당 1.6 T에 도달하는 방법 NVL72는 1.6T NIC 실리콘을 실제로 사용하지 않는다. 대신, GPU당 800G CX-9 패키지 2개가 모두 PCIe Gen6 lane을 통해 짝을 이루는 Vera CPU에 연결된다. 그 결과 논리적으로 "1.6T NIC"이 구현된다 — HGX와 동일한 CX-9 실리콘을 GPU당 두 배의 밀도로 배치한 셈이다. 4) 도입 패턴 — Neocloud vs Hyperscaler 어떤 기업이 어떤 form factor를 택하느냐에는 명확한 방향성이 있다. 절대 규칙은 아니지만 분명한 경향이 존재한다. Neocloud → DGX (VR NVL72) 쪽으로 기울어진다 플레이어: CoreWeave, Nebius, Lambda, Crusoe, TensorWave. 비즈니스 모델: GPU-as-a-Service — "GPU 임대업"으로서 배포 속도와 GPU 활용도의 최적화가 핵심. 왜 DGX인가: 사전 최적화된 Nvidia 소프트웨어 스택과 turnkey rack-scale 시스템이 통합에 드는 시간을 크게 줄여 준다. Neocloud는 커스텀 서버 엔지니어링 리스크를 떠안지 않고도 수천 개의 GPU를 빠르게 띄우는 것이 우선이다. 수요 패턴: GPU 수, TCO, uptime이 커스텀 토폴로지보다 더 중요하다. 표준화된 DGX 노드는 "그냥 작동한다"는 안정성이 자산이 된다. Hyperscaler → HGX 쪽으로 기울어진다 플레이어: AWS, GCP, Microsoft Azure, Meta (실무 차원에서는 xAI도 자사 fleet 일부에 사용 중). 비즈니스 모델: 대규모의 자체 커스터마이즈된 데이터센터 fabric. 내부 팀들이 커스텀 서버, 섀시, 네트워킹, 랙 설계를 직접 엔지니어링한다. 왜 HGX인가: Rubin GPU tray를 자체 선택한 CPU (in-house ARM, AMD, Intel)·펌웨어·telemetry·NIC·전력 공급·오케스트레이션과 자유롭게 페어링할 수 있게 해 준다. HGX tray는 기존 커스텀 랙 아키텍처에 자연스럽게 끼워 넣을 수 있고, Nvidia 브랜드 박스를 강제하지 않는다. 수요 패턴: 수백만 대의 서버에 걸친 유연성, 규모, 동질적 통합이 out-of-the-box turnkey 속도보다 우선시된다. 혼합 배포도 흔하다 일부 neocloud는 트레이닝 tier에는 DGX 랙 (빠른 배포, 높은 신뢰성), 인퍼런스 tier에는 HGX (저렴하고 커스터마이즈 가능)로 나눠 운영한다. 일부 hyperscaler는 fleet 대부분을 HGX로 유지하면서, 내부 AI 랩이나 전략 고객 응대용으로만 소수의 DGX 랙을 구매하기도 한다. 5) HGX가 NVL72와 함께 여전히 존재하는 이유 HGX는 rack-scale NVL72가 과한 환경 — 엔터프라이즈 클러스터, 혼합 워크로드 서버, 랩-스케일 인프라 — 즉, 더 작고 유연한 배포가 필요한 영역을 노린다. 자사 섀시에 Rubin GPU를 통합하려는 hyperscaler도 여기 포함된다. HGX는 single-plane, 8-rail 토폴로지를 따른다 — 1-plane 공식의 한도 ...

시리즈 안내 ⎯ Series Map Part 1: 플랫폼 개요와 아키텍처 맵 — Blackwell → Rubin 플랫폼의 핵심과 주요 사양 Part 2: Rubin GPU 엔지니어링 심층 분석 — process node, SM, HBM4, NVLink-C2C, 패키지, CPX와 Groq 3 LPX Part 3 (현재 글): Vera CPU와 네트워킹 실리콘 제품군 — Vera CPU, NVLink 6 Switch, ConnectX-9, BlueField-4, Spectrum-6 Part 4: 랙 조립 — 트레이, PCB, 쿨링 — HGX와 NVL72, 컴퓨트 트레이 모듈, cableless 미드플레인, PCB 업그레이드, 액체 냉각 Part 5: 랙 전력과 네트워킹 fabric — 전력 공급, HVDC, tray ↔ rack 배선, scale-up NVLink 6, scale-out InfiniBand와 Ethernet Part 6: 공급망 마스터 레퍼런스 — sub-system별 공급사 정리 4. Vera Vera는 Nvidia의 2세대 자체 ARM 기반 CPU로, Blackwell 플랫폼의 Grace를 잇는다. 설계 의도가 바뀌었다. Grace는 GPU 옆에 자리잡은 host CPU였다. Vera는 data engine으로 자리매김한다 — 데이터를 옮기고, 워크로드를 오케스트레이션하며, GPU의 처리량에 맞는 속도로 control flow를 처리하여 *Rubin GPU에 데이터가 효율적으로 전달되도록 조율하는 것이 역할이다. Rubin급 GPU 속도에서는 표준 서버 CPU가 병목이 된다. Vera는 그 병목을 제거하기 위해 특별히 설계됐다. Grace → Vera 한눈에 보기 변화는 네 개의 엔지니어링 레이어로 묶인다 — 무엇이 실행되는지, 무엇이 그것을 저장·공급하는지, 무엇이 그것을 칩 안팎으로 옮기는지, 이 모든 과정이 어떤 실리콘 위에서 작동하는지. 아래 표들은 각각 원시 사양의 변화 (delta)와 엔지니어링 결과를 짝지어 보여 준다 — Vera 섹션의 나머지를 읽을 때 표준 레퍼런스다. [연산 — Cores · Threads · SIMD] [캐시 & 메모리 서브시스템] [인터커넥트 & 표준] [실리콘] (1) Olympus Core와 Spatial Multithreading Vera는 Grace에서 사용된 ARM의 기성 Neoverse V2 코어에서 벗어나, Nvidia의 custom ARM 호환 Olympus 코어로 옮겨간다 — Nvidia 자체 CPU 코어 설계의 귀환이다. Olympus는 wide·deep microarchitecture로, branch prediction, prefetching, load-store 성능이 향상됐다. 일반 enterprise compute가 아닌, control-heavy하고 data movement가 많은 워크로드 (현대 GPU에 데이터를 공급하는 실제 병목 프로파일)에 맞춰 최적화됐다. ARM v9.2 완전 호환 — 기존 ARM Linux 배포판, 프레임워크, 오케스트레이션 소프트웨어가 수정 없이 실행된다. Spatial Multithreading이란 (그리고 SMT와 어떻게 다른가) 전통적인 Simultaneous Multi-Threading (SMT — Intel에서는 "Hyper-Threading", AMD Zen 코어에서 사용)은 코어의 실행 자원을 time-slicing해 두 스레드가 단일 코어를 공유하도록 한다. 처리량은 늘지만 스레드별 지연이 예측 불가능해지고 보안상 side-channel 공격 가능성이 생긴다. Vera의 Spatial Multithreading은 자원을 time-slicing하는 대신 물리적으로 분할하여 코어당 두 스레드를 실행한다. 결과: 88코어에 걸친 176 하드웨어 스레드. 스레드별 지연이 예측 가능하고, 스레드 간 격리가 강화된다. 한 테넌트의 워크로드가 다른 테넌트의 응답 시간에 영향을 주지 않아야 하는 multi-tenant AI factory에서는 결정적인 특성이다. 다이 레벨 yield 트릭 Nvidia는 실제로 die에 91개 코어를 인쇄하지만 88개만 활성화된 채로 출하한다. 3개의 redundant 코어는 순전히 제조 yield를 개선하기 위한 것이다 — 91개 중 어느 하나에 결함이 있어도 비활성화 처리하고 full 88-core 부품으로 출하한다. GPU 쪽의 floor-sweeping (제조 결함이 있는 일부 블록을 비활성화해 수율을 높이고, 이를 하위 모델로 판매하는 방식)과 동일한 발상이다. (2) 메모리 서브시스템 — SOCAMM + LPDDR5X Vera의 메모리 서브시스템은 Grace 대비 용량 3배·대역폭 2.4배로 재설계됐다. LPDDR5X (Low-Power DDR5X)는 최신 스마트폰·노트북에서 쓰이는 메모리 타입으로, 표준 서버 DDR5 대비 GB/s당 전력 효율이 훨씬 좋다. 대신 CPU에 가깝게 납땜되거나 모듈로 부착된다. Vera는 SOCAMM 모듈을 사용한다 — Small Outline Compression Attached Memory Module의 약자로, Nvidia가 데이터센터의 신뢰성·교체성 요구에 맞춰 설계한 LPDDR5X form factor다. Vera 소켓당 8개 SOCAMM 모듈, 총 1.5 TB @ 9,600 MT/s. 1024-bit 메모리 버스 (Grace의 512-bit의 두 배)가, 클럭을 합리적인 수준으로 유지하면서도 총 대역폭을 1.2 TB/s에 도달하게 만드는 메커니즘이다. 메모리 대역폭이 이렇게까지 중요한 이유 Rubin GPU 쪽 HBM 대역폭이 22 TB/s에 이르는 상황에서, 기존 CPU 쪽은 상대적으로 얇아 보였다. Vera의 1.2 TB/s LPDDR5X는 NVLink-C2C를 통해 애플리케이션에 노출되는 통합 메모리 풀의 두 번째 계층이다 (Part 2의 Rubin 섹션 (4) 참고). Rubin의 288 GB HBM4 용량을 초과한 KV cache는 어딘가 빠른 곳에 도달해야 한다 — Vera의 LPDDR5X가 바로 그 착륙 지점이다. Vera의 메모리 대역폭이 낮았다면 offload 경로가 GPU 연산을 멈추게 만들 것이다. (3) Scalable Coherency Fabric (SCF) — On-die 데이터 이동 2세대 Scalable Coherency Fabric은 88개 Olympus 코어 모두를 공유 L3 cache와 memory controller로 연결하는 on-chip 네트워크다. 단일 monolithic compute die 위에 구축됐다 — Nvidia가 compute 측에서는 chiplet 경계를 의도적으로 피했다. 이유: chiplet 경계는 지연과 대역폭 편차를 더한다. line rate에서 결정론적 데이터 이동이 본업인 CPU에게 이 편차는 받아들일 수 없다. 결과: SCF는 부하 상황에서도 피크 메모리 대역폭의 90% 이상을 유지한다. 즉, 소프트웨어가 헤드라인 수치인 1.2 TB/s에 근접한 값을 실제로 보게 된다는 뜻이다. Vera는 memory controller와 I/O는 chiplet으로 disaggregate하지만 (Rubin과 유사), compute die는 monolithic으로 유지한다는 점에 주목할 만하다. 이 분할은 엔지니어링 우선순위를 반영한다 — 독립적인 yield 관리가 도움 되는 부분은 chiplet 단위로 세분화하고, 결정론적 지연 (compute die 내부 연산·데이터 이동의 latency가 매번 일정하게 예측 가능해야 한다. 그래서 compute block은 chiplet보다 monolithic 구조가 유리하다.)이 필요한 부분은 monolithic으로 둔다. (4) I/O — NVLink-C2C, PCIe Gen6, CXL 3.1 Vera는 host 측 모든 I/O 인터페이스를 2배로 올리거나, 새로 도입했다. Grace 대비 비교는 다음과 같다: NVLink-C2C 행의 "Coherent"는 CPU와 GPU가 명시적 동기화 없이 동일한 메모리 내용을 자동 동기화를 통해 접근 가능하다는 의미다 (Part 2의 Rubin 섹션 (4)에서 자세히 다룬다). (5) Vera Rubin Superchip Vera는 일반적인 경우 단일 CPU로 판매되지 않는다. 기본 배포 단위는 Vera Rubin Superchip이다 — Vera CPU 1개 + Rubin GPU 2개를 단일 host 마더보드 모듈 위에 긴밀히 결합한 구성이다. CPU와 두 GPU는 NVLink-C2C를 통해 coherent 메모리 도메인 안에서 연결된다. 이것이 NVL72 랙의 기본 컴퓨트 빌딩 블록이다 — 각 compute tray가 superchip 2개를 담고, 랙은 18 tray를 담는다. Superchip 한 개당 합계: 100 PFLOPS NVFP4 (Rubin GPU 2개 합산), 2 TB의 fast memory, 88 Olympus 코어, 모듈 위 전체 실리콘의 트랜지스터 합 ~6 T. Vera는 agentic 처리, 분석, 클라우드, 스토리지, 인프라 서비스용으로 standalone 배포도 가능하지만, 랙 단위 플랫폼 thesis를 끌고 가는 것은 superchip 구성이다. (6) Summary — Vera, 한 번에 읽기 사양별 전체 변화 (와 엔지니어링적 귀결)는 앞부분 "Grace → Vera 한눈에 보기" 표에 정리되어 있다. 이 섹션은 그 배경에 깔린 thesis만 압축한다. 가장 깔끔한 해석: Vera CPU는 Rubin GPU에 데이터를 공급하는 데 있어 제약 요인을 최소화하는데 목적을 둔다. 모든 사양 업그레이드 — 대역폭, 용량, coherent link 폭, custom 코어 설계 — 은 연결되어있는 GPU의 처리량에 맞춰 보정된 결과다. 5. NVLink 6 Switch NVLink 6 Switch는 Vera Rubin의 scale-up fabric 칩이다 — 랙 단위 NVLink switch tray 안에 들어가, 72개의 Rubin GPU가 마치 단일 가속기처럼 서로 네트워킹 할 수 있게 만드는 실리콘이다. "Scale-up" = 여러 칩으로 더 큰 가상 가속기를 (랙 내에서) 구축하는 것. "Scale-out" = 데이터센터 안의 여러 랙을 연결하는 것 (ConnectX-9 + Spectrum-6가 별도로 담당). NVLink Switch는 랙에 대해, multi-core 칩의 on-die ring/mesh와 같은 위치 — all-to-all 인터커넥트다. (1) "동일한 Switch 칩, 두 배의 랙" 트릭 변화는 세 개 항목으로 나뉜다 — switch 실리콘 내부에서 무엇이 바뀌었는지, tray와 랙이 그 실리콘을 어떻게 합산되는지, switch가 순수 스위칭을 넘어 추가로 어떤 능력을 갖췄는지. 칩 수준 실리콘 Tray + Rack 합산 In-Network Compute (SHARP) 핵심 설계 선택은 칩 수준의 28.8 TB/s 스위칭 대역폭을 NVLink 5와 NVLink 6 사이에서 일정하게 유지했다는 것이다. 칩 수준 대역폭을 두 배로 늘리려면 더 큰 die 혹은 multi-die switch가 필요했을 텐데, 둘 다 설계 복잡도 비용이 크다. 대신 Nvidia는 칩 처리량은 그대로 두고, 링크당 SerDes 속도를 두 배로 (bidirectional signaling을 통해) 올리고 포트 수는 반으로 줄였다. 그 후 랙 단위 2배 스케일링은 tray나 랙 form factor를 바꾸지 않고서, tray당 칩 수를 두 배 (2 → 4) 늘리는 방식으로 달성됐다. (2) Bidirectional SerDes — NVLink 6가 링크당 속도를 두 배로 만드는 방법 헤드라인 숫자 자체는 단순하다 — NVLink 5는 전기 lane당 224G를 전달했고, NVLink 6는 lane당 448G를 전달한다. lane당 2배 점프다. 흥미로운 질문은 어떻게 Nvidia가 modulation rate나 baud rate를 두 배로 올리지 않고 이 수치에 도달했느냐다 — 둘 중 무엇을 건드렸어도 새로운 SerDes 실리콘과 더 빡빡한 signal integrity 마진이 필요했을 것이다. 답은 같은 구리 wire pair 위에서의 동시다발적 bidirectional signaling이다. 왜 단순한 "케이블 수를 2배로 늘리기"가 답이 아니었나 NVLink 대역폭을 두 배로 만드는 순진한 방법은 기존 200G SerDes를 그대로 두고 backplane 위의 구리 케이블 수만 두 배로 늘리는 것이다. 두 가지 이유로 그 길은 통하지 않는다. Blackwell NVL72 backplane은 이미 ~5,000개의 구리 케이블을 운반한다. 이를 ~10,000개로 두 배로 늘리는 일은 물리적으로 보면 어려운 과제고, GB200/GB300에서 이미 드러난 신뢰성 실패 모드를 훨씬 더 가속한다. 대안은 랙을 더 넓게 만드는 것 (AMD가 MI400 Helios 랙에서 택한 방향)인데, 이 경우 PCB trace 길이가 길어져 고속에서의 signal integrity가 저하된다. 그래서 Nvidia는 케이블 수는 그대로 두고, 대신 SerDes 속도를 밀어붙였다. "Bidirectional"이 실제로 의미하는 것 NVLink 전기 lane은 하나의 differential pair (DP) (동일한 크기에 극성이 반대인 신호를 운반하는 두 개의 도체)다. 과거의 NVLink lane pair는 한 방향씩 신호를 운반한다. Bidirectional SerDes는 동일한 pair 위에서 양 방향을 동시에 실행한다. 여기서 발생한...

시리즈 안내 ⎯ Series Map Part 1: 플랫폼 개요와 아키텍처 맵 — Blackwell → Rubin 플랫폼의 핵심과 주요 사양 Part 2 (현재 글): Rubin GPU 엔지니어링 심층 분석 — process node, SM, HBM4, NVLink-C2C, 패키지, CPX와 Groq 3 LPX Part 3: Vera CPU와 네트워킹 실리콘 제품군 — Vera CPU, NVLink 6 Switch, ConnectX-9, BlueField-4, Spectrum-6 Part 4: 랙 조립 — 트레이, PCB, 쿨링 — HGX와 NVL72, 컴퓨트 트레이 모듈, cableless 미드플레인, PCB 업그레이드, 액체 냉각 Part 5: 랙 전력과 네트워킹 fabric — 전력 공급, HVDC, tray ↔ rack 배선, scale-up NVLink 6, scale-out InfiniBand와 Ethernet Part 6: 공급망 마스터 레퍼런스 — sub-system별 공급사 정리 3. Rubin GPU — 엔지니어링 심층 분석 Blackwell 대비 Rubin의 기본 구조는 동일하게 유지된다 — reticle-sized logic die 두 개가 나란히 배치되고, 각각 HBM 스택으로 둘러싸여 있다. ("Reticle-sized"란 각 다이가 현재 photolithography 장비가 단일 노출 (single exposure)로 인쇄할 수 있는 최대 크기, 약 800 mm²라는 뜻이다. "Die"는 패키징되기 전 칩의 회로를 담은 실제 실리콘 정사각형을 가리킨다.) 8개의 HBM 스택은 두 다이와 함께 동일한 패키지에 배치된다. 변화는 다이 내부와 패키지 주변에서 일어난다. 35 PFLOPS dense FP4라는 수치 (GB200 대비 3.5배)는 세 가지 요인이 복합적으로 작용한 결과다. SM (Streaming Multiprocessor) 수: 160 → 224. SM은 Nvidia GPU의 기본 빌딩 블록으로, CUDA Core (범용 연산 유닛), Tensor Core (행렬 연산 유닛), 레지스터, shared memory를 담은 소형 프로세서다. 현대 GPU는 본질적으로 수백 개의 SM이 병렬로 실행되는 구조다. 5세대 Tensor Core의 폭이 SM당 clock당 32,768 FP4 MAC으로 두 배 늘어났다. MAC은 multiply-accumulate 연산 (a × b + c)으로, 신경망 수학에서 사용되는 행렬 곱셈의 핵심 연산이다. 클럭: 1.90 GHz → 2.38 GHz (+25%). GPU의 내부 사이클 속도로, 클럭이 빠를수록 실리콘 단위당 초당 더 많은 연산을 수행할 수 있다. 해당 문서 내 설명은 SM에서 시작해 메모리, I/O, 정밀도·sparsity, 전력, 마지막으로 패키지 순서로 진행된다. (1) Process Node와 Die 구조 Rubin은 TSMC의 3nm 공정을 사용하며, I/O를 chiplet 단위로 분산한다. 동시에 Blackwell의 2-die + 8-HBM-stack 레이아웃은 그대로 유지된다. "chiplet 단위로 분산된다는 것"은 하나의 거대한 monolithic die에 통합하는 대신, 칩을 여러 작은 조각 (chiplet)으로 나눈 후 동일한 패키지에 결합하는 방식이다. "I/O" (input/output)는 칩에서 외부 세계와 통신을 담당하는 부분으로, 주로 다른 GPU와의 NVLink, CPU와의 NVLink-C2C를 가리킨다. Compute die는 reticle-size를 유지하면서, I/O 대신 더 많은 SM과 더 넓은 Tensor Core에 면적을 할당한다. NVLink-C2C와 NVLink 6 I/O 블록은 logic die와 독립적으로 설계 및 수율 관리가 가능한 별도의 chiplet으로 분리된다. ("수율 관리"란 manufacturing yield를 의미한다 — 칩을 더 작은 조각들로 나누면 제조 결함이 발생할 시 monolithic die 전체가 아닌 해당 결함 부분만 오작동하기에, 전체 실리콘 중 사용 가능한 비율이 높아진다.) 트랜지스터 수는 208 B (Blackwell) → 336 B (Rubin)로 +60% 증가한다. 더 커진 logic die, 새로운 I/O chiplet, 두 배가 된 Tensor Core가 합산된 결과다. (2) 연산: SM, 5세대 Tensor Core, SFU SM당 Tensor Core의 변화가 FP4·FP8 스케일링을 주도한다. Tensor Core의 폭은 각 SM이 clock cycle당 수행할 수 있는 multiply-accumulate 연산 횟수를 결정한다. 특히, Tensor Core 폭의 2배 증가는 NVFP4와 FP8에만 적용된다. 더 넓은 포맷인 BF16과 TF32는 Blackwell과 동일하게 유지되어, FP16 성능은 Blackwell 대비 1.6배 상승에 그친다. BF16 (bfloat16)과 TF32 (Nvidia의 TensorFloat-32)는 각각 16비트·19비트 포맷으로, 일반적으로 AI 모델 훈련에 사용된다 — FP16보다 더 넓은 수치 범위를 제공하는 대신 FP8/FP4보다는 폭이 넓다. 이 아키텍처 결정은 대부분의 훈련 및 추론 워크로드가 TF32와 BF16에서 FP8·FP4로 옮겨갈 것이라는 Nvidia의 판단을 반영한다. Special Function Units (SFU). SFU는 각 SM 내부에서 "transcendental" 연산 (지수, 로그, sine, 역수 등 기본 multiply/add보다 훨씬 복잡한 연산)을 처리하는 소형 수학 유닛이다. Rubin은 SFU 경로를 확장한다. Softmax 가속 (SM당 clock당 EX2 연산으로 측정 — EX2는 2^x, softmax가 의존하는 지수 연산을 의미)이 Blackwell의 16에서 Rubin의 32 (FP32) / 64 (FP16) 로 상승한다. transformer 모델의 attention 블록을 지배하는 exp/softmax 연산이 2~4배 향상되는 셈이다. (Softmax는 임의의 숫자 벡터를 확률 분포로 변환하고, "attention" 메커니즘 (다음 토큰을 예측하기 위해 모델이 이전 토큰 중 어느 것이 중요한지 가중치를 매긴다)은 inference당 수십억 번 softmax를 호출한다.) 이 SFU 확장이 없었다면 attention 커널이 새로운 FP4 처리량의 병목이 되었을 것이다. AI + 과학 컴퓨팅의 융합. Rubin은 FP32/FP64 처리량을 AI 스타일 행렬 워크로드 쪽으로 재조정한다. FP64는 전통적인 과학 시뮬레이션 코드 (기후, 유체역학, 계산물리학)에서 사용되는 64비트 double-precision 포맷이다. "Vector" 연산은 배열 원소별 (element-wise) 연산이고, "Matrix" 연산은 대규모 행렬-행렬 곱셈으로, Tensor Core가 가속하는 대상이다. FP64 vector 처리량은 Blackwell 대비 다소 감소한다. Nvidia가 해당 실리콘 면적을 FP4·FP8과 Tensor Core용으로 재할당했기 때문이다. 행렬 연산에서 FP64급 정확도가 필요한 과학 코드는 "Tensor Core matrix emulation"을 거치도록 설계되어 있다. 여러 차례의 저정밀 Tensor Core pass를 실행하고, 오차 보정 규정을 활용해 결과를 결합하여 FP64 결과를 만들어 낸다. Ozaki 알고리즘이 그러한 기법 중 하나로, 저정밀 하드웨어에서 FP64에 준하는 정확도를 제공한다. Nvidia의 cuBLAS 라이브러리 (표준 선형대수 커널 라이브러리)가 이 에뮬레이션을 기본 탑재한다. FP64 vector는 여전히 연산 처리량보다 메모리 대역폭에 성능이 좌우되는 코드들에서 의미가 있다. (3) 메모리 서브시스템 — HBM4 Rubin은 HBM3E (Blackwell에서 사용된 세대)에서 HBM4로 전환한다. HBM3E 대비 스택당 bus width가 두 배가 됐다. "Bus width"는 HBM 스택을 GPU에 연결하는 병렬 wire의 개수로, wire가 많을수록 clock당 더 많은 데이터를 옮길 수 있다. Pin speed: 10.8 GT/s (gigatransfers per second — 각 wire가 토글되는 속도). 총 대역폭 목표: 22 TB/s로 Blackwell의 8 TB/s 대비 약 2.75~2.8배. 용량은 GB300과 동일한 288 GB로 유지. 처음 GTC 2025에서는 13 TB/s로 발표되었으나, 이후 Nvidia가 목표를 상향 조정했다. 새로운 memory controller (HBM 읽기·쓰기를 조율하는 on-die 로직) 및 더 긴밀한 compute-memory 통합과 짝지어, 부하 상황에서도 SM 파이프라인에 데이터가 효율적으로 제공된다. 대역폭 업그레이드가 강제된 이유. 원래의 13 TB/s 사양 하에서는 AMD의 MI450이 Rubin보다 더 높은 메모리 대역폭으로 출하될 상황이었다. 앞서 나가기 위해 Nvidia는 JEDEC 표준 이상의 HBM4 pin speed를 요구했다. JEDEC (Joint Electron Device Engineering Council)은 공식 메모리 사양을 정하는 산업 표준 기관으로, 모든 DRAM 공급사는 JEDEC 표준에 맞춰 설계한다. Nvidia는 사실상 SK Hynix, Samsung, Micron에게 공식 사양 이상으로 오버클럭하도록 요구하고 있으며, 메모리 공급사들은 표준이 보장하지 않는 속도로 부품을 검증해야 하는 상황이다. HBM4 공급사 Pin Speed 동향 Rubin 세대에서 3사 HBM 경쟁은 명확한 순위가 매겨진다. SK Hynix — 현재 HBM4 pin speed 검증에서 선두. 목표치인 10.8 GT/s에서 첫 Rubin-grade HBM4를 출하할 것으로 예상된다. Samsung — SK Hynix를 바짝 뒤쫓는 중이며 Nvidia에서 검증 단계. Rubin 양산이 본격화되면 second-source 공급사 역할을 할 것으로 보인다. Micron — HBM4 검증에서 상당히 뒤처졌으며 Rubin HBM4에서 사실상 배제되었다. HBM이 logic die 다음으로 GPU 패키지에서 가장 비싼 단일 부품이라는 점에서 의미 있는 상업적 타격이다. 실제로 의미하는 바. 초기 Rubin 출하분은 22 TB/s 헤드라인이 아닌 ~20 TB/s에 가깝게 떨어질 가능성이 높다. 공급사들이 양산 물량에서 풀 10.8 GT/s pin speed를 유지하기 어렵기 때문이다. Pin speed 검증이 새로운 병목이다. JEDEC 사양을 초과해 부품을 검증해 달라고 공급사에 요구한다는 것은, 수율과 binning ratio가 산업 표준이 아닌 Nvidia 전용 기준이 된다는 의미이기도 하다. 공급 연속성에 실질적인 리스크다. "Micron이 배제됐다"는 결과는 AI 하드웨어 공급망 전반에 파급된다 — 2026년 Micron의 HBM 매출에서 Nvidia 비중은 급감하는 반면, SK Hynix와 Samsung은 점진적 점유율을 추가로 가져간다. Rubin의 pin speed 목표가 실제로 검증되기 전까지, 22 TB/s 헤드라인은 보장된 출하 수치가 아닌 포부적 사양으로 받아들이는 것이 현실적이다. (4) I/O Chiplet — NVLink-C2C, NVLink 6와 Coherent Memory Rubin의 off-die 통신은 이번 세대에 새로 도입된 두 개의 전용 I/O chiplet으로 분리된다. NVLink는 Nvidia의 독점 고대역폭 chip-to-chip 인터커넥트로, 표준 ...