Claude API 500 api_error và 502 Bad Gateway — chính sách thử lại thực sự khôi phục được dịch vụ

Phân biệt 500 với 529 và 429 trước khi chọn cách khắc phục

429 là giới hạn tốc độ bạn đang vượt quá — hãy giảm tốc độ. 529 là nhà cung cấp đã đạt công suất — hãy backoff mạnh hơn và lâu hơn nhiều. 500/502 là lỗi, thường ngắn và thường chỉ ảnh hưởng đến một yêu cầu. Chỉ loại thứ ba đáng được thử lại nhanh, và đối xử với cả ba như nhau là lý do các vòng lặp thử lại khiến sự cố tệ hơn.

Thử lại 5xx, không bao giờ thử lại 4xx

Exponential backoff kèm jitter, tối đa năm lần thử. Cùng một helper hoạt động cho mọi nhà cung cấp — 400 hoặc 422 sẽ thất bại giống hệt ở lần thử tiếp theo, nên thử lại chỉ làm tăng độ trễ để đi đến cùng lỗi đó.

import time, random
from openai import OpenAI, APIStatusError

client = OpenAI(base_url="https://api.kunavo.com/v1", api_key="sk-kn-...")

def with_backoff(fn, max_retries=5):
    for attempt in range(max_retries):
        try:
            return fn()
        except APIStatusError as e:
            if e.status_code not in (429, 500, 529):
                raise                      # don't retry auth/validation errors
            retry_after = e.response.headers.get("retry-after")
            delay = float(retry_after) if retry_after else min(2 ** attempt, 30)
            time.sleep(delay + random.uniform(0, 0.5))   # jitter avoids herds
    raise RuntimeError("retries exhausted")

resp = with_backoff(lambda: client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "ping"}],
    max_tokens=32,
))
print(resp.choices[0].message.content)

Giới hạn riêng thời gian đến byte đầu tiên và tổng thời lượng

Một timeout cho toàn bộ yêu cầu không thể phân biệt quá trình sinh nội dung lâu với kết nối đã chết. Đặt deadline ngắn cho byte đầu tiên và deadline rộng rãi cho phần còn lại; khi đó kết nối treo sẽ thất bại nhanh, còn câu trả lời thực sự chậm được phép tiếp tục.

Ghi log trạng thái và độ trễ cho từng lần thử

Không có bản ghi theo từng lần thử, sau đó bạn sẽ không thể phân biệt sự cố của nhà cung cấp với timeout của chính mình. Mã trạng thái, độ trễ và số lần thử là đủ để phân biệt chúng vào sáng hôm sau.

Yêu cầu trả về 500 có bị tính phí không?

Trên Kunavo thì không — các yêu cầu thất bại được ghi nhận với chi phí bằng không. Khi thanh toán trực tiếp cho nhà cung cấp, cách tính phí có thể khác, nhưng lỗi 5xx nhìn chung không bị tính phí.

Thử lại 500 có thể tạo ra hai lần hoàn tất không?

Có. Một yêu cầu có thể thất bại sau khi mô hình đã sinh nội dung. Nếu công việc có tác dụng phụ, hãy làm cho nó idempotent ở tầng của bạn trước khi thêm cơ chế thử lại.

Khác biệt một dòng giữa 500, 502 và 529 là gì?

500 là nhà cung cấp gặp lỗi, 502 là một thành phần đứng trước không thể kết nối với nhà cung cấp, còn 529 là nhà cung cấp đã đạt công suất — hãy sớm thử lại hai lỗi đầu, nhưng chờ lâu hơn nhiều với lỗi thứ ba.