اگر برای بهینه‌سازی سرعت برنامه‌تان تعداد ورکرها را در APIهای رایگان افزایش می‌دهید، احتمالاً در حال ساختن یک توهم عملکردی هستید که در محیط عملیاتی فرو می‌پاشد. باید بدانید که دریافت وضعیت 200 OK تنها ثابت می‌کند سرور درخواست را پذیرفته است، نه اینکه چندین درخواست را به‌طور هم‌زمان پردازش می‌کند.
بسیاری از توسعه‌دهندگان تصور می‌کنند اگر یک API ده اتصال هم‌زمان را می‌پذیرد، یعنی ده مدل در حال اجراست. در واقعیت، درگاه‌ها (Gateways) اغلب سوکت‌های زیادی را می‌پذیرند اما آن‌ها را یکی‌یکی اجرا می‌کنند. این وضعیت یک صف پنهان ایجاد می‌کند که در آن تأخیر p50 (میانه) پایدار به نظر می‌رسد، اما تأخیر p95 با انتظار درخواست‌ها در صف، به‌شدت افزایش می‌یابد.
به نقل از راهنمای فنی منتشر شده در ۱۶ اوت ۲۰۲۶ توسط dev.to، این عدم تطابق باعث می‌شود توسعه‌دهندگان سیستم خود را بر اساس اعداد خیالی تنظیم کنند. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی مدیریت منابع در مدل‌های زبانی اشاره کردیم، بسیاری از خطاهای زمان‌بندی (Timeout) نه به دلیل نقص مدل یا پرامپت بد، بلکه نتیجه‌ی فشار صف در موازی‌سازی است. در این حالت، مدل هرگز پرامپت را نمی‌بیند؛ درخواست صرفاً پشت دیگران منتظر می‌ماند تا زمان اعتبارش تمام شود. این چالش‌های زیرساختی را می‌توان در مسیرهای شکست استقرار تجاری عامل‌های هوش مصنوعی مشاهده کرد که در آن عدم پیش‌بینی رفتار محیط عملیاتی منجر به شکست سیستم می‌شود.
چرا وضعیت HTTP محدودیت‌ها را پنهان می‌کند؟
نسخه‌های رایگان اغلب محدودیت‌های موازی‌سازی یا ظرفیت صف خود را منتشر نمی‌کنند. این عدم شفافیت باعث می‌شود خطاهایی که شبیه به خطای مدل هستند، در واقع شکست‌های مربوط به ظرفیت موازی‌سازی باشند. از آنجا که وضعیت 200 برای هر درخواست صادر می‌شود و سیگنالی از توان عملیاتی (Throughput) — شبیه به پهنای باند یک لوله آب که تعیین می‌کند در هر ثانیه چقدر آب عبور می‌کند — نیست، نمی‌تواند گلوگاه بودن سرور را نشان دهد.
برای یافتن حد واقعی، توسعه‌دهندگان باید یک «جاروب موازی‌سازی» (Concurrency Sweep) با یک پرامپت ثابت و کوتاه (مثلاً: "Return the single word ok.") اجرا کنند. با ثبت زمان کل و تأخیر در تعداد ورکر‌های افزایشی (مثلاً ۱، ۲، ۴، ۸)، می‌توان موازی‌سازی مؤثر را محاسبه کرد.
مکانیزم اندازه‌گیری
موازی‌سازی مؤثر از فرمول (زمان پایه × تعداد درخواست‌های تکمیل شده) تقسیم بر زمان کل محاسبه می‌شود. زمان پایه (T) همان زمانی است که در اجرای تک‌ورکره (c=1) ثبت شده است.
- مقدار نزدیک به ۱: درخواست‌ها به‌صورت ترتیبی (یکی پس از دیگری) پردازش می‌شوند.
- مقدار نزدیک به تعداد ورکرها: نقطه اتصال واقعاً درخواست‌ها را به‌طور موازی اجرا می‌کند.
- مقدار متوقف‌شده: افزودن ورکر بیشتر فقط فشار صف را زیاد می‌کند بدون اینکه توان عملیاتی افزایش یابد.
- کاهش تعداد OKها یا خطاهای 429: شما رسماً از حد سخت‌افزاری سرور عبور کرده‌اید.
- p95 بسیار بالاتر از p50: صف‌بندی آغاز شده است، حتی اگر تأخیر میانه هنوز قابل‌قبول باشد.
به عنوان مثال، یک تست ممکن است نشان دهد در ۲ ورکر، موازی‌سازی مؤثر ۱.۹۵ است، اما در ۸ ورکر تنها به ۲.۰۹ می‌رسد. در این سناریو، حالت c=8 بدتر است چون دو درخواست شکست می‌خورند و p95 از هفت ثانیه عبور می‌کند. این یعنی API ظرفیت موازی‌سازی را روی ۲ محدود کرده است، فارغ از اینکه شما چند ورکر مستقر کنید.
MonkeyCode که دسترسی رایگان به مدل‌ها و سرور رایگان ارائه می‌دهد، پیشنهاد می‌کند از این روش برای تبدیل حدس‌زدن تعداد ورکرها به یک علم اندازه‌گیری‌شده استفاده کنید. اگر این ابزار را روی نقاط اتصال رایگان MonkeyCode اجرا می‌کنید، به‌جای مثال‌های عمومی OpenAI، از مستندات فعلی آن‌ها برای URL، فرمت توکن و نام مدل استفاده کنید.
به‌کارگیری اندازه‌گیری
وقتی حد واقعی پیدا شد، راهکار افزایش ورکرها نیست، بلکه استفاده از یک سمافور (Semaphore) است. با پیاده‌سازی یک سمافور کوچک (مثلاً asyncio.Semaphore(2))، تعداد درخواست‌های ارسالی به API را با ظرفیت واقعی آن مطابقت می‌دهید.
- تثبیت استخر: استخر ورکرها را روی بیشترین موازی‌سازی تنظیم کنید که در آن مقدار موازی‌سازی مؤثر نزدیک به تعداد ورکرها باقی می‌ماند.
- صف‌بندی محلی: به‌جای افزایش اندازه استخر، یک صف در مقابل آن ایجاد کنید.
- تلاش‌های مجدد محدود: عملیات Retry را از مسیرهای نامحدود خارج کنید و فقط درخواست‌هایی را مجدداً ارسال کنید که در یک تعداد ورکر اندازه‌گیری‌شده و محدود شکست خورده‌اند.
این رویکرد، صف را از سرور راه دور — که هیچ دیدی از آن ندارید — به اپلیکیشن محلی شما منتقل می‌کند. در واقع، برای حذف کامل این وابستگی‌ها و کاهش تأخیرهای ناشی از درخواست‌های REST، سوییچ به معماری‌های محلی راهکاری بنیادین برای بهینه‌سازی چرخه‌های تکرار عامل‌های هوش مصنوعی است.
محدودیت‌ها و دامنه
توسعه‌دهندگان باید هر زمان که منطقه (Region)، مدل یا سهمیه (Quota) را تغییر دادند، این تست را تکرار کنند. چون نقاط اتصال رایگان مدام رفتارشان تغییر می‌کند، داده‌های هفته گذشته ممکن است امروز منقضی شده باشند.
به خاطر داشته باشید که این یک تست ظرفیت است، نه یک محک کیفیت. نتایج تحت تأثیر طول پرامپت، محدودیت توکن و طول خروجی هستند؛ بنابراین باید از یک داده ارسالی ثابت و نماینده استفاده کنید. همچنین، یک مکان کلاینت نمی‌تواند محدودیت‌های نرخ (Rate Limits) اعمال شده در نقاط دیگر را مشاهده کند.
این فرآیند برای کسانی که به متریک‌های سمت سرور برای عمق صف و p95 دسترسی دارند یا از سرویس‌های پولی استفاده می‌کنند (که ترافیک تست در آن‌ها هزینه دارد) ضروری نیست. اما برای مدل‌های رایگان، این تمرین فرض بنیادی ادغام API را تغییر می‌دهد: به کد وضعیت HTTP به‌عنوان سیگنال توان عملیاتی اعتماد نکنید. در عوض، API را به‌عنوان یک جعبه سیاه ببینید که باید پیش از ساخت لایه Retry، محدودیت‌های فیزیکی آن کاوش شود.
گام بعدی شما
- یک تست Concurrency Sweep با پرامپت‌های کوتاه روی APIهای رایگانی که استفاده می‌کنید اجرا کنید تا حد واقعی موازی‌سازی را بیابید.
- در کد خود به‌جای افزایش بی‌رویه ورکرها، از
asyncio.Semaphoreبرای محدود کردن درخواست‌های هم‌زمان استفاده کنید. - متریک p95 را به‌جای میانگین تأخیر رصد کنید تا متوجه شروع صف‌بندی در سرور شوید.
اما مدیریت این صف‌ها در مقیاس میلیونی نیازمند استراتژی‌های پیچیده‌تری است — به تحلیل ما درباره‌ی معماری‌های vLLM برای بهینه‌سازی استنتاج مراجعه کنید.
گفتگو