가속기 스케줄링은 다중 사용자 홈 AI에 어떤 영향을 미치나요?

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

가속기 스케줄링은 어떤 요청을 시작하고, 각 반복 단계에서 어떤 요청을 함께 처리하며, 메모리 상태를 유지하거나 다른 작업 뒤에서 대기할지를 결정함으로써 여러 사용자가 함께 사용하는 홈 AI에 영향을 줍니다.

한 가정의 여러 사용자는 처리 비용이 크게 다른 프롬프트를 보낼 수 있습니다. 짧은 조명 제어 질문, 긴 문서, 이미지, 음성 요청, 또는 수많은 호출을 생성하는 에이전트가 그 예입니다. 가속기는 도착 시간만으로 가정 내 작업의 중요도를 판단할 수 없습니다. 출력 길이를 예측하기 어려운 상황에서 스케줄러는 대기열 순서, 토큰 예산, 배칭, 우선순위, 메모리 할당, 모델 상주 상태를 함께 고려해야 합니다. 아래에서는 이러한 선택에 따라 동일한 하드웨어가 공정하고 빠르게 느껴질 수도, 사용할 수 없을 정도로 느려질 수도 있는 이유를 설명합니다.

FIFO는 도착 시간만을 우선순위로 취급합니다

선입선출(FIFO) 대기열은 단순하지만, 긴 프롬프트나 응답 하나가 나중에 도착한 여러 짧은 요청을 지연시킬 수 있습니다.

LLM 요청은 토큰 비용이 서로 다르므로, 요청 수만을 기준으로 공정성을 판단하면 한 사용자가 다른 사용자보다 훨씬 더 많은 가속기 시간을 사용할 수 있습니다.

부하가 낮을 때 FIFO는 예측 가능하지만, 가정 내 작업이 다양해지면 선두 차단(head-of-line blocking)이 발생합니다.

연속 배칭은 사용자 간 반복 단계를 공유합니다

반복 단계 수준의 스케줄러는 디코드 단계 사이에 새 시퀀스를 추가하고, 고정된 하나의 배치를 다시 구성하지 않고도 완료된 시퀀스를 제거할 수 있습니다.

Orca의 반복 단계 스케줄링은 활용도를 높이는 동시에 여러 사용자가 함께 진행할 수 있도록 합니다.

작업을 공유한다고 해서 속도가 동일해지는 것은 아닙니다. 스케줄러는 여전히 몇 개의 시퀀스를 진입시킬지, 각 시퀀스를 얼마나 자주 진행할지, 새 프리필이 진행 중인 디코드를 중단할지 결정해야 합니다.

우선순위 정책은 지연 시간에 민감한 요청을 보호합니다

음성 제어와 짧은 대화형 채팅은 백그라운드 요약, 임베딩 또는 이미지 생성보다 더 빠르게 처리되어야 할 수 있습니다.

Llumnix는 서로 다른 LLM 요청을 위한 지연 시간 우선순위를 다룹니다.

백그라운드 작업도 결국 실행되도록 우선순위에 에이징이나 할당량을 포함해야 하며, 선호되는 한 사용자가 가정 내 다른 사용자들의 작업을 무기한 굶주리게 해서는 안 됩니다.

-15% OFF

메모리 할당은 연산 시작 전에 요청을 차단할 수 있습니다

요청에는 모델 가중치 외에도 KV 캐시와 작업 공간이 필요합니다. 연산 장치가 유휴 상태로 보이더라도 메모리 여유 공간이 부족하면 스케줄러가 요청 수락을 지연시킬 수 있습니다.

ZimaSpace의 다중 사용자 메모리 압박 가이드는 컨텍스트가 길어질수록 동시에 활성 상태로 유지할 수 있는 대화 수가 줄어드는 이유를 설명합니다.

시퀀스를 선점하면 용량을 확보할 수 있지만, 나중에 해당 상태를 다시 계산하거나 복원해야 할 수 있어 메모리 정책이 추가 지연 시간으로 이어집니다.

프리필과 디코드는 서로 다르게 스케줄링해야 합니다

긴 프리필은 연산을 많이 사용하는 반면, 토큰 디코드는 가중치와 캐시 상태를 반복해서 읽습니다. 이를 제어 없이 함께 실행하면 스트리밍 출력이 멈출 수 있습니다.

Sarathi-Serve는 멈춤 없는 스케줄링과 청크 단위 프리필을 사용해 처리량을 높이면서 지연 시간에 미치는 영향을 제한합니다.

홈 스케줄러는 활성 대화에 디코드 기회를 우선 배정하고, 한 요청이 긴 반복 단계를 독점하지 않도록 대용량 문서 프리필을 여러 부분으로 나눌 수 있습니다.

공정성은 사용자가 체감하는 기준으로 측정해야 합니다

초당 총 토큰 수는 향상되었지만 한 사용자가 다른 사용자보다 훨씬 오래 기다릴 수 있습니다. 사용자 또는 작업 등급별로 대기 시간, 첫 토큰까지의 시간, 토큰 간 지연 시간, 완료 시간, 서비스 점유율을 추적해야 합니다.

Virtual Token Counter는 모든 요청을 동일하게 세는 대신 토큰 인식 공정성을 정의합니다.

음성, 대화형 채팅, 에이전트, 임베딩, 유지 관리 작업에 대해 명시적인 등급을 사용하세요. 그런 다음 길고 짧은 요청이 겹치는 상황을 테스트해 선택한 정책이 가정 내 기대에 부합하는지 확인하세요.

스케줄링으로 가속기 용량 자체를 늘릴 수는 없지만, 부족한 용량이 공정한 속도 저하로 나타날지, 꼬리 지연 시간이 급증하는 형태로 나타날지, 아니면 한 사용자가 모두를 막는 형태로 나타날지는 결정할 수 있습니다.

기술 및 AI 허브

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.