ระบบรับคำขอจำกัดผู้เรียกแต่ละรายไว้ที่ 30 คำขอต่อนาทีภายในองค์กร หากเกินจะตอบกลับ 429 พร้อมรหัส rate_limit หน้าต่างเวลายาวหนึ่งนาที กลไกป้องกันแยกตามแหล่งที่มาและแบบรวมทำงานก่อนการยืนยันคีย์ และอาจตอบ 429 ได้เช่นกัน เมื่อมี Retry-After ให้ปฏิบัติตาม และใช้ exponential backoff ร่วมกับ jitter
import time, random
for attempt in range(5):
try:
return client.chat.completions.create(...)
except RateLimitError:
time.sleep(min(2 ** attempt, 30) + random.random())เพดานการใช้จ่ายไม่ใช่การจำกัดอัตรา#
การปฏิเสธจากการใช้จ่ายและนโยบายมีสถานะต่างกัน และเงื่อนไขการแก้ต่างกัน ไม่มีรายการใดเป็น 429 และการทำ backoff ไม่ช่วยให้ผ่านได้:
| สถานะ | รหัส | ความหมาย | จะหายเมื่อ |
|---|---|---|---|
403 |
key_limit |
ใช้เพดานการใช้จ่ายของคีย์หมดแล้ว | รอบ reset หมุน (daily, weekly, monthly) — lifetime ไม่รีเซ็ต |
403 |
budget_limit |
ถึงเพดาน dailyMicro / monthlyMicro ของ invocation policy |
วันหรือเดือนของนโยบายเปลี่ยน หรือ Owner เพิ่มเพดาน |
403 |
policy_denied |
invocation policy ปฏิเสธโมเดลหรือขนาด output | นโยบายเปลี่ยน |
402 |
insufficient_budget |
กระเป๋าเงินของโปรเจกต์กันยอดไว้ไม่ได้ | Owner เติมเงินให้โปรเจกต์ |
กำหนดเพดานการใช้จ่ายของคีย์ได้ตอนสร้างคีย์ Invocation policy (allowedModels, dailyMicro, monthlyMicro, maxOutputTokens) คือข้อจำกัดที่มีชื่อซึ่ง Owner ขององค์กรจัดการ นโยบายที่ใช้งานอยู่ทุกข้อซึ่งใช้กับการเรียกจะยังมีผลพร้อมกันเสมอ กระเป๋าเงินของโปรเจกต์คือขอบเขตที่ตายตัวภายใต้ทั้งสองส่วน ดู Caps and spend controls
ขั้นตอนถัดไป#
- ข้อผิดพลาด — ทุกรหัสและวิธีแก้
- Caps and spend controls — กำหนดขอบเขตค่าใช้จ่าย แทนการจำกัดอัตรา