동적 배치

동적 배치 (Batchers / Dynamic Batching)

동적 배처 (Dynamic Batcher)

동적 배치는 서버가 추론 요청들을 합쳐서 배치를 동적으로 만들어내는 Triton의 기능이에요. 요청을 배치로 만들면 보통 처리량이 올라가요. 동적 배처는 stateless 모델에 사용해야 해요. 동적으로 만들어진 배치는 해당 모델에 구성된 모든 모델 인스턴스에 분배돼요.

동적 배치는 모델 구성의 ModelDynamicBatching 속성으로 모델별로 독립적으로 켜고 설정해요. 이 설정들은 동적으로 만들어지는 배치의 선호 크기, 다른 요청이 동적 배치에 합류하도록 요청이 스케줄러에서 지연될 수 있는 최대 시간, 그리고 큐 크기·우선순위·타임아웃 같은 큐 속성을 제어해요. 동적 배치에 대한 더 자세한 예제는 이 가이드를 참고하세요.

권장 구성 절차 (Recommended Configuration Process)

개별 설정들은 아래에서 자세히 설명할게요. 아래 단계는 각 모델에 대해 동적 배처를 튜닝할 때 권장하는 절차예요. Model Analyzer로 서로 다른 동적 배처 구성을 자동으로 탐색할 수도 있어요.

• 모델의 최대 배치 크기를 정하세요.

• 모델 구성에 다음을 추가해 동적 배처를 모든 기본 설정으로 켜세요. 기본적으로 동적 배처는 최대 배치 크기까지 최대한 큰 배치를 만들고, 배치를 구성할 때 지연시키지 않아요.

  dynamic_batching { }

• Performance Analyzer로 기본 동적 배처 구성이 주는 지연 시간과 처리량을 측정하세요.

• 기본 구성의 지연 시간이 지연 예산 안에 들어오면, 다음 중 하나 또는 둘 다 시도해서 지연 시간 증가와 처리량 증가를 맞바꿔 보세요:

  • 최대 배치 크기를 늘린다.

  • 배치 지연을 0이 아닌 값으로 설정한다. 지연 예산을 넘을 때까지 delay 값을 늘려가며 처리량 변화를 확인해 보세요.

• 선호 배치 크기는 대부분의 모델에 쓰지 말아야 해요. 선호 배치 크기는 해당 배치 크기가 다른 배치 크기보다 현저히 높은 성능을 낼 때만 구성해야 해요.

선호 배치 크기 (Preferred Batch Sizes)

preferred_batch_size 속성은 동적 배처가 만들려고 시도할 배치 크기를 나타내요. 대부분의 모델에서는 권장 구성 절차에서 설명한 것처럼 preferred_batch_size를 지정하지 말아야 해요. 예외는 서로 다른 배치 크기에 여러 최적화 프로파일을 지정하는 TensorRT 모델이에요. 이 경우 일부 최적화 프로파일이 다른 것보다 성능 개선이 훨씬 클 수 있으므로, 그 고성능 최적화 프로파일이 지원하는 배치 크기에 preferred_batch_size를 쓰는 게 합리적일 수 있어요.

다음 예제는 선호 배치 크기 4와 8로 동적 배치를 켜는 구성이에요.

  dynamic_batching {
    preferred_batch_size: [ 4, 8 ]
  }

모델 인스턴스가 추론을 받을 수 있게 되면, 동적 배처는 스케줄러에 쌓여 있는 요청들로 배치를 만들려고 시도해요. 요청은 받은 순서대로 배치에 추가돼요. 동적 배처가 선호 크기의 배치를 만들 수 있으면 가능한 가장 큰 선호 크기의 배치를 만들어 추론에 보내요. 선호 크기의 배치를 만들 수 없으면(또는 선호 배치 크기가 구성되지 않았으면), 모델이 허용하는 최대 배치 크기보다 작으면서 가능한 가장 큰 배치를 보내요(이 동작을 바꾸는 지연 옵션은 다음 섹션 참고).

생성된 배치의 크기는 count 메트릭으로 집계해 확인할 수 있어요.

배치 지연 (Delayed Batching)

동적 배처는 다른 요청이 동적 배치에 합류하도록 요청을 스케줄러에서 제한된 시간 동안 지연시키도록 구성할 수 있어요. 예를 들어 다음 구성은 요청의 최대 지연 시간을 100 마이크로초로 설정해요.

  dynamic_batching {
    max_queue_delay_microseconds: 100
  }

max_queue_delay_microseconds 속성 설정은 최대(또는 선호) 크기 배치를 만들 수 없을 때 동적 배처 동작을 바꿔요. 가용한 요청으로 최대 또는 선호 크기 배치를 만들 수 없으면, 동적 배처는 어떤 요청도 설정된 max_queue_delay_microseconds 값보다 오래 지연되지 않는 한 배치 전송을 지연시켜요. 이 지연 동안 새 요청이 도착해서 최대 또는 선호 배치 크기의 배치를 만들 수 있게 되면 즉시 그 배치를 추론으로 보내요. 지연이 만료되면 동적 배처는 최대·선호 크기가 아니어도 그 배치를 있는 그대로 보내요.

순서 보존 (Preserve Ordering)

preserve_ordering 속성은 모든 응답이 요청을 받은 순서와 같은 순서로 반환되도록 강제해요. 자세한 내용은 protobuf 문서를 참고하세요.

우선순위 레벨 (Priority Levels)

기본적으로 동적 배처는 모델의 모든 추론 요청을 담는 단일 큐를 유지해요. 요청들은 순서대로 처리되고 배치돼요. priority_levels 속성으로 동적 배처 안에 여러 우선순위 레벨을 만들어서 더 높은 우선순위의 요청이 더 낮은 우선순위의 요청을 앞지를 수 있게 해요. 같은 우선순위 레벨의 요청은 순서대로 처리돼요. 우선순위를 설정하지 않은 추론 요청은 default_priority_level 속성으로 스케줄링돼요.

큐 정책 (Queue Policy)

동적 배처는 요청이 배치를 위해 어떻게 큐에 쌓이는지 제어하는 여러 설정을 제공해요.

priority_levels가 정의되지 않으면 단일 큐의 ModelQueuePolicy를 default_queue_policy로 설정할 수 있어요. priority_levels가 정의되면 각 우선순위 레벨이 default_queue_policy와 priority_queue_policy로 지정된 서로 다른 ModelQueuePolicy를 가질 수 있어요.

ModelQueuePolicy 속성은 max_queue_size로 최대 큐 크기를 설정할 수 있게 해줘요. timeout_action, default_timeout_microseconds, allow_timeout_override 설정을 쓰면 큐에 머문 시간이 지정된 타임아웃을 넘는 개별 요청을 거부하거나 지연시키도록 큐를 구성할 수 있어요.

커스텀 배치 (Custom Batching)

동적 배처의 지정된 동작 위에 덧붙여서 동작하는 커스텀 배치 규칙을 설정할 수 있어요. 그러려면 tritonbackend.h에 정의된 함수 다섯 개를 구현하고 공유 라이브러리를 만들어야 해요. 함수들은 아래와 같아요.

공유 라이브러리 경로는 TRITON_BATCH_STRATEGY_PATH 파라미터로 모델 구성에 전달할 수 있어요. 제공하지 않으면 동적 배처는 모델 버전, 모델, 백엔드 디렉토리 순서대로 batchstrategy.so라는 이름의 커스텀 배치 전략을 찾아요. 발견하면 로드해요. 이렇게 하면 같은 백엔드를 쓰는 모든 모델이 커스텀 배치 전략을 쉽게 공유할 수 있어요.

커스텀 배치 라이브러리를 만들고 쓰는 튜토리얼은 backend examples 디렉토리를 참고하세요.

시퀀스 배처 (Sequence Batcher)

동적 배처와 마찬가지로 시퀀스 배처도 비배치 추론 요청을 합쳐서 배치를 동적으로 만들어요. 동적 배처와 달리 시퀀스 배처는 **일련의 추론 요청들을 같은 모델 인스턴스로 라우팅해야 하는 stateful 모델**에 사용해야 해요. 동적으로 만들어진 배치는 모델에 구성된 모든 모델 인스턴스에 분배돼요.

시퀀스 배치는 모델 구성의 ModelSequenceBatching 속성으로 모델별로 독립적으로 켜고 설정해요. 이 설정들은 시퀀스 타임아웃과, 시퀀스 시작·끝·준비·상관 ID를 나타내는 제어 신호를 모델에 어떻게 보낼지 구성해요. 자세한 내용과 예제는 Stateful Models를 참고하세요.

반복 시퀀스 (Iterative Sequences)

[!NOTE] 반복 시퀀스는 잠정(provisional) 기능이라 향후 버전에서 바뀔 수 있어요. 시퀀스 배처는 단일 요청을 여러 스케줄링 반복에 걸쳐 처리하는 "반복 시퀀스"의 stateful 실행을 지원해요. "반복 시퀀스"는 스케줄러가 각 단계에서 여러 in-flight 요청을 배치할 수 있게 하고, 모델 또는 백엔드가 아무 반복에서 요청을 완료할 수 있게 해줘요.

"반복 시퀀스"를 지원하는 모델·백엔드에서는 시퀀스 배처에서 다음과 같이 지정해 지원을 켤 수 있어요:

  sequence_batching {
    iterative_sequence: true
  }

"반복 시퀀스"는 완전한 응답이 생성될 때까지 단일 요청을 반복적으로 처리하는 stateful 모델을 말해요. 반복 시퀀스가 켜지면 시퀀스 스케줄러는 시퀀스를 시작하기 위한 단일 들어오는 요청을 기대해요. 반복 시퀀스를 지원하는 백엔드는 시퀀스 배처로 제어를 돌려주어(yield) 요청을 추후 배치에서 더 실행되도록 재스케줄할 수 있어요.

"반복 시퀀스"는 요청 하나로 표현되므로, 이전 섹션에서 언급한 제어 입력을 설정할 필요가 없어요. 스케줄러가 내부적으로 채워줘요.

"반복 시퀀스"는 decoupled일 수 있어서 실행 중 하나보다 많은 응답을 생성할 수 있고, 또는 non-decoupled여서 전체 응답이 완료될 때 단일 응답이 생성될 수도 있어요.

"반복 시퀀스"의 주요 장점은 백엔드에서 추가 상태를 유지하지 않고도 Triton의 네이티브 배치 기능으로 서로 다른 반복 단계의 요청들을 배치로 만들 수 있다는 거예요. 일반적으로 백엔드가 실행하는 배치는 같은 실행에서 완료되는데, 배치 안의 요청 하나의 실행이 나머지보다 훨씬 오래 걸리면 자원을 낭비할 수 있어요. "반복 시퀀스"를 쓰면 배치 안 각 요청의 처리를 여러 반복으로 쪼갤 수 있고, 어떤 요청이 완료되는 즉시 백엔드가 새 요청 처리를 시작할 수 있어요.

반복 시퀀스로 연속/인플라이트 배치 (Continuous/Inflight Batching)

연속 배치(continuous batching), 반복 레벨 배치(iteration level batching), 인플라이트 배치(inflight batching)는 LLM 추론에서 각 반복 단계마다 요청 배치를 구성하는 배치 전략을 설명하는 용어예요. 배치를 "연속적으로" 구성하면 추론 서버는 배치 안의 모든 요청이 끝나는 걸 기다리지 않고 배치 슬롯이 비는 즉시 재사용해서 처리량을 올릴 수 있어요.

요청을 처리하는 데 필요한 단계 수가 크게 달라질 수 있으므로, 기존 요청과 새 요청을 연속적으로 배치하면 처리량과 지연 시간 모두에 상당한 개선을 가져올 수 있어요.

반복 시퀀스로 인플라이트 배치를 얻으려면 백엔드가 요청 처리를 여러 단계로 쪼개야 해요. 각 단계는 Triton 모델 인스턴스 실행 하나에 해당해요. 각 단계가 끝나면 모델 인스턴스는 완료된 요청을 해제하고 아직 in-flight인 요청을 재스케줄해요. 그러면 Triton이 새 요청과 재스케줄된 요청을 섞은 다음 배치를 구성하고 스케줄링해요.

더 알아보기 (Learn more)

• 최적화 (Optimization) — 동적 배치를 활용한 성능 개선 사례
• 스케줄러 (Schedulers) — 기본·앙상블 스케줄러
• 모델 구성 (Model Configuration) — 동적 배치·인스턴스 그룹 구성 필드

출처: 공식문서 (Batchers)