NVIDIA는 맞춤형 가속기 개발사가 직접 설계하던 메모리 시스템의 일부를 HBM 스택 안으로 옮겼습니다. NVHBM에서는 NVIDIA의 자체 메모리 컨트롤러가 XPU 계산 다이가 아니라 HBM 베이스 다이에 들어가고, 두 다이는 자체 물리 인터페이스(PHY)로 연결됩니다. NVIDIA는 일반적인 HBM4E 구현과 비교해 스택당 대역폭을 최대 30% 높이고 HBM 전력을 최대 15% 낮추며, XPU 계산 다이에서 최대 25%의 면적을 다른 용도로 쓸 수 있다고 설명합니다[1][2]. 세 수치는 서로 더할 수 있는 성능 향상 폭이 아니며, 특히 25%는 애플리케이션 처리량이 25% 높아진다는 뜻이 아닙니다.
이번 발표에는 서로 다른 제품 세 가지가 함께 등장합니다. NVHBM은 메모리 구조이고, NVLink Fusion은 맞춤형 XPU를 NVIDIA의 랙 규모 패브릭에 연결할 칩렛과 링크를 제공하며, MediaTek은 이를 묶어 사전 검증된 설계·제조 경로로 공급합니다[3][5]. Amazon의 Annapurna Labs는 처음 공개된 NVHBM 협력사지만, 발표문은 향후 Trainium 설계를 위한 협력을 설명할 뿐 NVHBM을 적용한 Trainium4의 양산 구성을 공개하지 않았습니다[2][4]. 지금 판단할 대상은 벤치마크 결과가 아니라 컨트롤러 설계와 HBM 검증을 누가 맡고, 맞춤형 XPU 개발사가 어디에 차별화된 회로를 남길 수 있는가입니다.
값비싼 계산 다이를 차지하는 메모리 회로
HBM은 여러 장의 DRAM 다이를 쌓아 가속기 옆에 배치하고 인터포저 같은 첨단 패키지 배선으로 연결합니다. 짧고 넓은 경로에서 보드 수준 메모리보다 높은 대역폭을 얻지만, DRAM 스택만으로 메모리 시스템이 완성되지는 않습니다. XPU에는 요청을 배치하고 상태와 순서를 관리하며 오류 정책을 적용할 메모리 컨트롤러가 필요합니다. 컨트롤러의 트랜잭션을 전기 신호로 바꾸는 PHY도 계산 다이 가장자리에 놓입니다. 행렬·벡터 연산을 하지 않는 회로가 가장 비싼 선단 공정 면적을 사용하는 셈입니다.
다이 가장자리의 면적은 같은 크기의 빈 공간보다 제약이 많습니다. PHY는 범프와 인터포저 배선 위치에 맞아야 하고, 넓고 규칙적인 인터페이스 블록까지 전력과 클록을 전달해야 합니다. 큰 고정 블록이 자리를 차지하면 네트워크, 캐시, 연산 회로의 배치도 함께 달라집니다. 따라서 인터페이스 면적을 줄여 얻는 이점은 단순한 제곱밀리미터 합보다 클 수 있습니다. 다만 NVIDIA가 실제 XPU 배치도를 공개하지 않았으므로, 배치 자유도가 얼마나 늘어나는지는 아직 설계상 가능성으로 봐야 합니다.
HBM 아래의 베이스 다이는 원래부터 단순한 받침이 아닙니다. 위쪽 DRAM 다이에서 내려오는 실리콘 관통 전극(TSV)을 종단하고 패키지 쪽 인터페이스를 제공합니다. NVHBM은 여기에 NVIDIA의 자체 메모리 컨트롤러를 통합해 베이스 다이의 역할을 넓힙니다[1][2]. HBM 스택은 표준 메모리 종단점에 머물지 않고, 이전에는 가속기 개발사가 계산 다이에 넣던 제어 로직까지 포함합니다. XPU에는 이 스택과 연결할 더 작은 자체 PHY가 남습니다.
이동하는 컨트롤러와 남아 있는 메모리 기능
“컨트롤러를 HBM으로 옮긴다”는 표현만 보면 XPU에서 메모리 시스템 전체가 사라지는 것으로 오해하기 쉽습니다. 공개된 범위는 그보다 좁습니다. NVIDIA는 자체 컨트롤러를 맞춤형 HBM 베이스 다이에 통합하고 자체 PHY와 조합한다고 밝혔지만, 레지스터 인터페이스, 명령 프로토콜, 캐시 일관성, 오류 보고, 메모리 훈련 기능을 XPU와 스택 사이에서 어떻게 나누는지는 공개하지 않았습니다[1][3]. XPU는 여전히 메모리 요청을 만들고 프로그래밍 모델에 필요한 순서를 지키며, 장애 정보를 펌웨어와 장비 관리 계층에 전달해야 합니다. DRAM 컨트롤러가 이동하더라도 계산 다이 쪽에 남을 제어 기능이 있습니다.
물리적인 이동 거리도 없어지지 않습니다. 요청은 인터페이스와 인터포저 배선, 마이크로범프를 지나 베이스 다이에 도달하고, 이후 스택의 수직 배선을 통과합니다. NVHBM은 프로세싱 인 메모리(PIM)가 아니며 DRAM 배열 옆에서 텐서 연산을 수행하지 않습니다. 계산 다이의 인터페이스 면적과 전력을 줄이는 대신 메모리 스택이 더 많은 제어 책임을 맡도록 연결 구조를 다시 설계하는 기술입니다.
이 구조는 서로 다른 공정을 함께 최적화해야 합니다. 계산 다이는 빠르고 조밀한 연산 로직에 맞추지만, HBM 베이스 다이는 제어 로직과 TSV, 배선, 열, 메모리 공급사의 제조 공정을 함께 만족해야 합니다. 컨트롤러를 옮기면 비싼 XPU 면적을 아낄 수 있지만 베이스 다이의 크기와 복잡도가 커질 수 있고, 수율·검사 범위·수리 방식이 패키지 비용에 더 큰 영향을 줍니다. NVIDIA는 베이스 다이 면적과 공정, 여분 회로, 양품 다이 선별 방법을 공개하지 않았으므로 현재 자료만으로 패키지 원가를 계산할 수는 없습니다.
서로 다른 기준으로 제시된 네 가지 수치
가장 구체적인 수치는 PHY와 지원 회로의 면적을 일반적인 HBM4E 구현보다 최대 67% 줄인다는 주장입니다[1]. 이 비율의 분모는 XPU 전체가 아니라 인터페이스 블록입니다. 가장자리 회로의 3분의 2를 줄였다고 해서 모든 가속기 다이가 같은 비율로 작아지는 것은 아닙니다. HBM 스택 수, 스택마다 필요한 가장자리 길이, 되찾은 공간에 연산·SRAM·네트워크 블록을 실제로 배치할 수 있는지가 결과를 정합니다.
두 번째 수치는 XPU 계산 다이에서 다른 기능에 쓸 수 있는 면적이 최대 25% 늘어난다는 것입니다[1][2]. 이 부분은 NVIDIA의 공식 기술 글 안에서도 표현이 일치하지 않습니다. 비교 표에는 25%가 적혀 있지만 뒤쪽 본문에는 사용할 수 있는 주 다이 면적이 최대 30% 늘어난다고 설명합니다. 회사 발표문은 다시 25%를 사용합니다. 본지는 더 일관되게 반복된 25%를 기준으로 삼고 차이를 숨기지 않았습니다. 여기서 “사용 가능한 면적”은 다이가 25% 작아지거나 연산기가 25% 늘어나거나 원가가 25% 줄어든다는 뜻이 아닙니다. 연산, 캐시, I/O, 여분 회로 가운데 어디에 쓰느냐에 따라 성능과 수율이 달라집니다.
세 번째는 일반적인 HBM4E보다 스택당 메모리 대역폭을 최대 30% 높인다는 주장입니다[1]. NVIDIA는 핀 속도, 버스 폭, 스택 용량, 읽기·쓰기 비율, 실제 전송 효율, 애플리케이션의 지속 대역폭을 공개하지 않았습니다. 메모리 대역폭에 묶인 커널이라면 같은 접근 패턴에서 수치가 재현될 때 이점을 얻을 수 있습니다. 연산이 병목인 커널에는 직접적인 효과가 없고, 집단 통신·호스트 I/O·스케줄링이 제한하는 작업은 해당 문제를 먼저 해결해야 합니다.
네 번째 수치인 최대 15% 전력 절감은 XPU 전체나 랙, 데이터센터가 아니라 HBM 전력을 기준으로 합니다[1][2]. NVIDIA는 2,000W XPU를 사용하는 1GW 데이터센터에서 이 절감분으로 최대 1만5,000개의 XPU를 더 운용할 여유가 생길 수 있다고 설명합니다[1]. 그러나 공개 자료에는 XPU 전력에서 HBM이 차지하는 비율, 평균 이용률, 냉각 오버헤드, 예비 전력, 전력 변환 손실이 제시되지 않았습니다. 데이터센터 설계자는 이 숫자를 회사가 제시한 시나리오로만 기록하고, 정해진 메모리 작업을 수행할 때 패키지 입력에서 측정한 전력으로 장비 수를 다시 계산해야 합니다.
NVIDIA는 대역폭과 면적, 전력 개선을 묶으면 XPU당 종단 간 성능이 30% 높아진다고 주장합니다[1]. 세 입력을 기계적으로 곱할 수는 없습니다. 되찾은 면적에 유효한 회로를 넣어야 처리량이 생기고, HBM 전력 절감은 패키지가 전력이나 열에 제한될 때 의미가 있으며, 대역폭은 메모리가 병목인 구간에서만 효과가 있습니다. 작업 부하와 비교 XPU, 전력 제한, 완료 작업의 정의가 없으므로 이 30%는 벤치마크가 아니라 설계 예상치입니다.
여러 메모리 공급사와 하나의 컨트롤러 설계
NVIDIA는 여러 메모리 공급사가 제공할 수 있는 공통 NVHBM 구현을 만들겠다고 밝혔습니다[2]. 이는 맞춤형 XPU 개발의 실제 부담을 줄일 수 있습니다. 최신 HBM을 적용하려면 컨트롤러, PHY, 패키지, 신호 무결성, 열, 검사, 공급사별 편차를 함께 검증해야 합니다. 여러 공급사와 미리 검증한 컨트롤러와 베이스 다이를 사용하면 공급원을 복수로 유지하면서도 각 메모리마다 별도 컨트롤러 경로를 개발할 필요가 줄어듭니다.
다만 공급사가 여러 곳이라는 사실이 개방형 메모리 인터페이스를 뜻하지는 않습니다. NVIDIA는 컨트롤러를 자체 설계했고 NVHBM을 NVLink Fusion의 구성 요소로 설명합니다. 구현 가능한 인터페이스 규격, 라이선스 조건, 공급사 간 호환 보장, 프로그램 밖의 메모리 공급사를 검증하는 절차는 아직 공개하지 않았습니다[1][3]. 메모리 제조사는 여러 곳으로 넓히면서 컨트롤러 구조와 검증 방법은 NVIDIA에 모으는 방식입니다. 개발 기간과 랙 통합을 우선하는 팀에는 타당한 선택일 수 있지만, JEDEC 부품을 바로 바꾸어 끼우는 것과 같은 조건으로 평가해서는 안 됩니다.
양산 장애를 분석할 때 이 차이가 드러납니다. 검증에서 탈락한 원인은 DRAM, 베이스 다이의 컨트롤러, 자체 PHY, 인터포저 배선, 패키지 조립, XPU 펌웨어 가운데 어느 곳에나 있을 수 있습니다. 생산 계약에는 진단 책임, 인터페이스를 넘어 전달되는 오류 정보, 다른 공급사의 스택을 XPU 마스크 변경 없이 대체할 수 있는지를 명시해야 합니다. 세부 조건이 공개되기 전까지 “여러 공급사”는 공급 안정성을 높이려는 계획이지 현장에서 호환된다는 증거는 아닙니다.
AWS의 참여가 입증한 범위
Amazon의 Annapurna Labs는 NVIDIA와 NVHBM을 개발하는 첫 공개 협력사입니다. AWS와 NVIDIA의 공동 발표는 Trainium이 더 빠르고 전력 효율이 높은 메모리를 사용할 수 있으며, NVLink Fusion으로 Trainium과 NVIDIA GPU를 같은 랙 규모 구조에 연결할 수 있다고 설명합니다[4]. 문장은 미래 계획을 다룹니다. Trainium4의 테이프아웃에 NVHBM이 들어갔다거나 스택 수와 용량, 공급 시점, 벤치마크가 정해졌다는 뜻은 아닙니다.
그래도 Annapurna Labs의 참여는 중요합니다. 이미 맞춤형 가속기와 클라우드 운영 환경을 보유한 회사가 NVHBM이 해결하려는 통합 문제를 인정했다는 뜻이기 때문입니다. 다만 협력 의향을 앞서 제시한 네 수치의 독립 검증으로 볼 수는 없습니다. 발표는 AWS와 NVIDIA가 공동으로 냈고, 공개 시점에 NVHBM을 적용한 Trainium 시스템을 외부에서 측정할 수 없었습니다.
MediaTek의 8월 31일 발표는 설계부터 양산까지 이어지는 경로를 추가했습니다. MediaTek은 NVLink Fusion 칩렛, NVLink-C2C, NVHBM과 패키지·제조·랙 검증을 묶어 고객의 XPU 설계 기반으로 제공할 계획입니다[5]. 고객은 작업 부하에 맞춘 연산 로직에 집중하고 주변 시스템 통합의 상당 부분을 구매할 수 있습니다. 개발 기간을 줄이는 대신 메모리, 패키지, 패브릭 인터페이스가 하나의 플랫폼 선택으로 묶입니다.
NVHBM을 단순한 협력 소식이 아니라 메모리 구조의 변화로 봐야 하는 이유가 여기에 있습니다. 베이스 다이의 컨트롤러는 아래쪽의 메모리 공급사 검증과 위쪽의 랙 호환성을 연결하는 장치입니다. 전기적 이점도 중요하지만, 맞춤형 XPU를 반도체 한 개가 아니라 반맞춤형 플랫폼 부품으로 바꾸는 역할이 더 큽니다.
설계 채택 전에 필요한 실측 자료
첫 검증은 조건을 맞춘 패키지 비교입니다. 계산 구조가 같은 XPU 시험 칩에 일반 HBM4E와 NVHBM을 각각 연결하고, 계산 다이 전체 면적과 컨트롤러·PHY 면적, 인터포저 면적, 패키지 수율, 동작 주파수를 공개해야 합니다. 되찾은 가장자리 공간에 연산이나 SRAM을 넣었을 때 타이밍·전력 공급·배선 문제가 생기지 않는지도 확인해야 합니다. 빈 면적의 합만으로는 설계 이점을 입증할 수 없습니다.
두 번째는 용량과 온도를 붙인 메모리 실험입니다. 접근 크기와 뱅크 동작, 읽기·쓰기 비율을 바꾸면서 지속 대역폭을 측정하고, 대기·부하 상태의 HBM 전력도 함께 제시해야 합니다. 스택 아래의 베이스 다이에 로직이 늘어나면 열이 발생하는 위치가 달라지므로 DRAM과 컨트롤러의 정상 상태 온도를 모두 확인해야 합니다. 운영 환경의 추론에서는 최대 대역폭뿐 아니라 꼬리 지연, 수정 오류 보고, 채널 열화 뒤의 동작도 중요합니다.
세 번째는 분모를 고정한 애플리케이션 시험입니다. 같은 모델과 정밀도, 배치 정책, 패키지 전력, 랙 냉각 한계에서 완료한 학습 단계나 서비스 지연 목표를 만족한 추론 토큰을 비교해야 합니다. 변경 전후에 로컬 HBM, 연산, NVLink 집단 통신, 스케일아웃 네트워크, 호스트 I/O 가운데 무엇이 병목이었는지도 기록해야 합니다. 로컬 메모리에 제한된 구간만 NVHBM 대역폭의 직접적인 효과로 볼 수 있습니다.
구매 단계에서는 검증된 메모리 공급사, 스택 용량, 공급 기간, 베이스 다이 소유권, 검사 책임, 라이선스, 현장 장애 처리, 대체 공급 규칙을 확인해야 합니다. 전기적 목표를 달성해도 컨트롤러 검증 경로가 한 곳뿐이거나 베이스 다이 수율이 낮아져 계산 다이의 면적 절감 효과를 상쇄하면 제품의 경제성은 달라집니다.
메모리 구조로 판매하는 시스템 통합
NVHBM에서 가장 중요한 변화는 제목에 쓰기 좋은 25%가 아닙니다. 메모리 컨트롤러를 클라우드 사업자의 차별화된 계산 다이에서 NVIDIA가 설계한 베이스 다이로 옮기고, 그 메모리를 랙 규모 통합 프로그램으로 제공한다는 점입니다. 고객은 실리콘 면적과 대역폭, 전력 여유, 짧아진 검증 기간을 얻을 수 있습니다. 대신 주 연산 다이가 다른 회사의 구조를 사용하더라도 NVIDIA가 가속기의 메모리와 패브릭에 참여하게 됩니다.
맞춤형 반도체 팀은 작업 부하를 직접 개선하지 않는 인터페이스 개발과 검증에 오랜 시간과 인력을 사용합니다. 검증된 메모리 경로가 이 자원을 연산, 캐시, 컴파일러, 서비스 동작에 돌려 준다면 충분한 가치가 있습니다. 그러나 줄어든 개발 기간과 면적은 컨트롤러 의존성, 패키지 수율, 공급사 간 실제 대체 가능성, 전력당 완료 작업과 함께 비교해야 합니다.
현재 내릴 수 있는 결론은 “연산 성능 25% 향상”보다 좁고 정확합니다. NVIDIA는 메모리 제어 로직을 어디에 만들고 누가 검증할지를 바꾸는 설득력 있는 구조를 공개했습니다. 다음 자료는 되찾은 면적이 유효한 회로로 바뀌는지, 인터페이스 전력 절감이 패키지 입력에서도 유지되는지, 여러 메모리 공급사가 하나의 운영 가능한 공급망처럼 동작하는지를 보여 줘야 합니다. 그전까지 NVHBM은 주목할 설계안이자 생태계 전략이며, 양산 제품의 성능 결과는 아닙니다.
출처와 저작권 안내
이 글은 TechTimes 보도를 계기로 Silicon & Systems가 작성한 독립 산업 분석입니다. 핵심 사실과 수치는 NVIDIA의 기술 공개, NVLink Fusion 아키텍처 페이지, NVIDIA와 AWS의 공동 발표, NVIDIA와 MediaTek의 공동 발표에서 다시 확인했습니다. 회사의 예상치는 양산 실리콘의 실측값과 구분했습니다. 원문의 문장·표·도판·사진·제품 렌더링은 재수록하지 않았습니다. 모든 도판은 이 글을 위해 새로 만들었고, 재질 도판은 실제 제품 사진이나 제조 도면이 아닌 개념적 표현에 결정론적 라벨을 합성했습니다. 원 자료의 저작권은 각 매체와 회사에 있습니다(2026).