Câu trả lời ngắn gọn: đừng chuyển từ Claude sang GPT cho mọi yêu cầu thất bại. 401 nghĩa là phải sửa xác thực, và 404 liên quan đến đường dẫn nghĩa là URL hoặc endpoint cần được chỉnh đúng. 429 hoặc 5xx tạm thời có thể thử lại với backoff; nếu số lần thử lại có giới hạn vẫn thất bại, một mô hình dự phòng tương thích có thể tiếp quản.
Có một ngoại lệ quan trọng: phản hồi 500 với error.code: invalid_request vẫn là vấn đề của yêu cầu. Thử lại nó—hoặc gửi cùng payload bị lỗi sang mô hình khác—chỉ che giấu bug.
Bài viết này được xác minh vào ngày 20 tháng 8, 2026 đối chiếu với tài liệu của CometAPI về lỗi, thử lại, base URL, giới hạn tốc độ và mô hình dự phòng. Nội dung chỉ bao gồm phân loại lỗi. Về thiết kế route, thông tin xác thực của nhà cung cấp, và failover nhiều lớp, hãy xem hướng dẫn đầy đủ về dự phòng mô hình và hướng dẫn kỹ thuật về dự phòng.
Bắt đầu bằng quyết định thử lại hay thất bại
| Trạng thái | Thường có nghĩa là | Thử lại? | Dùng dự phòng? | Hành động đầu tiên |
|---|---|---|---|---|
| 401 | Thiếu hoặc khóa không hợp lệ | Không | Không | Sửa token Bearer |
| 404 | Sai đường dẫn hoặc endpoint | Không | Không | Kiểm tra base URL và route |
| 429 | Giới hạn tốc độ hoặc bão hòa | Có | Sau số lần thử lại có giới hạn | Giãn thời gian với jitter |
| 500 + invalid_request | Yêu cầu bị lỗi cấu trúc | Không | Không | Sửa payload |
| 500/503/504/524 | Sự cố tạm thời của nền tảng hoặc nhà cung cấp | Có | Sau số lần thử lại có giới hạn | Giữ lại request ID |
Câu hỏi thực tế không phải là “Claude có thất bại không?” mà là “Một mô hình khác có thể thành công mà không cần thay đổi phần không hợp lệ của yêu cầu này không?” Lỗi xác thực và đường dẫn ảnh hưởng đến chính kết nối, nên đổi mô hình không thể giải quyết. Sự cố về năng lực tạm thời và lỗi máy chủ có thể phụ thuộc vào route, vì vậy dự phòng có thể hữu ích.
Đọc lỗi trước khi chuyển mô hình
Sử dụng mã trạng thái HTTP cùng với error.code và error.message. Nhiều lỗi của CometAPI dùng cấu trúc bao như sau:
{
"error": {
"message": "human-readable detail and request id",
"type": "comet_api_error",
"param": "problematic_parameter_or_empty",
"code": "error_code_or_empty"
}
}
Đừng phân loại chỉ theo chữ số đầu tiên của mã trạng thái. Một 500 vẫn có thể mang invalid_request, trong khi đường dẫn CometAPI sai có thể trả về chuyển hướng hoặc HTML thay vì 404 JSON rõ ràng.
401 Unauthorized: Dừng lại và sửa xác thực
401 thường nghĩa là API key bị thiếu, sai định dạng, hết hạn, hoặc tải từ môi trường không đúng. Header phải là:
Authorization: Bearer $COMETAPI_KEY
Đừng thử lại và đừng đổi mô hình. Cả hai route đều dùng cùng xác thực bị lỗi. Kiểm tra xem dịch vụ triển khai có tải bí mật cũ không, có khoảng trắng thêm vào key không, và yêu cầu có đi đến môi trường dự định không. Xoay vòng hoặc nạp lại key chỉ thông qua quy trình quản lý bí mật của bạn.
404 Not Found: Sửa URL trước khi dùng dự phòng
Đối với yêu cầu tương thích OpenAI, hãy dùng chính xác base URL này:
https://api.cometapi.com/v1
Thiếu /v1, lặp đoạn đường dẫn, hoặc endpoint sai có thể tạo 404, một chuyển hướng, phản hồi HTML, hoặc lỗi phân tích của SDK. Tắt tự động theo chuyển hướng khi gỡ lỗi và xác nhận đường dẫn yêu cầu cuối cùng theo tài liệu API.
Nếu phản hồi nói rõ một mô hình không khả dụng hoặc không tìm thấy, hãy xác minh model ID trong CometAPI Models API hiện tại. Đừng coi mọi 404 là mô hình không khả dụng. Chỉ thêm dự phòng theo mô hình sau khi bạn đã ghi nhận và kiểm thử đúng tín hiệu đó.
429 Too Many Requests: Giãn thời gian trước khi chuyển dự phòng
429 có thể thử lại. Dùng backoff hàm mũ với jitter, giảm độ đồng thời bùng nổ, và đo route nào đang bão hòa. Thử lại ngay lập tức từ mọi worker có thể biến một giới hạn ngắn thành một đợt tăng lưu lượng lớn hơn.
Sau một số lần thử lại nhỏ, có giới hạn, dự phòng có thể phù hợp khi mô hình kế tiếp hỗ trợ cùng hợp đồng đầu vào/đầu ra và năng lực cần thiết. Dự phòng không miễn phí: nó tăng độ trễ và có thể thay đổi chi phí hoặc hành vi, nên hãy ghi nhận tần suất sử dụng.
Lỗi 5xx: Kiểm tra mã lỗi, rồi thử lại
500, 503, 504, và 524 thường đại diện cho sự cố nền tảng, nhà cung cấp, hoặc loại timeout. Giữ lại request ID, endpoint, mô hình, và timestamp, rồi thử lại với backoff. Nếu cùng lỗi tạm thời vẫn tồn tại sau ngân sách thử lại, chuyển sang route tương thích kế tiếp.
Nhưng hãy kiểm tra body trước. Khi một 500 chứa error.code: invalid_request hoặc invalid_request_error, hãy sửa phần thân yêu cầu và chỉ thử lại sau khi nó đã thay đổi. Các nguyên nhân phổ biến gồm thiếu trường messages hoặc một tham số riêng của nhà cung cấp mà endpoint đã chọn không chấp nhận.
Dùng một chính sách nhỏ trong code
Ví dụ Python này giữ thử lại và dự phòng trong ứng dụng. Nó dùng một key CometAPI, base URL tương thích OpenAI, và biến môi trường cho model ID Claude và GPT hiện hành. Nó chỉ thử lại các lỗi tạm thời, rồi đổi mô hình sau khi dùng hết ngân sách thử lại.
import os, random, time
from openai import APIError, OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_KEY"],
base_url="https://api.cometapi.com/v1",
max_retries=0,
)
MODELS = [os.environ["CLAUDE_MODEL"], os.environ["GPT_MODEL"]]
RETRYABLE = {429, 500, 503, 504, 524}
def complete(messages):
for model in MODELS:
for attempt in range(3):
try:
response = client.chat.completions.create(model=model, messages=messages)
return response.choices[0].message.content
except APIError as error:
status = getattr(error, "status_code", None)
code = getattr(error, "code", None)
if status in {401, 404} or code in {
"invalid_request", "invalid_request_error"
}:
raise
if status not in RETRYABLE:
raise
if attempt < 2:
time.sleep(2**attempt + random.random())
continue
break
raise RuntimeError("No configured route completed.")
print(complete([{"role": "user", "content": "Summarize this ticket."}]))
Tính năng thử lại tự động của SDK được tắt để ứng dụng kiểm soát tổng ngân sách thử lại và dự phòng. Nếu không có kiểm soát đó, thử lại của SDK cộng với thử lại của ứng dụng có thể nhân số lần gọi và làm chậm phản hồi cuối cùng.
Kiểm thử chính sách mà không đoán mò
| Tín hiệu mô phỏng | Kết quả mong đợi | Điều không được xảy ra |
|---|---|---|
| 401 | Raise ngay lập tức | Không thử lại và không gọi GPT |
| 404 | Raise ngay lập tức | Không dự phòng che đường dẫn sai |
| 429 | Backoff, rồi dự phòng | Không tạo bão thử lại ngay |
| 500 + invalid_request | Raise ngay lập tức | Không gửi trùng yêu cầu bị lỗi |
| 503/504/524 | Backoff, rồi dự phòng | Không tạo chuỗi route vô hạn |
Đây là các kiểm thử chính sách, không phải các nhận định về độ tin cậy thực tế của nhà cung cấp. Trong staging, hãy tiêm mã trạng thái và body lỗi vào bộ phân loại, xác minh số lượng và thứ tự các lần gọi, và đảm bảo lỗi cuối cùng của bạn vẫn bao gồm ngữ cảnh yêu cầu ban đầu.
Khi dự phòng Claude-to-GPT thực sự an toàn
Chuyển họ mô hình chỉ an toàn khi cả hai route đều có thể đáp ứng cùng hợp đồng ứng dụng. Chuẩn hóa các trường yêu cầu và phản hồi, kiểm thử đầu ra có cấu trúc hoặc hành vi tool trên cả hai mô hình, và xác minh mọi năng lực cần thiết về hình ảnh, tài liệu, ngữ cảnh, hoặc suy luận trước khi bật route.
Dự phòng cũng phải tôn trọng các tác động phụ. Nếu route đầu tiên đã kích hoạt một tool, ghi dữ liệu, hoặc stream phản hồi một phần, lặp lại mù quáng toàn bộ yêu cầu có thể nhân bản hành động hoặc gây nhầm cho người dùng. Hãy tiếp tục từ một checkpoint hoặc trả về lỗi có kiểm soát.
Kiểm soát sản xuất giúp giữ thử lại trong giới hạn
- Đặt một ngân sách độ trễ tổng. Tính mọi lần thử lại và dự phòng vào cùng hạn chót.
- Giới hạn thử lại. Dùng backoff với jitter và dừng sau một ngưỡng cấu hình nhỏ.
- Kiểm soát độ đồng thời. Giảm bùng nổ trước khi yêu cầu rời ứng dụng.
- Thêm circuit breaker. Tạm thời dừng gọi một route liên tục thất bại.
- Ghi log quyết định. Thu thập trạng thái, mã lỗi, request ID, mô hình, lần thử, độ trễ, và lý do dự phòng mà không lưu trữ bí mật.
- Theo dõi tỷ lệ dự phòng. Mức tăng kéo dài là tín hiệu vận hành, không phải chỉ số thành công bình thường.
Câu hỏi thường gặp
401 có bao giờ kích hoạt dự phòng mô hình không?
Không. Hãy sửa hoặc nạp lại API key. Một mô hình khác được gọi qua cùng thông tin xác thực sai sẽ thất bại vì cùng lý do.
404 có nên kích hoạt dự phòng?
Không theo mặc định. Trước tiên hãy sửa base URL hoặc endpoint. Chỉ tín hiệu “mô hình không khả dụng” được xác minh riêng mới nên đưa vào bộ phân loại dự phòng.
Nên thử lại 429 bao nhiêu lần?
Dùng một giới hạn nhỏ do ứng dụng định nghĩa, phù hợp với ngân sách độ trễ hướng người dùng. Backoff với jitter và giảm độ đồng thời; đừng thử lại ngay lập tức hoặc vô thời hạn.
Có phải mọi lỗi 5xx đều có thể thử lại?
Không. Các phản hồi 500, 503, 504, và 524 tạm thời là ứng viên thử lại, nhưng 500 với invalid_request phải fail cứng cho đến khi payload được sửa.
Claude và GPT có thể dùng cùng yêu cầu không đổi không?
Chỉ với các trường chung mà ứng dụng của bạn đã kiểm thử. Tham số riêng của nhà cung cấp, định dạng công cụ, đầu ra có cấu trúc, và đầu vào đa phương thức có thể cần adapter. Chỉ đổi model ID không chứng minh được tính tương thích.
Ở đâu có triển khai dự phòng đầy đủ?
Xem Cách xây dựng chiến lược dự phòng mô hình LLM vững chắc cho kiến trúc rộng hơn, và Hướng dẫn dự phòng mô hình CometAPI cho chi tiết triển khai.
Hãy để bộ phân loại lỗi làm người gác cổng
Dự phòng tự động hữu ích khi hẹp và có thể quan sát. Hãy để lỗi xác thực, đường dẫn, và yêu cầu sai cấu trúc thất bại rõ ràng. Thử lại giới hạn tốc độ và lỗi máy chủ tạm thời bằng backoff, sau đó chỉ chuyển sang route tương thích khi đã dùng hết ngân sách thử lại. Chính sách đó biến dự phòng thành cơ chế độ tin cậy thay vì cách che giấu lỗi cấu hình.