درون زیرساخت‌های AWS؛ عدم پیش‌بینی‌پذیری ظرفیت سرورها در مناطق مختلف

اگر امروز برای استقرار مدل‌های زبانی در AWS هزینه می‌پردازید، احتمالاً از گران‌ترین و کندترین مسیر ممکن استفاده می‌کنید. داده‌های جدید نشان می‌دهد که یک ترکیب خاص از سخت‌افزار و نرم‌افزار می‌تواند هزینه‌های استنتاج شما را به شدت کاهش دهد و سرعت پاسخ‌دهی را به بیش از ۱۳۱ توکن در ثانیه برساند.

طبق گزارش منتشر شده در ۵ اکتبر ۲۰۲۶، استنتاج روی نمونه‌های EC2 g6.xlarge با استفاده از vLLM، با سرعت میانه ۱۳۱.۵ توکن در ثانیه، تمام بک‌اندهای مورد آزمایش در AWS را پشت سر گذاشت. این نتیجه، انتظارات از عملکرد میزبانی شخصی (Self-hosting) مدل‌های زبانی بزرگ را تغییر می‌دهد و ثابت می‌کند که ترکیب GPU و نرم‌افزار مناسب می‌تواند سرویس‌های مدیریت‌شده را هم در تأخیر و هم در هزینه شکست دهد. در واقع، انتخاب بین موتورهای مختلف استنتاج، بسته به مقیاس کاربرد، می‌تواند تفاوت‌های چشم‌گیری در بهره‌وری ایجاد کند؛ موضوعی که در مقایسه‌ی جامع vLLM و Ollama بر اساس نیازهای سروری و شخصی به تفصیل بررسی کرده‌ایم.

انتخاب محل میزبانی مدل در AWS به تجربه‌ای پراکنده تبدیل شده است. توسعه‌دهندگان باید بین APIهای مدیریت‌شده، نقاط انتهایی (Endpoints) اختصاصی، اجاره GPU خام یا تراشه‌های شتاب‌دهنده اختصاصی انتخاب کنند. هر مسیر، خطاهای خاص، ساختار قیمت‌گذاری و پیچیدگی‌های نصب متفاوتی دارد. برای حل این ابهام، یک بررسی جدید با استفاده از یک عامل (Agent) — شبیه به یک مدیر پروژه هوشمند که دستورات را بین چندین کارمند پخش می‌کند و نتایج را جمع‌آوری می‌کند — شش بک‌اندهای مختلف را با پرامپت‌ها و اسکریپت‌های ارزیابی یکسان آزمایش کرد. تمام اعداد این گزارش از دو اجرای کامل در یک روز واحد با پرامپت‌های یکسان استخراج شده است.

زیرساخت سخت‌افزاری و نرم‌افزاری

این بررسی شش مسیر مختلف برای سرویس‌دهی به مدل Gemma 4 را مقایسه کرد. مسیر اول Amazon Bedrock بود که مدل Amazon Nova Micro (با شناسه us.amazon.nova-micro-v1:0) را به عنوان یک API مدیریت‌شده ارائه می‌داد. مسیر دوم، یک نقطه انتهایی در SageMaker بود که کانتینر vLLM را روی نمونه ml.g6.xlarge اجرا می‌کرد. مسیر سوم، یک نمونه خام EC2 g6.xlarge با پردازنده NVIDIA L4 بود که vLLM نسخه ۰.۳۰ را اجرا می‌کرد.

برای بررسی معماری‌های جایگزین، یک نمونه EC2 g5g.2xlarge شامل میزبان Arm Graviton2 و GPU NVIDIA T4G نیز تست شد. این مورد نیازمند نسخه اصلاح‌شده vLLM 0.27.2rc0 بود تا بتواند هسته‌های sm_75 پردازنده T4G و نیازهای خاص سرهای توجه (Attention Heads) مدل Gemma 4 را مدیریت کند. در نهایت، تراشه‌های اختصاصی AWS یعنی Inferentia2 (inf2.xlarge) و Trainium (trn1.2xlarge) مورد آزمایش قرار گرفتند.

جزئیات پیاده‌سازی

بر اساس مستندات فنی این بررسی، هر بک‌انند برای کار در چارچوب عامل Strands به پیکربندی خاصی نیاز داشت:

• Amazon Bedrock: نیازی به نمونه یا نقطه انتهایی نداشت. این سرویس از یک شناسه پروفایل استنتاج (us.amazon.nova-micro-v1:0) استفاده کرد تا از خطاهای اعتبارسنجی مرتبط با توان عملیاتی On-demand جلوگیری کند. تنظیمات این بخش تنها به یک مجوز IAM و یک شناسه مدل نیاز داشت.
• EC2 g6 (vLLM 0.30): یک نسخه ۴ بیتی از Gemma 4 E2B (xbill9/gemma-4-E2B-it-qat-q4_0-w4a16-ct-text-emb4) را سرویس داد. برای فعال‌سازی فراخوانی ابزار (Tool Call)، دو فلگ خاص --enable-auto-tool-choice و --tool-call-parser gemma4 لازم بود. این نمونه ۱۴.۰ دقیقه زمان برد تا به وضعیت سالم (Healthy) برسد.
• EC2 g5g (vLLM 0.27.2rc0): از یک AMI پیش‌ساخته استفاده کرد. بارگذاری وزن‌ها به دلیل اولین خوانش از یک Volume تازه که از یک اسنپ‌شات AMI بازیابی شده بود، ۵۲۰.۹۷ ثانیه زمان برد. هزینه این نمونه ۰.۵۵۶ دلار در ساعت است.
• SageMaker: از کانتینر vLLM شرکت AWS روی ml.g6.xlarge استفاده کرد. فلگ‌های vLLM به عنوان متغیرهای محیطی مانند SM_VLLM_ENABLE_AUTO_TOOL_CHOICE ، SM_VLLM_MODEL و SM_VLLM_TOOL_CALL_PARSER پاس داده شدند. نقطه انتهایی در ۸.۲ دقیقه به وضعیت InService رسید.
• Inferentia2 و Trainium: یک ایمیج دست‌نویس از Gemma 4 (xbill9/gemma4-optb:slim) را اجرا کردند. ایمیج کامپایل‌شده برای inf2 بدون نیاز به بازسازی روی trn1.2xlarge اجرا شد، زیرا هر دو دارای چیدمان شتاب‌دهنده یکسان هستند: دو هسته NeuronCore-v2 و ۳۲ گیگابایت حافظه دستگاه در هر تراشه. نمونه inf2.xlarge حدود ۱۴.۳ دقیقه و trn1.2xlarge حدود ۱۲.۸ دقیقه زمان برد تا آماده شوند.

مکانیزم‌های داخلی بک‌انندها

همان‌طور که در تحلیل‌های قبلی ما درباره بهینه‌سازی استنتاج اشاره کردیم، لایه نرم‌افزاری تعیین‌کننده سرعت نهایی است. در اینجا، اجرای Neuron از یک گراف torch_neuronx استفاده می‌کند. روی یک trn1.2xlarge مدل E2B در ۱۲۱.۲ ثانیه به وضعیت READY رسید و برای درخواستی با ۱۷ توکن پرامپت و ۹۴ توکن پاسخ، با سرعت ۳۸.۱ توکن در ثانیه سرویس داد. همچنین یک نسخه بزرگ‌تر ۲۶ میلیارد پارامتری از نوع ترکیب خبره‌ها (Mixture of Experts) — شبیه به تیمی از متخصصان که هر سوال را به فرد خبره‌تر می‌سپارند — با استفاده از slim int8-squeeze و ModelBuilder TP=2 تست شد که ۲۲۰.۱ ثانیه زمان بارگذاری نیاز داشت. برای درک عمیق‌تر از نحوه رفع گلوگاه‌های تأخیر در سیستم‌های پیچیده، تحلیل معماری Prime Inference در مدیریت پنجره‌های متنی طولانی دیدگاه‌های تکمیلی مفیدی ارائه می‌دهد.

در بخش مدیریت حافظه، trn1.2xlarge با ۸ پردازنده مجازی و ۳۲ گیگابایت رم، فضای بیشتری نسبت به inf2.xlarge (با ۴ پردازنده مجازی و ۱۶ گیگابایت رم) فراهم کرد. این فضای اضافی اجازه داد مدل E2B با اوج مصرف RSS معادل ۱۹.۵۳ گیگابایت بدون نیاز به فایل Swap بارگذاری شود.

در مورد یکپارچگی SageMaker، عامل Strands از طریق SageMakerAIModel ارتباط برقرار می‌کند که فراخوانی‌های invoke_endpoint را امضا می‌کند. پیکربندی مورد استفاده شامل max_tokens: 512 ، stream: False و temperature: 0.0 بود. در مقابل، استقرار روی g6 از دستور docker run با فلگ‌های --gpus all و --ipc=host و مقدار --max-model-len برابر با ۸۱۹۲ به همراه --gpu-memory-utilization 0.90 استفاده کرد.

اتصال و دسترسی

برای حفظ امنیت، نمونه‌ها هیچ ترافیک ورودی مستقیم نمی‌پذیرفتند. دسترسی از طریق پلاگین Session Manager در AWS CLI مدیریت شد. با استفاده از Port Forward، پورت ۸۰۰۰ هر نمونه به پورت‌های محلی (مثلاً ۸۰۰۱) متصل شد تا عامل Strands بتواند از طریق http://localhost:8001/v1 با سرورهای سازگار با OpenAI ارتباط برقرار کند یا از طریق فراخوانی‌های امضا شده invoke_endpoint با SageMaker در ارتباط باشد.

بنچمارک عملکرد و هزینه

داده‌ها سلسله‌مراتب واضحی را در سرعت و بهره‌وری نشان می‌دهند. در تستی برای نوشتن یک پاراگراف کوتاه درباره اقیانوس (محدودیت ۱۰۰ توکن)، نمونه EC2 g6 با vLLM به سرعت ۱۳۱.۵ توکن در ثانیه رسید. در مقابل، API مدیریت‌شده Bedrock به‌طور میانگین ۱۱۱.۹ توکن در ثانیه ثبت کرد. بک‌اندهای مبتنی بر Neuron (inf2 و trn1) با میانگین ۳۶.۴ و ۳۷.۱ توکن در ثانیه، به‌طور قابل‌توجهی کندتر بودند و g5g با ۳۷.۲ توکن در ثانیه درست پشت سر تراشه‌های Neuron قرار گرفت.

بهره‌وری هزینه بر اساس قیمت‌های لیست us-east-1 نیز روند مشابهی داشت. هزینه برای هر میلیون توکن از تقسیم قیمت ساعتی بر تعداد توکن‌های تولید شده در ساعت محاسبه شد:

• EC2 g6.xlarge: با قیمت ۰.۸۰۴۸ دلار در ساعت $ \rightarrow $ ۱.۷۰ دلار به ازای هر میلیون توکن.
• EC2 g5g.2xlarge: با قیمت ۰.۵۵۶ دلار در ساعت $ \rightarrow $ ۴.۱۵ دلار به ازای هر میلیون توکن.
• EC2 inf2.xlarge: با قیمت ۰.۷۵۸۲ دلار در ساعت $ \rightarrow $ ۵.۷۹ دلار به ازای هر میلیون توکن.
• EC2 trn1.2xlarge: با قیمت ۱.۳۴۳۸ دلار در ساعت $ \rightarrow $ ۱۰.۰۶ دلار به ازای هر میلیون توکن.

شکاف اکوسیستم Neuron

یک یافته بحرانی، وضعیت اکوسیستم AWS Neuron است. این مطالعه نشان داد که هیچ‌یک از نسخه‌های فعلی vLLM، مدل Gemma 4 را روی Neuron پشتیبانی نمی‌کنند. نسخه‌های vLLM-Neuron 0.24.0.1.1.0 و 0.21.0.1.0.0 تنها Trn2 و Trn3 را لیست می‌کنند، در حالی که خط 0.5.3 به vLLM 0.16 محدود شده است. برای اجرای مدل روی Inferentia2 یا Trainium، پژوهشگر مجبور شد مدل را به‌صورت دستی به یک گراف torch_neuronx تبدیل کند.

این تبدیل دستی محدودیت‌های شدیدی دارد:

• گراف در اندازه ثابت ۵۱۲ توکن ردیابی می‌شود که تنها ۱۲۸ توکن آن برای پرامپت رزرو شده است.
• سرور تعریف ابزارها (Tool Definitions) را کاملاً نادیده می‌گیرد.
• محدودیت ۱۲۸ توکنی پرامپت باعث می‌شود پرامپت‌های سیستمی و طرح‌های ابزاری (Tool Schemas) عامل Strands در آن جا نشوند.

واقعیت‌های ظرفیت و سهمیه

این بررسی تفاوت خطرناک بین «سهمیه» (Quota) و «ظرفیت» (Capacity) را برجسته می‌کند. سهمیه یعنی اجازه درخواست دارید، اما ظرفیت یعنی AWS واقعاً آن ماشین را در آن منطقه (Zone) داشته باشد.

در اجرای اول، راه‌اندازی inf2.xlarge در us-east-2a با خطای InsufficientInstanceCapacity شکست خورد، در حالی که ۸۰ پردازنده مجازی سهمیه آزاد وجود داشت. در نهایت، راه‌اندازی تنها در us-east-2b موفق بود. در اجرای دوم، پژوهشگر متوجه شد که هیچ ظرفیتی برای inf2.xlarge در هیچ‌یک از مناطق us-east-2 یا us-east-1 وجود ندارد و ماشین تنها در us-west-2a با موفقیت اجرا شد.

علاوه بر این، درخواست‌های Spot Instance برای Trainium (۸ پردازنده مجازی) در چهار منطقه آمریکا منجر به باز شدن تیکت‌های پشتیبانی شد که هیچ‌کدام به‌طور خودکار تایید نشدند. برای خرید دقیق یک نمونه trn1.2xlarge، سهمیه On-demand معادل ۸.۰ پردازنده مجازی در us-east-2 مورد نیاز بود.

قابلیت اطمینان عامل‌محور

با استفاده از عامل Strands، صحت فراخوانی ابزارها از طریق ابزار count_ids(op, value) تست شد. Bedrock، g6، SageMaker و g5g همگی ۲۰ از ۲۰ پاسخ صحیح و ۲۰ از ۲۰ فیلتر صحیح (id >= 10) را ثبت کردند.

به دلیل محدودیت توکن در بک‌اندهای Neuron، آن‌ها نتوانستند یک عامل را مستقلاً هدایت کنند و به عنوان ابزارهای یک عامل اصلی در Bedrock تست شدند. در دمو شناسایی پایتخت فرانسه، همه پاسخ «پاریس» را دادند. سریع‌ترین پاسخ متعلق به Trainium با ۰.۱۹۶ ثانیه بود، هرچند در ۴ مورد از ۵ اجرای بعدی، g6 سریع‌ترین بود. در اجرای دوم، g6 در چهار مورد و trn1 در یک مورد سریع‌ترین بود و اختلاف آن‌ها تنها ۹ میلی‌ثانیه بود. با این حال، باید به خاطر داشت که یک پاسخ موفق به تنهایی دلیل کافی برای تأیید کامل یکپارچگی سیستم نیست و نیازمند تست‌های تکرارپذیر است.

پایداری و تکرارپذیری

برای تأیید نتایج، اجرای دوم کامل انجام شد. تمام بک‌اندهای میزبانی شخصی در محدوده ۴٪ سرعت اجرای اول باقی ماندند. به‌طور خاص، g6 از ۱۳۱.۵ به ۱۳۲.۴۵ توکن در ثانیه رسید (+۰.۷٪)، در حالی که g5g از ۳۷.۲ به ۳۵.۸ توکن در ثانیه افت کرد (-۳.۸٪).

در دمای (Temperature) صفر، بک‌اندهای میزبانی شخصی بسیار سازگار بودند؛ g6 و SageMaker متنی دقیقاً یکسان (کلمه به کلمه) تولید کردند و inf2 و trn1 نیز مشابه بودند. در مقابل، Bedrock در ۱۰ تکرار با دمای صفر، ۹ پاسخ متفاوت ارائه داد.

خلاصه یافته‌ها

• سریع‌ترین: EC2 g6 (vLLM) با ۱۳۱.۵ توکن در ثانیه.
• ارزان‌ترین: EC2 g6 با ۱.۷۰ دلار به ازای هر میلیون توکن.
• پایدارترین: Bedrock (بدون نیاز به نصب، API سازگار).
• دشوارترین: Inferentia2/Trainium (نیازمند تبدیل دستی برای Gemma 4).

این تغییر در بنچمارک‌ها نشان می‌دهد برای توسعه‌دهندگانی که به وزن‌های اختصاصی یا نسخه‌های بازسازی‌شده مدل نیاز دارند، نمونه خام EC2 g6 در حال حاضر بهینه‌ترین توازن بین عملکرد و قیمت است. نقاط انتهایی مدیریت‌شده مانند SageMaker راحتی را فراهم می‌کنند اما بدون افزایش سرعت، هزینه ساعتی بیشتری می‌گیرند.

اگر قصد استقرار در محیط عملیاتی را دارید، ابتدا ظرفیت نمونه خود را در حداقل دو منطقه مختلف AWS بررسی کنید تا با خطاهای InsufficientInstanceCapacity مواجه نشوید. همچنین برای عیب‌یابی اتصالات و Port Forward، ابتدا از مدل‌های کوچک (مانند E2B) استفاده کنید، زیرا این مدل‌ها در صورت بروز خطا در عرض چند دقیقه شکست می‌خورند، نه چند ساعت (مانند مدل‌های بزرگتر ۲۶B MoE).

گام بعدی شما

• اگر از سرویس‌های مدیریت‌شده AWS استفاده می‌کنید، هزینه و سرعت خود را با نمونه‌های g6 و vLLM مقایسه کنید تا پتانسیل کاهش هزینه‌ها را بسنجید.
• پیش از استقرار در محیط عملیاتی، ظرفیت نمونه (Capacity) را در حداقل دو منطقه مختلف AWS بررسی کنید تا با خطای کمبود ماشین مواجه نشوید.
• برای عیب‌یابی اتصالات و Port Forward، ابتدا از مدل‌های کوچک (مانند E2B) استفاده کنید تا زمان شکست سیستم در مقیاس بزرگ کاهش یابد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.