[Paper] L4: Low-Latency 및 Load-Balanced LLM 서빙을 위한 Length-Aware Scheduling

발행: (2025년 12월 22일 오후 06:13 GMT+9)
7 min read
원문: arXiv

Source: arXiv - 2512.19179v1

개요

이 논문은 요청 길이를 인식함으로써 GPU에서 대형 언어 모델(LLM)을 서비스하는 속도를 크게 높이는 새로운 런타임 시스템 L4를 소개합니다. 최신 LLM은 100 k 토큰 이상의 컨텍스트 윈도우를 처리할 수 있기 때문에, 짧은 쿼리와 긴 쿼리를 같은 GPU 배치에 섞어 넣으면 연산이 낭비되고 지연 시간이 증가합니다. L4는 요청을 길이‑전문 인스턴스로 동적으로 라우팅하여 이질적인 워크로드를 원활한 파이프라인으로 전환합니다.

주요 기여

  • Length‑aware scheduling: 들어오는 요청의 토큰 길이에 따라 추론 인스턴스를 그룹화하여 인스턴스별 이질성을 감소시키는 새로운 스케줄러.
  • Dynamic programming partitioning: 전체 QoE(지연 시간 + 처리량)를 최대화하기 위해 길이‑전문화 단계의 최적 개수를 결정하는 효율적인 알고리즘.
  • Runtime range refinement & decentralized rebalancing: 중앙 병목 없이 그룹 간 및 각 그룹 내에서 길이 경계와 부하 분배를 지속적으로 조정하는 방법.
  • Comprehensive evaluation: 기존 최고 수준의 다중 인스턴스 스케줄러와 비교해 엔드‑투‑엔드 지연 시간 67 % 감소, 테일 지연 시간 69 % 감소, 처리량 2.89× 증가를 보여줍니다.

Methodology

  1. Instance Grouping – L4는 동일한 LLM의 여러 개의 동일한 GPU 인스턴스를 실행합니다. 각 인스턴스에는 길이 범위가 할당됩니다(예: 0‑2 k 토큰, 2‑8 k 토큰, …).
  2. Dynamic Partitioning – 가벼운 동적 프로그래밍(DP) 솔버를 사용하여, L4는 현재 요청 분포와 지연 시간 및 처리량의 균형을 맞추는 QoE 목표에 기반해 최적의 길이 범위 집합을 주기적으로 재계산합니다.
  3. Pipeline Flow – 요청이 도착하면 먼저 토큰 수와 가장 잘 맞는 범위 그룹에 배정됩니다. 요청이 증가하면(예: 후속 질문 때문에) 더 뒤 단계로 승격될 수 있어, 그룹 간에 자연스러운 파이프라인을 형성합니다.
  4. Load Balancing – 각 그룹 내에서는 분산형 로드 밸런서가 GPU 활용도를 모니터링하고 인스턴스 간에 요청을 이동시켜 핫스팟을 방지합니다. 그룹 간에는 L4가 길이 경계를 조정하여 각 그룹이 균등하게 작업하도록 유지합니다.
  5. Implementation – 표준 추론 엔진(예: vLLM) 위에 구축된 L4는 얇은 스케줄링 레이어만 추가하여 핵심 모델 실행을 그대로 유지합니다.

결과 및 발견

지표기준 (최첨단)L4
평균 종단 간 지연 시간1.2 s0.4 s (‑67 %)
99번째 백분위수 지연 시간2.8 s0.9 s (‑69 %)
처리량 (쿼리/초)120350 (×2.89)
GPU 활용도~55 %~92 %
  • 길이 이질성이 컨텍스트 윈도우가 ~32 k 토큰을 초과할 때 주요 병목 현상입니다.
  • 동적 파티셔닝은 작업 부하 변화(예: 긴 문서의 급증)에 몇 초 내에 적응하여 QoE를 안정적으로 유지합니다.
  • 분산형 재균형은 단일 장애 지점을 제거하고 수십 개의 GPU 인스턴스로 확장해도 눈에 띄는 오버헤드가 없습니다.

Practical Implications

  • Lower operational cost – Higher GPU utilization means fewer GPUs are needed to meet the same SLA, directly cutting cloud spend.
  • Better user experience – Faster response times, especially for long‑context queries (code generation, document summarization), improve perceived quality.
  • Simplified capacity planning – Operators can rely on L4’s self‑tuning to handle mixed workloads without manually sizing separate “short‑query” and “long‑query” clusters.
  • Plug‑and‑play integration – Since L4 sits on top of existing inference servers, teams can adopt it with minimal code changes, preserving existing model pipelines and monitoring tools.
  • Enables new services – Applications that were previously avoided due to latency (e.g., real‑time legal document analysis, multi‑turn chat with 100 k token context) become feasible.

제한 사항 및 향후 작업

  • 정적 모델 가중치 가정 – L4는 아직 실시간 모델 업데이트(예: LoRA 파인튜닝)와 같이 토큰당 연산 비용을 변경할 수 있는 상황을 처리하지 못합니다.
  • GPU 전용 초점 – 현재 설계는 동질적인 GPU 클러스터를 목표로 하며, 이기종 가속기(TPU, CPU)로 확장하는 것은 추후 과제로 남겨두었습니다.
  • 스케줄링 오버헤드 – 경량임에도 불구하고 DP 솔버와 범위 정제가 작은 고정 지연을 추가합니다; 향후 작업에서는 완전 비동기식 또는 학습 기반 스케줄러를 탐색할 수 있습니다.
  • 보안 및 격리 – 다중 테넌트 시나리오에서는 요청 간 간섭을 방지하기 위한 추가 샌드박스가 필요할 수 있으며, 이는 L4가 기본적으로 제공하지 않습니다.

핵심: L4는 적당한 길이 인식 스케줄링 레이어가 LLM 서비스에 있어 획기적인 성능 향상을 가능하게 함을 보여주며, 대규모 컨텍스트 애플리케이션을 개발자와 기업 모두에게 더 저렴하고 반응성이 높게 만듭니다.

저자

  • Yitao Yuan
  • Chenqi Zhao
  • Bohan Zhao
  • Zane Cao
  • Yongchao He
  • Wenfei Wu

논문 정보

  • arXiv ID: 2512.19179v1
  • 분류: cs.DC
  • 출판일: 2025년 12월 22일
  • PDF: PDF 다운로드
Back to Blog

관련 글

더 보기 »