좋은 아침이에요! 오늘은 캐시 인지 라우팅이에요. LLM 서버가 여러 대 있을 때, 요청을 아무 서버에나 돌려 보내지 않고 “이 대화의 앞부분(프리픽스)을 이미 계산해 KV 캐시로 들고 있는 서버”로 골라 보내는 방식이에요. 같은 프롬프트를 처음부터 다시 계산하지 않으니 첫 토큰이 나오는 시간(TTFT)과 비용이 확 줄어요.
시점부터 정리할게요. 새 기술은 아니에요. 프리픽스를 재사용하는 아이디어는 SGLang의 RadixAttention 논문(2023-12)과 vLLM의 자동 프리픽스 캐싱(2024)에서 자리 잡았고, Anthropic도 2024-08에 Claude 프롬프트 캐싱을 내놨어요. llm-d 프로젝트 자체도 2025-05에 Red Hat·Google·IBM 등이 처음 공개했고요. 이번에 화제가 된 건 2026-10-20(미국, 한국 시간 10-21) PyTorch Conference에서 llm-d 1.0이 정식 출시된 소식이에요. 같은 날 Google이 TorchTPU 오픈소스화와 TPU용 vLLM·SGLang 엔진도 함께 발표했어요.
왜 지금 뜨냐면, 트래픽 모양이 바뀌었기 때문이에요. 예전엔 “질문 하나, 답 하나”였는데, 지금은 에이전트가 길어지는 대화 전체를 매 스텝마다 다시 보내요. 일반 라운드로빈 로드밸런서는 이걸 매번 다른 서버로 보내서 같은 계산을 반복하게 만들죠. Google 발표 기준으로 코딩 에이전트 작업에서 프리픽스 인지 라우팅과 호스트 메모리 오프로드를 같이 쓰니 중간값 TTFT가 85% 넘게 줄었고, Snap은 캐시 적중률이 75~80%까지 올랐다고 해요.
Claude만 쓰는 개발자라면 라우터를 직접 운영할 일은 거의 없어요. 대신 같은 원리를 프롬프트 설계에 그대로 쓰면 돼요.
- 시스템 프롬프트, 도구 정의, 긴 문서처럼 안 바뀌는 건 맨 앞에, 사용자 입력처럼 매번 바뀌는 건 뒤에 두세요. 맨 위에 현재 시각이나 요청 ID를 넣으면 캐시가 매번 깨져요.
- 에이전트 루프에서는 Claude API의
cache_control로 캐시 지점을 찍고, 도구 목록 순서를 중간에 바꾸지 마세요. - 역할 나누기로 보면, 긴 공통 맥락은 “캐시에 맡기는 부분”, 매 턴 새로 판단해야 하는 짧은 질문만 “LLM이 새로 계산하는 부분”이 되게 짜는 거예요.
- 나중에 오픈 모델을 직접 서빙하게 되면(vLLM·SGLang), 그때 llm-d 같은 라우터를 기존 배포 앞에 붙이는 게 첫 단계예요.
연관 용어
- KV 캐시 오프로딩: GPU·TPU 메모리가 차면 캐시를 버리지 않고 호스트 RAM이나 SSD로 내려 보관하는 것.
- P/D 분리 (Prefill/Decode Disaggregation): 계산이 무거운 프리필과 메모리를 많이 쓰는 디코드를 서로 다른 서버 풀로 나누는 방식. DistServe 논문(2024-01) 무렵부터 알려졌어요.
- TTFT (Time To First Token): 요청 후 첫 토큰이 나오기까지 걸리는 시간. 캐시 효과를 볼 때 가장 먼저 보는 지표예요.
오늘도 프롬프트 앞부분은 단단하게, 뒷부분만 가볍게 바꿔 보세요. 좋은 하루 보내요!