이어지는 질문 세 개.

지난 편

6편에서 요청 하나가 접수부터 <EOS>까지 거치는 단계를 끝까지 따라가 봤다.

한 줄 결론

대화가 이어지면 앱 서버는 대화 전체를 다시 보내고, LLM 서버는 앞부분이 같으면 그 부분의 계산을 재사용한다.

쉽게 보기

6편의 대화에 질문 세 개를 차례로 붙여 보낸다. 2편 더 깊이에서 본 것처럼 API는 앞 대화를 기억하지 않는다. 그래서 앱 서버는 질문마다 대화 전체를 messages에 담아 다시 보낸다. 첫 후속 질문 그럼 수박은?의 요청은 6편 요청 끝에 메시지 두 개가 붙은 모양이다.

{
  "model": "claude-opus-5-5",
  "max_tokens": 1024,
  "system": "짧게 답하세요.",
  "messages": [
    { "role": "user", "content": "토마토는 과일이야?" },
    { "role": "assistant", "content": "네, 과일입니다." },
    { "role": "user", "content": "그럼 수박은?" }
  ],
  "stream": true
}

두 번째와 세 번째 질문도 같은 방식으로 직전 답과 새 질문이 messages 끝에 붙는다. 이 대화를 2편처럼 텍스트 하나로 이어 토큰으로 자르면 아래와 같다. 위치 0~15는 2편 표 그대로이고, 나머지 토큰 경계와 토큰 ID도 모두 가상 값이다.

답을 다시 보낼 때는 생성할 때 고른 <EOS> 자리에 닫는 표시 </assistant>(토큰 ID 10)가 들어간다. <EOS>는 원래 입력에 붙지 않았으므로 앞 답의 토큰은 <EOS> 앞까지만 남는다. 이 표시 방식은 2편처럼 공개 모델의 흔한 형식을 따른 것이고, Claude의 실제 형식은 공개되어 있지 않다.

질문마다 정리하면 이렇다(모두 가상 값).

캐시 히트는 직전 요청의 입력 토큰 수에 직전 답의 토큰 수(<EOS> 제외)를 더한 값이고, 새로 계산 열은 입력 토큰에서 캐시 히트를 뺀 값이다. 출력 토큰 수에는 <EOS>도 포함한다. 실제 엔진은 토큰 여러 개를 묶은 블록 단위(vLLM 기본 16토큰)로만 히트하므로 히트 수는 이보다 적을 수 있다. 여기서는 블록 단위를 무시하고 토큰 단위로 셌다(더 깊이 참고).

질문 1: 같은 앞부분은 다시 계산하지 않는다. 요청 1의 입력 27개 가운데 위치 0~18은 6편 요청이 이미 계산한 토큰과 ID가 똑같다. 여기서부터는 vLLM 같은 일반적인 서빙 엔진 기준이다. 6편 11단계에서 요청이 끝나면 KV 캐시 메모리를 비운다고 했다. 요청 사이에서 계산을 재사용하는 엔진은 그 메모리를 다른 요청이 쓸 수 있게 내놓되, 실제로 다른 요청이 그 자리를 쓰기 전까지는 내용을 지우지 않는다. 그래서 새 요청의 앞부분이 남아 있는 토큰과 같으면 그 값을 그대로 가져다 쓰고, prefill에서는 위치 19~26의 8개만 계산한다. 이렇게 요청끼리 같은 앞부분의 KV 캐시를 재사용하는 것을 prefix 캐시라고 한다. prefill이 짧아지므로 첫 토큰이 빨리 나온다.

질문 2: 다시 계산하지 않아도 참고는 한다. 그럼 왜 채소라고도 해?에는 무엇이 채소라는 건지가 없다. 모델은 앞 대화에서 그것을 찾는다. 아래는 어텐션에서 위치 34 채소가 앞 위치를 참고하는 비율의 한 예다.

위치 34 "채소"가 참고하는 비율 (어느 레이어의 한 예, 가상 값)

위치 22 수박 (질문 1)          0.15  ###
위치 27 수박 (답 1)            0.25  #####
위치 29 과일입니다. (답 1)     0.35  #######
위치 32 그럼                   0.05  #
위치 34 채소 (자기 자신)       0.10  ##
나머지 30개 위치               0.10  ##
                              -----
합계                           1.00

채소는 앞 답의 수박과 과일입니다.를 가장 많이 참고한다. 위치 32 그럼도 앞 답을 받아 이어 묻는 말이라, 그럼 자신을 계산할 때 위치 27 수박과 29 과일입니다.를 참고한다. 위치 27~29는 이번 요청에서 캐시 히트로 계산을 건너뛴 자리다. 계산만 건너뛸 뿐, 어텐션은 캐시에서 꺼낸 값을 새로 계산한 값과 똑같이 섞는다.

질문 3: 답이 길어지면 캐시도 커진다. 자세히 설명해줘에서는 예시를 짧게 하려고 요청의 max_tokens를 8로 줄였다. max_tokens는 토큰으로 바뀌어 입력에 들어가는 값이 아니라서, 바꿔도 캐시 히트에는 영향이 없다.

prefill   위치 46~53 계산 (0~45는 캐시에서)   -> 수박       캐시 54
decode 1  위치 54 수박                        -> 은         캐시 55
decode 2  위치 55 은                          -> 밭         캐시 56
...
decode 7  위치 60 식물                        -> 이라       캐시 61
출력이 max_tokens 8개에 도달해 멈춘다          stop_reason: "max_tokens"

decode마다 캐시가 한 토큰씩 늘어 61개가 된다. 마지막에 고른 이라는 <EOS>처럼 입력에 다시 붙지 않아 캐시에 들어가지 않는다. 답은 수박은 밭에서 자라는 한해살이 식물이라에서 끊기고, stop_reason은 max_tokens다. 6편 요청이 끝날 때 캐시는 19개였는데, 대화가 세 번 이어지자 요청 하나의 캐시가 61개로 늘었다.

시스템 지침에 현재 시각을 넣으면 손해인 이유. prefix 캐시는 요청 맨 앞부터 토큰 ID가 완전히 같은 구간까지만 히트한다. 3편에서 본 것처럼 각 위치의 값은 자기와 그 앞 토큰 전부를 섞어 만든다. 그래서 중간에 한 토큰만 달라도 그 뒤 위치의 값은 모두 달라진다. 시스템 지침 끝에 현재 시각 14:03처럼 보내는 시각을 붙인다고 하자. 질문 2를 14:03에, 질문 3을 14:05에 보내면 이렇다.

시각 토큰 5개가 늘어 질문 3의 입력은 59개다(가상 값). 시각이 없으면 질문 3은 8개만 계산하면 되는데, 시각이 바뀌어서 위치 11~58의 48개를 다시 계산한다. 위치 12부터는 토큰이 같아도 앞에 다른 시각을 섞었기 때문에 재사용할 수 없다. 시스템 지침은 모든 요청의 맨 앞에 온다. 여기에 매번 바뀌는 값을 넣으면 요청마다 시각 뒤의 대화 전체를 다시 prefill하고, 대화가 길어질수록 그 양도 늘어난다. 시각이 꼭 필요하면 바뀌지 않는 부분 뒤, 예를 들어 이번 질문 메시지에 넣는다.

새 용어

• prefix 캐시: 요청끼리 맨 앞부분의 토큰 ID가 같으면, 앞 요청에서 계산해 둔 그 부분의 KV 캐시를 다음 요청의 prefill에 재사용하는 것. 맨 앞부터 처음 달라지는 토큰 전까지만 히트한다.

"usage": {
  "input_tokens": 50,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 2000,
  "output_tokens": 120
}