학습·추론·에이전트·멀티모달: AI 사용량을 메모리 수요로 환산하는 방법
학습 가중치, 추론 KV 캐시, 에이전트 루프, 영상 생성까지 같은 계산 틀로 환산하고, 뉴스의 숫자만으로 특정 메모리 수요를 단정할 수 없는 이유를 설명합니다.
AI 뉴스에는 숫자가 넘쳐납니다. 2.8조 파라미터 모델, 주간 활성 사용자 800만 명, 30초 영상 생성. 이런 숫자를 접할 때 인프라 관점에서는 질문이 하나 더 필요합니다. 이 숫자가 실제로 많이 쓰이면, 어떤 메모리가 얼마나 더 필요해질까?
이 글은 그 환산 방법을 정리합니다. 학습·추론·에이전트라는 단계별 틀을 먼저 세우고, 파라미터 수, 사용자 수, 토큰 사용 구조, 영상 길이라는 서로 다른 뉴스 숫자를 같은 틀에 넣어 봅니다. 그리고 각 계산으로 무엇을 말할 수 있고 무엇을 말할 수 없는지 경계를 나눕니다.
참고: 이 글은 2026년 7월에 각각 발행된 메모리 수요 관련 글 다섯 편(학습·추론·Agent 단계, Kimi K3, Codex·ChatGPT Work, 토큰 설계, 씨댄스 2.5)을 하나의 가이드로 재구성했습니다.
1단계: 학습은 “모델 전체를 품는 메모리”가 필요하다
학습 단계에서는 모델 파라미터뿐 아니라 gradient, optimizer state, activation까지 함께 다뤄야 합니다. 단순히 70B 모델의 FP16 가중치만 보면 약 140GB 수준이지만, 실제 학습에서는 그보다 훨씬 많은 메모리가 필요합니다. 혼합 정밀도(mixed precision) Adam 기준으로 파라미터당 12~16바이트 이상이 필요할 수 있고, activation과 통신 버퍼까지 더해집니다.
그래서 대형 모델 학습은 한 장의 GPU 메모리 문제가 아니라 수백~수천 개 GPU에 모델과 데이터를 어떻게 나눠 담을지의 문제가 됩니다. 이 단계에서 중요한 메모리는 HBM입니다. 학습은 대량의 행렬 연산과 파라미터 업데이트가 반복되기 때문에, 용량뿐 아니라 대역폭이 성능을 좌우합니다.
다만 학습 수요는 소수의 빅테크와 대형 연구기관 중심입니다. 그래서 학습 단계의 메모리 수요는 “초고성능 HBM을 많이 쓰는 고밀도 수요”라고 볼 수 있습니다.
2단계: 추론은 “동시 사용자와 컨텍스트를 버티는 메모리”가 필요하다
추론 단계로 오면 이야기가 달라집니다. 서비스에서 중요한 것은 사용자의 질문을 빠르게 처리하는 것이고, 이때 모델 가중치는 메모리에 올라가 있어야 하며, 대화가 이어지는 동안 이전 토큰 정보를 저장하는 KV cache가 계속 쌓입니다.
NVIDIA TensorRT-LLM 문서에서도 KV cache는 모델 크기, 동시 요청 수, 컨텍스트 길이에 따라 선형으로 증가한다고 설명합니다. 예를 들어 Llama 3 70B(GQA 구조)를 단순 계산하면, FP16 KV cache는 사용자 1명 기준 8K 토큰에서 약 2.5GB, 32K 토큰에서 약 10GB, 128K 토큰에서는 약 40GB까지 늘어날 수 있습니다.
같은 계산을 40GB의 KV 캐시 예산에 적용하면 다음 조합이 거의 같은 공간을 사용합니다.
| 동시 요청 | 요청당 컨텍스트 | 요청당 KV 캐시 예시 | 합계 |
|---|---|---|---|
| 16개 | 8K 토큰 | 약 2.5GB | 약 40GB |
| 4개 | 32K 토큰 | 약 10GB | 약 40GB |
| 1개 | 128K 토큰 | 약 40GB | 약 40GB |
이 표는 특정 서버의 성능 보장이 아니라, 같은 캐시 예산을 짧은 요청 여러 개와 긴 요청 한 개가 서로 다르게 소비한다는 비교입니다. 실제 운영에서는 페이지 단위 할당, 양자화, prefix caching, eviction과 단편화가 결과를 바꿉니다. H200이 141GB HBM3E와 4.8TB/s 대역폭을 강조하고, GB200 NVL72 같은 랙 단위 시스템이 13.4TB HBM3E를 내세우는 것도 이 흐름과 맞닿아 있습니다.
3단계: Agent는 “GPU 메모리 밖의 기억”까지 요구한다
Agent 단계에서는 메모리의 의미가 한 번 더 바뀝니다. 챗봇은 한 번 질문에 답하고 끝날 수 있지만, Agent는 작업 목표를 세우고, 문서를 읽고, 도구를 호출하고, 이전 실행 결과를 기억하고, 다음 행동을 결정합니다.
Agent에는 짧은 작업 맥락을 담는 short-term memory, 사용자 선호와 과거 작업을 저장하는 long-term memory, 문서와 코드를 검색하는 vector database, 실행 로그와 상태를 보관하는 스토리지가 필요합니다. 즉 Agent의 메모리 수요는 GPU 안의 HBM에서 서버 D램, CXL 같은 확장 메모리, NVMe SSD, 분산 스토리지까지 이어지는 계층형 구조로 확장됩니다.
사례 1: 파라미터 수 — Kimi K3의 2.8조를 용량으로 바꾸면
Moonshot AI가 공개한 Kimi K3는 2.8조 파라미터, 100만 토큰 컨텍스트를 갖춘 오픈 모델입니다. 파라미터 수에 파라미터당 비트 수를 곱하면 원시 가중치의 이론적 하한을 계산할 수 있습니다. 2.8조×4비트÷8은 약 1.4TB입니다.
| 가중치 정밀도 가정 | 원시 가중치 용량 | 64개에 균등 분할할 때 개당 하한 |
|---|---|---|
| 4비트 | 약 1.4TB | 약 21.9GB |
| 8비트 | 약 2.8TB | 약 43.8GB |
| 16비트 | 약 5.6TB | 약 87.5GB |
이 표는 가중치만 계산합니다. 실제 실행에는 활성값, KV 캐시, 통신 버퍼, 런타임 작업 공간이 더 필요합니다. MoE 모델은 토큰마다 일부 전문가만 활성화하지만, 전체 전문가 가중치를 여러 가속기에 분산 저장해야 한다는 문제는 남습니다. Kimi 개발사 스스로 “64개 이상 가속기를 묶은 supernode 구성에서 배포할 것을 권장한다”고 밝힌 것도 이 계산과 방향이 같습니다.
가중치를 나눠 담으면 다음 병목은 장치 사이 통신입니다. 한 토큰에 필요한 전문가가 다른 가속기에 있으면 데이터가 노드 사이를 이동합니다. 그래서 용량뿐 아니라 내부 대역폭과 supernode 인터커넥트가 함께 중요해집니다.
사례 2: 사용자 수 — Codex·ChatGPT Work 800만의 의미
OpenAI의 Codex와 ChatGPT Work 합산 주간 활성 사용자(WAU)가 800만 명에 도달했다는 발표는 채택 신호입니다. 하지만 활성 사용자 수는 채택 지표이고, 인프라 부하는 작업량·동시성·상태 유지량으로 측정해야 합니다.
WAU 800만 명이 한 주 동안 같은 시간만큼 에이전트를 실행한다고 단순 가정하면, 평균 동시 작업 수는 WAU×주간 사용 분÷10,080분으로 계산할 수 있습니다.
| 사용자당 주간 실행 시간 가정 | 평균 동시 작업 |
|---|---|
| 30분 | 약 2만3,810개 |
| 120분 | 약 9만5,238개 |
| 300분 | 약 23만8,095개 |
세 경우 모두 WAU는 같지만 평균 동시 작업은 10배 차이 납니다. 실제 트래픽은 업무 시간대에 몰리고, 한 작업이 여러 모델 호출과 도구 실행을 포함하므로 피크 동시성은 이 단순 평균과 다릅니다. 이 표는 용량 예측 모델이 아니라 WAU만으로는 계획이 불가능하다는 반례입니다.
업무형 AI는 “질문 한 개, 답변 한 개”보다 복잡한 패턴을 만듭니다. 코드베이스, 테스트 로그, 실행 이력을 함께 처리하므로 문맥 길이, 동시성, 반복 추론 빈도가 커지고, HBM(가속기 내부) → 서버 D램(인덱싱·캐시) → SSD(로그·산출물) 계층이 한 작업 안에서 차례로 사용됩니다.
사례 3: 토큰 구조 — 프롬프트에서 루프까지의 곱셈
같은 사용자 수라도 호출 구조가 다르면 토큰 소비는 곱셈으로 달라집니다. 제가 사내 지식 검색 서비스를 운영하며 관찰한 호출 구조를 단순화하면 다음과 같습니다.
| 단계 | 1회 호출 토큰 | 반복·확장 | 총 토큰 | 단순 프롬프트 대비 |
|---|---|---|---|---|
| 프롬프트 | 3,000 | 1회 | 3,000 | 1× |
| 컨텍스트 | 26,500 | 1회 | 26,500 | 약 8.8× |
| 하네스 | 10,800 | 50개 케이스 | 540,000 | 180× |
| 루프 | 15,000 | 8단계 | 120,000 | 40× |
프롬프트 단계는 한 번 잘 묻는 일입니다. 컨텍스트 단계는 관련 문서와 도구 설명을 붙여 입력을 수 배로 키웁니다. 하네스 단계는 테스트 케이스 수만큼 호출을 반복하고, 루프 단계는 에이전트가 계획→실행→관찰→수정을 반복하며 이전 상태를 다시 읽습니다.
토큰은 과금 단위가 아니라 모델이 읽고 저장하고 참조해야 하는 작업 단위입니다. 입력이 길어지면 KV cache가 커지고, 루프가 길어지면 한 작업이 GPU와 메모리를 더 오래 점유하며, 동시 사용자가 늘면 같은 구조가 배치 단위로 반복됩니다.
사례 4: 멀티모달 — 30초 영상 생성의 시간 축
바이트댄스 씨댄스 2.5(Seedance 2.5)는 최대 30초 영상을 이음새 없이 한 번에 생성하고, 영상 한 편에 최대 50개의 참조 이미지와 오디오를 입력할 수 있습니다. 영상 생성은 이미지에 시간 축이 더해진 작업이라, 이전 프레임의 인물·배경·카메라 상태를 유지하며 다음 프레임을 만들어야 합니다.
24fps, 1920×1080, RGB 8비트, 압축 전 출력 프레임만 계산하면:
| 길이 | 24fps 기준 프레임 | 전체 원시 데이터 |
|---|---|---|
| 5초 | 120장 | 약 0.75GB |
| 30초 | 720장 | 약 4.48GB |
실제 서비스는 압축을 쓰고 모델은 픽셀 원본이 아니라 잠재 표현을 처리하므로, 이 표를 HBM 사용량으로 읽으면 안 됩니다. 다만 시간만 6배가 되면 관리해야 할 출력 프레임도 6배가 되고, 긴 시간 일관성을 유지하는 상태 공간이 커진다는 구조적 사실은 유효합니다.
계산으로 말할 수 있는 것과 없는 것
네 사례를 나열한 이유는 결론을 하나로 묶기 위해서입니다.
- 파라미터 수로는 가중치 용량의 하한을 계산할 수 있지만, 실제 배포 노드 수와 비용은 가속기당 메모리와 대역폭, 병렬화 방식이 공개되어야 합니다.
- 사용자 수로는 채택 규모를 알 수 있지만, 사용자당 실행 시간, 작업당 호출 수, 피크 동시성 없이는 서버 수를 계산할 수 없습니다.
- 토큰 구조로는 호출당·작업당 부담의 곱셈을 예상할 수 있지만, 캐시 적중률과 모델 구성에 따라 같은 요청량도 하드웨어 요구가 달라집니다.
- 영상 길이로는 시간 축 상태의 규모를 비교할 수 있지만, 모델의 잠재 공간과 배치 방식이 비공개면 특정 메모리 제품의 수요로 직결할 수 없습니다.
즉 뉴스의 숫자는 환산의 출발점이지, 특정 HBM 물량이나 메모리 업체 실적 예측의 근거가 아닙니다. 방향성 분석과 제품별 수요 전망을 구분하는 것이 정확한 해설의 경계입니다.
단계별로 봐야 할 운영 지표
“AI 메모리 수요가 늘어난다”는 문장만으로는 설비나 아키텍처를 결정할 수 없습니다. 워크로드 단계마다 관찰해야 할 지표가 다릅니다.
| 단계 | 우선 확인할 지표 | 지표가 알려주는 것 |
|---|---|---|
| 학습 | 모델 상태 총바이트, 가속기 이용률, 통신 대기 시간 | 용량 부족인지 통신 병목인지 구분 |
| 추론 prefill | 입력 토큰당 지연, 배치 크기, 메모리 대역폭 | 긴 입력 처리의 계산·대역폭 부담 |
| 추론 decode | 초당 토큰, KV 캐시 점유율, 캐시 적중률 | 동시성과 응답 속도의 균형 |
| Agent 실행 | 작업당 단계 수, 도구 호출 시간, 재시도율 | 모델 밖의 대기와 상태 관리 비용 |
| 장기 기억 | 검색 지연, 인덱스 크기, 보존 기간 | D램·SSD 용량과 데이터 관리 부담 |
증상이 “GPU 메모리 부족”으로 같아 보여도 해결책은 다릅니다. 가중치가 크면 모델 병렬화나 양자화를 검토하고, KV 캐시가 크면 페이지 단위 관리와 prefix caching을, 장기 기록이 크면 검색 인덱스와 보존 정책을 먼저 살펴야 합니다. CXL이나 SSD 오프로딩은 지연 증가를 감수할 수 있는 데이터에만 적용해야 합니다.
결론: 용량 계획은 GPU 매수에서 시작하지 않는다
학습에서는 70B FP16 가중치만 약 140GB이고 옵티마이저 상태가 더해집니다. 추론에서는 같은 40GB 캐시 예산이라도 8K 요청 16개와 128K 요청 1개가 경쟁합니다. 에이전트에서는 검색 인덱스와 실행 기록이, 멀티모달에서는 시간 축 상태가 추가됩니다.
따라서 용량 계획은 “GPU를 몇 장 살까”에서 시작하면 안 됩니다. 모델 상태, 요청 길이, 피크 동시성, 작업 단계 수와 보존 기간을 먼저 측정한 뒤, 어느 데이터를 HBM, 서버 D램, 스토리지에 둘지 결정해야 합니다. 이 순서가 뉴스의 숫자를 인프라 판단으로 바꾸는 방법입니다.
확인한 출처 / 근거
- NVIDIA H200 제품 페이지 — HBM3E 용량과 메모리 대역폭 사양의 공식 근거.
- NVIDIA GB200 NVL72 제품 페이지 — 랙 단위 HBM 용량과 대역폭 사양의 공식 근거.
- NVIDIA TensorRT-LLM KV cache 문서 — KV 캐시 증가 요인과 재사용·오프로딩 방식의 공식 기술 문서.
- Kimi 공식 블로그: Kimi K3 — 파라미터, 컨텍스트, 양자화, supernode 권장 구성을 확인한 개발사 원문.
- Reuters — China’s Moonshot unveils world’s largest open AI model — 공개 시점과 규모에 대한 교차 확인 보도.
- Tom’s Hardware — China’s 2.8-trillion-parameter Kimi K3 benchmark coverage
- Tibo Sottiaux (@thsottiaux), X 포스트 — 8M active users across Codex and ChatGPT Work
- The New Stack — OpenAI hits 8 million Codex users
- OpenAI, Prompt Caching — 반복 프롬프트를 재사용해 지연과 처리 비용을 낮추는 공식 설명.
- Anthropic, “Effective context engineering for AI agents” — 에이전트의 컨텍스트 구성과 관리 원칙.
- Neo4j, “Why AI teams are moving from prompt engineering to context engineering” — 프롬프트에서 컨텍스트 중심 설계로의 전환.
- Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention” (SOSP 2023) — KV 캐시의 동적 증가·단편화가 서빙 병목이 되는 구조.
- Hugging Face Transformers, “KV cache strategies” — KV cache의 동작 방식.
- CXL Consortium, “CXL Specification” — 메모리 확장·공유를 위한 CXL 인터커넥트 규격.
- The Information — ByteDance Unveils Seedance 2.5 Video Model — 모델 공개와 제품 포지셔닝을 확인한 최초 보도.
- The Decoder — ByteDance’s Seedance 2.5 breaks the 30-second barrier — 30초 생성과 참조 입력 사양을 설명한 기술 보도.
- Caixin Global — ByteDance Targets July Launch of Upgraded AI Video Model — 출시 일정과 공개 사양을 교차 확인한 보도.
- TrendForce, “How AI Inference Is Creating New Memory Demand” — AI 추론 확대와 메모리 수요의 연결.