اگر برای سرویس‌های چت مبتنی بر هوش مصنوعی خود تأخیرهای چندثانیه‌ای را تجربه می‌کنید، احتمالاً مشکل از مدل نیست، بلکه از نحوه توزیع ترافیک در خوشه‌های GPU است. آمازون وب سرویسز (AWS) با معرفی Amazon SageMaker HyperPod Inference Gateway در ۱۸ سپتامبر ۲۰۲۶، ادعا می‌کند که می‌تواند زمان انتظار برای دریافت نخستین توکن را تا ۸۲٪ کاهش دهد.
این سامانه در واقع یک لایه مسیریابی است که با زبان Kubernetes صحبت می‌کند و برخلاف روش‌های قدیمی، وضعیت داخلی سخت‌افزار را می‌بیند. طبق اعلام AWS، تأخیر نخستین توکن در این سیستم از ۴.۴ ثانیه به کمتر از ۸۰۰ میلی‌ثانیه رسیده است.
مشکل مسیریابی کور
بسیاری از سیستم‌های فعلی از روش‌های ساده‌ای مثل Round-robin (نوبتی) یا Least-connections (کمترین اتصال) برای توزیع درخواست‌ها استفاده می‌کنند؛ یعنی درخواست‌ها را به‌صورت نوبتی بین GPUها پخش می‌کنند بدون اینکه بدانند کدام کارت گرافیک واقعاً درگیر است. طبق گفته AWS، این الگوریتم‌ها هیچ دیدی نسبت به وضعیت لحظه‌ای GPU ندارند.
این الگوریتم‌ها نمی‌توانند تشخیص دهند که آیا یک پاد (Pod) در حال تولید متنی با کانتکست بسیار طولانی است یا خیر. همچنین نمی‌توانند ببینند که آیا یک آداپتور LoRA خاص از قبل در حافظه بارگذاری شده است یا خیر. همان‌طور که در تحلیل‌های پیشین ما درباره بهینه‌سازی زیرساخت‌های مدل‌های زبانی اشاره کردیم، این «کوری» منجر به توزیع ناعادلانه بار می‌شود.
به نقل از مستندات AWS، این الگوریتم‌های ساده نمی‌توانند تشخیص دهند که آیا KV Cache (حافظه موقت کلید-مقدار) — که شبیه به یک یادداشت سریع از کلمات قبلی است تا مدل مجبور نباشد هر بار همه چیز را از اول بخواند — پر شده است یا خیر. در نتیجه، برخی GPUها بیکار می‌مانند و برخی دیگر زیر فشار درخواست‌ها دفن می‌شوند. این امر باعث می‌شود در زمان پیک ترافیک، تأخیر نخستین توکن به بالای ۴ ثانیه برسد. این پیش‌بینی‌ناپذیری اغلب اپراتورها را مجبور می‌کند تا برای جبران این ناکارآمدی، سخت‌افزار بیشتری از حد نیاز تهیه کنند (Over-provisioning).
معماری دو لایه
برای حل این بحران، آمازون یک معماری دو لایه طراحی کرده است که بر پایه مفاهیم بومی کوبرنتیز (Kubernetes-native primitives) بنا شده است. لایه اول به عنوان یک افزونه مدیریت‌شده برای Amazon EKS (با نام amazon-sagemaker-hyperpod-inference) نصب می‌شود و از سه بخش اصلی بر اساس افزونه بازمنبع Gateway API Inference Extension تشکیل شده است:
- Envoy Gateway: یک پروکسی لایه ۷ که ترافیک HTTPS ورودی را خاتمه داده و یک نقطه دسترسی (Endpoint) خصوصی واحد برای هر خوشه ایجاد می‌کند.
- Body-Based Router: این بخش محتوای هر درخواست ورودی سازگار با OpenAI را بررسی می‌کند، فیلد مدل (model field) را استخراج کرده و درخواست را به استخر مدل مربوطه می‌فرستد. این قابلیت اجازه می‌دهد تا یک گیت‌وی واحد، چندین مدل مختلف را پشتیبانی کند.
- Endpoint Picker: مغز متفکر سیستم است که معیارهای لحظه‌ای را از Prometheus در هر پادِ سرویس‌دهنده مدل دریافت می‌کند. این بخش یک الگوریتم امتیازدهی وزنی را اجرا می‌کند که شامل معیارهایی چون میزان اشغال KV Cache، عمق صف (Queue Depth)، حضور آداپتور LoRA در حافظه، نرخ برخورد کش پیشوند (Prefix Cache Hit Rate) و تعداد درخواست‌های در حال اجرا است. هر امتیازدهنده دارای یک وزن قابل تنظیم است تا رفتار سیستم را برای بارهای کاری خاص (مثلاً چت‌های حساس به تأخیر در مقابل پردازش‌های دسته‌ای بهینه‌شده برای توان عملیاتی) تنظیم کند.
لایه دوم که «مسیریاب استنتاج جهانی» (Global Inference Router) نام دارد، به‌زودی عرضه خواهد شد. این لایه بر روی لایه اول بنا می‌شود تا هماهنگی را در سطح کل ناوگان، شامل چندین خوشه و مناطق جغرافیایی مختلف مدیریت کند. این لایه قابلیت‌هایی چون جایگزینی در صورت شکست (Failover) بین خوشه‌ها، محدودسازی نرخ جهانی (Global Rate Limiting) و شکل‌دهی ترافیک بر اساس هزینه را فراهم می‌کند، در حالی که گیت‌وی‌های هر خوشه همچنان مسیریابی محلی را بر عهده دارند.
استقرار و نظارت
نصب این سیستم برای کاهش اصطکاک طراحی شده است. استقرار آن تنها با یک دستور aws eks create-addon و یک منبع سفارشی (Custom Resource) به نام InferenceGatewayConfig که مدل‌ها و رفتار مسیریابی را تعریف می‌کند، انجام می‌شود. استقرار مدل‌های موجود از طریق برچسب‌های پاد (Pod Labels) شناسایی می‌شوند. این سیستم به هیچ Sidecar، Service Mesh یا تغییر در کد اپلیکیشن نیاز ندارد.
گیت‌وی یک نقطه دسترسی استاندارد و سازگار با OpenAI را روی پروتکل HTTP ارائه می‌دهد. AWS اشاره کرده است که کدهای کلاینت فعلی بدون هیچ تغییری کار می‌کنند و نیازی به تغییر SDK یا امضای SigV4 برای ترافیک استنتاج نیست. این سیستم با هر سرور مدل سازگار با OpenAI، از جمله vLLM، SGLang و TGI سازگار است.
برای نظارت بر عملکرد، چهار سطح رصد تعریف شده است:
- سطح پاد (Pod Level): پرومتئوس میزان اشغال KV Cache، عمق صف، درخواست‌های در حال اجرا و حضور آداپتورها را ردیابی می‌کند.
- سطح استخر (Pool Level): پرومتئوس و گرافانا تعداد کل درخواست‌ها، هیستوگرام‌های مدت‌زمان و تعداد توکن‌ها را رصد می‌کنند.
- سطح خوشه (Cluster Level): سرویس Amazon CloudWatch میانگین KV Cache، نرخ خطا و تأخیر P99 را ردیابی می‌کند.
- سطح ناوگان (Fleet Level): کلودواچ تصمیمات مسیریابی، رویدادهای Failover و دفعات برخورد با محدودیت نرخ (Rate Limit) را ثبت می‌کند.
بهینه‌سازی لورا و مدیریت خطا
برای تیم‌هایی که از لورا (LoRA) — که شبیه به اضافه کردن یک دفترچه راهنمای کوچک و تخصصی به یک کتابخانه بزرگ است تا مدل در یک حوزه خاص خبره شود — استفاده می‌کنند، یک امتیازدهنده اختصاصی به نام LoRA Affinity Scorer تعبیه شده است. این قابلیت تضمین می‌کند درخواست‌ها به همان پادهایی بروند که آداپتور مورد نیاز را از قبل در حافظه GPU دارند. اگر هیچ پادی آداپتور را بارگذاری نکرده باشد، درخواست به پادی با بیشترین ظرفیت available می‌رود؛ AWS می‌گوید این کار تأخیر ناشی از جابه‌جایی آداپتورها (Adapter Swap Latency) را حذف می‌کند.
رفتارهای تعریف‌شده برای مدیریت خطا جهت تضمین پایداری سیستم عبارتند از:
- شکست پاد: Endpoint Picker پادهایی که معیارهای آن‌ها قدیمی (Stale) شده است را حذف کرده و ترافیک را به پادهای سالم می‌فرستد.
- اتمام ظرفیت استخر: گیت‌وی خطای HTTP 429 را همراه با هدر
Retry-Afterبرمی‌گرداند تا در این فاصله، سیستم Autoscaling ظرفیت جدید اضافه کند. - شکست خوشه: مسیریاب جهانی متوجه قطع ضربان قلب (Heartbeat) شده و ترافیک را ظرف ۳۵ ثانیه تغییر مسیر می‌دهد.
- شکست منطقه‌ای: مسیریابی بین‌منطقه‌ای به‌طور خودکار فعال می‌شود. AWS اشاره کرده که این حالت تأخیر بیشتری دارد اما تأثیری بر در دسترس بودن (Availability) نمی‌گذارد.
نتایج بنچمارک
آمازون آزمایش‌های خود را روی نمونه‌های p5.48xlarge با GPUهای H100 و نمونه‌های g5 با A10G روی مدل‌هایی با اندازه ۸ میلیارد تا ۲۳۵ میلیارد پارامتر انجام داده است. تمام ترافیک از طریق Application Load Balancerهای داخلی با یک گروه گره کلاینت اختصاصی و سرورهای مدل ایزوله عبور کرده است. نتایج در برابر روش Round-robin کوبرنتیز با پیکربندی پیش‌فرض اندازه‌گیری شده است:
- Llama-3.1-8B: تأخیر P95 و P99 هر کدام ۹۷٪ کاهش یافت و توان عملیاتی ۸٪ افزایش یافت. در حالت استفاده از پیشوندهای مشترک (Shared Prompt Prefixes)، تأخیر P95 و P99 به ترتیب ۲۶٪ و ۴۳٪ کاهش یافت.
- Qwen3-32B: تأخیر P95 و P99 به ترتیب ۹۸٪ و ۹۷٪ کاهش یافت و توان عملیاتی ۵۰٪ افزایش یافت.
- Llama-3.1-70B: در ترافیک‌های شدید (Bursty)، تأخیر P95 و P99 به ترتیب ۹۴٪ و ۹۸٪ کاهش یافت و توان عملیاتی ۱۲٪ بیشتر شد.
- Qwen3-235B: کاهش مشابهی در P95 و ۸۹٪ کاهش در تأخیر P99 نشان داد.
این بهبودها به‌ویژه در محیط‌هایی که سخت‌افزارهای متنوع دارند، ترافیک نوسانی دارند یا از پیشوندهای مشترک استفاده می‌کنند، مشهودتر است. AWS اشاره کرده که در ناوگان‌های کاملاً یکنواخت با ترافیک ثابت، عملکرد این گیت‌وی مشابه Round-robin است.
در واقع، زیرساخت استنتاج از حالت «مسیریابی کور» به «مسیریابی آگاه از وضعیت» تغییر کرده است. با تبدیل وضعیت حافظه داخلی GPU به یک سیگنال اصلی برای مسیریابی، AWS به‌طور مؤثری «اتلاف» در خوشه‌های محاسباتی گران‌قیمت را کاهش می‌دهد. برای کسب‌وکارها، این به معنای توان عملیاتی بالاتر از همان تعداد H100 و تجربه کاربری سازگارتر برای اپلیکیشن‌های چت است. این رویکرد بهینه‌سازی زیرساختی در کنار ادغام مدل‌های پیشرفته، مشابه کاهش هزینه‌های عملیاتی در محیط Kiro است که با بهینه‌سازی لایه‌های استقرار حاصل شد.
نقشه راه و مدیریت
مدیریت این سیستم از طریق kubectl ،GitOps ،Helm و ArgoCD انجام می‌شود و چرخه حیات افزونه EKS، نصب، ارتقا و بازگشت (Rollback) را مدیریت می‌کند. مسیریابی لایه اول در هر خوشه از ۱۸ سپتامبر ۲۰۲۶ در مناطق پشتیبانی‌شده در دسترس است.
به‌روزرسانی‌های آینده شامل موارد زیر است:
- تقسیم ترافیک کاناری (Canary Traffic Splitting): مسیریابی درصدی از ترافیک به نسخه‌های جدید مدل با استفاده از منابع سفارشی
InferenceModelRewrite. - کنترل جریان (Flow Control): طبقه‌بندی درخواست‌ها به سه دسته «حیاتی» (Critical)، «استاندارد» (Standard) و «قابل حذف» (Sheddable) با کنترل پذیرش برای هر باند.
کاربران باید در دسترس بودن افزونه استنتاج را در مناطق خاص AWS خود بررسی کنند تا پیاده‌سازی را آغاز نمایند.
گام بعدی شما
- اگر از EKS برای سرویس‌دهی مدل استفاده می‌کنید، در دسترس بودن افزونه
amazon-sagemaker-hyperpod-inferenceرا در منطقه خود بررسی کنید. - برای مدل‌های چندگانه، پیکربندی
InferenceGatewayConfigرا برای جداسازی استخرهای مدل بهینه کنید. - در صورت استفاده از LoRA، اثر LoRA Affinity Scorer روی زمان پاسخ‌دهی مدل‌های تخصصی خود بسنجید.
اما بهینه‌سازی لایه شبکه تنها بخشی از ماجراست؛ برای درک اینکه چگونه سخت‌افزارهای جدیدتر این تأخیرها را در سطح تراشه حذف می‌کنند، تحلیل ما درباره تراشه‌های Blackwell را بخوانید. در همین راستا، بررسی پتانسیل تراشه Jalapeño نشان می‌دهد که چگونه سخت‌افزارهای اختصاصی می‌توانند حتی برتری‌های معماری Blackwell را در استنتاج به چالش بکشند.
گفتگو