| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Kubernetes
- golang
- 코틀린 코루틴의 정석
- AWS EKS
- 공부
- CKA
- CKA 기출문제
- 컨텍스트 엔지니어링
- Linux
- Pinpoint
- aws
- kotlin coroutine
- tucker의 go 언어 프로그래밍
- 기록으로 실력을 쌓자
- Java
- minikube
- kotlin
- SRE
- APM
- PETERICA
- Spring
- 티스토리챌린지
- AI
- 오블완
- go
- LLM
- CloudWatch
- 바이브코딩
- MySQL
- 정보처리기사 실기 기출문제
- Today
- Total
피터의 개발이야기
[AI] LLM의 미래는 어디로 가는가? 본문
ㅁ 들어가며
폰 노이만 한계를 넘어서는 NPU·PIM·PNM 기반 차세대 AI 컴퓨팅의 방향성에 대해서 고민하게 되었다.
최근 2~3년 동안 LLM 성능은 폭발적으로 성장했다. 하지만 그 이면에서는 하나의 질문이 커지고 있다.
“지금의 GPU 중심 컴퓨팅 구조로는 더 이상 LLM을 확장할 수 없지 않은가?”
LLM 추론의 병목은 더 이상 FLOPs(Floating Point Operations per second, 초당 수행 가능한 부동소수점 연산 수)가 아니라 메모리 이동 비용이다. 이 글에서는 미국 최신 연구를 기반으로 AI 특화 컴퓨팅(PIM·PNM·CIM)이 LLM의 미래를 어떻게 바꿀지를 살펴본다.
ㅁ 폰 노이만 구조의 한계
ㅇ LLM은 “계산”보다 “데이터 이동”에서 병목이 생긴다
Transformer 기반 LLM은 대규모 행렬 연산을 수행하지만, 실제 병목은 다음에서 발생한다.
- 수십억~수백억 파라미터
- 길어지는 KV 캐시
- HBM–GPU 간 데이터 이동 비용
이는 메모리 벽(memory wall) 문제이며, 결국 LLM 확장의 한계를 만든다.
ㅁ NPU의 한계: GEMM(General Matrix Multiply, 일반 행렬 곱셈 연산)은 빠르지만 KV 캐시는 느리다
ㅇ TPU·NPU는 행렬곱에는 최적화되어 있으나 전체 LLM 병목을 해결하지 못한다
NPU가 잘하는 것:
- 시스토릭 어레이 기반 GEMM
- 병렬 연산
- 저정밀도 텐서 연산
하지만 여전히 느린 영역:
- 긴 컨텍스트 Attention
- KV 캐시 업데이트
- GEMV(행렬–벡터)
- 불규칙한 메모리 접근
→ NPU만으로는 LLM 전체를 해결할 수 없다.
ㅁ PIM/CIM/PNM은 어떻게 LLM을 바꾸는가?
ㅇ CIM(Compute-in-Memory): 메모리 안에서 바로 Attention 실행
"Memory Is All You Need"에서 제시된 핵심 아이디어:
참고: ‘Memory Is All You Need’는 실제로 존재하는 학술 논문입니다.
LLM에서 발생하는 메모리 병목을 해결하기 위해 Compute-in-Memory(CIM) 기반의 새로운 연산 구조를 제안한 연구로,
기존 "Attention Is All You Need"처럼 제목은 비슷하지만 하드웨어 아키텍처 관점의 최신 연구 논문이다.
“꺼내오지 말고 메모리 안에서 계산하자.”
- SRAM·RRAM 기반 MAC 연산
- DRAM–HBM 왕복 제거
- 긴 컨텍스트 처리 효율 ↑
ㅇ DRAM 기반 PIM: PIM-GPT
PIM-GPT는 DRAM 내부에서 LLM 연산을 수행한 대표 사례.
- GEMV, KV 캐시 업데이트, LayerNorm을 DRAM에서 직접 처리
- row-buffer hit율 98% 이상
- GPU 대비 높은 에너지 효율
ㅇ NeuPIMs·HPIM: GPU/NPU + PIM의 역할 분담
NeuPIMs의 구조:
- NPU → GEMM 담당
- DRAM-PIM → GEMV·Attention·KV 캐시 담당
- 두 연산을 동시 실행(concurrent execution)
HPIM의 확장:
- SRAM-PIM → 지연 민감한 Attention
- HBM-PIM → 대규모 가중치 연산
→ NVIDIA A100 대비 최대 20배 성능 향상 보고
ㅁ LLM의 미래는 어디로 향할까?
ㅇ Memory-Centric AI로 이동
LLM 구조는 ‘연산 중심’에서 ‘데이터가 있는 곳에서 연산’으로 전환된다.
기대 효과
- 수십만 토큰 컨텍스트
- 장시간 reasoning (O1·R1 스타일)
- 더 낮은 전력
- 온디바이스 LLM 확산
ㅇ 모델 구조도 PIM 친화적으로 재설계될 것
- CIM에서 손실 적은 activation 채택
- Attention의 구조 단순화
- 규칙적 sparsity 적용
- PIM 최적화된 KV 캐시 구조 도입
ㅇ Edge LLM의 시대
PIM/CIM + QAT 조합은 다음을 가능하게 한다.
- 스마트폰에서도 10B 모델 실행
- 4bit·2bit 모델에서도 reasoning 성능 유지
ㅇ Training까지 PIM으로 갈까?
아직은 어려움이 존재:
- 학습은 고정밀 연산 필요
- 아날로그 소자 노이즈
- 가중치 업데이트 비용 큼
중기 전망:
Training = GPU/TPU 중심
Inference = PIM/PNM/CIM 중심
ㅁ 마무리: LLM의 미래는 “하드웨어 혁신”이 결정한다
LLM 시대의 다음 단계는 더 큰 모델이 아니라,
“더 적은 데이터 이동으로 더 많은 계산을 수행하는 아키텍처”이다.
향후 핵심 기술:
- Compute-in-Memory (CIM)
- DRAM-PIM·HBM-PIM
- GPU/NPU + PIM 이종 구조
- PIM 친화형 LLM 설계
- 양자화(QAT) + 메모리 중심 컴퓨팅
- Edge LLM 확산
'AI > AI개발전략 | 기획' 카테고리의 다른 글
| [AI] Cursor에서 토큰 사용량이 많은가? cache read 줄이는 법 (0) | 2025.09.04 |
|---|---|
| [AI] 컨텍스트 엔지니어링: 프롬프트를 넘어서 AI의 성공을 설계하는 법 (0) | 2025.09.02 |
| [AI] AI 시대 서버 관리자의 미래는? 플랫폼 엔지니어 나아가자! (9) | 2025.08.13 |
| [AI] 문서 기반 개발 프로세스: AI를 ‘알바생’으로 활용하는 실전 노트 (1) | 2025.07.26 |
| [AI] The AI-Native Software Engineer 요약 (2) | 2025.07.11 |
