LLM 성능 최적화를 위한 효율적인 요청 큐잉
문제: 파워 유저에 의한 리소스 차단
표준 추론 엔진(예: vLLM 또는 HuggingFace TGI)에서는 요청이 일반적으로 워커, 큐 및 스케줄러에 의해 처리됩니다. GPU 연산은 배치로 수행될 때 더 효율적이므로, 백엔드 큐는 스케줄러가 여러 요청을 하나의 배치로 묶을 수 있게 합니다.
하지만 "파워 유저"가 대량의 요청을 보내면 백엔드 큐를 가득 채울 수 있습니다. 이 경우, 다른 사용자의 후속 요청은 파워 유저의 모든 요청이 처리될 때까지 기다려야 하는 차단 효과가 발생하며, 새로운 요청의 긴급성이나 양과 무관하게 지연됩니다.
해결책: 공정 스케줄링 구현
리소스 차단을 방지하기 위해 TNG는 사용자와 추론 백엔드 사이에 위치하는 "LLM-Server"(API 서버)를 구현합니다. 요청을 직접 백엔드에 보내는 대신, LLM-Server는 각 사용자와 모델별로 별도의 큐를 관리합니다.
라운드 로빈 스케줄링
LLM-Server는 선입선출(FIFO) 방식이 아닌 라운드 로빈 스케줄러를 사용합니다. 이를 통해 서로 다른 사용자의 요청이 우선 순위를 갖게 되며, 특정 사용자가 여러 요청을 대기 중이더라도 단일 요청을 가진 사용자는 더 빠르게 서비스를 받을 수 있습니다.
잠재적인 스케줄링 확장
단순 요청 수 외에도 여러 메트릭을 기반으로 스케줄링을 세밀하게 조정할 수 있습니다:
- 처리 시간: 생성 길이를 추정하기 어려운 상황에서도 전체 대기 시간을 줄이기 위해 짧은 요청을 우선시합니다.
- 캐시 최적화:
KV-cache히트를 최대화하기 위해 유사한 요청을 함께 배치합니다. 이는NVIDIA Dynamo와AIBrix와 같은 프레임워크에서 사용되는 기법입니다. - 비즈니스 비용: 작업의 재정적 비용에 따라 요청 우선순위를 정합니다.
- 우선순위 티어: 사용 사례에 따라 서로 다른 큐를 설정합니다. 예를 들어, 인터랙티브 채팅 인터페이스는 높은 우선순위를 받아 UI 반응성을 유지하고, 코드 리뷰나 벤치마크용 배치 API 작업은 낮은 우선순위를 가집니다.
백엔드 백프레셔 관리
LLM-Server 수준에서의 공정 스케줄링은 서버가 모든 우선순위 요청을 즉시 백엔드에 전달할 경우 효과가 없습니다. 이렇게 하면 백엔드의 FIFO 큐에 요청이 쌓여 차단 문제가 다시 발생하기 때문입니다.
메트릭 기반 속도 조정
일부 백엔드(예: vLLM)는 백엔드 큐의 최대 요소 수를 제한할 수 없으므로, LLM-Server는 요청을 전달하는 속도를 동적으로 조정해야 합니다. TNG는 vLLM /metrics 엔드포인트에서 Prometheus 메트릭을 가져와 이를 구현합니다.
백엔드 큐 길이 메트릭을 모니터링하여, 큐 길이가 특정 임계값(예: 3) 이하일 때만 새로운 요청을 전달합니다. 이를 통해 신규 사용자의 지연 시간을 최소화하면서 낮은 지연 시간과 GPU 미활용 사이의 균형을 맞춥니다.
고급 메트릭 피드백 루프
실시간 성능에 기반한 추가 최적화가 가능합니다:
- 토큰 속도 임계값: time-per-output-token 메트릭이 일정 한도(예: 150 ms)를 초과하면 서버는 최소 생성 속도(예: >7 tokens/s)를 유지하기 위해 새로운 요청 스케줄링을 중단합니다.
- 우선순위별 임계값: 낮은 우선순위 배치 요청은 백엔드 큐가 완전히 비어 있을 때만 스케줄링되어 고우선순위 사용자의 지연 시간을 절대 증가시키지 않도록 합니다.
대안: 백엔드 측 우선순위 스케줄링
최근 vLLM 버전에서는 우선순위 기반 스케줄링이 도입되어 요청에 우선순위 레벨을 태그할 수 있습니다. 고우선순위 요청은 큐를 "점프"하여 바로 처리 배치에 들어갈 수 있으며, 이 과정에서 낮은 우선순위 요청이 대기 큐로 되돌아갈 수도 있습니다.
LLM-Server 스케줄링과 비교
백엔드 측 우선순위 스케줄링이 일부 로직을 단순화하지만, 업스트림 LLM-Server가 여전히 필요한 이유는 다음과 같습니다:
- 호환성: 백엔드 우선순위 기능은
vLLM에서는 제공되지만HuggingFace TGI에서는 지원되지 않습니다. - 속도 제어: 백엔드 스케줄링은
time-per-output-token과 같은 성능 메트릭을 기반으로 요청 제출 속도를 제어하지 못합니다. - 우선순위 할당: 사용자 ID 또는 애플리케이션 유형에 따라 요청에 우선순위를 부여하려면 객관적인 업스트림 인스턴스가 필요합니다.
큐잉 전략 요약
| 전략 | 구현 위치 | 주요 이점 | 제한 사항 |
|---|---|---|---|
| FIFO | 백엔드 | 간단한 구현 | 파워 유저가 다른 사용자를 차단함 |
| 공정 스케줄링 | LLM-Server | 사용자 차단 방지 | 업스트림 서버 필요 |
| 메트릭 기반 백프레셔 | LLM-Server | 백엔드 지연 최소화 | 메트릭 폴링 필요 |
| 우선순위 스케줄링 | 백엔드 (vLLM) | 고우선순위 즉시 처리 | 속도 제어 없음; vLLM 전용 |
SUMMARY: TNG Technology Consulting GmbH는 파워 유저가 다른 사용자를 차단하지 않도록 업스트림 LLM-Server에서 공정 스케줄링과 메트릭 기반 백프레셔를 구현하여 LLM 성능을 최적화하는 전략을 제시합니다.
TITLE: LLM 성능 최적화를 위한 효율적인 요청 큐잉