Azure OpenAI에서 토큰 사용량은 여유로워 보이는데 429 Too Many Requests가 계속 나온다면, 먼저 실패한 요청이 도착한 배포의 실제 한도와 응답 헤더를 확인하세요. 구독에 남아 있는 할당량, 배포에 배정된 분당 토큰 수(TPM), 완료 후 집계된 토큰 사용량은 서로 다른 값입니다. 성공한 요청의 과금 토큰이 적다는 사실만으로 요청 속도 제한에 걸리지 않았다고 판단할 수 없습니다.
Standard 배포의 제한은 요청이 들어올 때 예상되는 최대 토큰 처리량과 요청 수를 기준으로 적용됩니다. 따라서 짧은 답변에도 큰 출력 상한을 설정하거나 여러 작업자가 동시에 요청을 보내면, 분 단위 그래프가 낮아도 429가 발생할 수 있습니다. 이 차이는 Microsoft의 할당량 관리 문서에도 설명되어 있습니다.
아래 순서는 Standard 배포를 중심으로 합니다. API Management(APIM)를 경유하거나 Provisioned 배포를 사용하는 경우에는 각각의 제한을 별도로 확인해야 합니다. 포털과 할당량 관리 방식은 2026년 9월 5일 기준이며, 실제 적용 값은 사용 중인 구독과 배포에서 확인하세요.
실패한 요청 한 건에서 시작하세요
설정을 바꾸기 전에 같은 시간대의 성공 응답과 429 응답을 함께 확보합니다. 기록할 것은 요청 본문 전체보다 어디로, 언제, 몇 번째 시도가 전달되었는지입니다. 원문 입력이나 인증 키를 로그에 남길 필요는 없습니다.
- UTC 시각, 호출한 호스트와 배포 이름, 모델·버전·배포 유형
- HTTP 상태, 오류 코드와 메시지, 반환된 요청 식별자
- 처음 보낸 요청인지 재시도인지, 해당 논리 요청의 시도 횟수
- 입력 크기 추정치, 실제 요청에 지정한 출력 상한, 요청을 보낸 간격
- 아래 속도 제한 헤더의 원래 값과, 성공한 경우 응답의 토큰 사용량
공식 응답 헤더 설명에 따르면 요청 수와 토큰 수의 한도·잔여량을 각각 확인할 수 있습니다.
| 응답에서 확인할 값 | 무엇을 판단하는 데 쓰는가 |
|---|---|
x-ratelimit-limit-tokens | 현재 응답에 표시된 토큰 한도를 배포의 설정값과 비교 |
x-ratelimit-remaining-tokens | 토큰 여유가 줄어드는 시점과 429 발생 시점 비교 |
x-ratelimit-limit-requests / x-ratelimit-remaining-requests | 토큰이 남아 있어도 요청 수 제한에 가까워졌는지 확인 |
x-ratelimit-reset-tokens / x-ratelimit-reset-requests | 반환된 재설정 정보를 원문 그대로 보존 |
retry-after-ms | 429 응답에서 권고한 재시도 대기 시간. 단위는 밀리초 |
예를 들어 retry-after-ms: 2000이면 권고 대기 시간은 2초입니다. 이 단위를 다른 reset 헤더에 그대로 적용해서는 안 됩니다. 사용하는 API와 SDK가 해당 헤더를 해석하는 방식을 확인하세요. 게이트웨이가 헤더를 제거하거나 바꿀 수 있으므로, 값이 없으면 잔여량을 0으로 처리하지 말고 미확인 상태로 남겨야 합니다.
동일한 배포라고 생각했는데 애플리케이션이 오래된 배포 이름을 사용하거나, 일부 작업자만 다른 엔드포인트를 호출하는 경우도 먼저 배제하세요. 포털에서 수정한 대상과 오류를 낸 요청의 대상이 같아야 이후 비교가 의미가 있습니다.
헤더와 요청 패턴을 함께 보면 조치가 달라집니다
429라는 상태 코드만으로 TPM 부족을 확정할 수는 없습니다. 아래 표는 원인을 단정하는 규칙이 아니라, 다음에 확인할 항목을 좁히는 순서입니다. Standard의 일시적인 처리 용량 부족과 유효 한도 조정도 공식 문서에 별도의 429 유형으로 구분되어 있습니다.
| 함께 관찰되는 현상 | 먼저 확인할 부분 | 첫 조치 |
|---|---|---|
| 토큰 잔여량이 줄지만 성공 응답의 실제 출력은 짧음 | 출력 상한과 입력 크기 | 필요한 응답을 잘라내지 않는 범위에서 출력 상한 조정 |
| 토큰은 남아 있고 작업 시작 순간에 429가 집중됨 | 짧은 구간의 요청 수, 여러 작업자의 동시 시작 | 요청 전송 간격을 분산하고 모든 작업자의 합산 속도 제어 |
| 구독에는 여유가 있지만 특정 배포만 한도에 도달함 | 해당 배포에 실제로 배정된 TPM | 같은 할당량을 공유하는 배포 사이에서 배분 조정 |
| 헤더의 토큰 한도가 배포 설정값보다 낮음 | 배포 식별 정보, 설정 반영 여부, 백엔드 오류 메시지 | 전송량을 낮추고 대기 시간을 준수하며 유효 한도 추적 |
| APIM 경유 요청에서 오류가 나고 백엔드 호출 기록이 없음 | APIM 추적 결과와 제한 정책 | 게이트웨이의 제한 조건과 카운터 확인 |
헤더 하나를 보고 즉시 한도를 올리기보다는, 같은 시각의 오류 메시지와 전송 패턴이 같은 원인을 가리키는지 확인하는 편이 좋습니다. 설정과 유효 한도의 차이가 지속되면 원문 헤더와 요청 식별자가 지원 요청의 핵심 자료가 됩니다.
제한 계산에 포함되는 토큰은 실제 출력과 다릅니다
Azure OpenAI의 TPM 제한 계산은 요청 수신 시점의 추정치입니다. 입력과 출력 상한인 max_tokens, 지원하는 API에서는 best_of 등이 영향을 줍니다. 추정에는 문자 수 기반 계산도 포함되므로 로컬 토크나이저가 센 토큰 수와 정확히 일치하지 않습니다. best_of를 지원하지 않는 Chat Completions 요청에 이를 추가하거나, 다른 모델의 출력 상한 필드를 그대로 복사해서는 안 됩니다. TPM 계산 방식과 권장 설정을 사용 중인 API의 매개변수와 함께 확인하세요.
감각을 잡기 위해 입력 추정치 1,000토큰, 출력 상한 4,000토큰인 요청을 생각해 봅시다. 입력과 출력 상한을 단순히 더한 비교값은 요청당 5,000토큰입니다. 실제로 답변이 200토큰만 나왔다면 완료 후 토큰은 약 1,200토큰이지만, 그것이 요청 시점의 제한 계산과 같다는 뜻은 아닙니다.
출력 상한을 500으로 바꿀 수 있는 작업이라면 같은 단순 비교값은 1,500토큰으로 줄어듭니다. 이 계산은 설정이 왜 중요한지 보여 주는 예시이며, Azure의 정확한 내부 계산식이나 처리량 보장이 아닙니다. 변경 후에는 정상 응답이 중간에 끊기지 않는지, 긴 답변이 필요한 입력도 통과하는지까지 확인해야 합니다. 추론 모델에서는 출력 예산의 의미도 해당 모델 문서에 맞춰 판단해야 합니다.
일부 HTTP 400 요청도 제한 계산에 포함될 수 있지만 성공 요청의 과금 지표에는 나타나지 않을 수 있습니다. 입력 길이 오류를 계속 재전송하는 작업이 있다면, 그 오류부터 고치는 것이 토큰 한도 증설보다 우선입니다.
분당 평균이 같아도 한꺼번에 보내면 다릅니다
RPM은 분당 요청 수입니다. Azure는 요청 수를 보통 1초 또는 10초처럼 짧은 구간에서도 평가하므로, 1분 평균만 맞추는 방식으로는 순간적인 요청 집중을 막지 못합니다. 정확한 평가 구간을 모든 모델에 동일하게 가정해서는 안 됩니다. Microsoft의 RPM 설명은 요청을 균등하게 분산하도록 권장합니다.
예를 들어 배포의 실제 RPM이 600이라고 확인했다면 산술 평균은 초당 10건입니다. 작업자가 매분 첫 순간에 60건을 일제히 보내는 방식과 6초 동안 초당 10건을 보내는 방식은 요청 총수가 같아도 서버가 받는 순간 부하가 다릅니다. 초당 10건 역시 안전을 보장하는 값은 아니므로 실제 응답을 보며 여유를 두고 시작하세요.
동시 실행 수만 줄이는 것으로 충분하지 않을 수 있습니다. 응답이 빨리 끝나면 적은 작업자도 짧은 시간에 많은 요청을 보냅니다. 운영 환경에서는 요청 시작 간격과 진행 중인 요청 수를 별도로 제한하고, 여러 프로세스·서버가 같은 배포를 쓰면 합산된 요청 수와 토큰 수요를 제어해야 합니다. 재시도 요청도 이 대기열을 거쳐야 합니다.
TPM을 늘리기 전에 어디의 할당량인지 확인하세요
구독의 전체 할당량은 배포들이 나누어 쓰는 예산이며, 호출에 적용되는 값은 해당 배포에 배정된 한도입니다. 남은 예산이 있다는 것만으로 현재 배포가 자동으로 더 많이 처리하는 것은 아닙니다. 또한 TPM과 RPM은 모델별 비율로 연결되므로 두 값을 독립적으로 조절할 수 있다고 가정하지 마세요. 과거 모델의 1,000 TPM = 6 RPM을 모든 모델의 환산식으로 사용해서는 안 됩니다. 모델별 할당 관계를 확인해야 합니다.
다른 리전에 배포하면 한도가 늘어날까요?
먼저 Foundry의 Quota 화면에서 해당 모델의 Scope 열을 확인하세요. Microsoft는 2026년 5월 7일 이후 구독 수준 할당량 관리 전환을 시작했으며, 모든 모델에 이미 적용되었다고 단정할 수는 없습니다. 현재 적용 범위를 확인하는 방법은 다음과 같습니다.
Global: 전환된 Global Standard 모델은 같은 구독의 동일 모델·버전이 리전 전체에서 할당량을 공유합니다.Data Zone: 전환된 Data Zone Standard 모델은 동일 데이터 영역 안에서 할당량을 공유합니다.East US같은 리전 이름: 해당 구독·모델에 리전별 관리가 적용됩니다.
따라서 같은 공유 범위 안에 배포를 추가하는 일과 전체 할당량을 늘리는 일은 다릅니다. 다른 리전으로 옮기는 방안은 할당량 범위뿐 아니라 모델·버전 지원, 실제 가용 용량, 데이터 처리 지역 요건을 함께 확인한 뒤 선택해야 합니다. 한국어 서비스를 운영한다는 이유만으로 특정 한국 리전을 사용할 수 있다고 보장할 수는 없습니다.
포털에서 배분을 바꾸는 순서
새 Foundry 포털의 공식 절차에 따라 다음 순서로 확인합니다.
- New Foundry가 켜진 상태에서 Manage → Quota → Token per minute로 이동합니다.
- 오류를 낸 배포의 상세 화면을 열고 현재 할당량과 공유하는 다른 배포를 확인합니다.
- Affiliated deployments using shared quota에서 대상 배포의 연필 아이콘을 눌러 배분을 조정합니다. 다른 배포에서 가져올 때는 그 배포의 실제 수요와 여유를 먼저 확인합니다.
- 전체 할당량이 부족하면 Request quota로 증설을 요청합니다.
- 설정 변경은 반영에 최대 15분이 걸릴 수 있으므로 화면을 새로 고친 뒤 실제 응답의 유효 한도와 비교합니다.
15분은 설정 반영 안내이며 증설 신청 승인 기한이 아닙니다. 조회용 최소 권한으로 안내되는 구독 수준의 Cognitive Services Usages Reader 역할도 수정 권한을 뜻하지 않습니다. 조회만 가능한 계정이라면 확인한 배포와 필요한 변경값을 수정 권한이 있는 담당자에게 전달하세요.
자동화로 확인할 때도 숫자의 의미를 구분해야 합니다. ARM의 Usages API에서 currentValue는 배포들이 차지한 할당량이며, 최근 1분간 추론에 사용한 토큰 수가 아닙니다. name.value, name.localizedValue, unit, currentValue, limit를 함께 보존하고 항목별 단위를 확인하세요. Model Capacities API는 새 배포나 확장에 쓸 수 있는 용량을 조회하는 별도 API입니다. 두 관리 API의 용도를 혼동하면 사용하지 않은 배포의 할당량을 실제 트래픽으로 오해할 수 있습니다.
APIM 제한과 Provisioned 포화는 따로 처리합니다
APIM의 llm-token-limit 정책은 키별 토큰 카운터로 별도의 제한을 적용할 수 있습니다. 분당 토큰 속도를 초과하면 429, 일정 기간의 토큰 할당량을 초과하면 403을 반환합니다. 이것은 Azure OpenAI 배포의 TPM과 다른 제한입니다. 모든 403이 이 정책 때문이라는 뜻은 아니며, 정책 설정과 응답 조건을 실제 오류와 대조해야 합니다.
APIM 추적에서 요청이 백엔드까지 전달되었는지, 어느 정책에서 거부되었는지 확인하세요. 게이트웨이에서 차단된 요청에 대해 Azure 배포의 TPM만 올려도 해당 정책은 바뀌지 않습니다. 반대로 백엔드가 429를 반환했다면 배포의 응답과 한도를 확인해야 합니다. 원인 확인을 위해 기업의 필수 게이트웨이를 우회하는 대신 승인된 추적 기능과 로그를 사용하세요.
Provisioned 배포는 PTU로 전용 처리 용량을 확보합니다. 그러나 포화되면 429가 발생할 수 있으며, 모든 모델에 공통인 PTU→TPM 환산값도 없습니다. PTU 할당량 승인은 해당 모델을 배포할 실제 용량 확보와도 다릅니다. Provisioned 처리량 설명에 따라 모델, 입력·출력 구성, 실제 부하로 용량을 산정해야 합니다. Standard의 잦은 용량 변동 때문에 전환을 검토한다면, 배포된 PTU에는 사용 토큰 수와 무관한 시간당 요금이 발생한다는 점도 함께 비교하세요.
재시도를 늘리기보다 대기와 종료 조건을 정하세요
간헐적인 429에는 응답이 지시한 대기 시간을 따르는 것이 첫 조치입니다. retry-after-ms가 있으면 밀리초 단위로 해석하고, 적용 가능한 Retry-After가 있으면 그 형식에 맞춰 처리합니다. 둘 다 사용할 수 없다면 지수 백오프에 무작위 지연을 더하되, 전체 처리 기한과 최대 시도 횟수를 둡니다. 실패한 시도도 한도를 소비할 수 있어 즉시 반복할수록 복구가 늦어질 수 있습니다. Microsoft의 재시도 권장 방식을 기준으로 구성하세요.
SDK와 애플리케이션 중 어느 쪽이 재시도를 담당하는지도 명확히 해야 합니다. 예를 들어 바깥 반복문이 총 3회 시도하고 SDK가 각 호출마다 2회 재시도한다면, 최악의 경우 논리 요청 한 건이 최대 9번의 HTTP 시도로 늘어납니다. 이는 3 × (최초 1회 + 재시도 2회)라는 계산 예시입니다. 애플리케이션에서 직접 제어한다면 SDK의 재시도를 끄는 등 중첩을 제거하고, 처음 시도와 최종 결과를 모두 기록하세요.
서버가 권고한 대기 시간이 남은 처리 기한보다 길다면 그 기한 안에 무리하게 다시 보내지 말고, 작업 특성에 따라 지연 처리하거나 실패를 반환합니다. 잘못된 입력이나 인증 오류는 429와 같은 방식으로 반복하지 않습니다. 다른 모델로 전환할 필요가 있다면 응답 호환성과 비용, 데이터 처리 조건까지 포함해 재시도와 대체 모델 전환 기준을 따로 검토할 수 있습니다.
복구는 같은 요청량을 처리했는지까지 확인해야 합니다
설정을 저장했거나 요청 한 건이 성공했다는 것만으로 복구가 끝난 것은 아닙니다. 같은 작업량을 필요한 시간 안에 처리하면서 429와 재시도 부담이 줄었는지를 확인해야 합니다. 아래는 실제 결과를 채워 넣는 검증 절차이며, 특정 개선율을 전제하지 않습니다.
- 변경 전의 배포 이름·모델 버전·TPM·RPM·Scope와 오류 발생 시간대를 기록합니다. 처음 전송한 논리 요청 수와 재시도를 포함한 HTTP 시도 수를 나눠 셉니다.
- 원인에 맞는 변수 하나를 바꿉니다. 출력 상한, 전송 간격, 배포 할당량을 한 번에 바꾸면 어떤 조치가 효과가 있었는지 알기 어렵습니다.
- 같은 입력 길이 분포와 작업량으로 낮은 속도부터 시작해 평소 부하까지 점진적으로 높입니다. 평소 요청이 몰리던 구간도 확인하되 허용된 테스트 범위 안에서 진행합니다.
- 응답의 유효 한도와 잔여량, 처음 시도의 429 비율, 최종 성공률, 논리 요청당 HTTP 시도 수를 비교합니다. 대기열 체류 시간과 전체 응답 시간의 95백분위수(P95)도 함께 봅니다.
- 출력 상한을 줄였다면 응답 완결성까지 확인합니다. 할당량을 재배분했다면 한도를 줄인 다른 배포에서도 오류나 지연이 늘지 않았는지 확인합니다.
예를 들어 429가 줄었지만 대기열이 계속 길어진다면 요청을 더 천천히 보내며 문제를 뒤로 미룬 것일 수 있습니다. 재시도 후 성공률만 높아지고 처음 시도의 429가 그대로라면 과부하도 남아 있습니다. 반대로 목표 작업량을 유지하면서 처음 시도의 오류, 시도 횟수, 지연 시간이 함께 안정되면 조치가 효과를 냈다고 판단할 근거가 생깁니다.
설정 반영 시간을 지나도 낮은 전송량에서 429가 지속되거나 유효 한도가 설정과 계속 다르면 지원 요청을 준비하세요. 구독·리소스·배포 식별 정보, 모델과 버전, UTC 발생 시각, 요청 식별자, 민감한 내용을 제거한 오류와 원문 헤더, 변경 전후 설정을 전달하면 원인 조사에 도움이 됩니다. 구독 할당량 증설만으로 공유 처리 용량 문제가 해결된다고 가정하지 마세요.
마지막으로 TPM을 늘려도 한 요청에 넣을 수 있는 컨텍스트 길이는 늘어나지 않습니다. 긴 입력 자체가 거부된다면 모델별 입력 제한을 확인해야 합니다. OpenAI의 직접 API를 쓰는 요청은 Azure 배포 할당량과 관리 체계가 다르므로, 그 경우에는 OpenAI API 요청 한도 안내에서 계정 기준을 확인하세요.
