이는 시스템 용량을 나타내는 지표입니다. 단일 요청이 얼마나 빠르게 시작되거나 완료되는지는 알려주지 않습니다.
추론 처리량의 작동 방식
기본 계산식은 다음과 같습니다.
처리량 = 완료된 작업량 ÷ 경과 시간
여기서 ‘작업’이라는 단어가 중요합니다. 이미지 분류기의 경우 처리된 이미지 수를 의미할 수 있습니다. 언어 모델의 경우 완료된 요청 수 또는 처리된 토큰 수를 의미할 수 있습니다. ‘초당 2,000’이라는 결과는 무엇을 집계했는지 알기 전까지는 의미가 없습니다.
토큰 처리량에는 추가적인 구분이 필요합니다. 입력 토큰 처리량은 프롬프트 처리를 측정합니다. 출력 토큰 처리량은 생성된 토큰을 측정합니다. 총 토큰 처리량은 두 가지를 합한 값입니다. 이 비율들은 서로 다른 작업을 나타내므로 동일한 지표인 것처럼 비교해서는 안 됩니다.
측정 범위도 중요합니다. 결과가 가속기 하나, 서버 하나 또는 여러 복제본으로 구성된 전체 배포를 대상으로 할 수 있습니다. 모델과 워크로드가 그 밖의 조건에서 동일한 경우에만 배포 전체 결과를 가속기 수로 나누면 가속기당 용량을 비교하는 데 도움이 됩니다.
일반적으로 동시에 실행되는 요청이 많아질수록 처리량은 증가합니다. 서빙 시스템은 작업을 함께 배치해 각 처리 단계에서 하드웨어를 더 많이 활용할 수 있습니다. 언어 모델에서는 연속 배칭을 사용하면 가장 긴 시퀀스가 끝날 때까지 전체 배치를 유지하는 대신 완료된 시퀀스를 대기 중인 시퀀스로 교체할 수 있습니다.
하지만 이러한 향상에는 한계가 있습니다. 연산, 메모리 또는 다른 공유 리소스가 포화되면 추가 요청은 대기열에서 기다립니다. 유입률은 계속 증가할 수 있지만 완료율은 더 이상 그에 맞춰 증가하지 않습니다. 원시 처리량의 변화가 거의 없더라도 지연 시간은 악화됩니다.
따라서 유용한 용량 결과는 흔히 다음과 같이 표현됩니다.지연 시간 목표 조건에서의 지속 가능한 처리량. 벤치마크는 부하를 증가시키면서 완료된 작업량을 측정하고 응답 시간 제한이 여전히 충족되는지 확인합니다. 마지막으로 기준을 통과한 부하가 제약 없는 최고치보다 온라인 서비스 계획에 더 유용합니다.
예제 계산
한 벤치마크가 동일한 프롬프트 구성으로 하나의 모델 서버에 60초 동안 요청을 보낸다고 가정해 보겠습니다. 서버는 요청 1,200개를 완료하고 출력 토큰 180,000개를 생성합니다.
- 요청 처리량:
1,200 ÷ 60 = 초당 20개 요청 - 출력 토큰 처리량:
180,000 ÷ 60 = 초당 3,000개 출력 토큰
이는 동일한 실행 결과를 두 가지 관점에서 나타낸 것입니다. 요청률은 서버가 완료할 수 있는 상호작용 수를 추정하는 데 도움이 됩니다. 토큰률은 요청 수만으로는 드러나지 않는 응답 길이의 차이를 반영합니다.
이제 제공 부하를 초당 30개 요청으로 높여 보겠습니다. 서버는 초당 22개를 완료하지만, 매초 8개의 요청이 추가로 대기열에 들어가고 지연 시간 목표를 충족하지 못합니다. 제공 부하는 초당 30개 요청입니다. 관측된 완료 처리량은 초당 22개 요청입니다. 어느 쪽도 서비스가 초당 30개 요청을 지속적으로 처리할 수 있다는 것을 입증하지는 않습니다.
초당 20개 요청이 대기열을 안정적으로 유지하고 지연 시간 목표를 충족한 가장 높은 테스트 부하였다면, 해당 워크로드와 목표에 대해 용인할 수 있는 용량 수치는 20입니다.
추론 처리량이 중요한 이유
처리량은 운영자가 예상 수요에 필요한 하드웨어 규모를 파악하는 데 도움이 됩니다. 또한 달러당 완료 요청 수 또는 가속기 시간당 출력 토큰 수와 같은 비용 지표를 산출하는 데도 활용됩니다.
오프라인 작업에서는 처리량이 높을수록 전체 처리 시간이 단축될 수 있습니다. 온라인 서비스에서는 시스템이 요청을 완료하는 속도보다 빠르게 유입 요청이 누적되는 것을 방지하려면 충분한 처리량이 필요합니다.
목표는 제품에 따라 달라집니다. 배치 파이프라인은 전체 작업량을 극대화하기 위해 긴 대기 시간을 허용할 수 있습니다. 대화형 애플리케이션은 개별 요청의 응답성을 유지하면서 충분한 처리량을 확보해야 합니다. 굿풋(goodput)이라는 더 엄격한 지표는 서비스의 지연 시간 목표도 충족하는 작업만 집계합니다.
흔한 오해
처리량이 높으면 모든 응답이 더 빠르다
반드시 그렇지는 않습니다. 더 많은 요청을 배칭하면 서버 전체의 총 출력은 늘어날 수 있지만, 각 요청이 더 오래 대기하거나 토큰을 더 느리게 받을 수 있습니다. 처리량은 전체 시스템을 설명하고, 지연 시간은 개별 요청의 대기 시간을 설명합니다.
초당 토큰 수는 항상 처리량을 의미한다
‘초당 토큰 수’는 집계된 토큰 처리량을 나타낼 수도 있고, 한 사용자가 경험하는 생성 속도를 나타낼 수도 있습니다. 이 수치가 단일 요청을 대상으로 하는지 아니면 모든 동시 요청을 대상으로 하는지, 그리고 입력 토큰, 출력 토큰 또는 둘 다를 집계하는지 확인해야 합니다.
요청률이 처리량이다
요청률은 유입되는 양입니다. 처리량은 완료되는 양입니다. 시스템이 유입을 따라잡는 동안에만 두 값이 비슷합니다. 유입이 완료보다 많으면 요청이 지연되거나 거부되거나 삭제될 때까지 대기열이 증가합니다.
시스템을 비교하려면 처리량 수치 하나면 충분하다
처리량은 모델, 입력 및 출력 크기, 배치 또는 동시성 패턴, 하드웨어 범위, 측정 시간 구간, 지연 시간 제한에 따라 달라집니다. 시스템이 동일하더라도 워크로드를 변경하면 수치가 달라질 수 있습니다.
다음에 읽을 내용
처리량이 용량을 측정하는 대상인 프로세스는 AI에서 추론이란 무엇인가요?에서 확인하세요. 대기 시간을 측정하는 추론 지연 시간 및 생성 속도를 설명하는 경우가 많은 초당 토큰 수와 비교해 보세요. 전체적인 구분은 지연 시간 vs. TTFT vs. 초당 토큰 수 vs. 처리량에서 확인할 수 있습니다.