목차
- 1. LLM의 계산은 사실상 한 종류다 — 행렬곱
- 2. 어텐션 해부 — Q·K·V가 실제로 하는 일
- 3. 어텐션의 대가 — 기억해야 할 것이 생겼다
- 4. 같은 수식, 다른 병목 — 학습과 추론이 갈리는 지점
- 5. 메모리 읽는 기계 — 토큰 하나 = 모델 전체 1회 통독
- 6. 그래서 반도체 지도가 이렇게 그려진다
- 부록. 그 대역폭은 누가 정하나
- 7. 자주 묻는 질문 (FAQ)
1. LLM의 계산은 사실상 한 종류다 — 행렬곱
수천억 파라미터, 수십 층의 신경망 — 복잡하게 들리지만, 그 안에서 벌어지는 계산의 종류는 놀랄 만큼 단순합니다. 거의 전부가 행렬곱(matrix multiplication)입니다.
모델의 "파라미터"라는 것의 정체가 바로 행렬입니다. 학습이 끝난 모델은 수백 개의 커다란 숫자표(행렬)로 저장되어 있고, 추론은 입력을 벡터로 바꿔 그 행렬들에 차례로 통과시키는 과정입니다. 토큰이 들어오면 벡터가 되고, 그 벡터에 행렬을 곱하고, 결과에 또 다음 행렬을 곱하고 — 수십 개 층을 지나 마지막에 "다음 토큰의 확률"이 나옵니다.
크기 감각을 잡아 두면 뒤 이야기가 쉬워집니다. 파라미터 70억 개(7B) 모델을 FP16(숫자 하나에 2바이트)으로 저장하면 약 14GB입니다. 175B면 350GB. 이 숫자표 전체가 계산의 재료이고, 이 재료를 어디에 두고 얼마나 빨리 꺼내 오느냐가 이 시리즈 전체를 관통하는 질문이 됩니다.
2. 어텐션 해부 — Q·K·V가 실제로 하는 일
1편에서 어텐션을 "모든 단어가 모든 단어를 한 번에 바라본다"까지만 말하고 멈췄습니다. 이제 그 안을 봅니다. 어텐션에서 각 토큰은 자신의 벡터로부터 세 개의 벡터를 만들어 냅니다 — 이것도 각각 행렬곱입니다.
- Q (query) — "내가 지금 찾고 있는 것"을 담은 벡터
- K (key) — "내가 가진 정보의 색인"을 담은 벡터
- V (value) — "내용물 그 자체"를 담은 벡터
작동은 도서관 검색과 닮았습니다. 한 토큰의 Q를 문장 안 모든 토큰의 K와 내적(dot product)해서 "얼마나 관련 있나"를 점수로 만들고, 그 점수를 확률로 바꿔(softmax) 모든 토큰의 V를 가중 평균합니다. "그 남자는 … 지쳤다"에서 '지쳤다'의 Q가 '남자'의 K와 강하게 반응하면, '남자'의 V가 많이 섞여 들어오는 식입니다. 거리가 멀어도 내적 한 번이면 연결되는 것 — 이게 1편에서 말한 "벽 2(장기 의존성)"가 무너진 실제 메커니즘입니다.
여기서 1편의 "연산량이 길이의 제곱"이라는 말의 정체도 드러납니다. 토큰이 1,000개면 Q·K 내적을 1,000×1,000번 해야 합니다. 그리고 이 모든 것 — Q·K·V를 만드는 것도, 내적도, 가중합도 — 전부 행렬 연산입니다. 어텐션은 특별한 마법이 아니라, 행렬곱을 문장 관계 계산에 배치한 구조입니다.
3. 어텐션의 대가 — 기억해야 할 것이 생겼다
어텐션 구조는 공짜가 아닙니다. LLM이 글을 생성하는 방식을 떠올려 보면 — 토큰을 하나 만들고, 그걸 문맥에 붙이고, 다시 다음 토큰을 만듭니다. 그런데 새 토큰의 Q는 지금까지의 모든 토큰의 K와 V를 상대해야 합니다.
매번 과거 토큰들의 K·V를 처음부터 다시 계산하면 낭비가 너무 큽니다. 그래서 실제 시스템은 한 번 계산한 K와 V를 저장해 두고 재사용합니다. 이것이 KV cache입니다. 계산을 아끼는 대신 저장 공간을 내주는 거래이고, 문맥이 길어질수록 이 캐시는 정직하게 선형으로 불어납니다. 대화가 길어질수록, 에이전트가 문서를 많이 물고 있을수록, 모델 파라미터와는 별도로 메모리를 차지하는 두 번째 덩어리가 커지는 겁니다.
그리고 이 부담이 커지자, 최근 몇 년 사이 어텐션 구조 자체가 메모리 때문에 다시 설계되기 시작했습니다. 대표적인 세 갈래를 잠깐씩 뜯어 보면:
- MQA / GQA — K·V를 여럿이 나눠 쓴다. 실제 모델은 어텐션을 하나가 아니라 수십 개 병렬로 돌립니다(멀티헤드 — 각자 다른 종류의 관계를 봅니다). 원래는 헤드마다 자기 K·V를 따로 저장해서, 캐시가 헤드 수만큼 커졌습니다. MQA는 모든 헤드가 K·V 한 벌을 공유하고(Q만 각자), GQA는 그 중간으로 몇 개 헤드씩 그룹을 지어 한 벌씩 공유합니다. 예컨대 32개 헤드를 8그룹으로 묶으면 캐시가 4분의 1로 줄어듭니다.
강점: 구현이 단순하고 품질 손실이 작다 — 사실상 업계 기본값이 된 이유. 약점: 감소 폭이 그룹 수 비율까지라 한 자릿수 배율에서 멈춘다 (MQA까지 밀면 품질 손실 위험이 커진다). - MLA (딥시크) — 원본 대신 압축본을 저장한다. K·V를 통째로 저장하는 대신, 그걸 다시 만들어낼 수 있는 훨씬 작은 잠재 벡터만 저장해 두고 쓸 때 펼칩니다. 이불을 그대로 쌓는 대신 압축팩에 넣어 두는 셈입니다. DeepSeek-V2 논문 기준 KV cache가 약 93% 줄었다고 밝혔고 — 1편에서 본 딥시크의 효율화 계보(MoE — 필요한 부분만 켠다)와 같은 철학이 어텐션에 적용된 사례입니다.
강점: 감소 폭이 가장 크면서 품질을 지켰다(논문 보고 기준). 약점: 구조가 복잡하고 처음부터 그렇게 학습해야 해서, 이미 만들어진 모델에 소급 적용이 안 된다. - KV 양자화 — 숫자 하나를 더 짧게 쓴다. 저장하는 숫자의 정밀도를 16비트에서 8비트(FP8)로 낮추면 같은 내용이 절반 용량이 됩니다. 사진을 원본 대신 고화질 JPEG로 저장하는 것과 같은 거래로, 정밀도를 잃는 대신 공간을 법니다. 한 실측에서는 FP8 저장으로 토큰당 비용이 기존(BF16)의 54%로 내려가고 처리량이 15%가량 올랐습니다.
강점: 학습을 다시 할 필요 없이 서빙 단계에서 적용할 수 있고, 위 두 기법과 겹쳐 쓸 수 있다(GQA 모델의 캐시를 다시 반으로). 약점: 더 낮은 비트로 밀수록 정밀도 손실 관리가 어려워진다.
누가 무엇을 쓰는지는 공개된 모델에 한해 이렇게 정리됩니다:
| 모델 (공개 정보 기준) | 어텐션 캐시 전략 |
|---|---|
| Llama 3 (메타) · Qwen 2 이후 (알리바바) | GQA |
| gpt-oss (OpenAI의 공개 모델) | GQA + 슬라이딩 윈도우(문맥 창 제한을 층마다 교차) |
| DeepSeek V2·V3·R1 | MLA |
| Kimi K2 (문샷AI) | MLA (딥시크 계열 구조 채택) |
| Nemotron-H (엔비디아) | 어텐션 층 자체를 대폭 축소 — 대부분을 KV cache가 없는 Mamba 층으로 대체한 하이브리드 |
| GPT-5 · Claude · Gemini 등 프런티어 | 구조 미공개 — 알 수 없음 |
마지막 줄이 시사하는 것도 있습니다. 이 지도는 공개(오픈웨이트) 생태계의 지도이고, 프런티어 상용 모델의 어텐션 구조는 이제 영업기밀의 영역입니다. 한 가지 방향은 분명합니다 — 공개된 최신 모델 중에 순정 MHA를 그대로 쓰는 곳은 사실상 없고, 엔비디아처럼 어텐션 자체를 줄이는 제4의 길까지 등장했습니다.
여기서 이 시리즈의 사슬이 흥미로운 방향으로 한 번 꺾입니다. 1편에서 "알고리즘의 선택이 하드웨어를 불러낸다"고 했는데, 여기서는 사슬이 거꾸로 돕니다 — 하드웨어 청구서가 알고리즘을 다시 설계하게 만든 겁니다. 셋 다 모델을 더 똑똑하게 만드는 기법이 아니라, 오로지 메모리를 덜 쓰기 위해 어텐션을 개조한 것들이니까요. (Shazeer 2019 · Ainslie 외 2023 · DeepSeek-V2 2024 · vLLM 실측 2026)
그럼 메모리 문제는 풀리고 있는 걸까 — 두 곡선의 경주
토큰 하나가 차지하는 캐시가 이렇게 계속 줄어드니, "그럼 메모리 문제는 곧 풀리는 것 아닌가"라는 질문이 나옵니다. 반대쪽 곡선을 같이 봐야 답이 나옵니다.
왼쪽이 30분의 1로 내려가는 동안 오른쪽은 330배 올라갔습니다. 곱하면 답은 명확합니다 — 토큰당 효율이 아무리 좋아져도, 토큰 총량이 그보다 훨씬 빠르게 늘어서 메모리 총수요는 계속 커집니다. 오히려 인과가 반대에 가깝습니다. 토큰이 싸졌기 때문에 추론 모델(답 하나에 10배 토큰)과 에이전트(수십 번의 왕복) 같은 토큰 대식가들이 경제성을 얻었고, 그것이 총량을 폭발시켰습니다. 효율 개선이 소비를 줄이는 게 아니라 늘리는 이 구조(제번스 역설)가, 1편에서 예고한 "효율이 수요를 줄이는가" 논쟁의 답입니다.
4. 같은 수식, 다른 병목 — 학습과 추론이 갈리는 지점
이 장이 이 글의 핵심인데, 들어가기 전에 그림 하나를 먼저 깔아야 합니다. 계산하는 곳과 데이터가 사는 곳은 물리적으로 떨어져 있습니다. 이 글에서 연산기라고 부르는 것은 GPU 다이 위에 수천 개 깔린 계산 회로들입니다(CUDA 코어·텐서 코어 — CPU가 아닙니다). 이 연산기들은 칩 한가운데 있지만, 14GB짜리 파라미터는 그 옆에 살 수 없습니다(칩 위의 저장공간은 MB 단위뿐입니다). 파라미터는 칩 바깥의 메모리(HBM·DRAM)에 있고, 계산을 하려면 매번 그 숫자들을 연산기까지 실어 와야 합니다. 이 실어 오는 속도가 메모리 대역폭입니다.
주방에 비유하면 — 요리사(연산기)는 손이 아무리 빨라도, 재료(파라미터)가 창고(메모리)에서 컨베이어(대역폭)로 도착해야 요리를 시작합니다. 그러면 질문은 하나로 좁혀집니다. 재료를 한 번 실어 왔을 때, 그걸로 요리를 몇 번 하는가? 학습과 추론은 같은 행렬곱을 쓰는데, 바로 이 질문에서 답이 정반대로 갈립니다. 차이는 수식이 아니라 행렬곱의 모양에 있습니다.
학습은 행렬×행렬입니다. 수천 개의 문장을 배치(batch)로 묶어 한꺼번에 밀어 넣으니, 입력 자체가 두툼한 행렬이 됩니다. 이때 중요한 것은 — 메모리에서 한 번 읽어 온 파라미터를 배치 안의 수천 개 입력에 재사용한다는 점입니다. 14GB를 읽는 비용을 수천 번의 계산이 나눠 갚는 구조라, 병목은 계산 그 자체에 걸립니다. GPU의 연산기가 쉴 틈 없이 도는, 하드웨어 입장에서 "고마운" 워크로드입니다.
추론의 생성 단계는 행렬×벡터입니다. 다음 토큰은 하나씩만 만들 수 있으니(자기가 만든 토큰을 봐야 그다음을 만드니까), 입력이 벡터 하나입니다. 이러면 계산 구조가 뒤집힙니다. 14GB의 파라미터를 다 읽어 왔는데, 각 숫자로 하는 일은 곱셈 한 번, 덧셈 한 번이 사실상 전부입니다. 읽기 비용을 나눠 갚아 줄 동료 입력이 없습니다. 연산기는 놀고, 메모리에서 데이터가 오기를 기다리는 시간이 대부분이 됩니다.
아까의 주방 질문으로 돌아가면 — 학습은 재료를 한 번 실어 와 수천 그릇을 만들고(요리사가 병목), 생성은 재료를 실어 와 한 그릇 만들고 끝입니다(컨베이어가 병목). 하드웨어 쪽에서는 이걸 연산 강도(arithmetic intensity)라는 지표로 부릅니다 — 메모리에서 실어 온 바이트당 몇 번의 계산을 하느냐. 학습은 이 값이 높아 연산 바운드(연산기 속도가 전체 속도를 정함), 생성은 낮아 메모리 바운드(실어 오는 속도가 전체 속도를 정함)입니다. 같은 GPU가 학습에서는 잘 달리다가 추론 서비스에서는 연산기를 놀리는 이유, 추론 전용 칩들이 하나같이 메모리 대역폭을 앞세워 설계되는 이유가 전부 이 한 줄에서 나옵니다.
이 이야기가 실제 하드웨어 어디에서 벌어지는지를 한 장으로 그리면 이렇습니다:
CPU와 DRAM은 이 그림에서 일을 시키고 데이터를 준비하는 조연입니다. 행렬곱과 파라미터 수송은 전부 오른쪽 — GPU 다이와 HBM 사이 — 에서 벌어지고, PCIe(수십 GB/s)와 HBM(수천 GB/s)의 화살표 굵기 차이가 곧 왜 파라미터를 호스트가 아니라 HBM에 둬야 하는지의 이유입니다.
덧붙이면, 이 그림에서 GPU 다이와 HBM을 한 몸으로 붙여 놓은 물리적 실체가 있습니다. H100은 실리콘 인터포저 위에 GPU 다이와 HBM 스택들을 나란히 올린 2.5D 패키지(CoWoS)이고, 빨간 화살표의 정체는 그 인터포저에 새겨진 수천 가닥의 미세 배선입니다. 스택당 1024비트짜리 HBM 인터페이스는 일반 기판 배선으로는 뽑을 수 없어서, 실리콘에 배선을 새기는 이 방식이 필요해집니다 — 대역폭 병목이 왜 곧장 패키징 이야기(CoWoS 시리즈)로 이어지는지가 여기서 미리 보입니다.
5. 메모리 읽는 기계 — 토큰 하나 = 모델 전체 1회 통독
생성 단계의 병목을 숫자로 만져 보겠습니다. 단순화하면, 토큰 하나를 만들 때마다 모델은 자신의 파라미터 전체를 메모리에서 한 번 통독해야 합니다. 모든 층의 모든 행렬이 한 번씩 곱해지니까요.
7B 모델(FP16, 약 14GB)을 예로 들어 보겠습니다. H100(SXM)의 스펙시트에는 "메모리 대역폭 3.35TB/s"라고 적혀 있는데 — 여기서 말하는 "메모리"가 바로 앞 그림의 HBM입니다. GPU 보드에서 파라미터가 사는 곳이 HBM이니, GPU 스펙의 메모리 대역폭 = 다이와 HBM 사이 그 빨간 화살표의 속도입니다. 그러면 배치 1로 토큰을 만들 때의 이론 상한이 바로 계산됩니다: 3,350GB ÷ 14GB ≈ 초당 약 240토큰. 연산이 아무리 남아돌아도 이 벽은 못 넘습니다. 대역폭이 절반인 칩에서는 상한도 절반입니다. 생성 속도의 상한을 정하는 것은 연산기가 아니라 HBM 대역폭입니다.
그리고 이 그림이 시리즈 1편의 마지막 질문과 연결됩니다. 연산과 메모리의 성장 속도는 이미 크게 벌어져 있습니다. 한 분석에 따르면 지난 20년간 서버의 연산 성능이 약 6만 배 늘어나는 동안, 메모리 대역폭은 약 100배 느는 데 그쳤습니다 (Gholami 외, IEEE Micro 2024). 계산할 힘은 넘치는데 재료 공급이 못 따라오는 구조 — 업계가 메모리 월(memory wall)이라 부르는 이 격차 위에, 하필 "메모리 읽는 기계"인 LLM 추론이 올라앉은 겁니다.
6. 그래서 반도체 지도가 이렇게 그려진다
이번 편의 내용만으로도 AI 반도체 뉴스의 절반이 읽힙니다.
| 관찰되는 현상 | 이 글의 어느 대목인가 |
|---|---|
| 가속기 신제품 발표가 FLOPS보다 HBM 용량·대역폭을 앞세운다 | 생성 속도의 상한 = 대역폭 (5장) |
| 학습용과 추론용 칩의 설계가 갈라진다 | 행렬×행렬 vs 행렬×벡터 (4장) |
| 추론 서비스 가격이 배치·처리량 최적화에 목을 맨다 | 파라미터 읽기 비용을 나눠 갚는 산수 (5장) |
| 긴 문맥·에이전트가 나올수록 메모리 이야기가 커진다 | KV cache — 계산 대신 저장을 내주는 거래 (3장) |
| GQA·MLA·KV 양자화 같은 어텐션 개조가 계속 나온다 | 하드웨어 청구서가 알고리즘을 다시 설계하게 만드는 역방향 사슬 (3장) |
AI 하드웨어 뉴스를 볼 때 이렇게 물어 보세요. "이 워크로드는 연산 바운드인가, 메모리 바운드인가?" 배치가 두툼하면 연산, 토큰을 하나씩 뽑으면 메모리입니다. 이 한 가지 구분이 칩 스펙 시트에서 어느 숫자를 봐야 하는지(FLOPS인가 TB/s인가), 어느 회사의 무엇이 병목을 쥐고 있는지를 알려 줍니다.
부록 — 그 대역폭은 누가 정하나
본문 내내 "생성 속도의 상한 = HBM 대역폭"이라고 했으니, 마지막으로 한 층만 더 내려가 봅니다. 그 대역폭이라는 숫자는 딱 세 개의 곱으로 만들어집니다:
이 세 줄만으로 세대 교체의 논리가 읽힙니다. HBM3E까지는 ②(속도)를 밀어 올렸고, 그 길이 전력 벽에 막히자 HBM4는 ①(폭 두 배)로 방향을 틀었습니다. 시스템 쪽은 그동안 꾸준히 ③(스택 수)을 늘려 왔고요. 그리고 자주 헷갈리는 인터포저의 자리도 여기서 분명해집니다 — 인터포저는 ①을 실현하는 무대이지, 속도의 주인이 아닙니다. 대역폭의 주인은 메모리의 I/O와 표준, 패키징은 그것을 가능하게 하는 무대 — 이 한 문장이면 됩니다. 더 깊은 이야기는 HBM 시리즈와 CoWoS 시리즈에 있습니다.
LLM이 다시 그리는 반도체 지도 — 시리즈
- #1 LLM 현황 — Transformer에서 에이전트까지
- #2 LLM은 어떻게 계산하나 — 어텐션과 행렬곱 (이 글)
- #3 LLM이 하드웨어를 누르는 5축 (예정)
- #4 에이전트의 '기억'은 어디에 있나 — 착시, 그리고 메모리 월 (예정)
- #5 회사 경계가 무너진다 · #6 데이터센터 vs 로컬 · #7 한국의 자리 (예정)
더 깊이 — 노드별 딥다이브
다음 편에서는 시야를 다시 넓혀, LLM이 하드웨어를 누르는 압력을 다섯 개의 축(연산·메모리 용량·대역폭·통신·전력)으로 정리합니다. 오늘 그린 "메모리 읽는 기계"가 그 다섯 축 중 어디를 가장 세게 누르는지가 보일 겁니다.