Lỗi 503: cần làm gì khi gọi glm-4.6 thất bại

Mã 503 nghĩa là dịch vụ tạm thời không khả dụng, thường do bảo trì hoặc quá tải. Khác với 429, đây không phải hạn ngạch của bạn mà là vấn đề năng lực phía máy chủ.

503 Service Unavailable nghĩa là dịch vụ hiện không thể xử lý request, thường do quá tải hoặc bảo trì. Phân biệt với 429 rất quan trọng: 429 là hết hạn mức của bạn, 503 là server thiếu năng lực. Hãy tăng khoảng backoff thay vì đổi key.

glm-4.6 được Z.AI cung cấp. Mọi nội dung trên trang này — nguyên nhân, cách xử lý và dữ liệu đo được — đều tổng hợp từ hoạt động thực tế của mô hình này tại lớp gateway.

Tại gateway này, nguyên nhân thường gặp nhất là: Mô hình thượng nguồn quá tải. Hành động đầu tiên nên làm là: Thử lại sau với khoảng chờ dài hơn.

Nguyên nhân thường gặp

  • Mô hình thượng nguồn quá tải
  • Dịch vụ đang bảo trì hoặc phát hành dần
  • Nút ở khu vực của bạn không khả dụng
  • Lưu lượng tăng đột ngột

Cách khắc phục

  • Thử lại sau với khoảng chờ dài hơn
  • Chuyển sang mô hình tương đương ít tải hơn
  • Tránh chạy tác vụ hàng loạt vào giờ cao điểm
  • Theo dõi thông báo của chúng tôi

Ví dụ thử lại với backoff luỹ thừa

Đoạn mã dưới sẽ thử lại khi glm-4.6 trả về 503, tối đa 5 lần, thời gian chờ tăng dần kèm jitter ngẫu nhiên để các request đồng thời không retry cùng lúc. Hãy đọc base URL và API key từ biến môi trường, đừng hardcode vào code.

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-4.6'


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"}]))

Dữ liệu chính của mô hình này

Điểm cuối APIhttps://api.airai.cc/v1
Tương thích OpenAIOpenAI-compatible
Nhà cung cấpZ.AI
Ngữ cảnh204.8K
Khả năngReasoning, Tools, Open Weights
Định dạng APIopenai, openai-response, openai-response-compact, anthropic, gemini, openai-alpha-search
Công thức tính phíp * 0.6 + cr * 0.11 + cc * 0 + c * 2.2

Câu hỏi thường gặp

Chuyển sang model tương đương của hãng khác có giải quyết 503 không?

Nên chuẩn bị sẵn một model dự phòng. Có phương án dự phòng ở cấp kiến trúc thì đáng tin hơn là vá từng lỗi một. Model này của Z.AI có nhiều node upstream để gateway chuyển đổi. Chuẩn bị sẵn một mô hình dự phòng nhẹ hơn để luồng chính không bị gián đoạn. Đưa tên mô hình vào config, đổi upstream sẽ không cần sửa code.

503 có liên quan cách tính phí của glm-4.6 không?

Không bị tính phí, chỉ output thực sự được tạo mới tính vào sử dụng. Giá input khoảng $0.60 / triệu token. Kiểm tra số dư và giới hạn tốc độ trong console trước, rồi mới xem code. Khi ước tính chi phí từ p * 0.6 + cr * 0.11 + cc * 0 + c * 2.2, hãy tính cả ngân sách thử lại.

Context dài có làm 503 dễ xảy ra hơn không?

Cần đổi tham số request, chỉ thử lại sẽ không giúp được. Đây là lỗi cấu hình phía client, phía server không cần đổi. Nhãn năng lực là Reasoning, Tools, Open Weights, và giới hạn tham số bắt nguồn từ tập năng lực đó. Cửa sổ ngữ cảnh 204.8K quyết định đầu vào tối đa mỗi request; vượt quá sẽ bị từ chối ngay. Với lỗi tham số, hãy thất bại nhanh thay vì lãng phí lần thử lại. Cắt ngắn hoặc tóm tắt đầu vào dài — giảm 503 một cách rõ rệt.

Khi glm-4.6 trả về 503 nên đặt khoảng retry bao lâu?

Thường không cần sửa code nghiệp vụ, chỉ cần điều chỉnh nhịp gọi. Với cách tính phí p * 0.6 + cr * 0.11 + cc * 0 + c * 2.2, các request thất bại không được tính vào mức sử dụng. Đặt giới hạn thử lại ở 3–5 lần và thêm jitter. Dùng exponential backoff cho lỗi có thể thử lại, và trả lỗi ngay cho các lỗi còn lại.

Lỗi khác của mô hình này

Các mô hình khác gặp cùng lỗi

Dữ liệu cập nhật: 2026-10-11 13:20

Hỗ trợ kỹ thuậtHỗ trợ trực tuyến
Về đầu trang