اگر امروز در حال مقیاسبندی یک خطلوله تولیدی هوش مصنوعی هستید، یک کاربر مزاحم یا یک کلاستر GPU کند میتواند کل سیستم شما را به زانو درآورد. در ۱۷ ژوئن ۲۰۲۶، یک راهنمای فنی در وبسایت dev.to تشریح کرد که معماریهای توزیعشدهی AI برای بقا در برابر این فشارها، به چه حفاظهای مشخصی نیاز دارند.
تصور کنید پشتهی AI شما شبیه به یک بزرگراه پرترافیک است. در یک خطلوله معمولی، پرامپت کاربر به یک متعادلکننده بار، سپس به درگاه API و در نهایت به سرویس استنتاج (Inference) — مثل خودِ آشپزی، نه دورهی آموزش آشپز — میرسد. این سرویس ممکن است دوباره یک پایگاه داده برداری یا API تنظیم دقیق را فراخوانی کند. وقتی سرویسی مثل پایگاه داده کند میشود، درخواستها شبیه ترافیک شهری روی هم تلنبه میشوند. بدون راهی برای تغییر مسیر یا محدود کردن ورودی، کل سیستم حافظهاش پر شده و کرش میکند. به همین دلیل است که محدودیتهای استاندارد API برای بارهای کاری AI کافی نیستند.
نیاز به حفاظها
سیستمهای توزیعشدهی AI ذاتاً پیچیدهاند. این سیستمها باید حجم عظیمی از درخواستها و تأخیرهای متغیر در استنتاج مدل را مدیریت کنند. همچنین به وابستگیهای خارجی مثل کلاسترهای GPU و APIهای شخص ثالث (مانند OpenAI یا HuggingFace) متکی هستند. هر جزء ظرفیت محدودی دارد؛ سرورهای GPU فقط تعداد محدودی درخواست همزمان را میپذیرند و اتصالات پایگاه داده محدود است. بدون محدودکنندهی نرخ، یک کلاینت مزاحم میتواند تمام این منابع را ببلعد و بدون قطعکنها، شکست یک سرویس باعث ایجاد تایم-اوتهای زنجیرهای در کل سیستم میشود.
طبق گزارش dev.to، اولین خط دفاعی، «محدودکنندهی نرخ» (Rate Limiting) است. این ابزار تعیین میکند که یک کلاینت، کاربر یا سرویس در یک بازه زمانی مشخص چه تعداد درخواست میتواند ارسال کند تا دسترسی عادلانه تضمین شود و ازset-starvation یا گرسنگی منابع جلوگیری گردد.
همانطور که در تحلیلهای قبلی ما دربارهی زیرساختهای مدلهای زبانی اشاره کردیم، مدیریت منابع در مقیاس بالا، اولویت اصلی مهندسان زیرساخت است.
مکانیزمهای محدودکنندهی نرخ
الگوریتمهای مختلف، توازنهای متفاوتی برای ترافیک AI ارائه میدهند:
- توکنباکت (Token Bucket): برای AI ترجیح داده میشود چون اجازه میدهد فورههای کوتاه (مثلاً ارسال دستهای پرامپتها توسط کاربر) رخ دهد اما میانگین بلندمدت را حفظ میکند. پیادهسازی آن ساده است اما برای هر باکت نیاز به حافظه دارد.
- باکت نشتکننده (Leaky Bucket): نرخ خروجی ثابتی دارد و ساده است، اما در برابر فورهها انعطاف کمتری دارد.
- پنجره ثابت (Fixed Window): سربار کمی دارد اما در لحظهی بازنشانی (Reset) با جهشهای ترافیکی مواجه میشود.
- پنجره لغزان (Sliding Window): دقیقتر و نرمتر از پنجرههای ثابت است، هرچند کمی پیچیدهتر است.
برای استقرارهای خاص مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — این راهنما سه بهبود حیاتی را پیشنهاد میکند:
- گلوگاه توکنمحور: محدود کردن بر اساس تعداد توکنهای ورودی/خروجی بهجای تعداد درخواستها؛ چون یک پاسخ ۴۰۹۶ توکنی بهمراتب سنگینتر از پاسخ ۱۰۰ توکنی است.
- صفهای اولویتدار: اختصاص کاربران ویژه به باکتهای مجزا با محدودیتهای بالاتر.
- وضعیت توزیعشده: استفاده از Redis یا etcd برای همگامسازی محدودیتها در چندین نمونهی سرویس. برای مثال، یک محدودکننده مبتنی بر Redis میتواند از کلیدهایی با فرمت
ratelimit:{user_id}:{timestamp}برای ردیابی درخواستها در یک پنجره زمانی استفاده کند.
وقتی محدودکنندهی نرخ نتواند جلوی فشار را بگیرد، قطعکنها (Circuit Breakers) وارد عمل میشوند. این الگو فراخوانیهای سرویسهای پاییندست، مثل سرور استنتاج GPU را رصد میکند. اگر شکستها از یک حد مشخص فراتر رفت، مدار «باز» میشود و تمام فراخوانیهای بعدی را فوراً رد میکند تا سرویس فرصت بازیابی داشته باشد.
چرخه حیات قطعکن
۱. بسته (Closed): عملیات عادی؛ درخواستها آزادانه جریان مییابند و سیستم شکستها را رصد میکند.
۲. باز (Open): حد شکست رد شده است؛ درخواستها سریعاً رد میشوند یا یک پاسخ جایگزین فعال میشود. این کار مانع از هدر رفتن منابع روی سرویسی میشود که میدانیم خراب است.
۳. نیمهباز (Half-Open): پس از یک دوره استراحت (recovery timeout)، سیستم تعداد محدودی درخواست (مثلاً ۳ مورد) میفرستد تا بازیابی را چک کند. اگر موفق شوند، مدار بسته میشود.
برای بهینهسازی این روند در AI، توسعهدهندگان باید تفاوت انواع شکست را بدانند. خطاهای گذرا مثل تایم-اوتهای ۵۰۳ یا خطاهای اتصال باید از خطاهای دائمی مثل درخواستهای اشتباه ۴۰۰ تفکیک شوند. فقط خطاهای گذرا باید در شمارش حد شکست محاسبه شوند.
ویژگیهای پیشرفتهی قطعکن در AI
- تشخیص فراخوانیهای کند: این راهنما توصیه میکند پاسخهای غیرعادی کند (مثلاً بیش از ۱۰ ثانیه برای استنتاج LLM) را به عنوان شکست تلقی کنید. این کار مانع از اشغال طولانیمدت اتصالات میشود، جایی که کانکشنها بیش از حد باز میمانند.
- استراتژیهای جایگزین (Fallback): بهجای کرش کامل، سیستم میتواند پاسخی کاهشیافته ارائه دهد. مثلاً اگر فراخوانی کامل LLM شکست خورد، سیستم میتواند نسخهای کوتاه شده از پرامپت یا یک پاسخ کششده بازگردانده شود.
این تغییر در پیادهسازی، رویکرد این حوزه را از «تلاش برای مقیاسبندی» به «طراحی برای شکست» تغییر میدهد. با پذیرش این واقعیت که کلاسترهای GPU گاهی لگ میزنند، مهندسان میتوانند سیستمهایی بسازند که بهصورت تدریجی کیفیتشان کم شود (Degrade Gracefully) — یعنی ارائه یک پاسخ جایگزین ساده بهجای یک تایم-اوت کامل.
برای کسانی که استنتاج در مقیاس بالا را مدیریت میکنند، گام بعدی ارزیابی این است که آیا ابزارهای مانیتورینگ فعلیشان میتوانند «فراخوانیهای کند» را پیش از آنکه استخر اتصالات (Connection Pool) را تخلیه کنند، به عنوان شکست شناسایی کنند یا خیر.
گام بعدی شما
- بررسی کنید که آیا ابزارهای مانیتورینگ فعلی شما میتوانند «فراخوانیهای کند» پیش از اتمام ظرفیت اتصالات شناسایی کنند یا خیر.
- استراتژی Fallback خود را تعریف کنید تا در زمان قطعی GPU، کاربر بهجای خطای ۵۰۰، یک پاسخ ساده یا کششده دریافت کند.
- اگر از Redis استفاده میکنید، ساختار کلیدهای محدودکننده نرخ خود را برای پشتیبانی از توکنهای ورودی/خروجی بهروز کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو