تصور کنید یک برنامهنویس است که ساعتها وقت صرف بهینهسازی مدل خود میکند، اما همچنان با یک نشانگر چرخان و کند در دمو مواجه است. این کندی لزوماً به معنای ضعف مدل یا کمبود GPU نیست، بلکه احتمالاً نتیجهٔ یک خطای ساختاری در نحوهٔ مدیریت ابزارهاست.
به نقل از تحلیل فنی منتشر شده در ۱۲ سپتامبر ۲۰۲۶ در وبسایت dev.to، بسیاری از گلوگاههای عاملمحور (Agentic) ناشی از «عادتهای متوالی» (Serial Habits) است؛ یعنی تمایل کلاینت به اینکه منتظر بماند تا یک ابزار کاملاً تمام شود و سپس ابزار بعدی را اجرا کند، حتی اگر این دو هیچ وابستگی به هم نداشته باشند. این تحلیل استدلال میکند که یک نشانگر چرخان در دموی هوش مصنوعی، اغلب بیشتر از آنکه نشاندهنده محدودیت سختافزاری باشد، یک نقص ساختاری را میپوشاند.
این مشکل زمانی رخ میدهد که توسعهدهندگان از رابطهای چت ساده به سمت عامل (Agent) — شبیه به یک دستیار هوشمند که میتواند بهجای حرف زدن، ابزارهای مختلف را برای انجام کار به کار بگیرد — حرکت میکنند. در این جریانهای کاری، تصور رایج این است که پاسخ کند، یعنی مدل در حال کلنجار رفتن است یا واحد پردازش گرافیکی (GPU) — همان موتور قدرتمندی که تمام محاسبات سنگین هوش مصنوعی را انجام میدهد — بیش از حد درگیر شده است.
نویسنده اشاره میکند که پیش از این، خودش هم دلیل کندی دموها را «درد GPU» میدانست و در حالی که نشانگر میچرخید، فشار روی GPU را روایت میکرد. اما واقعیت اغلب شبیه به یک «پل تکبانده» در ساعت شلوغی است؛ ماشینها ممکن است سریع باشند، اما چون فقط یکی در هر لحظه میتواند عبور کند، همه میخزند. در واقع، عامل صرفاً در حال اجرای یک صف مؤدبانه و یکی-یکی است که باعث هدر رفتن توان محاسباتی موجود میشود.
همانطور که در تحلیلهای قبلی ما دربارهی بهینهسازی استنتاج اشاره کردیم، شناسایی درست گلوگاه، نیمی از مسیر حل مسئله است. برای تشخیص این وضعیت، نویسنده مفهوم «میزان اشغال» (Occupancy) را معرفی میکند؛ شمارندهای که با ارسال هر درخواست افزایش و با دریافت پاسخ (پایان بدنه پاسخ) کاهش مییابد. اگر نمودار اشغال هرگز از عدد ۱ بالاتر نرود، یعنی سیستم شما بهصورت متوالی اجرا میشود، فارغ از اینکه مدل زیربنایی شما چقدر قدرتمند است. در چنین حالاتی، بحث «همزمانی» (Concurrency) صرفاً یک خیالپردازی یا «داستان تخیلی» (Fan Fiction) است. این موضوع یادآور این نکته است که در بسیاری از APIهای رایگان، دریافت وضعیت HTTP 200 لزوماً به معنای پردازش موازی در لایههای زیرین نیست و ممکن است توهمی از سرعت باشد.
طبق گزارش dev.to، داشبوردهای سمت سرور اغلب حقیقت را پنهان میکنند چون آنها فقط زمان رسیدن درخواستها را میبینند و از عادتهای متوالی کلاینت بیخبرند. برای یافتن حقیقت، نویسنده یک ردیاب (Tracer) سفارشی طراحی کرده که چهار نقطه زمانی (Stamp) خاص را ثبت میکند:
- شروع درخواست (Request start): لحظهای که فراخوانی آغاز میشود.
- دریافت نخستین بایت (First byte received): لحظهای که سرور پاسخ دادن را شروع میکند.
- دریافت آخرین بایت (Last byte received): لحظهای که بدنه پاسخ به پایان میرسد.
- تعداد درخواستهای فعال (In-flight count): تعداد درخواستهایی که در هر لحظه در جریان هستند.
برای پیادهسازی فنی این ردیاب، نویسنده یک محیط تست (Harness) در پایتون با استفاده از یک Span dataclass و یک کلاس OccupancyLog ایجاد کرد. کلاس Span زمانهای t0 (شروع)، t_first (اولین بایت) و t1 (تکمیل) را ردیابی میکند که اجازه میدهد مقادیر wait_first_ms و total_ms محاسبه شوند. کلاس OccupancyLog از یک threading.Lock استفاده میکند تا افزایش و کاهش شمارنده in_flight را بهصورت ایمن در میان تردها (Threads) مدیریت کند.
این ردیاب هرگونه فراخوانی HTTP از نوع generate-style را پوشش میدهد. با نمونهبرداری از شمارنده در حین اجرای فراخوانیها، توسعهدهنده میتواند یک نمودار ASCII یا یک فایل CSV تولید کند. نمودار ASCII میزان اشغال را در طول زمان واقعی (Wall time) نشان میدهد که در آن هر کاراکتر نماینده یک نمونه است. اگر نمودار الگویی شبیه به «چهار کوه، چهار دره و صفر همپوشانی» را نشان دهد، تایید میشود که شما در یک حلقه متوالی گیر کردهاید.
برای جداسازی اثر حلقه از نویزهای ارائهدهندگان ابری، پیشنهاد میشود از یک سرور شبیهساز (Mock Server) محلی استفاده کنید. با اجرای یک سرور پایتونی چندرشتهای (mock_generate.py) که با دستور time.sleep() تأخیر مدل را شبیهسازی میکند، توسعهدهندگان میتوانند یک «توقف کنترلشده» ایجاد کنند. این کار مانع از آن میشود که توسعهدهنده نویزهای صف (Queue noise) ارائهدهنده ابری را به افسانههای فنی تبدیل کند. این شبیهساز عمداً چندرشتهای طراحی شده تا اگر کلاینت اجازه دهد، بتواند همپوشانیها را مدیریت کند.
در یک تست واقعی روی یک عامل متوالی، نویسنده توالی خاصی را مشاهده کرد: ابتدا یک فراخوانی برای «برنامهریزی» (plan)، سپس «جستوجوی ابزار» (tool_search)، بعد «واکشی ابزار» (tool_fetch) و در نهایت «جمعبندی» (recap). نتایج به شرح زیر بود:
- plan: اولین بایت = 200.4ms، کل = 201.1ms
- tool_search: اولین بایت = 350.2ms، کل = 350.9ms
- tool_fetch: اولین بایت = 350.1ms، کل = 350.8ms
- recap: اولین بایت = 200.3ms، کل = 201.0ms
حتی اگر از مدل سریعتری استفاده میشد، شکل نمودار تغییری نمیکرد؛ فقط کوهها کوتاهتر میشدند اما گپهای خالی همچنان باقی میماندند. گلوگاه اصلی، عادت به جفت کردن ابزارهایی بود که نیازی به جفت شدن نداشتند. نویسنده اشاره میکند که یک مدل بزرگتر در این حالت صرفاً «همان دندانهها را رنگ میزند»؛ یعنی دندانههای بلندتر، اما با همان گپهای خالی.
راهکار نهایی، شناسایی ابزارهای مستقل است. اگر ابزار B برای اجرا به خروجی ابزار A نیاز ندارد، باید هر دو بهطور همزمان با استفاده از Threading یا فراخوانیهای Async اجرا شوند. نویسنده استدلال میکند که این «عادت» اغلب گلوگاهی است که «نشان مدل» (Model Badge) به سینه زده است تا خودش را پنهان کند.
در مثال مذکور، مرحله «برنامهریزی» باید متوالی بماند چون مسیر بقیه کارها را تعیین میکند. اما ابزارهای «جستوجو» و «واکشی» میتوانند همپوشانی داشته باشند. وقتی نویسنده به یک حلقه همپوشان با استفاده از threading.Thread تغییر وضعیت داد، میزان اشغال در طول اجرای دستهای ابزارها به عدد ۲ رسید. در نتیجه، زمان کل اجرای عملیات (Wall-clock time) بهشدت کاهش یافت، در حالی که زمان پاسخ هر ابزار در سرور شبیهساز دقیقاً همان مقدار قبلی باقی مانده بود.
برای بهینهسازی و دوری از توصیههای مبتنی بر «فولکلور» و حدس و گمان، یک ماتریس تصمیمگیری بر اساس نمودار اشغال پیشنهاد میشود. این ماتریس بیشتر یک چکلیست برای کلاینت است تا یک کارت امتیاز برای ارائهدهنده:
- اشغال روی ۱ ثابت است: ابزارهای مستقل را همزمان کنید؛ قبل از اینکه بخواهید مدل «سریعتر» بخرید، این کار را انجام دهید.
- اشغال بالا میرود اما زمان اولین بایت (First-byte) بسیار زیاد است: به صف، DNS یا TLS نگاه کنید؛ توکنهای رمزگش (Decode tokens) را متهم نکنید.
- اشغال بالا میرود اما زمانهای کل (Totals) کم میشوند: ساختار موازی را حفظ کنید و کل عامل را بازنویسی نکنید.
- اشغال بالا میرود اما خطاها زیاد میشوند: تعداد درخواستهای فعال (In-flight) را محدود کنید و از Jitter (تأخیر تصادفی) استفاده کنید؛ به یک مسیر اشتراکی رایگان فشار بیش از حد نیاورید.
این تئوری سپس روی دسترسیهای رایگان مدلهای MonkeyCode و گزینه سرور آن تست شد (که بخشی از تلاشهای تبلیغاتی محصول MonkeyCode بود). نتیجه تایید کرد که میزان اشغال یک «واقعیت کلاینت» است. چه از GPU خصوصی استفاده کنید و چه از مسیرهای رایگان اشتراکی، اگر اشغال روی ۱ بماند، مشکل از حلقه است، نه سختافزار. در این زمینه، شناخت باورهای غلط درباره نقاط اتصال رایگان مدلهای هوش مصنوعی به توسعهدهندگان کمک میکند تا انتظارات واقعبینانهای از زیرساختهای اشتراکی داشته باشند.
با این حال، نویسنده چندین هشدار در مورد مسیرهای رایگان (Shared Lanes) میدهد:
- برای SLA مناسب نیستند: یک مسیر رایگان برای شکل دادن به کلاینت مفید است اما برای قراردادهای سطح خدمات (SLA) گزینه بدی است.
- انطباق و امنیت: از نظر انطباق امنیتی ضعیف است؛ هرگز اسرار و دادههای حساس را در یک جعبه پرامپت اشتراکی قرار ندهید.
- پایداری: مراقب باشید که تلاشهای مجدد (Retries) را به یک هجوم (Stampede) تبدیل نکنید.
باید توجه داشت که این ردیاب محدودیتهایی دارد و همه چیز را نمیبیند. این ابزار زمانبندی هسته (Kernel scheduling) یا میزان اشغال SMهای GPU را رصد نمیکند. این ردیاب فقط پروسه، سوکتها و «ادب» کلاینت را میبیند. اندازهگیریهای اولین بایت شامل صفهایی است که توسعهدهنده مالک آنها نیست و اندازهگیریهای آخرین بایت شامل تأخیرهای شبکهای خارج از کنترل اوست.
علاوه بر این، در حالی که Threading به شبیهساز کمک میکند، نمیتواند ابزارهای وابسته را «صادق» کند. اگر ابزار B به شناسهای (ID) از ابزار A نیاز داشته باشد، آنها باید متوالی بمانند. مرحله «جمعبندی» در یک عامل، یک عملیات ادغام (Merge) است، نه یک قهرمان؛ این مرحله باید منتظر بماند تا تمام ابزارهای قبلی تمام شوند، به همین دلیل است که میزان اشغال در این فاز بهدرستی دوباره به ۱ برمیگردد.
برای کسانی که میخواهند این نتایج را تکرار کنند، یک ابزار کامل پایتونی ارائه شده است. کلاس OccupancyLog شامل متد dump_csv برای خروجی گرفتن جهت رسم نمودار است. در حالی که نمودار ASCII برای بررسیهای سریع مفید است، نویسنده پیشنهاد میکند از یک اسکریپت ساده matplotlib برای رسم فایل CSV استفاده کنید. این بصریسازی بهوضوح «تابع پلهای» فراخوانیهای فعال را در طول ثانیههای زمان واقعی نشان میدهد.
محدودیتهای فنی کلیدی این ابزار عبارتند از:
- I/O مسدودکننده (Blocking): استفاده از
urllibدر این ابزار آموزشی بهطور عمدی مسدودکننده است. - ریسکهای Async: کلاینتهای تولیدی که از
asyncاستفاده میکنند، اگر ترتیبawaitآنها متوالی باشد، همچنان بهصورت متوالی عمل میکنند. - قفلگذاری (Locking): استفاده از
threading.Lockبرای جلوگیری از Race Condition هنگام بهروزرسانی شمارندهin_flightضروری است.
این روش برای همه نیست. نویسنده صراحتاً پیشنهاد میکند در موارد زیر از این رویکرد صرفنظر کنید:
- اگر قرارداد p99 سختگیرانهای دارید که نیاز به ابزارسازی (Instrumentation) عمیقتر دارد.
- اگر به دلیل محدودیتهای امنیتی نمیتوانید پرامپتها را روی یک جعبه اشتراکی قرار دهید.
- اگر امیدوارید یک نمودار بتواند جایگزین یک هدف سطح خدمات (SLO) رسمی شود.
- اگر در هر درخواست فقط یک فراخوانی دارید؛ در این صورت، اشغال روی ۱ درست و مورد انتظار است.
این رویکرد فرض بنیادی عیبیابی عاملها را تغییر میدهد. بهجای تنظیم دما (Temperature) یا تعویض مدل، اولین قدم باید رسم خط اشغال باشد. اگر تعداد درخواستهای در جریان هرگز تغییر نکند، توسعهدهنده در حال تماشای صفی است که خودش ساخته است. برای هر عاملی که دارای حلقه است، «دندانههای» ASCII نمودار اشغال، حقیقتی خشنتر و صادقانهتر از هر داشبورد سازندهای ارائه میدهد. وقتی دمو کند است، اولین سوال باید این باشد: «چه تعداد درخواست در جریان (In-flight) هستند؟»
گام بعدی شما
- ردیاب Occupancy را روی یکی از عاملهای کند خود پیاده کنید تا بفهمید گلوگاه در مدل است یا در ساختار فراخوانیها.
- ابزارهای مستقل در زنجیره عامل خود را شناسایی کرده و آنها را به صورت Async یا Threaded اجرا کنید.
- پیش از ارتقای مدل به نسخههای گرانتر و سریعتر، نمودار اشغال را رسم کنید تا از عدم اتلاف محاسبات مطمئن شوید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو