429 오류: glm-5 호출이 실패할 때 대처법

429는 속도 제한에 걸렸다는 뜻입니다. 일정 시간 내 요청 수나 토큰 수가 현재 요금제 할당량을 초과했습니다.

429 Too Many Requests 는 오류가 아니라 레이트 리밋 응답입니다. 요청 자체는 유효하지만 현재 요금제가 허용하는 요청 속도나 동시 실행 수를 초과한 것입니다. 응답 헤더가 알려주는 시간만큼 기다렸다가 재시도하면 복구되며, 요청 본문을 바꿀 필요는 없습니다.

glm-5 는 Z.AI 가 제공하며, 이 페이지의 원인 분석·처리 방법·실측 데이터는 모두 게이트웨이 계층에서 이 모델의 실제 운영 상황을 바탕으로 정리했습니다.

이 게이트웨이에서 가장 흔한 원인은 「동시 요청이 너무 많음」입니다. 우선 처리할 동작은 「동시 요청을 제한하고 지수 백오프로 재시도」입니다.

주요 원인

  • 동시 요청이 너무 많음
  • 현재 요금제 쿼터 소진
  • 대기 없이 즉시 재시도

해결 방법

  • 동시 요청을 제한하고 지수 백오프로 재시도
  • 쿼터가 큰 요금제로 변경
  • 반복 요청 캐싱

지수 백오프 재시도 예시

아래 코드는 glm-5가 429를 반환할 때 최대 5회까지 재시도합니다. 대기 시간은 점점 길어지고 무작위 지터가 더해져 동시 재시도를 막습니다. base URL과 API 키는 환경 변수에서 읽고, 코드에 하드코딩하지 마세요.

import os, time, random
import requests

BASE  = os.getenv("OPENAI_BASE_URL")   # e.g. https://<your-gateway>/v1
KEY   = os.getenv("OPENAI_API_KEY")
MODEL = 'glm-5'


def chat(messages, retries=5):
    """Retry with exponential backoff + jitter."""
    for i in range(retries):
        try:
            r = requests.post(
                BASE + "/chat/completions",
                headers={"Authorization": "Bearer " + KEY},
                json={"model": MODEL, "messages": messages, "stream": True},
                timeout=60,
            )
            if r.status_code == 429 or r.status_code >= 500:
                time.sleep(min(2 ** i + random.uniform(0, 1), 30))
                continue
            r.raise_for_status()
            return r.json()
        except requests.exceptions.Timeout:
            time.sleep(min(2 ** i + random.uniform(0, 1), 30))
    raise RuntimeError("gave up after " + str(retries) + " retries")


print(chat([{"role": "user", "content": "hello"}]))

이 모델의 핵심 데이터

API 엔드포인트https://api.airai.cc/v1
OpenAI 호환OpenAI-compatible
제공사Z.AI
컨텍스트204.8K
지원 기능Reasoning, Tools, Open Weights
API 형식openai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
과금 공식p * 1 + cr * 0.2 + cc * 0 + c * 3.2

자주 묻는 질문

429 발생 시 예비 모델로 전환해야 하나요?

아키텍처 수준에서 폴백을 두는 편이 오류를 하나씩 고치는 것보다 안정적입니다. Z.AI 의 이 모델에는 게이트웨이가 전환할 수 있는 upstream 노드가 여러 개 있습니다. 더 가벼운 예비 모델을 준비해 두면 주 흐름이 끊기지 않습니다.

타임아웃은 얼마로 설정해야 하나요?

여기서 진짜 변수는 동시성과 타임아웃이며, 모델 자체가 아닙니다. 먼저 동시성을 낮추세요. 처리량 문제의 대부분은 그것으로 사라집니다. 이 모델의 컨텍스트 윈도우는 204.8K, 벤더는 Z.AI 입니다. 동시성은 낮은 값에서 시작해 몇 분 지켜본 뒤 단계적으로 높이세요.

429 은 glm-5 의 과금 방식과 관련이 있나요?

청구되지 않습니다. 실제로 생성된 출력만 사용량에 반영됩니다. 입력 단가는 대략 $1.00 / 백만 토큰입니다. 먼저 콘솔에서 잔액과 속도 제한을 확인한 뒤 코드를 살펴보세요.

재시도하면 요청이 두 번 실행되나요?

보통 비즈니스 코드를 바꿀 필요는 없고 호출 간격만 조정하면 됩니다. 재시도가 가장 효과적인 첫 단계입니다. 과금 방식이 p * 1 + cr * 0.2 + cc * 0 + c * 3.2 인 경우, 실패한 요청은 사용량에 포함되지 않습니다. 재시도 상한을 3~5회로 정하고 지터를 추가하세요. 재시도 가능한 오류에는 지수 백오프를 쓰고, 나머지는 즉시 오류를 반환하세요.

이 모델의 다른 오류

같은 오류가 나는 다른 모델

데이터 업데이트: 2026-10-10 08:15

기술 지원온라인 상담
맨 위로