쌓아 올린 메모리, 넓어진 통로
HBM(High Bandwidth Memory, 고대역폭 메모리)은 여러 개의 D램(DRAM) 다이를 위로 쌓고, 그 사이를 수천 개의 미세한 관통 전극으로 이어 붙여 한 번에 어마어마한 폭의 데이터를 주고받도록 만든 메모리다. 한 문장으로 줄이면, '층층이 쌓아 통로를 극단적으로 넓힌 D램'이다. 국제 반도체 표준화 기구인 JEDEC이 JESD235 규격으로 그 인터페이스와 동작을 정의했고(HBM3부터는 별도 표준 JESD238), 세대를 거듭하며 HBM2, HBM2E, HBM3, HBM3E로 발전해 왔다.
일반적인 컴퓨터 메모리인 DDR 계열과 비교하면 성격이 뚜렷이 다르다. 흔히 쓰는 D램은 좁은 통로로 아주 빠르게 데이터를 밀어내는 방식에 가깝다. 반면 HBM은 통로 자체를 압도적으로 넓혀 놓았다. 데이터 신호선(I/O)의 폭이 스택당 1024비트에 이르고, 전원·제어선을 더하면 수천 개의 미세 범프로 연결된다. 차선 두 개짜리 고속도로와 차선 수천 개짜리 대로를 떠올리면 감이 온다. 한 대가 얼마나 빨리 달리느냐보다, 한꺼번에 몇 대가 지나갈 수 있느냐가 HBM의 핵심이다.
이렇게 넓은 통로를 확보하려면 물리적으로 프로세서 바로 옆에 붙여야 한다. 그래서 HBM은 GPU나 AI 가속기와 같은 연산 칩과 함께 하나의 패키지 안에 실린다. 실리콘으로 만든 중간 배선판인 인터포저(interposer) 위에 연산 칩과 HBM 스택을 나란히 올리고, 그 위에서 수천 가닥의 배선으로 잇는다. 물리적 거리가 짧아야 넓은 통로를 낮은 전력으로 유지할 수 있기 때문이다. 이 점이 메인보드에 슬롯으로 꽂는 일반 메모리와 근본적으로 다른 지점이다.
왜 AI 반도체는 메모리에 목을 매는가
AI 반도체, 특히 대규모 언어모델(LLM, Large Language Model)을 돌리는 GPU와 가속기가 HBM을 요구하는 이유는 '메모리 장벽(memory wall)'이라는 오래된 숙제 때문이다. 지난 수십 년간 프로세서의 연산 속도는 눈부시게 빨라졌지만, 메모리에서 데이터를 실어 나르는 속도는 그만큼 따라오지 못했다. 그 격차가 점점 벌어지면서, 이제 계산 자체가 아니라 계산할 데이터를 제때 공급하지 못하는 것이 병목이 됐다.
이 문제는 딥러닝 연산의 성격 때문에 특히 심각하다. 트랜스포머(Transformer) 기반 모델은 거대한 가중치 행렬을 메모리에서 읽어와 곱셈과 덧셈을 반복한다. 모델이 커질수록 읽어야 할 가중치의 양이 폭발적으로 늘어난다. 수십억, 수천억 개의 파라미터를 담은 모델이라면 한 번의 추론에도 방대한 데이터를 메모리에서 연산 장치로 옮겨야 한다. 연산 장치가 아무리 빨라도 데이터가 도착하지 않으면 놀 수밖에 없다.
이런 상황을 '메모리 바운드(memory-bound)'라고 부른다. 연산 능력이 남아도는데도 메모리 대역폭이 부족해 전체 속도가 결정되는 상태다. 반대로 데이터 공급은 넉넉한데 계산량 자체가 많아 느린 경우는 '컴퓨트 바운드(compute-bound)'다. LLM 추론, 특히 토큰을 하나씩 만들어 내는 생성 단계는 전형적인 메모리 바운드 작업이다. 그래서 넓은 통로를 가진 HBM이 없으면 아무리 강력한 연산 코어를 얹어도 제 성능을 내지 못한다.
NVIDIA H100 같은 최신 AI 가속기가 HBM3를 채택한 것도 같은 맥락이다. 텐서 코어(Tensor Core)로 행렬 연산을 극한까지 밀어붙이려면, 그 코어에 데이터를 끊김 없이 부어 줄 메모리가 반드시 필요하다. HBM은 이 공급 라인을 감당하는 사실상의 표준 해법으로 자리 잡았다.
관통 전극과 스택, 대역폭이 만들어지는 원리
HBM이 넓은 통로를 얻는 비결은 크게 두 가지다. 첫째는 수직 적층이고, 둘째는 실리콘 관통 전극(TSV, Through-Silicon Via)이다. 여러 장의 D램 다이를 위로 쌓은 뒤, 각 다이를 관통하는 미세한 구멍을 뚫고 그 안을 금속으로 채워 위아래 층을 전기적으로 잇는다. 이렇게 하면 옆으로 길게 배선을 늘어놓지 않고도, 짧은 수직 경로로 수많은 신호선을 확보할 수 있다.
대역폭은 간단한 곱셈으로 이해할 수 있다. 대역폭은 대략 '통로의 폭(신호선 개수) × 신호선 하나가 초당 실어 나르는 양'으로 정해진다. HBM은 통로의 폭을 극단적으로 넓히는 전략을 택했다. 신호선 하나하나의 속도는 무리하게 올리지 않는다. 대신 개수를 압도적으로 늘려 총량을 키운다. 이 방식은 전력 효율에도 유리하다. 신호 하나를 아주 빠르게 흔들면 전력 소모와 발열이 급증하지만, 여러 개를 적당한 속도로 병렬 처리하면 같은 총 대역폭을 더 낮은 전력으로 얻을 수 있다.
여기에 물리적 근접성이 결정적으로 작용한다. HBM 스택을 GPU 다이 바로 옆, 같은 패키지 안에 두면 신호가 이동하는 거리가 매우 짧아진다. 거리가 짧으면 신호가 흐트러지기 전에 도착하므로, 넓은 통로를 안정적으로 유지할 수 있다. 만약 이 메모리를 메인보드 저편에 두고 긴 배선으로 이었다면, 수천 개의 신호선을 온전히 유지하는 것 자체가 불가능에 가깝다.
정리하면 HBM의 성능은 '쌓아서(적층) 짧게(TSV·근접 배치) 넓게(수천 신호선)'라는 세 축에서 나온다. 이 세 가지가 맞물려, 좁고 빠른 기존 메모리로는 도달할 수 없는 총 대역폭을 실현한다.
토큰 하나를 만들 때 메모리에서 벌어지는 일
LLM이 문장을 생성하는 과정을 따라가면 메모리 대역폭이 왜 중요한지 피부로 와닿는다. 언어모델은 입력 문장을 토큰(token)이라는 작은 단위로 쪼갠 뒤, 각 토큰을 숫자 벡터인 임베딩(embedding)으로 바꾼다. 그리고 트랜스포머 층을 통과시키며 다음에 올 토큰의 확률 분포를 계산한다. 어휘 사전 전체에 대해 '이 단어가 다음에 올 확률'을 매기고, 그중 하나를 골라 이어 붙인다.
핵심은 이 과정을 토큰 하나마다 반복한다는 점이다. 한 토큰을 만들 때마다 모델의 모든 가중치를 메모리에서 다시 읽어와야 한다. 100개 토큰짜리 답변을 생성한다면 방대한 가중치를 100번 훑는 셈이다. 여기서 계산량 자체는 크지 않은데, 데이터를 읽어오는 시간이 대부분을 차지한다. 그래서 생성 속도는 사실상 메모리 대역폭에 비례한다. HBM의 넓은 통로가 초당 몇 개의 토큰을 만들어 낼지를 좌우한다.
확률 분포에서 다음 토큰을 고르는 방식도 함께 알아 둘 만하다. 가장 확률이 높은 단어만 뽑으면(그리디 방식) 답변이 딱딱하고 반복적으로 흐른다. 그래서 디코딩 파라미터로 다양성을 조절한다. 대표적으로 온도(temperature)는 확률 분포를 얼마나 평탄하게 펼칠지를 정한다. 값이 낮으면 확신에 찬 단어에 몰리고, 높으면 덜 확실한 단어에도 기회를 준다. top-k는 확률 상위 k개 후보만 남기는 방식이고, top-p(뉴클리어스 샘플링)는 누적 확률이 일정 값에 이를 때까지의 후보만 대상으로 삼는다.
이 디코딩 파라미터는 메모리와 직접 관계는 없지만, 생성의 품질과 속도를 함께 다루는 실무에서 늘 붙어 다닌다. 아래 표에 주요 파라미터의 성격을 정리했다.
디코딩 파라미터 한눈에 보기
다음 토큰을 확률 분포에서 고를 때 쓰는 대표적인 조절 장치들이다. 실무에서는 보통 온도와 top-p를 함께 쓰고, 상황에 따라 조합을 바꾼다.
| 파라미터 | 하는 일 | 값을 높이면 | 주로 쓰는 상황 |
|---|---|---|---|
| temperature | 확률 분포의 평탄함 조절 | 다양·창의적, 대신 불안정 | 창작·브레인스토밍 |
| top-k | 상위 k개 후보만 남김 | 후보 폭이 넓어짐 | 다양성 확보 |
| top-p | 누적 확률 p까지만 남김 | 후보 폭이 넓어짐 | 균형 잡힌 생성 |
| greedy(값 0에 수렴) | 최고 확률만 선택 | — | 정답이 명확한 과제 |
정확한 답이 필요한 요약이나 코드 생성에서는 온도를 낮게 두어 안정성을 확보한다. 반대로 아이디어를 넓게 펼치고 싶으면 온도와 top-p를 함께 올린다. 다만 무작정 올리면 문장이 산으로 가므로, 과제 성격에 맞춰 조금씩 조정하는 감각이 중요하다.
KV 캐시, 메모리를 갉아먹는 숨은 주범
LLM 추론에서 HBM 용량과 대역폭을 실제로 가장 크게 잡아먹는 것은 의외로 모델 가중치만이 아니다. KV 캐시(Key-Value cache)라 부르는 중간 결과가 큰 비중을 차지한다. 트랜스포머의 자기어텐션(self-attention)은 이전에 만든 모든 토큰의 키(Key)와 값(Value) 벡터를 참조한다. 매번 다시 계산하면 낭비이므로, 한 번 계산한 키와 값을 메모리에 저장해 두고 재사용한다. 이 저장 공간이 KV 캐시다.
문제는 이 캐시가 문장이 길어질수록, 동시에 처리하는 요청이 많아질수록 무섭게 불어난다는 데 있다. 긴 대화, 긴 문서 요약을 다루면 KV 캐시만으로 HBM이 가득 차기도 한다. 게다가 요청마다 얼마나 긴 답변이 나올지 미리 알 수 없어, 메모리를 넉넉히 잡아 두면 그만큼 낭비가 생긴다. 예약해 둔 공간을 다 쓰지 못하고 놀리는 파편화 문제가 서빙 효율을 갉아먹는다.
이 문제를 정면으로 다룬 대표적 연구가 PagedAttention을 제안한 vLLM이다. 운영체제가 메모리를 작은 페이지 단위로 쪼개 관리하듯, KV 캐시도 작은 블록으로 나눠 필요할 때 동적으로 할당하는 발상이다. 큰 덩어리를 미리 통째로 예약하지 않으니 파편화가 크게 줄고, 같은 HBM으로 훨씬 많은 요청을 동시에 처리할 수 있다. 서빙 처리량이 눈에 띄게 올라간다.
결국 AI 반도체의 성능은 HBM이라는 하드웨어와, 그 위에서 메모리를 얼마나 알뜰하게 굴리느냐 하는 소프트웨어가 함께 결정한다. 하드웨어만 좋다고 되는 것도, 알고리즘만 영리하다고 되는 것도 아니다.
FlashAttention이 보여 준 메모리 계층의 진실
HBM은 GPU 안에서 가장 넓은 통로를 가진 메모리이지만, 그렇다고 가장 빠른 저장 공간은 아니다. GPU 내부에는 연산 코어에 훨씬 가까운 작고 빠른 메모리, 이른바 온칩 SRAM이 있다. 계층으로 보면 연산 코어와 가까울수록 빠르고 작으며, 멀수록 크고 상대적으로 느리다. HBM은 용량이 크고 대역폭이 넓지만, 온칩 메모리에 비하면 접근 지연이 크다.
FlashAttention은 바로 이 계층 구조를 파고든 기법이다. 기존 어텐션 계산은 거대한 중간 행렬을 HBM에 통째로 썼다가 다시 읽어오는 과정을 반복했다. 이 왕복이 어텐션 연산의 진짜 병목이었다. FlashAttention은 계산을 작은 조각으로 나눠 온칩의 빠른 메모리 안에서 처리하고, HBM으로 오가는 데이터 왕복을 최소화한다. 그러면서도 근사가 아닌 정확한 어텐션 결과를 낸다.
이 사례가 던지는 교훈은 분명하다. HBM 대역폭이 아무리 넓어도, 그 통로를 불필요하게 자주 오가면 성능을 다 까먹는다. 진짜 최적화는 대역폭을 늘리는 것만이 아니라, 애초에 그 통로를 덜 쓰도록 알고리즘을 짜는 데 있다. HBM을 이해한다는 것은 이런 메모리 계층 전체를 함께 이해한다는 뜻이다.
현장에서 HBM 용량을 다루는 법
실무에서 AI 반도체를 다룰 때 가장 먼저 부딪히는 벽은 HBM 용량이다. 모델을 GPU에 올리려면 가중치와 KV 캐시, 그리고 각종 중간 버퍼가 모두 HBM 안에 들어가야 한다. 큰 모델일수록 이 용량이 부족해지기 쉽다. 그래서 엔지니어들은 여러 기법을 동원한다.
가장 널리 쓰는 방법이 양자화(quantization)다. 가중치를 32비트나 16비트 부동소수점 대신 8비트, 4비트 정수 같은 낮은 정밀도로 표현해 용량을 줄인다. 정밀도를 낮추면 같은 HBM에 더 큰 모델을 담을 수 있고, 읽어야 할 데이터양이 줄어 대역폭 부담도 덜어진다. 다만 지나치게 낮추면 품질이 떨어지므로, 어디까지 줄일지 균형을 찾는 작업이 실무의 핵심이다.
모델 하나가 GPU 한 장에 안 들어가면 여러 장에 나눠 싣는다. 층을 나눠 배치하는 파이프라인 병렬(pipeline parallelism), 하나의 층 안에서 연산을 쪼개는 텐서 병렬(tensor parallelism) 같은 기법을 조합한다. 이때는 GPU 사이를 잇는 고속 연결망도 중요해진다. HBM 안에서의 대역폭뿐 아니라, GPU 간 데이터 이동 속도까지 함께 고려해야 전체 성능이 나온다.
서빙 단계에서는 앞서 언급한 vLLM 같은 프레임워크가 KV 캐시를 효율적으로 관리해 처리량을 끌어올린다. 여러 요청을 묶어 한꺼번에 처리하는 배칭(batching)도 대역폭을 알뜰히 쓰는 대표적 기법이다. 요청 하나를 처리할 때 읽어온 가중치를, 같이 묶인 여러 요청이 함께 나눠 쓰면 그만큼 효율이 오른다.
흔한 오해와 놓치기 쉬운 지점
가장 흔한 오해는 'HBM이 곧 빠른 메모리'라는 생각이다. 정확히는 '대역폭이 넓은 메모리'다. 접근 지연 자체는 온칩 SRAM보다 크다. 한 번에 나르는 양이 많다는 것과, 한 요청에 즉각 응답하는 빠릿함은 다른 이야기다. AI 연산처럼 대량의 데이터를 꾸준히 부어야 하는 작업에 유리할 뿐, 모든 면에서 우월한 메모리가 아니다.
두 번째 오해는 대역폭만 넓으면 성능이 저절로 오른다는 착각이다. FlashAttention과 KV 캐시 관리가 보여 주듯, 넓은 통로도 잘못 쓰면 낭비다. 소프트웨어가 메모리 접근 패턴을 얼마나 잘 설계하느냐가 실제 성능을 가른다. 하드웨어 사양표의 숫자만 보고 성능을 예단하면 곤란하다.
세 번째는 용량과 대역폭을 뭉뚱그리는 오해다. 둘은 별개의 자원이다. 대역폭이 넉넉해도 용량이 부족하면 큰 모델은 아예 못 올린다. 반대로 용량이 커도 대역폭이 좁으면 생성 속도가 안 나온다. 실무에서는 이 두 축을 따로 점검해야 한다. 마지막으로, HBM은 제조 난도가 높고 값이 비싸며 전력과 발열 관리가 까다롭다는 한계도 분명하다. 무조건 많이 붙인다고 될 일이 아니라, 비용과 전력까지 함께 저울질하는 설계가 필요하다.
대역폭과 연산의 저울질, 루프라인으로 읽는 AI 반도체
AI 반도체의 성능을 이야기할 때 흔히 초당 부동소수점 연산량(FLOPS)만 앞세우지만, 실제 추론 현장에서 병목은 대개 메모리 쪽에서 먼저 터진다. 이 둘의 관계를 한눈에 정리하는 도구가 루프라인 모델(roofline model)이다. 가로축에 연산 강도(arithmetic intensity), 세로축에 달성 가능한 연산 성능을 놓고 그리면, 그래프는 두 개의 벽으로 이루어진다. 왼쪽은 메모리 대역폭이 그어 놓은 경사진 지붕이고, 오른쪽은 연산기가 그어 놓은 평평한 천장이다. 어떤 연산이 어느 벽에 부딪히는지가 곧 그 연산이 메모리에 묶여 있는지 연산에 묶여 있는지를 말해 준다.
연산 강도란 메모리에서 바이트 하나를 읽어 올 때 그 데이터로 몇 번의 연산을 수행하는가를 뜻한다. 단위는 FLOP/byte다. 행렬-행렬 곱처럼 한 번 읽어 온 값을 여러 번 재사용하는 연산은 연산 강도가 높아 오른쪽 천장에 가서 붙는다. 반대로 행렬-벡터 곱, 즉 배치 크기가 1인 상황의 디코딩 단계는 한 번 읽은 가중치를 딱 한 번만 쓰고 버리므로 연산 강도가 극도로 낮다. 이런 연산은 왼쪽 경사면에 놓여 대역폭이 성능을 온전히 결정한다. LLM 추론의 토큰 생성 국면이 바로 이 자리에 있다.
구체적으로 따져 보자. 어떤 가속기의 연산 성능이 대략 1,000 TFLOPS이고 메모리 대역폭이 대략 3 TB/s라면, 두 벽이 만나는 임계 연산 강도는 1,000/3, 즉 약 333 FLOP/byte 부근이 된다. 배치 1 디코딩의 연산 강도는 흔히 1~2 FLOP/byte 수준에 머문다. 임계값에서 두 자릿수 이상 모자란다. 이 말은 연산기의 99% 이상이 놀고 있고, 오직 데이터를 실어 나르는 통로만 쉴 새 없이 돌아간다는 뜻이다. HBM에 그토록 매달리는 근본 이유가 이 숫자 하나에 담겨 있다.
루프라인의 관점을 잡고 나면 최적화의 방향이 분명해진다. 왼쪽 벽에 붙은 연산은 아무리 연산기를 늘려도 빨라지지 않는다. 대신 배치를 키워 같은 가중치를 여러 요청이 나눠 쓰게 만들거나, 데이터 재사용을 늘려 연산 강도 자체를 오른쪽으로 밀어야 한다. 뒤에서 다룰 배치 병합이나 양자화가 왜 그토록 효과가 큰지도 이 그림 안에서 자연스럽게 설명된다. 최적화란 결국 점을 왼쪽 경사면에서 오른쪽 천장 쪽으로 옮기는 작업이다.
가중치를 압축해 통로를 넓히다, 양자화의 메모리 산술
디코딩이 대역폭에 묶여 있다면, 옮겨야 할 데이터의 양 자체를 줄이는 것이 가장 직접적인 처방이다. 양자화(quantization)가 바로 그 처방이다. 모델 가중치를 16비트 부동소수점(FP16, BF16) 대신 8비트 정수(INT8)나 4비트(INT4, NF4)로 표현하면, 같은 파라미터를 옮기는 데 필요한 바이트가 절반 또는 4분의 1로 준다. 연산 강도가 낮아 대역폭이 곧 속도인 국면에서, 옮길 바이트를 반으로 줄이면 토큰 생성 속도가 사실상 두 배 가까이 빨라진다. 양자화가 추론 최적화의 첫 카드로 꼽히는 이유다.
숫자로 감을 잡아 보자. 70B 규모의 모델은 BF16으로 담으면 파라미터만 약 140GB를 차지한다. 80GB짜리 HBM을 얹은 가속기 한 장에 들어가지 않는다. 같은 모델을 INT4로 누르면 약 35GB로 줄어, 한 장에 올리고도 KV 캐시와 활성값을 위한 여유가 생긴다. 즉 양자화는 속도만이 아니라 '몇 장의 카드가 필요한가'라는 배치 비용까지 바꾼다. 카드 수가 줄면 카드 사이를 잇는 통신 오버헤드도 함께 사라지므로, 효과는 곱으로 나타난다.
다만 정밀도를 낮추면 값이 뭉개진다. 관건은 어디를 얼마나 뭉개도 품질이 버티는가다. 실무에서 널리 쓰이는 기법을 성격에 따라 정리하면 다음과 같다.
| 기법 | 대상 비트 | 특징 | 적용 시점 |
|---|---|---|---|
| GPTQ | 4비트 | 오차를 이웃 가중치로 보정하며 층별로 재양자화 | 사후(학습 후) |
| AWQ | 4비트 | 활성값이 큰 중요 채널을 보호해 정확도 유지 | 사후 |
| bitsandbytes(NF4) | 4비트 | 정규분포에 맞춘 자료형, QLoRA와 결합 | 사후·미세조정 |
| SmoothQuant | 8비트 | 활성값의 이상치를 가중치로 옮겨 INT8 곱을 안정화 | 사후 |
핵심 통찰은 가중치 분포에 이상치(outlier)가 소수 존재한다는 점이다. 대부분의 값은 좁은 범위에 몰려 있고, 극소수 채널만 큰 값을 갖는다. 이 소수를 함부로 뭉개면 품질이 급락한다. AWQ가 중요 채널을 골라 보호하고 SmoothQuant가 이상치의 크기를 가중치 쪽으로 넘겨 균형을 맞추는 것도 다 이 분포의 성질을 겨냥한 설계다. 양자화를 단순한 '반올림'으로 오해하면 이 미묘한 지점을 놓친다.
카드 한 장으로 안 될 때, 메모리를 쪼개는 병렬화 전략
양자화를 해도 담기지 않는 초거대 모델이라면 여러 가속기에 나눠 실어야 한다. 이때 무엇을 어떻게 쪼개느냐에 따라 필요한 대역폭과 통신 방식이 달라진다. 크게 텐서 병렬(tensor parallelism), 파이프라인 병렬(pipeline parallelism), 전문가 병렬(expert parallelism) 세 갈래로 나뉜다. 각각은 메모리 부담을 더는 방식과 대신 치러야 하는 통신 비용의 성격이 다르다.
텐서 병렬은 하나의 행렬 곱을 여러 카드가 열이나 행 단위로 나눠 계산하는 방식이다. 각 카드가 가중치의 일부만 들고 있으므로 카드당 메모리가 줄어든다. 대신 층마다 부분 결과를 모으는 전체 합산(all-reduce) 통신이 발생한다. 이 통신은 매 층마다 일어나므로 카드 사이의 연결이 느리면 곧바로 병목이 된다. 그래서 텐서 병렬은 NVLink처럼 카드 간 대역폭이 큰 한 노드 안에서 쓰는 것이 정석이다. HBM의 내부 대역폭 못지않게 카드 사이의 대역폭도 중요해지는 지점이다.
파이프라인 병렬은 모델을 층 단위로 잘라 카드마다 다른 구간을 맡긴다. 통신은 구간 경계에서만 일어나 텐서 병렬보다 훨씬 가볍다. 문제는 파이프라인 거품(bubble)이다. 첫 카드가 계산하는 동안 뒤쪽 카드는 놀고, 마지막 카드가 일할 때 앞쪽이 논다. 이 유휴를 줄이려고 마이크로 배치를 잘게 쪼개 흘려보내지만, 거품을 완전히 없애지는 못한다. 지연시간에 민감한 서비스라면 이 거품이 체감 성능을 갉아먹는다.
전문가 병렬은 혼합 전문가(MoE) 구조에서 전문가 네트워크들을 카드별로 흩어 놓는 방식이다. 토큰마다 소수의 전문가만 활성화되므로 총 파라미터는 거대해도 실제 계산량은 작다. 대신 어떤 토큰이 어떤 카드의 전문가로 가야 하는지를 라우팅하는 전량 교환(all-to-all) 통신이 새로 생긴다. 이 통신 패턴은 불규칙하고 부하가 치우치기 쉬워, 특정 전문가에 토큰이 몰리면 그 카드만 과부하가 걸린다. 병렬화는 만능이 아니라 저마다 다른 병목을 새로 불러온다는 점을 늘 염두에 두어야 한다.
HBM3에서 HBM4로, 그리고 대역폭 뒤에 숨은 전력의 벽
HBM은 세대를 거치며 핀당 속도와 적층 단수를 함께 끌어올려 왔다. HBM2에서 HBM2E, HBM3, HBM3E로 이어지며 스택 하나가 내는 대역폭은 꾸준히 커졌고, 적층 단수도 8단에서 12단, 16단으로 높아지는 방향으로 나아가고 있다. 다가올 HBM4는 인터페이스 폭을 기존 1,024비트에서 2,048비트로 두 배 넓히는 것이 가장 큰 변화로 꼽힌다. 통로의 폭 자체를 넓혀 같은 클럭에서도 더 많은 데이터를 실어 나르겠다는 발상이다.
그런데 대역폭을 키우는 일은 곧 전력과의 싸움이다. 데이터를 실어 나르는 데도 에너지가 든다. 반도체 설계에서는 이를 비트당 에너지(pJ/bit)로 따진다. 대역폭이 커질수록 초당 옮기는 비트가 늘어나므로, 비트당 에너지를 낮추지 못하면 메모리가 소비하는 총 전력이 눈덩이처럼 불어난다. 실제로 대형 가속기 패키지에서 HBM이 차지하는 전력 비중은 결코 무시할 수준이 아니다. 대역폭을 자랑하는 사양표 뒤에는 늘 열과 전력이라는 그늘이 따라붙는다.
이 전력의 벽이 여러 설계 결정을 밀어붙인다. HBM을 연산 다이 바로 옆에 붙여 신호가 오가는 거리를 극단적으로 줄이는 이유도, 실리콘 인터포저(interposer)라는 값비싼 중간 기판을 감수하는 이유도 결국은 짧은 거리가 에너지를 아끼기 때문이다. 나아가 메모리 스택 밑바닥의 로직 다이에 간단한 연산을 심어, 데이터를 굳이 연산 다이까지 옮기지 않고 그 자리에서 처리하려는 시도도 나온다. 이른바 프로세싱 인 메모리(PIM) 계열의 접근이다. 데이터를 안 옮기는 것이 옮기는 것보다 늘 싸다는 원칙을 물리적 구조로 옮긴 셈이다.
발열 문제는 적층 구조에서 특히 고약하다. 다이를 위로 쌓을수록 아래쪽 다이의 열이 위로 빠져나가기 어려워진다. 16단, 그 이상으로 쌓으려면 다이를 더 얇게 갈아야 하고, 얇아진 다이는 휘어짐과 균열에 취약해진다. 그래서 HBM4 세대에서는 열을 빼내는 방식과 접합 기술 자체가 성능만큼이나 중요한 경쟁 축으로 떠올랐다. 대역폭 숫자만 좇다 보면 이 물리적 제약이 실제 양산의 발목을 잡는다는 사실을 놓치기 쉽다.
여러 요청을 한 번에, 배치와 스케줄링이 대역폭을 살리는 법
앞서 배치 1 디코딩이 연산 강도가 극도로 낮아 연산기를 거의 놀린다고 했다. 뒤집어 보면, 같은 가중치를 여러 요청이 함께 쓰게 만들면 이 낭비를 크게 줄일 수 있다. 가중치를 HBM에서 한 번 읽어 오는 동안 요청 하나가 아니라 열 개, 스무 개의 토큰을 동시에 계산하면, 읽어 온 바이트당 연산량이 그만큼 올라간다. 루프라인의 점이 왼쪽 경사면을 타고 오른쪽으로 이동한다. 배치가 대역폭 병목을 완화하는 핵심 수단인 이유가 여기 있다.
문제는 요청마다 도착 시점도 다르고 생성 길이도 제각각이라는 점이다. 예전 방식처럼 한 배치가 모두 끝날 때까지 기다렸다가 다음 배치를 받으면, 짧은 요청이 긴 요청에 발이 묶여 하염없이 대기한다. 이를 풀어낸 것이 연속 배치(continuous batching)다. 배치를 고정하지 않고 매 생성 단계마다 새 요청을 끼워 넣고 끝난 요청은 빼낸다. 자리가 비는 즉시 채우니 가속기가 노는 시간이 크게 줄어든다. vLLM 같은 추론 엔진이 이 방식을 앞세워 처리량을 끌어올린 것도 같은 원리다.
여기에 페이지드 어텐션(PagedAttention)이 결합하면 효과가 배가된다. KV 캐시를 연속된 큰 덩어리로 잡지 않고 운영체제의 가상 메모리처럼 작은 페이지 단위로 쪼개 관리하는 기법이다. 요청마다 미리 최대 길이만큼 캐시 공간을 예약하던 낭비가 사라지고, 실제 생성한 만큼만 페이지를 붙여 쓴다. 조각난 공간까지 알뜰히 채우니 같은 HBM 용량으로 훨씬 많은 요청을 동시에 담을 수 있다. 배치를 키우려면 메모리가 있어야 하고, 메모리를 아끼면 배치를 키울 수 있다는 선순환이 만들어진다.
다만 배치를 무한정 키운다고 좋은 것은 아니다. 배치가 커지면 개별 요청의 지연시간이 늘고, KV 캐시 압박도 다시 커진다. 처리량과 지연시간은 저울의 양 끝이다. 대화형 서비스라면 첫 토큰까지의 지연(TTFT)을 지키기 위해 배치를 절제해야 하고, 대량 일괄 처리라면 지연을 양보하고 배치를 최대로 밀어붙이는 편이 이득이다. 스케줄링이란 결국 이 저울을 서비스 성격에 맞게 기울이는 기술이다. 하드웨어 사양이 같아도 스케줄러 설계에 따라 실효 성능이 몇 배씩 갈리는 까닭이 여기에 있다.
여기서 한 걸음 더 나아가려면
HBM과 AI 반도체를 제대로 이해하려면 메모리 하드웨어와 모델 알고리즘을 양쪽에서 함께 봐야 한다. 하드웨어 쪽으로는 JEDEC의 HBM 표준 문서와 NVIDIA H100 아키텍처 자료를 살펴보면, 실제 제품이 대역폭과 용량을 어떻게 설계했는지 감을 잡을 수 있다. 메모리 장벽이라는 개념의 역사도 함께 짚어 두면 왜 이 모든 노력이 필요한지 큰 그림이 그려진다.
소프트웨어와 알고리즘 쪽으로는 FlashAttention과 PagedAttention(vLLM) 논문이 출발점으로 좋다. 두 연구 모두 '메모리를 어떻게 덜 쓰고 알뜰히 굴릴 것인가'라는 같은 질문에 다른 각도로 답한다. 여기에 대규모 언어모델의 효율적 추론을 폭넓게 정리한 서베이 논문을 곁들이면, 양자화·배칭·병렬화 같은 기법들이 서로 어떻게 맞물리는지 지도를 얻을 수 있다.
인접 개념으로는 트랜스포머와 자기어텐션의 동작 원리, 토큰화와 임베딩, 그리고 KV 캐시의 구조를 함께 익히길 권한다. 이 개념들을 알아야 'HBM 대역폭이 왜 토큰 생성 속도를 좌우하는가'라는 물음에 스스로 답할 수 있다. 결국 AI 반도체의 성능은 넓은 통로를 가진 메모리와, 그 통로를 영리하게 쓰는 소프트웨어의 합작품이다. 두 세계를 오가며 공부할 때 비로소 전체 그림이 완성된다.