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

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

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

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

Google 연구진이 제시한 LLM 추론의 3대 병목 요인

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라고 합니다.

LLM 추론에서 데이터의 흐름

ⓒ deep daiv.

💡연산 밀도(Arithmetic Intensity)

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

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

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

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

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

HBM의 한계를 넘는 Google의 제안, HBF

앞서 살펴본 것처럼 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를 개발하고 있습니다.

NVIDIA의 ICMS: HBM의 속도와 SSD의 용량을 결합하다

Google이 HBF라는 새로운 하드웨어 구조를 제안했다면, GPU 시장의 절대강자 NVIDIA는 시스템 차원에서 해법을 내놓았습니다. 바로 ICMS(Inference Context Memory Storage)입니다.

최근 CES 2026에서 젠슨 황은 ‘HBM만으로 GPU의 컴퓨팅을 지원하기에는 턱없이 부족하며, 메모리 병목 현상은 더 심화되고 있다’고 강조하며 이 플랫폼을 공개했습니다.

ICMS: HBM과 SSD를 장점을 결합한 하이브리드 아키텍처

ⓒ deep daiv.

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

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

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

DeepSeek의 Engram: 뻔한 건 외워두자

앞서 Google과 NVIDIA가 하드웨어와 이를 둘러싼 플랫폼에서 문제를 해결하려 했다면, DeepSeek는 '모델이 데이터를 처리하는 방식' 자체를 바꾸는 소프트웨어적인 해법을 제시했습니다. 바로 최근 <Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models> 논문에서 공개한 ‘Engram’ 기술입니다.

기존 Transformer 구조에서는 ‘San Francisco’나 ‘New York City’처럼 거의 한 단어처럼 붙어 다니는 고유명사를 출력할 때에도, GPU 메모리 연산 레이어에서 매번 관계를 재구성하여 계산해야 합니다. ‘San’이 나오면 ‘Francisco’가 나온다는 것은 굳이 생각할 필요도 없는 뻔한 패턴인데도, 비싼 GPU 자원을 소모하는 것이죠.

DeepSeek 연구진은 여기서 의문을 가졌습니다. "이미 답이 정해진 뻔한 표현까지, 굳이 매번 뇌(GPU)를 풀가동해 다시 계산해야 할까? 그냥 옆에 있는 답안지(외부 메모리)를 보고 바로 옮겨 적으면 안 될까?"

이것이 바로 ‘조건부 메모리(Conditional Memory)’, 즉 Engram의 핵심 아이디어입니다. 자주 반복되는 단어 패턴(N-gram)이나 변하지 않는 지식은 GPU 밖의 거대한 룩업 테이블(Lookup Table)에 미리 저장해 두고, 추론할 때 연산 없이 룩업 테이블에서 결괏값만 쏙쏙 뽑아서 쓰는 방식입니다. 이렇게 하면 불필요한 연산을 건너뛸 수 있어, 추론 속도는 빨라지고 비용은 획기적으로 줄어듭니다. 이렇게 하면 비싼 HBM 용량을 낭비하지 않고도 훨씬 더 많은 지식을 다룰 수 있게 됩니다. 업계에서는 이 기술이 다가오는 2월 출시 예정인 DeepSeek-V4의 핵심 아키텍처가 될 것이라고 보고 있습니다.

연구진은 “우리는 조건부 메모리가 차세대 희소 모델(Sparse Model)을 위한 필수적인 모델링 기본 요소라고 생각한다.”라고 강조합니다. 여기서 희소 모델은 한 번의 추론에서 모델 전체의 파라미터를 다 써서 연산하지 않고, 토큰이나 상황에 따라 일부 모듈만 선택적으로 활성화하여 계산하는 모델을 말합니다. 대표적으로 MoE 아키텍처가 희소 모델 아키텍처이죠.

Engram은 기존의 MoE 아키텍처를 대체하는 게 아니라, 서로 상호 보완적인 관계에서 모델의 성능을 극대화합니다. MoE는 동적인 계산(Dynamic Computation)에 집중한다면, Engram은 정적인 지식(Static Knowledge)을 제공하는 역할을 합니다.

실제로 연구진이 테스트한 결과, 모델 전체 용량의 약 20~25%를 Engram 메모리에 할당하고 나머지 75~80%를 MoE에 할당했을 때 가장 뛰어난 성능을 보였으며, 두 축 간의 U자형 스케일링 법칙을 발견했습니다.

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

앞으로 AI 추론 성능을 바꿀 기술은?

정리하면 이렇습니다. 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 혁신은 새로운 알고리즘이 아니라, 데이터가 이동하는 길목 어딘가에서 나올지도 모릅니다.