한도가 속한 서비스
이름이 혼동되기 쉽습니다. Groq는 자체 하드웨어에 모델을 호스팅하는 회사입니다. Grok는 xAI의 모델 계열입니다. 이 사이트는 둘 다 아니며, 독립적인 제공자가 운영하는 단일 오픈 웨이트 모델용 OpenAI 호환 API입니다(model ID uncensored). 따라서 특정 플랜의 분당 요청 수나 토큰 수와 같은 Groq API 속도 제한 자체를 확인하려면 Groq 콘솔이나 문서를 열고 계정에 해당하는 수치를 확인하세요. 수치는 변경되며 제가 추측하지 않습니다.
이후 내용은 당사 API에 정확히 적용되며, 이러한 습관은 모든 제공자에게 적용됩니다: 한도 헤더를 존중하고, 올바른 오류에만 재시도하며, 서버가 대신 처리하기 전에 자체 동시성을 제한하세요. Grok NSFW 설정을 위해 여기 오셨다면, 통합 가이드도 관련 오류를 다룹니다.
한도 요약
| 제한 | 전체 키 | 체험 키 |
|---|---|---|
| 동시 요청 | 8 | 2 |
| 분당 요청 수 | 300 | 60 |
| 요청 본문 | 8 MB | 8 MB |
| 컨텍스트 창 (프롬프트 및 응답) | 100,000 토큰 | 100,000 토큰 |
이 중 두 가지는 엄밀한 의미의 속도 제한으로, 분당 요청 수와 동시성입니다. 나머지 두 가지는 단일 요청의 크기 제한이며 속도 제한과 독립적입니다. 90,000 토큰 프롬프트를 가진 요청은 1줄 프롬프트와 마찬가지로 분당 300개에 대해 하나의 요청으로 계산되지만, 더 오래 걸리고 슬롯을 더 오래 점유합니다.
$0.50 체험 크레딧은 가입 후 API 키 페이지에서 한 번의 클릭으로 받을 수 있으며, 체험 한도를 사용합니다. 전체 키 한도는 충전 후에 적용됩니다.
3가지 유형의 429
모든 한도 오류는 HTTP 429로 발생하지만, 의미와 대응 방법이 다릅니다.
rate_limited: 분당 허용량을 초과한 요청을 보냈습니다. 속도를 줄이세요. 창은 1분이므로 요청을 균등하게 간격으로 보내는 것이 긴 일시 정지보다 더 도움이 됩니다.concurrency: 동시에 너무 많은 요청이 진행 중입니다. 이전 요청이 완료될 때까지 기다리세요. 이는 스트리밍에서 흔하며, 각 요청은 전체 생성 동안 지속됩니다.- 일시적 과부하: 또한 429이며,
Retry-After: 5헤더가 있습니다. 이는 귀하의 과실이 아니며 키의 한도와 관련이 없습니다. 명시된 5초를 기다렸다가 재시도하세요.
실패한 요청은 요금이 부과되지 않으므로 재시도 루프는 최종적으로 성공한 하나의 요청 비용만 발생합니다. 응답에는 X-RateLimit-Limit-Requests 및 X-RateLimit-Limit-Concurrency가 포함되어 클라이언트가 하드 코딩된 값 대신 자체 한계를 읽을 수 있으며, 잔여 크레딧을 나타내는 X-Balance-USD와 지원팀에 문의할 때 기록하고 인용해야 하는 X-Request-Id도 포함됩니다.
처리량 계산: 분당 300을 달성하기 어려운 이유
두 한도는 상호 작용합니다. 8개의 동시 슬롯이 있으면 분당 완료할 수 있는 최대치는 8 x 60을 요청의 평균 지속 시간(초)으로 나눈 값입니다. 분당 300 요청을 실제로 달성하려면 요청의 평균 지속 시간이 8 x 60 / 300 = 1.6초여야 합니다. 더 느린 요청은 먼저 동시성으로 제한됩니다.
| 평균 요청 시간 | 전체 키(8 슬롯) 기준 분당 최대 | 체험 키(2 슬롯) 기준 분당 최대 |
|---|---|---|
| 2초 | 240 | 60 |
| 10초 | 48 | 12 |
| 20초 | 24 | 6 |
이것은 가상의 요청 시간을 위한 산술 상한선이며 우리 서비스의 측정치가 아닙니다. 직접 요청 시간을 측정하세요. 핵심은 전체 키로 20초 동안 긴 창작 생성 시 분당 24 요청으로 제한되며 허용된 300보다 훨씬 낮다는 것입니다. 더 많은 처리량이 필요하면 max_tokens로 응답을 짧게 하거나 호출당 텍스트 양을 줄여 더 높은 요청 제한을 기대하지 마세요.
세 가지 경우 모두 처리하는 클라이언트
이 Python 클라이언트는 세마포어를 사용하여 자체 동시성을 제한하고, 존재할 경우 Retry-After를 읽으며, 그렇지 않으면 작은 지터로 백오프합니다. 공식 openai 패키지를 사용합니다.
import random
import threading
import time
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI, RateLimitError
client = OpenAI(
base_url="https://api.groknsfw.top/v1",
api_key="YOUR_KEY",
max_retries=0, # we handle retries ourselves
)
slots = threading.BoundedSemaphore(8) # use 2 on the trial key
def ask(prompt, tries=6):
for attempt in range(tries):
with slots:
try:
r = client.chat.completions.create(
model="uncensored",
messages=[{"role": "user", "content": prompt}],
max_tokens=400,
)
return r.choices[0].message.content
except RateLimitError as e:
wait = e.response.headers.get("retry-after")
body = e.response.text
# sleep outside the slot so others can proceed
delay = float(wait) if wait else min(2 ** attempt, 30)
if "rate_limited" in body:
delay = max(delay, 5)
time.sleep(delay + random.random())
raise RuntimeError("still rate limited after retries")
with ThreadPoolExecutor(max_workers=8) as pool:
results = list(pool.map(ask, ["Write one line about the sea."] * 20))
print(len(results))Node의 동일한 아이디어는 최대 8개의 대기 중인 프라미스를 허용하는 작은 큐이며, 아래 curl 확인은 한도 헤더를 인쇄하여 키의 한도를 확인할 수 있게 합니다:
curl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
-H "Authorization: Bearer YOUR_KEY" | grep -i "x-"스트리밍, 긴 프롬프트 및 컨텍스트
stream: true가 있는 스트리밍 요청은 마지막 이벤트가 도착할 때까지 동시성 슬롯을 유지합니다. 이는 느린 리더가 귀하에게 영향을 미친다는 것을 의미합니다: 각 청크를 처리하는 동안 코드가 일시 정지되면 슬롯이 점유된 상태로 유지됩니다. 스트림을 즉시 소비하세요.
긴 프롬프트는 두 가지 방식으로 한도와 상호 작용합니다. 첫째, 처리하는 데 더 많은 시간이 걸리므로 위의 공식에 따라 처리량을 낮춥니다. 둘째, 응답과 함께 100,000 토큰 창에 맞춰야 하므로 여백을 유지하세요. 오래된 대화 턴을 잘라내면 두 문제 모두에 도움이 되며, 동일한 정리가 청구액을 줄입니다: 입력 토큰 1M당 $0.15로, 20,000 토큰의 기록을 다시 보낼 때마다 $0.003의 비용이 발생합니다.
요청 형식의 세부 사항은 빠른 시작에 있으며, 요금은 가격 책정 페이지에 있습니다.
자신의 사용자에게 한도 표시
속도 제한도 제품 결정입니다. 앱이 최종 사용자와 API 사이에 있다면, 원시 429가 그들에게 도달해서는 안 됩니다. 대신 그들이 무엇을 볼지 미리 결정하세요.
- 채팅 앱의 경우 짧은 "생성 중" 상태를 표시하고 메시지를 큐에 넣으세요. 화면에 활동이 있다면 몇 초의 대기는 대부분의 사용자에게 보이지 않습니다.
- 배치 도구의 경우, 완료된 항목의 카운트로 진행 상황을 표시하고 작업을 백그라운드에서 실행하세요. 재시도는 내부적이어야 하며 오류로 표시되지 않아야 합니다.
- 공유 배포의 경우, 자체 코드에서 각 사용자에게 작은 사용자별 할당량을 제공하여 한 사용자가 다른 사용자의 모든 8개 슬롯을 차지하지 않도록 하세요.
모든 실패에 대해 세 가지 항목을 기록하세요: X-Request-Id, 오류 코드 및 앱이 그 순간 진행 중이었던 요청 수. 이러한 정보를 통해 몇 분 내에 잘못된 클라이언트와 실제 부하를 구분할 수 있습니다. 문제가 서버 측에 있는 것처럼 보이면 요청 ID가 지원이 먼저 요청할 것입니다.
마지막으로 의도적으로 실패 경로를 테스트하세요. 의도적으로 세마포어를 낮게 설정한 클라이언트와 높은 클라이언트로 실행하고 로그가 무엇을 보여주는지 확인하세요. 한 번도 실행되지 않은 재시도 루프는 신뢰할 수 없습니다. 동시 요청이 2개만 허용되는 체험 키는 짧은 스크립트로 concurrency 오류를 쉽게 발생시키고 코드 반응을 볼 수 있는 편리한 장소이며, 요청당 몇 분의 1센트의 비용이 듭니다.
일반적인 실수
대부분의 429 문제는 몇 가지 패턴으로 인해 발생합니다.
- 즉시 재시도하기 모든 실패 시 재전송하는 루프는 한 번의 초과 순간을 폭풍으로 바꿉니다. 기다리고, 지터를 추가하며, 시도 횟수를 제한하세요.
- 모든 것을 재시도하기. 429 및 일시적 서버 오류에만 재시도가 필요합니다. 잘못된 요청이나 잘못된 키는 항상 동일한 방식으로 실패합니다.
- 스트림을 카운트에 포함하는 것을 잊기. 전체 키의 10개 열린 채팅 창은 10개의 스트림일 수 있으며, 이는 8개 슬롯보다 2개 더 많습니다.
- 타임아웃을 설정하지 않기 응답이 없는 연결은 슬롯을 계속 점유합니다. HTTP 클라이언트에 각 요청에 적절한 타임아웃을 설정하세요.
- 평균을 기준으로 크기 조정하기 트래픽은 버스트로 들어옵니다. 일일 평균이 아닌 가장 바쁜 1분을 위해 계획하세요.
출시 전 용량 계획
최대 부하에서 역산하세요. 동시에 30명의 사용자가 채팅하고 각 응답이 약 15초 동안 스트리밍된다고 가정하면, 모든 사용자가 전송하는 순간 30개의 슬롯이 필요하며, 전체 키는 8개를 제공합니다. 나머지는 자체 앱에서 큐에 넣고 짧은 대기 시간을 표시하며 슬롯이 비면 처리하세요. 8개의 슬롯과 15초 응답으로 분당 8 x 60 / 15 = 32개의 응답을 완료할 수 있습니다.
배치 작업의 경우, 동시성 제한과 동일한 고정 작업자 풀을 실행하고 재시도 로직이 일시적 과부하를 처리하도록 하세요. 한도를 우회하는 대신 큐를 구축하세요: 이는 예측 가능한 동작을 제공하고 사용자에게 실제 대기 시간을 표시할 수 있게 합니다.
