온디바이스 AI…클라우드를 떠난 AI가 메모리에 거는 부담
스마트폰이 서버 없이 스스로 AI를 돌리는 시대. 온디바이스 AI가 성립하는 세 가지 이유, 기기 안에서 벌어지는 메모리와의 씨름, 그리고 한국 메모리 산업에 열리는 두 번째 전선을 정리한다.
데이터센터 전기 기사에서 AI의 무게중심이 거대한 서버 단지에 있음을 봤다. 그런데 반대 방향의 흐름이 동시에 자라고 있다. AI를 클라우드에서 꺼내 손안의 기기에 넣는 흐름, 온디바이스 AI다.
왜 기기로 내려오나, 세 가지 이유
① 속도. 서버 왕복 없이 즉시 응답한다. 실시간 통역, 카메라 인식처럼 지연이 체감되는 기능일수록 기기 안 실행이 유리하다.
② 사생활. 데이터가 기기를 떠나지 않는다. 사진·메시지·음성 같은 민감한 정보를 서버로 보내지 않고 처리한다는 것 자체가 제품의 신뢰가 된다.
③ 독립성과 비용. 통신이 끊겨도 동작하고, 사용자가 늘어도 서버 비용이 늘지 않는다. 기능을 쓰는 순간마다 클라우드 요금이 발생하는 구조와의 경제적 차이가 크다.
물론 대형 모델의 학습과 무거운 추론은 여전히 데이터센터의 몫이다. 실제 지형은 “큰 일은 클라우드, 잦고 민감한 일은 기기”로 나뉘는 하이브리드로 굳어지는 중이다.
기기 안의 씨름, 병목은 다시 메모리다
기기 안의 제약 조건은 데이터센터와 정반대다. 전원은 배터리, 냉각 장치는 사실상 없음, 공간은 손바닥. 이 조건에서 AI 모델을 돌리려면 두 가지 씨름이 벌어진다.
하나는 모델 다이어트, 모델의 숫자 정밀도를 낮추고(양자화) 구조를 쳐내 (경량화) 기기 크기에 맞춘다. 다른 하나가 메모리와의 씨름이다. AI 추론의 병목은 연산보다 모델 데이터를 메모리에서 꺼내 오는 속도에 걸리는 경우가 많다. HBM 기사에서 본 “작업대 문제”의 모바일 버전이다. 기기에서는 HBM 대신 저전력 토리의 용어 메모 D램 전원이 꺼지면 내용이 사라지는 휘발성 메모리. 연산의 작업대 역할을 하며, 전원이 꺼져도 데이터가 남는 낸드플래시와 함께 메모리 반도체의 양대 축이다. D램 자세히 보기 → (LPDDR 계열)이 그 역할을 맡는다. 전력 한 방울로 대역폭을 최대한 짜내는 설계 경쟁이고, 모델이 커질수록 요구 용량도 함께 커진다. AI 칩 기사에서 본 NPU가 연산을 맡고, 저전력 D램이 공급을 맡는 짝이다.
한국 메모리의 두 번째 전선
특집이 추적해 온 AI 메모리 수요의 첫 전선은 서버용 HBM이었다. 온디바이스 AI는 두 번째 전선을 연다. 스마트폰·PC·자동차에 실리는 저전력 고용량 메모리의 수요다. 서버 전선이 소수 고객의 대형 주문이라면, 기기 전선은 수억 대 단위의 저변 수요라는 점에서 성격이 다르다. 두 전선 모두에서 상위 공급자가 한국 기업 들이라는 것, AI가 어느 쪽으로 발전하든 메모리 수요가 남는다는 특집의 명제가, 여기서 한 번 더 확인된다.
- 01
하이브리드 지형
큰 일은 클라우드, 잦고 민감한 일은 기기, 온디바이스는 클라우드의 대체가 아니라 분업이다.
- 02
제약의 역전
데이터센터의 병목이 전력망이라면 기기의 병목은 배터리와 발열, 그래서 승부가 와트당 대역폭으로 모인다.
- 03
두 번째 전선
서버 HBM에 이어 기기용 저전력 D램, AI 메모리 수요의 저변이 넓어지는 구조를 수출 통계로 추적할 것.
손안에 들어가는 크기를 계산해 보면
「기기로 내려온다」는 말의 제약은 곱셈 하나로 드러난다. 파라미터 1개는 FP16이면 2바이트, FP8이면 1바이트를 차지한다.
| 모델 크기 | FP16 | FP8 |
|---|---|---|
| 70억 | 14GB | 7GB |
| 700억 | 140GB | 70GB |
서버에서는 80GB짜리 카드를 여러 장 묶으면 되지만, 휴대기기의 메모리는 그 자릿수가 아니다. 70억 파라미터를 FP8로 낮춰야 7GB이고, 여기에 운영체제와 다른 앱이 쓰는 몫까지 더해야 실제 그림이 된다.
그래서 온디바이스 경쟁은 성능 경쟁이자 다이어트 경쟁이 된다. 같은 모델을 줄이는 것이 아니라 애초에 다른 크기의 모델을 쓰는 쪽에 가깝다는 뜻이다. 다만 위 표는 파라미터만 센 하한선이고, 계산 중간값과 문맥 길이에 비례해 늘어나는 몫이 빠져 있다는 점은 함께 기억할 일이다.
실무에서 틀리기 쉬운 지점
첫째, 온디바이스를 「작은 서버」로 상상하는 것. 메모리와 전력 예산의 자릿수가 다르다. 서버에서 돌던 모델을 그대로 옮기는 것이 아니라, 그 자리에 맞는 모델을 새로 고르는 일에 가깝다.
둘째, 용량만 보고 대역폭을 잊는 것. 모델이 기기 메모리에 올라가도 매초 그 무게를 실어 나르지 못하면 응답이 느려진다. 서버 쪽의 HBM이 비싼 이유와 같은 원리가 손안에서도 작동한다.
셋째, 전력 문제를 부수적인 것으로 두는 것. 기기에서는 발열이 곧 성능 상한이고 배터리가 사용 시간을 정한다. 전력당 성능이 사양표의 숫자보다 실제 경험을 좌우한다.
넷째, 클라우드와 온디바이스를 양자택일로 보는 것. 실제 제품은 간단한 일은 기기에서, 무거운 일은 서버로 보내는 혼합 구조를 쓴다. 두 전선이 함께 커지는 것이며, 그래서 메모리 수요도 양쪽에서 동시에 늘어난다.
자료
- NVIDIA H100 Tensor Core GPU H100 SXM 메모리 80GB · 대역폭 3.35TB/s (서버 쪽 기준값)
- 도토리경제 자체 계산: 파라미터 수 × 정밀도 파라미터 1개를 FP16이면 2바이트, FP8이면 1바이트로 잡아 곱한 값이다. 활성값·KV 캐시가 빠져 있으므로 실제 소요는 이보다 크다
수치는 발표 기관 원자료를 파이프라인이 매일 자동 수집한 값이다. 기관 사정으로 사후 정정될 수 있으며, 투자 자문이 아니다.
도토리경제는 매일 아침 스스로 지표를 거둬 기사와 대시보드로 바꾸는 구조로 굴러갑니다. 그 과정에서 쌓인 것이 도움이 될 만한 자리가 있다면 편하게 말씀해 주십시오. 강의든 자문이든 같이 만드는 일이든 좋습니다.
댓글
GitHub 계정으로 로그인해 의견을 남길 수 있습니다. 격려도, 오류 제보도 환영합니다. 잘못된 수치 제보는 확인 후 정정합니다.