안녕하세요, 에디터 쏘입니다 :)

이전 뉴스레터에서 다룬 MoE(Mixture of Experts), 추론 모델(Reasoning Model), RAG, 멀티모달(Multimodal)과 같은 트렌드 기억하시나요?

이 기술들은 더 똑똑한 AI를 만들지만, 공통적으로 더 길고 복잡한 연산이라는 부작용을 낳습니다. 모델이 처리해야 할 데이터가 방대해지고 생각의 깊이 깊어지면서, 실제 서비스 단계인 추론(Inference)에서 속도가 느려지고 비용이 가파르게 늘어나는 문제가 발생한 것입니다.

이 문제를 해결하려면 모델 자체의 최적화도 중요하지만, 결국 거대한 데이터를 나르고 계산하는 ‘물리적 하드웨어’의 한계를 넘어서야 합니다.

최근 Google DeepMind 연구진은 <Challenges and Research Directions for Large Language Model Inference Hardware> 논문은 추론을 느리게 만드는 병목 현상의 원인과 해결책을 정리했습니다.

오늘은 이 논문과 함께, 추론 효율성을 높이기 위해 진행되고 있는 하드웨어와 AI 분야의 따끈따끈한 최신 연구들을 소개하겠습니다.

  

A100, H100 같은 GPU 이름을 들어보셨나요? AI 시대에 GPU 연산 성능은 매우 중요합니다. 하지만 GPU 연산이 빠르다고 AI가 빠르게 동작하는 것은 아닙니다. GPU가 한 번에 아무리 많은 연산을 할 수 있더라도, GPU의 연산 속도만큼 데이터를 빠르게 전달해 주지 못한다면 연산은 대기 상태가 됩니다. 이것이 바로 '병목(Bottleneck)’입니다.

이때 연산장치가 쉴 새 없이 일할 수 있도록 데이터를 빠르게 읽고 전달해 주는 역할을 하는 것이 바로 HBM(High Bandwidth Memory, 고대역폭 메모리)입니다.

HBM은 데이터 처리 속도가 매우 빠른 DRAM을 수직으로 쌓아 올려 만든 적층 메모리입니다. 우리가 흔히 아는 HDD나 SSD 같은 저장장치는 전원이 꺼져도 데이터가 남는 비휘발성이지만, HBM의 재료인 DRAM은 전원이 꺼지면 정보가 사라지는 휘발성 메모리입니다.

그렇다면 데이터가 날아가는 단점이 있는데도 왜 굳이 DRAM을 쓸까요? 이유는 압도적인 속도 때문입니다. 현재 기술로는 DRAM만큼 GPU의 엄청난 속도를 맞춰줄 수 있는 다른 메모리가 없습니다. 이렇게 고성능 GPU와 HBM을 하나의 패키지로 묶은 반도체 세트를 ‘AI 가속기(Accelerator)’라고 부릅니다.

지금도 LLM이 추론할 때 가장 바쁘게 오가는 모델의 가중치(Weights), KV-Cache, 중간 계산값들은 모두 이 비싸고 빠른 HBM 위에서 돌아가고 있습니다.

  

하드웨어 병목을 이해하려면 먼저 추론 구조를 알아야 합니다. Transformer 기반 LLM 추론은 크게 두 단계로 나뉩니다. ‘프리필(Prefill)’은 사용자의 질문을 한 번에 읽고 이해하는 단계입니다. 모든 토큰을 병렬적으로 처리하므로 속도가 빠릅니다. ‘디코드(Decode)’는 답변을 한 토큰씩 생성하는 단계입니다. 여기가 문제입니다.

디코드 단계는 앞 단어가 나와야 뒤 단어를 예측할 수 있는 순차적(Autoregressive) 방식입니다. 이때 다음 토큰을 만들기 위해서는 지금까지 나눈 대화의 맥락(과거 토큰들)을 모두 참조해야 합니다. 이게 Self-Attention 메커니즘이죠.

문제는 토큰 하나를 만들 때마다 과거 데이터를 매번 다시 계산하면 시간이 너무 오래 걸린다는 점입니다. 그래서 실무에서는 과거 계산 결과(Key/Value)를 KV-Cache라는 형태로 HBM에 저장해두고 재사용합니다.

하지만 KV-Cache는 대화가 길어질수록(Long-Context), 생각이 깊어질수록(Reasoning) 기하급수적으로 커집니다. 결국 데이터가 커질수록 HBM이 감당해야 할 부담이 늘어나고, 여기서 심각한 병목이 발생하게 됩니다.

 

Google 연구진은 LLM 추론 속도를 떨어뜨리는 병목 요인을 ① 메모리 대역폭, ② 메모리 용량, ③ 통신 지연 세 가지로 분류합니다.

메모리 대역폭(Memory Bandwidth)은 메모리와 연산 장치 사이에서 1초에 얼마나 많은 데이터를 옮길 수 있는지(GB/s)를 의미합니다. 디코드 단계에서 GPU 내부를 들여다보면 왜 이것이 병목인지 알 수 있습니다.

LLM 추론에서 핵심 연산인 Attention은 GPU의 기본 작업 단위인 SM(Streaming Multiprocessor) 내부의 ‘텐서 코어(Tensor Core)’에서 수행됩니다. 연산하려면 HBM에 있는 데이터(KV-Cache, 모델 가중치)를 코어 바로 옆에 있는 초고속 임시 메모리인 SRAM으로 가져와야 합니다.

이때 KV-Cache는 계속 재사용되므로 SRAM에 최대한 오래 붙잡아 두려 노력하지만, 시퀀스가 길어져 용량이 커지면 결국 HBM을 오가게 됩니다. 모델 가중치는 용량이 매우 커서 SRAM에 계속 둘 수 없습니다. 따라서 매 토큰을 생성할 때마다 거대한 모델 전체를 HBM에서 SRAM으로 끊임없이 이동시켜야 합니다.

결국 텐서 코어의 연산 속도가 아무리 빨라도, HBM에서 SRAM으로 방대한 데이터를 옮기는 시간을 기다리느라 추론 시간의 대부분이 소요됩니다. 대역폭이 좁을수록 데이터를 옮기는 시간이 더 오래 걸립니다. 이렇듯 코어에서 계산할 준비가 되어 있어도 데이터가 늦게 도착해서 그동안 계산을 하지 못하고 대기 상태가 되는 것을 Memory-Bound라고 합니다.

  

이 현상을 설명하는 주요 개념이 ‘연산 밀도(Arithmetic Intensity)’입니다. ‘연산량(FLOPS) ÷ 메모리로부터 옮긴 데이터량(Bytes)’으로 정의되며, 데이터를 한 번 읽어와서 몇 번의 연산을 수행하는지 나타냅니다.

디코드 단계는 매 스탭마다 모델 전체 가중치와 KV-Cache를 읽어와야 하므로 데이터 전송량은 매우 크지만, 연산 횟수는 상대적으로 적습니다. 즉, 연산 밀도가 낮아 Memory-Bound가 발생하기 쉬우며, 결과적으로 메모리 대역폭이 전체 성능을 결정짓게 됩니다.

메모리 용량(Memory Capacity)은 한 번에 메모리에 얼마나 많은 데이터를 올릴 수 있는지를 말합니다. 추론 중 메모리를 점유하는 두 가지 주요 요소는 다음과 같습니다. 모델 가중치는 모델의 크기에 비례하고, 고정적인 용량을 차지합니다. KV-cache는 입력 프롬프트와 생성된 출력 길이에 비례하여 동적으로 계속 커집니다.

단일 GPU의 HBM 용량 부족으로 인해 모델 가중치와 KV-Cache를 다 담을 수 없는 경우, 여러 GPU(또는 여러 서버)에 모델을 쪼개서 올리는 분산 처리(Model Parallelism)가 필요합니다.

이 경우 각 GPU가 계산한 중간 결과를 합치기 위해 서버 간 통신이 필수로 발생합니다. 이때 발생하는 데이터 전송 시간을 인터커넥트 지연(Interconnect Latency)이라고 하며, 이는 전체 추론 속도를 늦추는 세 번째 병목 요인이 됩니다.

  

앞서 살펴본 것처럼 HBM은 현존하는 메모리 중 가장 빠르지만, 용량이 작고 가격이 비싸다는 치명적인 한계가 있습니다. 용량이 부족하니 거대한 모델을 담기 위해 여러 대의 GPU를 연결해야 하고, 이 과정에서 GPU끼리 데이터를 주고받느라 인터커넥트 지연이라는 또 다른 병목이 발생했죠.

Google 연구진은 이 논문에서 이러한 메모리 용량 문제를 해결할 유력한 연구 방향으로 HBF(High Bandwidth Flash, 고대역폭 플래시)를 지목했습니다.

HBM이 속도가 빠른 DRAM을 쌓아 올린 것이라면, HBF는 전원이 꺼져도 데이터가 날아가지 않는 ‘낸드 플래시(NAND Flash)’를 층층이 쌓아 올린 메모리입니다. 보통 SSD에 쓰이는 낸드 플래시는 GPU와 멀리 떨어져 있어 속도가 느렸지만, HBF는 이를 HBM처럼 GPU 바로 옆에 붙이고 데이터 통로를 뚫는 방식으로 이 문제를 해결했습니다. 덕분에 기존 HBM 수준의 대역폭을 유지하면서도, 저장 용량은 무려 10배 가까이 늘릴 수 있게 되었죠.

HBF는 HBM을 대체하기보다는 서로의 단점을 채워주는 보완재가 됩니다. HBF는 데이터를 한 번에 많이 보내는 능력은 뛰어나지만, 데이터를 찾아서 반응하는 속도는 여전히 HBM을 따라갈 수 없기 때문입니다. 그래서 이 논문에서는 두 메모리의 특성에 맞춘 역할 분담을 강조합니다.

매 순간 빠르게 변하고 즉각적인 반응이 필요한 KV-Cache는 빠른 HBM에 두고, 덩치가 크지만, 내용이 변하지 않는 모델의 가중치는 용량이 넉넉한 HBF에 저장하는 식이죠. 이렇게 하면 비싼 HBM 공간을 아낄 수 있어 동일한 모델을 더 적은 수의 GPU로 구동할 수 있습니다. 결과적으로 GPU 간의 불필요한 통신이 줄어들어, 전체적인 추론 속도가 빨라지는 효과를 얻게 됩니다. 즉, HBF로 단순히 저장 공간만 늘리는 것이 아니라, 시스템의 효율성을 높여 통신 병목까지 해결하는 전략적인 접근인 셈입니다. 현재 SanDisk, SK하이닉스, 삼성 등 주요 메모리 제조사도 이런 흐름에 발맞춰 HBF를 개발하고 있습니다.

  

ICMS의 핵심은 ‘GPU 외부에 있는 저장장치(SSD)를 마치 HBM의 연장선처럼 활용하겠다’라는 것입니다. 데이터 전송 속도가 매우 빠른 고속 SSD 인터페이스(NVMe) 등을 활용해, 용량이 큰 컨텍스트와 캐시 데이터를 외부 저장장치로 빼내겠다는 전략이죠. NVIDIA는 차세대 칩인 Vera Rubin부터 이 기술을 적극 도입하겠다고 밝혔습니다.

앞서 본 HBF가 낸드 플래시를 GPU 옆에 쌓아 올리는 ‘하드웨어적인 혁신’이라면, ICMS는 이미 널리 쓰이는 SSD를 소프트웨어와 시스템 최적화를 통해 메모리 계층으로 끌어들이는 ‘플랫폼적인 혁신’이라고 볼 수 있습니다.

정리하자면, HBF와 ICMS는 접근 방식은 다르지만 목표는 같습니다. 비싸고 용량이 작은 HBM에만 모든 짐을 지우지 말자는 것입니다. 두 기술 모두 HBM 바깥의 넉넉한 저장 공간(Nand Flash 또는 SSD)을 추론 과정에 적극적으로 개입시켜, 용량 부족과 비용 문제, 그리고 통신 지연이라는 병목을 동시에 해결하려는 필사적인 노력의 결과물이라 할 수 있습니다.

  

Engram은 이렇듯 모델의 사고 능력(Reasoning)과 지식 저장 능력(Knowledge Storage)을 분리하여, GPU 연산에 대한 의존도를 낮추려는 접근입니다. HBF와 ICMS가 하드웨어 차원에서 메모리 계층을 확장하는 것이라면, Engram은 모델 아키텍처 차원에서 지식을 외부로 분리하는 것이죠. 접근법은 다르지만, 세 기술 모두 HBM에 대한 절대 의존을 깨려 한다는 점에서 같은 방향을 향하고 있습니다.  

정리하면 이렇습니다. HBM은 현존하는 가장 빠른 메모리지만, 용량이 작습니다. 용량이 작으니 거대한 모델과 긴 컨텍스트를 담으려면 여러 GPU에 나눠 담아야 하고, GPU가 늘어날수록 서로 데이터를 주고받는 통신 시간도 늘어납니다.

결국 빠른 메모리를 쓰기 위해 느린 통신을 감수해야 하는 역설이 생긴 것이죠. 문제는 최근 AI 트렌드가 이 역설을 더 심화시키고 있다는 점입니다. Long-Context, Reasoning Model, Multimodal처럼 요즘 주목받는 기술들은 하나같이 더 많은 데이터를 더 오래 기억해야 합니다. KV-Cache는 점점 커지고, HBM의 용량 한계가 더욱 드러나고 있죠.

Google의 HBF, NVIDIA의 ICMS, DeepSeek의 Engram은 바로 이 문제를 해결하려는 시도입니다. 접근법은 다르지만 방향은 같습니다. "조금 느린 메모리를 써서, 통신 자체를 줄이자." HBM 하나에 모든 것을 욱여넣는 대신, 넉넉한 공간에 데이터를 펼쳐두고 GPU가 혼자서도 일할 수 있게 만드는 것이죠.

지난 몇 년간 AI 경쟁은 '더 큰 모델', '더 긴 컨텍스트'를 향해 달려왔습니다. 하지만 이제 경쟁의 축이 바뀌고 있습니다. 똑같은 모델이라도 얼마나 빠르고, 얼마나 싸게 굴릴 수 있느냐가 진짜 승부처가 된 것이죠.

Google, NVIDIA, DeepSeek가 거의 동시에 같은 방향을 가리킨 것은 우연이 아닐 겁니다. 이 기술들이 실제 서비스에 적용되기 시작하면, AI 추론의 비용과 속도는 또 한 번 큰 변곡점을 맞이할지도 모릅니다. 어쩌면 다음 AI 혁신은 새로운 알고리즘이 아니라, 데이터가 이동하는 길목 어딘가에서 나올지도 모릅니다.