캐시 키: 라벨이 아니라 라우팅 힌트

추측 대신 키 크기를 잡는 이유

고유 키를 넣고 싶어지는 반사적 선택은 구체성이 공짜라고 — 더 촘촘한 키는 요청을 구분하는 데 도움만 줄 뿐이라고 — 전제합니다. 그 전제를 받아들이기 전에 두 가지를 나란히 놓아 볼 만합니다. 첫째는 Microsoft Learn이 문서화하는 내용입니다. 프롬프트 캐싱은 캐시 적격 조건으로 동일한 앞부분 프리픽스를 요구하고, prompt_cache_key는 프리픽스 해시와 결합되어 반복 작업이 어디에 떨어질지를 조종합니다. 같은 문서는 대략적인 지점 하나를 표시합니다 — 하나의 프리픽스+키 조합에 대해 분당 약 15개 요청 — 이를 넘어서면 트래픽이 추가 머신으로 흘러넘치고 캐시 효율이 떨어질 수 있습니다. 둘째는 이 저장소의 원천 실행에서 나온 희소한 정제 공개 집계로, 같은 프리픽스를 더 많은 버킷으로 쪼갤 때 캐시 적중률과 첫 토큰 지연이 실제로 어떻게 움직였는지를 보여 주려고 서술용으로 포함합니다.

잠시 멈춰 볼 부분은 그 짝짓기입니다. 적중률만 보면 그 아래에서 사용자 경험이 바뀌는 동안에도 안심되게 읽힐 수 있습니다. 이 구간에서는 버킷 수가 늘어나는 동안에도 적중률이 높고 거의 평평하게 유지되어, 그 값만 읽으면 쪼개기에 비용이 들지 않은 것처럼 보입니다. 나머지 절반의 이야기는 첫 토큰 지연의 꼬리가 들려줍니다 — 뜨거운 버킷 하나가 매우 큰 p95를 지고 있었는데, 트래픽을 더 많은 버킷으로 분산하자 그 값이 가파르게 떨어졌습니다. 그래서 운영의 질문은 “캐시가 적중했는가?”가 아니라 “각 버킷이, 한 버킷만 너무 뜨거워지지 않으면서 프리픽스가 지역성을 유지하도록 크기가 잡혀 있는가?”입니다. 프리픽스 해시 라우팅과 분당 약 15개 요청이라는 대략적 오버플로 지점은 Microsoft Learn이 문서화하는 내용이고, 버킷 수 계산과 적중률·지연을 함께 보여 주는 공개 자료는 보편적인 캐시 적중 곡선이 아니라 이 저장소가 옹호하는 운영적 추론이자 원천 실행 근거입니다. 아래 차트가 그 짝짓기를 명시적으로 보여 줍니다.

공식 동작 · 키가 바꾸는 것

동일한 프리픽스에서 시작하는 캐시

Microsoft Learn에 따르면 프롬프트 캐싱에는 최소 1,024개의 입력 토큰이 필요하며 처음 1,024개 토큰이 동일해야 합니다. 초기 프리픽스는 라우팅을 위해 해시되고, 처음 1,024개 토큰 이후에는 추가 캐시 일치가 128개 토큰 단위로 발생합니다. 처음 1,024개 토큰 안에서 단 한 글자만 달라져도 캐시 적중이 미스로 바뀔 수 있습니다.

크기 산정 · 버킷을 위험 구간 아래로 유지

버킷 수의 트레이드오프: 하나는 너무 뜨겁고, 다수는 너무 차가움

Microsoft Learn은 대략적인 오버플로 지점을 설명합니다. 동일한 프리픽스와 prompt_cache_key 조합이 분당 약 15개 요청을 초과하면 일부 요청이 추가 머신으로 라우팅되어 캐시 효율이 떨어질 수 있습니다. 실무적인 크기 산정 규칙은 공유 프리픽스를 충분히 안정적인 버킷으로 나누어 각 버킷이 여유를 두고 그 위험 구간 아래에 머무르도록 하는 것입니다.

관측된 근거 · 희소한 공개 자료

적중률과 지연을 함께 읽기

키 설계 · 안정적인 워크로드 버킷

버킷 기준: 호출이 아니라 워크로드 단위

좋은 키는 동일한 워크로드에 대해 결정적이어야 합니다. 나쁜 키는 호출마다 달라지는 엔트로피를 담습니다. 타임스탬프, UUID, 무작위 접미사, 또는 고유한 호출 토큰이 키에 들어가면 캐시 키 공간이 폭발하고 프리픽스가 재사용을 쌓을 수 없습니다.

출처와 근거 경계

Tier 1 — 서비스 계약(Microsoft Learn). 프롬프트 캐싱 프리픽스 규칙, 프리픽스 해시 라우팅, 128개 토큰 단위 일치 단계, 단 한 글자의 미스, prompt_cache_key 라우팅 힌트, 그리고 분당 약 15개 요청의 오버플로 지점이 여기에 문서화되어 있습니다.

• [1] Prompt caching with Azure OpenAI — 1,024 토큰 최소 요건과 동일 프리픽스 요구, 초기 프리픽스 해시 기반 라우팅, 처음 1,024개 이후 추가로 동일한 128개 토큰마다의 캐시 일치, 단 한 글자의 캐시 미스, 프리픽스 해시와 결합되어 라우팅에 영향을 주는 prompt_cache_key 힌트, 그리고 동일 프리픽스·키 요청이 추가 머신으로 넘쳐 캐시 효율이 떨어지는 분당 약 15개 요청 지점을 정의합니다. 출처: Microsoft Learn 문서 (2026-06-04 접근) · 아카이브.

Tier 2 — 운영적 추론(이 저장소). 버킷 개수 계산과 공개 적중률 자료는 Learn 사양이 아니라 이 저장소의 운영적 추론이자 소스 실행 근거입니다.

• [2] 이 저장소, docs/12-prompt-cache-key-policy.md — 버킷 크기 산정 런북: 문서화된 약 15-RPM 수치에서 minimum_buckets = ceil(common_prefix_rpm / 15)를 도출하며, recommended_buckets 공식과 기본 버킷당 10-RPM 목표는 Learn 사양이 아니라 이 저장소의 운영적 추론입니다. 출처.
• [3] 이 저장소, results/cache-key-bucketing/cache_hit_ratio_vs_cardinality.csv — 적중률과 첫 토큰 지연 표의 바탕이 된 희소한 공개 집계 자료로, 보편적 곡선이 아니라 소스 실행 근거입니다. 출처.

이 주제가 증명하는 것과 증명하지 못하는 것. 접근일 기준 Microsoft Learn이 명시하는 프롬프트 캐싱 계약 — 1,024 토큰 프리픽스 규칙, 프리픽스 해시 라우팅, prompt_cache_key 힌트, 분당 약 15개 요청의 오버플로 지점 — 과, 공유 프리픽스를 각 버킷이 여유를 두고 그 지점 아래에 머물도록 충분히 안정적인 버킷으로 나누는 이 저장소의 크기 산정 경험칙을 문서화합니다. 버킷 개수 공식과 공개 적중률 자료는 운영적 추론이자 소스 실행 근거이며, 보장된 캐시 적중 곡선이 아닙니다. 모든 모델·리전·트래픽 형태에서 동일하게 성립하는 보편적 임계값은 증명하지 못합니다.