처리량(Throughput)이란? AI가 일정 시간에 처리하는 작업량

TL;DR

처리량(Throughput)은 AI 시스템이 일정 시간 동안 처리해 결과를 내는 요청, 토큰 또는 데이터의 전체 양입니다. 한 사용자가 얼마나 빨리 답을 받는지는 레이턴시로 보고, 서비스 전체가 얼마나 많은 작업을 감당하는지는 처리량으로 봅니다. 처리량을 비교할 때는 모델, 입력·출력 길이, 동시 요청 수, 측정 시간과 성공 조건을 함께 확인해야 합니다.

핵심 3줄 요약

• 핵심 1
  처리량은 시스템 전체의 작업 능력을 나타냅니다. 요청 수나 처리 토큰 수를 초·분 같은 시간 단위로 나눠 표시합니다.
• 핵심 2
  처리량과 레이턴시는 같은 지표가 아닙니다. 전체 처리량이 높아도 한 사용자의 대기 시간은 길 수 있습니다.
• 핵심 3
  숫자만 떼어 비교하면 오해하기 쉽습니다. 모델, 요청 길이, 동시성, 오류율, 품질 조건이 같아야 의미 있는 비교가 됩니다.

이 글에서 다룰 내용

한 문장 정의

한 문장 정의: 처리량은 AI 모델이나 서비스가 일정 시간 동안 성공적으로 처리하고 반환하는 요청, 토큰 또는 데이터의 양을 나타내는 성능 지표입니다.

AWS는 처리량을 모델이 처리하고 반환하는 입력과 출력의 수와 속도로 설명합니다. Microsoft 문서에서는 AI 서비스의 시스템 처리량을 분당 요청 수와 전체 처리 토큰 수로 봅니다. 같은 처리량이라도 무엇을 세는지에 따라 단위가 달라질 수 있습니다.

텍스트 생성 AI에서는 분당 요청 수, 분당 토큰 수, 초당 토큰 수를 자주 봅니다. 이미지나 음성 모델은 시간당 생성 건수, 초당 처리 샘플처럼 다른 단위를 쓸 수 있습니다. 처리량 숫자 옆에는 측정 대상을 반드시 적어야 합니다.

한 줄 정리: 처리량은 한 번의 답변 속도보다, 일정 시간 동안 시스템 전체가 끝낸 작업의 양에 초점을 둡니다.

왜 중요한가요?

AI 기능을 혼자 시험할 때는 답변 한 건이 빨리 나오는지가 먼저 보입니다. 하지만 여러 사람이 동시에 쓰는 서비스나 수천 건을 처리하는 자동화에서는 전체 작업량이 더 중요해집니다.

첫째, 필요한 시스템 용량을 계산할 수 있습니다. 시간당 고객 문의 6,000건을 분류해야 한다면 평균 요청 수와 입력·출력 길이를 알아야 필요한 모델 배포 용량을 잡을 수 있습니다.

둘째, 혼잡 시간의 안정성을 점검할 수 있습니다. 평소에는 잘 작동해도 점심시간이나 캠페인 직후 요청이 몰리면 대기열과 오류가 늘 수 있습니다. 처리량을 꾸준히 보면 어느 지점에서 시스템이 포화되는지 찾기 쉽습니다.

셋째, 비용과 성능을 함께 비교할 수 있습니다. 더 빠른 모델이나 큰 서버가 처리량을 높일 수 있지만 비용도 달라집니다. 같은 품질 기준을 만족하는 조건에서 성공 요청당 비용이나 백만 토큰당 처리 시간을 함께 보는 편이 실무에 유용합니다.

넷째, 서비스 목표를 구체적으로 정할 수 있습니다. “AI가 빨라야 한다”보다 “피크 시간에 분당 500건을 처리하고 실패율을 기준 아래로 유지한다”처럼 목표를 적으면 시험과 개선이 쉬워집니다.

핵심 인사이트: 처리량은 서버가 빠른지 자랑하는 숫자가 아니라, 실제 업무량을 정해진 시간 안에 끝낼 수 있는지 확인하는 운영 지표입니다.

쉬운 예시

카페를 떠올려 보겠습니다. 한 손님이 주문한 커피가 나오기까지 3분 걸린다면 그 손님이 느끼는 대기 시간은 레이턴시에 가깝습니다. 카페가 한 시간에 커피 120잔을 만든다면 그 숫자는 처리량에 가깝습니다.

바리스타를 늘리고 주문을 나눠 만들면 카페 전체 처리량은 올라갈 수 있습니다. 하지만 주문 접수가 밀리거나 복잡한 메뉴가 많으면 내 커피가 나오는 시간은 길어질 수 있습니다. 처리량이 높다고 모든 손님의 대기 시간이 짧아지는 것은 아닙니다.

AI 고객지원 서비스도 비슷합니다. 모델이 분당 300건을 처리하더라도 각 문의가 길거나 동시에 많은 요청이 들어오면 일부 사용자는 오래 기다릴 수 있습니다. 반대로 한 요청은 매우 빨리 끝나도 동시에 한 건만 처리한다면 전체 처리량은 낮을 수 있습니다.

쉬운 예시 정리: 레이턴시는 내 주문이 나오는 시간이고, 처리량은 가게가 일정 시간에 완성한 주문 수입니다.

처리량은 어떻게 측정하나요?

측정 단위는 업무에 맞춰 고릅니다. 텍스트 생성 API라면 다음 세 가지가 대표적입니다.

1. 분당 요청 수(RPM): 1분 동안 성공적으로 끝낸 요청 수입니다.
2. 분당 토큰 수(TPM): 1분 동안 처리한 입력 토큰과 생성한 출력 토큰의 양입니다.
3. 초당 토큰 수(TPS): 일정 시간에 시스템이 처리하거나 생성한 토큰 수입니다.

Microsoft는 시스템 수준 처리량을 분당 토큰 수와 요청 수로 설명하고, 입력 토큰과 출력 토큰을 나눠 살펴보도록 안내합니다. AWS의 프로비저닝된 처리량도 일정 시간 동안 처리하는 입력 토큰과 출력 토큰을 기준으로 용량을 설명합니다.

같은 RPM이라도 긴 문서 100건과 짧은 질문 100건은 필요한 연산량이 다릅니다. 출력이 길수록 생성 시간이 늘 수 있고, 이미지나 음성까지 포함하면 비교 조건은 더 달라집니다. 평균값만 보지 말고 피크 시간, 긴 요청, 실패 요청도 따로 확인해야 합니다.

실전 팁: 처리량 기록에는 모델과 버전, 입력·출력 길이, 동시 요청 수, 측정 시간, 성공 기준, 오류율을 함께 남기세요. 그래야 다음 시험과 숫자를 제대로 비교할 수 있습니다.

비슷한 용어와 차이

처리량과 레이턴시

처리량은 일정 시간 동안 시스템 전체가 처리한 양입니다. 레이턴시는 요청 하나가 응답을 받기까지 걸린 시간입니다. Microsoft도 애플리케이션 용량을 계산할 때 시스템 처리량과 호출별 응답 시간을 별도 개념으로 구분합니다.

처리량과 동시성(Concurrency)

동시성은 같은 시점에 진행 중인 요청이나 사용자의 수입니다. 동시 요청을 늘리면 남는 자원을 더 활용해 처리량이 올라갈 수 있지만, 어느 지점부터는 시스템이 포화돼 레이턴시와 오류가 늘 수 있습니다. MLCommons의 엔드포인트 자료도 동시성이 증가하면 처리량이 오르다가 최대 수준에서 포화될 수 있음을 보여 줍니다.

처리량과 레이트 리밋(Rate Limit)

레이트 리밋은 서비스 제공자가 허용하는 요청이나 토큰 사용의 상한입니다. 처리량은 실제로 완료한 작업량입니다. 허용 한도가 높아도 모델, 네트워크, 요청 길이 때문에 실제 처리량은 그보다 낮을 수 있습니다.

처리량과 배치 처리(Batch Processing)

배치 처리는 여러 작업을 모아서 처리하는 방식입니다. 처리량을 높이는 데 도움이 될 수 있지만 처리량 그 자체는 아닙니다. 실시간 응답이 필요하지 않은 대량 분류나 임베딩 생성은 배치 처리와 잘 맞습니다.

처리량과 프로비저닝된 처리량

처리량은 성능을 측정하는 일반 지표입니다. 프로비저닝된 처리량은 일정한 모델 처리 용량을 미리 확보하는 클라우드 서비스 방식입니다. Google Cloud는 공유형 사용 방식과 고정 비용으로 특정 처리량을 예약하는 방식을 구분합니다. 제품마다 단위, 과금, 지원 모델, 보장 범위가 다르므로 제공자 문서를 따로 확인해야 합니다.

비교 정리: 처리량은 전체 작업량, 레이턴시는 한 요청의 대기 시간, 동시성은 함께 진행하는 요청 수, 레이트 리밋은 허용 상한, 배치 처리는 작업을 묶는 방식입니다.

실전에서는 어떻게 쓰이나요?

고객 문의 분류에서는 영업시간과 캠페인 직후에 들어오는 문의량을 기준으로 분당 처리 건수를 정합니다. 자동 분류가 밀리면 상담원이 보는 대기열도 길어지므로 피크 시간의 처리량이 중요합니다.

사내 문서 검색에서는 직원 수, 평균 질문 길이, 검색 문서 수, 답변 길이를 함께 봅니다. 처리량만 높이려고 답변을 지나치게 짧게 만들거나 검색 단계를 줄이면 품질이 떨어질 수 있습니다.

콘텐츠 검수 자동화에서는 마감 전 수천 개 문서를 처리해야 할 수 있습니다. 즉시 답변이 필요하지 않다면 배치 처리와 대기열을 써서 정해진 시간 안에 전체 작업을 끝내는 방향으로 설계할 수 있습니다.

AI 인프라 비교에서는 같은 모델과 데이터, 품질 목표를 유지한 채 처리량과 레이턴시를 함께 측정합니다. MLPerf Inference도 학습된 모델로 입력을 얼마나 빨리 처리하고 결과를 내는지 비교하며, 시나리오별로 레이턴시 제한과 처리량 지표를 둡니다.

실전 점검 순서

1. 업무량을 계산합니다. 평상시와 피크 시간의 요청 수를 따로 셉니다.
2. 요청 모양을 기록합니다. 평균·상위 구간의 입력 길이, 출력 길이, 이미지·음성 포함 여부를 확인합니다.
3. 성공 조건을 고정합니다. 오류 응답이나 품질 기준 미달 결과를 처리 완료로 셀지 정합니다.
4. 처리량과 레이턴시를 함께 측정합니다. 전체 작업량이 늘어도 사용자의 대기 시간이 허용 범위인지 봅니다.
5. 동시성을 단계적으로 올립니다. 처리량이 더 오르지 않고 대기와 오류만 늘어나는 포화 지점을 찾습니다.
6. 비용과 품질을 대조합니다. 같은 품질 조건에서 성공 작업당 비용을 비교합니다.

한 줄 정리: 좋은 처리량 시험은 최대 숫자 한 번을 찍는 시험이 아니라, 실제 요청 조건에서 품질과 대기 시간을 지키며 반복해서 낼 수 있는 작업량을 확인하는 시험입니다.

주의할 점

첫째, 처리량이 높다고 답변 품질이 좋아지는 것은 아닙니다. 더 짧은 답을 만들거나 검증 단계를 빼면 숫자는 높아져도 업무 결과는 나빠질 수 있습니다.

둘째, 측정 조건이 다르면 숫자를 바로 비교할 수 없습니다. 모델, 하드웨어, 입력·출력 길이, 동시성, 캐시 사용, 배치 크기가 달라지면 결과도 달라집니다.

셋째, 평균값만 보면 혼잡을 놓칠 수 있습니다. 평상시 평균 처리량이 충분해도 특정 시간대에 요청이 몰리면 대기와 오류가 커질 수 있습니다. 피크 구간과 긴 요청을 따로 시험해야 합니다.

넷째, 예약 용량과 실제 결과를 같은 말로 보면 안 됩니다. 프로비저닝된 처리량은 용량을 확보하는 상품 개념입니다. 실제 처리량은 요청 모양, 모델, 서비스 설정에 영향을 받습니다.

다섯째, 대량 처리에도 개인정보와 권한 기준이 필요합니다. 처리량을 높이려고 민감한 문서를 무분별하게 묶거나 검토 없이 외부로 보내면 안 됩니다. 입력 가림, 접근 권한, 로그, 사람 승인을 별도로 설계해야 합니다.

주의: 처리량 최적화는 품질 검증과 안전 절차를 줄이는 일이 아닙니다. 성공 요청 수를 셀 때는 기술적으로 응답한 건수뿐 아니라 업무 기준을 통과한 결과인지도 확인하세요.

자주 묻는 질문

Q1. 처리량이 높으면 AI 답변도 더 빨라지나요?

항상 그렇지는 않습니다. 처리량은 전체 시스템이 일정 시간에 끝낸 작업량이고, 한 요청의 속도는 레이턴시입니다. 시스템 전체 처리량이 높아도 요청이 몰리면 개인의 대기 시간은 길어질 수 있습니다.

Q2. AI 처리량은 어떤 단위로 보나요?

텍스트 생성에서는 분당 요청 수, 분당 토큰 수, 초당 토큰 수를 자주 씁니다. 이미지·음성·임베딩 작업은 시간당 건수나 초당 샘플 수처럼 다른 단위를 쓸 수 있습니다. 숫자와 함께 측정 대상을 적어야 합니다.

Q3. 레이트 리밋이 곧 처리량인가요?

아닙니다. 레이트 리밋은 허용된 사용량의 상한이고, 처리량은 실제로 성공적으로 끝낸 작업량입니다. 한도가 넉넉해도 긴 요청, 시스템 부하, 오류 때문에 실제 처리량은 낮을 수 있습니다.

Q4. 동시 요청을 계속 늘리면 처리량도 계속 오르나요?

그렇지 않습니다. 초반에는 자원을 더 활용해 처리량이 오를 수 있지만, 포화 지점 이후에는 대기 시간과 오류만 늘 수 있습니다. 동시성을 단계적으로 높이며 처리량, 레이턴시, 오류율을 함께 봐야 합니다.

Q5. 프로비저닝된 처리량을 사면 성능이 항상 보장되나요?

상품과 제공자 조건에 따라 다릅니다. 예약 용량은 예측 가능한 운영에 도움이 되지만 실제 결과는 모델, 입력·출력 길이, 호출 빈도, 설정에 영향을 받습니다. 과금 방식과 지원 모델, 초과 요청 처리 규칙도 공식 문서에서 확인해야 합니다.

출처

마무리

처리량은 AI 시스템이 일정 시간 동안 성공적으로 끝내는 요청, 토큰 또는 데이터의 양입니다. 한 번의 답변이 빠른지만 보지 않고, 실제 서비스가 몰리는 업무를 얼마나 안정적으로 감당하는지 보여 줍니다.

감자나라ai님이 AI 기능이나 자동화를 운영한다면 최대 처리량 숫자부터 찾기보다 실제 요청 길이와 피크 시간, 허용 레이턴시, 품질 기준을 먼저 정해 보세요. 같은 조건에서 처리량과 오류율, 비용을 함께 기록해야 운영에 쓸 수 있는 숫자가 됩니다.