연속 배칭은 홈 AI 서버의 공정성에 어떤 영향을 미칠까요?

연속 배칭은 활성 배치를 보충해 사용률을 높이지만, 공정성은 시간이 지남에 따라 사용자가 입장 허가, 토큰 서비스, 메모리를 어떻게 배분받는지에 달려 있습니다.

가정용 AI 서버는 모든 시퀀스가 함께 완료될 때까지 기다리지 않고 여러 대화를 결합할 수 있습니다. 완료된 요청은 빠져나가고 새 요청이 들어오며, 활성 사용자는 반복되는 추론 반복 단계에서 자원을 공유합니다. 이를 통해 처리량은 높아지지만 요청은 서로 같지 않습니다. 한 사용자는 짧은 명령을 제출하고, 다른 사용자는 긴 문서를 제출하며, 또 다른 사용자는 수백 개의 토큰을 생성하는 에이전트를 실행할 수 있습니다. 공정한 스케줄러는 어떤 작업 단위를 기준으로 삼을지, 새 요청을 어떻게 진입시킬지, 예측하기 어려운 출력 길이와 우선순위를 어떻게 조정할지를 결정해야 합니다.

연속 배칭은 스케줄링 단위를 고정 배치에서 반복 단계로 바꿉니다

정적 배칭은 그룹이 완료될 때까지 하나의 그룹을 함께 유지하므로, 짧은 요청이 먼저 끝나면 용량이 낭비됩니다. 연속 배칭은 생성 반복 단계 사이에 비어 있는 슬롯을 다시 채울 수 있습니다.

Orca는 요청의 시퀀스 상태가 바뀔 때 요청이 들어오고 나갈 수 있도록 반복 단계 수준 스케줄링을 도입했습니다.

이는 사용률을 높이지만, 사용자가 나눌 수 없는 하나의 요청 슬롯을 받는 대신 다음 반복 단계에 들어갈 자리를 계속 두고 경쟁해야 한다는 의미이기도 합니다.

입장 순서는 누가 서비스 누적을 시작할지 결정합니다

활성 배치 밖에 있는 요청은 모델의 진행을 전혀 받지 못합니다. 스케줄러는 도착 시간, 예상 길이, 우선순위, 사용 가능한 KV 블록 또는 공정성 카운터를 기준으로 요청을 허용할 수 있습니다.

vLLM은 시퀀스가 커질 때 메모리를 할당할 수 있도록 페이지 단위 KV 캐시 관리와 연속 입장 처리를 결합합니다.

선착순 방식은 간단하지만, 긴 요청이 쌓인 대기열은 나중에 들어온 짧은 가정용 명령이 빠르게 완료될 수 있는데도 지연시킬 수 있습니다.

요청을 동일하게 세면 가속기 서비스는 불균등해질 수 있습니다

5개 토큰으로 된 답변과 500개 토큰으로 된 답변은 모두 하나의 요청이지만, 차지하는 디코드 반복 단계 수는 크게 다릅니다. 프롬프트 길이에 따라서도 필요한 프리필 작업량이 달라집니다.

Virtual Token Counter는 요청 수만으로는 서로 다른 LLM 워크로드가 소비한 서비스를 나타낼 수 없기 때문에 토큰 기반 공정성을 정의합니다.

가정용 정책은 공정성이 동일한 토큰 작업량, 동일한 대기 시간, 동일한 완료 기회, 또는 지연 시간에 민감한 작업에 대한 우선권을 의미하는지 결정해야 합니다.

모든 워크로드를 만족하는 단일 지표는 없습니다. 음성 명령과 백그라운드 요약이 반드시 동일한 대우를 받아야 하는 것은 아닙니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

알 수 없는 출력 길이 때문에 향후 서비스를 예측하기 어렵습니다

스케줄러는 입장 시점에 프롬프트 크기를 알지만, 모델이 정확히 몇 개의 출력 토큰을 생성할지는 대개 알 수 없습니다. 하나의 요청이 예상보다 훨씬 오래 활성 상태로 남을 수 있습니다.

공정성 연구에서는 예측하기 어려운 요청 길이를 LLM 서빙의 독특한 과제로 강조합니다.

실제로 처리된 토큰을 기준으로 서비스 비용을 부과하면 부정확한 길이 추정에 전적으로 의존하지 않아도 되지만, 긴 요청이 여러 반복 단계 동안 메모리를 점유하는 문제는 여전히 발생할 수 있습니다.

대규모 프리필은 이미 토큰을 받고 있는 사용자를 방해할 수 있습니다

여러 사용자가 디코드 중일 때 새 문서 프롬프트가 들어올 수 있습니다. 이 프롬프트의 계산량이 큰 프리필 때문에 활성 대화가 기다려야 하는 반복 단계 시간이 길어질 수 있습니다.

Sarathi-Serve는 대규모 프리필을 분할하고 진행 중인 디코드의 지연 시간에 미치는 영향을 줄이기 위해 정체 없는 스케줄링을 사용합니다.

디코드 토큰만 계산하는 스케줄러는 한 사용자가 대규모 프리필을 반복적으로 도입해 모든 사용자의 스트리밍 출력을 지연시키는 경우에도 불공정할 수 있습니다.

따라서 공정한 계산에는 생성된 토큰뿐 아니라 입력 처리도 포함되어야 합니다.

계산이 포화되기 전에 메모리 압박이 공정성 문제를 일으킬 수 있습니다

모든 활성 대화에는 KV 캐시가 필요하며, 더 긴 컨텍스트는 더 많은 블록을 소비합니다. 하나의 큰 컨텍스트를 사용하는 사용자는 활성 배치에 들어갈 수 있는 다른 요청의 수를 줄일 수 있습니다.

ZimaSpace의 다중 사용자 분석은 가정 내 동시성을 공유 모델 메모리 및 스케줄러 결정과 연결합니다.

요청을 선점하거나 스왑하면 용량을 회복할 수 있지만, 중단된 사용자는 이후 재계산, 캐시 재로드 또는 더 긴 완료 시간을 부담할 수 있습니다.

따라서 메모리 입장 처리와 계산 스케줄링은 서로 무관한 제한으로 작동하지 않고 동일한 공정성 정책을 따라야 합니다.

우선순위에는 에이징, 할당량, 사용자에게 보이는 측정 지표가 필요합니다

음성 제어, 접근성 도구, 짧은 대화형 채팅은 임베딩이나 야간 요약보다 높은 우선순위를 받을 수 있습니다. 하지만 순수한 우선순위 스케줄링은 낮은 우선순위 작업을 굶길 수 있습니다.

Llumnix는 서빙 조건이 변함에 따라 요청 배치와 리소스 결정을 조정하기 위해 동적 스케줄링을 사용합니다.

에이징, 사용자별 할당량, 최대 컨텍스트 또는 출력 제한, 예약된 백그라운드 할당량을 추가하면 우선 작업이 빠르게 응답하면서도 다른 작업을 무기한 차단하지 않도록 할 수 있습니다.

사용자 또는 워크로드 등급별로 대기 시간, 첫 토큰까지의 시간, 토큰 간 지연 시간, 완료 시간, 제공된 토큰 수, 선점 횟수를 측정하세요. 연속 배칭은 초당 총 토큰 수가 높을 때가 아니라, 관찰된 분포가 가정용 정책과 일치할 때 공정합니다.