KV 캐시 라우팅: 중복된 LLM 프리필 작업 제거

KV 캐시 라우팅은 반복적인 프롬프트 접두사가 LLM 트래픽에서 계속 나타날 때 중요합니다. 올바른 요청이 올바른 복제본에 도달하면, 서비스 엔진은 동일한 프리필 토큰을 반복적으로 다시 계산하는 대신 캐시된 어텐션 상태를 재사용할 수 있습니다.

이는 인프라 세부사항처럼 들리지만, 곧 제품 문제로 이어집니다. 긴 시스템 프롬프트, RAG 컨텍스트, 몇 가지 샷 예제, 그리고 다중 턴 채팅 기록은 프리필 작업을 비용이 많이 들게 만들 수 있습니다. 모든 복제본이 동일한 접두사를 다시 계산할 때, 팀은 지연 시간, GPU 시간, 그리고 용량 계획에서 비용을 지불하게 됩니다.

ShareAI는 개발자들에게 150개 이상의 모델, 마켓플레이스 가시성, 라우팅, 그리고 장애 복구를 위한 하나의 API를 제공합니다. KV 캐시 라우팅은 모델 서비스 인프라 내부에서 한 층 아래에 위치합니다. ShareAI 독자들에게 유용한 결론은 간단합니다: 라우팅 결정은 모델 선택부터 반복된 프롬프트를 처리하는 GPU 복제본까지 AI 스택의 모든 층에서 중요합니다.

KV 캐시 라우팅이 중요한 이유

LLM 추론 중, 모델은 먼저 프리필 단계에서 입력 프롬프트를 처리합니다. 이는 키-값 캐시(KV 캐시)를 생성하며, 이후 생성된 토큰이 이미 처리된 컨텍스트를 참조할 수 있도록 합니다.

접두사 캐싱은 이후 요청이 동일한 프롬프트 시작 부분을 공유할 때 서비스 엔진이 해당 캐시를 재사용할 수 있도록 합니다. vLLM 자동 접두사 캐싱 문서 는 공유 접두사에 대해 KV 캐시를 재사용하여 새로운 요청이 공유된 부분에 대한 계산을 건너뛸 수 있도록 설명합니다. SGLang 접두사 캐싱 은 일반적인 토큰 시퀀스에 대해 KV 캐시를 공유하는 관련 아이디어를 사용합니다.

이는 많은 요청이 동일한 방식으로 시작되는 워크로드에서 특히 중요합니다: 큰 시스템 프롬프트를 사용하는 지원 에이전트, 반복적인 문서 조각을 사용하는 RAG 애플리케이션, 저장소 지침을 사용하는 코딩 에이전트, 또는 턴 간 대화 기록을 유지하는 채팅 제품.

라운드 로빈이 실패하는 경우

접두사 캐싱은 하나의 복제본에서 가장 쉽습니다. 동일한 프로세스가 반복된 접두사를 보고 메모리가 사용 가능하다면 해당 캐시를 재사용할 수 있습니다. 문제는 서비스가 수평적으로 확장될 때 나타납니다.

표준 라운드 로빈 로드 밸런서를 사용하면, 첫 번째 요청은 복제본 A에서 캐시를 예열할 수 있지만, 동일한 접두사를 가진 두 번째 요청은 복제본 B에 도달합니다. 복제본 B는 해당 캐시 상태를 가지고 있지 않으므로 동일한 프리필 작업을 다시 계산합니다. 세 번째 요청은 복제본 C로 이동하여 다시 캐시를 놓치게 됩니다.

복제본 수가 증가함에 따라, 단순한 로드 밸런싱은 관련 요청을 더 많은 머신에 분산시킬 수 있습니다. 모델 서비스 플릿은 균형 잡힌 것처럼 보일 수 있지만, 접두사 캐시 적중률은 떨어집니다. 이것이 KV 캐시 라우팅이 해결하려는 간극입니다.

세 가지 실용적인 라우팅 수준

1. 세션 친화성

세션 친화성은 동일한 사용자, 작업 공간, 테넌트 또는 대화에서 발생하는 트래픽을 동일한 복제본으로 라우팅합니다. 이는 다중 턴 채팅을 시작하기에 가장 간단한 방법으로, 후속 프롬프트가 종종 이전 컨텍스트를 공유하기 때문입니다.

단점은 사용자 식별이 항상 프롬프트 유사성과 동일하지 않다는 점입니다. 두 사용자가 동일한 긴 시스템 프롬프트를 공유하더라도 서로 다른 복제본으로 라우팅될 수 있습니다. 또한 복제본이 추가되거나 제거될 때 세션 친화성이 방해받을 수 있습니다.

2. 접두사 해시 라우팅

접두사 해시 라우팅은 프롬프트 자체를 라우팅 키로 사용합니다. 라우터는 프롬프트의 안정적인 시작 부분을 해시하고 일치하는 접두사를 동일한 복제본으로 보냅니다.

이는 반복적인 시스템 프롬프트, 몇 가지 예제, 또는 공유된 검색 컨텍스트가 사용자 식별보다 더 중요한 경우에 더 잘 작동합니다. 어려운 부분은 접두사 경계를 선택하는 것입니다. 해시에 타임스탬프, 요청 ID 또는 사용자별 필드가 포함되면 라우팅 키가 분열되고 캐시 재사용이 무너집니다.

3. 캐시 이벤트 인식 라우팅

가장 고급 접근 방식은 어떤 캐시 블록이 어떤 복제본에 상주하는지를 추적한 다음, 부하를 고려하면서도 캐시 중첩이 가장 좋은 복제본으로 각 요청을 라우팅합니다. llm-d 라우터 프로젝트 KV-캐시 지역성, 현재 부하, 우선순위를 고려하여 요청이 어디로 가야 할지를 선택하는 엔드포인트 선택기를 설명합니다.

이는 더 복잡하지만, 캐시 미스가 측정되고 비용이 많이 들며 빈번한 고처리량 플릿에 적합한 방향입니다.

건너뛰어야 할 때

KV 캐시 라우팅은 복잡성을 감수할 만큼 자동으로 가치가 있는 것은 아닙니다. 프롬프트가 짧고, 대부분 고유하거나, 반복 구조가 거의 없는 배치로 처리되는 경우에는 적합하지 않습니다.

문서 요약, 창의적 생성, 일회성 추출, 그리고 많은 비동기 배치 작업은 캐시 인식 라우팅을 정당화할 만큼 충분한 공유 접두사 중첩을 가지지 않을 수 있습니다. 이러한 경우에는 단순한 부하 분산이 더 깔끔할 수 있습니다.

실용적인 테스트는 측정입니다: 캐시 적중률, 첫 번째 토큰까지의 시간, 처리량, 대기열 깊이, GPU 메모리 압박, 완료된 작업당 비용. 캐시 인식 라우팅이 이러한 숫자를 변경하지 않는다면, 먼저 프롬프트 구조를 수정하십시오.

ShareAI와의 적합성

ShareAI는 AI 마켓플레이스 및 API이며, GPU 클러스터 내부의 모델 제공 로드 밸런서가 아닙니다. 개발자는 ShareAI를 사용하여 하나의 API를 통해 여러 모델에 액세스하고, 마켓플레이스 신호를 비교하며, 요청을 라우팅하고, 사용량을 관리하며, 경로가 저하될 때 장애 조치를 수행합니다.

이는 여전히 KV 캐시 라우팅과 관련이 있습니다. 자체 추론 스택을 운영하는 경우 더 나은 인프라 질문을 할 수 있도록 도와줍니다. 호스팅된 모델을 사용하는 경우, 유사한 모델 이름을 가진 두 경로가 실제 작업 부하에서 다르게 작동하는 이유를 평가하는 데 도움이 됩니다.

빌더에게는 가격 책정과도 연결됩니다. 긴 프롬프트, 반복된 RAG 컨텍스트, 또는 에이전트 루프가 있는 앱은 매우 불균형한 AI 사용을 생성할 수 있습니다. ShareAI Builder는 애플리케이션 소유자가 ShareAI를 통해 AI 추론 트래픽을 라우팅하고, 마진 또는 추가 요금을 설정하며, 고객이 라우팅된 사용량에 대해 ShareAI에 비용을 지불하도록 하고, 생성된 사용량에 따라 월별 지급을 받을 수 있도록 합니다. 애플리케이션 자체는 ShareAI 외부에서 구축됩니다.

모델 선택 및 경로 평가를 위해 시작하십시오 ShareAI 모델 마켓플레이스에서. 구현 기본 사항을 위해 사용하십시오 ShareAI API 참조.

KV 캐시 라우팅 체크리스트

• 안정적인 프롬프트 콘텐츠를 먼저 배치하십시오: 시스템 프롬프트, 도구 규칙, 예제, 반복된 컨텍스트.
• 동적 필드를 나중에 이동하십시오: 타임스탬프, 요청 ID, 사용자별 사실, 일회성 지침.
• 라우팅 변경 전후의 캐시 적중률을 측정하십시오.
• 첫 번째 토큰까지의 시간, 처리량, 대기열 깊이, VRAM 압박을 함께 관찰하십시오.
• 캐시 이벤트 인식 라우팅을 구축하기 전에 프리픽스 해시 라우팅으로 시작하십시오.
• 하나의 글로벌 정책을 강제하는 대신 작업 부하별로 라우팅 규칙을 분리하십시오.
• 비용과 지연 시간을 추론 클러스터 내부뿐만 아니라 애플리케이션 수준에서도 가시적으로 유지하십시오.

자주 묻는 질문

KV 캐시 라우팅이란 무엇인가요?

KV 캐시 라우팅은 반복되는 프롬프트 접두사를 가진 요청을 이미 해당 KV 캐시를 보유하고 있을 가능성이 높은 복제본으로 보내는 라우팅 전략입니다. 목표는 중복된 프리필 계산을 줄이는 것입니다.

KV 캐시 라우팅은 접두사 캐싱과 어떻게 다른가요?

접두사 캐싱은 공유된 프롬프트 접두사에 대해 캐시된 상태를 재사용할 수 있는 모델 서비스 엔진의 기능입니다. KV 캐시 라우팅은 캐시된 상태가 이미 존재하는 곳에 일치하는 요청을 배치하도록 돕는 트래픽 배치 전략입니다.

라운드 로빈 라우팅이 접두사 캐싱에 왜 해가 되나요?

라운드 로빈 라우팅은 어떤 복제본이 어떤 캐시된 접두사를 가지고 있는지 알지 못한 채 요청을 복제본에 분산시킵니다. 반복되는 프롬프트가 다른 복제본에 도달하기 때문에 캐시를 놓칠 수 있습니다.

어떤 작업 부하가 KV 캐시 라우팅에서 가장 큰 혜택을 받나요?

다중 턴 채팅, RAG, 코딩 에이전트, 지원 에이전트, 몇 샷 프롬프트, 그리고 긴 공유 시스템 프롬프트를 가진 앱이 가장 적합합니다. 이들은 상당한 프롬프트 접두사를 재사용하기 때문입니다.

팀이 KV 캐시 라우팅을 생략해야 할 때는 언제인가요?

프롬프트가 짧고, 대부분 고유하거나, 반복 구조가 거의 없는 배치 지향적인 경우 생략하세요. 이러한 경우 라우팅 복잡성이 큰 가치를 추가하지 않을 수 있습니다.

vLLM과 SGLang이 접두사 캐싱을 지원하나요?

네. vLLM은 자동 접두사 캐싱을 문서화하고, SGLang은 일반적인 토큰 시퀀스에 걸친 공유 KV 캐시에 대한 접두사 캐싱을 문서화합니다. 여러 복제본이 관련된 경우 서비스 엔진은 여전히 라우팅 지원이 필요합니다.

KV 캐시 라우팅이 의미론적 캐싱과 동일한가요?

아니요. KV 캐시 라우팅은 추론 서비스 내에서 정확하거나 거의 구조적인 접두사 재사용과 함께 작동합니다. 의미론적 캐싱은 보통 임베딩이나 유사성 임계값을 사용하여 의미를 기반으로 응답이나 중간 결과를 저장하고 재사용합니다.

ShareAI가 KV 캐시를 인식하는 로드 밸런서를 대체하나요?

아니요. ShareAI는 모델 액세스, 라우팅, 장애 조치, 사용량 및 청구를 위한 AI 마켓플레이스 및 API 계층입니다. KV-캐시 인식 라우팅은 추론 복제본을 운영하는 팀을 위한 하위 수준 모델 제공 인프라입니다.

빌더들은 KV 캐시 라우팅에 대해 어떻게 생각해야 하나요?

빌더들은 캐시 동작을 AI 중심 앱 내의 하나의 비용 요인으로 간주해야 합니다. 애플리케이션 사용량이 고르지 않은 경우, ShareAI는 앱이 ShareAI 외부에서 구축되고 소유된 상태로 AI 트래픽을 라우팅하고 수익화하는 데 도움을 줄 수 있습니다.

라우팅을 변경하기 전에 팀은 무엇을 측정해야 하나요?

캐시 적중률, 첫 번째 토큰까지의 시간, 처리량, 대기열 깊이, VRAM 압력, 작업당 비용, 출력 품질을 측정하세요. 라우팅 변경은 대시보드뿐만 아니라 작업 부하를 개선해야 합니다.

KV 캐시 라우팅이 AI API 비용을 줄일 수 있나요?

팀이 자체적으로 모델을 제공하는 경우, 중복된 프리필 작업이 줄어들어 GPU 효율성을 향상시킬 수 있으므로 인프라 비용을 줄일 수 있습니다. 호스팅된 API의 경우, 제공자가 이러한 절감을 가격이나 성능에 반영하는지에 따라 효과가 달라집니다.