vLLM은 왜 캐시가 있는 요청을 먼저 받을까

처음 들어온 프롬프트를 가진 요청 A와 앞부분을 재사용할 수 있는 요청 B가 순서대로 대기 중이라고 하자. vLLM의 캐시 기반 대기열 재정렬은 조건이 맞으면 B의 순서를 앞당길 수 있다. B가 적중한 KV 블록을 먼저 확보하면 A의 새 블록 할당에 밀려날 가능성을 줄인다. A와 B의 순서는 동작을 설명하기 위한 가상 예시다.

고정 리비전의 스케줄러 코드 (새 창)는 prefix caching과 FCFS를 함께 쓸 때만 이 옵션을 적용한다. 창 크기의 기본값은 0, 캐시 사용량 임계값의 기본값은 0.5다. 재정렬 조건을 만족하면 대기열 앞 N개에서 아직 계산을 시작하지 않은 일반 대기 요청의 자리만 모은다. 해당 자리의 요청을 캐시 적중 토큰이 많은 순으로 정렬하고, 동률이면 도착 순서를 유지한다. 차단되었거나 일부 계산된 요청은 자리가 그대로다.

이 단계는 대기 순서만 바꾼다. 실제 실행 여부는 이후의 토큰 예산과 블록 할당에도 달려 있다. B가 앞당겨져도 같은 스텝에서 실행된다고 보장할 수는 없다.

vLLM의 캐시 설계 예시 (새 창)에서는 요청이 적중한 블록의 참조 수를 먼저 올린다. 다른 요청이 쓰지 않아 그 블록이 자유 큐에 있었다면 큐에서 빠진다. 이후 새 블록은 자유 큐의 앞에서 가져오므로, 캐시가 남은 블록을 할당받으면 이전 캐시 항목이 제거될 수 있다.

가상의 A와 B에 대입하면, A가 먼저 오고 새 블록 할당이 B의 캐시 블록까지 닿을 때 B는 그 부분을 다시 계산한다. B가 먼저 블록을 확보하면 같은 축출 경로를 피할 수 있다. 자유 블록이 충분하거나 A의 할당이 해당 블록까지 닿지 않으면 순서를 바꿔도 이 이득은 생기지 않는다.

창을 넓히면 재사용 후보가 더 들어오지만, 각 스텝에서 확인할 캐시 조회도 늘어날 수 있다. 가상 예시에서 B를 앞당기면 캐시가 없는 A는 더 기다릴 수 있다. 비교하려면 동일한 요청 순서와 부하에서 창을 끈 설정과 작은 창을 둔 설정을 각각 실행하고, 적중 여부별 첫 토큰까지의 상위 지연과 재계산량을 함께 본다. 반복 접두부가 많고 축출로 재계산이 자주 생기는지부터 확인한다. 캐시가 없는 요청의 지연이 허용 범위를 넘으면 적중률이 올라도 창을 넓힐 근거가 약하다. 이 글은 코드를 읽어 동작을 추적했으며 처리량이나 지연을 측정하지 않았다.