ข้อผิดพลาด 401, 404, 429 และ 5xx ของ CometAPI: ควรลองใหม่หรือปล่อยให้ล้มเหลว?

คำตอบสั้น ๆ: อย่าสลับจาก Claude ไป GPT ทุกครั้งที่คำขอล้มเหลว 401 หมายความว่าต้องแก้การยืนยันตัวตนให้ถูกต้อง และ 404 ที่เกี่ยวกับ path หมายถึงต้องแก้ไข URL หรือ endpoint 429 หรือ 5xx ชั่วคราวสามารถลองใหม่ด้วย backoff; หากลองซ้ำแบบจำกัดแล้วยังล้มเหลว ค่อยใช้โมเดลสำรองที่เข้ากันได้

มีข้อยกเว้นสำคัญหนึ่งข้อ: การตอบกลับ 500 ที่มี error.code: invalid_request ก็ยังเป็นปัญหาที่ตัวคำขอเอง การลองใหม่ — หรือส่ง payload เดิมที่เสียไปยังโมเดลอื่น — มีแต่จะซ่อนบั๊ก

บทความนี้ได้รับการตรวจสอบเมื่อ 20 สิงหาคม 2026 เทียบกับเอกสารของ CometAPI เกี่ยวกับข้อผิดพลาด การลองซ้ำ base URL การจำกัดอัตรา และการ fallback ของโมเดล บทความนี้ครอบคลุมเฉพาะการจัดประเภทข้อผิดพลาดเท่านั้น สำหรับการออกแบบเส้นทาง ข้อมูลรับรองผู้ให้บริการ และการเฟลโอเวอร์หลายชั้น โปรดดู บทเรียนครบถ้วนเรื่องการทำโมเดล fallback และ คู่มือ fallback เชิงเทคนิค

เริ่มจากการตัดสินใจว่าจะลองใหม่หรือยุติ

คำถามที่ใช้งานได้จริงไม่ใช่ “Claude ล้มเหลวหรือไม่?” แต่คือ “โมเดลอื่นจะสำเร็จได้โดยไม่ต้องเปลี่ยนส่วนที่ไม่ถูกต้องของคำขอนี้หรือไม่?” ข้อผิดพลาดด้านการยืนยันตัวตนและ path ส่งผลกับการเชื่อมต่อเอง การเปลี่ยนโมเดลจึงไม่ช่วยปัญหาเหล่านี้ ความล้มเหลวด้านความจุและเซิร์ฟเวอร์ชั่วคราวอาจเฉพาะเส้นทาง จึงอาจใช้ fallback ช่วยได้

อ่านข้อผิดพลาดก่อนสลับโมเดล

ใช้สถานะ HTTP ร่วมกับ error.code และ error.message ความล้มเหล้าของ CometAPI จำนวนมากอยู่ในรูปแบบซองแบบนี้:

{
  "error": {
    "message": "human-readable detail and request id",
    "type": "comet_api_error",
    "param": "problematic_parameter_or_empty",
    "code": "error_code_or_empty"
  }
}

อย่าจัดประเภทโดยดูแค่หลักแรกของรหัสสถานะเพียงอย่างเดียว 500 อาจมากับ invalid_request ได้ ขณะเดียวกันการใช้ path ของ CometAPI ผิดอาจส่งกลับ redirect หรือ HTML แทน 404 แบบ JSON ที่สะอาด

401 Unauthorized: หยุดและแก้ไขการยืนยันตัวตน

401 โดยมากหมายถึงคีย์ API ขาด ผิดรูปแบบ หมดอายุ หรือโหลดมาจากสภาพแวดล้อมที่ผิด ส่วนหัวต้องเป็น:

Authorization: Bearer $COMETAPI_KEY

อย่าลองใหม่และอย่าสลับโมเดล ทั้งสองเส้นทางจะใช้การยืนยันตัวตนที่เสียเหมือนกัน ตรวจสอบว่าบริการที่ดีพลอยใช้ความลับรุ่นเก่าหรือไม่ มีช่องว่างปะปนในคีย์หรือไม่ และคำขอกำลังไปยังสภาพแวดล้อมที่ตั้งใจหรือไม่ หมุนเวียนหรือโหลดคีย์ใหม่ผ่านกระบวนการจัดการความลับเท่านั้น

404 Not Found: แก้ URL ก่อนทำ Fallback

สำหรับคำขอที่เข้ากันได้กับ OpenAI ให้ใช้ base URL นี้เท่านั้น:

https://api.cometapi.com/v1

การขาด /v1 การซ้ำส่วนของ path หรือใช้ endpoint ผิด อาจทำให้เกิด 404 การ redirect การตอบกลับ HTML หรือข้อผิดพลาดของ SDK ระหว่างการแยกวิเคราะห์ ปิดการตาม redirect อัตโนมัติระหว่างดีบัก และยืนยัน path คำขอสุดท้ายกับเอกสารอ้างอิง API

หากการตอบกลับระบุชัดว่าโมเดลไม่พร้อมใช้งานหรือไม่พบ ให้ยืนยันรหัสโมเดลใน CometAPI Models API ปัจจุบัน อย่าปฏิบัติต่อ 404 ทุกกรณีว่าเป็นการไม่มีโมเดล เพิ่ม fallback เฉพาะโมเดลหลังจากคุณจับสัญญาณนั้นและทดสอบแล้วเท่านั้น

429 Too Many Requests: ใช้ Backoff ก่อนค่อย Failover

429 สามารถลองใหม่ได้ ใช้ exponential backoff พร้อม jitter ลดความหนาแน่นของการระเบิดคำขอ และวัดว่าเส้นทางใดอิ่มตัว การลองใหม่ทันทีจากทุก worker จะเปลี่ยนการจำกัดระยะเวลาสั้น ๆ ให้เป็นการพุ่งของทราฟฟิกที่ใหญ่ขึ้น

หลังจากลองซ้ำจำนวนเล็ก ๆ ที่จำกัดแล้ว Fallback อาจเหมาะสมเมื่อโมเดลถัดไปรองรับอินพุต เอาต์พุต และความสามารถที่ต้องการแบบเดียวกัน Fallback มีต้นทุน เพิ่มเวลาแฝง และอาจเปลี่ยนพฤติกรรม จึงควรบันทึกความถี่การใช้งาน

5xx Errors: ตรวจสอบโค้ดก่อนแล้วค่อยลองใหม่

500, 503, 504 และ 524 มักแทนความล้มเหลวของแพลตฟอร์ม ผู้ให้บริการ หรือชั้น timeout ให้เก็บ request ID, endpoint, โมเดล และเวลา แล้วลองใหม่ด้วย backoff หากความล้มเหลวชั่วคราวแบบเดิมยังคงอยู่หลังใช้โควตาการลองซ้ำ ให้ย้ายไปยังเส้นทางถัดไปที่เข้ากันได้

แต่ตรวจสอบเนื้อหาก่อน เมื่อ 500 มี error.code: invalid_request หรือ invalid_request_error ให้แก้เนื้อคำขอแล้วค่อยลองใหม่ สาเหตุทั่วไป ได้แก่ ไม่มีฟิลด์ messages หรือใช้พารามิเตอร์เฉพาะผู้ให้บริการที่ endpoint ที่เลือกไม่รองรับ

ใช้นโยบายเล็ก ๆ เพียงอันเดียวในโค้ด

ตัวอย่าง Python นี้เก็บการลองซ้ำและ fallback ไว้ในแอปพลิเคชัน ใช้คีย์ CometAPI เดียว base URL ที่เข้ากันได้กับ OpenAI และตัวแปรสภาพแวดล้อมสำหรับรหัสโมเดล Claude และ GPT ปัจจุบัน ลองซ้ำเฉพาะความล้มเหลวชั่วคราว แล้วจึงเปลี่ยนโมเดลหลังจากใช้โควตาการลองซ้ำหมด

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

ปิดการลองซ้ำอัตโนมัติของ SDK เพื่อให้แอปพลิเคชันควบคุมโควตาการลองซ้ำและ fallback ทั้งหมด หากขาดการควบคุมนี้ การลองซ้ำของ SDK บวกกับการลองซ้ำของแอปพลิเคชันอาจทวีคูณจำนวนการเรียกและหน่วงการตอบกลับสุดท้าย

ทดสอบนโยบายโดยไม่ต้องเดา

สิ่งเหล่านี้เป็นการทดสอบนโยบาย ไม่ใช่การอ้างถึงความน่าเชื่อถือของผู้ให้บริการจริง ในสเตจจิง ให้ฉีดสถานะและเนื้อข้อผิดพลาดเข้าไปในตัวจัดประเภท ตรวจสอบจำนวนและลำดับของการเรียก และยืนยันว่าข้อผิดพลาดสุดท้ายของคุณยังคงมีบริบทของคำขอต้นฉบับ

เมื่อไรการ Fallback จาก Claude ไป GPT ถึงปลอดภัยจริง

การสลับตระกูลโมเดลปลอดภัยก็ต่อเมื่อทั้งสองเส้นทางตอบสนองสัญญาประชาคมของแอปพลิเคชันได้เหมือนกัน ทำให้ฟิลด์คำขอและคำตอบเป็นมาตรฐานเดียวกัน ทดสอบเอาต์พุตเชิงโครงสร้างหรือพฤติกรรมของเครื่องมือกับทั้งสองโมเดล และยืนยันความสามารถด้านภาพ เอกสาร บริบท หรือการให้เหตุผลตามที่ต้องการก่อนเปิดใช้เส้นทาง

Fallback ควรคำนึงถึง side effects ด้วย หากเส้นทางแรกได้เรียกใช้เครื่องมือ เขียนข้อมูล หรือสตรีมคำตอบบางส่วนไปแล้ว การทำซ้ำทั้งคำขอโดยไม่คิดอาจทำให้การกระทำซ้ำซ้อนหรือผู้ใช้สับสน ให้ทำต่อจากจุดตรวจสอบ หรือส่งความล้มเหลวที่ควบคุมได้แทน

เช็คลิสต์บนโปรดักชันเพื่อจำกัดการลองซ้ำ

• กำหนดงบประมาณเวลาแฝงรวมเดียว: นับทุกการลองซ้ำและ fallback ไว้ภายใต้เส้นตายเดียวกัน
• จำกัดจำนวนการลองซ้ำ: ใช้ backoff พร้อม jitter และหยุดหลังจากถึงขีดจำกัดที่ตั้งไว้
• ควบคุมความขนาน: ลดการระเบิดความหนาแน่นก่อนที่คำขอจะออกจากแอปพลิเคชัน
• เพิ่ม circuit breaker: หยุดเรียกเส้นทางที่ล้มเหลวซ้ำ ๆ ชั่วคราว
• บันทึกการตัดสินใจ: เก็บสถานะ รหัสข้อผิดพลาด request ID โมเดล ครั้งที่พยายาม หน่วงเวลา และเหตุผลในการ fallback โดยไม่เก็บความลับ
• ติดตามอัตราการ fallback: การเพิ่มขึ้นต่อเนื่องคือสัญญาณปฏิบัติการ ไม่ใช่ตัวชี้วัดความสำเร็จปกติ

คำถามที่พบบ่อย

401 ควรก่อให้เกิดการ fallback ของโมเดลหรือไม่?

ไม่ แก้ไขหรือโหลดคีย์ API ใหม่ โมเดลอื่นที่เรียกผ่านข้อมูลยืนยันตัวตนที่ไม่ถูกต้องชุดเดียวกันก็จะล้มเหลวด้วยเหตุผลเดียวกัน

404 ควรทำให้เกิด fallback หรือไม่?

ไม่ใช่โดยปริยาย ให้แก้ base URL หรือ endpoint ก่อน เพิ่ม fallback เฉพาะเมื่อสัญญาณ “โมเดลไม่พร้อมใช้งาน” ได้รับการยืนยันแยกต่างหากแล้วเท่านั้น

ควรลองซ้ำ 429 กี่ครั้ง?

ใช้ขีดจำกัดขนาดเล็กที่กำหนดโดยแอปพลิเคชันซึ่งสอดคล้องกับงบประมาณเวลาแฝงที่ผู้ใช้สัมผัส ใช้ backoff พร้อม jitter และลดความขนาน; อย่าลองใหม่ทันทีหรือไม่สิ้นสุด

ข้อผิดพลาด 5xx ทุกอย่างลองใหม่ได้หรือไม่?

ไม่ 500, 503, 504, และ 524 แบบชั่วคราวเป็นผู้สมัครสำหรับการลองใหม่ แต่ 500 ที่มี invalid_request ควรล้มเหลวทันทีจนกว่าจะปรับ payload ให้ถูกต้อง

Claude และ GPT ใช้คำขอเดียวกันแบบไม่ต้องเปลี่ยนได้หรือไม่?

ได้เฉพาะฟิลด์ที่แอปพลิเคชันของคุณทดสอบแล้วเท่านั้น พารามิเตอร์เฉพาะผู้ให้บริการ รูปแบบเครื่องมือ เอาต์พุตเชิงโครงสร้าง และอินพุตแบบหลายโมดัลอาจต้องมีตัวปรับ โมเดล ID ที่เปลี่ยนเพียงอย่างเดียวไม่ได้พิสูจน์ความเข้ากันได้

โค้ด fallback ฉบับเต็มอยู่ที่ไหน?

ดู วิธีสร้างกลยุทธ์ fallback ของโมเดล LLM ที่แข็งแรง สำหรับสถาปัตยกรรมภาพรวม และดู คู่มือการทำโมเดล fallback กับ CometAPI สำหรับรายละเอียดการนำไปใช้

ทำให้ตัวจัดประเภทข้อผิดพลาดเป็นด่านหน้าควบคุม

การ fallback อัตโนมัติมีประโยชน์เมื่อมันแคบและตรวจสอบได้ ปล่อยให้ข้อผิดพลาดด้านการยืนยันตัวตน path และคำขอที่มีรูปแบบไม่ถูกต้องล้มเหลวอย่างชัดเจน ลองใหม่สำหรับการจำกัดอัตราและความล้มเหลวของเซิร์ฟเวอร์ชั่วคราวด้วย backoff จากนั้นค่อยย้ายไปเส้นทางที่เข้ากันได้หลังจากใช้โควตาการลองซ้ำจนหมด นโยบายนี้เปลี่ยน fallback ให้เป็นเครื่องมือตรวจสอบความน่าเชื่อถือ แทนที่จะเป็นวิธีซ่อนบั๊กการกำหนดค่า

แหล่งข้อมูล

• รหัสข้อผิดพลาดและการจัดการของ CometAPI
• กลยุทธ์ข้อผิดพลาดและการลองซ้ำของ CometAPI
• การจำกัดอัตราและการทำงานพร้อมกันของ CometAPI
• คู่มือ base URL ของ CometAPI
• คู่มือ fallback ของโมเดลและผู้ให้บริการของ CometAPI
• บทเรียนครบถ้วนเรื่องการทำโมเดล fallback