اگر برای خط لوله‌ی تولید خود به سرورهای رایگان تکیه کرده‌اید، احتمالاً با بمبی ساعتی از تایم‌اوت‌ها رو‌به‌رو هستید. یک سرور استنتاج رایگان، در واقع یک سرویس شبکه‌ای با محدودیت نرخ (Rate-limited) است، نه یک جعبه جادویی. در ۱۷ اوت ۲۰۲۶، یک تست فشار فنی توسط MonkeyCode نشان داد که تکیه بر میانگین تأخیر (P50) برای هر سیستم عملیاتی، یک قمار خطرناک است. افشای لازم: این مقاله به عنوان بخشی از فعالیت‌های ترویجی محصولات MonkeyCode تهیه شده است که در آن از دسترسی رایگان به مدل و گزینه سرور رایگان به عنوان هدف تست استفاده شده است. حقیقت این است که حتی اگر یک مدل در شناسایی خطاهای YAML بی‌نقص باشد، اگر باعث شود یک CI تایم‌اوت شود، تبدیل به نویزی بی‌فایده می‌شود.
بسیاری از توسعهدهندگان تصور می‌کنند لایه‌های رایگان صرفاً «کمی کندتر» هستند و برای کارهای پس‌زمینه مناسب‌اند. این تصور، واقعیت صف‌های مشترک را نادیده می‌گیرد؛ جایی که میانگین تأخیر، جهش‌های ناگهانی را می‌پوشاند که باعث شکست تایم‌اوت‌های سیستم می‌شوند. در دنیای واقعی، پاسخی که ۹ ثانیه بعد می‌رسد مفید است، اما پاسخی که ۴۰ ثانیه طول بکشد، یک شکست سیستمی است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی پایداری مدل‌های بازمتن اشاره کردیم، تفاوت بین «کار کردن در محیط تست» و «پایداری در مقیاس واقعی» دقیقاً در همین نقاط شکست نهفته است. استنتاج (Inference) — که شبیه لحظه‌ی آشپزی واقعی است، نه دوره‌ی آموزش آشپز — در سرورهای رایگان نه بر اساس سرعت، بلکه بر اساس مدیریت صف پیش می‌رود.
ریسک‌های پنهان لایه‌های رایگان
طبق گزارش MonkeyCode، سه مشکل اساسی پشت توهم «کندیِ قابل‌تحمل» لایه‌های رایگان وجود دارد:
- پوشش P50: میانگین تأخیر، جهش‌هایی را که باعث فعال شدن تایم‌اوت‌ها می‌شوند، مخفی می‌کند.
- محدودیت‌های هم‌زمانی: پاسخ‌های ۴۲۹ (Too Many Requests) حتی در شرایط هم‌زمانی کم نیز رایج هستند و اتفاق نادری نیستند.
- تورم بازتلاش: منطق بازتلاش (Retry) می‌تواند به‌طور موثری تأخیر نهایی شما را دو برابر کند.
برای شناسایی این نقاط شکست پنهان، یک ابزار تست اختصاصی (Harness) با استفاده از پایتون و aiohttp ساخته شد. در این تست از «پرامپت‌های کوچک» استفاده شد؛ پرامپت‌های کوچک به عنوان یک جمله به همراه یک دستور کوتاه زیر ۱۰۰ توکن (تکه‌های کوچکی از متن شبیه برش‌های کیک) تعریف شدند. هدف از این کار، جداسازی تأخیر شبکه و سرور از زمان تولید مدل بود. اگر از پرامپت‌های طولانی استفاده می‌شد، زمان پردازش مدل با زمان شبکه مخلوط می‌شد و کفِ تأخیر (Floor) را به طور کاذب تغییر می‌داد.
متدولوژی تست و ابزار سنجش
این ابزار به‌گونه‌ای طراحی شد تا به‌جای اندازه‌گیری ساده‌ی سرعت در یک لحظه، «نقطه‌ی شکست» را پیدا کند. برای ارسال درخواست‌ها از یک تابع async استفاده شد و برای محدود کردن هم‌زمانی از یک Semaphore بهره گرفته شد. در این ابزار از هیچ سیستم تله‌متری شخص ثالثی استفاده نشد. اسکریپت مذکور برای هر فراخوانی، وضعیت کد (status_code)، تأخیر بر حسب میلی‌ثانیه (latency_ms)، زمان شروع (started_at) و تعداد بازتلاش‌ها (retry_count) را ثبت کرد.
- ماتریس تست: سه سطح هم‌زمانی مختلف (۱، ۴ و ۱۰) مورد بررسی قرار گرفتند.
- حجم داده: در هر سطح از این سه حالت، ۳۰ درخواست ارسال شد.
- مراحل: دور اول بدون هیچ بازتلاشی اجرا شد تا رفتار خام سرور نمایش داده شود؛ دور دوم با استراتژی Exponential Backoff (عقب‌نشینی تصاعدی) اجرا شد تا قدرت بازیابی سیستم تست شود.
- تایم‌اوت: اسکریپت هر درخواستی که در ضرب‌الاجل ۱۵ ثانیه‌ای پاسخ نمی‌داد را به عنوان شکست ثبت کرد، زیرا این موارد معمولاً مربوط به تایم‌اوت‌های Gateway یا قطع شدن اتصالات هستند.
داده‌های نقطه‌ی شکست
نتایج نشان‌دهنده شکافی عمیق و واگرایی شدید بین تجربه میانگین و بدترین سناریوی ممکن است:
- هم‌زمانی ۱: میانگین (P50) ۱.۸ ثانیه بود، در حالی که P95 به ۴.۲ ثانیه رسید. در این حالت تنها یک پاسخ ۴۲۹ و صفر خطای کلی ثبت شد.
- هم‌زمانی ۴: میانگین به ۳.۱ ثانیه افزایش یافت، اما P95 جهشی شدید به ۸.۷ ثانیه داشت. در این سطح، ۶ پاسخ ۴۲۹ (Too Many Requests) و ۱ خطای کلی دریافت شد.
- هم‌زمانی ۱۰: میانگین به ۵.۶ ثانیه رسید، اما P95 به شدت جهش کرد و به ۱۳.۹ ثانیه رسید؛ ۱۲ پاسخ ۴۲۹ و ۴ خطای کلی ثبت شد.
این اعداد ثابت می‌کنند که سرور مقیاس‌پذیر نیست، بلکه بار اضافی را «می‌اندازد» (Load Shedding). وقتی هم‌زمانی افزایش می‌یابد، بدترین ۵٪ فراخوانی‌ها بسیار سریع‌تر از میانگین تخریب می‌شوند. اگر یک خط لوله‌ی CI تایم‌اوت سخت ۱۰ ثانیه‌ای داشته باشد، P95 معادل ۱۳.۹ ثانیه یعنی سیستم به‌طور مکرر شکست می‌خورد، حتی اگر میانگین ۵.۶ ثانیه، همه چیز را سالم نشان دهد. P50 در واقع وعده‌ای به کاربران در مسیرهای خوش‌بینانه (Happy-path) است، اما P95 وعده‌ای است که به بازتلاش‌های شما داده می‌شود.
پارادوکس بازتلاش
بر اساس مستندات تست، پیاده‌سازی بازتلاش‌های تصاعدی مشکل بنیادین محدودیت نرخ (Rate-limiting) را حل نمی‌کند، بلکه خطاهای ۴۲۹ را پشت تأخیرهای کلی طولانی‌تر پنهان می‌کند. در تست هم‌زمانی ۱۰، درخواستی که دو بار شکست خورد — یک بار بازتلاش بعد از ۲ ثانیه و بار دیگر بعد از ۴ ثانیه — در نهایت در تلاش سوم موفق شد. این اتفاق تأخیر کلی آن تک درخواست را به ۱۱.۸ ثانیه رساند.
در حالی که سرور این مورد را به عنوان یک «موفقیت» ثبت کرد، اما در واقعیت، Job مربوط به CI مدت‌ها پیش تایم‌اوت شده بود. برای توسعه‌دهنده، بازتلاشی که بعد از ضرب‌الاجل (Deadline) موفق شود، همچنان یک شکست است.
چه زمانی لایه‌ی رایگان کافی است؟
استفاده از استنتاج رایگان تنها در شرایط خاص و محدود زیر منطقی و کاربردی است:
- زمانی که عملیات در پس‌زمینه اجرا می‌شود و هیچ کاربری در انتظار پاسخ نیست.
- زمانی که پذیرش یک صف ۳۰ ثانیه‌ای برای سیستم قابل قبول باشد.
- زمانی که نتایج به‌طور تهاجمی کش (Cache) می‌شوند و یک پرامپت یکسان به‌ندرت درخواست می‌شود.
- زمانی که خط لوله به‌گونه‌ای طراحی شده باشد که نرخ خطای ۱۰٪ را تحمل کند، به‌جای اینکه انتظار خطای صفر داشته باشد.
چه زمانی باید ارتقا دهید؟
هرگز به یک نمونه‌ی یک دقیقه‌ای به عنوان حقیقت مطلق تکیه نکنید؛ تست‌ها را در ساعات مختلف شبانه‌روز و از منطقه‌ای که سرور CI شما در آن مستقر است اجرا کنید. اگر شرایط زیر برقرار است، لایه‌ی رایگان را به‌طور کامل کنار بگذارید:
- تایم‌اوت عملیات شما زیر ۵ ثانیه است.
- در هر بار اجرا، صدها فراخوانی انجام می‌دهید.
- بررسی AI در مسیر بحرانی (Critical Path) برای Merge قرار دارد.
- تیم شما نمی‌تواند یک خطای ۴۲۹ را در بازه‌ی زمانی استقرار (Deploy Window) تحمل کند.
متریک P95 یک حکم نهایی درباره‌ی سرویس نیست، بلکه خط‌کشی برای تصمیم‌گیری است که چه زمانی باید به لایه‌ی پولی ارتقا دهید یا یک سیستم صف‌بندی مقاوم‌تر پیاده‌سازی کنید.
گام بعدی شما
- تست‌های تأخیر را در ساعات مختلف شبانه‌روز و از منطقه‌ای که سرور CI شما در آن است اجرا کنید.
- اگر تایم‌اوت سیستم شما زیر ۵ ثانیه است، فوراً از لایه‌ی رایگان فاصله بگیرید.
- برای عملیات‌های بحرانی (Critical Path) در مسیر Merge، از سیستم‌های صف‌بندی (Queuing) مقاوم‌تر استفاده کنید.
اما داستان سخت‌افزاری این تحول و نحوه مدیریت حافظه در سرورهای استنتاج حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی KV Cache مراجعه کنید.
گفتگو