배치 크기는 첫 토큰 및 토큰당 지연 시간에 어떤 영향을 미치나요?

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

더 큰 배치는 전체 토큰 처리량을 높이는 경우가 많지만, 큐 대기, 더 무거운 반복 작업, 메모리 압박으로 인해 첫 토큰 지연 시간과 토큰당 지연 시간이 늘어날 수 있습니다.

배치 크기가 1인 로컬 모델은 각 디코딩 단계에서 매우 적은 작업을 위해 모델 가중치를 이동하므로 가속기를 충분히 활용하지 못할 수 있습니다. 요청을 결합하면 이러한 이동 비용을 분산하고 처리량을 높일 수 있습니다. 그러나 요청은 실행 승인을 기다릴 수 있고, 긴 프리필이 디코딩을 차단할 수 있으며, 활성 시퀀스가 추가될 때마다 KV 캐시와 토큰 작업량이 늘어납니다. 따라서 최적의 배치는 처리량, 응답성, 지연 시간 목표 내의 굿풋 중 무엇을 목표로 하는지에 따라 달라집니다.

배칭은 요청 간에 모델 작업을 분산합니다

배치 행렬 연산은 여러 시퀀스의 토큰을 함께 처리하여 하드웨어 활용도를 높이고, 고정된 실행 시작 비용이나 가중치 전송 비용을 더 많은 유용한 작업에 분산합니다. 이러한 효과는 연산 능력, 메모리 대역폭, 캐시 용량 또는 스케줄링 오버헤드가 포화되기 전까지 가장 크게 나타납니다.

Orca의 반복 수준 스케줄링은 반복 수준의 스케줄링을 도입하여 디코딩 반복 사이에 완료된 시퀀스가 빠지고 새로운 작업이 참여할 수 있도록 합니다. 이를 통해 모든 요청이 정적 배치에서 가장 오래 걸리는 구성원을 기다려야 하는 상황을 피할 수 있습니다.

배치 크기는 설정된 최대값, 승인된 시퀀스 수 또는 한 번의 반복에서 처리되는 토큰 수를 의미할 수 있습니다. 연속 배칭에서는 이 값들이 서로 다르므로 성능 보고서에는 어떤 수량을 제어하고 관찰했는지 명시해야 합니다. 이러한 차이는 이후의 가정용 테스트에서도 계속 확인할 수 있습니다.

첫 토큰 지연 시간에는 큐 대기와 프리필이 포함됩니다

첫 토큰까지의 시간은 요청이 도착한 시점부터 시작하며, 스케줄러 대기, 프롬프트 프리필, 첫 디코딩 단계를 포함합니다. 배치를 구성하기 위해 기다리는 정책은 큐 대기 시간을 늘릴 수 있고, 긴 프롬프트를 승인하면 한 번의 반복을 점유하여 기존의 대화형 요청을 지연시킬 수 있습니다.

최근의 연속 배칭 비교 자료는 연속 배칭이 요청을 동적으로 승인하고 제거하는 방식과 공격적인 스케줄링이 처리량과 TTFT 사이에서 어떻게 절충하는지를 설명합니다. 이를 통해 배치 크기만으로는 첫 토큰 응답성을 예측할 수 없는 이유를 알 수 있습니다. 자동화가 다음 단계로 진행되기 전에 중간 결과를 확인할 수 있어야 합니다.

청크 단위 프리필은 긴 프롬프트와 디코딩 작업을 교차 처리할 수 있지만, 청크 크기라는 또 다른 절충 요소가 생깁니다. 작은 청크는 대화형 토큰을 보호하지만 스케줄링 오버헤드를 추가하고, 큰 청크는 프리필 효율을 높이는 대신 더 긴 차단 구간을 만듭니다. 이러한 경계는 현실적인 운영 조건에서 별도로 측정해야 합니다.

토큰당 지연 시간은 실행 중인 반복에 따라 달라집니다

디코딩 중에는 일반적으로 한 단계에서 활성 시퀀스마다 하나의 토큰이 생성됩니다. 시퀀스가 많아지면 배치가 커지고 각 반복의 소요 시간이 늘어날 수 있지만, 전체 초당 토큰 수는 증가할 수 있습니다. 서로 다른 컨텍스트 길이, 캐시 압박, 선점, 분산 동기화로 인해 편차도 발생합니다.

DistServe의 프리필-디코드 분리는 프리필과 디코드의 연산 특성과 서비스 목표가 서로 다르기 때문에 두 과정을 분리합니다. 이 설계는 전체 처리량 최적화가 TTFT 및 출력 토큰당 소요 시간과 충돌할 수 있는 이유를 보여줍니다. 여러 소스가 제한된 컨텍스트를 놓고 경쟁할 때 이러한 실질적인 영향이 나타납니다.

실패의 경계는 오프라인 처리량 차트에서 가장 큰 배치를 선택한 뒤 이를 대화형 홈 어시스턴트에 적용하는 것입니다. 큐 대기나 토큰 간 간격이 사용자 대상 목표를 위반한다면 가속기 활용률과 관계없이 명목상 처리량은 사용할 수 있는 굿풋이 아닙니다.

배치 굿풋 프런티어를 파악하세요

짧은 대화, 긴 RAG 프롬프트, 백그라운드 작업을 제어된 도착률로 재생합니다. 최대 시퀀스 수와 배치 토큰 한도를 변경하면서 TTFT 백분위수, 토큰 간 지연 시간, 종단 간 지연 시간, 프롬프트 및 출력 처리량, 큐 깊이, 캐시 사용량, 선점, 거부된 요청을 측정합니다.

연속 배칭 동작을 활용하여 설정된 한도와 각 반복에서 실제로 관찰되는 배치를 구분합니다. 프롬프트 및 출력 분포를 고정하고, 첫 토큰 및 토큰 간격 목표를 모두 충족하는 요청의 비율을 보고합니다.

초당 원시 토큰 수가 아니라 이러한 목표 안에서 완료되는 작업을 최대화하는 설정을 선택합니다. 백그라운드 배치가 대화형 굿풋을 낮추면 이를 격리하거나 우선순위를 낮추고, 모델, 양자화, 컨텍스트 구성 또는 스케줄러를 변경한 후 다시 테스트합니다.

기술 및 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.