KV 캐시와 continuous batching: 추론 서버 처리량을 어디서 늘릴까?

요청을 모으는 방식이 체감 성능을 바꿉니다

현행 Transformers 문서는 생성 단계마다 요청을 다시 배치하는 continuous batching을 설명하고, NVIDIA의 TensorRT-LLM 백엔드도 진행 중인 요청을 묶어 처리하는 구성을 다룹니다. 긴 응답과 짧은 응답이 섞인 서비스에서는 같은 크기의 요청 묶음을 끝까지 기다리는 방식이 비효율적일 수 있습니다. 자체 추론 서버를 운영한다면 모델 크기와 GPU 수 외에 요청 스케줄링을 살펴볼 이유입니다.

• Hugging Face Transformers · Continuous batching
• NVIDIA Triton · TensorRT-LLM Backend

가상의 사내 문서 도우미에는 짧은 용어 질문과 긴 보고서 요약이 동시에 들어옵니다. 긴 요청이 끝날 때까지 새 요청을 받지 못하면 유휴 자원이 생길 수 있고, 반대로 무조건 많이 받아들이면 메모리와 대기 시간이 악화될 수 있습니다. 먼저 요청의 입력·출력 길이와 유입 간격을 수집해 어떤 조합에서 지연이 생기는지 확인합니다.

KV 캐시와 공통 접두부 재사용은 같은 지표가 아닙니다

토큰 생성 중 사용하는 KV 캐시는 앞서 처리한 토큰의 계산 정보를 보관합니다. 활성 요청의 길이와 수가 늘면 메모리 사용도 함께 커집니다. vLLM의 접두부 캐싱은 여기에 더해 새 요청이 공유하는 입력 앞부분의 계산을 재사용하는 기능입니다. 공통 지침이나 같은 문서가 반복될 때와 매번 다른 자료가 들어올 때의 이득을 따로 측정해야 합니다.

접두부가 재사용되어 입력 처리가 빨라졌다고 출력 생성 단계까지 같은 비율로 빨라지는 것은 아닙니다. 요청마다 긴 답변을 만드는 업무는 생성 시간의 비중이 클 수 있습니다. 반대로 입력이 길고 출력이 짧은 업무에서는 입력 계산과 캐시가 중요할 수 있습니다. 전체 응답 시간을 한 숫자로만 비교하지 말고 단계별 시간과 유효하게 완료된 요청을 함께 기록하세요.

부하 실험은 긴 요청과 짧은 요청을 섞어야 합니다

실험에서는 동일한 GPU·모델·정밀도를 유지하고 동시성, 입력 길이와 출력 제한을 단계적으로 바꿉니다. 모든 요청이 짧은 경우와 긴 문서가 일부 섞인 경우를 따로 실행하세요. 앞선 요청의 완료를 기다렸다가 다음 요청을 보내는 방식만 쓰면 실제 혼잡 시 대기열이 쌓이는 모습을 놓칠 수 있어 유입률을 통제하는 실험도 필요합니다.

평균 초당 토큰 수가 올라가도 느린 요청의 지연이나 시간 초과가 악화되면 대화형 서비스에는 맞지 않을 수 있습니다. 접수부터 첫 응답, 생성 완료까지의 분포와 실패·취소를 함께 집계합니다. 한 사용자의 긴 작업이 짧은 요청을 밀어내는지도 확인하고, 필요하면 긴 작업을 분리된 경로로 보내거나 허용 문맥과 대기열 한도를 조정합니다.

최대 처리량보다 유지 가능한 운영 지점을 정합니다

튜닝 결과는 서버 버전, 모델 구조와 커널 구현이 바뀌면 다시 달라질 수 있습니다. 기준 부하와 설정을 보관하고, 처리량 증가가 지연 목표·메모리 여유와 양립하는 지점을 선택하세요. 공통 입력을 캐시할 때도 사용자 권한과 데이터 경계를 유지해야 합니다. 비용 비교에는 완료한 업무 수와 장애 복구 시간을 포함해야 실제 운영에 쓸 수 있는 결론이 됩니다.

• 입력 처리와 출력 생성 시간을 구분했는가
• 공유 접두부 유무에 따른 차이를 측정했는가
• 긴 요청이 섞인 유입 부하에서 대기열을 확인했는가
• 처리량 증가와 함께 지연·실패·메모리 여유를 확인했는가