LLM 추론 스케줄링 '토큰 슬라이스' — 긴 요청 독점을 막는 청크 디코딩 실험

핵심 메시지

• LLM 요청은 응답이 얼마나 길어질지 미리 알 수 없어, 긴 요청이 디코더 자원을 오래 점유하면 짧은 요청이 대기열에서 굶는 문제가 생긴다.
• 토큰 슬라이스는 디코딩 결과를 고정 크기 청크로 잘라 '예측 가능한 작업 단위'를 만들고, 스케줄러가 응답 생성 도중에도 배치를 다시 조정할 수 있게 한다.
• 이 방식은 CPU 스케줄링의 시분할을 그대로 가져온 것이라, 컨텍스트 스위칭 비용이라는 단점도 함께 가져온다. 슬라이스 사이에 KV 캐시가 밀려나면 다시 계산해야 한다.
• 발표자들이 참여한 오픈소스 프로젝트는 요청을 어디로 보낼지 정할 때 부하 기반 라우팅과 프리픽스 캐시 기반 라우팅을 함께 저울질한다.
• 우선순위가 다른 여러 사용자를 다루는 또 다른 방법으로 '흐름 제어'가 있으며, 낮은 우선순위 배치 작업을 밀어내 높은 우선순위 요청에 자리를 내주는 방향으로 개발되고 있다.

쉽게 이해하기

챗봇이나 API 뒤에서 대형 언어 모델을 돌릴 때 가장 다루기 까다로운 성질 중 하나는, 요청이 들어온 시점에 그 요청이 얼마나 긴 답을 만들지 알 수 없다는 점이다. 발표자들은 이 불확실성이 여러 사용자가 한 서버를 공유하는 환경에서 특히 아프다고 설명한다. 응답이 긴 요청 몇 개가 쌓이면 디코더 자원을 차지해 버리고, 몇 토큰이면 끝날 짧은 요청들이 큐에서 기다리게 된다.

발표는 먼저 이 문제를 다루는 인프라 층을 소개한다. 여러 조직이 함께 만드는 오픈소스 추론 오케스트레이션 프로젝트로, 게이트웨이가 요청 본문을 스케줄러에 넘겨 어떤 모델 서버로 보낼지 판단하게 하는 구조다. 여기서 중요한 판단 기준 두 가지가 등장한다. 하나는 GPU 메모리와 큐 상태를 보고 부하를 고르게 퍼뜨리는 방식이고, 다른 하나는 이미 계산된 KV 캐시가 남아 있는 서버로 요청을 몰아주는 방식이다.

발표자는 이 둘이 서로 반대 방향으로 당긴다고 말한다. 캐시를 노린 라우팅은 요청을 한곳에 붙이려 하고, 부하 기반 라우팅은 흩뿌리려 한다. 벤치마크 사례에서는 캐시 지역성을 무시한 단순 라운드로빈이나 부하 기반 분배만으로는 하드웨어 여력이 충분한 상황에서도 목표 성능에 도달하지 못했고, 두 기준을 함께 고려했을 때 비로소 기대한 성능이 나왔다고 소개한다. 다만 수치 자체보다 'AI 워크로드는 KV 캐시라는 상태를 이해하는 스케줄링이 필요하다'는 점이 요지라고 덧붙인다.

본 주제인 토큰 슬라이스는 여기서 한 걸음 더 나아간다. 요청이 종료 토큰이 나올 때까지 무한정 디코더에 머무르게 두는 대신, 정해진 개수의 토큰을 하나의 '시간 조각'으로 삼아 디코딩을 잘라 내는 것이다. 그러면 스케줄러는 응답이 끝나기를 기다리지 않고 중간에 개입해 요청 배치를 다시 짤 수 있고, 앞선 요청이 뒤의 요청을 막아 세우는 상황을 줄일 수 있다. 잘라 낸 조각을 모아 완성된 응답으로 돌려주는 일은 별도 사이드카가 맡는다.

대가도 분명하다. 발표자는 이 방식이 운영 복잡도를 높이고, 무엇보다 컨텍스트 스위칭 비용을 감수해야 한다고 강조한다. 요청이 디코더를 계속 붙잡고 있을 때는 KV 캐시가 그대로 유지되지만, 조각 사이에 캐시가 밀려나면 다시 계산해야 하므로 오히려 손해가 될 수 있다. 그래서 현재는 실험적 기능으로 두고, 포화 상태가 아닌 환경에서 성능을 해치지 않는다는 점이 확인되어야 핵심 기능으로 옮기겠다는 입장이다.

발표의 뒷부분에서는 대안으로 '흐름 제어'가 소개된다. 요청 유입 자체를 조절하는 장치로, 디코드 워커가 과부하로 처리량이 무너지는 상황을 막고 우선순위별로 처리량을 다르게 배분한다. KV 캐시 사용률을 '얼마나 찼는가'를 나타내는 하나의 숫자로 환산해 오토스케일링과 유입 속도 결정에 쓰는 방식이다. 며칠이 걸려도 상관없는 배치 작업을 한산한 시간대에 밀어 넣었다가, 우선순위가 높은 실서비스 요청이 몰리면 밀어내는 형태의 기능도 개발 중이라고 밝힌다.

주요 인사이트

• LLM 서빙 문제의 상당 부분은 새로운 문제가 아니라 오래된 운영체제 문제의 재등장이다. 발표자들은 수십 년 된 CPU 스케줄링 지혜를 추론에 옮겨 온다고 표현했고, 실제로 선점·시분할·우선순위·기아 상태 같은 개념이 그대로 쓰인다.
• 다만 그대로 옮겨 오면 단점도 그대로 따라온다. 스레드 전환 비용에 해당하는 것이 여기서는 KV 캐시 재계산이며, 이 비용이 크면 공정성을 얻는 대신 전체 처리량을 잃는다.
• AI 인프라에서는 '상태를 모르는 로드밸런싱'이 성능을 무너뜨린다. 이미 계산된 캐시가 어디 있는지 모른 채 요청을 고르게 뿌리면, 하드웨어가 충분해도 같은 계산을 반복하게 된다.
• 같은 문제에 접근하는 설계가 하나일 필요는 없다. 응답을 잘게 자르는 토큰 슬라이스와, 유입 자체를 조절하고 낮은 우선순위 작업을 밀어내는 흐름 제어는 목적이 겹치며, 발표자들도 어느 쪽이 충분한지는 아직 결론이 나지 않았다고 말한다.

자주 묻는 질문

관련 AI 소식