HBM

HBM은 AI 인프라 글에서 자주 보이는 반도체 용어지만, 단순히 “비싼 메모리”라고만 이해하면 핵심을 놓치기 쉽다. AI 모델을 실제 서비스로 돌릴 때는 계산 칩이 빠른 것만으로 부족하고, 모델이 계속 읽고 써야 하는 데이터를 충분히 빠르게 공급할 메모리가 필요하다. HBM은 바로 그 병목을 줄이기 위해 쓰이는 고대역폭 메모리다.

한 줄로 말하면

HBM은 GPU·AI accelerator 옆에 매우 넓은 통로로 붙는 고성능 메모리로, 큰 AI 모델을 빠르게 실행할 때 데이터가 칩 안팎으로 이동하는 병목을 줄여준다.

비유로 이해하기

AI accelerator를 아주 빠른 주방이라고 생각해보자. 요리사와 조리기구가 아무리 빨라도, 재료 창고에서 재료가 한 줄 통로로 천천히 들어오면 주문을 빨리 처리할 수 없다. HBM은 이 주방 바로 옆에 넓고 가까운 재료 창고를 붙여, 많은 재료가 동시에 들어오게 하는 장치에 가깝다.

다만 이 비유에는 한계가 있다. 실제 HBM은 물리적 창고가 아니라 DRAM 칩을 수직으로 쌓고, AI accelerator와 매우 넓은 데이터 통로로 연결한 메모리 패키지다. 중요한 것은 “저장 용량이 크다”만이 아니라, 정해진 시간 안에 얼마나 많은 데이터를 주고받을 수 있는가, 즉 bandwidth다.

정확한 정의

HBM은 High Bandwidth Memory의 약자다. 여러 DRAM die를 수직으로 쌓고, GPU나 AI accelerator 가까이에 배치해 넓은 인터페이스로 연결하는 고성능 메모리 방식이다. 일반 서버 메모리보다 물리적으로 더 가깝고 데이터 통로가 넓기 때문에, 같은 시간에 더 많은 데이터를 칩으로 공급할 수 있다.

AI 모델 실행에서는 파라미터, 중간 activation, attention 계산에 필요한 KV cache 같은 데이터가 계속 이동한다. 이때 연산 장치가 기다리지 않으려면 메모리가 충분한 bandwidth와 capacity를 제공해야 한다. 그래서 HBM은 LLM inference serving에서 latency, throughput, cost per token을 바꾸는 중요한 요소가 된다.

왜 중요한가

1. AI 병목은 FLOPS만으로 해결되지 않는다

AI 칩 성능을 볼 때 흔히 초당 연산량, 즉 FLOPS를 먼저 본다. 하지만 큰 모델을 실제로 서비스하면 연산 장치가 데이터를 기다리는 시간이 중요해진다. HBM bandwidth가 부족하면 계산 칩이 빠르더라도 모델 파라미터와 cache를 제때 읽지 못해 실제 처리량이 제한될 수 있다.

그래서 AI 인프라 경쟁은 “가장 빠른 칩”만의 경쟁이 아니다. 메모리 bandwidth, chip 간 interconnect, software scheduler, 전력·냉각, rack density가 함께 맞아야 한다.

2. Inference 비용 구조와 직접 연결된다

LLM inference serving에서는 학습이 끝난 모델을 사용자 요청마다 계속 실행한다. 긴 context를 처리하거나 많은 요청을 동시에 처리하면 KV cache가 커지고, 이 cache를 어디에 어떻게 보관하고 읽을지가 비용과 지연시간을 바꾼다.

HBM은 빠르지만 비싸고 공급도 제한될 수 있다. 따라서 HBM을 많이 붙이면 성능은 좋아질 수 있지만, 칩·패키징·전력·공급망 비용도 함께 올라간다. 결국 중요한 질문은 “HBM이 있느냐”가 아니라 “특정 workload에서 HBM capacity와 bandwidth가 비용 대비 충분한가”다.

3. AI capex cycle의 공급망 병목이 된다

AI capex cycle에서는 AI 수요가 데이터센터, 칩, 전력, 냉각, 네트워크, 장비 투자로 번진다. 이때 HBM은 고성능 AI accelerator의 핵심 부품이기 때문에 공급망 병목으로 자주 등장한다.

AI 기업이나 hyperscaler가 더 많은 compute capacity를 원해도, GPU/accelerator 패키지에 들어가는 HBM과 advanced packaging capacity가 부족하면 실제 장비 출하가 늦어질 수 있다. 그래서 HBM은 반도체 회사의 부품 이야기를 넘어, 데이터센터 투자 일정과 AI 인프라 수익성에도 영향을 준다.

실제 예시

LLM inference serving

긴 문서를 넣고 답을 생성하는 LLM 서비스를 생각해보자. 처음에는 긴 prompt를 읽는 prefill 단계가 있고, 그 뒤에는 token을 하나씩 생성하는 decode 단계가 이어진다. 이 과정에서 이전 token들의 key/value 표현을 저장한 KV cache를 계속 읽고 써야 한다.

동시 사용자가 많아지고 context가 길어질수록 KV cache는 커진다. 이때 HBM capacity가 부족하면 요청을 많이 묶기 어렵고, HBM bandwidth가 부족하면 token 생성이 느려질 수 있다. 그래서 LLM inference 비용을 볼 때는 model 크기뿐 아니라 HBM, memory bandwidth, interconnect, scheduler를 함께 봐야 한다.

Rack-scale inference system

Etched의 rack-scale inference system 인터뷰는 단일 칩 성능보다 rack 단위 memory와 interconnect를 강조했다. 인터뷰의 주장을 검증된 성능으로 받아들이면 안 되지만, 왜 회사들이 HBM과 memory topology를 이야기하는지는 보여준다. Inference 경쟁이 칩 하나의 benchmark를 넘어, 여러 칩이 메모리를 어떻게 공유하고 데이터를 얼마나 낮은 지연으로 주고받는지의 문제로 넓어지고 있기 때문이다.

헷갈리지 말아야 할 점

• HBM은 저장장치 SSD가 아니다. 모델 실행 중 데이터를 빠르게 공급하는 DRAM 계열 메모리이며, 영구 저장소가 아니다.
• HBM 용량만 크면 충분한 것이 아니다. Capacity와 bandwidth, 전력, 패키징, chip 간 통신, software scheduler가 함께 맞아야 한다.
• HBM이 많다고 모든 모델이 자동으로 싸게 돌아가지는 않는다. Workload가 memory-bound인지 compute-bound인지, prefill과 decode 중 어디가 병목인지에 따라 효과가 다르다.
• HBM은 AI capex의 한 부품일 뿐이다. 전력, 냉각, networking, rack 설계, 고객 수요가 맞지 않으면 HBM 공급만으로 수익성이 결정되지 않는다.
• 회사 발표에서 HBM을 강조한다고 해서 성능이 검증된 것은 아니다. 독립 benchmark, 실제 고객 workload, 전력·비용 데이터를 함께 봐야 한다.

관련 문서

• LLM inference serving
• Cost per token
• AI capex cycle
• Etched의 rack-scale inference system 인터뷰
• AI agent runtime과 AI capex cycle의 차이

출처

• NVIDIA Blog — Inference software and lowest token cost
• Bloomberg Technology — Etched rack-scale inference interview