[AI] GPU가 다 하는 줄 알았는데, Agentic AI 시대에 CPU가 다시 중요해진 이유
AI INFRA · PREFILL/DECODE · HETEROGENEOUS COMPUTING
GPU가 다 하는 줄 알았는데,
Agentic AI 시대에 CPU가 다시 중요해진 이유
지난 몇 년간 AI 인프라의 주인공은 단연 GPU였다. 그런데 Agent가 검색하고, API를 호출하고, 코드를 실행하고, 다시 모델에게 묻기 시작하자 CPU가 다시 무대 중앙으로 걸어 나오고 있다. GPU의 시대가 끝났다는 얘기는 아니다. 오히려 GPU를 비싼 계산에만 쓰기 위해 CPU가 더 중요해졌다.
LLM은 답변 하나를 두 번 다르게 계산한다
LLM 추론은 하나의 연속된 작업처럼 보이지만, 하드웨어 관점에서는 성격이 전혀 다른 Prefill과 Decode로 나뉜다.
Prefill — 질문을 한꺼번에 읽기
입력 프롬프트 전체를 병렬 처리해 각 토큰의 Key·Value를 계산하고 KV Cache를 만든다. 긴 문서나 대화 이력이 들어올수록 연산량이 커지며, 대규모 행렬 연산을 많이 수행해 대체로 compute-bound다.
Decode — 답을 한 토큰씩 쓰기
이미 만든 KV Cache를 참조하면서 다음 토큰을 하나씩 생성한다. 각 단계의 병렬성은 상대적으로 작고 모델 가중치와 Cache를 계속 읽어야 하므로 대체로 memory-bandwidth-bound다.
시스템 지시 + RAG 문서
행렬 계산 · KV 생성
대화 문맥의 작업 기억
Token 1 → 2 → 3…
그래서 LLM 서비스에는 서로 다른 두 지연시간이 있다. 사용자가 답변 첫 글자를 보기까지의 TTFT(Time To First Token)는 주로 Prefill과 대기열의 영향을 받고, 이후 글자가 얼마나 부드럽게 나오는지를 보여주는 ITL(Inter-Token Latency)은 Decode 성능과 밀접하다. “평균 응답시간” 하나만 보면 병목을 찾기 어려운 이유다.
왜 하필 GPU였을까: 빠른 CPU를 많이 붙이면 안 되나?
Transformer의 핵심 연산은 거대한 행렬 곱이다. CPU는 복잡한 분기와 다양한 업무를 낮은 지연으로 처리하는 데 강하지만, GPU는 수천 개의 작은 연산을 동시에 수행하는 구조와 높은 메모리 대역폭을 가진다. 쉽게 말하면 CPU는 숙련된 소수의 셰프, GPU는 같은 칼질을 동시에 하는 거대한 조리 라인이다.
| 특성 | CPU | GPU |
|---|---|---|
| 강점 | 분기, 직렬 로직, OS, 네트워크, DB, 범용 코드 | 대규모 병렬 행렬 연산, 높은 메모리 대역폭 |
| LLM 역할 | 토큰화, 라우팅, 검색, Tool, 보안, 스케줄링 | Attention, MLP, Prefill, Decode |
| 메모리 | DRAM 용량이 크고 상대적으로 저렴 | HBM은 빠르지만 비싸고 용량이 제한적 |
| 잘못 쓰는 경우 | 대형 모델의 고처리량 생성 | I/O 대기, 단순 JSON 처리, API 호출 대기 |
GPU가 비싼 이유도 칩 가격만이 아니다. HBM, 고속 인터커넥트, 전력·냉각, 여러 GPU에 모델을 나누는 통신 비용까지 포함된다. 무엇보다 GPU 메모리에는 모델 가중치뿐 아니라 요청마다 커지는 KV Cache가 함께 들어간다. 사용자가 늘거나 컨텍스트가 길어지면 연산보다 먼저 메모리가 부족해질 수 있다.
그런데 왜 Agentic AI가 CPU를 다시 불렀을까
일반 Chatbot은 “한 번 입력 → 한 번 생성”에 가까웠다. Agent는 다르다. 계획하고, 검색하고, 여러 도구를 호출하고, 결과를 검증한 뒤 다시 모델을 부른다. 모델 추론 사이사이에 GPU가 잘하지 못하는 작업이 끼어든다.
계획 생성
JSON 검증
검색·API·DB
권한·정책 검사
결과 판단
1. Tool Calling은 대부분 CPU와 I/O의 일이다
REST API, Python 함수, SQL, 파일 파싱, 브라우저 자동화는 대규모 행렬 계산이 아니다. 응답을 기다리는 동안 GPU를 점유하면 가장 비싼 서버가 HTTP 응답을 멍하니 기다리게 된다. Agent Runtime은 비동기 CPU Worker에서 도구를 실행하고 GPU Serving은 별도 Pool로 분리하는 편이 효율적이다.
2. RAG는 모델 호출 전후에 CPU 집약적 파이프라인을 만든다
문서 파싱, 청킹, 메타데이터 처리, BM25 검색, 권한 필터, 결과 병합, 프롬프트 조립은 CPU의 몫이 크다. Vector Search는 GPU로 가속할 수도 있지만 일반적인 기업 규모에서는 CPU 기반 ANN과 DB가 비용·운영 측면에서 충분한 경우가 많다.
3. 보안과 Guardrail은 분기 투성이다
PII 탐지, DLP, 정책 평가, Tool Allowlist, 출력 스키마 검증, 감사 로그는 “조건에 따라 다른 행동”이 핵심이다. Agent가 복잡해질수록 모델 계산보다 이런 제어 로직과 상태 관리가 많아진다.
4. Agent는 많은 작은 요청을 만든다
하나의 사용자 요청이 Planner, Retriever, Critic, Summarizer 호출로 쪼개진다. 짧고 불규칙한 요청이 폭증하면 Tokenization, Serialization, TLS, Queue, Scheduler의 CPU 부담이 커진다. GPU 사용률이 낮다고 GPU가 부족한 것이 아니라, CPU 전처리나 네트워크가 GPU에 일을 제때 공급하지 못하는 경우도 생긴다.
5. CPU DRAM이 GPU HBM의 ‘창고’가 된다
모든 KV Cache와 모델 상태를 비싼 HBM에 계속 둘 필요는 없다. 덜 자주 쓰는 Cache를 CPU Host Memory, 로컬 SSD, 공유 스토리지로 내리는 계층형 캐시가 등장했다. NVIDIA Dynamo도 KV Cache를 GPU 메모리에서 CPU 메모리와 스토리지로 Offload하는 구조를 제시한다. CPU가 모델을 직접 계산하지 않아도, GPU가 다시 계산하지 않게 만드는 역할을 한다.
최신 인프라 트렌드: 한 장비가 다 하지 않는다
Prefill과 Decode는 필요한 자원이 다르다. 그래서 최근 Serving은 두 단계를 서로 다른 Worker로 분리하는 Disaggregated Serving으로 이동하고 있다. Prefill Pool은 연산 처리량과 TTFT에, Decode Pool은 메모리 대역폭과 ITL에 맞춰 독립적으로 확장한다.
Auth · Router · Scheduler
긴 입력 · TTFT 최적화
토큰 생성 · ITL 최적화
RAG · DB · API · Sandbox
HBM · DRAM · SSD
다만 분리가 언제나 이득은 아니다. Prefill에서 생성한 큰 KV Cache를 Decode Worker로 옮기는 시간이 절약한 연산보다 길 수 있다. 트래픽이 작거나 입력·출력 길이가 일정한 서비스는 하나의 GPU Pool에서 Continuous Batching하는 편이 단순하고 빠를 수 있다. 최신 Serving의 핵심은 무조건 분리가 아니라 ISL·OSL·동시성·SLO에 따라 자원을 동적으로 배치하는 것이다.
| 워크로드 | 주 병목 | 먼저 볼 지표 |
|---|---|---|
| 긴 문서 요약 | Prefill GPU 연산 | TTFT, Input Token/s |
| 긴 추론 답변 | Decode·HBM 대역폭 | ITL, Output Token/s |
| RAG QA | 검색·Rerank·Prefill 혼합 | Retrieval P95, TTFT |
| Tool-heavy Agent | CPU·네트워크·외부 API | Step Latency, CPU Queue, Tool P95 |
| 다중 사용자 Chat | KV Cache·Scheduler | Cache Hit, Queue, GPU Memory |
금융권 AI 플랫폼이라면 어떻게 나눌까
금융권에서는 GPU 효율만큼 격리와 감사 가능성이 중요하다. 모델 서버 안에 Agent Tool을 함께 넣기보다 역할별 실행 영역을 분리하는 편이 안전하고 운영하기 쉽다.
# GPU는 모델 계산, CPU는 정책과 실행을 담당한다.
async def run_agent(request, principal):
policy = cpu_policy_engine.authorize(request, principal)
context = await cpu_retrieval_pool.search(
request.query, filters=policy.allowed_documents
)
plan = await gpu_inference_pool.generate(
prompt=build_prompt(request, context),
workload="short_prefill_decode"
)
for call in validate_tool_calls(plan, policy):
result = await cpu_sandbox_pool.execute(call)
audit.write(principal, call, result.status)
return await gpu_inference_pool.generate(
prompt=build_final_prompt(plan, result),
workload="decode_heavy"
)- GPU Plane: 승인된 모델의 Prefill·Decode와 Embedding/Reranker 중 가속 효과가 검증된 작업
- CPU Control Plane: 인증, 세션, 모델 라우팅, Queue, Rate Limit, DLP, 정책 판단
- CPU Tool Plane: RAG, SQL, 내부 API, 파일 변환, Agent Sandbox를 최소권한으로 실행
- Memory Plane: HBM·Host DRAM·SSD 사이 Cache 등급과 민감정보 보존기간을 함께 관리
예전에는 모델 크기와 GPU 개수가 AI 인프라의 거의 전부처럼 보였다. 지금은 요청 하나가 시스템 전체를 여행한다. 모델이 생각하는 시간뿐 아니라 검색하는 시간, 권한을 확인하는 시간, 도구가 일하는 시간, Cache를 옮기는 시간까지 합쳐야 사용자 경험이 된다. AI 인프라는 이제 GPU 서버가 아니라 CPU·GPU·메모리·네트워크가 역할을 나눠 갖는 분산 시스템이다.
참고자료
- NVIDIA — Dynamo와 Disaggregated Prefill/Decode
- POD-Attention — Prefill/Decode의 서로 다른 병목
- PagedAttention — vLLM의 KV Cache 메모리 관리
- NVIDIA Dynamo — 공식 오픈소스 저장소
- vLLM — Disaggregated Prefilling
※ Prefill이 항상 연산 병목이고 Decode가 항상 메모리 병목인 것은 아니다. 모델 구조, 입력·출력 길이, Batch 크기, Quantization, 하드웨어와 Serving 설정에 따라 병목은 달라지므로 실제 트래픽으로 TTFT·ITL·Queue·GPU/CPU 사용률을 함께 측정해야 한다.