주제 탐구 · 2026-11-06 · 기초 · 작성자 bombong
AI 반도체: GPU·TPU·NPU, 그리고 진짜 병목인 메모리 대역폭
AI 칩의 실제 속도는 연산 성능보다 메모리에서 데이터를 얼마나 빨리 가져오느냐에 더 크게 좌우될 때가 많다. 이 글은 GPU·TPU·NPU가 어떻게 다른지, LLM 추론에서 왜 메모리 벽이 생기는지, 연구자들이 이 벽을 어떤 방법으로 넘으려 하는지 정리한다.
목차
- LLM이 답을 한 토큰씩 만드는 디코딩 단계에서는 계산보다 가중치·KV 캐시를 메모리에서 읽어 오는 일이 병목이 되기 쉽다. 이를 '메모리 벽'이라 부른다.
- GPU·TPU·NPU는 모두 행렬 곱을 빠르게 하려는 칩이다. 서로 다른 점은 범용성, 소프트웨어 생태계, 어디에 쓰려고 만들었는지다.
- 메모리 벽에 대한 대응은 세 갈래다. 읽는 횟수를 줄이고(추측 디코딩·KV 압축), 메모리 안에서 계산하고(PIM), 값싼 칩 여러 개를 빠른 연결로 묶는다.
- 칩을 고를 때는 FLOPS 표보다 메모리 대역폭·용량, 칩 사이 연결 속도, 소프트웨어 성숙도, 달러·전력당 토큰 수를 함께 봐야 한다.
- 논문에 나온 가속 배수는 특정 모델과 설정에서 잰 값이다. 내 워크로드에서도 그만큼 빨라진다는 보장은 없다.
왜 칩 이야기가 메모리 이야기가 됐나
AI 반도체라고 하면 흔히 '연산을 얼마나 빨리 하나'를 떠올린다. 칩 사양표 맨 위에 FLOPS(초당 부동소수점 연산 횟수)가 적히는 것도 그래서다. 그런데 대규모 언어 모델(LLM)을 실제로 서비스해 보면 연산 장치가 놀고 있는 시간이 생각보다 길다. 계산할 재료가 메모리에서 아직 도착하지 않았기 때문이다.
이유는 LLM이 글을 만드는 방식에 있다. LLM은 자기회귀 모델이라서 토큰을 한 번에 하나씩 만들고, 그 토큰을 다시 입력에 붙여 다음 토큰을 만든다. 토큰 하나를 만들 때마다 모델의 가중치 대부분을 메모리에서 다시 읽어야 한다. 그런데 한 번 읽은 가중치로 하는 계산은 행렬과 벡터 하나를 곱하는 정도다. DRAM 내부 병렬 연산 연구논문는 엣지 기기에서 자기회귀 디코딩 시간 대부분이 메모리에 묶인 행렬-벡터 곱(GeMV)에 쓰인다고 지적한다.
NPU용 추측 디코딩 연구논문도 NPU 하드웨어에서 LLM을 추론할 때 부딪히는 문제를 '메모리 벽(Memory Wall)'이라고 부른다. 연산 장치가 아무리 빨라져도 메모리 대역폭(초당 옮길 수 있는 데이터 양)이 따라오지 못하면 전체 속도는 메모리 쪽에 맞춰진다. 그래서 요즘 AI 칩 경쟁은 연산기보다 메모리와 데이터 이동을 둘러싸고 벌어지는 경우가 많다.
핵심 아이디어: 요리사보다 식재료 운반이 느린 주방
식당 주방을 떠올려 보자. 요리사(연산 장치)는 손이 아주 빠르지만, 식재료는 멀리 있는 창고(메모리)에서 한 번에 정해진 양만 실어 온다. 손님 한 명의 요리를 한 숟갈씩 만드는데 숟갈마다 창고에서 재료 전부를 다시 가져와야 한다면, 요리사를 아무리 늘려도 음식이 나오는 속도는 운반 속도를 넘지 못한다.
이 비유로 보면 칩 설계자가 할 수 있는 일은 크게 셋이다. 첫째, 통로를 넓힌다. 칩 바로 옆에 메모리를 쌓아 올려 대역폭을 키운 HBM(고대역폭 메모리)이 이 방향이다. 둘째, 한 번 실어 온 재료로 여러 그릇을 만든다. 여러 요청을 묶어 처리하는 배치 처리나 여러 토큰을 한꺼번에 검증하는 추측 디코딩이 여기에 해당한다. 셋째, 창고 안에서 요리한다. 메모리 내부에서 계산하는 PIM(Processing-In-Memory)이 이 아이디어다.
같은 비유로 GPU·TPU·NPU의 차이도 설명할 수 있다. 셋 다 '빠른 요리사'를 많이 둔 주방이지만, 어떤 요리를 주로 하려고 지었는지, 주방 도구(소프트웨어)가 얼마나 갖춰졌는지가 다르다.
GPU·TPU·NPU는 무엇이 다른가
GPU(그래픽 처리 장치)는 원래 화면의 수많은 점을 동시에 계산하려고 만든 칩이다. 같은 계산을 대량으로 병렬 처리하는 구조가 신경망의 행렬 곱과 잘 맞아 AI 학습과 추론에 널리 쓰이게 됐다. GPU의 가장 큰 강점은 하드웨어 자체보다 CUDA라는 프로그래밍 생태계다. 개발자와 라이브러리, 추론 엔진이 대부분 이 위에서 먼저 만들어진다.
TPU(텐서 처리 장치)는 구글이 신경망의 행렬 연산에 맞춰 설계한 전용 칩이다. 범용성을 줄인 대신 행렬 곱을 효율적으로 흘려 보내는 데 집중했다. NPU(신경망 처리 장치)는 신경망 연산에 특화한 칩을 넓게 부르는 말로, 스마트폰·엣지 기기 안의 작은 칩부터 데이터센터용 추론 칩까지 포함한다. Groq의 TSP처럼 캐시나 하드웨어 스케줄러를 아예 빼고 컴파일러가 모든 연산 시점을 미리 정하는 정적 스케줄링 칩도 이 계열의 한 극단이다.
전용 칩일수록 특정 연산에서 전력과 비용 효율이 좋아질 수 있다. 대신 소프트웨어가 따라오지 않으면 그 장점을 쓰지 못한다. NPU 추측 디코딩 연구논문가 출발점으로 삼은 문제도 국내(중국) 인프라에서 주류 추측 디코딩 알고리즘을 기본 지원하지 않는다는 점이었다. GPU에서는 당연히 되는 최적화가 새 칩에서는 직접 다시 만들어야 하는 숙제가 된다. 이것이 범용 칩과 전용 칩 사이에서 맞바꾸는 핵심이다.
GPU·TPU·NPU 한눈에 비교
GPU범용 병렬 칩
- 학습·추론 모두 널리 쓰임
- CUDA 생태계가 최대 강점
- 새 최적화가 먼저 나오는 곳
TPU구글의 행렬 연산 전용 칩
- 행렬 곱에 집중한 설계
- 범용성을 줄이고 효율을 택함
NPU신경망 특화 칩 전반
- 엣지 기기부터 데이터센터 추론까지
- 전력·비용 효율을 노림
- 소프트웨어 지원이 숙제
공통 셋 다 결국 메모리에서 데이터를 얼마나 빨리 가져오느냐에 속도가 묶인다
어떻게 작동하나: 추론 한 번이 메모리를 쓰는 방식
LLM 추론은 두 단계로 나뉜다. 첫 단계인 프리필(prefill)은 사용자가 보낸 프롬프트 전체를 한꺼번에 처리한다. 토큰 여러 개를 동시에 계산하므로 한 번 읽어 온 가중치를 여러 번 재사용할 수 있고, 연산 장치를 꽉 채우기 쉽다. 이 단계에서 각 토큰의 중간 계산 결과를 KV 캐시에 저장해 둔다. 다음 단계에서 같은 계산을 반복하지 않으려는 것이다.
두 번째 단계인 디코딩은 토큰을 하나씩 만든다. 토큰 하나를 만들려면 모델 가중치와 지금까지 쌓인 KV 캐시를 메모리에서 읽고, 계산하고, 결과 토큰을 다시 입력으로 넣는다. 한 번 읽은 데이터로 하는 계산량이 적어서 이 단계는 메모리 대역폭에 묶인다. 대화가 길어질수록 KV 캐시도 커진다. 그래서 LoopServe논문는 대화 기록이 길어질수록 LLM의 계산·메모리 부담이 함께 커진다고 짚는다.
정리하면 '메모리 용량'은 모델 가중치와 KV 캐시를 칩 안에 담을 수 있는지를 정하고, '메모리 대역폭'은 디코딩 속도를 정한다. 사용자 체감으로 옮기면 프리필은 첫 토큰까지 걸리는 시간(TTFT)에, 디코딩은 그 뒤 글이 흘러나오는 속도에 주로 영향을 준다.
발전 흐름: 메모리 벽을 넘으려는 세 가지 시도
첫 번째는 메모리를 덜 읽는 알고리즘이다. 추측 디코딩은 작은 모델이 다음 토큰 몇 개를 미리 짐작하고, 큰 모델이 그 후보를 한 번에 검증하게 한다. 큰 모델의 가중치를 한 번 읽어서 토큰 여러 개를 확정할 수 있으니 메모리 왕복이 줄어든다. NPU용 추측 디코딩 연구논문는 이 기법을 NPU에서 돌아가도록 OpenPangu-7B 모델에 끝에서 끝까지(end-to-end) 이어지는 추측 추론 가속 체계로 구현했다. 같은 계열에서 계층적 검증 트리 연구논문는 가능성이 높은 후보부터 검증하고 가망 없는 후보를 일찍 쳐내는 방식으로 추론 시간과 에너지를 줄였다고 보고했다.
두 번째는 KV 캐시를 똑똑하게 줄이는 방법이다. LoopServe논문는 프리필 단계에서 입력마다 어텐션 행렬의 중요한 부분만 골라 계산하고, 디코딩 단계에서는 최근 생성된 토큰을 기준으로 KV 캐시를 점진적으로 압축한다. 위치만 보고 고정된 규칙으로 자르는 방식은 실제 대화의 흐름을 따라가지 못한다는 문제의식에서 나왔다. 이 연구는 실제 질문 위치와 대화 의존성을 반영한 멀티턴 데이터셋 11개짜리 벤치마크도 함께 냈다.
세 번째는 하드웨어 구조 자체를 바꾸는 방향, 즉 메모리 안에서 계산하는 PIM이다. PRIMAL논문은 PIM 기반 LLM 추론 가속기에 LoRA(저랭크 적응)를 결합했다. 여러 종류의 PIM 처리 장치를 2차원 격자 네트워크로 잇고, SRAM 재프로그래밍과 쉬는 부분의 전원을 끄는 방식으로 LoRA 교체와 계산을 겹쳐 처리한다. Llama-13B에 LoRA 랭크 8을 적용한 설정에서 NVIDIA H100 대비 처리량 1.5배, 에너지 효율 25배를 보고했다. 데이터를 운반하지 않고 창고 안에서 요리하면 전력 효율이 크게 좋아질 수 있다는 사례다.
요즘 어디로 가고 있나
최근 연구는 메모리 안 계산을 더 깊이 파고들고 있다. DRAM 내부 병렬 연산 연구논문는 DRAM 안에서 직접 계산하는 PUD(Processing-using-DRAM)로 디코딩의 GeMV를 처리한다. DRAM은 6만 5,536개 열에서 동시에 계산할 수 있을 만큼 병렬성이 크다. 그런데 Llama3 8B의 QKV 행렬이 6,144행에 그치는 것처럼 LLM 한 층의 가중치는 이 병렬성을 다 채우기에 작다. 연구진은 다음 층의 계산을 현재 층과 함께 묶어 넣는 알고리즘과, DRAM 구조에 맞춘 데이터 배치를 함께 설계했다. 그 결과 PUD 기준선보다 최대 1.41배, 프로세서 기반 실행보다 2.45배 빠른 디코딩을 보고했다.
두 번째 흐름은 '칩 하나'가 아니라 '칩 묶음'의 효율을 따지는 것이다. 클러스터 효율 연구논문는 값싼 가속기는 칩 하나의 메모리가 작아 여러 개를 묶어야 하고, 그러면 칩 사이 통신이 성패를 가른다고 본다. Blackhole 칩을 묶은 Tenstorrent Galaxy에서 통신과 계산을 겹치는 등 최적화한 결과, 3년 구매·전기료 기준으로 RTX PRO 6000 Blackwell GPU 8장 서버 대비 달러당 토큰 수가 1.07~2.24배였다. 반대로 같은 칩에서 통신을 TCP 수준으로 느리게 흉내 내자 처리량이 23.5~67.4% 떨어졌고, 평가한 모든 설정에서 비용 우위가 사라졌다. 칩 사이를 잇는 인터커넥트가 메모리 대역폭만큼 중요하다는 뜻이다.
세 번째 흐름은 새 칩의 약점인 소프트웨어를 AI로 메우려는 시도다. 멀티 에이전트 커널 최적화 연구논문에 따르면 최신 LLM은 단일 연산 CUDA 커널은 대부분 맞게 작성하지만, 거의 본 적 없는 칩과 언어 앞에서는 정확도가 무너진다. 연구진은 문서가 부족한 Rust 기반 언어로 프로그래밍하는 FuriosaAI RNGD NPU를 대상으로 에이전트 루프를 만들었다. 에이전트는 문서 요약을 직접 쓰고 검증하며, 칩 성능을 측정하고, 컴파일러 규칙을 기록했다. 12일 동안 Gemma-4-12B 디코딩 커널 3개를 최적화해 공식 기준 대비 기하평균 9.293배 속도를 냈다. 각 커널은 가중치를 옮기는 데만 필요한 사이클의 1.25배 이내까지 다가갔다. 결국 최적화의 천장도 메모리 이동량이라는 점이 다시 확인된다.
최근 연구가 보고한 수치
한계와 쟁점, 그리고 실무 판단 기준
가장 흔한 실수는 칩을 FLOPS 숫자로만 비교하는 것이다. 챗봇·코딩 에이전트처럼 긴 답을 생성하는 서비스는 디코딩 비중이 커서 메모리 대역폭과 용량이 체감 속도를 좌우한다. 긴 컨텍스트를 다룬다면 KV 캐시가 들어갈 메모리 용량부터 따져야 한다. 여러 칩을 묶어 쓸 계획이라면 클러스터 효율 연구논문가 보여 주듯 인터커넥트가 느릴 때 비용 우위가 통째로 사라질 수 있다.
두 번째 실수는 논문 수치를 일반화하는 것이다. PRIMAL논문의 에너지 효율 25배는 Llama-13B와 LoRA 랭크 8이라는 특정 설정에서 잰 값이다. Galaxy의 결과도 특정 모델과 3년 비용 모델을 전제로 한다. PIM 연구 상당수는 실제 양산 칩이 아니라 설계·모의 실험 단계라는 점도 염두에 둬야 한다. 비교 기준이 무엇인지(H100인지, 같은 계열의 기준선인지)도 꼭 확인해야 한다. DRAM 내부 연산 연구논문의 1.41배와 2.45배는 기준이 달라서 생긴 차이다.
세 번째는 소프트웨어 성숙도를 과소평가하는 것이다. 전용 NPU는 하드웨어 효율이 좋아도 추측 디코딩 같은 최적화를 기본 지원하지 않을 수 있다논문. 커널을 짜는 데도 큰 노력이 든다. 멀티 에이전트 커널 연구논문에서도 장비 시간이 부족하고 측정값에 잡음이 많아 12일이 걸렸다. 도입을 판단할 때는 지금 쓰는 모델과 추론 엔진이 그 칩에서 바로 돌아가는지부터 확인하는 편이 안전하다.
실무 지표로는 '초당 토큰'만 보지 말고 '달러당 토큰'과 '전력(줄)당 토큰'을 함께 보는 습관이 좋다. 칩 하나가 빨라도 여러 장을 묶어야 하거나 전기를 많이 쓰면 총비용은 달라진다.
AI 칩 고를 때 점검 목록
메모리
- 가중치와 KV 캐시가 메모리에 다 들어가는가
- 디코딩 비중이 큰 서비스라면 대역폭을 먼저 봤는가
연결·비용
- 여러 칩을 묶을 때 인터커넥트가 충분히 빠른가
- 달러당·전력당 토큰으로 비교했는가
소프트웨어
- 쓰는 모델과 추론 엔진이 바로 돌아가는가
- 추측 디코딩 같은 최적화를 기본 지원하는가
수치 해석
- 논문 수치의 모델·설정·기준선을 확인했는가
- 모의 실험인지 실제 칩 측정인지 구분했는가
더 공부하려면
메모리 벽이라는 문제 자체를 감 잡으려면 DRAM 내부 병렬 연산 연구논문의 문제 설명 부분을 먼저 읽기를 권한다. 디코딩이 왜 메모리에 묶이는지, 하드웨어의 병렬성과 모델 크기가 왜 맞지 않는지가 구체적인 숫자로 나온다.
알고리즘 쪽 대응은 NPU 추측 디코딩 연구논문와 LoopServe논문를 차례로 보면 '덜 읽기' 전략의 두 갈래(토큰을 묶어 검증하기, KV 캐시 줄이기)를 비교할 수 있다. 하드웨어 쪽은 PRIMAL논문이 PIM 가속기 설계를 보는 입구로 좋다.
실제 도입을 고민하는 독자라면 클러스터 효율 연구논문를 추천한다. 칩 가격, 전기료, 인터커넥트가 어떻게 하나의 비용 지표로 묶이는지 보여 준다. 새로운 NPU의 소프트웨어 문제에 관심이 있다면 멀티 에이전트 커널 최적화 연구논문가 현장의 어려움을 솔직하게 기록하고 있다.
관련 용어
참고 문헌
핵심 논문
- Accelerating OpenPangu Inference on NPU via Speculative Decoding (2026)
- LoopServe: An Adaptive Dual-phase LLM Inference Acceleration System for Multi-Turn Dialogues (2025)
- Hierarchical Verification of Speculative Beams for Accelerating LLM Inference (2025)
- PRIMAL: Processing-In-Memory Based Low-Rank Adaptation for LLM Inference Accelerator (2026)
최근 연구
AI가 참고 문헌을 바탕으로 작성하고 검수를 거친 해설입니다. 정확한 내용은 원문을 확인해 주세요.