در این مقاله
برای رفع خطای 429 در API هوش مصنوعی، اول علت را تشخیص دهید و بعد درباره تلاش مجدد تصمیم بگیرید. ارسال بی‌وقفه همان درخواست معمولاً راه‌حل نیست؛ ممکن است صف، مصرف و زمان انتظار را بیشتر کند. محدودیت نرخ، سهمیه حساب و سیاست یک مدل می‌توانند رفتار متفاوتی داشته باشند، حتی اگر در ظاهر پاسخ مشابهی ببینید.
در این راهنما یک برنامه پاسخ‌گویی به پیام ساختگی را در نظر می‌گیریم. کاربر باید یا پاسخ معتبر بگیرد یا بداند درخواست چه وضعیتی دارد. کلید، متن خصوصی و اثر جانبی ابزار نباید در فرایند Retry آسیب ببینند. نمونه کد فقط محاسبه فاصله انتظار را نشان میدهد و هیچ درخواست پولی یا تضمین جلوگیری از صورتحساب تکراری ارائه نمی‌کند.
429 دقیقاً چه چیزی را ثابت می‌کند؟
استاندارد HTTP، کد 429 را برای تعداد زیاد درخواست توضیح میدهد، اما علت و جزئیات عملی را قرارداد ارائهدهنده تعیین می‌کند. تعریف رسمی 429 نقطه شروع است، نه جدول سهمیه همه APIها. نام مدل، مسیر، وضعیت حساب و بدنه امن خطا را ثبت کنید. یک عدد ثابت برای همه مدلها و حسابها فرض نکنید.
اگر پاسخ از Proxy یا لایه برنامه خودتان می‌آید، آن را با محدودیت ارائهدهنده مدل اشتباه نگیرید. مسیر درخواست را بدون افشای Credential مشخص کنید و زمان رخداد را با گزارش مصرف مقایسه کنید. خطای احراز هویت و ورودی نامعتبر معمولاً با تکرار خودکار همان درخواست اصلاح نمی‌شوند؛ برای هر دسته خطا یک تصمیم جدا لازم است.
بودجه درخواست، زمان و هزینه را جدا محدود کنید
یک کار میتواند سه محدودیت داشته باشد: تعداد تلاش، زمان کل و سقف هزینه. داشتن فقط سقف سه تلاش کافی نیست اگر هر تلاش چند دقیقه منتظر بماند. از طرف دیگر، کوتاه‌کردن Timeout به‌تنهایی تضمین نمی‌کند پردازش سمت ارائهدهنده متوقف شده باشد. برنامه باید وضعیت نامعلوم را بشناسد و به کاربر وعده اشتباه درباره انجام‌نشدن درخواست ندهد.
بودجه را برای یک کار کاربر تعریف کنید، نه برای هر لایه به‌صورت مستقل. اگر SDK، Proxy و Worker هر کدام سه بار تکرار کنند، تعداد تلاش واقعی بیشتر از انتظار می‌شود. تنظیمات Retry کتابخانه موجود را پیش از افزودن حلقه جدید بخوانید. برای ارزیابی هزینه نتیجه نهایی، راهنمای هزینه و Eval ایجنت را مطالعه کنید.
Retry-After را با زمان مجاز کار تطبیق دهید
هدر Retry-After میتواند فاصله زمانی یا تاریخ HTTP باشد. قرارداد رسمی Retry-After را مبنا قرار دهید و فرض نکنید مقدار همیشه یک عدد ساده است. اگر انتظار پیشنهادی از مهلت کار بیشتر است، نباید آن را کوتاه کنید و زودتر به ارائهدهنده فشار بیاورید؛ کار را طبق قرارداد برنامه به صف بسپارید یا شکست قابل اقدام برگردانید.
نبود این هدر نیز مجوز تکرار فوری نیست. Backoff محدود با فاصله افزایشی و نوسان کنترل‌شده میتواند هم‌زمانی تلاش‌ها را کاهش دهد. اما تصمیم درباره اینکه کدام پاسخ قابل تکرار است باید قبل از محاسبه فاصله گرفته شود. تابع زیر فقط همین فاصله را محاسبه می‌کند؛ احراز هویت، لغو، بودجه و اجرای اثر جانبی را مدیریت نمی‌کند.
export function retryDelayMs(header, attempt, nowMs) {
if (!Number.isInteger(attempt) || attempt < 0 || attempt > 3
|| !Number.isFinite(nowMs)) throw new Error("invalid input");
if (attempt === 3) return null;
const raw = typeof header === "string" ? header.trim() : "";
const dateMs = /[A-Za-z]/.test(raw)
? Date.parse(/GMT$/i.test(raw) ? raw : raw + " GMT")
: NaN;
let delay;
if (/^\d+$/.test(raw)) delay = Number(raw) * 1000;
else if (Number.isFinite(dateMs)) {
delay = Math.max(0, dateMs - nowMs);
} else delay = 1000 * 2 ** attempt;
if (!Number.isFinite(delay) || delay > 30_000) return null;
return Math.max(250, delay);
}خروجی null یعنی این نمونه در همان کار تعاملی ادامه نمی‌دهد؛ نباید آن را صفر میلی‌ثانیه تفسیر کنید. عدد سی ثانیه در اینجا حد آموزشی یک محصول فرضی است، نه محدودیت پاستا یا استاندارد HTTP. در اجرای واقعی، jitter، مهلت کل و لغو کاربر را در همان هماهنگ‌کننده درخواست پیاده کنید و رفتار تاریخ و ورودی نامعتبر را با ساعت کنترل‌شده تست کنید.
صف به معنی ظرفیت نامحدود نیست
وقتی درخواست بیشتر از ظرفیت پردازش است، صف میتواند فشار را مرتب کند، اما اگر طول و سن کار محدود نباشند، مشکل فقط پنهان می‌شود. برای هر کار زمان انقضا، اولویت و رفتار لغو داشته باشید. درخواست قدیمی‌ای که کاربر دیگر نیازش ندارد نباید بی‌دلیل پس از چند ساعت مدل را صدا بزند. طول صف و تعداد Worker را با ظرفیت واقعی مدل هماهنگ کنید.
تفکیک مشتریان نیز مهم است. یک کاربر پرمصرف نباید همه ظرفیت را اشغال کند. سهم‌بندی و محدودیت باید در بک‌اند با هویت معتبر اعمال شوند، نه صرفاً در دکمه رابط. برای پیاده‌سازی صف Node.js، راهنمای BullMQ و Redis و برای اتوماسیون Queue Mode در n8n را بررسی کنید؛ هیچ‌کدام به‌تنهایی سهمیه مدل را افزایش نمی‌دهند.
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.