AI Agent는 왜 KV Cache가 중요한가: vLLM과 LMCache로 반복 문맥 비용 줄이기
AI Agent는 일반적인 챗봇보다 훨씬 많은 문맥을 반복해서 읽습니다.
System prompt, tool schema, MCP 설명, 저장소 규칙, 코드베이스 문서, 대화 이력까지 매 요청에 다시 포함됩니다. Codex, Claude Code, Hermes Agent처럼 도구를 사용하고 여러 단계를 수행하는 Agent일수록 이 반복 문맥은 빠르게 길어집니다.
이때 중요한 것이 KV Cache입니다. 같은 문맥을 다시 계산하지 않고 재사용할 수 있다면 첫 응답까지 걸리는 시간과 GPU 연산량을 크게 줄일 수 있기 때문입니다. vLLM의 Automatic Prefix Caching(APC)이 첫 단계라면, LMCache는 이 캐시를 GPU 한 대의 임시 메모리에서 여러 요청과 인스턴스가 활용할 수 있는 인프라 자산으로 확장합니다.
30초 요약
AI Agent는 매 요청마다 긴 공통 문맥을 반복하므로 일반 챗봇보다 KV Cache 재사용의 가치가 큽니다.
vLLM APC는 동일한 prefix의 KV Cache를 GPU 안에서 재사용해 prefill 시간을 줄입니다.
LMCache는 KV Cache를 GPU, CPU DRAM, NVMe, 원격 저장소로 확장하고 여러 vLLM 인스턴스 사이에서 공유할 수 있게 합니다.
효과는 cache hit ratio, 반복 문맥의 길이, 저장·전송 비용에 따라 달라집니다. 출력 생성이 긴 decode 중심 작업이나 매번 문맥이 달라지는 요청에는 효과가 제한적입니다.
Codex와 Claude Code가 사용하는 managed model backend에는 사용자가 LMCache를 직접 설치할 수 없습니다. LMCache는 Hermes Agent처럼 self-hosted vLLM backend를 사용하는 Agent, 또는 자체 Agent 플랫폼에 직접 적용하는 기술입니다.
AI Agent는 왜 매번 같은 내용을 다시 읽을까?
코딩 Agent가 한 번의 작업을 시작할 때 모델이 받는 입력은 사용자의 한 문장만이 아닙니다. 일반적으로 다음과 같은 문맥이 함께 전달됩니다.
문맥 | 예시 | 변화 빈도 |
|---|---|---|
System prompt | Agent 역할, 안전 정책, 응답 규칙 | 낮음 |
도구 정의 | 함수 schema, MCP server와 Skill 설명 | 낮음 |
조직·저장소 규칙 | AGENTS.md, CLAUDE.md, coding convention | 낮음 |
프로젝트 문맥 | 아키텍처 문서, 주요 코드, API 명세 | 중간 |
대화 이력 | 이전 계획, tool call과 결과 | 높음 |
현재 작업 | 이번 요청과 새로 읽은 파일 | 매번 변경 |
앞부분의 system prompt, tool schema, 조직 규칙은 여러 요청에서 거의 동일합니다. 같은 저장소를 여러 Agent가 다룬다면 프로젝트 문맥도 상당 부분 겹칩니다. 그럼에도 재사용 체계가 없다면 모델은 이 토큰들을 요청마다 처음부터 계산합니다.
Agent workload의 핵심 비용은 새로운 질문만이 아니라, 새로운 질문 앞에 매번 붙는 긴 공통 문맥에서 발생합니다.
KV Cache는 무엇을 저장하는가
Transformer가 입력 토큰을 처리하면 각 attention layer에서 Key와 Value tensor가 생성됩니다. 이후 토큰을 생성할 때 이전 토큰의 Key와 Value를 매번 다시 계산하지 않도록 저장해 두는 것이 KV Cache입니다.
LLM inference는 크게 두 단계로 나눌 수 있습니다.
Prefill: 입력 prompt 전체를 처리하고 첫 토큰 생성에 필요한 KV Cache를 만듭니다.
Decode: 이미 만들어진 KV Cache를 참조하면서 출력 토큰을 한 개씩 생성합니다.
입력이 길수록 prefill 연산은 커집니다. 20K~100K tokens의 저장소 문맥을 반복하는 Agent에서는 첫 토큰이 나오기 전까지의 시간, 즉 TTFT(Time To First Token)가 사용자 경험과 처리량을 좌우할 수 있습니다.
KV Cache를 재사용한다는 것은 모델의 답을 저장하는 것이 아닙니다. 동일한 입력 구간을 모델이 이미 읽고 만들어 둔 중간 계산 결과를 다시 쓰는 것입니다. 따라서 이후 질문과 출력은 달라도 공통 prefix가 같다면 prefill 일부를 생략할 수 있습니다.
vLLM의 Automatic Prefix Caching
vLLM은 Automatic Prefix Caching을 제공합니다. 이전 요청과 token-identical한 prefix가 있으면 해당 구간의 KV block을 재사용합니다.
예를 들어 세 명의 Agent가 같은 repository instruction과 tool schema를 읽은 뒤 서로 다른 작업을 수행한다면, 공통 prefix의 KV Cache를 다시 계산하지 않을 수 있습니다.
다만 APC의 역할에는 분명한 경계가 있습니다.
줄어드는 것은 주로 prefill 시간입니다. 이미 긴 답변을 생성하는 decode 단계 자체가 빨라지는 것은 아닙니다.
캐시는 기본적으로 vLLM engine이 관리하는 KV pool 안에 존재합니다.
GPU 메모리가 부족하면 LRU 정책에 따라 오래된 block이 제거됩니다.
다른 vLLM instance나 재시작된 process가 기존 캐시를 그대로 공유하는 구조는 아닙니다.
LMCache가 바꾸는 것: KV Cache를 데이터 계층으로
LMCache는 KV Cache를 GPU 내부의 일시적인 메모리로만 보지 않습니다. GPU, CPU DRAM, local disk/NVMe, remote backend를 포함하는 multi-tier storage에 저장하고 필요할 때 다시 불러오는 데이터 계층으로 다룹니다.
LMCache의 deployment modes. 출처: LMCache 공식 문서
계층 | 장점 | 고려사항 |
|---|---|---|
GPU | 가장 빠른 재사용 | 용량이 작고 모델 실행 메모리와 경쟁 |
CPU DRAM | GPU보다 큰 cache pool | PCIe 전송 비용과 host memory 사용량 |
NVMe / local disk | 더 큰 용량, process 재시작 이후 활용 가능 | I/O latency와 쓰기 증폭 |
Remote backend | 여러 instance와 node가 공유 | network latency와 운영 복잡도 |
핵심은 단순한 offload가 아닙니다. 여러 inference instance가 같은 cache를 조회할 수 있고, prefill worker와 decode worker를 분리한 환경에서도 KV를 전달할 수 있습니다. vLLM 공식 예제는 단일 node에 적합한 in-process 방식과, instance 간 공유에 적합한 multiprocess 방식 등을 안내합니다.
LMCache는 KV Cache를 GPU 내부의 임시 데이터에서, 여러 요청과 vLLM instance가 공유하는 인프라 자산으로 바꿉니다.
Codex, Claude Code, Hermes Agent에서 왜 더 중요한가
여기서 제품과 workload를 구분해야 합니다. Codex와 Claude Code는 Agent client이지만, 기본적으로 사용하는 hosted model의 inference infrastructure는 각 provider가 운영합니다. 사용자가 그 backend에 LMCache를 설치할 수는 없습니다.
반면 Hermes Agent나 자체 개발 Agent가 local/open model을 vLLM으로 호출한다면 LMCache를 직접 적용할 수 있습니다. Codex·Claude Code와 유사한 동작을 self-hosted backend로 구현하거나 일부 작업을 local model로 분산할 때 같은 원리가 적용됩니다.
1. 긴 system prompt와 tool schema
Agent는 사용할 수 있는 도구를 모델에 설명해야 합니다. MCP server와 Skill 수가 늘어날수록 tool schema도 길어집니다. 이 정보는 매 작업에서 반복되기 때문에 안정적인 prefix로 구성하면 cache hit 가능성이 높습니다.
2. 저장소 규칙과 회사의 업무 기준
AGENTS.md, coding convention, 보안 규칙, 리뷰 기준처럼 여러 작업에 공통으로 적용되는 문맥도 좋은 재사용 대상입니다. 같은 팀의 여러 Agent가 같은 기준을 읽는다면 공통 prefix의 계산 비용을 나눌 수 있습니다.
3. 여러 단계로 이어지는 Agent loop
Agent는 계획을 세우고, 파일을 읽고, tool을 호출하고, 결과를 다시 해석합니다. 매 단계에서 이전 대화 이력이 반복되므로 multi-turn session에서는 재사용 가능한 문맥이 빠르게 커집니다.
4. 같은 repository에서 동시에 일하는 여러 Agent
다른 작업을 맡은 Agent라도 architecture document, dependency map, test policy는 공유합니다. cache가 instance마다 격리되어 있으면 같은 내용을 각각 계산하지만, shared cache layer가 있으면 공통 문맥을 재사용할 여지가 생깁니다.
효과가 큰 workload와 작은 workload
효과가 큰 경우 | 효과가 제한적인 경우 |
|---|---|
긴 system prompt와 tool schema가 고정된 Agent | 입력이 짧고 매 요청이 완전히 다른 경우 |
같은 repository 문맥을 공유하는 동시 작업 | 출력이 매우 긴 decode 중심 작업 |
같은 문서를 반복 참조하는 RAG | prefix의 순서·표현이 매번 바뀌는 prompt |
긴 multi-turn Agent session | cache를 읽는 비용이 재계산보다 큰 짧은 구간 |
여러 vLLM instance가 공통 context를 사용하는 환경 | 코드·문서가 매 요청마다 크게 변경되는 환경 |
Context 길이와 동시 사용자 수에 따른 cache regime 비교. 출처: LMCache 공식 agentic workload benchmark
중요한 지표는 cache 용량이 아니라 실제로 재사용된 token 비율입니다. timestamp, request ID, tool 순서처럼 자주 바뀌는 값을 prefix 앞부분에 배치하면 이후 내용이 같아도 cache hit가 깨질 수 있습니다. 안정적인 공통 문맥을 앞에 두고 동적인 정보는 뒤로 보내는 prompt 설계가 함께 필요합니다.
LMCache 도입 전에 측정해야 할 것
공식 문서와 LMCache 논문은 workload에 따라 큰 TTFT 및 throughput 개선을 보고합니다. 다만 논문의 최대 수치를 모든 서비스에 그대로 적용할 수는 없습니다. 저장장치, interconnect, model size, prompt 중복률에 따라 결과가 크게 달라집니다.
따라서 운영 환경에서는 다음 네 가지 구성을 같은 workload로 비교해야 합니다.
Prefix caching이 없는 vLLM baseline
vLLM APC
vLLM APC + LMCache CPU offload
여러 instance가 공유하는 LMCache multiprocess 또는 remote 구성
32 concurrent users, 100K context stress test의 TTFT 비교. 특정 MI300X 환경에서 측정된 결과입니다. 출처: LMCache 공식 benchmark
측정할 지표는 다음과 같습니다.
TTFT p50 / p95
input token throughput과 end-to-end latency
cached token 수와 cache hit ratio
cache store / retrieve latency
GPU utilization, CPU memory, PCIe·network bandwidth
동시 요청 수가 증가할 때의 tail latency
Agent workload용 benchmark는 이렇게 설계할 수 있습니다
단순히 같은 prompt를 두 번 호출하는 benchmark는 실제 Agent workload를 충분히 반영하지 못합니다. 다음 시나리오를 분리해 측정하는 편이 좋습니다.
공통 repository context + 서로 다른 작업: 32K tokens의 동일 문맥 뒤에 bug fix, test 작성, 문서화 요청을 각각 붙입니다.
Multi-turn session: 8~12번의 tool call이 이어지는 과정에서 대화 이력이 증가할 때 TTFT를 측정합니다.
동일한 tool schema + 서로 다른 사용자: 여러 Agent가 같은 MCP·Skill 정의를 공유할 때 instance 간 cache 재사용을 확인합니다.
완전히 고유한 prompt: cache hit가 거의 없을 때 LMCache overhead가 어느 정도인지 확인합니다.
이렇게 해야 “cache가 있을 때 빠르다”가 아니라, 우리 Agent workload에서 경제성이 있는지를 판단할 수 있습니다.
현재 vLLM에서 LMCache 연결하기
LMCache의 현재 quickstart는 multiprocess connector를 사용한 예시를 제공합니다. 설치 버전과 connector API는 빠르게 바뀌므로 실제 적용 전에는 최신 quickstart와 vLLM integration example을 함께 확인해야 합니다.
vllm serve Qwen/Qwen3-8B \
--port 8000 \
--kv-transfer-config \
'{"kv_connector":"LMCacheMPConnector","kv_role":"kv_both","kv_connector_extra_config":{"lmcache.mp.host":"localhost","lmcache.mp.port":5555}}'단일 node에서 기능을 검증할 때는 in-process 구성으로 시작할 수 있지만, 여러 vLLM instance가 cache를 공유하는 것이 목표라면 multiprocess 또는 remote backend를 포함한 구조가 필요합니다. 버전별 connector 이름과 module path가 다를 수 있으므로 command를 그대로 고정하기보다 배포 버전에 맞춘 검증이 필수입니다.
운영에서 놓치기 쉬운 세 가지
1. Cache hit를 높이는 prompt 구조
고정된 system prompt, tool schema, 조직 규칙을 앞부분에 배치하고 session마다 달라지는 값은 뒤로 보내야 합니다. 내용이 같아도 token sequence가 다르면 재사용할 수 없습니다.
2. 보안과 격리
회사 문서와 코드에서 만든 KV Cache도 민감한 운영 데이터입니다. tenant, project, permission boundary를 고려하지 않은 shared cache는 정보 격리 문제를 만들 수 있습니다. cache key, namespace, retention, 삭제 정책을 서비스 권한 모델과 함께 설계해야 합니다.
3. 저장보다 비싼 전송
대형 모델의 KV Cache는 매우 큽니다. CPU나 remote storage에 저장했다고 항상 빨라지는 것은 아닙니다. 불러오는 시간이 GPU에서 다시 계산하는 시간보다 짧아야 의미가 있습니다. chunk size, storage tier, network bandwidth를 workload에 맞게 조정해야 합니다.
결론: Agent 시대에는 모델만큼 문맥을 운영하는 방식이 중요합니다
AI Agent가 수행하는 작업이 길어질수록 모델은 같은 system prompt, tool schema, 회사 규칙과 repository context를 반복해서 읽습니다. 이 반복을 그대로 두면 Agent 수와 사용량이 늘어날수록 GPU 비용과 TTFT가 함께 증가합니다.
vLLM APC는 동일한 prefix를 GPU 안에서 재사용하는 좋은 출발점입니다. LMCache는 여기서 한 단계 더 나아가 KV Cache를 CPU, disk, remote backend로 확장하고 여러 instance가 활용할 수 있는 데이터 계층으로 만듭니다.
다만 LMCache가 모든 inference를 빠르게 만드는 것은 아닙니다. 먼저 우리 workload에서 공통 문맥이 얼마나 반복되는지, cache 전송 비용보다 재계산 비용이 큰지 측정해야 합니다. Agent infrastructure의 성능은 model benchmark만이 아니라 문맥을 얼마나 안정적으로 구성하고 재사용하는가에서 결정됩니다.
참고 자료
Plaid Labs는 Local LLM과 AI Agent 운영 인프라를 직접 구축하며, 반복 문맥과 회사 지식을 더 효율적으로 전달하는 방법을 실험하고 있습니다. 팀의 업무 규칙과 Skill을 Agent가 함께 사용하는 방법은 OPSCALE에서 확인할 수 있습니다.