# 하드웨어 친화적 LLM 설계, KV 캐시·양자화·MoE로 메모리 병목 줄이기

- 게시: 2026.07.18
- 원문(HTML): https://trendbrief.news/articles/%ED%95%98%EB%93%9C%EC%9B%A8%EC%96%B4-%EC%B9%9C%ED%99%94%EC%A0%81-llm-%EC%84%A4%EA%B3%84-kv-%EC%BA%90%EC%8B%9C-%EC%96%91%EC%9E%90%ED%99%94-moe%EB%A1%9C-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%B3%91%EB%AA%A9-%EC%A4%84%EC%9D%B4%EA%B8%B0.html
- 발행: [트렌드브리프](https://trendbrief.news/)

![하드웨어 친화적 LLM 설계, KV 캐시·양자화·MoE로 메모리 병목 줄이기](https://trendbrief.news/assets/articles/%ED%95%98%EB%93%9C%EC%9B%A8%EC%96%B4-%EC%B9%9C%ED%99%94%EC%A0%81-llm-%EC%84%A4%EA%B3%84-kv-%EC%BA%90%EC%8B%9C-%EC%96%91%EC%9E%90%ED%99%94-moe%EB%A1%9C-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%B3%91%EB%AA%A9-%EC%A4%84%EC%9D%B4%EA%B8%B0/hero-1.png)

> LLM 추론은 답을 만드는 디코딩 단계에서 연산이 아니라 메모리 대역폭에 먼저 묶인다. GQA·양자화·MoE가 이 병목을 푸는 핵심 설계이며, Meta Llama 3와 DeepSeek-V3의 실제 구조로 원리를 정리했다.

하드웨어 친화적 LLM 설계는 모델 구조와 숫자 정밀도를 GPU의 메모리 계층·연산 유닛에 맞춰 짜는 일이다. 전제는 하나다. 대형 언어 모델은 답을 한 토큰씩 만들어 내는 디코딩 단계에서 연산 능력이 아니라 메모리 대역폭(GPU가 초당 메모리에서 데이터를 읽어 오는 속도)에 먼저 막힌다. NVIDIA가 공개한 H100 SXM 사양을 보면 2026년 7월 기준 FP8 연산 성능은 초당 약 3,958조 회(TFLOPS)에 이르지만, 이 연산 유닛을 다 채우려면 가중치를 그만큼 빠르게 읽어 와야 한다. KV 캐시를 줄이는 GQA, 정밀도를 낮추는 양자화, 활성 파라미터를 줄이는 MoE가 곧 추론 속도로 직결되는 이유다. 이 글은 트랜스포머 기반 LLM의 추론 최적화 관점만 다루고, 밑바닥부터의 학습이나 특정 벤더의 설치 절차는 다루지 않는다.

이 관점을 최근 정리한 곳이 NVIDIA다. 2026년 7월 NVIDIA 개발자 블로그의 [모델-하드웨어 코디자인 글](https://developer.nvidia.com/blog/ai-model-co-design-hardware-friendly-llm-design/)은 정확도, 처리량, 상호작용성(지연) 세 축을 GPU 특성에 맞춰 함께 설계하자고 제안한다. NVIDIA는 "하드웨어에 정렬된 모델은 그저 더 빠르게 도는 데 그치지 않고, 더 잘 확장되고 비용이 낮으며 더 널리 채택된다"고 밝혔다.

같은 글이 제시하는 설계 지침은 구체적이다. 깊이를 늘리기보다 너비를 키우면 산술 강도가 올라가고 지연이 줄어든다. 모델 차원은 GPU 타일에 맞춰 최소 128의 배수로, 가능하면 256이나 512로 정렬하고, 가중치 행렬은 정방형에 가깝게 둔다. NVIDIA는 투영이나 축소 차원(H나 H')이 너무 작으면 GPU가 계산보다 데이터를 옮기는 데 시간을 더 쓰는 메모리 바운드 상태에 갇힌다고 설명한다.

## 왜 GPU가 놀아도 LLM은 느린가

답부터 말하면, 답 생성 단계의 병목이 연산이 아니라 메모리 이동이기 때문이다. 모델이 프롬프트를 한꺼번에 처리하는 프리필(prefill) 단계는 행렬 곱이 몰려 연산에 묶이지만, 그다음 한 토큰씩 뽑아내는 디코딩 단계는 성격이 다르다. 토큰 하나를 만들 때마다 모델 가중치 전체를 메모리에서 한 번씩 읽어 와야 한다.

규모를 숫자로 보면 감이 온다. 700억(70B) 파라미터 모델을 FP16(16비트 부동소수점)으로 올리면 가중치만 약 140GB다. 초당 몇 토큰을 뽑느냐는 이 140GB를 얼마나 빠르게 읽어 오느냐로 거의 결정된다. 그동안 텐서 코어(행렬 곱 전용 연산 유닛)는 데이터를 기다리며 상당 시간 논다. 연산 성능과 메모리 대역폭 중 어느 쪽에 먼저 부딪히는지를 그려 본 그래프를 루프라인(roofline)이라 부르는데, 디코딩은 대부분 메모리 쪽 벽에 걸린다. 그래서 하드웨어 친화적 설계의 목표는 "연산을 더 빨리"가 아니라 "읽어 올 데이터를 더 적게"로 모인다.

![대부분 비어 유휴 상태인 큰 GPU 다이가, 데이터 블록이 드문드문 지나는 얇은 메모리 파이프로만 공급받고 옆에 모래시계가 놓인 선화 — 위쪽 넓은 빠른 차선은 비어 있다](https://trendbrief.news/assets/articles/%ED%95%98%EB%93%9C%EC%9B%A8%EC%96%B4-%EC%B9%9C%ED%99%94%EC%A0%81-llm-%EC%84%A4%EA%B3%84-kv-%EC%BA%90%EC%8B%9C-%EC%96%91%EC%9E%90%ED%99%94-moe%EB%A1%9C-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%B3%91%EB%AA%A9-%EC%A4%84%EC%9D%B4%EA%B8%B0/sec-membound-1.png)

메모리 바운드: H나 H′가 작으면 GPU는 계산보다 데이터를 옮기는 데 시간을 더 쓴다 — 강한 연산 유닛이 좁은 대역폭에 굶주린다.

## KV 캐시를 줄이는 GQA

어텐션은 이미 만든 앞쪽 토큰들의 키(K)와 값(V)을 캐시에 쌓아 두고 재사용한다. 이 KV 캐시는 문맥이 길어질수록, 어텐션 헤드가 많을수록 커진다. 긴 문맥을 다루는 서비스에서 KV 캐시는 가중치 못지않게 대역폭을 잡아먹는 짐이 된다.

GQA(Grouped-Query Attention, 여러 쿼리 헤드가 키·값 헤드 하나를 함께 쓰는 방식)는 이 짐을 줄인다. Google 연구진이 2023년 EMNLP에서 발표한 GQA 논문(Ainslie 외)은 헤드마다 키·값을 따로 두는 기존 방식(MHA)과 키·값을 하나로 몰아넣는 극단적 방식(MQA) 사이를, 중간 개수의 키·값 헤드로 절충한 구조다. Meta는 Llama 3 공식 블로그에서 8B·70B 전 모델에 키·값 헤드 8개짜리 GQA를 적용해 추론 속도를 높이고 KV 캐시를 줄였다고 밝혔다. 쿼리 헤드가 64개라면 키·값 헤드를 8개로 묶어 KV 캐시가 8분의 1로 준다.

KV 캐시 크기는 정해진 공식으로 계산된다. 시퀀스 하나당 필요한 바이트를 그대로 대입해 보면 규모가 보인다.

```
# KV 캐시(바이트) = 2 × 레이어 수 × KV 헤드 수 × 헤드 차원 × 시퀀스 길이 × 배치 × 정밀도(바이트)
# 예: 레이어 32, KV 헤드 8, 헤드 차원 128, 8192 토큰, 배치 1, FP16(2바이트)
kv_bytes = 2 * 32 * 8 * 128 * 8192 * 1 * 2
print(kv_bytes / 1e9) # 약 1.07 GB
```

키·값 헤드가 8개가 아니라 64개(MHA)였다면 같은 조건에서 약 8.6GB가 든다. 헤드 하나를 줄이는 설계 선택이 시퀀스 하나당 수 기가바이트의 대역폭 차이로 돌아온다.

## 커널을 다시 짠 FlashAttention

GQA가 캐시에 쌓을 양을 줄인다면, FlashAttention은 어텐션을 계산하는 동안 메모리를 오가는 횟수를 줄인다. Dao 외가 2022년 발표한 [FlashAttention 논문](https://arxiv.org/abs/2205.14135)의 핵심은 GPU 메모리의 속도 차이를 파고든 것이다. HBM(용량은 크지만 느린 메모리)과 SRAM(용량은 작지만 빠른 온칩 메모리) 사이의 데이터 이동이 병목이라는 관찰에서 출발한다.

표준 방식은 시퀀스 길이의 제곱(N×N)짜리 어텐션 행렬을 통째로 HBM에 펼친다. FlashAttention은 이 행렬을 타일(tile) 단위로 잘라 빠른 SRAM 안에서 계산하고, 큰 중간 행렬을 HBM에 아예 만들지 않는다. 근삿값이 아니라 결과가 정확히 같은 방식이라는 점이 중요하다. 논문은 시퀀스 길이 1K 기준 GPT-2 학습에서 약 3배 빠른 속도를 보고했다. 오늘날 대부분의 추론 엔진에 기본으로 들어가 있어, 대개 개발자가 직접 구현하기보다 켜져 있는지 확인하는 대상에 가깝다.

## 정밀도를 낮추는 양자화

양자화는 가중치를 더 낮은 정밀도로 저장해 읽어 올 데이터 자체를 줄이는 방법이다. FP16에서 FP8, INT8, INT4로 내려갈수록 가중치가 차지하는 바이트가 줄고, 그만큼 대역폭 병목이 풀린다. NVIDIA의 [TensorRT-LLM 문서](https://nvidia.github.io/TensorRT-LLM/)는 H100·H200·B200에서 FP8을 하드웨어가 기본 지원하며, 텐서 코어 처리량이 FP16 대비 약 2배로 올라간다고 설명한다.

정밀도를 낮추면 정확도가 떨어질 위험이 따르므로, 방법마다 손실을 줄이는 장치가 다르다. 가중치만 4비트로 낮추고 실제 계산은 FP16으로 하는 가중치 전용(weight-only) 양자화는 저장·읽기 부담을 약 4분의 1로 줄이면서 계산 정밀도는 유지한다. AWQ나 GPTQ 같은 방법은 활성값 패턴을 보고 중요한 가중치 채널을 보호해 정확도 손실을 억제한다. 실무에서는 FP16 원본과 출력을 비교해 품질 하락을 재보며 FP8부터 단계적으로 내리는 편이 안전하다.

4비트로 더 내려갈 때 정확도를 지키는 최신 접근으로 NVIDIA는 NVFP4 포맷을 제시한다. NVFP4는 16개 값으로 이뤄진 마이크로블록마다 FP8 스케일을 적용하고, 그 위에 텐서 단위 FP32 스케일을 한 겹 더 얹는 계층적 4비트 포맷이다. NVIDIA에 따르면 Blackwell GB300에서 FP4 연산의 피크 성능은 15 PFLOPS로 FP8의 5 PFLOPS, FP16/BF16의 2.5 PFLOPS를 크게 웃돌고, DeepSeek-R1을 7개 벤치마크로 평가했을 때 정확도는 FP8 대비 약 1점 이내로 유지됐다.

## MoE는 왜 파라미터가 커도 빠른가

답부터 말하면, 토큰 하나를 처리할 때 전체 파라미터 중 일부 전문가만 켜기 때문이다. MoE(Mixture of Experts, 여러 개의 작은 전문가 네트워크 중 라우터가 일부만 골라 쓰는 구조)는 층마다 여러 전문가를 두고, 각 토큰을 그중 소수에게만 보낸다.

DeepSeek는 V3 기술 보고서에서 전체 6,710억(671B) 파라미터를 저장하되 토큰당 370억(37B)만 활성화한다고 밝혔다. 층마다 전문가 256개 중 8개만 켜는 구조다. Mistral AI의 Mixtral 8x7B는 전체 약 467억(46.7B) 파라미터 중 토큰당 약 130억(13B)을 쓰는 방식으로, 전문가 2개만 켠다. 오픈 모델의 전체 파라미터가 조 단위로 커지는 흐름(예: [2.8조 파라미터급 오픈 모델](https://trendbrief.news/articles/kimi-k3-2-8%EC%A1%B0-%ED%8C%8C%EB%9D%BC%EB%AF%B8%ED%84%B0-%EC%98%A4%ED%94%88-%EB%AA%A8%EB%8D%B8%EC%9D%98-%EC%8A%A4%ED%8E%99%EA%B3%BC-api-%EC%9A%94%EA%B8%88.html))에서도 실제로 켜지는 파라미터는 그 일부다.

주의할 점이 하나 있다. MoE는 토큰당 연산량과 대역폭 부담을 줄일 뿐, 저장 메모리는 전체 크기 그대로 필요하다. 671B 모델이라면 활성이 37B라도 671B를 전부 GPU 메모리에 올려 둬야 한다. 그래서 MoE는 대역폭에는 후하지만 메모리 용량에는 여전히 부담이 큰 설계다.

이 저장 부담을 여러 장치로 나누는 방법으로 NVIDIA는 전문가를 여러 GPU에 분산하는 전문가 병렬(EP)을 제시한다. 전문가가 흩어지면 GPU마다 처리하는 토큰 묶음이 커져 동시성이 오르고, 그만큼 GEMM 연산의 활용도가 함께 높아진다는 관점이다.

## 세 가지 레버를 어떻게 고르나

정답은 워크로드에 달렸다. 긴 문맥이 주된 부담이면 KV 캐시 쪽(GQA·FlashAttention)이, 모델 크기가 대역폭을 잡아먹으면 양자화가, 파라미터 규모를 키우면서 토큰당 비용은 억누르고 싶으면 MoE가 우선이다. 세 레버가 줄이는 대상과 대가는 서로 다르다.

| 설계 레버 | 줄이는 대상 | 주된 대가 | 대표 사례 |
| --- | --- | --- | --- |
| GQA | KV 캐시 메모리·대역폭 | KV 헤드를 줄이면 품질 소폭 하락 | Llama 3 (KV 헤드 8개) |
| FlashAttention | 어텐션 중간 행렬의 HBM 접근 | 커널 구현 복잡도 | 대부분의 추론 엔진 기본 탑재 |
| 양자화(FP8·INT4) | 가중치 저장·읽기 대역폭 | 정밀도 손실로 정확도 하락 | NVIDIA TensorRT-LLM, AWQ·GPTQ |
| MoE | 토큰당 활성 연산량 | 전체 저장 메모리는 그대로 | DeepSeek-V3 (671B 중 37B 활성) |

실무 순서는 대개 이렇다. GQA와 FlashAttention은 최신 추론 엔진에 기본으로 들어가 있으니 켜져 있는지부터 확인한다. 그다음 양자화는 정확도를 재보며 FP8에서 시작해 필요하면 더 낮춘다. MoE는 배포 단계에서 켜고 끄는 옵션이 아니라 어떤 모델을 고르느냐의 문제이므로, 모델 선택 단계에서 대역폭 이득과 메모리 용량 부담을 함께 저울질해야 한다. 세 갈래 모두 결국 같은 목표를 향한다. 읽어 올 데이터를 줄여, 놀고 있는 연산 유닛을 일하게 만드는 것이다.

## 관련 글

- [LLM 프롬프트 토큰 줄이기, 측정·캐싱·압축으로 접근하기](https://trendbrief.news/articles/llm-%ED%94%84%EB%A1%AC%ED%94%84%ED%8A%B8-%ED%86%A0%ED%81%B0-%EC%A4%84%EC%9D%B4%EA%B8%B0-%EC%B8%A1%EC%A0%95-%EC%BA%90%EC%8B%B1-%EC%95%95%EC%B6%95%EC%9C%BC%EB%A1%9C-%EC%A0%91%EA%B7%BC%ED%95%98%EA%B8%B0.md)
- [LLM 필러 토큰과 숨은 추론, 무의미한 점이 계산이 되는 조건](https://trendbrief.news/articles/llm-%ED%95%84%EB%9F%AC-%ED%86%A0%ED%81%B0%EA%B3%BC-%EC%88%A8%EC%9D%80-%EC%B6%94%EB%A1%A0-%EB%AC%B4%EC%9D%98%EB%AF%B8%ED%95%9C-%EC%A0%90%EC%9D%B4-%EA%B3%84%EC%82%B0%EC%9D%B4-%EB%90%98%EB%8A%94-%EC%A1%B0%EA%B1%B4.md)
- [GitHub API rate limit, 여러 워커가 공유 캐시로 한도 아끼기](https://trendbrief.news/articles/github-api-rate-limit-%EC%97%AC%EB%9F%AC-%EC%9B%8C%EC%BB%A4%EA%B0%80-%EA%B3%B5%EC%9C%A0-%EC%BA%90%EC%8B%9C%EB%A1%9C-%ED%95%9C%EB%8F%84-%EC%95%84%EB%81%BC%EA%B8%B0.md)
- [LLM 모델 라우팅, 쉬운 요청은 싼 모델로 보내는 원리와 도구](https://trendbrief.news/articles/llm-%EB%AA%A8%EB%8D%B8-%EB%9D%BC%EC%9A%B0%ED%8C%85-%EC%89%AC%EC%9A%B4-%EC%9A%94%EC%B2%AD%EC%9D%80-%EC%8B%BC-%EB%AA%A8%EB%8D%B8%EB%A1%9C-%EB%B3%B4%EB%82%B4%EB%8A%94-%EC%9B%90%EB%A6%AC%EC%99%80-%EB%8F%84%EA%B5%AC.md)
- [REST API 뜻과 설계 원칙, 키움증권 API 사례](https://trendbrief.news/articles/rest-api-%EB%9C%BB%EA%B3%BC-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99-%ED%82%A4%EC%9B%80%EC%A6%9D%EA%B6%8C-api-%EC%82%AC%EB%A1%80.md)