วิธีแก้ไขข้อผิดพลาด 429 และ Rate Limit ของ Meshy API

หาก integration ของคุณพบข้อผิดพลาด 429, RateLimitExceeded หรือ NoMoreConcurrentTasks เมื่อเรียกใช้งาน Meshy API คู่มือนี้จะอธิบายว่าทำไมจึงมีขีดจำกัดเหล่านี้ และวิธีออกแบบ integration ของคุณให้ทำงานได้อย่างเหมาะสมภายใต้ขีดจำกัดเหล่านั้น

API ของ Meshy ทำหน้าที่อยู่เบื้องหน้าของทรัพยากร GPU ที่ใช้ร่วมกันซึ่งใช้ในการสร้างโมเดล 3D, เท็กซ์เจอร์ และไฟล์ที่เกี่ยวข้อง ขีดจำกัดอัตราการเรียกใช้งานและขีดจำกัดการทำงานพร้อมกันช่วยปกป้องโครงสร้างพื้นฐานที่ใช้ร่วมกันนี้ เพื่อให้คุณภาพของผลลัพธ์และระยะเวลาในการสร้างคงที่สม่ำเสมอสำหรับผู้ใช้ทุกคนบนแพลตฟอร์ม บัญชีทุกบัญชีตามแพ็กเกจปัจจุบันจะมีจำนวนคำขอสูงสุดที่สามารถทำได้ในช่วงเวลาที่กำหนด และจำนวนงานสร้างที่ทำงานได้พร้อมกันสูงสุด (ที่อยู่ในคิวหรือกำลังดำเนินการ)

มีขีดจำกัดแยกกันสองประเภท ซึ่งแสดงอาการล้มเหลวแตกต่างกัน:

• ขีดจำกัดอัตราคำขอ (429 / RateLimitExceeded): นี่คือขีดจำกัดจำนวน API call (เช่น การสร้างงาน, การตรวจสอบสถานะ) ที่คุณสามารถเรียกได้ต่อนาที การเกินขีดจำกัดนี้หมายถึงคุณเรียก API ถี่เกินไป โดยไม่ขึ้นกับจำนวนงานที่กำลังทำงานอยู่จริง

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

ตรวจสอบขีดจำกัดคำขอและการทำงานพร้อมกันปัจจุบันของแพ็กเกจคุณได้ใน Meshy dashboard เนื่องจากขีดจำกัดเหล่านี้อาจแตกต่างกันตามระดับแพ็กเกจ

เมื่อคุณได้รับการตอบกลับ 429 หรือ RateLimitExceeded อย่าลองส่งคำขอเดิมซ้ำทันที แต่ให้ทำดังนี้:

• ใช้ exponential backoff: รอช่วงเวลาสั้นๆ แล้วเพิ่มเป็นสองเท่าในทุกครั้งที่ล้มเหลวต่อเนื่อง จนถึงค่าสูงสุดที่เหมาะสม

• เพิ่ม jitter (ค่าสุ่มเล็กน้อย) ลงในช่วงเวลา backoff เพื่อไม่ให้ worker หลายตัวในระบบของคุณลองใหม่พร้อมกันในจังหวะเดียว

• ปฏิบัติตาม header Retry-After หรือ header เกี่ยวกับขีดจำกัดอัตราการเรียกใช้งานที่ส่งกลับมาในการตอบกลับ (หากมี) แทนการเดาเวลารอเอง

• จำกัดจำนวนครั้งในการลองใหม่ต่อหนึ่งคำขอ เพื่อไม่ให้ความล้มเหลวที่เกิดขึ้นต่อเนื่องทำให้เกิดการวนซ้ำไม่สิ้นสุด

ข้อผิดพลาด NoMoreConcurrentTasks หมายถึงคุณมีงานที่ใช้งานอยู่ครบเพดานสูงสุดของบัญชีแล้ว เพื่อหลีกเลี่ยงการชนขีดจำกัดนี้ในสภาพแวดล้อม production:

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

• ตรวจสอบสถานะงานเป็นระยะ (หรือใช้ webhooks หากรองรับใน workflow ของคุณ) เพื่อทราบว่าเมื่อไรที่มีช่องว่างว่าง แทนการส่งงานแบบคาดเดา

• จัดกลุ่มและควบคุมอัตราการส่งงานสร้างจำนวนมาก แทนการยิงคำขอทั้งหมดพร้อมกัน — วิธีนี้ช่วยปรับรูปแบบทั้งอัตราคำขอและจำนวนงานที่ทำพร้อมกันของคุณให้ราบรื่นขึ้น

• เพิ่มระบบตรวจสอบ/แจ้งเตือนฝั่งของคุณ เพื่อให้มองเห็นการเพิ่มขึ้นผิดปกติของข้อผิดพลาด 429/NoMoreConcurrentTasks ได้ก่อนที่จะส่งผลกระทบต่อผู้ใช้ของคุณ

ปัจจุบัน Meshy API ยังไม่รองรับการ "ลองใหม่" ในตัวสำหรับงานสร้างที่มีอยู่ในแพ็กเกจ individual หรือ studio — หากผลลัพธ์ไม่ตรงตามความคาดหวัง คุณต้องส่งคำขอสร้างใหม่ ซึ่งจะใช้เครดิตตามปกติ เมื่อ pipeline อัตโนมัติของคุณจัดการกับข้อผิดพลาดชั่วคราว (เช่น 429) โปรดตรวจสอบว่า logic การลองใหม่ของคุณส่งคำขอเดิมซ้ำหลังจาก backoff เท่านั้น ไม่ใช่สร้างงานสร้างซ้ำซ้อนทุกครั้ง

หากคุณได้ implement backoff และคิวที่คำนึงถึงขีดจำกัดการทำงานพร้อมกันแล้ว แต่ยังคงพบขีดจำกัดอัตราหรือการทำงานพร้อมกันอย่างสม่ำเสมอ นั่นมักเป็นสัญญาณว่าความต้องการ throughput ของ integration ของคุณเกินขีดจำกัดของแพ็กเกจปัจจุบัน ตรวจสอบ dashboard สำหรับเพดานคำขอและการทำงานพร้อมกันของแพ็กเกจปัจจุบันของคุณ และพิจารณาอัปเกรด หรือติดต่อทีมขายของ Meshy เกี่ยวกับการเข้าถึง API ระดับองค์กร หากคุณต้องการ throughput ที่สูงขึ้นอย่างต่อเนื่อง

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

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

ตรวจสอบใน Meshy dashboard สำหรับขีดจำกัดที่เกี่ยวข้องกับแพ็กเกจปัจจุบันของคุณ เนื่องจากขีดจำกัดเหล่านี้อาจแตกต่างกันตามระดับแพ็กเกจ

ไม่ สำหรับแพ็กเกจ individual หรือ studio — งานสร้างที่ล้มเหลวหรือไม่น่าพอใจต้องส่งใหม่เป็นคำขอใหม่ ซึ่งใช้เครดิตตามปกติ ลูกค้า Enterprise ควรติดต่อฝ่ายขายเกี่ยวกับฟังก์ชันการลองใหม่

Implement คิวภายในเครื่องที่ควบคุมอัตราการส่งงานให้อยู่ต่ำกว่าขีดจำกัดการทำงานพร้อมกัน เพิ่ม exponential backoff พร้อม jitter สำหรับการตอบกลับ 429 และตรวจสอบอัตราข้อผิดพลาด เพื่อให้คุณสามารถตอบสนองได้ก่อนที่จะส่งผลกระทบต่อผู้ใช้ของคุณ

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

• วิธีใช้งาน Meshy API

• Meshy API รองรับการลองใหม่สำหรับงานสร้างหรือไม่?