KV cache 원리부터 메모리 관리까지: 프롬프트 캐싱 제대로 쓰기

캐시된 입력의 비용이 낮은 이유는 모델이 이미 수행한 연산을 재사용할 수 있기 때문입니다. KV 캐시(KV cache)는 어텐션 데이터인 키와 값, 2가지 배열을 보관합니다. 덕분에 대규모 언어 모델은 앞선 모든 토큰의 상태를 다시 계산하지 않고도 대화를 이어 갈 수 있습니다. 반복되는 컨텍스트의 처리 비용은 줄어들지만, 대화가 길어질수록 차지하는 메모리는 늘고 새 토큰이 어텐션으로 참조해야 할 컨텍스트도 많아집니다.

재사용할 만한 접두부를 유지하고, 대화 이력을 얼마나 남길지 관리해야 합니다. 둘은 별개의 작업입니다. 접두부는 요청의 맨 앞에서 바뀌지 않는 부분을 뜻합니다. 이 부분을 캐싱하면 입력 처리량을 줄일 수 있지만, 에이전트의 나머지 작업까지 사라지는 것은 아닙니다.

아래의 제공사별 요금과 캐시 규칙은 2026년 10월 15일 각 업체의 공식 요금 페이지와 문서를 기준으로 확인했습니다. 메모리 계산은 문서에 명시된 텐서 형태에서 도출한 값이며, 특정 GPU에서 측정한 결과가 아닙니다.

KV cache란? 반복되는 프롬프트에서 재사용하는 연산

KV 캐시는 저장해 둔 어텐션 상태입니다. 어텐션은 트랜스포머가 앞선 정보 중 현재 예측에 필요한 정보를 가져오는 메커니즘입니다. 텍스트나 그 밖의 모델 입력을 이루는 단위인 토큰은 각 어텐션 레이어 안에서 수치 표현으로 변환됩니다. 캐시는 해당 레이어의 키와 값을 보관했다가 나중에 다시 사용합니다. 레이어별 저장 방식은 Hugging Face의 캐시 설명에서 확인할 수 있습니다.

어텐션의 세 가지 역할은 자료실에 빗대면 이해하기 쉽습니다.

• **쿼리(query)**는 현재 위치에서 찾으려는 정보를 나타냅니다.
• **키(key)**는 앞선 위치의 정보를 검색 조건과 대조할 수 있게 합니다.
• **값(value)**은 대조 결과에 따라 가져올 정보를 담습니다.

보고서를 쓰기 전에 조사 노트를 정리하고 색인을 붙여 둔다고 생각해 보겠습니다. 새 문장을 쓸 때마다 준비된 노트를 참고할 수 있습니다. 문장을 쓸 때마다 색인과 노트를 처음부터 다시 만들면 같은 일을 반복하게 되고, 그대로 보관하면 공간을 차지합니다. 다만 실제 구현은 이 비유와 다릅니다. 모델이 저장하는 것은 사람이 읽을 수 있는 색인 카드나 문서 요약이 아니라 수치 배열입니다.

현재 쿼리를 앞선 키들과 비교하면 어텐션 가중치가 나오고, 이 가중치로 값들을 결합합니다. 인과적 트랜스포머에서는 앞선 위치가 뒤에 올 정보를 볼 수 없습니다. 따라서 뒤에 토큰이 추가되어도 앞선 위치에서 이미 계산한 상태를 바꿀 필요가 없습니다. 이 성질 때문에 재사용이 가능합니다. PagedAttention 원 논문은 이러한 어텐션 계산과 생성 과정을 설명합니다.

일반적인 캐시가 과거의 모든 쿼리 대신 K와 V를 저장하는 이유도 여기에 있습니다. 다음 예측에는 현재 쿼리와 지금까지 쌓인 키·값이 필요합니다. 과거의 쿼리는 이미 역할을 마쳤습니다.

고객 지원 에이전트라면 보관된 상태는 지침, 툴 정의, 정책 문서, 지금까지의 대화를 나타낼 수 있습니다. 이 상태는 특정 모델과 앞선 컨텍스트에 종속됩니다. 모델이 학습한 가중치도, 고객 정보를 영구히 기억하는 데이터베이스도 아닙니다.

접두부 캐싱과 답변 캐싱도 다릅니다. 모델은 여전히 새 응답을 생성합니다. 같은 문서에 대해 다른 질문을 하면, 이전 답변을 반환하는 대신 문서를 미리 처리해 둔 상태를 재사용할 수 있습니다.

KV cache의 동작 원리: 프리필과 디코드의 차이

프리필(prefill)은 입력을 준비하고, 디코드(decode)는 그 입력에서 이어지는 출력을 생성합니다. 두 단계를 구분하면 캐시 적중 후 응답이 더 빨리 시작되어도 끝날 때까지는 여전히 시간이 걸리는 이유를 이해할 수 있습니다.

일반적인 자기회귀 트랜스포머의 처리 흐름을 글로 나타내면 다음과 같습니다.

프리필: 프롬프트 토큰 → 프롬프트 처리 → 레이어별 키와 값 보관 → 첫 출력 토큰 예측.

디코드: 가장 최근에 생성된 토큰 + 보관된 키와 값 → 해당 토큰을 처리하고 컨텍스트에 어텐션 적용 → 다음 토큰 예측. 새로 계산한 키와 값은 캐시에 추가합니다.

디코드 반복: 생성이 끝날 때까지 계속 커지는 캐시를 재사용합니다.

프리필은 이미 주어진 프롬프트의 여러 위치를 함께 처리할 수 있습니다. 반면 디코드는 아직 정해지지 않은 다음 토큰을 차례로 생성하며 진행합니다. PagedAttention 논문의 생성 및 실행 흐름에서도 이 차이를 설명합니다.

KV 캐시는 접두부 전체를 다시 계산할 때보다 다음 토큰을 저렴하게 생성하도록 해 줍니다. 그렇다고 다음 토큰의 연산량이 컨텍스트 길이와 무관해지는 것은 아닙니다. 일반적인 전체 어텐션에서는 여전히 새 쿼리가 보관된 키·값과 상호작용합니다. 남겨 둔 컨텍스트가 많을수록 사용해야 할 어텐션 데이터도 많아집니다. Hugging Face 문서는 각 단계에 남아 있는 이 어텐션 연산을 설명합니다.

여기서 재사용을 두 종류로 나눠 봐야 합니다. 하나의 응답 안에서 KV 캐싱은 생성 중 같은 계산이 반복되는 것을 막습니다. 요청 간에 적용되는 **접두부 캐싱(prefix caching)**은 호스팅 API에서 프롬프트 캐싱이라고도 부릅니다. 재사용 조건을 충족하는 상태를 보존해 후속 호출에서 프리필 연산 일부를 건너뛰는 방식입니다. 대화 식별자가 있다는 사실만으로 그 상태가 재사용 가능한 것은 아닙니다.

에이전트가 정책 문서를 읽고 툴을 호출한 뒤, 그 결과를 어떻게 처리할지 모델에 판단을 요청한다고 가정해 보겠습니다. 다음 요청에서는 기존 지침과 문서를 공통 접두부로 유지하고 뒤에 툴 결과를 덧붙일 수 있습니다. 캐시가 조건을 충족하고 사용 가능한 상태라면 제공사는 이 공통 앞부분을 다시 처리할 필요가 없습니다.

API를 활용하는 개발자라면 첫 토큰이 나오기까지의 지연과 응답 생성에 걸리는 시간을 모두 살펴봐야 합니다. 첫 토큰 지연이 줄었다고 디코드까지 빨라졌다고 볼 수는 없습니다. vLLM의 Automatic Prefix Caching 문서는 프리필 연산 절감과 디코드 시간을 명확히 구분합니다.

재사용한 연산은 어떻게 캐시 입력 요금으로 이어질까?

할인은 제공사의 과금 규칙에 따라 재사용된 입력 연산에 적용됩니다. 모든 서비스에 통하는 할인율은 없으며, 캐시에 적중한 요청의 모든 토큰이 할인되는 것도 아닙니다.

일반 입력, 캐시 쓰기, 캐시 읽기를 구분하는 API라면 입력 요금은 다음과 같이 나타낼 수 있습니다.

입력 요금 = (U × p_input + W × p_write + R × p_read) / 1,000,000

여기서 U는 일반 입력 토큰 수, W는 캐시 쓰기로 과금되는 토큰 수, R은 캐시 읽기로 과금되는 토큰 수입니다. 각 p는 해당 항목의 백만 토큰당 요금입니다. 세 항목은 서로 겹치면 안 됩니다. 캐시 쓰기로 계산한 토큰에 일반 입력 요금을 다시 더하지 않아야 합니다. 이 식은 OpenAI와 Anthropic의 요금 항목을 같은 단위로 계산한 것입니다.

여기에 출력 요금, 해당되는 툴 이용 요금, 별도로 청구되는 캐시 저장 요금을 더합니다. Google의 명시적 캐시는 보관 시간까지 계산해야 하므로 쓰기·읽기만으로는 비용을 설명할 수 없습니다. 아래는 과금 방식의 사례이며, 모델의 우열을 비교하는 순위가 아닙니다.

Anthropic: 재사용할 접두부의 끝을 지정합니다

Anthropic은 cache_control로 프롬프트 캐싱을 설정합니다. 요청 최상위에 지정하면 캐시 분기점(breakpoint)을 자동 관리하고, 개별 콘텐츠 블록에 직접 지정할 수도 있습니다. 분기점은 보존할 접두부의 끝을 나타냅니다. 두 방식 모두 요금 문서에 설명되어 있습니다.

요금 예시 — 표준 Claude API: Claude Sonnet 5.5의 백만 토큰당 요금은 입력 $2, 캐시 읽기 $0.10, 5분 보관 캐시 쓰기 $2.50, 1시간 보관 캐시 쓰기 $4입니다. Anthropic 요금.

이 모델에서 캐싱 가능한 접두부의 최소 길이는 512토큰입니다. 캐시 경계까지의 내용이 정확히 일치해야 합니다. 읽기가 발생하면 추가 쓰기 요금 없이 유효 기간이 갱신됩니다. 다만 요청이 시작될 때부터 시간이 흐르므로 응답 생성 시간도 이 기간에 포함됩니다. 다른 Claude 모델은 최소 길이와 읽기 할인율이 다릅니다. Anthropic 프롬프트 캐싱 규칙.

문서 에이전트가 사용자의 긴 응답 대기 후 다시 실행된다면, 보관 기간에 따라 다음 호출이 기존 접두부를 읽을 수도, 다시 쓸 수도 있습니다. 사용량 정보의 cache_creation_input_tokens와 cache_read_input_tokens를 확인해야 합니다. 같은 문서를 다시 보냈다는 사실만으로 할인된 읽기가 발생했다고 판단할 수는 없습니다. 사용량 필드.

OpenAI: 모델별 캐시 쓰기 규칙을 확인합니다

OpenAI는 지원 모델에서 프롬프트 캐싱을 기본으로 활성화합니다. 최신 모델은 암시적·명시적 캐시 분기점을 모두 지원합니다. 구체적인 동작은 모델마다 다릅니다. OpenAI 프롬프트 캐싱.

요금 예시 — Standard 짧은 컨텍스트 구간: GPT-6.1 Sol의 백만 토큰당 요금은 입력 $2.00, 캐시된 입력 $0.10, 캐시 쓰기 $2.50입니다. 입력 272K토큰을 넘으면 요청 전체에 적용되는 입력 및 캐시 단가가 두 배가 됩니다. OpenAI 요금, 모델별 기준.

GPT-5.6 이상에서는 최소 1,024개의 가시적 입력 토큰이 필요하며, 문서에 명시된 캐시 유효 기간은 마지막 쓰기 또는 재사용 후 최소 30분입니다. 캐시 쓰기 요금은 해당 토큰의 일반 입력 요금을 대체합니다. 전체 입력 요금에 같은 금액을 한 번 더 더하는 방식이 아닙니다. 이전 모델에는 다른 쓰기 및 보관 규칙이 적용됩니다. 현재 캐싱 규칙.

Responses API에서는 usage.input_tokens_details.cached_tokens와 cache_write_tokens를 확인합니다. 세션을 유지한다고 캐시 적중이 보장되지는 않습니다. 요청 구성과 보고된 사용량을 조사해야 한다면 이 사이트의 GPT-6 프롬프트 캐싱 진단 가이드를 참고할 수 있습니다.

Google Gemini: 자동 재사용과 명시적 저장을 구분합니다

Google Gemini는 자동으로 동작하는 암시적 캐싱을 제공하며, 캐시 적중 시 절감분이 요금에 반영됩니다. Gemini 3.8 Flash의 경우 문서에 명시된 최소 길이는 입력 4,096토큰입니다. 공통 내용을 앞부분에 배치하고 요청 간격을 짧게 유지하면 재사용 가능성이 높아집니다. Google 컨텍스트 캐싱 가이드.

요금 예시 — 유료 Standard Gemini Developer API: Gemini 3.8 Flash의 백만 토큰당 요금은 입력 $0.75, 캐시된 입력 $0.075이며, 명시적 캐시 저장 요금은 백만 토큰당 시간당 $0.50입니다. 이 요금은 2026년 12월 31일까지 적용됩니다. Google 요금.

명시적 캐싱은 만료 시간을 설정한, 이름이 있는 캐시 콘텐츠 리소스를 사용합니다. 이후 generateContent 요청에서 이 리소스를 참조합니다. 저장 요금이 있기 때문에 사용하지 않는 문서를 보관하는 동안에도 비용이 발생할 수 있습니다. Google 캐싱 API 레퍼런스.

어떤 API를 선택하는지도 중요합니다. Interactions API는 암시적 캐싱만 지원합니다. Google의 현재 가이드에 따르면 Gemini 4 Argon 이후 모델에서는 명시적 캐싱을 지원하지 않습니다. 지원 대상인 Gemini 3 및 2.5 모델은 명시적 캐시에 generateContent를 사용합니다. Interactions API에서는 가이드에 따라 usage.total_cached_tokens를 확인합니다. Google의 API별 규칙.

API 운영 관점에서 핵심은 자동 캐시 적중을 관찰하는 것인지, 비용을 지불하고 리소스를 의도적으로 보관하는 것인지 구분하는 데 있습니다. 여러 제공사를 함께 지원하는 캐시 추상화 계층을 만들 때 이 둘의 수명 주기가 같다고 가정해서는 안 됩니다.

KV 캐시 메모리는 보관한 컨텍스트에 비례해 늘어납니다

일반적인 전체 어텐션 레이어에서는 원시 KV 메모리 사용량이 보관된 토큰 수에 비례해 증가합니다. 대화가 길어지면 앞부분에 요금 할인이 적용되더라도 메모리에 유지해야 할 작업 데이터는 계속 늘어납니다.

시퀀스 길이가 같고 모든 어텐션 레이어의 구조가 동일하다면 다음과 같이 계산할 수 있습니다.

KV bytes ≈ 2 × B × T × L × H_kv × D × S

• 2: 키 배열 하나와 값 배열 하나입니다.
• B: 동시에 처리하는 시퀀스 수입니다. 각 시퀀스가 캐시 데이터를 공유하지 않는다고 가정합니다.
• T: 시퀀스마다 처리한 뒤 보관하고 있는 토큰 수입니다. 프롬프트 토큰과 생성된 토큰을 모두 포함합니다.
• L: 이 형태의 캐시를 유지하는 어텐션 레이어 수입니다.
• H_kv: 레이어당 키·값 헤드 수입니다.
• D: 헤드당 스칼라 값의 개수입니다.
• S: 스칼라 값 하나를 저장하는 데 쓰는 바이트 수입니다.

이 식은 문서에 명시된 레이어별 캐시 형태와 vLLM의 키·값 헤드 구조를 바탕으로 원소 수를 계산한 것입니다. 장치 전체의 메모리 사용량이 아니라 원시 텐서의 크기를 추정합니다.

헤드 수를 정확히 넣는 것이 중요합니다. 여러 쿼리 헤드가 키·값 헤드를 공유하는 그룹 쿼리 어텐션에서는 이 식에 KV 헤드 수를 사용해야 합니다. 그보다 많은 쿼리 헤드 수를 대입하면 캐시 크기를 과대 추정하게 됩니다.

모델과 저장 정밀도를 그대로 두고 T를 두 배로 늘리면 원시 밀집 캐시도 두 배가 됩니다. T와 독립적으로 동시 처리하는 시퀀스 수를 모두 두 배로 늘리면 네 배가 됩니다. 이는 대수적으로 도출되는 결과이며, 특정 GPU의 용량이나 실측 처리량에 대한 주장이 아닙니다.

고객 지원 서비스를 자체 호스팅한다면 이 식에서 유용한 용량 계획 질문을 얻을 수 있습니다. 모든 고객을 합쳐 동시에 활성 상태로 보관하는 토큰이 얼마나 되는가 하는 것입니다. 모델을 메모리에 올리는 것은 시작에 불과합니다. 서버에는 고객별로 계속 변하는 추론 상태를 담을 공간도 필요합니다.

Hugging Face의 캐시 전략 문서는 윈도 기반 레이어의 한계를 설명하고, vLLM의 접두부 캐시 설계 문서는 재사용 가능한 물리 블록을 다룹니다. 상태 구조가 이런 일반적인 밀집 키·값 배열과 다르다면 해당 아키텍처의 문서에 명시된 구조를 기준으로 계산해야 합니다.

호스팅 API 사용자에게는 같은 증가가 다른 형태로 드러납니다. 캐시 적중률이 일정하더라도 매 턴 읽기로 과금되는 토큰 수가 늘 수 있습니다. 단가가 낮아도 입력이 계속 늘면 요금도 커집니다. 출력 생성 과정에서도 컨텍스트에 대한 어텐션은 계속 수행되며, 요금 구간을 나누는 기준은 전체 입력 길이에 따라 달라질 수 있습니다.

vLLM에서 KV 캐시를 최적화하는 방법

오픈소스 LLM 서빙 엔진 vLLM은 자체 호스팅 환경에서 메모리 할당, 재사용, 데이터 표현을 조정할 수 있게 합니다. 배포 설정을 바꾸기 전에 어떤 조정이 현재 병목을 해결하는지부터 판단해야 합니다.

PagedAttention: 대화가 길어지는 만큼 블록을 할당합니다

PagedAttention은 여러 물리 블록에 나뉘어 저장된 KV 데이터를 대상으로 어텐션을 수행할 수 있게 합니다. 하나의 논리적 시퀀스를 위해 앞으로 필요할 수 있는 최대 크기의 연속 메모리를 한꺼번에 예약할 필요가 없습니다. 원래 설계는 메모리 할당 낭비를 줄이고 공유를 가능하게 합니다. PagedAttention 논문.

자료실 비유를 그대로 적용할 수 있습니다. 조사 자료가 늘어날 때마다 비어 있는 선반 구역을 배정하고, 그 순서를 나타내는 지도를 유지하면 됩니다. 자료가 얼마나 쌓일지 알기도 전에 거대한 서가 한 줄을 통째로 비워 둘 필요는 없습니다.

페이징 자체가 토큰마다 저장하는 정보량을 줄이지는 않습니다. 그 정보를 가용 메모리에 더 효율적으로 배치하는 방식입니다. 또한 vLLM은 Paged Attention 커널 페이지를 과거 구현에 관한 문서로 표시하고 있습니다. 개념은 참고하되, 예전 커널 설명을 현재 구현으로 받아들이지는 않아야 합니다.

접두부 캐싱: 이전 요청과 겹치는 연산을 건너뜁니다

Automatic Prefix Caching은 일치하는 접두부의 KV 상태를 재사용합니다. vLLM 문서에서는 enable_prefix_caching=True 설정을 안내합니다. 같은 문서에 대한 질문이나 에이전트의 여러 턴에서 요청의 앞부분이 반복된다면 이 기능이 해당됩니다. Automatic Prefix Caching.

캐시의 동일성을 판단할 때는 개별 블록의 텍스트뿐 아니라 그 앞의 접두부도 포함합니다. 따라서 같은 문단이라도 앞선 지침이 다르면 캐시를 서로 바꿔 쓸 수 있다고 가정해서는 안 됩니다. vLLM의 해시 기반 캐시 설계는 이 의존 관계를 명시합니다.

효과의 한계는 워크로드가 결정합니다. 서로 관련 없는 프롬프트는 공유할 연산이 적고, 긴 답변을 생성할 때는 여전히 디코드가 대부분의 시간을 차지할 수 있습니다. 엔진 자체를 선택하는 단계라면 vLLM과 SGLang 비교에서 더 넓은 관점의 선택 기준을 살펴볼 수 있습니다.

KV 캐시 양자화: 저장하는 값 하나당 바이트 수를 줄입니다

KV 캐시 양자화는 캐시에 보관하는 수치의 정밀도를 낮추는 방법입니다. vLLM은 kv_cache_dtype="fp8"로 FP8 캐시 저장을 지원하며, 품질을 위해 데이터셋 기반 스케일 보정을 권장합니다. 사용할 수 있는 방식은 어텐션 백엔드에 따라 달라집니다. vLLM 캐시 양자화 문서.

16비트 값을 8비트로 바꾸면 공식에서 계산하는 원시 스칼라 데이터의 크기는 절반이 됩니다. 이는 스케일 메타데이터와 메모리 할당 오버헤드를 더하기 전의 값입니다. 서버 전체 메모리가 절반으로 줄어든다는 뜻도, 실측 속도 향상을 입증하는 결과도 아닙니다. 모델 가중치를 양자화하는 것과 어텐션 상태를 양자화하는 것은 별개의 선택입니다.

실서비스 에이전트에서는 중요한 장기 작업으로 평가해야 합니다. 제약 조건을 유지하고, 툴을 선택하고, 이전 메시지에서 세부 정보를 찾아내는 능력을 확인합니다. 상태를 줄이는 것은 작업을 계속 성공적으로 수행할 수 있을 때만 의미가 있습니다. 서버가 시작된다는 사실만으로 품질이 그대로라고 판단해서는 안 됩니다.

KV 캐시 압축: 정밀도 축소와 내용 축소를 구분합니다

값의 정밀도를 낮추는 것과 보관하는 위치의 수를 줄이는 것은 서로 다른 절충입니다. 양자화는 값의 표현 방식을 바꿉니다. 범위가 제한된 어텐션 윈도는 해당 레이어가 참조할 수 있는 위치를 바꿉니다. 두 방식에서 발생할 수 있는 문제를 단순히 ‘압축’이라는 하나의 효과로 묶어서는 안 됩니다. Hugging Face 캐시 전략.

실무에서 먼저 할 수 있는 일은 관련 없는 툴 출력을 더 이상 보내지 않는 것입니다. 이후 컨텍스트가 커지는 원인을 줄일 수 있습니다. 다만 이는 애플리케이션 차원의 판단입니다. 보관할 상태를 최적화하기 전에 에이전트에 필요한 근거가 유지되는지 확인해야 합니다.

KV 캐시 오프로딩: 데이터 전송을 감수하고 더 많은 상태를 보관합니다

오프로딩은 재사용 가능한 상태를 다른 메모리 계층으로 옮기는 방식입니다. vLLM의 OffloadingConnector는 완료된 블록을 CPU 호스트 메모리와 지원되는 보조 계층에 보관하고, 캐시 적중 시 필요한 블록을 GPU로 다시 가져올 수 있습니다. vLLM 오프로딩 가이드.

유용한 접두부를 GPU에 계속 둘 수 있는 시간보다 더 오래 재사용해야 할 때 도움이 될 수 있습니다. 대신 데이터 이동이 발생합니다. 실제 워크로드에서 재계산을 피하는 이점과 전송에 드는 작업을 비교해야 합니다. 모든 환경에서 통하는 지연 시간 개선 효과를 단정할 수는 없습니다.

활성 KV 캐시로 메모리가 부족해지면 vLLM은 요청을 선점해 실행을 중단한 뒤 나중에 다시 계산할 수 있습니다. 최적화 가이드는 선점이 잦아질 때 동시 처리 요청 수와 메모리 할당을 점검하도록 권장합니다. 운영자에게는 GPU 메모리가 가득 찼다는 사실보다 선점 횟수가 늘고 있다는 신호가 조치 방향을 정하는 데 더 유용합니다.

캐시 적중률만으로는 알 수 없는 것

적중률이 높다고 에이전트가 효율적인 것은 아닙니다. 적중률은 재사용 정도를 나타냅니다. 실제 서비스에 필요한 것은 허용 가능한 시간과 예산 안에서 작업을 성공적으로 끝내는 일입니다.

대화는 이전 입력의 거의 전부를 재사용하면서도 매 턴 길어질 수 있습니다. 할인된 요금으로 불필요한 자료를 거듭 읽을 수도 있습니다. 접두부 재사용으로 직접 줄일 수 없는 출력 생성에 대부분의 시간을 쓸 수도 있습니다.

캐시 지표를 지키기 위해 불필요하게 커진 대화 기록을 그대로 유지하지 않아야 합니다. 과거 내용이 더 이상 도움이 되지 않으면 기록을 압축하거나 새로 시작합니다. 접두부가 바뀌면 다시 처리해야 할 수 있다는 점도 받아들여야 합니다. 판단 기준은 작업 품질과 전체 연산량입니다. 이 사이트의 컨텍스트 엔지니어링 가이드는 작업 컨텍스트에 무엇을 포함할지 결정하는 방법을 설명합니다.

API를 사용하는 개발자라면 요청들이 상당한 분량의 내용을 반복해서 공유할 때 프롬프트 배치부터 최적화하는 것이 좋습니다. 같은 접두부를 거의 반복하지 않는 워크로드라면 복잡한 캐시 관리는 뒤로 미뤄도 됩니다. 자체 호스팅 운영자는 모델에 연산 자원이 더 필요하다고 결론 내리기 전에 메모리 할당 압박과 선점을 조사해야 합니다. 짧고 서로 관련 없는 일회성 요청에서는 요청 간 재사용으로 얻을 것이 적습니다.

LLM KV 캐시에서 자주 묻는 질문

ChatGPT도 KV 캐시를 사용하나요?

OpenAI는 API의 KV 기반 프롬프트 캐싱을 문서로 설명합니다. 이는 공개 API 기능의 동작 방식을 알려 주는 것이며, ChatGPT 내부 서빙 환경의 모든 세부 사항을 밝히는 것은 아닙니다. 개발할 때는 선택한 API 모델의 공개된 캐시 규칙과 사용량 필드를 기준으로 삼아야 합니다. OpenAI 문서.

KV 캐시를 GPU 메모리로 오프로딩해야 하나요?

GPU 추론에서는 활성 어텐션 상태를 GPU에서 사용합니다. vLLM의 오프로딩 기능은 재사용 가능한 블록을 호스트 메모리나 지원되는 다른 계층으로 옮겼다가 필요할 때 다시 가져옵니다. 더 많은 접두부를 보관하는 이점이 전송 부담보다 클 때 검토할 만합니다. vLLM 오프로딩.

KV 캐시가 가득 차면 어떻게 되나요?

vLLM은 사용하지 않는 캐시 블록을 제거할 수 있습니다. 활성 요청으로 메모리가 부족하면 작업을 선점해 중단하고 나중에 다시 계산할 수 있으며, 이는 지연 시간에 영향을 줍니다. 모델의 컨텍스트 윈도 한도를 초과하는 것과는 별개의 문제입니다. 캐시 관리, 선점.

KV 캐시 크기는 어떻게 줄일 수 있나요?

보관하는 컨텍스트나 동시 처리 시퀀스 수를 줄이고, 조건을 충족하는 공통 접두부를 재사용하거나, 정밀도가 낮은 캐시 저장 방식을 평가할 수 있습니다. 오프로딩은 상태가 놓이는 위치를 바꾸는 방법이므로 전체 크기까지 줄어드는 것은 아닙니다. 메모리뿐 아니라 작업 품질과 관찰된 지연 시간도 함께 보고 효과를 판단해야 합니다. 캐시 전략.

에이전트의 캐시 적중률을 높이는 세 가지 습관

작업을 진행하는 동안 앞부분을 고정하고, 바뀌는 내용은 뒤에만 덧붙입니다. 정확히 일치하는 접두부를 재사용하려면 요청 구성이 일정해야 합니다. 물론 제공사의 최소 길이, 보관 기간, 가용성 조건도 충족해야 합니다.

1. 1

   고정된 시스템 프롬프트를 맨 앞에 둡니다

   API가 정한 메시지 구조 안에서 지속적으로 적용할 지침, 툴 정의, 재사용할 참고 자료를 변동되는 작업 데이터보다 앞에 둡니다. 문구, 툴 순서, 직렬화 방식도 일정하게 유지합니다. Anthropic의 계층 순서는 툴, 시스템, 메시지입니다. 툴 구성이 바뀌면 뒤따르는 내용의 재사용도 무효화될 수 있습니다. Anthropic 캐시 구조.

2. 2

   이력을 다시 쓰지 말고 뒤에 덧붙입니다

   이전 메시지를 유지한 채 새 사용자 턴, 어시스턴트의 툴 호출, 툴 결과를 추가합니다. 호출할 때마다 요약이나 서식을 바꿔 과거 턴을 다시 구성하는 방식은 피합니다. 컨텍스트 압축이 필요해지면 이를 명확한 전환 지점으로 삼고, 이후에는 새로운 접두부를 고정해 유지합니다. 각 블록이 앞선 토큰에 의존한다는 특성을 따르는 방법입니다. vLLM 접두부 동일성 기준.

3. 3

   타임스탬프는 앞부분에서 뺍니다

   현재 시각, 요청 식별자 등 계속 바뀌는 메타데이터는 재사용할 자료 뒤에 배치합니다. 맨 앞의 타임스탬프가 바뀌면 그 뒤 컨텍스트를 재사용하지 못할 수 있습니다. 명시적 캐시 분기점을 사용한다면 고정된 접두부가 끝나고 변동되는 뒷부분이 시작되기 직전에 표시합니다. Anthropic 캐시 분기점 안내.

다음 근무일에는 대표적인 에이전트 대화 하나를 골라 실제 요청이 만들어지는 지점에서 살펴보십시오. 연속된 호출의 접두부가 정확히 일치하는지 비교한 뒤, 제공사가 보고한 캐시 쓰기·읽기 사용량을 총 입력, 출력, 지연 시간과 함께 확인합니다. 제공사를 바꾸기 전에 불안정한 접두부부터 고칩니다. 적중률이 이미 충분한데도 에이전트가 느리다면, 다음으로 보관된 컨텍스트의 양, 출력 길이, 서버 자원 경합을 조사합니다.

AI 에이전트를 뒷받침하는 시스템을 실무 관점에서 이해하고 싶다면 뉴스레터를 구독하세요.