صف یک سیاست است: کنترل پذیرش هوش مصنوعی زیر بار

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

«GPU بیشتری اضافه کنید» کافی نیست. ظرفیت ممکن است پیش از گرم‌شدن نمونه‌های تازه از دست برود، یک API پایین‌دستی گلوگاه شود و ناوگان بزرگ‌تر هم هنگام کمبود به قاعده نیاز دارد. تصمیم عملی این است: وقتی ظرفیت محدود است، کدام کار هوش مصنوعی باید پذیرفته، کوتاه صف‌بندی، امن تنزل، به آینده موکول یا روشن و سریع رد شود؟

این راهنما صف را سطح سیاست‌گذاری می‌داند، نه بافری تصادفی، و نتیجه مفید و به‌موقع را به‌جای تعداد خام درخواست بهینه می‌کند.

توان عملیاتی با کار مفید یکی نیست

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

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

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

سازوکارهای ثابت‌شده را از سیاست هوش مصنوعی جدا کنید

چند سازوکار در مهندسی سامانه‌های توزیع‌شده جاافتاده‌اند:

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

برای نمونه، مشخصات Reactive Streams پس‌فشار ناهمگام را چنان تعریف می‌کند که مشترک تقاضا را کنترل کند و بافر محدود بماند. قابلیت اولویت و انصاف API در Kubernetes درخواست‌ها را در سطح‌های اولویت طبقه‌بندی می‌کند، هم‌زمانی را جدا می‌سازد، صف منصفانه و شاردینگ درهم‌ریخته به‌کار می‌گیرد و می‌تواند ترافیک اضافی را برای جهش کوتاه صف کند یا رد نماید. مدیر اضافه‌بار Envoy فشار سنجیده‌شده منابع را به اقدام مرحله‌ای مانند توقف پذیرش درخواست تازه تبدیل می‌کند و مستنداتش حفاظت خود میزبان را از قطع‌کننده مدار برای سرویس بالادستی جدا می‌داند.

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

هر درخواست باید پاکت پذیرش داشته باشد

پرامپت خام را مستقیم وارد صف مشترک استنتاج نکنید. بیرون مدل یک پاکت مورد اعتماد بسازید:

مدل می‌تواند پیچیدگی را به‌عنوان یک نشانه برآورد کند، اما نباید priority، tenant، deadline، approved یا emergency را تعیین کند. مقدار مورد اعتماد را از وضعیت احراز هویت‌شده محصول، عملیات درخواستی و سیاست نسخه‌دار به‌دست آورید. این اصل ادامه لایه مجوز ابزارهای هوش مصنوعی است: اختیار دسترسی و اولویت منابع دو تصمیم متفاوت‌اند، اما هیچ‌کدام به متن تولیدشده تعلق ندارند.

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

سنجه‌های تولید vLLM شمار درخواست‌های در حال اجرا و انتظار، زمان صف، توکن ورودی و خروجی، زمان پیش‌پرکردن و رمزگشایی و مصرف نهان‌گاه KV را نشان می‌دهند. این‌ها نشانه‌های پیاده‌سازی‌اند، نه سیاست کامل پذیرش تجاری؛ با این حال روشن می‌کنند چرا شمار درخواست به‌تنهایی فشار سرویس مدل را توضیح نمی‌دهد.

یکی از پنج سرنوشت را صریح انتخاب کنید

ردشدن را پشت یک چرخنده طولانی پنهان نکنید. RFC 6585 کد HTTP 429 را برای محدودیت نرخ تعریف می‌کند و اجازه فیلد Retry-After می‌دهد؛ در عین حال عمداً سیاست شناسایی مشتری و شمارش درخواست را به سرور می‌سپارد. وقتی خود فراخواننده یا سهمیه‌اش محدود است از 429 استفاده کنید و برای دسترس‌ناپذیری کل سرویس معنای وضعیت را آگاهانه انتخاب کنید. مهم‌تر از خود کد، دلیل صادقانه‌ای مانند tenant_quota، class_capacity، dependency_open، deadline_impossible یا queue_full است.

زمان تلاش دوباره فقط وقتی وعده است که سرور بتواند از آن دفاع کند. اگر زمان بازیابی نامعلوم است، همین را بگویید. مشتری نباید هر رد را به موج هماهنگ تلاش دوباره تبدیل کند. نیت منطقی پایدار و بودجه تجمعیِ توضیح‌داده‌شده در راهنمای تلاش دوباره و تکرارپذیری امن را حمل کنید.

صف کوچک و منقضی‌شونده بسازید، نه انبار امید

ظرفیت صف به سه سقف نیاز دارد:

1. تعداد یا جایگاه وزن‌دار: چه مقدار کار در حال اجرا و انتظار مجاز است؛
2. سن: کار تا چه مدت می‌تواند منتظر بماند و هنوز تازه باشد؛
3. هزینه: صف نماینده چه تعداد توکن، ابزار، بایت یا رزرو پایین‌دستی است.

مهلت مطلق را هنگام ورود، پیش از مرحله پرهزینه و هنگام خروج از صف بررسی و زمان باقی‌مانده را به بازیابی، استنتاج و ابزار منتقل کنید. هرجا محصول اجازه می‌دهد، با قطع اتصال کاربر کار را لغو کنید. قلم بی‌مصرف‌کننده، هدف پایدار یا مسیر وضعیت معمولاً اتلاف است.

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

APF در Kubernetes قیاس مفیدی دارد: درخواست‌ها می‌توانند تعداد متفاوتی «صندلی» بگیرند، سطح‌های اولویت هم‌زمانی جدا دارند و صف منصفانه گرسنگی جریان‌ها را کاهش می‌دهد. اصل را وام بگیرید، نه تنظیم را. هزینه هوش مصنوعی نامطمئن است و با طول زمینه، وضعیت نهان‌گاه، مدل، دسته‌بندی و رفتار ابزار تغییر می‌کند.

انصاف را از برچسب اشتراک ویژه قوی‌تر کنید

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

• سهم تضمین‌شده برای هر کلاس کار؛
• سهمیه مستأجر یا تیم درون آن کلاس؛
• ظرفیت جهشِ قابل قرض‌گرفتن تا وقتی سامانه سالم است؛
• اولویت پایین‌تر برای کار بالای سهمیه هنگام ازدحام؛
• هزینه وزن‌دار تا یک درخواست بسیار بزرگ خود را هم‌اندازه درخواست کوچک نشان ندهد؛
• ذخیره‌ای باریک برای سلامت، لغو، کنترل رخداد و بازیابی.

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

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

سرویس را تنزل دهید، نه کنترل را

تنزل باید پیش از اضافه‌بار و برای هر وظیفه تعریف شود:

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

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

هر تنزل را رفتار محصولی جدا با ارزیابی، پیام، سنجه و بازگشت مخصوص بدانید و منظم تمرین کنید؛ مسیر اضطراری کم‌استفاده احتمالاً کم‌اعتمادترین کد سرویس است.

مثال عملی: یک درگاه و چهار نوع کار

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

کنترل‌گر دو صندلی برای سلامت، لغو و عملیات رخداد رزرو می‌کند. ۱۸ صندلی به جست‌وجوی تعاملی، هشت صندلی به پیشنهاد دستور کار و ۱۲ صندلی به ارزیابی دسته‌ای می‌رسد. صندلی خالی دسته‌ای قابل قرض است، اما کلاس دسته‌ای کف تعاملی را مصرف نمی‌کند. هر مستأجر درون هر کلاس سهم محدود دارد و درخواست‌ها مهلت مطلق حمل می‌کنند.

کندی ارائه‌دهنده زمان تولید را دو برابر می‌کند و یک مستأجر ۵۰۰ پرونده ارزیابی می‌فرستد. کنترل‌گر:

• ترافیک سلامت و لغو را از ذخیره می‌پذیرد؛
• پرسش تعاملی را در سهم هر مستأجر عبور می‌دهد؛
• فقط جهش تعاملی‌ای را صف می‌کند که پیش از مهلت تمام می‌شود؛
• ارسال پیامددار تازه را متوقف، اما نیت ازقبل‌تأییدشده را برای اعتبارسنجی دوباره نگه می‌دارد؛
• پرونده‌های دسته‌ای را پایدار به تعویق می‌اندازد و شناسه وضعیت می‌دهد؛
• تلاش بالای سهمیه را پیش از رسیدن به ارائه‌دهنده رد می‌کند؛
• تولیدِ مشتری قطع‌شده را لغو می‌کند؛
• اجازه نمی‌دهد تلاش خودکار دوباره، بودجه صندلی دوم بگیرد.

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

لبه پرتگاه را آزمایش کنید، نه فقط شیب آرام را

آزمون ظرفیت باید بار پیشنهادی را از نقطه تثبیت توان مفید فراتر ببرد. این وضعیت‌ها را بگنجانید:

• جهش ناگهانی و افزایش تدریجی ترافیک؛
• ازدست‌رفتن نیمی از ظرفیت استنتاج؛
• افزایش تأخیر ارائه‌دهنده بدون خطای صریح؛
• تغییر ترکیب از پرامپت کوتاه به زمینه و خروجی بلند؛
• کندی ابزار یا بازیابی پشت استنتاج سالم؛
• یک مستأجر پرصدا و مستأجرهای آرام متعدد؛
• تلاش دوباره، هج و اتصال مجدد هماهنگ؛
• لغو هنگام صف، تولید و اجرای ابزار؛
• شکست مخزن صف و وضعیت منقضی پذیرش؛
• سوءاستفاده از اولویت و کم‌برآوردی هزینه؛
• انتقال به نهان‌گاه یا نمونه مدل سرد؛
• بازیابی در حضور عقب‌ماندگی بزرگِ معوق.

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

با کارنامه‌ای کامل برای تصمیم اداره کنید

راهنمای مشاهده‌پذیری عامل هوش مصنوعی اتصال ردپا میان مدل و ابزار را پوشش می‌دهد. سنجه‌های ویژه پذیرش را نیز اضافه کنید:

• کار پیشنهادی، پذیرفته، صف‌شده، معوق، تنزل‌یافته، رد، لغو و تکمیل‌شده بر پایه کلاس و مستأجر؛
• تکمیل مفید پیش از مهلت، نه فقط موفقیت سمت سرور؛
• عمق صف، هزینه وزن‌دار و سن میانه، صدک ۹۵ و بیشینه؛
• توکن، مدت، ابزار و صندلی برآوردی در برابر واقعی؛
• دلیل رد و نرخ کاهش اشتباه بار؛
• سهم انصاف و زمان گرسنگی؛
• کار کامل‌شده پس از قطع اتصال یا مهلت؛
• ضریب تلاش دوباره و نیت منطقی تکراری؛
• اشباع وابستگی و وضعیت قطع‌کننده مدار؛
• کیفیت نتیجه در حالت تنزل؛
• مصرف ذخیره اضطراری و زمان بازیابی.

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

دروازه پذیرش

پیش از آنکه سرویس مشترک هوش مصنوعی ترافیک تولید را بپذیرد، پاسخ این پرسش‌ها باید مثبت باشد:

1. آیا هر درخواست کلاس، مستأجر، مهلت، پیامد، تخمین هزینه و مسیر لغو مورد اعتماد دارد؟
2. آیا استنتاج، بازیابی، ابزار و وابستگی‌های دیگر بودجه جدا دارند؟
3. آیا صف با تعداد، سن و هزینه وزن‌دار محدود شده است؟
4. آیا کنترل‌گر پذیرش، صف کوتاه، تنزل امن، تعویق پایدار و رد صریح را جدا می‌کند؟
5. آیا صلاحیت اولویت و اضطرار بیرون مدل ساخته و سقف‌گذاری می‌شود؟
6. آیا مستأجر آرام و جریان کوچک هنگام رخداد همسایه پرصدا پیشرفت می‌کنند؟
7. آیا تلاش‌های دوباره یک نیت منطقی و بودجه تجمعی مشترک دارند؟
8. آیا حالت‌های تنزل بدون تضعیف شاهد، مجوز یا اعتبارسنجی آزموده شده‌اند؟
9. آیا آزمون اضافه‌بار از اشباع عبور می‌کند و دوره بازیابی را هم می‌سنجد؟
10. آیا داشبورد تکمیل مفیدِ به‌موقع و انصاف را گزارش می‌کند، نه فقط توان عملیاتی را؟

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

یادداشت منابع — بازبینی ۱۰ اوت ۲۰۲۶

• کتاب SRE گوگل: رسیدگی به شکست‌های آبشاری — فصل آنلاین کتاب ۲۰۱۶؛ منبع صف محدود، کاهش بار، تنزل تدریجی، مهلت و اضافه‌بار ناشی از تلاش دوباره.
• AWS Builder Center: کاهش بار برای جلوگیری از اضافه‌بار — منتشرشده ۱۲ ژوئن و ویرایش‌شده ۱۵ ژوئن ۲۰۲۶؛ منبع توان مفید، رد زودهنگام، کار محدود، سن صف، اولویت‌بندی و آزمون اضافه‌بار.
• AWS Builder Center: انصاف در سامانه‌های چندمستأجری — منتشرشده ۱۲ ژوئن و ویرایش‌شده ۱۵ ژوئن ۲۰۲۶؛ منبع سهمیه گردش کار، محدودسازی، رفتار جهش و جداسازی مستأجر.
• Kubernetes: اولویت و انصاف API — مستند زنده، بازبینی‌شده در تاریخ انتشار؛ منبع جداسازی سطح اولویت، صندلی، صف منصفانه، شاردینگ درهم‌ریخته، صف محدود و تصمیم صف یا رد.
• Envoy: مدیر اضافه‌بار — مستند جاری پروژه در ۲۰۲۶، بازبینی‌شده در تاریخ انتشار؛ منبع پایش فشار منابع، محرک، اقدام مرحله‌ای و مرز قطع‌کننده مدار.
• Reactive Streams برای JVM — نسخه مشخصات 1.0.4؛ منبع تقاضای تحت کنترل مشترک، پس‌فشار ناهمگام، لغو و بافر محدود.
• vLLM: سنجه‌های تولید — مستند زنده سروینگ، بازبینی‌شده در تاریخ انتشار؛ منبع سنجه درخواست در حال اجرا و انتظار، زمان صف، توکن، پیش‌پرکردن، رمزگشایی و نهان‌گاه KV.
• RFC 6585: کدهای وضعیت افزوده HTTP — RFC مسیر استاندارد آوریل ۲۰۱۲؛ منبع HTTP 429 و معنای اختیاری Retry-After.