핵심 요약 칩의 연산 성능은 20년간 ~60,000배 뛰었지만, 그 연산에 데이터를 공급하는 배선은 따라오지 못했다. 오늘날 AI 가속기의 진짜 제약은 네트워킹이다. GPU↔GPU 네트워크든 GPU↔메모리 HBM 버스든 본질은 같다. 둘 다 비좁은 die edge를 지나야 하기 때문이다. 구리에는 더 내어줄 가장자리가 없다. 결국 광학이 해답이나, 전환은 단계적으로 온다. SerDes를 하루아침에 걷어 내고 co-packaged optics로 바꿀 수는 없다. 일단 광학이 주 I/O 매체가 되면, 메모리는 GPU 옆에 함께 패키징하는 대상이 아니라 fabric 너머에서 붙여 쓰는 자원이 된다 — 연산 풀과 값싼 commodity DRAM 풀이 하나의 저지연 optical fabric에 연결되고, optical switch가 경로를 잡는다. HBM은 사라지지 않는다 — 캐시 계층으로 강등될 뿐이다. 이 노트를 읽는 법 Section 0 — 왜 광학인가, 왜 단계적으로 접근할 수밖에 없는가에 대해 짧게 되짚는다. Section 1–3 — 핵심: 가속기는 네트워크에 묶여 있다 → 메모리도 네트워크의 일부다 → 메모리를 optical 스위치 너머로 분리한다. Section 4 — 어떤 기업들이 해당 아키텍처를 개발하고 있는지, 어디를 봐야 하는지. 출처 종합 네 개의 출처를 기반해 핵심 주장 하나로 엮었다. 엔지니어링 방향성은 출처들 사이에서 비교적 잘 교차 검증되지만, 정확한 시점과 HBM 쇠퇴의 규모는 불확실하다. Irrational Analysis — HBM: High-Bandwidth Mistake (Jun 01 2026). 메모리 분리 (disaggregation) 주장. 자기 포지션을 방어하는 색채가 강하다 — DRAM 롱 포지션에서 Samsung을 노골적으로 미는 입장이며, "7~10년 내 HBM 물량 ~90% 감소" 주장은 전적으로 latency 문제 (§3)가 대규모로 풀린다는 전제에 기댄다. SemiVision — Lightmatter Taiwan Tech Day in 20 Minutes (Jan 29 2026)와 Lightmatter at Computex 2026: The Bottleneck Has Shifted from Compute to Interconnect (Jun 04 2026). Optical fabric 쪽 주장으로, 서술의 중심은 Lightmatter다. SemiAnalysis — Co-Packaged Optics (CPO) Book — Scaling with Light. CPO의 경제성·단계론·신뢰성 데이터. CPO 전환, DSP 비용·전력 근거, Rubin의 HBM4 핀 속도 요구에 대한 보강 자료는 동반 노트 CPO에 관하여 (Part 1–2)와 Vera Rubin Decoded (Part 2)에서 가져왔다. 0 · Refresher — 왜 광학인가, 왜 단계적인가 0.1 진짜 범인은 die edge (shoreline) "shoreline"이 뜻하는 것 칩은 하나의 섬에 가깝다. 전력·메모리·네트워크 등 모든 외부 연결은 칩의 둘레를 건너야 한다. 그 둘레는 die 크기로 정해지고, 그 위에 배치할 수 있는 유효 I/O lane 수가 곧 shoreline (=beachfront)이다. 데이터 이동량이 커질수록 병목은 코어가 아니라 이 "칩의 둘레"가 된다. 하나의 문제를 두 관점으로 바라보면 한쪽은 이를 shoreline 문제라 부르고, 다른 쪽은 메모리 대역폭을 "I/O 밀도 문제"로 본다. 동일한 문제를 서로 다른 각도에서 설명하고 있을 뿐이다. Logic die 주변을 HBM이 둘러싸고, SerDes I/O가 같은 가장자리를 놓고 경쟁한다. "새로운 패러다임이 필요하다." 0.2 구리의 세 가지 한계점 SerDes & PHY SerDes (Serializer/Deserializer)는 고속 직렬 비트 스트림을 구리선에 싣고, 반대편에서 다시 복원하는 회로다. PHY: 채널과 물리적으로 맞닿는 더 넓은 아날로그 프런트엔드. 둘 다 die 가장자리에 자리 잡아 shoreline·전력·면적을 잡아먹는다. 세 가지 한계점 도달 거리. 구리선을 탄 고속 전기 신호는 ~2 m를 넘어서면 급격히 약해진다. NVLink는 지금 GPU당 ~7.2 Tb/s 속도로 네트워킹이 가능하나 (Rubin은 ~14.4 Tb/s 목표), 그건 단일 랙 내에서만 가능하다. Copper scale-up 도메인을 랙 외부로, 무한히 확장할 수는 없다. 비선형 전력. Broadcom에 따르면 최근 스위치 세대들에서 대역폭이 ~80배 오르는 동안 시스템 전력은 ~22배 올랐고, SerDes/광학 전력은 코어 로직보다 3배 이상 빠르게 늘었다. 비트가 더 필요해지는 바로 그 지점에서 비트당 전력 효율이 악화된다. 고속에서의 insertion loss. 단일 구리선 내 전기신호의 속도를 224 Gbit/s (그리고 "진짜" 448G)까지 밀어붙이면 신호 무결성의 벽에 부딪힌다 — bump, via, trace, 커넥터 하나하나가 신호를 깎아먹는다. PAM4로 단일 lane에서 448G의 속도를 내려면 ~244 Gbaud가 필요한데, 전력과 손실 측면에서 감당하기 어렵다. Nvidia가 채널당 448G에 도달하는 방식도 두 lane을 사용한 양방향 SerDes (한 채널을 224G Tx + 224G Rx가 나눠 쓰는 방식)를 통해서지, 단일 lane을 통한 단방향 448G는 아니다. PAM4 Pulse Amplitude Modulation, 4 레벨 — 자리당 1비트 대신 2비트 (전압 4단계)를 실어, 같은 baud rate에서 비트율을 두 배로 만든다. 더 밀어붙이면 (PAM6/PAM8) 비트는 얻지만 신호 마진과 전력을 잃는다. 212 Gbps에서는 신호가 커넥터에 닿기도 전에 ~20 dB를 잃는다 — 따라서 "특화된 ASIC과 CPO 인터커넥트의 개발을 요구한다." 0.3 왜 광학인가, 그리고 핵심 지표들 광학은 정말 중요한 지표에서 이긴다: 네트워킹 거리가 증가해도 유지되는, 에너지당 대역폭 밀도. 구리를 통한 전기 링크는 도달 거리에 따라 신호 품질이 지수적으로 감소하지만, 광학 링크는 거의 변함없다. 업계 격언은 "되도록 가능한 곳엔 구리, 어쩔 수 없는 곳엔 광학"인데, 그 "어쩔 수 없는" 선이 점점 칩 쪽으로 다가오고 있다. Pluggables → CPO 광학은 단계적으로 칩에 가까워진다. 각 단계는 광신호 변환 직전의 전기 구간을 줄이고, 그 결과 DSP (Digital Signal Processor)를 떼거나 SerDes 부담을 낮출 수 있다. 전력 수치는 800G 기준이다. Traditional pluggables — 엔진이 전면 패널 cage (~15–30 cm)에 있다. 긴 PCB 경로 때문에 DSP가 필요하다. ~30 W; 전면 패널 hot-swap. LPO (Linear Pluggable) — 같은 cage를 쓰되 DSP를 떼어내 그 부담을 호스트로 넘긴다. ~15–18 W. OBO와 CPO 사이의 한 단계가 아니라 pluggable의 한 갈래다. OBO (On-Board Optics) — 엔진을 보드 중앙부에 납땜한다 (~수 cm). 여전히 DSP가 필요하고, 납땜형이라 현장 교체가 어렵다. ~20 W. "양쪽의 최악" (CPO의 복잡함 + pluggable의 한계)에 가깝다. NPO (Near-Packaged Optics) — 광학 엔진이 패키지 근처, 흔히 소켓에 꽂는 별도 substrate에 놓인다. SerDes까지는 여전히 짧은 구리선 구간이 남지만, DSP는 간소화할 수 있다. ~15 W; 모듈 단위 교체 가능. 위험이 낮은 중간 단계다. CPO (Co-Packaged Optics) — 엔진이 호스트 패키지 위 (~10 mm)에 올라간다. long-reach SerDes와 transceiver DSP를 없앤다. ~5 W; 패키지 단위 교체. OE (Optical Engine) = PIC (Photonic IC — modulator·waveguide·detector) + EIC (Electronic IC — driver·TIA·제어 로직). 각 단계를 아키텍처 단면도로 보면 다음과 같다. 기준점에서 시작해, 단계마다 optics를 ASIC 쪽으로 당겨 온다: 기준점 — traditional pluggables: 모듈이 전면 패널 cage에, ASIC에서 손실 PCB로 15–30 cm 떨어져 있다. 그 긴 전기 구간이 바로 DSP가 복원해야 할 대상이다. OBO: 모듈이 ASIC 근처 보드 중앙부로 옮겨 오지만, 수 cm의 PCB 구간은 남는다 — 그래서 DSP도 남는다. 광신호는 내부 fiber jumper를 타고 전면 패널에 닿는다. NPO: 광 엔진이 같은 PCB 위 별도의 교체 가능한 패키지로 ASIC 옆에 놓인다 — 전기 구간이 훨씬 짧고 DSP는 간소화할 수 있다. ASIC, EIC, PIC를 나란히 둔 모습 — 광 엔진을 호스트 substrate에 올려 전기 경로를 ~mm로 줄이고 DSP를 아예 없애는 건 CPO뿐이다. DSP: 비용과 전력의 핵심 표적 Pluggable transceiver에서 DSP는 긴 구리선 구간을 지나며 열화된 전기 신호를 리타이머를 통해 복원한다. 너무 멀리 보내 손상된 신호를 되살리기 위한 회로다. DSP는 800G 모듈 전력의 ~50% (30 W 중 ~20 W)이고 BoM의 20~30%다. 게다가 transceiver 자체가 클러스터 TCO의 ~10%를 차지할 수 있다. 그래서 DSP는 비용과 전력 양쪽에서 가장 큰 지렛대 중 하나다. CPO를 통해 전기 신호의 이동 구간을 줄이면 DSP는 더 이상 필요 없다. 계산 예시: 18k-GPU 규모의 GB300 클러스터를 2-layer InfiniBand fabric으로 묶으면 800G transceiver ~18,432개 + 1.6T transceiver ~27,648개가 필요하다. DSP당 6–7 W (800G), 12–14 W (1.6T)를 소비한다고 잡으면, back-end 네트워크에만 DSP 전력 ~480 kW (랙당 ~1.8 kW)가 들어간다. 여기가 공략 지점이다. DSP vs CPO — 링크 단위로는 크지만 클러스터 단위에서는 희석된다 DSP transceiver를 CPO로 바꾸면: transceiver 전력 −84% 절감, 네트워킹 전력 −23% 절감이 가능하지만, 총 클러스터 전력으로는 ~2% 절감에 그친다. (3-Layer 네트워크 클러스터 기준) 개별 링크 단위 기준: 상당한 절감효과를 이룰 수 있다. DSP 기반 pluggable과 CPO 광 엔진 (OE) + 외부 레이저를 대역폭 800G로 정규화해 비교하면: 800G DR4 pluggable: ~16–17 W 소비에서 → CPO OE + 레이저: ~4–5 W 소비 = ~73% 감소. 800G 2×FR4 pluggable: ~15 W 소비에서 → OE + 레이저: 5.4 W 소비 = ~65% 감소. 모듈 종류도 다르고 별개의 연구인데도 같은 범위로 떨어진다는 점이 결과의 신뢰도를 높인다. 어떻게 이런 가파른 절감이 가능한지: DSP가 pluggable 전력의 대부분을 차지한다. CPO는 짧은 전기 구간 덕에 그 규모의 전력 소보가 불필요하고, 이 하나의 절감이 CPO의 대표 수치인 링크당 ~50–80% 전력 절감에 가장 크게 기여한다. 클러스터 단위 기준: 클러스터 규모에서는 희석된다. 3-layer GB300 NVL72 클러스터 전반에서 DSP transceiver를 CPO로 바꾸면 transceiver 전력은 ~84%, 네트워킹 전력은 ~23% 줄어든다. 하지만 네트워킹은 클러스터 전력의 ~9%에 불과해서, 총 클러스터 전력은 ~2%밖에 안 줄어든다 (2-layer 망에서도 ≤~4%). 비용도 마찬가지다: 네트워킹 비용 −21%지만 총 클러스터 비용은 −3% (2-layer 망에서 최대 −46% / −7%). 따라서 scale-out 쪽은 전력 절감의 상한이 낮고, 전략적 견인력은 scale-up에 있다. 전력 2–4% / 비용 3–7% 절감만으로는 서비스 용이성·신뢰성·vendor lock-in에 대한 우려를 안고 뛰어들기 어렵다. CPO가 "있으면 좋은" 게 아니라 반드시 필요한 곳은 scale-up이다 — copper/SerDes 스케일링이 물리적 벽에 부딪히는 영역이며, 광학의 영역이 scale-out에서 scale-up 순으로 확장되는 이유도 바로 이것이다. 0.4 왜 단계적이어야 하나 SerDes를 곧바로 CPO로 갈아끼울 수는 없다. 광학은 integration ladder (통합의 사다리)를 오른다. 단계가 올라갈수록 die에 더 가까워지고 비트당 비용은 낮아지지만, 구현 난도는 높아진다: 단계적 경로: copper/pluggables → NPO → 2D CPO → 3D CPO → 3D photonic interposer. 발목을 잡는 건 물리적 한계가 아니라 경제성과...

NVIDIA (NASDAQ: NVDA) 는 하드웨어 설계부터 소프트웨어 스택까지 모든 인프라에 end-to-end 솔루션을 제공할 것. 본격적인 agentic-driven 소프트웨어 스택 시대의 개막, 이를 위한 필수 하드웨어로 Vera CPU를 더욱 주목함. 1. NVIDIA DSX DSX는 AI 팩토리 구축에 필요한 칩, 시스템, 소프트웨어, 데이터센터 시설, 파트너 기술 전반을 통합한 플랫폼으로, 토큰당 비용을 최소화하고 초기 생산 가동 시점을 단축하는 데 초점을 맞춤. Jensen Huang은 “칩만 공급하는 것이 아니라 AI 팩토리 구축을 위한 완전한 플레이북을 제공하는 것”이라며 “투자 전에 전체 팩토리를 시뮬레이션하고, 랙 설치 전 성능을 검증하며, 생산 환경에 필요한 수준의 안정성을 확보할 수 있다”고 밝힘. 신규 핵심 구성 요소: DSX MaxLPS: 전력 예산 내에서 메가와트당 토큰 처리량을 극대화하는 소프트웨어 제품군. 45도 액체 냉각과 전력 효율 최적화로 최대 40% 더 많은 GPU를 에너지 효율이 가장 높은 구간에서 운영 가능. DSX OS: AI 팩토리 운영을 위한 오픈소스 운영 소프트웨어. 수명주기 관리, 지능형 스케줄링, 상태 자동화, 복원력, 멀티테넌트 운영 기능 제공. 기존 플랫폼 구성 요소: DSX Reference Design: 컴퓨팅, 네트워크, 스토리지, 전력, 냉각을 아우르는 검증된 AI 팩토리 설계 아키텍처. DSX Sim: 설계부터 운영까지 인프라를 시뮬레이션·최적화하는 디지털 트윈 기반 플랫폼. DSX Flex: 전력망과 AI 팩토리를 연결해 수요반응, 전력가격 변동, 재생에너지 활용 등을 자동 조정. DSX Exchange: 컴퓨팅, 네트워크, 전력, 냉각 시스템 데이터를 통합 연동하는 플랫폼. 파트너 동향: 클라우드 사업자 (CoreWeave (NASDAQ: CRWV), Crusoe, IREN (NASDAQ: IREN), Lambda, Nebius (NASDAQ: NBIS), Nscale, Yotta Data Services 등)와 협력해 DSX Sim·DSX MaxLPS·DSX OS를 배포 중. Dell Technologies (NYSE: DELL), HPE (NYSE: HPE), Lenovo (HKG: 0992), Supermicro (NASDAQ: SMCI) 와 함께 ASUS (TPE: 2357), Foxconn (TPE: 2317), Gigabyte (TPE: 2376), Pegatron (TPE: 4938), Quanta Cloud Technology (QCT, TPE: 2382), Wistron (TPE: 3231), Wiwynn (TPE: 6669) 등도 DSX 지원...

시리즈 안내 ⎯ 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 공식의 한도 ...