Cache Hit과 Hidden State 탐지

Cache 상태도 운영 상태야

provider가 cache 적중 지표를 보여준다면 그걸 일급 telemetry로 다뤄. cache가 잘 먹고 있는 줄 알았던 워크플로가 실은 turn마다 prefix를 소리 없이 새로 쌓고 있을 수도 있거든. 비용 그래프가 알려주긴 하는데, 남겨야 알려주지. cache 적중률은 비용에도, 동작이 일관되느냐에도 앞서 나오는 지표야.

작정하고 찔러봐

같은 prefix를 짧은 간격으로 두 번 보내고, 두 번째가 적중했다고 나오는지 봐. 그다음 prefix에서 byte 하나만 바꿔 보내고, 이번엔 빗나가는지 봐. 5분짜리 시험이면 caching 전략이 의도대로 도는지가 드러나.

숨은 상태는 cache랑 재생에 산다

'알 수 없는' 모형 동작이 cache 상태까지 거슬러 올라가는 경우가 있어. 앞선 실험의 prefix가 아직 따뜻해서 답을 한쪽으로 기울이는 거지. session을 차갑게 다시 시작하고, prefix byte를 하나 바꿔서 cache를 강제로 깨고, 그래도 그 동작이 남는지 봐. 안 남으면 버그는 모형이 아니라 숨어 있던 cache 상태야.

Code

기록에 남기는 cache 적중률·python

def cache_hit_ratio(usage):
    fresh = usage.input_tokens - getattr(usage, "cache_read_input_tokens", 0)
    cached = getattr(usage, "cache_read_input_tokens", 0)
    total = fresh + cached
    return cached / total if total else 0.0

if cache_hit_ratio(response.usage) < 0.3 and prefix_should_have_hit:
    log_cache_miss_anomaly(response)

찔러보는 순서·text

1. Send prefix P + question Q1. Record cached_tokens.
2. Send prefix P + question Q2 (same P). Expect cached_tokens > 0 on second call.
3. Send prefix P' (P with one byte changed) + question Q3. Expect cached_tokens = 0.
If step 2 shows no hit, your prefix is not actually byte-stable -> hunt the cache buster.

Exercise

실제 워크플로 하나에서 요청 10번을 연달아 보내면서 turn마다 cache 적중률을 남겨봐. 많이 재사용될 줄 알았는데 50%가 안 되면, 찔러보는 순서를 돌려서 훼방꾼을 잡아.

Hint

흔한 훼방꾼 — timestamp, request id, 정렬 안 된 JSON key, 매번 새로 만들어지는 tool schema.