Efficient Request Queueing – Optimizing LLM Performance

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

다중 사용자 환경의 대규모 언어 모델 서빙에서는 사용자별 공정 스케줄링과 백엔드 지표 기반의 동적 요청 제어를 결합해야 지연 시간을 줄이면서 그래픽 처리 장치 활용률을 유지할 수 있다.

📌 핵심 요약

• 추론 엔진은 들어온 요청을 대기열에 모은 뒤 여러 요청을 배치로 처리해 그래픽 처리 장치의 성능과 자원 효율을 높이지만, 단순 선입선출 방식에서는 한 사용자의 대량 요청이 다른 사용자를 오래 막을 수 있다.
• 상위 API 서버에 사용자별·모델별 대기열을 두고 각 대기열을 순환하며 요청을 전송하면, 먼저 도착한 한 사용자의 요청을 모두 처리하기 전에 뒤늦게 참여한 사용자의 요청도 공정하게 배치할 수 있다.
• 공정성은 요청 수뿐 아니라 처리 시간, 프롬프트 유사성에 따른 핵심값 캐시 적중 가능성, 요청 비용, 대화형·코드 검토·일괄 처리와 같은 업무 우선순위까지 고려해 확장할 수 있다.
• 상위 서버가 요청을 너무 빨리 전송하면 백엔드의 선입선출 대기열이 다시 가득 차므로, 백엔드 대기열 길이와 토큰당 출력 시간 같은 프로메테우스 지표를 이용해 전송 속도를 동적으로 제한해야 한다.
• vLLM의 백엔드 우선순위 스케줄링은 높은 우선순위 요청을 대기열과 실행 배치 앞으로 이동시킬 수 있지만, 우선순위 부여와 전송률 제어에는 여전히 상위 API 서버가 필요하며 다른 추론 엔진에는 같은 기능이 제공되지 않는다.

🧩 주요 포인트

1. 추론 엔진은 들어온 요청을 대기열에 모은 뒤 여러 요청을 배치로 처리해 그래픽 처리 장치의 성능과 자원 효율을 높이지만, 단순 선입선출 방식에서는 한 사용자의 대량 요청이 다른 사용자를 오래 막을 수 있다.
2. 상위 API 서버에 사용자별·모델별 대기열을 두고 각 대기열을 순환하며 요청을 전송하면, 먼저 도착한 한 사용자의 요청을 모두 처리하기 전에 뒤늦게 참여한 사용자의 요청도 공정하게 배치할 수 있다.
3. 공정성은 요청 수뿐 아니라 처리 시간, 프롬프트 유사성에 따른 핵심값 캐시 적중 가능성, 요청 비용, 대화형·코드 검토·일괄 처리와 같은 업무 우선순위까지 고려해 확장할 수 있다.
4. 상위 서버가 요청을 너무 빨리 전송하면 백엔드의 선입선출 대기열이 다시 가득 차므로, 백엔드 대기열 길이와 토큰당 출력 시간 같은 프로메테우스 지표를 이용해 전송 속도를 동적으로 제한해야 한다.
5. vLLM의 백엔드 우선순위 스케줄링은 높은 우선순위 요청을 대기열과 실행 배치 앞으로 이동시킬 수 있지만, 우선순위 부여와 전송률 제어에는 여전히 상위 API 서버가 필요하며 다른 추론 엔진에는 같은 기능이 제공되지 않는다.

🧠 상세 정리

1. 추론 엔진의 대기열과 배치 처리

여러 애플리케이션과 사용자가 제한된 그래픽 처리 장치를 공유하면 동시에 들어오는 대규모 언어 모델 요청이 서로 자원을 두고 경쟁하게 된다. vLLM이나 허깅페이스 TGI 같은 추론 엔진은 다음 토큰을 계산하는 작업자, 새 요청이 들어가는 대기열, 대기열의 요청을 작업자로 옮기는 스케줄러로 구성된다. 대기열이 필요한 이유는 요청을 하나씩 고립시켜 계산하는 것보다 여러 요청을 하나의 배치로 묶어 계산하는 편이 그래픽 처리 장치의 성능과 자원 효율 측면에서 유리하기 때문이다. 스케줄러는 대기 중인 여러 요청을 골라 같은 배치에 넣고, 추론 엔진은 이 배치를 처리하면서 토큰을 생성한다. 일반적으로 추론 엔진 하나는 모델 하나만 제공하므로, 서로 다른 모델을 운영하려면 모델별 배포 인스턴스를 병렬로 실행하게 된다.

2. 선입선출 대기열에서 발생하는 사용자 독점

단순한 선입선출 대기열에서는 한 사용자가 짧은 시간에 많은 요청을 보내면 그 요청들이 백엔드 대기열을 빠르게 채운다. 사용자 A가 여러 요청을 먼저 전송하고 사용자 B와 C가 잠시 뒤에 요청을 보내면, B와 C의 요청은 A가 먼저 쌓아 둔 요청들이 처리될 때까지 같은 모델을 이용하지 못한다. 이 현상은 특정 사용자가 계산 자원을 직접 독점해서라기보다, 한 번 백엔드에 들어간 요청의 순서를 나중에 바꾸기 어렵다는 대기열 구조에서 발생한다. 예시는 vLLM을 중심으로 설명되지만, 선입선출 방식으로 요청을 받는 다른 추론 백엔드에서도 같은 문제가 나타날 수 있다. 따라서 배치 처리의 효율은 유지하되 한 사용자의 대량 제출이 다른 사용자의 응답 시작을 지나치게 늦추지 않도록 별도의 스케줄링 계층이 필요하다.

3. 사용자별 대기열과 공정 스케줄링

TNG의 구성에서는 사용자가 vLLM 백엔드에 직접 요청하지 않고 LLM 서버라고 부르는 API 서버를 거친다. 이 서버는 사용자와 모델별로 분리된 대기열을 유지하고, 전체 요청을 하나의 선입선출 순서로 꺼내는 대신 각 사용자 대기열을 순환 방식으로 방문한다. 사용자 A의 첫 요청이 이미 예약된 뒤 B와 C가 참여하더라도, A의 나머지 요청을 모두 처리할 때까지 기다리게 하지 않고 서로 다른 사용자의 요청을 번갈아 백엔드로 보낼 수 있다. 예시에서는 A의 요청 세 개가 먼저 기다리고 있어도 C가 A의 요청 하나만 더 완료된 뒤 서비스를 받을 수 있어 신규 사용자의 지연이 크게 줄어든다. 핵심은 추론 엔진에 요청을 보낸 뒤 순서를 고치려 하지 말고, 완전한 제어권이 있는 상위 LLM 서버에서 사용자 간 우선순위를 정해 올바른 순서로 전송하는 것이다.

4. 공정성 기준과 업무별 우선순위의 확장

가장 단순한 공정성은 한 사용자가 연속해서 두 번 이상 처리되기 전에 단일 요청만 보낸 새 사용자를 먼저 서비스하는 요청 수 기준이다. 처리 시간을 기준으로 삼아 긴 프롬프트나 긴 생성이 다른 사용자를 오래 막지 않도록 짧은 요청을 우선할 수도 있지만, 생성 길이는 사전에 정확히 예측하기 어렵다. 최대 토큰 수가 지정된 요청도 있으나 일반적인 대화형 요청은 제한이 없을 수 있고, 같은 형태의 요청도 짧은 요약부터 긴 이야기나 전체 코드 작성까지 출력 길이가 크게 달라진다. 프롬프트 유사성을 바탕으로 요청 순서를 조정하면 vLLM의 핵심값 캐시 적중률을 높일 여지가 있으며, 업무 환경이나 호스팅 서비스에서는 개별 요청 비용도 판단 기준이 될 수 있다. 또한 대화형 서비스는 빠른 반응을 위해 높은 우선순위를, 대규모 코드 검토는 중간 우선순위를, 벤치마크와 예약 일괄 작업은 다른 작업이 없을 때 실행되는 낮은 우선순위를 부여할 수 있다.

5. 백엔드 대기열의 역압력 부재

상위 LLM 서버가 공정한 순서를 계산했더라도 모든 요청을 즉시 백엔드로 보내면 문제가 다시 발생한다. 사용자 A의 요청들이 백엔드 선입선출 대기열에 한꺼번에 쌓인 뒤 사용자 C가 참여하면, C는 상위 서버의 공정 스케줄링과 관계없이 이미 들어간 A의 요청이 끝날 때까지 기다려야 한다. 이상적으로는 백엔드 대기열의 최대 항목 수를 제한해 상위 스케줄러가 요청을 밀어 넣지 못하도록 역압력을 제공해야 하지만, vLLM은 해당 제한 기능을 제공하지 않는다. 따라서 상위 서버가 백엔드 상태를 관찰하면서 새 요청의 전송 속도를 동적으로 조절하고, 신규 사용자의 지연을 줄이기 위해 백엔드 대기열을 짧게 유지해야 한다. 고정 전송률 제한은 요청이 대부분 짧을 때 그래픽 처리 장치를 충분히 활용하지 못할 수 있고 모델과 부하 양상마다 적정 값을 맞추기도 어려워 적합하지 않다.

6. 프로메테우스 지표를 이용한 동적 전송 제어

LLM 서버는 vLLM의 지표 제공 경로에서 프로메테우스 지표를 가져와 백엔드 대기열 길이를 스케줄링 판단에 사용할 수 있다. 예를 들어 백엔드 대기열 길이가 3보다 작을 때만 새 요청을 전송하면, 대기 요청이 무제한으로 누적되는 것을 막으면서 현재 처리 용량을 계속 채울 수 있다. 목표 대기열 길이를 더 낮추면 신규 사용자의 지연은 줄어들지만 배치가 충분히 채워지지 않아 처리 효율이 떨어질 수 있으므로 두 목표 사이에 절충이 필요하다. 이 목표값은 최대 동시 처리 요청 수를 뜻하지 않으며, vLLM의 연속 배치 기능은 현재 배치에 공간이 생기는 즉시 대기 요청을 추가하므로 실제 병렬 처리 수는 목표 대기열 길이보다 많을 수 있다. 현재 지표가 0이고 허용 길이가 3이라면 지표를 다시 조회하기 전에 요청 세 개를 즉시 보내는 방식으로 지표 조회와 전송 과정도 최적화할 수 있다.

7. 응답 속도와 요청 등급을 반영한 피드백 제어

백엔드 대기열과 상위 스케줄러 사이에 피드백 고리가 만들어지면 대기열 길이 외의 지표도 전송 결정에 추가할 수 있다. TNG의 대화형 인공지능 비서는 초당 7토큰을 넘는 생성 속도, 즉 출력 토큰당 약 150밀리초보다 빠른 응답을 사용자 경험의 목표로 삼는다. 백엔드가 보고한 출력 토큰당 시간이 150밀리초를 넘으면 상위 스케줄러는 새 요청을 보내지 않아 진행 중인 요청의 생성 속도가 더 악화되는 것을 막는다. 지표 임계값은 요청 우선순위에 따라 다르게 설정할 수 있으며, 낮은 우선순위의 일괄 처리 요청은 백엔드 대기열이 완전히 비었을 때만 예약할 수 있다. 이 정책은 그래픽 처리 장치가 잠시 덜 활용될 위험을 감수하더라도 이후 도착할 높은 우선순위 요청의 지연이 늘어나는 상황을 피하는 데 목적이 있다.

8. 백엔드 우선순위 스케줄링의 가능성과 한계

vLLM은 기존 선입선출 방식 대신 요청에 숫자 우선순위를 붙여 보내는 백엔드 우선순위 스케줄링 기능을 추가했다. 더 높은 우선순위의 요청이 대기하면 vLLM은 대기열뿐 아니라 실행 중인 배치까지 우선순위에 따라 다시 정렬해 해당 요청을 처리 배치로 직접 이동시킬 수 있다. 그 과정에서 낮은 우선순위 요청은 실행 배치에서 빠져나와 대기열로 돌아갈 수 있으며, 반복 정렬의 부가 비용과 현실적인 부하에서 지연 시간에 미치는 영향은 추가 측정이 필요하다. 사용자가 백엔드에 보낸 미완료 요청 수에 따라 같은 사용자의 두 번째·세 번째 요청에 점차 낮은 우선순위를 부여하면 사용자별 공정성도 표현할 수 있지만, 이 기능은 vLLM에만 있고 허깅페이스 TGI에는 제공되지 않는다. 또한 백엔드 기능만으로는 출력 토큰당 시간에 따른 전송률을 제어하거나 각 요청의 업무적 우선순위를 객관적으로 정할 수 없으므로, 대기열 로직은 단순화할 수 있어도 상위 LLM 서버 자체를 완전히 제거할 수는 없다.

9. 다중 사용자 서빙을 위한 결론과 다음 주제

대기열과 스케줄링 정책은 우선순위와 부하 특성이 서로 다른 여러 사용자와 클라이언트가 동시에 요청하는 환경에서 사용자 경험을 직접 좌우한다. 사용자별 대기열을 순환하는 공정 스케줄링은 특정 사용자의 대량 요청이 다른 사용자의 응답 시작을 막는 문제를 완화하고, 지표 기반 전송 제어는 공정한 순서가 백엔드 선입선출 대기열에서 다시 무너지는 것을 방지한다. 백엔드 대기열 목표를 지나치게 낮추면 배치 효율이 감소할 수 있으므로 짧은 지연과 높은 자원 활용률 사이에서 운영 목적에 맞는 균형을 찾아야 한다. vLLM의 우선순위 기능은 상위 계층의 대기열 구현을 줄일 수 있지만, 요청 등급 결정과 전송률 조절을 담당할 API 서버는 현실적인 구성에서 계속 필요하다. 후속 글에서는 추론 엔진의 사전 채움과 디코드 단계에서 이루어지는 토큰 생성, 자원 활용, 여러 요청의 동시 처리 전략을 다룰 예정이다.

🧾 핵심 주장 / 시사점

• 공정 스케줄링의 실효성은 사용자별 순서를 계산하는 것만으로 확보되지 않으며, 계산된 순서가 백엔드에 반영될 수 있도록 백엔드 대기열의 길이까지 함께 통제해야 한다.
• 대기열 길이와 출력 토큰당 시간을 이용한 피드백 제어는 고정 전송률보다 모델별 처리 특성과 변화하는 요청 길이에 대응하기 쉽지만, 낮은 지연과 배치 효율 사이의 임계값 조정이 필요하다.
• 백엔드 우선순위 기능이 있어도 요청의 업무적 중요도를 판정하고 사용자별 공정성을 수치화하며 전송 속도를 제어하는 책임은 상위 API 서버에 남는다.

✅ 액션 아이템

• 상위 API 서버에서 사용자별·모델별 대기열을 두고 순환 전송을 적용해 한 사용자의 대량 요청이 다른 사용자 지연을 압박하지 않도록 한다.
• 공정성 규칙을 요청 수 외 처리시간, 캐시 적중 가능성, 요청 비용까지 확장해 배치 우선순위 산정을 강화한다.
• 백엔드 선입선출 혼잡을 막기 위해 대기열 길이와 토큰당 출력시간 지표를 기반으로 상위 서버 전송률을 동적으로 제한한다.

❓ 열린 질문

• 사용자별·모델별 라운드 기반 스케줄링에서 한 사이클 처리량은 어느 수준으로 두는 것이 지연 완화에 가장 적합한가?
• 처리시간, 캐시 적중 가능성, 요청 비용을 함께 반영할 때 공정성 가중치는 어떤 방식으로 정해야 할까?
• vLLM 우선순위 이동 기능이 있는 경우, 다른 추론 엔진과의 정책 일관성을 위해 상위 서버는 어떤 우선순위 기준으로 정렬해야 할까?