LLM API 속도 제한 비교 (2026): 5개 벤더, 5가지 규칙

다섯 개의 LLM API, 다섯 가지 속도 제한 (rate-limit) 규칙: Anthropic은 분당 토큰 (10M, 캐시 무료)을 제한하며, DeepSeek은 동시성 (500)을 제한하고, OpenAI와 Google은 대시보드 전용으로 전환했습니다.

요약 (TL;DR). LLM API 속도 제한을 순위 매기는 단일 테이블은 존재하지 않습니다. 왜냐하면 가장 큰 5개 벤더가 측정하는 기준이 서로 다르기 때문입니다. Anthropic은 분당 요청 (requests), 입력 토큰 (input tokens), 출력 토큰 (output tokens)을 제한하며, 캐시 읽기 (cache reads)는 제한에 포함되지 않습니다. Moonshot과 OpenAI는 지출이 많아질수록 한도를 높여줍니다. DeepSeek은 분당 속도 제한을 완전히 무시하고, 동시에 실행할 수 있는 요청의 수를 제한합니다. Google과 OpenAI는 모두 모델별 수치를 공개 문서에서 제거하고 대시보드로 옮겼습니다. 유용한 질문은 "누구의 RPM(분당 요청 수)이 가장 높은가"가 아닙니다. 여러분의 앱이 실제로 API를 호출하는 방식에 어떤 제한 설계가 맞는지, 그리고 어떤 제한에 먼저 걸리든 어떻게 우회할 것인지가 핵심입니다.

A rate limit (속도 제한)은 순위를 매길 수 있는 단일 숫자가 아닙니다. Anthropic은 분당 토큰을 계산하고, DeepSeek은 진행 중인 요청 (requests in flight)을 계산하며, OpenAI는 사용자가 얼마나 지불했는지를 계산합니다. 이들을 하나의 열에 나열하는 것은 범주 오류 (category error)입니다.

다음은 어떤 종류의 워크로드 (workload)가 어떤 제한에 걸리기 쉬운지를 나타낸 것이며, 이를 통해 귀하에게 적합한 벤더 설계를 선택할 수 있습니다.

모두가 원하는 단 하나의 테이블 (그리고 그것이 일치하지 않는 이유)

모든 "속도 제한 비교" 포스트는 열을 훑어보며 승자를 선택할 수 있는 그리드 (grid)를 약속합니다. 하지만 벤더들이 제한(limit)이 무엇인지에 대해 서로 동의하지 않기 때문에, 이 그리드는 접촉하자마자 무너집니다. 여기 정직한 버전이 있습니다: 동일한 5개의 열을 사용하되, 그 열들이 서로 일치하지 않는다는 사실을 채워 넣은 결과입니다.

어떤 행을 읽더라도 그 형태가 달라집니다. 세 곳의 벤더는 정확한 모델별 수치를 보여주지만, 두 곳은 그렇지 않습니다. 두 곳은 토큰을 기준으로 제한하고, 한 곳은 진행 중인 요청(requests in flight)을 기준으로 제한하며, 두 곳은 주로 계정을 통해 지불한 금액을 기준으로 제한합니다. 이러한 불일치가 실제 발견된 핵심 사항이며, 이 포스트의 나머지 내용은 여러분이 429 에러를 받았을 때 각 셀이 무엇을 의미하는지에 대해 다룹니다.

아래의 모든 수치는 2026-07-22 기준으로 각 벤더의 공식 속도 제한 (rate-limit) 문서에서 추출되었습니다. 벤더가 더 이상 모델별 수치를 공개하지 않는 경우, 이 포스트는 추측하는 대신 그 사실을 명시합니다.

Anthropic: 세 가지 축, 그리고 캐시 읽기(Cache Reads)는 무료

Anthropic은 다섯 곳 중 가장 투명하며, 동시에 가장 다차원적입니다. 모든 모델 클래스는 세 가지 축에 대해 동시에 제한을 받습니다: 분당 요청 수 (RPM), 분당 입력 토큰 (ITPM), 그리고 분당 출력 토큰 (OTPM)입니다. 이 중 어느 하나라도 초과하면 retry-after 헤더와 함께 429 에러를 받게 되며, 해당 헤더는 정확히 얼마나 기다려야 하는지 알려줍니다. 버킷은 지속적으로 채워지므로 (토큰 버킷, token bucket), 고정된 리셋 시간을 기다릴 필요가 없습니다.

티어는 Start, Build, Scale, 그리고 Custom으로 나뉩니다. 티어를 직접 구매하여 올라가는 것이 아니라, 조직의 사용 이력과 계정 상태에 따라 자동으로 상향됩니다. 각 티어에는 월간 지출 한도 (monthly spend cap)가 있습니다:

모델별 수치는 Anthropic이 실제로 상세 정보를 공개하는 부분입니다. Opus 4.8, 4.7, 4.6, 4.5가 하나의 통합 버킷을 공유하는 Claude Opus 4.x의 경우 다음과 같습니다:

가장 눈에 띄는 점이자 Anthropic의 한계치가 겉보기보다 높은 이유는 바로 캐시 인식 ITPM (cache-aware ITPM) 규칙입니다. 대부분의 Claude 모델의 경우, cache_read_input_tokens는 ITPM에 포함되지 않습니다. 캐시에 기록된 토큰과 일반 입력 토큰은 여전히 카운트되지만, 캐시에서 다시 읽어온 토큰은 속도 제한 (rate limit)을 받지 않습니다. Anthropic이 직접 제시한 예시를 보면: 2,000,000 ITPM 제한 환경에서 캐시 히트율 (cache hit rate)이 80%라면, 분당 약 10,000,000개의 총 입력 토큰을 밀어 넣을 수 있습니다. 이는 8M의 캐시된 토큰이 제한 사항에 등록되지 않기 때문입니다. Claude Haiku 3.5는 캐시 읽기(cache reads)를 여전히 카운트하는 유일한 예외입니다.

만약 입력값의 큰 비중이 안정적인 시스템 프롬프트 (system prompt)이거나 매 호출마다 보내는 긴 문서라면, 이 규칙은 티어(tier)를 올리는 것보다 더 효과적으로 처리량 (throughput)을 변화시킵니다. 저희는 프롬프트 캐싱 비용 계산 (the prompt-caching cost math)에서 이 부분의 비용 측면을 다루었으며, 속도 제한 측면은 비용 대신 처리량을 향상시키는 동일한 레버(lever) 역할을 합니다.

팀들이 미처 인지하지 못하는 두 가지 각주가 있습니다: 메시지 배치 API (Message Batches API)는 별도의 제한을 가지며, 관리형 에이전트 (Managed Agents) 또한 별도의 제한(생성 엔드포인트의 경우 300 RPM, 읽기 엔드포인트의 경우 1,200 RPM)을 가집니다. 배치 트래픽에서 한계에 부딪혔다고 해서 Messages API의 제한을 모두 소진했다는 의미는 아닙니다.

Moonshot / Kimi: 네 가지 차원을 동시에, 유료 결제로 등반하기

Moonshot은 이 그룹 중에서 가장 명시적인 유료 결제 기반의 티어 사다리 구조를 가지고 있습니다. 티어는 $1에서 $3,000까지의 누적 충전 금액에 의해 순수하게 결정되며, 각 티어는 동시성 (concurrency), RPM, TPM, 그리고 일일 토큰량 (TPD)이라는 네 가지 다이얼을 동시에 움직입니다.

USD로 청구되는 국제 플랫폼 (platform.kimi.ai)의 티어 정보는 다음과 같습니다:

이 수치들을 다른 무엇과 비교하기 전에 반드시 알아두어야 할 함정이 하나 있습니다: Moonshot은 두 개의 별도 플랫폼을 두 개의 별도 계층(ladder)으로 운영합니다. 국제 플랫폼 (platform.kimi.ai, platform.moonshot.ai로도 접속 가능)은 USD로 측정되며, API를 호출하기 전에 $1의 충전(top-up)이 필요합니다. 중국 본토 플랫폼 (platform.moonshot.cn)은 ¥0에서 시작하여 ¥50 / ¥100 / ¥500 / ¥5,000 / ¥20,000 단계로 올라가는 자체 RMB 계층을 가지고 있습니다. 이 둘은 서로 통화를 변환한 것이 아니며, 진입 조건도 다릅니다. 하나는 첫 결제를 통해 제한을 해제해야 하지만, 다른 하나는 그렇지 않습니다. 티어를 가정하기 전에 귀하의 키(key)가 어느 플랫폼에 속해 있는지 확인하십시오.

Tier 0에서 Tier 1로의 도약은 주목할 만합니다: $9를 추가로 충전하면 3 RPM 및 단일 동시 요청(single concurrent request) 상태에서 200 RPM 및 50 동시 요청 상태로 전환되며, 일일 토큰 상한선(daily token ceiling)이 완전히 제거됩니다. Tier 0는 무언가를 구축하기 위한 단계라기보다, 단순히 "실제 사용자임을 증명"하는 최소한의 바닥 단계에 불과합니다.

티어 표에서 보여주지 않는 한 가지가 있습니다: 개별 모델은 귀하의 티어와 별개로 용량 제한(capacity-constrained)을 받을 수 있습니다. Kimi K3와 같이 새로 출시된 모델은 귀하가 티어 제한에 전혀 근접하지 않았음에도 불구하고, 업스트림 용량 문제로 인해 429 에러를 반환할 수 있습니다. 이는 제한 사항이 귀하의 계정 속도(rate)가 아니라 해당 모델에 대한 제공업체의 전체 여유 용량(total headroom)이기 때문입니다. 이런 상황이 발생하면 더 높은 티어를 구매하는 것은 도움이 되지 않습니다. 해결책은 다른 모델로 폴백(fallback)하는 것이며, 이는 이 포스트의 뒷부분에서 다룰 라우팅 패턴(routing pattern)입니다.

DeepSeek: RPM은 전혀 없음, 오직 동시성만 존재

DeepSeek는 모든 비교 그리드를 깨뜨리는 예외적인 존재입니다. RPM이나 TPM 제한을 공개하지 않습니다. 대신 계정 수준에서 한 번에 처리할 수 있는 요청 수인 동시성(concurrency)을 제한합니다:

한도(cap)를 넘지 않는다면 모델이 응답을 반환하는 속도만큼 빠르게 요청을 보낼 수 있습니다. 이를 초과하면 429 에러를 받게 됩니다. 속도를 조절하기 위해 고려해야 할 분당 예산(per-minute budget)이 없으므로, 병렬 워크로드(parallel workloads)를 처리할 때 논리적으로 이해하기가 훨씬 쉽습니다. 즉, 워커 풀(worker pool)의 크기를 동시성 한도(concurrency cap)에 맞춰 설정하면 분당 토큰 수(tokens per minute)에 대해 더 이상 걱정할 필요가 없습니다.

DeepSeek은 과부하를 처리하는 방식도 다릅니다. 서버가 바쁠 때 요청을 거부하는 대신, 연결을 유지(keep alive)하며 비스트리밍(non-streaming) 호출에는 빈 줄을 보내고, 스트리밍(streaming) 호출에는 SSE : keep-alive 주석을 보냅니다. 그리고 추론(inference)이 10분 동안 시작되지 않을 경우에만 연결을 종료합니다. 할당량(quota)이 확장된 계정은 user_id 파라미터를 사용하여 최종 사용자별로 동시성을 격리할 수도 있는데, 이는 하나의 키를 통해 많은 고객을 멀티플렉싱(multiplexing)하는 경우에 중요합니다. 만약 에이전트 루프(agent loop)에서 DeepSeek을 실행한다면, 저희의 DeepSeek V4 Pro 실제 비용 분석에서 동시성 모델이 캐시 미스(cache misses) 및 비용 청구 시의 사고 토큰(thinking tokens)과 어떻게 상호작용하는지 다루고 있습니다.

OpenAI: 지출액에 따른 티어, 베일에 싸인 수치들

OpenAI는 여전히 누적 결제 금액을 기준으로 6개의 티어(tier)를 나누어 제한을 둡니다.

제한 요소는 RPM(분당 요청 수), RPD(일당 요청 수), TPM(분당 토큰 수), TPD(일당 토큰 수), 분당 이미지 수, 그리고 일부 스트리밍 모델의 경우 분당 오디오 시간 등 매우 다양합니다. 제한 범위 내에 있을 때, 응답에는 x-ratelimit-limit-requests, x-ratelimit-remaining-requests 및 그에 상응하는 토큰 관련 헤더가 포함되어 실시간으로 남은 여유 공간(headroom)을 확인할 수 있습니다.

여기서 표를 무너뜨리는 결정적인 차이점이 있습니다. OpenAI의 속도 제한 (rate-limit) 문서는 더 이상 모델별 구체적인 RPM 또는 TPM 수치를 나열하지 않습니다. 해당 페이지는 실제 수치를 확인하기 위해 모델 페이지나 계정 대시보드로 사용자를 안내합니다. 이는 불평할 만한 실수(oversight)가 아니라, 하나의 데이터 포인트입니다. OpenAI는 모델별 속도 제한이 매우 빈번하게 변동되어 정적인 표를 제공하는 것이 오히려 오해를 불러일으킬 수 있다고 판단했으며, 이에 따라 수치는 사용자의 계정 및 티어 (tier)와 연결된 대시보드에서 관리됩니다. 따라서 OpenAI의 모델별 RPM이 고정된 것처럼 정확한 수치를 인용하는 게시물은 이미 오래되어 쓸모없게 되었을 수도 있는 스냅샷을 인용하고 있는 것입니다.

Google Gemini: 티어 (Tiers), 시간 게이트 (Time Gates), 그리고 10분 지출 창 (Spend Window)

Gemini의 티어는 결제 상태, 지출액, 그리고 경과 시간을 결합하여 결정됩니다:

3일 및 30일 요구 사항은 이례적입니다. 비용을 지불하더라도 Tier 2 또는 Tier 3에 도달하기 위한 대기 기간을 건너뛸 수 없습니다. 또한 Gemini는 일반적인 RPM / TPM / RPD 위에 지출 기반 제어를 추가로 적용하며, 이는 10분 단위의 이동 창 (rolling window) 기준으로 강제됩니다 (Tier 1은 $10, Tier 2 및 Tier 3는 $200). 따라서 분당 토큰 속도가 정상이라 하더라도 갑작스러운 지출 급증이 발생하면 제한(throttle)을 받을 수 있습니다. 한도를 초과하면 429 RESOURCE_EXHAUSTED 오류가 발생합니다.

OpenAI와 마찬가지로 Gemini도 모델별 RPM / TPM / RPD 수치를 정적 문서에 두지 않고, 활성 제한 수치를 확인할 수 있는 AI Studio 내부에 유지합니다. 또한 이 페이지의 모든 내용은 Gemini Developer API에만 적용되며, 자체적인 할당량 (quota) 시스템을 완전히 별도로 운영하는 Vertex AI에는 적용되지 않습니다.

단위가 일치하지 않는 이유 (아무도 표로 만들지 않는 부분)

한 걸음 물러나서 보면, 이러한 불일치 자체가 핵심입니다. 각 벤더에서 여유 공간 (headroom)의 단일 "단위"가 실제로 무엇을 보장하는지, 그리고 그 단위가 어디에서 병목을 일으키는지에 대한 내용은 다음과 같습니다.

수천 개의 작은 분류(classification) 호출을 보내는 팀은 RPM에 먼저 도달하며, ITPM(Input Tokens Per Minute)은 전혀 신경 쓰지 않습니다. 모든 요청에 200k 토큰 분량의 문서를 붙여넣는 팀은 RPM이 0에 가까운 상태에서도 분당 토큰 제한(token-per-minute walls)에 부딪힙니다. 50개의 병렬 에이전트(parallel agents)를 실행하는 팀은 동시성(concurrency) 제한에 걸립니다. 이 세 팀은 동일한 "최적의 속도 제한(best rate limits)" 권장 사항을 사용할 수 없습니다. 왜냐하면 이들은 세 가지 서로 다른 단위에 의해 제약을 받으며, 그 어떤 단일 순위도 이 세 팀 모두를 만족시킬 수 없기 때문입니다.

실제 사례를 통해 이 함정을 구체적으로 살펴보겠습니다. 예를 들어, 각각 30,000 토큰의 RAG 요청을 보내는 50개의 워커(workers)를 운영한다고 가정해 봅시다. DeepSeek의 deepseek-v4-pro 모델을 사용할 경우, 이는 500의 동시성 제한(concurrency cap) 대비 50개의 인플라이트(in-flight) 요청이므로, 10배의 여유분(headroom)을 가지게 되어 429 오류를 전혀 보지 않습니다. 동일한 워크로드를 분당 입력 토큰 제한이 2,000,000인 벤더로 옮긴다면, 만약 그 50개의 요청이 동일한 1분 안에 몰릴 경우, 한 번의 버스트(burst)로 1,500,000개의 입력 토큰이 소모되며 여기에 추가로 보내는 다른 토큰들이 더해집니다. 당신은 갑자기 DeepSeek에서는 추적조차 하지 않았던 제한치의 75%에 도달하게 되며, 약간의 트래픽 증가만으로도 제한을 넘어서게 됩니다. 동일한 동시성, 동일한 요청 크기임에도 불구하고, 완전히 다른 벽에 부딪히는 것입니다.

이것이 바로 벤더 간 마이그레이션(cross-vendor migration)이 사람들을 놀라게 하는 이유입니다. 전혀 신경 쓰지 않았던 제한이 당신을 괴롭히는 제한이 되며, 몇 달 동안 문제없이 작동하던 코드 경로가 제공업체를 바꾸는 날부터 429 오류를 던지기 시작합니다.

어떤 제한이 당신을 먼저 저지할 것인가 (의사결정 프레임워크)

티어를 업그레이드하거나 구조를 재설계하기 전에, 당신이 실제로 어떤 벽에 부딪히고 있는지 파악하십시오.