배치 추론 처리량 계산기
입력
| 배치 크기 | 32 |
|---|---|
| 요청당 출력 토큰 수 | 256 |
| 배치 완료 시간 | 5 초 |
배치 추론 처리량 계산기
측정한 배치 완료 시간을 집계 초당 토큰, 요청당 속도, 초당 요청 수로 변환합니다. 배치 LLM 서빙의 처리량 대 지연 시간 절충을 보여 줍니다.
입력
배치
결과
값을 입력하면 계산 결과가 표시됩니다.
세부 정보
배치 추론 처리량
배치 추론은 프로덕션 언어 모델 서버가 높은 활용도에 이르는 방법이다. 요청을 한 번에 하나씩 디코딩하는 대신 여러 개를 함께 처리한다. 모델 가중치를 한 번 읽어 그룹 전체에 재사용하므로 서버의 총 출력은 배치 크기에 따라 가파르게 올라가지만, 개별 요청은 배치가 끝날 때까지 기다린다. 이 계산기는 그 두 관점을 분리하여, 측정한 배치 완료 시간을 집계 처리량, 요청당 속도, 요청률로 변환한다.
배칭의 절충
자기회귀 디코딩은 메모리 제한이다. 각 단계는 토큰 하나를 만들기 위해 모든 가중치를 읽는다. 단일 요청이 진행 중일 때는 그 메모리 트래픽의 거의 전부가 한 사용자만을 위한 것이다. 여러 요청을 하나의 배치로 묶으면 같은 가중치 읽기가 모든 요청에 대해 동시에 토큰을 만들어 내므로, 대역폭 비용은 거의 그대로인 채 집계 토큰 속도가 배치 크기에 따라 올라간다. 단점은 지연 시간이다. 요청은 자신이 포함된 배치 단계가 끝나기 전에는 떠날 수 없으므로 요청당 속도는 나아지지 않으며, 배치가 커지면 약간 떨어질 수도 있다.
공식
배치 크기 , 요청당 출력 토큰 수 , 측정한 배치 완료 시간 로부터 다음을 구한다.
vaggvreqR=tbB×Nout=tbNout=tbB여기서 는 집계 처리량, 는 요청당 처리량, 은 초당 완료되는 요청 수이다. 집계는 단순히 요청당 속도에 배치 크기를 곱한 값이다.
계산 예시
서버가 각각 256개 토큰을 생성하는 32개 요청 배치를 디코딩하고, 그 배치가 5초 만에 끝난다고 하자.
vaggvreqR=532×256=1638.4 tokens/s=5256=51.2 tokens/s=532=6.4 requests/s운영자는 서버에서 초당 1,600개가 넘는 토큰이 흘러나오는 것을 보지만, 각 사용자는 초당 약 51개 토큰으로 읽는다. 메모리가 허용하고 완료 시간이 5초 근처에 머문다면, 배치를 64로 두 배로 늘리면 집계는 대략 두 배가 되고 요청당 수치는 그대로 유지된다.
배치 크기 선택
집계 처리량은 작업이 메모리 제한 상태인 동안에만 배치 크기에 따라 계속 올라간다. 일단 배치가 연산을 포화시키거나 키-값 캐시가 장치 메모리를 소진하면, 완료 시간이 배치보다 빠르게 늘어나 요청당 지연 시간이 나빠진다. 실용적인 목표는 메모리가 아직 들어가는 한도 안에서 요청당 지연 시간을 허용 가능한 수준으로 유지하는 가장 큰 배치이며, 여러 배치 크기에서 완료 시간을 측정하여 찾는다. 실제 서버는 또한 연속 배칭을 사용하는데, 고정된 그룹이 아니라 매 단계마다 요청이 합류하고 떠나는 방식으로 지속 처리량을 더욱 높인다. 를 결정하는 단일 스트림 상한에 대해서는 추론 처리량 계산기를 참고하고, 여러 복제본에 걸친 플릿 단위 용량에 대해서는 유효 초당 토큰 수 계산기를 참고하면 된다.
자주 묻는 질문 (FAQ)
집계 처리량이 요청당 처리량보다 훨씬 높은 이유는 무엇인가
집계 처리량은 배치 안의 모든 요청에 걸쳐 서버가 내보내는 모든 토큰을 계산하는 반면, 요청당 처리량은 단일 사용자가 경험하는 값이다. 배칭은 각 모델 가중치를 한 번 읽어 그룹 전체에 재사용하므로, 서빙되는 총 토큰 수는 배치 크기에 대략 비례하여 올라간다. 그러나 개별 요청은 여전히 배치가 끝날 때까지 기다려야 하므로 체감 속도는 나아지지 않으며, 배치가 커지면 약간 떨어질 수도 있다. 이것이 배치 서빙의 핵심 절충, 즉 운영자에게는 처리량, 사용자에게는 지연 시간이라는 맞교환이다.
배치는 항상 클수록 좋은가
어느 지점까지만 그렇다. 작업이 메모리 제한 상태인 동안에는 집계 처리량이 배치 크기에 따라 올라가지만, 일단 배치가 연산을 포화시키거나 키-값 캐시가 메모리를 소진하면 완료 시간이 배치보다 빠르게 늘어나 요청당 지연 시간이 나빠진다. 실용적인 최적점은 메모리가 아직 들어가는 한도 안에서 요청당 지연 시간을 목표 범위에 유지하는 가장 큰 배치이며, 여러 배치 크기에서 완료 시간을 측정하여 찾는다.
연속 배칭은 이것을 어떻게 바꾸는가
이 계산기는 함께 시작해 함께 끝나는 고정 배치를 모델링한다. 최신 서버는 연속(인플라이트) 배칭을 사용하는데, 매 단계마다 새 요청이 합류하고 완료된 요청이 떠나면서 시퀀스 길이가 달라도 가속기를 가득 채운 상태로 유지한다. 이는 지속 집계 처리량을 고정 배치 추정치보다 높이지만, 같은 절충이 성립한다. 즉 초당 총 토큰은 향상되더라도 개별 요청은 여전히 디코드 속도에 묶인다.
면책조항
추정치는 배치 안의 모든 요청이 같은 수의 토큰을 생성하고 함께 시작한다고 가정한다. 실제 워크로드는 시퀀스 길이가 섞여 있고 연속 배칭을 사용하므로, 측정된 집계 처리량은 다를 것이다. 용량을 산정하기 전에 대상 하드웨어에서 여러 배치 크기로 벤치마크하는 것이 좋다.