🧠 DRAM

NVHBM 분석

개요

NVHBM은 NVIDIA가 2026년 8월 공개한 custom HBM 아키텍처입니다. 기존 HBM 구현에서는 XPU(compute die)에 memory controller와 넓은 HBM PHY를 배치하지만, NVHBM은 NVIDIA가 설계한 memory controller를 HBM 3D stack의 base die로 옮깁니다. 따라서 NVHBM은 HBM4E를 대체하는 JEDEC 세대 규격이나 새로운 DRAM cell 기술이 아니라, HBM stack과 XPU의 인터페이스 경계를 다시 설계하는 package-level 기술입니다. NVIDIA가 NVHBM이라는 약어의 공식적인 낱말 풀이나 세부 protocol 이름을 별도로 공개한 것은 아닙니다.

NVIDIA는 standard HBM4E 대비 stack당 memory bandwidth 최대 30% 증가, HBM power 최대 15% 감소, XPU compute die area 최대 25% 확보를 제시했습니다. Technical Blog는 custom PHY와 더 좁은 interface를 통해 PHY·support area 최대 67% 감소와 layout 전체의 usable silicon 최대 80% 증가도 언급합니다. 이 수치는 NVIDIA가 제시한 상대 비교이며 NVHBM의 절대 pin 수, signal rate, stack capacity, latency, 실제 양산 제품과 독립 벤치마크 결과는 공개되지 않았습니다.

기존 HBM4E와 NVHBM의 base die 및 controller 배치 비교

그림 1. NVHBM의 핵심은 DRAM array 자체보다 memory controller와 PHY의 배치·면적을 바꾸는 것입니다. 실제 base die 내부 회로와 PHY block의 정확한 partition은 공개 자료를 바탕으로 확정할 수 없습니다.

핵심 개념

HBM 세대가 아닌 custom implementation

HBM4E는 HBM 계열의 세대·제품 구현을 가리키는 반면, NVHBM은 NVIDIA가 특정 XPU 플랫폼에 제공하려는 custom base-die technology입니다. NVIDIA의 발표는 NVHBM을 JEDEC 표준 문서나 독립된 DRAM generation으로 소개하지 않고, NVLink Fusion 고객이 사용할 수 있는 custom HBM architecture로 설명합니다. 따라서 NVHBM = HBM5 또는 NVHBM = HBM4E의 후속 규격으로 읽으면 안 됩니다.

NVHBM이 바꾸는 중심은 다음 세 가지입니다.

Controller 위치: XPU die에 있던 custom memory controller를 HBM base die로 이동
PHY와 배선: custom PHY와 더 효율적인 interface connection으로 XPU와 interposer의 면적 부담 축소
통합 경계: HBM supplier의 DRAM stack, NVIDIA의 base die·controller, custom XPU를 사전 검증된 조합으로 묶음

Base die로 이동한 memory controller

HBM stack의 base die는 여러 DRAM die의 TSV 경로와 외부 인터페이스가 만나는 층입니다. NVHBM에서는 이 층에 NVIDIA custom memory controller를 포함시켜, XPU가 직접 DRAM command를 모두 생성하는 대신 NVHBM interface를 통해 stack 쪽 controller와 통신하도록 설계합니다.

공개 자료는 controller에 포함되는 address mapping, command queue, refresh scheduler, ECC·RAS 경계, channel 수를 명시하지 않습니다. 따라서 다음 흐름은 NVHBM의 공개 구조와 일반적인 메모리 controller 역할을 결합한 개념 모델입니다.

XPU가 load/store 요청을 만들고 custom HBM interface로 전달합니다.
NVHBM의 외부 PHY가 패키지 연결을 통해 요청과 write data를 수신합니다.
base-die controller가 주소를 channel·bank·row·column 동작으로 변환하고 DRAM command를 스케줄링합니다.
HBM 내부 TSV와 logic path를 통해 해당 DRAM bank가 activate, read/write, precharge를 수행합니다.
읽은 데이터는 base die와 PHY를 거쳐 XPU cache 또는 compute engine으로 돌아갑니다.

Custom PHY와 interface footprint

NVIDIA는 NVHBM이 standard HBM4E보다 더 효율적인 interface connection을 사용하고, custom PHY가 PHY·support area를 최대 67% 줄일 수 있다고 설명합니다. 넓은 HBM interface는 낮은 pin rate에서 큰 대역폭을 얻는 장점이 있지만, XPU die edge, interposer routing, power delivery에 넓은 면적을 요구합니다. NVHBM은 controller를 stack 안으로 이동시키면서 XPU 쪽 interface를 재구성해 중앙 compute area를 확보하는 방향입니다.

다만 더 좁은 interface가 의미하는 정확한 data width, lane 수, pin당 rate, signaling 방식은 공개되지 않았습니다. SPHBM4처럼 폭을 줄이고 serialization하는 방식이라고 단정할 수도 없습니다. NVHBM의 공개 정보만으로는 HBM 내부 wide interface와 외부 XPU-facing interface 사이에 어떤 serialization, protocol conversion, training 또는 error handling이 들어가는지 확정할 수 없습니다.

메모리 계층에서의 위치

NVHBM은 XPU의 메모리 계층에서 HBM이라는 device memory 층의 구현 경계를 바꿉니다. Register file, shared memory, on-chip SRAM, L1/L2 cache가 NVHBM 때문에 사라지는 것은 아니며, HBM capacity가 자동으로 증가하는 것도 아닙니다. XPU의 cache hierarchy와 workload가 보는 HBM address space의 논리적 역할은 유지되고, 달라지는 것은 XPU와 DRAM stack 사이의 controller·PHY 배치와 물리적 데이터 경로입니다.

특히 NVHBM과 NVLink Fusion은 서로 다른 계층의 기술입니다. NVHBM은 한 XPU package 안에서 HBM에 접근하는 local memory 경로이고, NVLink Fusion은 custom XPU를 NVIDIA NVLink scale-up fabric, NVLink-C2C와 MGX rack architecture에 연결하는 system-level IP입니다.

그림 2. 요청은 XPU의 cache·compute 계층에서 시작해 custom PHY와 base-die controller를 거쳐 HBM bank로 이동합니다. controller를 base die에 둔다고 해서 HBM이 XPU cache나 rack 전체의 coherent memory로 바뀌는 것은 아닙니다.

공급망과 NVLink Fusion

NVIDIA는 NVHBM base die를 leading memory providers와 설계·검증하고, 여러 memory provider가 공급할 수 있는 standard NVHBM implementation을 마련한다고 발표했습니다. 이 방식의 목적은 각 HBM supplier마다 custom XPU의 interface와 qualification을 처음부터 반복하는 부담을 줄이는 것입니다.

첫 협력 대상으로 발표된 곳은 Amazon의 Annapurna Labs입니다. NVIDIA 발표는 Annapurna Labs가 NVLink Fusion과 함께 차세대 Trainium, starting with Trainium4를 지원한다고 설명하지만, Trainium4가 NVHBM을 탑재한 양산 제품으로 확정되었다고 발표한 것은 아닙니다. 현재 확인 가능한 범위는 향후 AWS infrastructure를 위한 협력입니다.

비교/분석

아래 수치는 NVHBM에 대한 NVIDIA 공개 자료와 기존 HBM 문서의 구조를 비교한 것입니다. NVHBM의 절대 사양이 공개되지 않았으므로 수치가 없는 항목은 미공개로 남겨야 합니다.

항목	일반적인 standard HBM4E 구현	NVHBM	설계 의미
기술 성격	HBM 세대·제품 구현	NVIDIA custom HBM base-die architecture	NVHBM은 JEDEC 세대명이 아님
memory controller 위치	XPU compute die 측	HBM base die에 NVIDIA custom controller	XPU die에서 memory control 회로를 분리
PHY	넓은 HBM interface 중심	custom PHY와 효율적인 interface connection	exact lane 수·신호 방식은 미공개
DRAM stack	TSV 기반 HBM stack	HBM stack과 custom base die의 조합	DRAM cell density·stack height는 공개되지 않음
stack당 대역폭	비교 기준	최대 30% 증가 주장	standard HBM4E 대비 상대값, 독립 측정 아님
HBM power	비교 기준	최대 15% 감소 주장	HBM subsystem 기준이며 XPU 전체 전력과 다름
XPU compute die area	memory controller·PHY 면적 포함	최대 25% 추가 compute die area 주장	발표문 기준. main-die 30% 서술과 지표를 혼동하지 않음
PHY·support area	비교 기준	최대 67% 감소 주장	NVIDIA Technical Blog 기준
interposer layout	넓은 배선·면적 요구	usable silicon 최대 80% 증가 주장	전체 layout 지표이며 XPU compute area와 동일하지 않음
absolute interface width	HBM4E 구현별 상이	미공개	2048-bit 또는 특정 serialization을 가정하면 안 됨
capacity·latency·stack height	제품별 공개 사양	미공개	NVHBM 이름만으로 HBM 용량·지연을 계산할 수 없음
공급 방식	DRAM vendor별 HBM qualification	여러 memory provider 검증 목표	custom XPU의 supplier qualification 부담 완화
시스템 연결	XPU의 HBM controller와 package fabric	NVHBM은 local memory, NVLink Fusion은 별도 scale-up	두 기술을 하나의 interface로 오해하면 안 됨
공개 상태	HBM4E 제품·공급 생태계 존재	2026년 8월 발표·협력/roadmap 단계	NVHBM의 상용 제품 수치와 출시 일정은 미공개

공개 수치의 해석

NVIDIA의 최대 30% bandwidth 증가는 per stack 비교입니다. 예를 들어 어떤 HBM4E 기준이 4 TB/s라고 가정하면 다음과 같이 약 5.2 TB/s가 계산되지만, 이는 NVHBM의 공개 사양이 아닙니다.

예시 bandwidth = 기준 HBM4E bandwidth × (1 + 0.30)
               = 4.0 TB/s × 1.30
               = 5.2 TB/s

실제 유효 대역폭은 pin rate와 interface width 외에도 command overhead, controller scheduling, refresh, ECC·RAS, PHY efficiency, memory access pattern, thermal throttling에 의해 결정됩니다. 따라서 NVHBM의 절대 대역폭은 공식 speed bin과 제품 datasheet가 공개된 뒤에 계산해야 합니다.

Area 수치도 같은 기준으로 더하면 안 됩니다. NVIDIA corporate announcement와 Technical Blog의 표는 XPU compute die area 최대 25%를 제시하지만, Technical Blog 본문에는 main-die silicon 최대 30%라는 다른 표현도 있습니다. compute die area, main-die silicon, PHY·support area, usable silicon across the layout은 측정 범위가 다를 수 있으므로 각각 별도의 지표로 기록해야 합니다.

동작 원리

패키지 수준 데이터 경로

그림 3. NVHBM은 local HBM 경로의 interface boundary를 바꾸고, NVLink Fusion은 XPU를 rack-scale fabric에 연결합니다. 두 경로의 성능·전력·열 수치는 함께 측정해야 하지만 하나의 link로 합쳐지는 것은 아닙니다.

Compute와 cache: matrix engine, vector unit, on-chip cache가 model weight, activation, KV cache 데이터를 요구합니다. 메모리 요청의 최종 주소와 우선순위 정책은 XPU architecture와 workload에 좌우됩니다.
XPU-side custom interface: XPU에는 NVHBM과 연결되는 custom PHY 또는 관련 interface IP가 필요합니다. NVIDIA는 interface footprint가 작아진다고 설명하지만, 고객 설계에 배치되는 세부 PHY block의 범위는 공개하지 않았습니다.
Package routing: XPU와 HBM stack은 advanced package 및 interposer 경로로 연결됩니다. interface가 차지하는 면적이 줄면 interposer trace routing과 XPU die edge에 여유가 생길 수 있지만, 실제 개선폭은 stack 배치와 package rule에 따라 달라집니다.
Base-die controller: NVHBM base die의 NVIDIA custom memory controller가 명령을 HBM 내부 동작으로 변환합니다. controller의 channel organization, scheduler 정책, refresh·ECC 경계는 공개 자료에 포함되어 있지 않습니다.
HBM 내부 동작: DRAM die는 TSV·micro-bump와 내부 logic path를 통해 연결되고, 선택된 bank에서 row activate, column read/write, precharge와 refresh를 수행합니다. NVHBM이라는 이름만으로 기존 HBM의 DRAM array 동작이 변경된다고 볼 근거는 없습니다.
데이터 반환: 읽은 데이터는 base die와 custom interface를 지나 XPU cache 또는 compute engine으로 반환됩니다. 실제 latency와 sustained bandwidth는 interface training, queue depth, memory-level parallelism, thermal state를 포함해 검증해야 합니다.

전력과 대역폭 효과

대역폭 증가는 단순히 DRAM cell의 동작 속도를 높이는 것만을 뜻하지 않습니다. controller와 PHY를 stack 중심으로 재배치하면 XPU-side routing, support circuit, interface loading을 줄이고, 같은 package·power budget 안에서 더 많은 유효 데이터 전송을 제공할 여지가 있습니다. NVIDIA는 이 결과를 standard HBM4E 대비 최대 30% bandwidth와 15% HBM power 개선으로 제시합니다.

그러나 HBM power 15% 감소는 HBM subsystem의 상대 지표입니다. XPU compute die가 더 많은 matrix engine이나 cache를 사용하면 package total power와 thermal density는 오히려 증가할 수 있습니다. 또한 memory-bound workload에서는 bandwidth 이득이 throughput으로 이어질 가능성이 크지만, compute-bound workload에서는 성능 향상이 작을 수 있습니다.

Area 재배치와 interposer

기존 HBM에서 XPU die perimeter와 interposer는 memory controller, wide PHY, power·clock·signal routing을 함께 수용해야 합니다. NVHBM은 controller를 HBM base die에 두고 custom PHY를 사용해 다음과 같은 재배치를 노립니다.

XPU 중앙 영역에 더 많은 compute logic, cache 또는 workload-specific 기능을 배치
HBM stack과 XPU 사이 interposer trace의 혼잡과 routing blockage 완화
같은 package footprint에서 XPU compute die 또는 다른 I/O block의 설계 여유 확보
여러 memory provider의 검증된 base-die 조합을 사용해 custom XPU의 qualification 기간 단축

이 효과는 controller logic이 공짜로 사라지는 것이 아니라 HBM base die, stack assembly, package, 전력·열 경계로 이동하는 것입니다. Base die 면적, HBM stack 열, package test, vendor qualification 비용은 여전히 시스템 설계의 일부입니다.

신뢰성·열·검증 경로

HBM은 얇은 DRAM die의 TSV stack과 고밀도 package를 사용하므로, controller 이동만으로 신뢰성 문제가 해결되지 않습니다. NVHBM을 실제 제품에 적용하려면 최소한 다음 항목을 함께 검증해야 합니다.

Signal integrity: custom PHY의 eye margin, crosstalk, package trace loss, clock·data alignment
Power integrity: HBM과 XPU 전원 rail, simultaneous switching noise, IR drop, transient current
Thermal: DRAM stack과 base die의 온도, XPU hot spot, heat spreader·cooling 조건, sustained bandwidth에서의 throttling
RAS: on-die ECC, system ECC, error reporting, scrub·refresh 정책과 controller의 책임 경계
Manufacturing: known-good stack/base die 선별, micro-bump·TSV continuity, package warpage, burn-in, failure analysis
Qualification: 여러 memory provider의 동일 interface 동작, firmware·driver 초기화, workload별 성능 재현성

NVIDIA가 여러 memory provider와 NVHBM을 검증한다고 밝힌 것은 공급망 선택지를 넓히려는 장점입니다. 반대로 provider별 DRAM process, stack height, thermal profile, test flow가 달라지면 동일한 custom base die라도 제품 특성의 일관성을 별도로 입증해야 합니다.

장단점

장점

XPU 면적 재배치: memory controller와 support interface를 HBM base die 쪽으로 옮겨 compute die에 더 많은 기능을 넣을 여지가 있습니다.
대역폭 잠재력: NVIDIA 발표 기준 standard HBM4E 대비 stack당 memory bandwidth 최대 30%를 목표로 합니다.
전력 여유: HBM power 최대 15% 감소 주장은 같은 XPU power envelope에서 sustained compute 또는 냉각 여유로 전환될 수 있습니다.
패키지 배선 완화: custom PHY와 더 효율적인 interface로 XPU die edge와 interposer layout의 제약을 줄일 수 있습니다.
공급망 선택: leading memory providers와 검증된 implementation을 여러 업체에서 제공하는 방향은 custom XPU의 supplier qualification을 단순화할 수 있습니다.
AI workload 적합성: model weight, activation, KV cache를 반복적으로 읽는 memory-bound training·inference에서 bandwidth와 power 개선의 가치가 큽니다.

단점과 위험

절대 사양 불확실성: interface width, pin rate, capacity, latency, stack height, protocol이 미공개라 제품 간 직접 비교가 어렵습니다.
기술 종속성: XPU memory controller를 독립 구현하는 대신 NVIDIA custom base die·PHY와 integration rule에 의존하게 됩니다.
검증 복잡도 이동: controller를 base die로 옮겨도 PHY, package, HBM stack, firmware 초기화와 thermal qualification이 필요합니다.
열 경계의 집중: base die에 controller를 추가하면 stack 하부의 전력 밀도와 interposer 방향 열 경로를 다시 분석해야 합니다.
수율·수리성 문제: HBM stack과 custom base die의 결함은 package 조립 이후 발견·교체가 어렵고, known-good 선별 비용을 높일 수 있습니다.
벤더 주장 의존: 최대 30%, 15%, 25%와 area 관련 수치는 NVIDIA 공개 상대 비교이며, workload·제품·시험 조건이 공개된 독립 benchmark가 아닙니다.
HBM capacity 해결 아님: controller·PHY 재배치는 DRAM cell density, stack height, HBM package의 물리적 용량 한계를 자동으로 높이지 않습니다.
NVLink와 혼동 가능: NVHBM이 package-local HBM 경로를 개선해도, XPU 간 통신 latency와 rack-scale bandwidth는 NVLink Fusion 및 별도 fabric 설계의 문제입니다.

적용 판단

우선순위	확인할 질문	검증 지표
메모리 병목	XPU가 HBM bandwidth 부족으로 stall하는가?	achieved bandwidth, memory stall, XPU utilization, tokens/s
die area	추가된 compute area가 실제 성능으로 전환되는가?	PHY·controller area, compute density, cache/matrix engine area
전력·열	HBM 절감이 total package budget에 남는가?	HBM power, package power, junction temperature, throttling
package	좁은 interface가 실제 배선·조립을 단순화하는가?	interposer congestion, trace length, SI margin, package yield
공급망	여러 memory provider에서 동일하게 동작하는가?	qualification time, first-pass yield, vendor-to-vendor variance
신뢰성	controller·PHY 이동 후 RAS 경계가 명확한가?	ECC coverage, error reporting, scrub/refresh behavior, burn-in
소프트웨어	custom controller가 초기화·firmware 부담을 늘리지 않는가?	boot training, firmware complexity, driver changes, recovery path

NVHBM은 HBM의 용량을 단순히 늘리는 선택보다, controller·PHY·package area를 어디에 둘 것인가에 대한 시스템 설계 선택입니다. 따라서 memory-bound AI accelerator에서는 유력한 방향이지만, compute die 면적 확보만으로 제품 성능이 보장되지는 않습니다. 공개된 상대 수치와 실제 제품의 sustained workload 결과를 분리해 평가하고, NVLink Fusion의 rack-scale 이점과 local NVHBM 이점을 중복 계산하지 않아야 합니다.

핵심 정리

NVHBM은 NVIDIA custom memory controller를 HBM 3D stack의 base die로 옮기고 custom PHY와 interface를 함께 재설계하는 package-level HBM architecture입니다. NVIDIA는 standard HBM4E 대비 stack당 bandwidth 최대 30%, HBM power 최대 15%, XPU compute die area 최대 25% 개선을 제시했지만, 절대 interface·capacity·latency 사양과 독립 benchmark는 아직 공개하지 않았습니다. controller 이동은 HBM을 새로운 JEDEC 세대나 coherent rack memory로 만드는 것이 아니라, XPU와 local HBM 사이의 면적·전력·검증 경계를 재배치하는 변화입니다. 실제 가치는 memory-bound workload와 package 제약에서 확인되며, thermal·SI/PI·RAS·수율·여러 memory provider qualification을 포함한 system-level 검증이 필요합니다.