홈 AI 배칭은 지연 시간과 처리량을 어떻게 절충하나요?

홈 AI 배칭은 호환되는 작업을 결합해 전체 처리량을 높이지만, 각 요청이 더 오래 대기하거나 다른 사용자와 더 느린 반복 단계를 공유할 수 있습니다.

단일 프롬프트는 유휴 가속기에 즉시 들어갈 수 있지만, 가족용 서버에는 여러 채팅, 문서 프롬프트, 음성 요청, 백그라운드 작업이 겹쳐서 들어오는 경우가 많습니다. 런타임은 배치를 구성하기 위해 요청을 잠시 보류하거나, 디코드 반복 단계 사이에 새 시퀀스를 추가하거나, 긴 프리필을 더 작은 청크로 나눌 수 있습니다. 이러한 선택은 가속기를 더 높은 효율로 활용하게 해 주지만, 첫 토큰까지 걸리는 시간, 토큰 간 지연 시간, 공정성에도 영향을 줍니다. 아래에서는 배칭이 어떤 상황에서 도움이 되며, 처리량 향상이 대화형 경험 개선으로 이어지지 않는 시점은 언제인지 설명합니다.

배칭은 남는 가속기 용량을 공유 작업으로 전환합니다

특히 작은 행렬 연산이나 짧은 시퀀스를 처리할 때는 하나의 요청이 모든 병렬 실행 레인을 효율적으로 사용하지 못할 수 있습니다. 여러 요청을 결합하면 더 큰 텐서 연산을 구성할 수 있어 가속기를 더욱 효과적으로 활용할 수 있습니다.

Orca는 반복 단계 수준 스케줄링을 도입했습니다. 이를 통해 모든 시퀀스가 끝날 때까지 하나의 고정 배치를 유지하도록 강제하는 대신, 생성 반복 단계 사이에 요청이 들어오고 나갈 수 있습니다.

향상 폭은 단위 시간당 완료된 토큰 또는 요청 수로 측정합니다. 이는 특정 사용자가 토큰을 더 빨리 받는다는 것을 보장하지는 않습니다.

배치 윈도우는 연산 시작 전에 대기 시간을 추가합니다

더 많은 요청을 기다리는 런타임은 더 크고 효율적인 배치를 구성할 수 있지만, 가속기를 사용할 수 있는 상태였더라도 가장 먼저 들어온 요청은 그 대기 시간을 감수해야 합니다.

처리량과 지연 시간 간 트레이드오프는 더 큰 배치가 장치 효율을 높이는 동시에 대기 시간이나 반복 단계 시간을 늘릴 때 뚜렷하게 나타납니다.

대화형 홈 AI에는 일반적으로 짧거나 적응형인 배치 윈도우가 필요합니다. 백그라운드 임베딩 작업은 대화 응답보다 완료된 작업량이 목표이므로 더 긴 대기 시간을 감수할 수 있습니다.

긴 프리필은 짧은 디코드 작업을 지연시킬 수 있습니다

프롬프트 처리는 연산량이 큰 대규모 프리필을 수행하는 반면, 활성 대화는 메모리 대역폭에 영향을 많이 받는 디코드 단계를 반복적으로 요청합니다. 이들을 하나의 배치에 섞으면 짧은 대화형 디코드 작업이 긴 문서 프롬프트 뒤에서 기다리게 될 수 있습니다.

DistServe는 두 단계의 리소스 및 지연 시간 특성이 서로 다르기 때문에 프리필과 디코드 간 간섭을 분리합니다.

청크 단위 프리필은 긴 프롬프트를 나누어 디코드 요청이 청크 사이에서 실행될 수 있도록 하는 절충안입니다. 다만 문서 처리가 완료되기까지 더 많은 스케줄링 라운드가 필요합니다.

최적의 설정은 서버가 하나의 긴 분석 작업을 우선하는지, 아니면 이미 스트리밍 답변을 받고 있는 여러 사용자를 우선하는지에 따라 달라집니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

서로 다른 시퀀스 길이는 모든 배치를 고르지 않게 만듭니다

요청마다 프롬프트 길이, 출력 길이, 중지 조건, 모델 기능이 다릅니다. 어떤 요청은 빠르게 끝나는 반면 다른 요청은 계속 활성 상태로 남기 때문에 배치 구성이 지속적으로 변합니다.

vLLM은 페이지형 KV 캐시와 함께 연속 배칭을 사용합니다. 고정된 배치 경계까지 기다리는 대신 용량이 확보되는 대로 새 요청을 추가할 수 있습니다.

효율적인 메모리 관리가 적용되더라도 매우 긴 응답 하나가 여러 반복 단계에 걸쳐 디코드 슬롯과 KV 캐시를 점유할 수 있습니다. 따라서 배치 크기는 요청 수만이 아니라 토큰 및 메모리 예산으로 표현해야 합니다.

더 큰 배치는 사용자별 토큰 처리율을 낮출 수 있습니다

초당 총 토큰 수는 증가하더라도 각 사용자가 받는 디코드 반복 단계의 비중은 줄어들 수 있습니다. 집계 처리량이 높아졌다는 대시보드 수치와 실제 스트리밍 속도 저하는 동시에 나타날 수 있습니다.

ZimaSpace의 가족 동시성 가이드는 한 명의 사용자만 대상으로 한 벤치마크가 여러 대화가 겹치는 상황의 지연 시간을 예측하지 못하는 이유를 설명합니다.

집계 처리량과 함께 첫 토큰까지 걸리는 시간, 토큰 간 시간, 요청별 완료 시간도 측정하세요. 그렇지 않으면 사용자가 직접 체감하지 못하는 지표에 맞춰 배칭을 조정하게 될 수 있습니다.

대화형 작업과 백그라운드 작업에 서로 다른 배치 정책을 설정하세요

음성 및 채팅에는 짧은 대기 윈도우, 제한된 동시성, 높은 우선순위를 할당하세요. 임베딩, 인덱싱, 요약, 오프라인 변환 작업에는 더 큰 배치와 낮은 우선순위를 허용해 유휴 용량을 활용하도록 하세요.

공정한 LLM 서빙 연구에서는 토큰 인식 공정성을 사용합니다. 이를 통해 한 요청의 긴 입력이나 출력이 불균형적으로 많은 리소스를 무기한 점유하지 않도록 합니다.

최대 배치 크기뿐 아니라 실제 가족 사용량을 대표하는 부하에서 테스트하세요. 유용한 설정은 대화형 경로의 첫 토큰 및 스트리밍 지연 시간 목표를 충족하면서 가장 높은 처리량을 제공하는 구성입니다.

하나의 가속기로 두 작업 유형을 모두 처리할 수 없다면, 하나의 보편적인 배칭 정책보다 작업자나 스케줄을 분리하는 편이 더 간단할 수 있습니다.

FAQ

배칭은 항상 지연 시간을 늘리나요?

아니요. 효율적인 배칭은 전체 대기열 처리 시간을 줄이고 과부하를 방지할 수 있지만, 배치를 기다리거나 더 긴 반복 단계를 공유하면 개별 요청의 지연 시간이 늘어날 수 있습니다.

배치 크기는 사용자 수를 의미하나요?

정확히는 그렇지 않습니다. 런타임은 활성 시퀀스, 토큰, KV 블록 또는 전체 작업량을 기준으로 예산을 설정할 수 있으며, 한 사용자가 여러 요청을 동시에 생성할 수도 있습니다.

음성 요청을 임베딩 작업과 함께 배칭해야 하나요?

일반적으로 동일한 지연 시간 정책으로 처리해서는 안 됩니다. 음성은 대화형 작업인 반면, 임베딩 작업은 대기할 수 있고 유휴 용량이 있을 때 더 큰 배치를 사용할 수 있습니다.