학습·​추론·​Agent가 바꾸는 메모리 수요

학습 가중치와 추론 KV 캐시를 계산식으로 비교하고, 같은 40GB 캐시 예산에서도 컨텍스트 길이와 동시 사용자 조합이 달라지는 이유를 설명합니다.

생성형 AI를 이야기할 때 우리는 보통 모델 크기와 GPU 성능을 먼저 봅니다. 몇 조 개 파라미터인가, 어떤 GPU를 몇 장 썼는가, 토큰 생성 속도가 얼마나 빠른가 같은 지표입니다. 그런데 실제 AI 인프라를 들여다보면 점점 더 자주 등장하는 병목이 있습니다. 바로 메모리입니다.

AI의 발전 단계를 단순화하면 세 단계로 볼 수 있습니다. 첫째는 모델을 만드는 학습 단계, 둘째는 사용자의 질문에 답하는 추론 단계, 셋째는 여러 도구와 기억을 연결해 일을 수행하는 Agent 단계입니다. 흥미로운 점은 이 세 단계가 모두 메모리를 필요로 하지만, 필요한 메모리의 성격이 서로 다르다는 것입니다.

1단계: 학습은 “모델 전체를 품는 메모리”가 필요하다

학습 단계에서는 모델 파라미터뿐 아니라 gradient, optimizer state, activation까지 함께 다뤄야 합니다. 단순히 70B 모델의 FP16 가중치만 보면 약 140GB 수준이지만, 실제 학습에서는 그보다 훨씬 많은 메모리가 필요합니다. 혼합 정밀도(mixed precision) Adam 기준으로 파라미터당 12~16바이트 이상이 필요할 수 있고, activation과 통신 버퍼까지 더해집니다.

그래서 대형 모델 학습은 한 장의 GPU 메모리 문제가 아니라 수백~수천 개 GPU에 모델과 데이터를 어떻게 나눠 담을지의 문제가 됩니다. 이 단계에서 중요한 메모리는 HBM입니다. HBM은 GPU 가까이에 붙어 높은 대역폭을 제공합니다. 학습은 대량의 행렬 연산과 파라미터 업데이트가 반복되기 때문에, 메모리 용량뿐 아니라 대역폭이 성능을 좌우합니다.

다만 학습 수요는 소수의 빅테크와 대형 연구기관 중심입니다. 모델을 새로 만드는 기업은 많지 않고, 학습 클러스터는 매우 비쌉니다. 그래서 학습 단계의 메모리 수요는 “초고성능 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 캐시 예산에 적용하면 다음 조합이 거의 같은 공간을 사용합니다.

이 표는 특정 서버의 성능 보장이 아니라, 캐시 예산을 짧은 요청 여러 개와 긴 요청 한 개가 서로 다르게 소비한다는 비교입니다. 실제 운영에서는 페이지 단위 할당, 양자화, prefix caching, eviction과 단편화가 결과를 바꿉니다.

이 때문에 추론 시대의 메모리 병목은 단순히 “모델을 올릴 수 있느냐”가 아닙니다. 얼마나 많은 사용자를 동시에 처리할 수 있는가, 긴 문서를 얼마나 유지할 수 있는가, 반복되는 프롬프트를 얼마나 재사용할 수 있는가가 중요해집니다. H200이 141GB HBM3E와 4.8TB/s 대역폭을 강조하고, GB200 NVL72 같은 랙 단위 시스템이 13.4TB HBM3E와 576TB/s 대역폭을 내세우는 것도 이 흐름과 맞닿아 있습니다.

3단계: Agent는 “GPU 메모리 밖의 기억”까지 요구한다

Agent 단계에서는 메모리의 의미가 한 번 더 바뀝니다. 챗봇은 한 번 질문에 답하고 끝날 수 있지만, Agent는 작업 목표를 세우고, 문서를 읽고, 도구를 호출하고, 이전 실행 결과를 기억하고, 다음 행동을 결정합니다. 여기서 필요한 것은 HBM만이 아닙니다.

Agent에는 짧은 작업 맥락을 담는 short-term memory, 사용자 선호와 과거 작업을 저장하는 long-term memory, 문서와 코드를 검색하는 vector database, 실행 로그와 상태를 보관하는 스토리지가 필요합니다. 즉 Agent의 메모리 수요는 GPU 안의 HBM에서 서버 D램, CXL 같은 확장 메모리, NVMe SSD, 분산 스토리지까지 이어지는 계층형 구조로 확장됩니다.

특히 Agent가 길고 복잡한 업무를 처리하려면 컨텍스트가 길어집니다. 컨텍스트가 길어질수록 추론 단계의 KV cache 부담도 커집니다. 동시에 과거 기록을 모두 GPU에 올려둘 수는 없기 때문에, 필요한 정보만 빠르게 찾아와 다시 컨텍스트에 넣는 검색·저장 구조가 중요해집니다. 앞으로의 AI 인프라는 “GPU 몇 장인가”보다 “HBM, D램, 스토리지, 네트워크가 얼마나 잘 이어져 있는가”가 더 중요해질 수 있습니다.

단계별로 봐야 할 운영 지표

“AI 메모리 수요가 늘어난다”는 문장만으로는 설비나 아키텍처를 결정할 수 없습니다. 워크로드 단계마다 관찰해야 할 지표가 다릅니다.

증상이 “GPU 메모리 부족”으로 같아 보여도 해결책은 다를 수 있습니다. 가중치가 크면 모델 병렬화나 양자화를 검토하고, KV 캐시가 크면 페이지 단위 관리와 prefix caching을, 장기 기록이 크면 검색 인덱스와 보존 정책을 먼저 살펴야 합니다. CXL이나 SSD 오프로딩은 지연 증가를 감수할 수 있는 데이터에만 적용해야 합니다.

계산에서 얻을 수 있는 결론

학습에서는 70B FP16 가중치만 약 140GB이고, 옵티마이저 상태와 활성값이 더해집니다. 추론에서는 같은 40GB 캐시 예산이라도 8K 요청 16개와 128K 요청 1개가 경쟁할 수 있습니다. Agent 단계에서는 여기에 검색 인덱스, 도구 실행 기록과 장기 보존 데이터가 추가됩니다.

따라서 용량 계획은 “GPU를 몇 장 살까”에서 시작하면 안 됩니다. 모델 상태, 요청 길이, 피크 동시성, 작업 단계 수와 보존 기간을 먼저 측정한 뒤 어느 데이터를 HBM, 서버 D램과 스토리지에 둘지 결정해야 합니다. 이 순서가 학습·추론·Agent를 하나의 막연한 메모리 수요로 합치지 않는 방법입니다.

확인한 출처 / 근거

• NVIDIA H200 제품 페이지 — HBM3E 용량과 메모리 대역폭 사양의 공식 근거.
• NVIDIA GB200 NVL72 제품 페이지 — 랙 단위 HBM 용량과 대역폭 사양의 공식 근거.
• NVIDIA TensorRT-LLM KV cache 문서 — KV 캐시 증가 요인과 재사용·오프로딩 방식의 공식 기술 문서.
• TensorRT-LLM KV cache 소스 코드 문서 — 구현 세부와 문서 변경 이력을 확인할 수 있는 원문 저장소.