یک صورت‌حساب پنج‌رقمی یا موجی از خطاهای ۴۲۹، معمولاً اولین نشانه‌هایی هستند که به یک تیم هشدار می‌دهند واحد‌های توان عملیاتی رزروشده (PTU) در مایکروسافت فاندری (Microsoft Foundry) یک گزینه ساده برای قیمت‌گذاری نیستند. طبق راهنمای فنی منتشرشده در ۲۹ سپتامبر ۲۰۲۶، انتخاب PTU در واقع یک تصمیم مهندسی ظرفیت است که کاربر باید پیش از استقرار، محاسبات ریاضی آن را دقیقاً انجام دهد. بسیاری از تیم‌ها این موضوع را از راه سخت کشف می‌کنند: یا با طوفانی از خطاهای ۴۲۹ در هنگام لانچ محصول روی یک استقرار استاندارد، یا با یک صورت‌حساب عظیم پس از آنکه کسی «فقط کمی بیشتر رزرو کرد تا خیالمان راحت باشد».
بسیاری از سیستم‌های عملیاتی در نهایت با مدل‌های پرداخت به‌ازای مصرف (Pay-as-you-go) به بن‌بست می‌رسند؛ زیرا این مدل‌ها ظرفیت منطقه‌ای را بین تمام کاربران (Tenants) تقسیم می‌کنند. این موضوع باعث ایجاد نوسانات پیش‌بینی‌ناپذیر در تأخیر (Latency) می‌شود که برای ابزارهای حساس مثل دستیارهای پرداخت یا سیستم‌های بررسی تقلب غیرقابل‌قبول است. همان‌طور که در تحلیل قبلی ما درباره‌ی ریسک‌های امنیتی سرورهای MCP مایکروسافت و گوگل و خطراتی مانند SSRF اشاره کردیم، در اینجا ریسک نه امنیتی، بلکه مالی و عملکردی است. استقرار استاندارد هیچ تضمینی برای توان عملیاتی (Throughput) نمی‌دهد و تنها خدماتی در حد توان سیستم (Best-effort) ارائه می‌کند که با محدودیت‌های نرخ توکن (TPM/RPM) مدیریت می‌شوند و این محدودیت‌ها می‌توانند تحت فشار بار منطقه‌ای، سخت‌گیرانه‌تر شوند.
تصور کنید شرکتی در روزهای شلوغ «بلک فرایدی» یک بات مشتریان را مدیریت می‌کند. در استقرار استاندارد، هیچ تضمینی برای سرعت پاسخ‌دهی وجود ندارد و تنها خدمات در حد توان ارائه می‌شود. PTUها این مشکل را حل می‌کنند؛ آن‌ها با فراهم کردن ظرفیت مدل اختصاصی و ایزوله، تضمین می‌کنند که مدل فارغ از بار منطقه‌ای، «گرم» و در دسترس باقی بماند و برای هر مدل، یک توافق‌نامه سطح خدمات (SLA) مشخص برای تأخیر ارائه دهد. در مقابل، هزینه این ظرفیت اختصاصی به‌صورت ساعتی محاسبه می‌شود، چه از آن استفاده کنید و چه نکنید. بنابراین، تخمین کم ظرفیت منجر به کندی سیستم و محدود کردن کاربران می‌شود، و تخمین زیاد، باعث سوزاندن بودجه برای سخت‌افزارهای بیکار می‌گردد. این خطاهای تخمینی دقیقاً همان نقاط ضعفی هستند که در بررسی چهار تله عملیاتی در هزینه‌های مدل‌های زبانی به آن‌ها اشاره کردیم و نشان دادیم چگونه می‌توانند هزینه‌ها را به شدت افزایش دهند.
انواع استقرار
مدل‌های فاندری چهار شکل استقرار مختلف دارند که هر کدام تعادلی بین هزینه، تأخیر و پیش‌بینی‌پذیری ایجاد می‌کنند:
- استاندارد (Standard): پرداخت به‌ازای توکن بدون تضمین تأخیر. مناسب برای محیط‌های توسعه، تست یا ترافیک تولیدی با حجم کم و غیرقابل‌پیش‌بینی.
- پردازش اولویت‌دار (Priority Processing): پرداخت به‌ازای توکن با نرخ اولویت. این مدل یک هدف تأخیر مشخص را بدون نیاز به تعهد بلندمدت فراهم می‌کند و برای بارهای کاری تولیدی که به تأخیر حساس هستند، ایده‌آل است.
- رزروشده (Provisioned): محاسبه هزینه به‌ازای هر PTU در هر ساعت (یا از طریق رزرو). این مدل یک هدف تأخیر مشخص برای هر مدل ارائه می‌دهد و مخصوص بارهای کاری حیاتی، در مقیاس بالا و با توان عملیاتی تضمین‌شده است.
- دسته‌ای (Batch): پردازش غیرهمزمان با تخفیف توکنی و بدون تضمین تأخیر. مناسب برای کارهای حجیم و غیرتعاملی مثل تولید بردار معنایی (Embedding) برای داده‌های قدیمی یا اجرای ارزیابی‌های آفلاین.
در اینجا تصمیم بر سر این نیست که کدام گزینه به‌ازای هر توکن ارزان‌تر است (که معمولاً در حجم کم، مدل استاندارد برنده است)، بلکه تصمیم واقعی این است که یک جهش چندثانیه‌ای و پیش‌بینی‌ناپذیر در تأخیر، چه هزینه‌ای برای محصول شما دارد.
چهار رکن PTUها
توان عملیاتی رزروشده متفاوت از محاسبات ابری استاندارد عمل می‌کند. اول اینکه PTUها هنگام خرید مستقل از مدل هستند اما بازدهی آن‌ها به مدل بستگی دارد. شما مجموعه‌ای از PTUها را می‌خرید و آن‌ها را به یک مدل متصل می‌کنید، اما یک مدل سنگین‌تر (با پنجره متنی بزرگتر یا پارامترهای بیشتر) برای رسیدن به همان مقدار توکن در دقیقه (TPM)، به PTUهای بیشتری نیاز دارد. استفاده از تعداد PTUهای فصل گذشته برای یک نسخه به‌روزرسانی شده از مدل، بدون اجرای مجدد محاسبات، یکی از منابع اصلی تخمین‌های اشتباه است.
دوم، تفاوت بین سهمیه (Quota) و ظرفیت (Capacity) است. سهمیه یک سقف سیاستی است که به هر اشتراک، در هر منطقه Azure و برای هر نوع استقرار (Global، Data Zone و Regional که استخرهای جداگانه‌ای دارند) اعطا می‌شود. سهمیه‌ای که در East US تأیید شده است، در West Europe هیچ ارزشی ندارد. اما ظرفیت، همان سخت‌افزار فیزیکی موجود در مرکز داده در آن لحظه است. داشتن سهمیه تأییدشده، لزوماً به معنای امکان استقرار نیست اگر سخت‌افزار فیزیکی منطقه توسط سایر کاربران اشغال شده باشد.
سوم، هر مدل حداقل‌های خاص و گام‌های مقیاس‌پذیری دارد. شما نمی‌توانید بخشی از یک واحد را مستقر کنید؛ باید عدد را به نزدیک‌ترین گام گرد کنید، مثلاً ۵ یا ۵۰ PTU. به دلیل این الزام به گرد کردن، عدد محاسبه شده شما تقریباً هرگز با عدد خریداری شده مطابقت نخواهد داشت.
چهارم، صورت‌حساب ثابت است. شمارنده از لحظه ایجاد تا حذف فعال است، فارغ از اینکه میزان استفاده ۵٪ باشد یا ۹۵٪. این موضوع باعث می‌شود که بیش‌تخمینی (Over-provisioning) گران تمام شود و کم‌تخمینی منجر به خطاهای ۴۲۹ گردد، و تقریباً هیچ نقطه تعادل راحتی وجود ندارد مگر اینکه سایزینگ دقیق باشد. در کنار این هزینه‌های ثابت، وجود فرآیندهای رها شده در پس‌زمینه نیز می‌تواند بودجه را به شدت تخریب کند؛ موضوعی که در راهنمای شناسایی و توقف فرآیندهای زامبی در سیستم‌های استریمینگ به طور مفصل بررسی کردیم.
فرمول تخمین ظرفیت
فاندری ترافیک را با استفاده از فرمولی به عدد «TPM نرمال‌شده» تبدیل می‌کند که نرخ درخواست، شکل پرامپت/پاسخ و نرخ命中 حافظه (Cache hit rate) را به یک عدد واحد تبدیل می‌کند. سپس این عدد بر ثابتِ توان عملیاتی هر PTU تقسیم می‌شود.
برای این محاسبه به سه ورودی اصلی از پروفایل ترافیکی شما نیاز است:
- Peak RPM: بیشترین تعداد درخواست در دقیقه در شلوغ‌ترین بازه پایدار. سایزینگ بر اساس میانگین RPM، تضمین‌کننده خطای ۴۲۹ در زمان پیک است.
- میانگین اندازه توکن: میانگین اندازه پرامپت و میانگین اندازه پاسخ بر حسب توکن.
- نرخ حافظه (Cache Rate): کسری از توکن‌های ورودی که از حافظه پرامپت فاندری تأمین می‌شوند. توکن‌های کش‌شده از مصرف PTU مستثنی می‌گردند.
در این فرمول، توکن‌های خروجی وزن بیشتری دارند زیرا تولید یک توکن خروجی، هزینه محاسباتی بیشتری نسبت به پردازش یک توکن ورودی دارد. برای مدل‌های کلاس GPT-4.1، این نسبت با نسبت قیمت‌گذاری استاندارد مطابقت دارد؛ یعنی اگر توکن‌های خروجی ۴ برابر گران‌تر باشند، تقریباً ۴ برابر ظرفیت PTU را مصرف می‌کنند.
مسیر محاسبه:
۱. TPM ورودی = Peak RPM × میانگین توکن‌های پرامپت
۲. TPM خروجی = Peak RPM × میانگین توکن‌های پاسخ
۳. TPM نرمال‌شده = (TPM ورودی × (۱ − نرخ حافظه)) + (نسبت خروجی به ورودی × TPM خروجی)
۴. PTUهای مورد نیاز = TPM نرمال‌شده ÷ Input_TPM_per_PTU (سپس گرد کردن به بالا تا نزدیک‌ترین گام مقیاس)
قدرت حافظه پرامپت
حافظه پرامپت (Prompt Caching) قدرتمندترین ابزار بهینه‌سازی موجود است. توکن‌های ذخیره‌شده کاملاً از مصرف PTU مستثنی می‌شوند. با قرار دادن پرامپت‌های سیستمی ثابت، بلوک‌های تکراری few-shot و طرح‌های ابزار (Tool schemas) ثابت در ابتدای پنجره متنی، تیم‌ها می‌توانند نیاز خود به PTU را به‌شدت کاهش دهند.
در یک مثال عملی برای استقرار مدل GPT-5.2 با ۱۰۰۰ درخواست در دقیقه (Peak RPM)، پرامپت‌های ۲۰۰ توکنی و پاسخ‌های ۲۰ توکنی:
- با نرخ حافظه ۰٪: TPM نرمال‌شده ۳۶۰,۰۰۰ است که به ۱۰۵.۸۸ واحد PTU خام نیاز دارد و به ۱۱۰ واحد PTU گرد می‌شود.
- با نرخ حافظه ۵۰٪: TPM نرمال‌شده به ۲۶۰,۰۰۰ کاهش می‌یابد که به ۷۶.۴۷ واحد PTU خام نیاز دارد و به ۸۰ واحد PTU گرد می‌شود.
این اختلاف ۳۰ واحدی، یک صرفه‌جویی ماهانه قابل توجه در هزینه است که صرفاً از طریق بازسازی ساختار پرامپت به دست می‌آید. انضباط در استفاده از حافظه پرامپت اغلب به عنوان یک مورد «خوب است اگر باشد» دیده می‌شود، اما در واقع یک اهرم حیاتی در برنامه‌ریزی ظرفیت است.
مدیریت سرریز با Spillover
برای مدیریت جهش‌های ترافیکی که از حد پیک رزروشده فراتر می‌روند، فاندری از مکانیزم سرریز (Spillover) استفاده می‌کند. بدون این قابلیت، فاندری به محض اشباع شدن استخر PTU، خطای ۴۲۹ برمی‌گرداند. با فعال بودن سرریز، درخواست‌های اضافی به‌طور خودکار به یک استقرار استاندارد (Pay-as-you-go) در همان منبع فاندری هدایت می‌شوند.
مهندسان می‌توانند این مورد را از طریق هدر x-ms-spillover-deployment کنترل کنند. این قابلیت اجازه می‌دهد تا وضعیت‌های قابلیت اطمینان متفاوتی تعریف شود. برای مثال، یک چت کاربر-محور می‌تواند سرریز شود تا تأخیر متغیر را بپذیرد، در حالی که یک پردازش دسته‌ای در پس‌زمینه می‌تواند در صف قرار گیرد تا از هزینه‌های بالاتر استقرار استاندارد اجتناب شود.
نکته حیاتی این است که سرریز در حال حاضر فقط برای مدل‌های Azure OpenAI فعال است. مدل‌های شخص ثالث مثل Meta Llama یا DeepSeek از این ویژگی پشتیبانی نمی‌کنند؛ به این معنی که تیم‌ها باید استراتژی‌های مدیریت فشار (مانند retry-with-backoff یا صف‌بندی) را در لایه اپلیکیشن خود پیاده کنند.
صورت‌حساب و رزروها
فاندری دو حالت پرداخت دارد: ساعتی و رزرو (Reservation). پرداخت ساعتی، PTUها را با نرخ ثابت $/PTU/hour محاسبه می‌کند و برای آزمایش‌های کوتاه‌مدت یا بنچ‌مارک‌ها در نظر گرفته شده است. این یک مکانیزم scale-to-zero نیست، زیرا هنگام مقیاس‌دهی مجدد به بالا، تضمینی برای موجود بودن ظرفیت وجود ندارد؛ حذف یک استقرار، ظرفیت را به‌طور دائمی به استخر مشترک برمی‌گرداند.
رزروهای Azure در مقابل، تخفیف ساعتی را در ازای تعهد یک‌ماهه یا یک‌ساله ارائه می‌دهند. با این حال، رزروها و استقرارها به‌طور سست به هم متصل هستند. خرید یک رزرو باعث ایجاد استقرار نمی‌شود و ایجاد یک استقرار لزوماً نیازمند رزرو نیست.
ترتیب درست عملیات این است: ابتدا استقرار رزروشده را ایجاد کنید تا از موجود بودن سخت‌افزار فیزیکی در منطقه هدف مطمئن شوید. تنها پس از آن باید رزرو مالی را خریداری کنید. خرید رزرو پیش از استقرار یک اشتباه رایج است که می‌تواند شما را در وضعیتی قرار دهد که تعهد مالی پرداخت کرده‌اید اما هیچ سخت‌افزاری برای مصرف آن در دسترس ندارید.
پیاده‌سازی در محیط عملیاتی
یک شرکت SaaS را در نظر بگیرید که برای ۴۰۰ کارمند در اروپا یک دستیار دسته‌بندی تیکت مستقر می‌کند. برای رعایت قوانین سخت‌گیرانه اقامت داده‌ها (Data Residency)، آن‌ها باید از Data Zone Provisioned (EU) به‌جای Global Provisioned استفاده کنند، زیرا مسیریابی بین منطقه‌ای با محدودیت‌های «فقط اروپا» ناسازگار است.
با پیک ۳۰۰ درخواست در دقیقه، پرامپت‌های ۶۰۰ توکنی (متن تیکت + قطعات پایگاه دانش) و پاسخ‌های ۱۵۰ توکنی، تیم تعداد PTUهای خود را محاسبه می‌کند. با تنظیم دستورالعمل‌های ثابت پایگاه دانش و طرح خروجی در ابتدای پرامپت، آن‌ها به نرخ حافظه ۳۵٪ دست می‌یابند.
آن‌ها جهش‌های نادر مربوط به حوادث بحرانی (P1) را از طریق سرریز در سطح هر درخواست به یک استقرار استاندارد اختصاصی هدایت می‌کنند. این کار تضمین می‌کند که جهش در یک بار کاری، به‌طور بی‌صدا تضمین تأخیر سایر بارهای کاری که از منبع مشترک استفاده می‌کنند را تخریب نکند. پس از تأیید میزان مصرف پایدار به مدت دو هفته، آن‌ها یک رزرو یک‌ساله را برای به حداقل رساندن هزینه‌ها فعال کردند.
اشتباهات رایج مهندسی
- استفاده از میانگین ترافیک: سایزینگ بر اساس میانگین RPM به‌جای پیک، منجر به شکست‌های تولیدی در طول رویدادهای پربار می‌شود.
- تخمین ایستا: استفاده مجدد از تعداد PTUها پس از ارتقای مدل خطرناک است زیرا
Input_TPM_per_PTUو نسبت خروجی به ورودی بین نسخه‌ها تغییر می‌کند. - فرض انعطاف‌پذیری: برخورد با PTUها مانند پادهای کوبرنتیز و مقیاس‌دهی شبانه، این واقعیت را نادیده می‌گیرد که ظرفیت یک استخر مشترک و رقابتی است و تضمینی برای بازگشت آن وجود ندارد.
- ترتیب رزرو: خرید تعهدات مالی پیش از تأیید موجودی سخت‌افزار فیزیکی.
- سرریز سراسری: اعمال سرریز در سطح کل منبع می‌تواند ترافیک حساس به تأخیر را به‌طور غیرمنتظره به استخرهای مشترک نشت دهد؛ به‌جای آن از هدرهای درخواستی استفاده کنید.
- محدودیت‌های شخص ثالث: فرض اینکه مدل‌های Llama یا DeepSeek دارای شبکه ایمنی ۴۲۹-به-استاندارد هستند.
چه زمانی از PTU استفاده نکنیم؟
وقتی ترافیک واقعاً غیرقابل‌پیش‌بینی یا کم است — مانند مراحل توسعه، تست یا کشف محصول در مراحل اولیه — از PTUها صرف‌نظر کنید. کف پرداخت ساعتی به این معنی است که یک استقرار رزروشده بیکار تقریباً همیشه گران‌تر از مدل پرداخت به‌ازای مصرف است. علاوه بر این، اگر نمی‌توانید تخمین مطمئنی از Peak RPM ارائه دهید، فرمول‌های سایزینگ ورودی‌های بد را تقویت می‌کنند و ریسک را از «تأخیر غیرقابل‌پیش‌بینی» به «هزینه غیرقابل‌پیش‌بینی» منتقل می‌کنند.
پردازش اولویت‌دار (Priority processing) اغلب میانه‌ای بهتر است و هدف تأخیر مشخصی را بدون نیاز به تعهد ظرفیت ارائه می‌دهد.
توصیه‌های کاربردی
- سایزینگ بر اساس پیک: فرمول سایزینگ را روی شلوغ‌ترین پنجره‌های ترافیکی اجرا کنید و پس از هر تغییر در نسخه مدل، آن را مجدداً اجرا نمایید.
- طراحی حافظه-محور: نرخ حافظه پرامپت را به عنوان یک هدف طراحی در طول توسعه در نظر بگیرید. پرامپت‌ها را به‌گونه‌ای ساختاردهی کنید که محتوای ایستا در ابتدا قرار گیرد.
- تأیید ظرفیت: همیشه موجود بودن ظرفیت را با یک استقرار واقعی پیش از خرید هرگونه رزرو تأیید کنید.
- سرریز محدودشده: از هدرهای سرریز در سطح درخواست استفاده کنید تا مطمئن شوید فقط بارهای کاری که تأخیر متغیر را تحمل می‌کنند به استقرار استاندارد هدایت می‌شوند.
- مانیتورینگ بهره‌وری: میزان استفاده از رزرو را از طریق Cost Management نظارت کنید. اگر یک رزرو به‌طور مداوم کمتر از حد مورد نیاز استفاده می‌شود، به‌جای پذیرفتن آن به عنوان هزینه غرق‌شده، سایز استقرار را اصلاح کنید.
- سایزینگ مستقل: برای منابع چند-مدلی، سایزینگ و رزرو را به‌طور مستقل برای هر بار کاری انجام دهید؛ میانگین‌گیری بین مدل‌های مختلف اعداد بی‌معنی تولید می‌کند.
توان عملیاتی رزروشده در واقع یک معامله است: شما انعطاف‌پذیری پرداخت به‌ازای مصرف را فدای قطعیت تأخیر تضمین‌شده می‌کنید. این معامله تنها زمانی سودمند است که محاسبات ریاضی زیربنایی دقیق باشد. پیش از استقرار، ریاضیات را انجام دهید، پیش از رزرو، ظرفیت را تأیید کنید و با سرریز به عنوان یک شبکه ایمنی محدودشده برخورد کنید، نه یک فرض کلی.
گفتگو