محدودیت نرخ درخواست‌ها مانع از فروپاشی زیرساخت‌های مدل زبانی بزرگ نمی‌شود

تصور کنید سیستمی ساخته‌اید که دقیقاً طبق قوانین ترافیکی عمل می‌کند، اما باز هم با یک تصادف زنجیره‌ای در قلب سرورها متوقف می‌شود. اگر امروز برای مدیریت ترافیک مدل‌های خود فقط به شمارش تعداد درخواست‌ها تکیه می‌کنید، احتمالاً در برابر بارهای کاری غیرمنتظره کاملاً بی‌دفاع هستید. یک سرویس LLM در محیط تولید ممکن است کاملاً در محدوده محدودیت‌های نرخ (Rate Limits) خود باقی بماند، اما اگر چند درخواست بسیار حجیم تمام حافظه در دسترس GPU را مصرف کنند، سیستم کرش می‌کند. این تنش به این دلیل وجود دارد که شمارش درخواست‌ها، یک مدل مدیریت منابع نیست؛ تمایزی که با افزایش جریان‌های کاری عامل‌محور (Agentic Workflows) و افزایش تنوع در هزینه درخواست‌ها، حیاتی می‌شود.

بسیاری از توسعه‌دهندگان از محدودیت نرخ (Rate Limiting) — شبیه به نگهبانی که فقط تعداد افراد ورودی به یک سالن را می‌شمارد بدون اینکه بداند هر کس چه وسیله‌ای همراه دارد — به عنوان اولین خط دفاعی استفاده می‌کنند. این روش به سؤال ساده‌ای پاسخ می‌دهد: یک کاربر یا فراخواننده خاص در یک بازه زمانی مشخص اجازه دارد چه مقدار ترافیک ارسال کند؟ این رویکرد از مشتریان متخلف، طوفان‌های تصادفی بازส่ง (Retry Storms) و جهش‌های ناگهانی ترافیک محافظت می‌کند. همچنین مانع از آن می‌شود که مستاجران پرصدا (Noisy Tenants) از سهمیه‌های قراردادی خود فراتر روند یا مصرف API را به شدت افزایش دهند. برای مثال، یک سیستم ممکن است اجازه ۱۰۰ درخواست در دقیقه برای هر کاربر یا ۱,۰۰۰ درخواست برای هر مستاجر را بدهد و در صورت رد شدن این حد، خطای HTTP 429 'Too Many Requests' را برگرداند. این کد وضعیت صراحتاً توسط RFC 6585 تعریف شده است تا نشان دهد کاربر در یک بازه زمانی معین، درخواست‌های بیش از حدی ارسال کرده است.

اما طبق راهنمای فنی منتشر شده در ۳۱ اوت ۲۰۲۶ در وب‌سایت dev.to، این روش هزینه واقعی پردازش را نادیده می‌گیرد. در دنیای مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — دو درخواست که هر دو «یک عدد» شمرده می‌شوند، می‌توانند ردپای سخت‌افزاری کاملاً متفاوتی داشته باشند.

شکاف منابع

برای درک این شکاف، دو نوع بار کاری متمایز را مقایسه کنید:

• درخواست‌های تعاملی: این درخواست‌ها ممکن است ۱,۰۰۰ توکن ورودی و حداکثر ۳۰۰ توکن خروجی داشته باشند. در اینجا، کاربر فعالانه منتظر پاسخ است.
• درخواست‌های پس‌زمینه: این درخواست‌ها ممکن است ۳۰,۰۰۰ توکن ورودی و حداکثر ۴,۰۰۰ توکن خروجی داشته باشند. در این مورد، هیچ‌کس منتظر پاسخ فوری نیست.

برای یک سیستم محدودکننده نرخ، هر دو مورد دقیقاً «یک درخواست» شمرده می‌شوند. اما آن‌ها برای سیستم زیرین معادل نیستند. این درخواست‌ها برای مدت‌های متفاوتی ظرفیت هم‌زمانی (Concurrency) ارائه‌دهنده را اشغال می‌کنند و بودجه‌های توکنی بسیار متفاوتی را مصرف می‌کنند. اگر واحد حسابداری یک محدودکننده نرخ صرفاً «درخواست در ثانیه یا دقیقه» باشد، نمی‌تواند این تفاوت را ببیند. در نتیجه، ترافیک می‌تواند کاملاً در محدوده تنظیمات محدودیت نرخ باشد، اما همچنان یک منبع کمیاب را تخلیه کند.

شکست محدودیت‌های هم‌زمانی

حتی اضافه کردن محدودیت هم‌زمانی — مثلاً سقف گذاشتن برای درخواست‌های در جریان (In-flight) روی ۲۰ مورد — از غرق شدن کامل سرویس پایین‌دستی توسط کارهای موازی نامحدود جلوگیری می‌کند. اما این کار یک «مسئله تخصیص» ایجاد می‌کند.

تصور کنید ۲۰ درخواست سنگین پس‌زمینه تمام ۲۰ جایگاه موجود را تصاحب کنند. یک ثانیه بعد، یک درخواست تعاملی از سوی کاربری که منتظر پاسخ است می‌رسد. محدودکننده نرخ می‌گوید درخواست مجاز است، اما محدودکننده هم‌زمانی می‌گوید هیچ ظرفیتی وجود ندارد.

این سناریویی را ایجاد می‌کند که در آن سیستم از نظر فنی «محافظت شده» است، اما در اولویت‌بندی کارهایی که بیشترین اهمیت را دارند شکست می‌خورد. ما از یک مشکل «نرخ» به یک مشکل «تخصیص» رسیده‌ایم. سیستم سالم می‌ماند، اما تجربه کاربری فرو می‌پاشد زیرا کارهای دسته‌ای (Batch) با اولویت پایین، ترافیک حساس به تأخیر را مسدود کرده‌اند.

کنترل پذیرش چگونه کار می‌کند

اینجاست که کنترل پذیرش (Admission Control) وارد عمل می‌شود. این مکانیزم سؤال را از «سرعت ورود ترافیک چقدر است؟» به «آیا با توجه به ظرفیت فعلی، این تکه کار خاص اجازه شروع دارد؟» تغییر می‌دهد. در حالی که برخی سیستم‌ها این اصطلاح را به طور گسترده برای شامل کردن محدودیت نرخ به کار می‌برند، تمایز مفید در اینجا بین «کنترل سرعت ورود» و «تصمیم‌گیری درباره اینکه آیا یک درخواست باید ظرفیت اجرایی کمیاب فعلی را مصرف کند یا خیر» است.

برخلاف محدودکننده نرخ، یک کنترل‌کننده پذیرش می‌تواند چندین نقطه داده را در تصمیم‌گیری خود دخیل کند:

• وضعیت فعلی: میزان هم‌زمانی فعلی و بهره‌وری کلی منابع.
• پروفایل درخواست: هزینه تخمینی درخواست و اولویت آن.
• بستر مستاجر: کلاس بار کاری مستاجر و ظرفیت رزرو شده برای او.
• سلامت سیستم: عمق صف‌ها و ضرب‌الاجل‌های زمانی سخت‌گیرانه.

تخصیص منعطف ظرفیت

سرویسی را در نظر بگیرید که دارای ۳۲ جایگاه اجرایی است که بین کلاس‌های کاری تعاملی و دسته‌ای (Batch) مشترک است. بدون کنترل‌ها، پردازش‌های دسته‌ای ممکن است تمام ۳۲ جایگاه را مصرف کنند و ترافیک تعاملی را مجبور کنند پشت کارهایی منتظر بماند که هیچ‌کس منتظر پاسخ آن‌ها نیست.

یک جایگزین، تقسیم استاتیک ظرفیت است؛ مثلاً ۲۸ جایگاه برای تعاملی و ۴ جایگاه برای دسته‌ای. اگرچه این کار از ترافیک تعاملی محافظت می‌کند، اما باعث هدر رفت ظرفیت می‌شود. اگر تنها ۱۰ درخواست تعاملی در حال اجرا باشند، ۱۸ جایگاه بیکار می‌مانند در حالی که کارهای دسته‌ای در صف انتظار هستند.

یک سیاست پذیرش منعطف‌تر اجازه می‌دهد ترافیک دسته‌ای، ظرفیت‌های استفاده نشده را «قرض» بگیرد. هنگامی که تقاضای تعاملی افزایش می‌یابد، کنترل‌کننده پذیرش کارهای دسته‌ای جدید را متوقف می‌کند تا ظرفیت محافظت شده بازیابی شود. این امر به سیستم اجازه می‌دهد زیرساخت‌های گران‌قیمت را به بهره‌وری حداکثری برساند و در عین حال از کارهای حساس به تأخیر در زمان رقابت بر سر منابع محافظت کند.

تخصیص منابع آگاه از توکن (Token-Aware)

برای بارهای کاری LLM، این به معنای ردیابی یک بودجه تقریبی از توکن‌های در جریان است. یک درخواست برای یک پیام کوتاه ممکن است ۱,۶۰۰ توکن (۱,۲۰۰ ورودی + ۴۰۰ حداکثر خروجی) رزرو کند، در حالی که تحلیل یک سند بزرگ ممکن است ۲۷,۰۰۰ توکن (۲۴,۰۰۰ ورودی + ۳,۰۰۰ حداکثر خروجی) رزرو نماید.

کنترل‌کننده پذیرش با این موضوع به عنوان یک مسئله «تخصیص منابع» برخورد می‌کند، نه یک مسئله «شمارش ترافیک». این رزرو کردن نیازی نیست که یک پیش‌بینی بی‌نقص باشد؛ سیستم می‌تواند در هنگام پذیرش به صورت محافظه‌کارانه رزرو کند و پس از مشخص شدن مصرف واقعی، رزرو را تسویه نماید.

مقابله با اضافه‌بار پنهان

این مکانیزم همچنین شکست‌هایی را برطرف می‌کند که محدودیت نرخ کاملاً نادیده می‌گیرد. محدودیت نرخ یک سیاست درباره ترافیک ورودی است، اما نرخ ایمن یک سیستم توزیع‌شده ثابت نیست.

اگر یک ارائه‌دهنده پایین‌دستی کند شود و درخواست‌هایی که معمولاً ۵۰۰ میلی‌ثانیه زمان می‌برند ناگهان ۸ ثانیه طول بکشند، هم‌زمانی شروع به انباشته شدن می‌کند، حتی اگر نرخ ورود ثابت بماند. این وضعیت یک چرخه خطرناک را فعال می‌کند:

۱. نرخ ورود ثابت می‌ماند.
۲. درخواست‌ها برای تکمیل شدن زمان بیشتری می‌برند.
۳. کارهای در جریان و صف‌ها رشد می‌کنند.
۴. تأخیر افزایش می‌یابد و باعث فعال شدن تایم‌اوت‌ها می‌شود.
۵. تایم‌اوت‌ها باعث بازส่ง (Retry) می‌شوند و کارهای بیشتری به سیستم اضافه می‌کنند.

راهنمای SRE گوگل هشدار می‌دهد که محدودیت نرخ ساده نمی‌تواند جلوی شکستی را که پیش از این شروع شده است بگیرد. قابلیت اطمینان واقعی مستلزم «ریزش بار» (Load Shedding) است؛ یعنی رد کردن کارها در حالی که سیستم به اضافه‌بار نزدیک می‌شود تا از تخلیه کامل منابع و شکست‌های زنجیره‌ای جلوگیری شود.

خط لوله تولید (Production Pipeline)

سیستم‌های قابل اعتماد این ابزارها را در یک توالی خاص ترکیب می‌کنند. یک درخواست ابتدا از احراز هویت عبور می‌کند، سپس از یک محدودکننده نرخ برای بررسی سیاست سهمیه، و در نهایت از یک کنترل‌کننده پذیرش برای بررسی ظرفیت اجرایی در دسترس، پیش از آنکه به سرویس پایین‌دستی برسد.

در کدنویسی، این به شکل یک بررسی دو مرحله‌ای است:

if (!rateLimiter.allow(tenant)) {
  return tooManyRequests();
}

const reservation = admissionController.tryAcquire({
  workloadClass: request.workloadClass,
  estimatedCost: estimateCost(request),
});

if (!reservation) {
  return overloaded();
}

try {
  return await callDownstream(request);
} finally {
  reservation.release();
}

محدودکننده نرخ از سرویس در برابر نقض سیاست‌های ترافیکی محافظت می‌کند، در حالی که کنترل‌کننده پذیرش از ظرفیت اجرایی کمیاب محافظت می‌نماید.

پیامدها برای عامل‌های هوش مصنوعی (AI Agents)

سیستم‌های عامل‌محور این مشکل را تشدید می‌کنند. یک اقدام واحد کاربر می‌تواند چندین فراخوانی مدل پایین‌دستی، اجراهای مداوم پس‌زمینه و فراخوانی‌های ابزاری بازگشتی (Recursive) را فعال کند. عملیات با بافتار طولانی (Long-context) ظرفیت بسیار بیشتری نسبت به پرامپت‌های تعاملی کوتاه مصرف می‌کنند.

در این محیط‌ها، چالش اصلی دیگر تعداد درخواست در دقیقه نیست. این یک سؤال زمان‌بندی (Scheduling) است: وقتی تقاضا از ظرفیت پیشی می‌گیرد، کدام تکه کار خاص شایستگی ادامه یافتن را دارد؟

اضافه‌بار در این سیستم‌ها همیشه به شکل کرش کردن ظاهر نمی‌شود. اغلب به شکل سیستمی است که از نظر فنی درخواست‌ها را دقیقاً طبق طراحی پردازش می‌کند، اما کارهای اشتباه در حال مصرف ظرفیت موجود هستند و باعث انفجار تأخیر برای کاربر نهایی می‌شوند. به همین دلیل است که ابزارهایی مانند async-bulkhead-llm و MoFlux بر پذیرش آگاه از توکن تمرکز می‌کنند تا از ترافیک تعاملی محافظت کرده و در عین حال به بارهای کاری با اولویت پایین‌تر اجازه دهند از ظرفیت‌های بیکار استفاده کنند.

گام بعدی شما

• اگر از APIهای مدل زبانی در مقیاس بالا استفاده می‌کنید، لایه‌ای برای تخمین توکن‌های ورودی/خروجی پیش از ارسال درخواست اضافه کنید.
• سیاست‌های اولویت‌بندی (Priority Queue) را برای تفکیک ترافیک تعاملی از ترافیک دسته‌ای (Batch) پیاده‌سازی کنید.
• ابزارهایی مانند async-bulkhead-llm را برای مدیریت ظرفیت توکن‌محور بررسی کنید.

اما مدیریت این ظرفیت‌ها تنها نیمی از مسیر است؛ تأثیر معماری‌های جدید در کاهش هزینه استنتاج را در تحلیل ما درباره مدل‌های تقطیری بررسی کنید.