LLM 엔진 과부하는 왜 취소만으로 회복되지 않는가

들어가며

LLM 호출이 시간 초과되면 클라이언트와 프록시는 자동으로 재시도하는 경우가 많다. 사용자가 이미 떠난 요청을 취소하면 추론 엔진이 자원을 회수하고 정상화할 것이라는 기대도 자연스럽다. 그러나 arXiv에 공개된 연구는 이 가정이 충분하지 않다고 지적한다. 취소가 엔진에 도착하기 전에 재시도가 프롬프트 처리에 필요한 계산 대부분을 이미 수행할 수 있기 때문이다.

실험에서 드러난 문제

연구진은 vLLM에서 세 가지 오픈 모델을 사용해 과부하, 재시도, 취소를 조합한 실험을 진행했다. 한 모델에 대해서는 각 클라이언트 시도와 엔진 내부에서 생성된 실행을 연결하는 스케줄러 추적도 수집했다. 주요 결과는 다음과 같다.

• 취소만으로는 서비스가 복구되지 않았다. 재시도를 켠 실험에서 취소 단독으로 서비스가 회복된 경우는 없었다. 과부하 이후 도착한 호출 중 실제로 전달된 비율은 12~38%에 그쳤다.
• 취소 시점이 너무 늦었다. vLLM이 실행한 재시도는 시간 초과 0.5초 이내에 프리필을 시작하는 경우가 많았다. 이후 vLLM이 중단한 실행도 프롬프트 토큰의 79~85%를 이미 계산한 상태였다.
• 기본 지표가 낭비를 놓칠 수 있다. vLLM의 프롬프트 토큰 카운터는 실제 계산된 프롬프트 토큰의 약 3분의 1에서 절반을 기록하지 못했다. 이 수치만 보면 재시도로 발생한 계산 낭비와 부하를 과소평가할 수 있다.

연구는 두 가지 대안도 비교했다. 재시도 예산은 추가 시도를 제한해 서비스를 회복시켰지만, 과부하 기간에 발생한 많은 호출은 전달되지 않았다. 요청 병합은 중복 시도를 하나로 묶었고, 취소가 실행 중인 처리를 먼저 중단하지 않았다면 과부하 이후의 모든 호출을 전달했다. 다만 일부 응답은 늦게 도착했다.

의미와 영향

이 결과는 “취소가 성공했는가”만으로 시스템 상태를 판단할 수 없음을 보여준다. API 계층에서 요청이 취소됐더라도 추론 엔진은 이미 대부분의 계산을 끝냈을 수 있다. 반대로 엔진의 대기열이 비워졌다고 해서 사용자 요청이 결과를 받은 것은 아니다.

LLM 서비스 운영자는 재시도를 클라이언트 측 안정성 기능이 아니라 용량 관리의 일부로 다뤄야 한다. 제한된 재시도, 중복 요청의 조기 탐지, 요청 병합, 실제로 계산된 모든 토큰을 포함하는 비용 지표가 주요 설계 후보가 될 수 있다. 이 연구가 모든 환경에 적용되는 단일 해법을 제시한 것은 아니다. 하지만 평가 기준은 분명하다. 재시도가 추가한 실행량과 최종적으로 사용자에게 전달된 호출을 함께 측정해야 한다.

출처: arXiv