HBM과 AI 반도체란? 대역폭 병목부터 LLM 추론 최적화까지

HBM(High Bandwidth Memory, 고대역폭 메모리)은 여러 개의 D램(DRAM, 컴퓨터가 지금 작업 중인 데이터를 잠시 올려 두는 기억 장치) 다이를 위로 쌓고, 그 사이를 수천 개의 미세한 관통 전극으로 이어 붙인 메모리입니다. 다이(die)는 둥근 반도체 원판(웨이퍼)에서 잘라 낸 칩 한 조각을 말합니다. 이렇게 하면 한 번에 매우 넓은 폭의 데이터를 주고받을 수 있습니다. 한 문장으로 줄이면 '층층이 쌓아 통로를 극단적으로 넓힌 D램'입니다. 국제 반도체 표준화 기구인 JEDEC이 규격을 정했고, 세대를 거듭하며 HBM2, HBM2E, HBM3, HBM3E로 발전해 왔습니다. 2025년 4월에는 다음 세대인 HBM4 표준도 나왔습니다(규격 번호는 HBM이 JESD235, HBM3가 JESD238, HBM4가 JESD270-4).

한눈에 보기

• HBM은 메모리 칩을 여러 층 쌓고 구멍을 뚫어 이어, 한 번에 옮길 수 있는 데이터 양을 크게 늘린 메모리입니다.
• ChatGPT 같은 AI가 답을 한 글자씩 만들 때마다 방대한 데이터를 메모리에서 꺼내 와야 해서, 계산 속도보다 이 통로의 넓이가 속도를 정하는 경우가 많습니다.
• 그래서 AI 반도체 경쟁은 곧 HBM 경쟁이기도 하며, 2026년 현재 SK하이닉스·삼성전자·마이크론이 HBM4로 맞붙고 있습니다.

쌓아 올린 메모리, 넓어진 통로

이런 상황을 떠올려 보세요. 동네 식당 주방에 솜씨 좋은 요리사가 열 명 있습니다. 손이 빨라 한 접시를 몇 분 만에 끝냅니다. 그런데 식재료 창고가 주방 끝 좁은 복도 너머에 있고, 복도는 한 사람이 겨우 지나갈 폭입니다. 점심 주문이 몰리면 요리사들은 도마 앞에서 재료가 오기만 기다립니다. 요리사를 더 뽑아도 소용이 없습니다. 복도를 넓히고 창고를 주방 바로 옆에 붙여야 음식이 빨리 나갑니다. ChatGPT에 긴 회의록 요약을 부탁했을 때 답이 한 글자씩 흘러나오는 것도 비슷한 사정입니다. AI 칩의 계산 능력은 넉넉한데, 계산에 쓸 데이터를 메모리에서 실어 오는 통로가 속도를 붙잡습니다. HBM은 이 창고를 주방 바로 옆에 붙이고 복도를 수천 갈래로 넓힌 메모리라고 보면 됩니다.

일반적인 컴퓨터 메모리인 DDR 계열과 비교하면 성격이 뚜렷이 다릅니다. 흔히 쓰는 D램은 좁은 통로로 아주 빠르게 데이터를 밀어내는 방식에 가깝습니다. 반면 HBM은 통로 자체를 압도적으로 넓혀 놓았습니다. 이 통로의 넓이, 곧 1초 동안 옮길 수 있는 데이터의 양을 대역폭(bandwidth)이라고 부릅니다. 데이터 신호선(I/O, 데이터가 드나드는 전선 한 가닥)의 폭이 스택당 1024비트에 이르고, 전원·제어선을 더하면 수천 개의 미세 범프로 연결됩니다. 범프(bump)는 칩과 그 아래 기판을 전기로 잇는, 좁쌀보다 작은 금속 돌기입니다. 차선 두 개짜리 고속도로와 차선 수천 개짜리 대로를 떠올리면 감이 옵니다. 한 대가 얼마나 빨리 달리느냐보다, 한꺼번에 몇 대가 지나갈 수 있느냐가 HBM의 핵심입니다.

이렇게 넓은 통로를 확보하려면 물리적으로 프로세서 바로 옆에 붙여야 합니다. 그래서 HBM은 GPU(원래 그래픽 처리용으로 만들었지만, 단순한 계산 수천 개를 한꺼번에 해내 AI 계산에 널리 쓰이는 칩)나 AI 가속기 같은 연산 칩과 함께 하나의 패키지 안에 실립니다. 실리콘으로 만든 중간 배선판인 인터포저(interposer) 위에 연산 칩과 HBM 스택을 나란히 올리고, 그 위에서 수천 가닥의 배선으로 잇습니다. 물리적 거리가 짧아야 넓은 통로를 낮은 전력으로 유지할 수 있기 때문입니다. 이 점이 메인보드에 슬롯으로 꽂는 일반 메모리와 근본적으로 다른 지점입니다.

왜 AI 반도체는 메모리에 목을 매는가

AI 반도체, 특히 대규모 언어 모델(LLM, Large Language Model, 방대한 글을 읽고 배워 문장을 이어 쓰는 AI 모델)을 돌리는 GPU와 가속기가 HBM을 요구하는 이유는 '메모리 장벽(memory wall)'이라는 오래된 숙제 때문입니다. 지난 수십 년간 프로세서의 연산 속도는 눈부시게 빨라졌지만, 메모리에서 데이터를 실어 나르는 속도는 그만큼 따라오지 못했습니다. 그 격차가 점점 벌어지면서, 이제는 계산 자체가 아니라 계산할 데이터를 제때 공급하지 못하는 것이 병목이 됐습니다.

이 문제는 딥러닝 연산의 성격 때문에 특히 심각합니다. 트랜스포머(Transformer, 문장 속 단어들이 서로를 참고해 뜻을 정하도록 계산하는 신경망 구조) 기반 모델은 거대한 가중치 행렬을 메모리에서 읽어 와 곱셈과 덧셈을 반복합니다. 가중치(weight)는 모델이 학습하며 익힌 지식을 담은 숫자들로, 파라미터라고도 부릅니다. 모델이 커질수록 읽어야 할 가중치의 양이 폭발적으로 늘어납니다. 수십억, 수천억 개의 파라미터를 담은 모델이라면 한 번의 추론(학습을 마친 모델이 실제로 답을 만들어 내는 일)에도 방대한 데이터를 메모리에서 연산 장치로 옮겨야 합니다. 연산 장치가 아무리 빨라도 데이터가 도착하지 않으면 놀 수밖에 없습니다.

이런 상황을 '메모리 바운드(memory-bound)'라고 부릅니다. 연산 능력이 남아도는데도 메모리 대역폭이 부족해 전체 속도가 결정되는 상태입니다. 반대로 데이터 공급은 넉넉한데 계산량 자체가 많아 느린 경우는 '컴퓨트 바운드(compute-bound)'입니다. LLM 추론, 특히 토큰을 하나씩 만들어 내는 생성 단계는 전형적인 메모리 바운드 작업입니다. 그래서 넓은 통로를 가진 HBM이 없으면 아무리 강력한 연산 코어를 얹어도 제 성능을 내지 못합니다.

2022년에 나온 NVIDIA H100(SXM 제품 기준)이 HBM3를 채택하고, 2026년 9월 기준(보완 시점) NVIDIA의 최신 플랫폼인 Rubin이 GPU 한 개에 HBM4를 최대 288GB 붙인 것도 같은 맥락입니다. 텐서 코어(Tensor Core, 행렬 곱셈에 특화된 연산 유닛)로 행렬 연산을 극한까지 밀어붙이려면, 그 코어에 데이터를 끊김 없이 부어 줄 메모리가 반드시 필요합니다. HBM은 이 공급 라인을 감당하는 사실상의 표준 해법으로 자리 잡았습니다.

관통 전극과 스택, 대역폭이 만들어지는 원리

HBM이 넓은 통로를 얻는 비결은 크게 두 가지입니다. 첫째는 수직 적층이고, 둘째는 실리콘 관통 전극(TSV, Through-Silicon Via, 칩을 위아래로 꿰뚫는 금속 기둥)입니다. 여러 장의 D램 다이를 위로 쌓은 뒤, 각 다이를 관통하는 미세한 구멍을 뚫고 그 안을 금속으로 채워 위아래 층을 전기적으로 잇습니다. 이렇게 하면 옆으로 길게 배선을 늘어놓지 않고도, 짧은 수직 경로로 수많은 신호선을 확보할 수 있습니다. 아파트에 계단 하나를 두는 대신 층마다 엘리베이터를 수천 대 놓은 것과 같습니다.

대역폭은 간단한 곱셈으로 이해할 수 있습니다. 대역폭은 대략 '통로의 폭(신호선 개수) × 신호선 하나가 초당 실어 나르는 양'으로 정해집니다. HBM은 통로의 폭을 극단적으로 넓히는 전략을 택했습니다. 신호선 하나하나의 속도는 무리하게 올리지 않습니다. 대신 개수를 압도적으로 늘려 총량을 키웁니다. 이 방식은 전력 효율에도 유리합니다. 신호 하나를 아주 빠르게 흔들면 전력 소모와 발열이 급증하지만, 여러 개를 적당한 속도로 병렬 처리하면 같은 총 대역폭을 더 낮은 전력으로 얻을 수 있습니다.

여기에 물리적 근접성이 결정적으로 작용합니다. HBM 스택을 GPU 다이 바로 옆, 같은 패키지 안에 두면 신호가 이동하는 거리가 매우 짧아집니다. 거리가 짧으면 신호가 흐트러지기 전에 도착하므로, 넓은 통로를 안정적으로 유지할 수 있습니다. 만약 이 메모리를 메인보드 저편에 두고 긴 배선으로 이었다면, 수천 개의 신호선을 온전히 유지하는 것 자체가 불가능에 가까웠을 것입니다.

정리하면 HBM의 성능은 '쌓아서(적층) 짧게(TSV·근접 배치) 넓게(수천 신호선)'라는 세 축에서 나옵니다. 이 세 가지가 맞물려, 좁고 빠른 기존 메모리로는 도달할 수 없는 총 대역폭을 실현합니다.

토큰 하나를 만들 때 메모리에서 벌어지는 일

LLM이 문장을 생성하는 과정을 따라가면 메모리 대역폭이 왜 중요한지 피부로 와닿습니다. 언어 모델은 입력 문장을 토큰(token, AI가 글을 읽고 쓰는 조각 단위로, 보통 단어 하나보다 조금 작은 단위)으로 쪼갠 뒤, 각 토큰을 숫자 목록인 임베딩(embedding, 뜻이 비슷한 말끼리 가까운 자리에 놓이도록 바꾼 숫자 좌표)으로 바꿉니다. 그리고 트랜스포머 층을 통과시키며 다음에 올 토큰의 확률 분포를 계산합니다. 어휘 사전 전체를 놓고 '이 단어가 다음에 올 확률'을 매기고, 그중 하나를 골라 이어 붙입니다.

핵심은 이 과정을 토큰 하나마다 반복한다는 점입니다. 한 토큰을 만들 때마다 모델의 모든 가중치를 메모리에서 다시 읽어 와야 합니다. 100개 토큰짜리 답변을 생성한다면 방대한 가중치를 100번 훑는 셈입니다. 여기서 계산량 자체는 크지 않은데, 데이터를 읽어 오는 시간이 대부분을 차지합니다. 그래서 생성 속도는 사실상 메모리 대역폭에 비례합니다. HBM의 넓은 통로가 초당 몇 개의 토큰을 만들어 낼지를 좌우합니다. 앞의 식당으로 치면, 손님 한 명의 주문 한 줄을 처리할 때마다 창고 전체를 한 번씩 훑고 오는 것과 같습니다.

확률 분포에서 다음 토큰을 실제로 고르는 방식(온도, top-p 같은 디코딩 설정)은 답변의 성격을 바꾸지만 메모리 대역폭과는 직접 관계가 없습니다. 이 설정은 프롬프트 엔지니어링 글에서 따로 다룹니다.

KV 캐시, 메모리를 갉아먹는 숨은 주범

LLM 추론에서 HBM 용량과 대역폭을 크게 잡아먹는 것은 모델 가중치만이 아닙니다. 의외로 KV 캐시(Key-Value cache)라고 부르는 중간 결과가 큰 비중을 차지합니다. 트랜스포머의 자기어텐션(self-attention, 문장 속 각 토큰이 앞의 토큰들을 얼마나 참고할지 따지는 계산)은 이전에 만든 모든 토큰의 키(Key)와 값(Value) 벡터를 참조합니다. 매번 다시 계산하면 낭비이므로, 한 번 계산한 키와 값을 메모리에 저장해 두고 재사용합니다. 이 저장 공간이 KV 캐시입니다. 회의록을 요약하는 AI가 앞에서 읽은 내용을 잊지 않도록 적어 두는 메모장이라고 보면 됩니다.

문제는 이 캐시가 문장이 길어질수록, 동시에 처리하는 요청이 많아질수록 무섭게 불어난다는 데 있습니다. 긴 대화, 긴 문서 요약을 다루면 KV 캐시만으로 HBM이 가득 차기도 합니다. 게다가 요청마다 얼마나 긴 답변이 나올지 미리 알 수 없어, 메모리를 넉넉히 잡아 두면 그만큼 낭비가 생깁니다. 예약해 둔 공간을 다 쓰지 못하고 놀리는 파편화 문제가 서빙(만든 모델을 여러 사용자에게 실제 서비스로 제공하는 일) 효율을 갉아먹습니다.

이 문제를 정면으로 다룬 대표적 연구가 PagedAttention을 제안한 vLLM입니다. 운영체제가 메모리를 작은 페이지 단위로 쪼개 관리하듯, KV 캐시도 작은 블록으로 나눠 필요할 때 그때그때 할당하는 발상입니다. 큰 덩어리를 미리 통째로 예약하지 않으니 파편화가 크게 줄고, 같은 HBM으로 훨씬 많은 요청을 동시에 처리할 수 있습니다. 서빙 처리량이 눈에 띄게 올라갑니다. 식당으로 치면 단체 손님이 올지 모른다고 큰 방을 통째로 비워 두는 대신, 온 인원만큼 테이블을 붙여 주는 방식입니다.

결국 AI 반도체의 성능은 HBM이라는 하드웨어와, 그 위에서 메모리를 얼마나 알뜰하게 굴리느냐 하는 소프트웨어가 함께 결정합니다. 하드웨어만 좋다고 되는 것도, 알고리즘만 영리하다고 되는 것도 아닙니다.

FlashAttention이 보여 준 메모리 계층의 진실

HBM은 GPU에 붙은 외부 메모리 가운데 통로가 가장 넓지만, 가장 빠른 저장 공간은 아닙니다. GPU 내부에는 연산 코어에 훨씬 가까운 작고 빠른 메모리, 이른바 온칩 SRAM이 있습니다. SRAM(Static RAM)은 연산 코어와 같은 칩 안에 들어 있어 아주 빠르지만 용량이 작은 메모리로, 요리사 손 닿는 곳의 작은 선반과 같습니다. 계층으로 보면 연산 코어와 가까울수록 빠르고 작으며, 멀수록 크고 상대적으로 느립니다. HBM은 용량이 크고 대역폭이 넓지만, 온칩 메모리에 비하면 접근 지연이 큽니다.

FlashAttention은 바로 이 계층 구조를 파고든 기법입니다. 기존 어텐션 계산은 거대한 중간 행렬을 HBM에 통째로 썼다가 다시 읽어 오는 과정을 반복했습니다. 이 왕복이 어텐션 연산의 진짜 병목이었습니다. FlashAttention은 계산을 작은 조각으로 나눠 온칩의 빠른 메모리 안에서 처리하고, HBM으로 오가는 데이터 왕복을 최소화합니다. 그러면서도 근사가 아닌 정확한 어텐션 결과를 냅니다.

이 사례가 주는 교훈은 분명합니다. HBM 대역폭이 아무리 넓어도, 그 통로를 불필요하게 자주 오가면 성능을 잃습니다. 진짜 최적화는 대역폭을 늘리는 데서 그치지 않고, 애초에 그 통로를 덜 쓰도록 알고리즘을 짜는 데 있습니다. HBM을 이해한다는 것은 이런 메모리 계층 전체를 함께 이해한다는 뜻입니다.

현장에서 HBM 용량을 다루는 법

실무에서 AI 반도체를 다룰 때 가장 먼저 부딪히는 벽은 HBM 용량입니다. 모델을 GPU에 올리려면 가중치와 KV 캐시, 그리고 각종 중간 버퍼가 모두 HBM 안에 들어가야 합니다. 그래서 엔지니어들은 세 가지 방향으로 대응합니다. 가중치를 16비트 대신 8비트나 4비트처럼 더 적은 자릿수로 적어 크기를 줄이는 양자화(quantization), 한 장에 안 들어가는 모델을 여러 장의 GPU에 나눠 싣는 병렬화, 여러 사용자의 요청을 묶어 한 번 읽어 온 가중치를 함께 쓰게 하는 배치(batching)입니다. 양자화는 짐을 압축해 복도를 덜 오가게 하고, 병렬화는 창고를 여러 개 두며, 배치는 한 번 창고에 다녀올 때 여러 손님의 재료를 같이 들고 오는 방법입니다. 각 기법이 대역폭을 어떻게 아끼는지는 글 끝 '개발자를 위한 심화'에서 숫자와 함께 다룹니다.

흔한 오해와 놓치기 쉬운 지점

가장 흔한 오해는 'HBM이 곧 빠른 메모리'라는 생각입니다. 정확히는 '대역폭이 넓은 메모리'입니다. 접근 지연 자체는 온칩 SRAM보다 큽니다. 한 번에 나르는 양이 많다는 것과, 한 요청에 즉각 응답하는 속도는 다른 이야기입니다. AI 연산처럼 대량의 데이터를 꾸준히 부어야 하는 작업에 유리할 뿐, 모든 면에서 우월한 메모리가 아닙니다.

두 번째 오해는 대역폭만 넓으면 성능이 저절로 오른다는 착각입니다. FlashAttention과 KV 캐시 관리가 보여 주듯, 넓은 통로도 잘못 쓰면 낭비입니다. 소프트웨어가 메모리 접근 패턴을 얼마나 잘 설계하느냐가 실제 성능을 가릅니다. 하드웨어 사양표의 숫자만 보고 성능을 예단하면 곤란합니다.

세 번째는 용량과 대역폭을 뭉뚱그리는 오해입니다. 둘은 별개의 자원입니다. 대역폭이 넉넉해도 용량이 부족하면 큰 모델은 아예 못 올립니다. 반대로 용량이 커도 대역폭이 좁으면 생성 속도가 안 나옵니다. 창고가 넓은 것과 복도가 넓은 것은 다른 문제입니다. 실무에서는 이 두 축을 따로 점검해야 합니다. 마지막으로, HBM은 제조 난도가 높고 값이 비싸며 전력과 발열 관리가 까다롭다는 한계도 분명합니다. 무조건 많이 붙인다고 될 일이 아니라, 비용과 전력까지 함께 저울질하는 설계가 필요합니다.

HBM3에서 HBM4로, 그리고 대역폭 뒤에 숨은 전력의 벽

HBM은 세대를 거치며 핀당 속도와 적층 단수를 함께 끌어올려 왔습니다. HBM2에서 HBM2E, HBM3, HBM3E로 이어지며 스택 하나가 내는 대역폭은 꾸준히 커졌고, 적층 단수도 8단에서 12단, 16단으로 높아지고 있습니다. HBM4에서 가장 큰 변화는 인터페이스 폭을 기존 1,024비트에서 2,048비트로 두 배 넓힌 것입니다. 통로의 폭 자체를 넓혀 같은 동작 속도(클럭)에서도 더 많은 데이터를 실어 나르겠다는 발상입니다. 2026년 9월 기준(보완 시점) HBM4는 이미 양산에 들어가 NVIDIA Rubin 같은 최신 가속기에 실리고 있습니다.

HBM4는 한국 반도체 기업들이 앞장선 분야이기도 합니다. SK하이닉스는 2025년 9월 12일 HBM4 개발을 마치고 세계 최초로 양산 체제를 갖췄다고 발표했습니다. 입출력 단자를 이전 세대의 두 배인 2,048개로 늘리고 전력 효율을 40% 이상 높였으며, 동작 속도는 JEDEC 표준(8Gbps)보다 빠른 10Gbps 이상이라고 밝혔습니다. 삼성전자는 2026년 2월 12일 HBM4 양산을 시작해 고객사에 상용 제품을 출하했다고 발표했고, 핀당 11.7Gbps(최대 13Gbps), 스택당 최대 3.3TB/s를 내세웠습니다. 미국 마이크론도 2026년 6월 24일 분기 실적 발표에서 HBM4를 주력 고객사의 플랫폼용으로 대량 출하하고 있다고 밝혀, 세 회사가 같은 세대에서 맞붙는 구도가 됐습니다.

그런데 대역폭을 키우는 일은 곧 전력과의 싸움입니다. 데이터를 실어 나르는 데도 에너지가 듭니다. 반도체 설계에서는 이를 비트 하나를 옮기는 데 드는 에너지(pJ/bit, 피코줄은 1조분의 1줄)로 따집니다. 대역폭이 커질수록 초당 옮기는 비트가 늘어나므로, 비트당 에너지를 낮추지 못하면 메모리가 소비하는 총 전력이 눈덩이처럼 불어납니다. 대역폭을 자랑하는 사양표 뒤에는 늘 열과 전력이라는 그늘이 따라붙습니다.

이 전력의 벽이 여러 설계 결정을 이끕니다. HBM을 연산 다이 바로 옆에 붙여 신호가 오가는 거리를 극단적으로 줄이는 이유도, 실리콘 인터포저라는 값비싼 중간 기판을 감수하는 이유도 결국은 짧은 거리가 에너지를 아끼기 때문입니다. 나아가 메모리 스택 밑바닥의 로직 다이에 간단한 연산을 심어, 데이터를 굳이 연산 다이까지 옮기지 않고 그 자리에서 처리하려는 시도도 나옵니다. 이른바 프로세싱 인 메모리(PIM, 메모리 안에서 간단한 계산까지 해내는 방식) 계열의 접근입니다. 데이터를 옮기지 않는 편이 옮기는 것보다 늘 싸다는 원칙을 물리적 구조로 옮긴 것입니다.

발열 문제는 적층 구조에서 특히 까다롭습니다. 다이를 위로 쌓을수록 아래쪽 다이의 열이 위로 빠져나가기 어려워집니다. 16단, 그 이상으로 쌓으려면 다이를 더 얇게 갈아야 하고, 얇아진 다이는 휘어짐과 균열에 약해집니다. 그래서 HBM4 세대에서는 열을 빼내는 방식과 접합 기술 자체가 성능만큼이나 중요한 경쟁 축으로 떠올랐습니다. 대역폭 숫자만 좇다 보면 이 물리적 제약이 실제 양산의 발목을 잡는다는 사실을 놓치기 쉽습니다.

여기서 한 걸음 더 나아가려면

HBM과 AI 반도체를 제대로 이해하려면 메모리 하드웨어와 모델 알고리즘을 양쪽에서 함께 봐야 합니다. 하드웨어 쪽으로는 JEDEC의 HBM 표준 문서와 NVIDIA H100·Rubin 아키텍처 자료를 살펴보면, 실제 제품이 대역폭과 용량을 어떻게 설계했는지 감을 잡을 수 있습니다. 메모리 장벽이라는 개념의 역사도 함께 짚어 두면 왜 이 모든 노력이 필요한지 큰 그림이 그려집니다.

소프트웨어와 알고리즘 쪽으로는 FlashAttention과 PagedAttention(vLLM) 논문이 출발점으로 좋습니다. 두 연구 모두 '메모리를 어떻게 덜 쓰고 알뜰히 굴릴 것인가'라는 같은 질문에 다른 각도로 답합니다. 여기에 대규모 언어 모델의 효율적 추론을 폭넓게 정리한 서베이 논문을 곁들이면, 양자화·배치·병렬화 같은 기법들이 서로 어떻게 맞물리는지 지도를 얻을 수 있습니다.

인접 개념으로는 트랜스포머와 자기어텐션의 동작 원리, 토큰화와 임베딩, 그리고 KV 캐시의 구조를 함께 익히길 권합니다. 이 개념들을 알아야 'HBM 대역폭이 왜 토큰 생성 속도를 좌우하는가'라는 물음에 스스로 답할 수 있습니다. 결국 AI 반도체의 성능은 넓은 통로를 가진 메모리와, 그 통로를 영리하게 쓰는 소프트웨어의 합작품입니다. 두 세계를 오가며 공부할 때 비로소 전체 그림이 완성됩니다.

개발자를 위한 심화

이 부분은 직접 구현하는 개발자를 위한 내용입니다.

대역폭과 연산의 저울질, 루프라인으로 읽는 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에 그토록 매달리는 근본 이유가 이 숫자 하나에 담겨 있습니다.

루프라인의 관점을 잡고 나면 최적화의 방향이 분명해집니다. 왼쪽 벽에 붙은 연산은 아무리 연산기를 늘려도 빨라지지 않습니다. 대신 배치를 키워 같은 가중치를 여러 요청이 나눠 쓰게 만들거나, 데이터 재사용을 늘려 연산 강도 자체를 오른쪽으로 밀어야 합니다. 옮길 바이트 자체를 줄이는 양자화도 같은 벽을 공략합니다. 이어지는 양자화와 배치 절이 왜 효과가 큰지도 이 그림 안에서 설명됩니다. 최적화란 결국 점을 왼쪽 경사면에서 오른쪽 천장 쪽으로 옮기는 작업입니다.

옮길 짐 줄이기, 양자화의 메모리 산술

디코딩이 대역폭에 묶여 있다면, 옮겨야 할 데이터의 양 자체를 줄이는 것이 가장 직접적인 처방입니다. 양자화가 바로 그 처방입니다. 모델 가중치를 16비트 부동소수점(FP16, BF16) 대신 8비트 정수(INT8)나 4비트(INT4, NF4)로 표현하면, 같은 파라미터를 옮기는 데 필요한 바이트가 절반 또는 4분의 1로 줄어듭니다. 연산 강도가 낮아 대역폭이 곧 속도인 국면에서, 옮길 바이트를 반으로 줄이면 토큰 생성 속도가 이론상 두 배 가까이까지 오를 수 있습니다. 양자화가 추론 최적화의 첫 카드로 꼽히는 이유입니다.

숫자로 감을 잡아 보겠습니다. 70B 규모의 모델은 BF16으로 담으면 파라미터만 약 140GB를 차지합니다. 80GB짜리 HBM을 얹은 가속기 한 장에 들어가지 않습니다. 같은 모델을 INT4로 줄이면 약 35GB가 되어, 한 장에 올리고도 KV 캐시와 활성값을 위한 여유가 생깁니다. 즉 양자화는 속도만이 아니라 '몇 장의 카드가 필요한가'라는 배포 비용까지 바꿉니다. 카드 수가 줄면 카드 사이를 잇는 통신 부담도 줄어드므로, 속도 이득에 통신 절감이 더해집니다.

다만 정밀도를 낮추면 값이 뭉개집니다. 관건은 어디를 얼마나 뭉개도 품질이 버티느냐입니다. 실무에서 널리 쓰이는 기법을 성격에 따라 정리하면 다음과 같습니다.

핵심은 활성값(activation, 모델이 계산하는 도중 층과 층 사이를 오가는 중간 값)에 이상치(outlier)가 일부 채널에 몰려 나타난다는 점입니다. 대부분의 값은 좁은 범위에 몰려 있고, 극소수 채널만 큰 값을 갖습니다. 이 소수를 함부로 뭉개면 품질이 급락합니다. AWQ는 가중치 크기가 아니라 활성값 분포를 보고 중요한 가중치 채널(논문 기준 약 1%)을 골라, 그 채널의 크기를 키우는 수학적으로 같은 변환으로 양자화 오차를 줄입니다. SmoothQuant는 가중치는 양자화하기 쉽고 활성값은 어렵다는 관찰에서 출발해, 활성값의 이상치를 매끄럽게 누르고 그만큼의 양자화 난도를 가중치 쪽으로 넘깁니다. 둘 다 활성값 이상치라는 분포의 성질을 겨냥한 설계입니다. GPTQ는 결이 다릅니다. 한 층의 가중치를 순서대로 양자화하면서, 앞에서 생긴 오차를 2차 정보(오차가 얼마나 민감하게 커지는지를 나타내는 곡률)로 계산해 아직 양자화하지 않은 가중치를 조정해 메웁니다. 양자화를 단순한 '반올림'으로 오해하면 이 미묘한 지점을 놓칩니다.

카드 한 장으로 안 될 때, 메모리를 쪼개는 병렬화 전략

양자화를 해도 담기지 않는 초거대 모델이라면 여러 가속기에 나눠 실어야 합니다. 이때 무엇을 어떻게 쪼개느냐에 따라 필요한 대역폭과 통신 방식이 달라집니다. 크게 텐서 병렬(tensor parallelism), 파이프라인 병렬(pipeline parallelism), 전문가 병렬(expert parallelism) 세 갈래로 나뉩니다. 각각은 메모리 부담을 더는 방식과 대신 치러야 하는 통신 비용의 성격이 다릅니다.

텐서 병렬은 하나의 행렬 곱을 여러 카드가 열이나 행 단위로 나눠 계산하는 방식입니다. 각 카드가 가중치의 일부만 들고 있으므로 카드당 메모리가 줄어듭니다. 대신 층마다 부분 결과를 모으는 전체 합산(all-reduce) 통신이 발생합니다. 이 통신은 층마다 일어나므로 카드 사이의 연결이 느리면 곧바로 병목이 됩니다. 그래서 텐서 병렬은 NVLink처럼 카드 간 대역폭이 큰 한 노드 안에서 쓰는 것이 정석입니다. HBM의 내부 대역폭 못지않게 카드 사이의 대역폭도 중요해지는 지점입니다.

파이프라인 병렬은 모델을 층 단위로 잘라 카드마다 다른 구간을 맡깁니다. 통신은 구간 경계에서만 일어나 텐서 병렬보다 훨씬 가볍습니다. 문제는 파이프라인 거품(bubble)입니다. 첫 카드가 계산하는 동안 뒤쪽 카드는 놀고, 마지막 카드가 일할 때 앞쪽이 놉니다. 이 유휴를 줄이려고 마이크로 배치를 잘게 쪼개 흘려보내지만, 거품을 완전히 없애지는 못합니다. 지연 시간에 민감한 서비스라면 이 거품이 체감 성능을 갉아먹습니다.

전문가 병렬은 혼합 전문가(MoE) 구조에서 전문가 네트워크들을 카드별로 흩어 놓는 방식입니다. 토큰마다 소수의 전문가만 활성화되므로 총 파라미터는 거대해도 실제 계산량은 작습니다. 대신 어떤 토큰이 어떤 카드의 전문가로 가야 하는지를 라우팅하는 모두 대 모두 교환(all-to-all) 통신이 새로 생깁니다. 이 통신 패턴은 불규칙하고 부하가 치우치기 쉬워, 특정 전문가에 토큰이 몰리면 그 카드만 과부하가 걸립니다. 병렬화는 만능이 아니라 저마다 다른 병목을 새로 불러온다는 점을 늘 염두에 두어야 합니다.

여러 요청을 한 번에, 배치와 스케줄링이 대역폭을 살리는 법

앞서 배치 1 디코딩은 연산 강도가 극도로 낮아 연산기를 거의 놀린다고 했습니다. 뒤집어 보면, 같은 가중치를 여러 요청이 함께 쓰게 만들면 이 낭비를 크게 줄일 수 있습니다. 가중치를 HBM에서 한 번 읽어 오는 동안 요청 하나가 아니라 열 개, 스무 개의 토큰을 동시에 계산하면, 읽어 온 바이트당 연산량이 그만큼 올라갑니다. 루프라인의 점이 왼쪽 경사면을 타고 오른쪽으로 이동합니다. 배치가 대역폭 병목을 완화하는 핵심 수단인 이유가 여기 있습니다.

문제는 요청마다 도착 시점도 다르고 생성 길이도 제각각이라는 점입니다. 예전 방식처럼 한 배치가 모두 끝날 때까지 기다렸다가 다음 배치를 받으면, 짧은 요청이 긴 요청에 발이 묶여 하염없이 대기합니다. 이를 풀어낸 것이 연속 배치(continuous batching)입니다. 배치를 고정하지 않고 생성 단계마다 새 요청을 끼워 넣고 끝난 요청은 빼냅니다. 자리가 비는 즉시 채우니 가속기가 노는 시간이 크게 줄어듭니다. vLLM 같은 추론 엔진이 이 방식을 앞세워 처리량을 끌어올린 것도 같은 원리입니다.

여기에 본문에서 본 PagedAttention이 결합하면 효과가 커집니다. 요청마다 최대 길이만큼 KV 캐시를 미리 잡지 않고 실제 생성한 만큼만 페이지를 붙여 쓰니, 같은 HBM 용량으로 더 많은 요청을 한 배치에 담을 수 있습니다. 배치를 키우려면 메모리가 있어야 하고, 메모리를 아끼면 배치를 키울 수 있다는 선순환이 만들어집니다.

다만 배치를 무한정 키운다고 좋은 것은 아닙니다. 배치가 커지면 개별 요청의 지연 시간이 늘고, KV 캐시 압박도 다시 커집니다. 처리량과 지연 시간은 저울의 양 끝입니다. 대화형 서비스라면 첫 토큰까지의 지연(TTFT)을 지키려고 배치를 절제해야 하고, 대량 일괄 처리라면 지연을 양보하고 배치를 최대로 밀어붙이는 편이 이득입니다. 스케줄링이란 결국 이 저울을 서비스 성격에 맞게 기울이는 기술입니다. 하드웨어 사양이 같아도 스케줄러 설계에 따라 실효 성능이 크게 갈리는 까닭이 여기에 있습니다.