Rate Limits
Rate Limits (요금 한도)
Rate limit은 API가 특정 기간 동안 사용자·클라이언트가 서비스를 접근할 수 있는 횟수를 제한하는 정책이에요. API의 악용·오용을 막고, 모두가 공정하게 API에 접근할 수 있게 하며, 인프라의 전체 부하를 관리하는 역할을 해요. 어떤 한도에 먼저 닿느냐에 따라 제한이 걸리기 때문에, 자신의 서비스 요금 한도가 어떻게 측정되는지 이해하는 게 중요해요.
한도가 어떻게 측정되나
Rate limit은 RPM(분당 요청), RPD(일당 요청), TPM(분당 토큰), TPD(일당 토큰), IPM(분당 이미지) 같은 지표로 측정돼요. 어떤 옵션에 먼저 닿느냐에 따라 제한이 걸려요. 예를 들어 RPM이 20인데 토큰만 100개인 요청 20개를 보내도, TPM 한도(예: 150k)를 채우지 않았어도 요청 수 한도에 닿을 수 있어요.
몇 가지 중요한 점이 있어요.
- Rate limit은 사용자 단위가 아니라 조직 수준과 프로젝트 수준에서 정의돼요.
- 한도는 사용하는 모델마다 달라요.
- GPT-5.5 같은 긴 컨텍스트 모델은 긴 컨텍스트 요청에 별도 rate limit이 있어요.
- OpenAI는 조직별로 승인된 월 사용 한도를 설정하며, 이는 조직·프로젝트에 구성하는 spend limits와는 별개예요.
- 일부 모델 계열은 공유 rate limit을 가져요. 조직 한도 페이지의 "shared limit"에 나열된 모델들은 하나의 rate limit을 공유해요.
Batch API 큐 한도는 특정 모델에 큐잉된 총 input 토큰 수로 계산돼요. 보류 중인 batch 작업의 토큰은 큐 한도에 포함되고, 완료되면 더 이상 그 모델 한도에 집계되지 않아요.
Usage tiers
조직의 rate·사용 한도는 계정 설정의 limits 섹션에서 볼 수 있어요. API 지출이 늘수록 다음 usage tier로 자동 승급되고, 대부분 모델에서 rate limit이 늘어나는 경우가 많아요.
| Tier | 자격 | 사용 한도 |
|---|---|---|
| Free | 지원 지역 내 사용자 | 월 $100 |
| Tier 1 | $5 지불 | 월 $100 |
| Tier 2 | $50 지불 | 월 $500 |
| Tier 3 | $100 지불 | 월 $1,000 |
| Tier 4 | $250 지불 | 월 $5,000 |
| Tier 5 | $1,000 지불 | 월 $200,000 |
응답 헤더의 rate limit
계정 페이지에서 한도를 보는 것 외에, HTTP 응답 헤더에서 남은 요청·토큰 같은 정보도 볼 수 있어요. 주요 헤더는 이래요.
| Field | 예시 값 | 설명 |
|---|---|---|
| Retry-After | 56 | 일시 rate-limit 오류 후 재시도까지 기다릴 최소 초 수 |
| x-ratelimit-limit-requests | 60 | rate limit 소진 전 허용된 최대 요청 수 |
| x-ratelimit-limit-tokens | 150000 | rate limit 소진 전 허용된 최대 토큰 수 |
| x-ratelimit-remaining-requests | 59 | rate limit 소진 전 남은 요청 수 |
| x-ratelimit-remaining-tokens | 149984 | rate limit 소진 전 남은 토큰 수 |
| x-ratelimit-reset-requests | 1s | 요청 기반 rate limit이 초기화되기까지 시간 |
| x-ratelimit-reset-tokens | 6m0s | 토큰 기반 rate limit이 초기화되기까지 시간 |
| x-ratelimit-limit-project-tokens | 60000 | 프로젝트의 토큰 한도 |
| x-ratelimit-remaining-project-tokens | 57000 | 프로젝트 범위 토큰 rate limit 소진 전 남은 토큰 수 |
| x-ratelimit-reset-project-tokens | 3s | 프로젝트 범위 토큰 rate limit 초기화까지 시간 |
Retry-After는 일시 rate limit에 의한 429와 일시 모델 과부하에 의한 503 응답에 있을 수 있어요. 쿼터·청구·사용자 조치가 필요한 오류는 재시도로 해결되는 게 아님을 뜻하지는 않아요.
오류 완화 (Error mitigation)
급격한 트래픽 증가와 모델 과부하 처리
요청 속도가 너무 빠르게 증가하면 slow_down이, 요청한 모델이 일시 과부하되면 server_is_overloaded가 반환될 수 있어요. HTTP 상태와 error.code로 구분해요.
| HTTP status | Error type | Error code | 의미 | 대처 |
|---|---|---|---|---|
429 |
rate_limit_error |
slow_down |
요청 속도가 너무 빨리 증가 | Retry-After 있으면 따르고, 요청 속도를 낮춰 점진적으로 증가 |
503 |
service_unavailable_error |
server_is_overloaded |
요청 모델이 일시 과부하 | Retry-After 있으면 따르고 재시도. 계속되면 재시도 간격 증가 |
Retry-After가 없으면 재시도 간격을 늘리고 작은 임의 지연(jitter)을 추가해요. slow_down은 트래픽이 분당·토큰당 한도 안에 있어도 발생할 수 있어요. 한도 소진 여부가 아니라 트래픽이 얼마나 빨리 증가했는지를 반영하거든요. 참고로 트래픽이 분당 100만 input 토큰에 닿으면 15분마다 50% 이하로만 늘리는 게 경험칙이에요.
기존 오류 핸들러를 업데이트할 땐 HTTP 상태와 error.code 둘 다 확인해요. SDK 오류 핸들러에서 429와 503을 모두 처리해요. 예를 들어 Python·TypeScript·Ruby는 429에 RateLimitError, 503에 InternalServerError를, Java는 RateLimitException·InternalServerException을 사용해요.
지수 백오프로 재시도
일시 rate limit을 초과하면 API가 429 오류를 반환해요. 응답에 Retry-After 헤더가 있으면 재시도까지 기다릴 초 수를 알려줘요. 이 값을 최소값으로 보고 그만큼 이상 기다리되, 여러 클라이언트가 동시에 재시도하지 않도록 작은 임의 지연을 더해요. 지수 백오프는 실패 요청 후 잠시 기다렸다 실패할 때마다 지연을 늘리는 방식이에요.
공식 SDK는 설정에 따라 적격 429·503을 자동 재시도해요. Retry-After 처리 방식(특히 긴 지연)은 SDK 버전·설정에 따라 달라요. 유효한 서버 지연이 지원되는 최대 재시도 지연을 넘으면 무한 재시도 대신 요청을 보류해요. 자체 HTTP 클라이언트를 쓰면 Retry-After를 따르고, 없으면 지터가 있는 지수 백오프로 폴백해요. 재시도 횟수와 총 재시도 시간을 모두 제한하세요. 쿼터·청구·사용자 조치가 필요한 오류는 재시도하지 마세요. 참고로 실패 요청도 분당 한도에 포함되므로 같은 요청을 계속 보내는 건 통하지 않아요.
지수 백오프를 직접 구현하거나 tenacity, backoff 같은 라이브러리를 쓸 수 있어요. 참고로 이 라이브러리들은 서드파티 도구라 OpenAI가 신뢰성·보안을 보장하지 않아요.
max_tokens 줄이기
rate limit은 max_tokens와 요청 문자 수로 추정한 토큰 수 중 큰 값으로 계산돼요. max_tokens를 기대 응답 크기에 최대한 가깝게 설정하세요.
배칭 (Batching)
즉시 응답이 필요 없는 사용 사례라면 Batch API로 많은 요청을 동기 rate limit에 영향 없이 제출·실행할 수 있어요. 동기 응답이 필요한 경우엔 요청당 더 많은 작업을 묶어 분당 요청 한도에 닿았지만 분당 토큰 여유가 있을 때 처리량을 늘릴 수 있어요.