۹۲ ثانیه. این همان زمانی است که یک درخواست تکگانه میتواند طول بکشد تا شما یک مشتری را از دست بدهید، فارغ از اینکه میانگین تأخیر سیستم شما چقدر ایدهآل به نظر برسد. این درس سختی بود که یک توسعهدهنده در مدیریت گیتویهای سازگار با OpenAI آموخت؛ جایی که متریکهای نظارتی استاندارد، بحرانیترین شکستها را مخفی میکنند.
بسیاری از توسعهدهندگان برای سنجش پایداری سیستم، تأخیر (Latency) — که مثل زمان انتظار شما در صف نانوایی برای دریافت نان است — را بر اساس میانه (p50) رصد میکنند. اما طبق گزارشی که در ۳ سپتامبر ۲۰۲۶ در dev.to منتشر شد، سیستمی که میانگین پایداری ۲.۳ ثانیهای را نشان میداد، در واقع از «تأخیر دُم» (Tail Latency) شدید رنج میبرد؛ یعنی همان پاسخهای بهندرت اما فاجعهباری که تجربه کاربر را نابود میکنند. این چالش با آنچه در بررسی تأثیر تأخیر P95 بر توقف خطوط تولید AI مشاهده کردیم همسو است، جایی که نوسانات شدید در لایههای انتهایی باعث شکست کل سیستم میشود.
همانطور که در تحلیلهای قبلی ما دربارهی زیرساختهای استنتاج اشاره کردیم، تفاوت بین «عملکرد متوسط» و «پایداری واقعی» در لایههای گیتوی نهفته است. برای درک خطر میانگین، این توسعهدهنده چهار روز متوالی، روزانه سه درخواست کوچک (با حداکثر ۱۰ توکن یا max_tokens=10) ارسال کرد تا رفتار سیستم را در مقیاس کوچک بسنجد. نتایج تکاندهنده بود:
- ۳۱ اوت (صبح): ۲.۴۲ ثانیه، ۱۱.۲۲ ثانیه و یک توقف ۹۲ ثانیهای که منجر به Timeout شد.
- ۳۱ اوت (عصر): ۲.۰۷ ثانیه، ۲.۳۰ ثانیه، ۱.۷۷ ثانیه.
- ۱ سپتامبر: ۱.۶۴ ثانیه، ۲.۵۳ ثانیه، ۸.۴۰ ثانیه.
- ۲ سپتامبر: ۲.۷۵ ثانیه، ۲.۱۲ ثانیه، ۴.۱۷ ثانیه.
- ۳ سپتامبر: ۲.۴۶ ثانیه، ۱.۷۳ ثانیه، ۳.۰۰ ثانیه.
از ۱۴ درخواست ارسال شده، ۱۳ مورد زیر ۱۲ ثانیه بودند، اما تنها یک مورد ۹۲ ثانیه طول کشید و در نهایت شکست خورد. اگر توسعهدهنده فقط به میانگین نگاه میکرد، نتیجه میگرفت که سیستم با ۲.۳ ثانیه «بسیار پایدار» است و دقیقاً همان عددی را نادیده میگرفت که باعث ریزش مشتریان میشود.
برای یافتن گلوگاه و تشخیص دقیق مشکل، درخواستهای ارسالی از طریق گیتوی با درخواستهای مستقیم به ارائهدهنده (Upstream) مقایسه شد. نتایج تفاوت فاحشی را در نحوه مدیریت ناپایداری توسط این دو مسیر نشان داد:
- ارسال مستقیم به Upstream: پاسخها نوسانی و پرش داشتند؛ یک مورد ۲۰.۷۷ ثانیه، مورد دیگر ۱.۴۷ ثانیه و مورد سوم ۴.۵۲ ثانیه طول کشید. با این حال، هر ۳ مورد از ۳ درخواست (۳/۳) با موفقیت تکمیل شدند.
- ارسال از طریق گیتوی: پاسخها ۲.۴۲ ثانیه، ۱۱.۲۲ ثانیه و ۹۲ ثانیه بودند. در اینجا تنها ۲ مورد از ۳ درخواست (۲/۳) تکمیل شد و یکی کاملاً متوقف شد.
بررسی سختافزار سرور هیچ نشانهای از فشار یا استرس نشان نداد. توسعهدهنده وضعیت سرور (Box) را بررسی کرد و متوجه موارد زیر شد:
- میانگین بار (Load Average): ۰.۰۰، ۰.۰۰، ۰.۰۰
- حافظه (Memory): ۲۰۵ مگابایت از مجموع ۱۹۷۵ مگابایت استفاده شده بود
- دیسک (Disk): تنها ۷٪ از ظرفیت دیسک اشغال شده بود
- فرآیند (Process): فرآیند گیتوی فعال بود و پورت ۳۰۰۰ در وضعیت سالم (Healthy) قرار داشت
سرور با کمبود توان محاسباتی یا فشار سختافزاری مواجه نبود؛ بلکه صرفاً در حالت «انتظار» بود. ریشه مشکل، نبود پیکربندی زمان انتظار (Request Timeout) در گیتوی بود. بدون تعریف یک حد زمانی مشخص، گیتوی اتصال را بهطور نامحدود باز نگه میداشت در حالی که ارائهدهنده در بالا-دستی دچار وقفه یا Stall شده بود. این اتفاق، یک لرزش کوتاه در شبکه ارائهدهنده را به یک انجماد دائمی و طولانی برای کاربر نهایی تبدیل کرد. این نوع ناپایداری در لایههای ارتباطی، یادآور تأخیرهای شدید در سرویسهای رایگان مدلهای AI است که میتواند پاسخدهی را تا چندین برابر کند و پایداری تولید را به خطر اندازد.
برای حل این بحران و جلوگیری از تکرار آن، یک استراتژی دوگانه اجرا شد. نخست، یک زمان انتظار سختگیرانه (Strict Timeout) تعریف شد تا سیستم بهجای انجماد، «سریع شکست بخورد» (Fail Fast). دوم، یک مکانیزم جایگزین (Fallback) طراحی شد تا درخواستهای تایم-اوت شده بهطور خودکار به ارائهدهنده دوم هدایت شوند؛ چرا که در اکثر ساختارهای نرمافزاری، دریافت یک پاسخ کند بهتر از دریافت هیچ پاسخی نیست.
این تغییر رویکرد، فرض بنیادی نظارت بر گیتوی را عوض میکند. تکیه بر میانگین داشبوردها یک ریسک و نقطه ضعف است؛ تنها متریکی که برای قابلیت اطمینان (Reliability) اهمیت دارد، حداکثر تأخیر (p100) و نرخ تایم-اوت است. اکنون این توسعهدهنده هر دو را رصد میکند: میانه ۲.۴ ثانیه | حداکثر ۹۲ ثانیه | تایم-اوت ۱ از ۱۴.
برای هر کسی که زیرساخت هوش مصنوعی خود را مدیریت میکند، این ریسک خاموش است. همه چیز در نمودارها سالم به نظر میرسد تا زمانی که مشتری برای نزدیک به دو دقیقه به یک دایره چرخان (Loading Spinner) خیره شود و در نهایت سیستم را ترک کند.
تست این موضوع ساده است: یک دسته کوچک از درخواستهای یکسان را اجرا کنید — سه مورد به گیتوی و سه مورد به ارائهدهنده مستقیم — و واریانس (تفاوت) آنها را مقایسه کنید. اگر حداکثر تأخیر گیتوی بهطور قابلتوجهی بیشتر از ارائهدهنده بود، شما قطعاً با مشکل تایم-اوت مواجه هستید.
همین امروز فایلهای پیکربندی خود را برای وجود مقدار timeout بررسی کنید. اگر این مقدار وجود ندارد یا روی حالت پیشفرض (Default) است، سیستم شما در برابر توقفهای ناگهانی ارائهدهندگان بالا-دستی آسیبپذیر است.
گام بعدی شما
- فایلهای پیکربندی گیتوی خود را برای وجود مقدار
timeoutبررسی کنید. - اگر مقدار تایم-اوت روی پیشفرض است یا وجود ندارد، آن را بر اساس تحمل کاربر (مثلاً ۳۰ ثانیه) محدود کنید.
- متریک p100 (حداکثر تأخیر) را به داشبورد نظارتی خود اضافه کنید تا نقاط کور سیستم را ببینید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو