프리픽스 캐싱은 홈 AI 서버에서 반복되는 프롬프트 작업을 어떻게 줄일까요?

프리픽스 캐싱은 동일한 선행 토큰 시퀀스에 대해 이미 계산된 키-값 상태를 재사용하여 반복되는 프롬프트 작업을 줄입니다.

홈 AI 서버에서 이 공유 프리픽스는 시스템 정책, 도구 스키마, 긴 문서, 가정용 지침 세트 또는 반복되는 채팅 기록일 수 있습니다. 첫 번째 요청에는 여전히 전체 프리필 비용이 발생하지만, 이후 일치하는 요청은 그중 상당 부분을 건너뛸 수 있습니다. 주요 이점은 프리필 경로 단축과 첫 토큰 생성 속도 향상이지, 생성이 무료가 되는 것은 아닙니다.

캐시가 없으면 반복 프롬프트가 동일한 프리필을 다시 계산합니다

응답을 생성하기 전에 자기회귀 모델은 입력 토큰을 처리하고 이후 디코딩에 사용되는 키-값 상태를 구축합니다. 따라서 긴 시스템 프롬프트, 도구 스키마, 문서 헤더 또는 공유 지침 블록은 모든 요청에서 동일한 프리필 작업을 소모할 수 있습니다.

Prompt Cache는 겹치는 프롬프트 구간의 어텐션 상태를 재사용하여 이러한 기회를 체계화합니다. 홈 AI 서버에서는 사용자가 새 문장 하나만 입력하더라도 반복되는 부분이 수천 개의 토큰에 이를 수 있습니다.

재사용하지 않으면 GPU 또는 CPU가 동일한 프리픽스에 대해 행렬 연산을 다시 수행하고 동일한 모델 가중치를 다시 읽습니다. 출력이 같을 수는 있지만 서버는 여전히 계산 설정 비용을 부담합니다.

프리픽스 캐시는 이미 처리된 프리픽스의 KV 상태를 저장합니다

첫 번째 호환 요청이 완료되면 런타임은 공유 프리픽스와 연결된 KV 상태를 유지할 수 있습니다. 이후 요청은 선행 토큰 시퀀스가 캐시된 블록과 일치하는지 확인하는 것으로 시작합니다.

vLLM의 자동 프리픽스 캐시는 블록의 토큰과 그 앞에 있는 프리픽스를 기준으로 블록을 식별합니다. 일치하는 요청은 중복 상태를 할당하고 계산하는 대신 동일한 물리적 캐시 블록을 가리킬 수 있습니다.

재사용되는 객체는 최종 답변도, 일반적인 의미 요약도 아닙니다. 정확히 호환되는 프리픽스에 대한 모델별 어텐션 상태입니다.

캐시 적중 시 공유 프리필을 건너뛰지만 새 접미사는 여전히 계산합니다

프리픽스가 일치하면 런타임은 저장된 어텐션 상태에서 시작하여 캐시 경계 이후의 새 토큰만 평가할 수 있습니다. 따라서 안정적인 시스템 프롬프트 하나를 사용하는 가정용 어시스턴트는 짧은 명령을 처리할 때마다 반복되던 작업을 피할 수 있습니다.

LMCache는 LLM 요청 간 KV 캐시 재사용을 모델 가중치를 변경하는 방식이 아니라 서빙 계층의 최적화로 설명합니다.

새 사용자 메시지에는 여전히 프리필이 필요하며, 생성되는 모든 출력 토큰에도 디코드 계산이 필요합니다. 프리픽스 캐싱은 주로 생성이 시작되기 전의 중복 작업을 줄입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

길고 안정적인 프리픽스일수록 첫 토큰 생성 시간 단축 효과가 큽니다

캐시는 그렇지 않으면 다시 계산해야 하는 부분에 비례하여 작업을 절약합니다. 2,000토큰 분량의 지침과 문서 프리픽스를 재사용하는 것은 10토큰짜리 인사말을 재사용하는 것보다 훨씬 큰 효과가 있습니다.

SGLang의 서빙 설계는 구조화된 KV 재사용을 통해 공유 프리픽스 워크로드를 가속합니다. 홈 서버에서 이에 해당하는 예로는 반복되는 에이전트 정책, 도구 목록, 가정용 지식 패킷 또는 문서 템플릿이 있습니다.

따라서 프리픽스 캐싱은 생성 중 초당 토큰 수만이 아니라 첫 토큰 생성 시간과 프리필 처리량을 기준으로 평가해야 합니다. 디코드 단계는 거의 변하지 않더라도 응답이 더 빨리 시작될 수 있습니다.

작은 프롬프트 변경도 블록 경계에서 재사용을 중단시킬 수 있습니다

캐시는 일반적으로 토큰과 모델 상태를 기준으로 정확하게 작동합니다. 도구 정의의 순서를 바꾸거나, 시작 부분에 변하는 타임스탬프를 삽입하거나, 어댑터를 전환하거나, 시스템 프롬프트를 수정하면 이후 블록을 재사용할 수 없게 될 수 있습니다.

Hugging Face의 서빙 지침은 프리필과 디코드 스케줄링을 구분합니다. 프롬프트 앞부분에 안정적인 콘텐츠를 배치하면 해당 프리필의 더 큰 비율을 재사용할 수 있습니다.

따라서 애플리케이션은 변동성이 큰 데이터를 기본적으로 안정적인 프리픽스의 앞부분에 삽입하지 말고, 동일한 정보를 뒤쪽에 배치할 수 있다면 그렇게 해야 합니다.

캐시 용량과 제거 정책이 홈 서버의 한계를 결정합니다

KV 블록은 메모리를 사용하므로 서버가 모든 프리픽스를 영구적으로 유지할 수는 없습니다. 여러 동시 대화, 긴 컨텍스트, 여러 모델이 동일한 메모리 풀을 놓고 경쟁하며 오래된 재사용 가능 상태를 제거할 수 있습니다.

ZimaSpace의 모델 캐싱과 웜 응답 지연 시간에 관한 설명은 더 넓은 캐시 계층 구조를 제공합니다. 프리픽스 캐싱은 그중 한 계층일 뿐이며, 모델 가중치를 메모리에 상주시키는 것과 혼동해서는 안 됩니다.

실제 가정 내 동시 사용 수준에서 캐시 적중률, 재사용된 토큰 수, 첫 토큰 생성 시간, 프리필 처리량, KV 메모리 사용량 및 제거율을 측정해야 합니다.

NVIDIA의 TensorRT-LLM 문서는 KV 캐시 재사용을 서빙 최적화로 설명하며, 재사용 가능한 상태는 일치하는 블록이 계속 사용 가능한 동안에만 도움이 된다는 동일한 핵심 한계를 제시합니다.