AI 에이전트 로컬 실행 VRAM·RAM 요구량 실측

AI 에이전트를 로컬에서 돌릴 때 VRAM 킬러는 모델이 아니라 '루프가 쌓는 문맥'이다. 에이전트는 한 번의 질문·답이 아니라 결정→도구 실행→관찰을 반복하는데, 매 턴 도구 결과가 문맥에 누적돼 다시 통째로 모델에 먹인다. 실측 핵심 셋: ① 시작 프롬프트 2K가 10스텝 작업이면 20K+ 토큰으로 부푼다(도구 정의만 1~3K). ② 그 문맥은 KV 캐시에 쌓여 긴 루프에선 KV가 모델 가중치보다 커진다. ③ 그래서 예산은 첫 응답이 아니라 '루프 전체' 기준이어야 한다 — 안 그러면 작업 중간에 OOM으로 죽는다. 즉 "모델이 8GB니 되겠지"가 아니라 모델+누적 문맥+동시성을 함께 잡아야 한다.

한 줄 요약: 에이전트 메모리는 눈덩이다. 한 걸음(도구 호출)마다 관찰이 눈처럼 붙어, 언덕을 다 내려오기 전에(작업 완료 전에) 눈덩이가 방(VRAM)을 꽉 채운다. 첫 걸음 크기로 방을 고르면 중간에 막힌다.

에이전트 메모리는 왜 다른가?#

루프가 문맥을 계속 되먹이기 때문이다. 일반 채팅은 한 번 넣고 한 번 답하면 끝이지만, 에이전트는 시스템 프롬프트+도구 목록+이전 단계 전부를 매 턴 다시 통과시킨다. 그래서 문맥이 자라고 KV 캐시가 계속 VRAM을 먹는다. 프로덕션 에이전트는 요청당 5만~50만 입력 토큰을 쓰기도 한다(출력은 수백 토큰뿐). 결론: 에이전트 사이징의 질문은 "어떤 모델이 들어가나"가 아니라 "모델+문맥창+검색+동시 실행 몇 개가 함께 들어가나"다.

문맥은 얼마나 쌓이나?#

토큰 수에 선형으로, 루프가 길수록 무섭게 쌓인다. 70B는 KV가 32K에서 약 14GB, 128K에서 약 43GB로 가중치(fp16 140GB)의 상당 부분을 넘본다. 소형 모델도 기본 문맥선 2~6GB, 긴 문맥선 훨씬 더다 — 30B로 128K 대화를 하면 모델 외에 8~12GB RAM이 더 든다. 도구 결과가 큰 문서·로그면 한 번에 수 GB가 붙는다. 그래서 도구 출력을 필요한 만큼만 잘라 문맥에 넣는 '문맥 엔지니어링'이 raw VRAM만큼 중요하다.

왜 작업 중간에 터지나?#

KV 캐시가 통제 없이 자라기 때문이다. 로컬에선 징후가 뚜렷하다 — 긴 대화 뒤 생성이 급격히 느려지고(KV가 스왑으로 밀림), CPU 오프로드 중 OOM이 나고, Ollama·llama.cpp가 생성 도중 커널 OOM 킬러에 죽는다. 또 prefill 스파이크 주의: 어텐션 행렬이 시퀀스 길이의 제곱으로 순간 커져, KV가 들어가도 그 순간 터질 수 있다(FlashAttention 필요). 즉 에이전트가 긴 문서를 읽거나 긴 추론 루프에 들어가는 바로 그 순간 인프라가 무너진다.

어떻게 예산하고 줄이나?#

핵심은 루프 전체로 예산하고, KV를 눌러 OOM을 피하는 것이다.

• 예산: 가중치+문맥에 15~20% 헤드룸을 더해 GPU 급을 정한다(빠듯하면 스왑으로 기어간다).
• 압축: FP8 KV 캐시(예: OLLAMA_KV_CACHE_TYPE=q8_0)로 절반, 문맥은 num_ctx·max-model-len으로 캡, prefix 캐싱으로 시스템 프롬프트 재사용.
• 규율: 문맥은 길수록 좋은 게 아니다 — 아주 긴 문맥은 중간이 흐려지는 'lost-in-the-middle'이 있어, 요약·가지치기가 답이다. 정확한 값은 내 작업 루프로 직접 재라.

함께 읽기: 에이전트 브라우저 제어, 직접 써보고 느낀 점과 한계, ComfyUI로 이미지·영상 만들기: 우리가 직접 굴리며 잰 운영 회고

함께 읽기: 로컬 오픈 LLM VRAM·RAM 요구량, 직접 계산·실측, 로컬 음성합성(TTS) 오픈모델 — VRAM·RAM 요구량 실측

참고 링크

• vLLM(PagedAttention·prefix 캐싱)
• Ollama(KV 캐시 타입·num_ctx)
• llama.cpp(KV 양자화·문맥)
• PagedAttention 논문(vLLM)
• FlashAttention(prefill 스파이크 완화)

참고: GB·토큰 수치는 2026년 공개 측정·추정이며 모델·문맥·동시성·어텐션 백엔드에 따라 달라진다(영구 수치 아님). KV는 도구 출력·문서 크기에 크게 좌우되니, 정확한 메모리는 내 에이전트 루프로 직접 재라(여기 수치는 출발점). 문맥을 늘리는 게 항상 이득은 아니다(중간 소실). 에이전트·서빙 스택은 빠르게 바뀌니 분기별로 다시 본다.