LLM Inference Scheduler Analysis

LLM Inference Scheduler 심층 분석

Admission Control · Batching Policy · SLO Aware Queueing · Fairness · Token Budgeting

LLM inference scheduler는 단순히 요청 순서를 정하는 큐 관리자가 아니라, latency와 throughput, fairness와 memory budget 사이의 충돌을 매 step마다 조정하는 제어기입니다. 특히 continuous batching, chunked prefill, KV block pool, 멀티테넌트 우선순위가 결합된 현대 serving 엔진에서는 스케줄러의 판단이 곧 사용자 체감 성능과 GPU 활용률을 동시에 좌우합니다. 본 문서는 목표 지표, scheduling loop, 대표 정책, backpressure, 그리고 cluster-level 배치 관점에서 이 문제를 정리합니다.

또한 스케줄러는 독립된 큐가 아니라 router, runtime, memory manager와 맞물린 상태 기계에 가깝습니다. 어떤 요청을 지금 admit할지, 어떤 요청을 다음 token step으로 넘길지, 어떤 prefill을 chunk로 쪼갤지, 어떤 tenant를 먼저 보호할지까지 함께 결정해야 하므로, 실제 구현에서는 정책과 메모리 제어가 분리되지 않는 경우가 많습니다.

핵심 개념

• Admission control은 단순한 입장 허가가 아니라 KV budget과 active sequence budget을 함께 보는 메모리 게이트입니다.
• Batching policy는 prefill과 decode를 어떤 비율과 순서로 섞을지 정하는 규칙이며, utilization과 latency의 균형을 좌우합니다.
• Backpressure는 active decode, prefill burst, remote KV 지연이 상위 큐로 전파되는 현상이며, 운영 품질을 직접 흔듭니다.
• Fairness와 SLO는 priority, aging, deadline-like rule로 구현되는 경우가 많고, 멀티테넌트 환경에서는 필수 제약입니다.

1. 스케줄러는 무엇을 동시에 최적화하는가

추론 스케줄러는 TTFT, ITL, tail latency 같은 사용자 지표와 throughput, GPU utilization, KV 점유율 같은 시스템 지표를 동시에 본다는 점에서 단순 FCFS 큐와 다릅니다. 게다가 fairness, tenant priority, active sequence 상한 같은 운영 제약도 함께 만족시켜야 합니다.

즉 스케줄러는 '누구를 먼저 돌릴지'만 정하는 것이 아니라, 언제 admit할지, 어느 배치에 넣을지, prefill과 decode를 어떤 비율로 섞을지까지 포함한 제어 문제를 풀고 있습니다.

그림 1. latency, efficiency, policy, system reality를 동시에 맞추는 scheduler objective

2. 실제 동작은 ingest -> admit -> batch -> refill의 반복이다

요청은 ingress에서 tenant, 모델, SLO 정보를 가진 채 큐에 들어오고, admission gate는 KV budget과 active sequence budget을 보고 요청을 받아들일지 지연시킬지 결정합니다. 이후 runtime은 prefill 또는 decode 배치를 구성하고, step이 끝날 때마다 빈 slot을 다시 채웁니다.

중요한 점은 이 루프가 요청 단위가 아니라 token step 단위로 매우 자주 반복된다는 것입니다. 그래서 작은 정책 차이도 TTFT와 ITL, 심지어 tail latency에 크게 누적될 수 있습니다.

그림 2. ingest, admit, batch, refill로 이어지는 inference scheduler loop

Admission은 compute보다 memory 문제에 가깝다

현대 LLM serving에서는 admit 여부가 단순한 GPU slot 수보다 KV block pool과 prefix cache 상태에 더 강하게 좌우됩니다. 따라서 스케줄러는 실행기와 메모리 관리자를 분리해 볼 수 없습니다.

3. 대표 정책은 단순성, 효율, 우선순위 제어 사이의 선택이다

정적 배치나 FCFS는 구현이 단순하고 예측 가능하지만, 서로 다른 길이의 요청이 섞이면 GPU와 메모리 빈칸이 자주 생깁니다. 반대로 continuous batching은 utilization을 높이지만 fairness를 별도로 관리해야 하며, queue 상태 변화에 더 민감합니다.

우선순위 기반 또는 SLO-aware 정책은 급한 요청을 구제하는 데 유리하지만, 잘못 설계하면 낮은 우선순위 요청이 오래 밀릴 수 있습니다. 그래서 많은 시스템이 FCFS, priority, aging, deadline-like 요소를 절충해서 사용합니다.

비교/분석

그림 3. static batch, continuous batching, priority-aware policy의 비교

4. Queueing과 Backpressure는 운영 품질을 결정한다

active decode가 block pool을 거의 다 쓰면 신규 admit이 막히고, prefill burst가 과도하면 decode ITL이 흔들립니다. 여기에 remote KV나 네트워크 지연까지 겹치면 backpressure가 앞단 ingress까지 전파됩니다.

좋은 스케줄러는 단순히 큐를 비우는 것이 아니라, 어디에서 병목이 시작되는지 조기에 감지하고 hold, reject, reroute, chunk resize 같은 완충 전략을 적용합니다. 이 계층이 약하면 GPU는 바쁘게 보여도 사용자 경험은 급격히 나빠집니다.

그림 4. ingress queue, admission gate, active decode pool, prefill pool 사이의 backpressure 전파

5. 단일 노드가 아니라 클러스터 스케줄링으로 확장된다

멀티 GPU 또는 멀티 노드 serving에서는 front router가 모델/테넌트/affinity를 보고 요청을 분산하고, global scheduler가 placement와 policy를 결정한 뒤, 각 node runtime이 local continuous batching을 수행합니다. 즉 전역 정책과 로컬 정책이 계층적으로 나뉩니다.

특히 disaggregated serving이나 MoE serving처럼 네트워크와 remote state가 중요한 구조에서는 global scheduler가 node 혼잡도, KV locality, fabric 상태를 함께 봐야 합니다. 이때 스케줄러는 사실상 분산 시스템 제어기 역할을 하게 됩니다.

그림 5. front router, global scheduler, node runtime, execution resource로 이어지는 cluster-level scheduler stack

6. 장단점

장점은 scheduler가 단순 배치기보다 훨씬 정교하게 자원을 쓸 수 있다는 점입니다. continuous batching, chunked prefill, prefix cache, KV budget을 함께 보면 같은 GPU에서도 더 높은 utilization과 더 낮은 tail latency를 동시에 노릴 수 있습니다. 멀티테넌트 환경에서는 priority, aging, quota를 통해 특정 고객이나 서비스 등급을 보호하기도 쉽습니다.

반면 단점은 정책 복잡도가 빠르게 커진다는 점입니다. decode를 우대하면 긴 prefill이 밀리고, aggressive priority를 쓰면 starvation이 생기며, memory pressure를 보수적으로 잡으면 throughput이 떨어집니다. 분산 환경으로 갈수록 router, node runtime, remote KV store의 상태까지 엮이므로 원인 분석과 튜닝도 어려워집니다.

관련 기술

7. 핵심 정리

LLM inference scheduler의 본질은 batch를 예쁘게 만드는 것이 아니라, 제한된 memory와 compute 안에서 latency, throughput, fairness를 동시에 관리하는 온라인 제어 문제입니다. 그래서 좋은 정책은 이론적으로만 깔끔한 규칙보다, 실제 block pool과 queue dynamics를 잘 반영하는 규칙인 경우가 많습니다.

결국 scheduler는 serving 엔진의 주변 기능이 아니라 중심부입니다. continuous batching, prefix caching, remote KV, 멀티테넌트 정책까지 모두 스케줄러를 통해 현실적인 품질로 연결되기 때문입니다.