فاز 17 · درس 1

مقایسه پلتفرم‌های ابری LLM: بررسی AWS Bedrock، Vertex AI و Azure OpenAI

نوع
مفهومی
زمان
حدود 60 دقیقه
زبان‌ها
Python (stdlib, toy cost-, -latency comparator)
پیش‌نیاز
فاز 11 (مهندسی LLM)، فاز 13 (ابزارها و پروتکل‌ها)
سه مسیر ابری متفاوت که به یک مرکز داده‌ی مرکزی متصل می‌شوند، با مقیاس‌های متوازن و نمادهای تاخیر و هزینه
فهرست مطالب
  1. اهداف یادگیری
  2. صورت مسئله
  3. مفاهیم پایه
  4. سه رویکرد متفاوت
  5. شکاف تاخیر در مقیاس‌های بزرگ
  6. محاسبات اقتصادی ظرفیت رزروشده
  7. سازوکار فین‌اپس — مزیت رقابتی اصلی
  8. وابستگی به پلتفرم: ریسک اساسی در سال 2026
  9. محل استقرار داده‌ها، قراردادهای BAA و صنایع تحت نظارت
  10. اعدادی که باید به خاطر بسپارید
  11. استفاده از ابزارهای واقعی
  12. خروجی این درس
  13. تمرین‌ها
  14. اصطلاحات کلیدی
  15. برای مطالعه‌ی بیشتر

وقتی محصول هوش مصنوعی شما از مرحله‌ی آزمایشی فراتر می‌رود و نیازمند پایداری، توافق‌نامه‌های سطح خدمت (SLA) دقیق و رهگیری مالی سازمانی می‌شود، اتصال مستقیم به API خام ارائه‌دهندگان مدل دیگر پاسخگوی نیازها نخواهد بود. سه غول ابری یعنی آمازون (AWS Bedrock)، مایکروسافت (Azure OpenAI) و گوگل (Vertex AI) هر کدام استراتژی کاملاً متفاوتی برای ارائه‌ی مدل‌های زبانی در پیش گرفته‌اند و انتخاب نادرست میان آن‌ها می‌تواند به تاخیر بالا، افزایش سرسام‌آور هزینه‌ها و قفل‌شدگی روی یک فروشنده منجر شود.

برای توسعه‌دهندگان ایرانی، استفاده از این زیرساخت‌های ابری چالش‌های مضاعفی دارد. کارت‌های بانکی ایرانی برای پرداخت مستقیم به ارائه‌دهندگان خارجی قابل استفاده نیستند و شارژ اعتبار API معمولاً به راه‌های واسط نیاز دارد. علاوه بر این، محدودیت‌های دسترسی بر اساس نشانی IP در برخی از این سرویس‌ها وجود دارد؛ بنابراین معماری شما باید آمادگی تغییر مسیر خودکار (Failover) را داشته باشد.

این درس به شما کمک می‌کند تفاوت‌های عمیق فنی میان رویکرد بازارگاهی Bedrock، ظرفیت اختصاصی (PTU) در Azure و برتری چندوجهی و بافت طولانی Vertex AI را درک کنید و سیستمی مقاوم و مقرون‌به‌صرفه بسازید.

سه غول رایانش ابری (Hyperscaler)، سه رویکرد کاملاً متفاوت. سرویس AWS Bedrock یک بازارگاه مدل است؛ یعنی Claude، Llama، Titan، Stability و Cohere همگی پشت یک API واحد قرار دارند. در سوی دیگر، Azure OpenAI بر پایه‌ی شراکت انحصاری با OpenAI و ارائه‌ی واحدهای توان پردازشی رزروشده (Provisioned Throughput Units یا PTU) برای تامین ظرفیت اختصاصی بنا شده است. پلتفرم Vertex AI نیز رویکرد «اول Gemini» را در پیش گرفته و بهترین گزینه برای بافت‌های متنی طولانی (Long-context) و سناریوهای چندوجهی (Multimodal) به شمار می‌رود. در سال 2026، بررسی‌های بنچمارک Artificial Analysis نشان می‌دهد میانه‌ی تاخیر تا دریافت اولین توکن (TTFT) در Azure OpenAI روی مدل‌های معادل Llama 3.1 405B حدود 50 میلی‌ثانیه و در Bedrock حدود 75 میلی‌ثانیه است؛ دلیل این اختلاف به PTU بازمی‌گردد، چرا که ظرفیت اختصاصی همیشه از ظرفیت اشتراکی برحسب تقاضا (On-demand) بهتر و سریع‌تر عمل می‌کند. معیار تصمیم‌گیری این نیست که «کدام پلتفرم سریع‌تر است»، بلکه باید ببینید «کاتالوگ مدل‌ها و سازوکارهای فین‌اپس (FinOps) کدام سرویس با محصول شما همخوانی دارد». این درس به شما یاد می‌دهد که انتخاب خود را بر پایه‌ی مقایسه‌ی دقیق معایب و مزایا استوار کنید، نه حدس و گمان.

اهداف یادگیری

  • نام بردن از سه رویکرد اصلی این پلتفرم‌ها (بازارگاه در برابر انحصاری در برابر اول Gemini) و تطبیق هر کدام با کاربرد محصولی مناسب.
  • توضیح مزایای حاصل از خرید واحدهای توان پردازشی رزروشده (PTU) در Azure OpenAI و علت کندتر بودن حالت برحسب تقاضای Bedrock به‌میزان تقریبی 25 میلی‌ثانیه در مقیاس 405B.
  • ترسیم ساختار انتساب هزینه‌ها در حوزه‌ی فین‌اپس برای هر پلتفرم (پروفایل‌های استنتاج کاربردی در Bedrock، معماری پروژه-به‌ازای-هر-تیم در Vertex، و دامنه‌های منابع به‌همراه رزرو PTU در Azure).
  • تدوین خط‌مشی «حداقل دو ارائه‌دهنده» و تشریح این که چرا وابستگی انحصاری به یک ارائه‌دهنده (Single-vendor lock-in) در سال 2026 یک اشتباه بسیار پرهزینه است.

صورت مسئله

مدل Claude 3.7 Sonnet را برای محصول خود برگزیده‌اید و حالا نوبت به سرویس‌دهی آن رسیده است. می‌توانید مستقیماً API شرکت Anthropic را فراخوانی کنید، آن را از طریق AWS Bedrock به کار بگیرید، یا درخواست‌ها را از یک گیت‌وی (Gateway) رد کنید. اتصال مستقیم به API ساده‌ترین راه است؛ Bedrock مواردی مثل قراردادهای BAA، اندپوینت‌های VPC، سیستم IAM و تفکیک هزینه با CloudWatch را به آن اضافه می‌کند. گیت‌وی نیز قابلیت‌هایی همچون تغییر مسیر خودکار هنگام خرابی (Failover)، صدور صورت‌حساب یکپارچه و مدیریت محدودیت نرخ درخواست (Rate limit) میان ارائه‌دهنده‌های گوناگون را برایتان به ارمغان می‌آورد.

مسئله‌ی عمیق‌تر، تنوع کاتالوگ است. اگر در یک محصول به‌طور هم‌زمان به Claude و Llama و Gemini نیاز داشته باشید، نمی‌توانید همه‌ی آن‌ها را از یک مرجع واحد تهیه کنید؛ مگر این که هم‌زمان از Bedrock، Vertex و Azure OpenAI استفاده کنید. غول‌های ابری جایگزین مستقیم یکدیگر نیستند؛ هر کدام از آن‌ها روی اینکه چه شرکتی مالکیت لایه‌ی مدل را به دست خواهد گرفت، شرط‌بندی متفاوتی کرده‌اند.

در این درس به بررسی این سه شرط‌بندی، شکاف تاخیر، تفاوت‌های فین‌اپس و ریسک وابستگی به پلتفرم می‌پردازیم.

مفاهیم پایه

سه رویکرد متفاوت

AWS Bedrock — مدل بازارگاهی. شامل Claude (محصول Anthropic)، Llama (محصول Meta)، Titan (مدل اختصاصی AWS)، Stability (تولید تصویر)، Cohere (امبدینگ)، Mistral و زیرکاتالوگ‌های گوناگون تصویر و امبدینگ. یک API واحد، یک سطح دسترسی IAM، و یک خروجی یکپارچه روی CloudWatch. شرط‌بندی Bedrock روی این فرضیه است که مشتریان بیش از یک مدل خاص، خواهان حق انتخاب و انعطاف‌پذیری هستند.

Azure OpenAI — شراکت انحصاری. دسترسی به مدل‌های GPT-4 / 4o / 5 / سری o، ابزارهای DALL·E و Whisper، در کنار امکان فاین‌تیونینگ مدل‌های OpenAI در دیتاسنترهای Azure. در کاتالوگ «Azure OpenAI Service» هیچ مدلی غیر از مدل‌های OpenAI وجود ندارد و سایر مدل‌ها به سرویس Azure AI Foundry منتقل شده‌اند که محصولی جداگانه است. شرط‌بندی Azure روی این اصل استوار است که OpenAI همواره در لبه‌ی فناوری باقی می‌ماند و مشتریان خواهان ابزارهای کنترلی سازمانی روی این رابطه‌ی اختصاصی هستند.

Vertex AI — اولویت مطلق با Gemini، بقیه در اولویت بعد. ارائه‌ی نسخه‌های Gemini 1.5 / 2.0 / 2.5 در دو رده‌ی Flash و Pro، به‌همراه Model Garden برای مدل‌های متفرقه. شرط‌بندی Vertex روی پردازش چندوجهی و بافت‌های متنی عظیم متمرکز است؛ بافت متنی 1 میلیون توکنی Gemini برگ برنده و مزیت رقابتی اصلی آن به شمار می‌رود.

شکاف تاخیر در مقیاس‌های بزرگ

بنچمارک‌های مداوم Artificial Analysis نشان می‌دهند که روی مدل‌های معادل Llama 3.1 405B، میانه‌ی تاخیر تا دریافت اولین توکن (TTFT) در Azure با استفاده از PTU حدود 50 میلی‌ثانیه است؛ در حالی که همین شاخص در حالت برحسب تقاضای اشتراکی Bedrock به حدود 75 میلی‌ثانیه می‌رسد. این شکاف ناشی از ضعف زیرساخت AWS نیست، بلکه به تفاوت در مدل ظرفیت بازمی‌گردد. Azure با فروش PTU (واحدهای توان پردازشی رزروشده) ظرفیت پردازنده‌های گرافیکی را به‌طور اختصاصی برای سازمان شما رزرو می‌کند. سرویس Bedrock هم قابلیت مشابهی به نام ظرفیت رزروشده (Provisioned Throughput) دارد، اما هزینه‌ی آن از حدود 21 دلار در ساعت به‌ازای هر واحد شروع می‌شود و به همین دلیل بیشتر مشتریان از همان ظرفیت اشتراکی برحسب تقاضا استفاده می‌کنند.

در ظرفیت اشتراکی برحسب تقاضا، ترافیک شما با ترافیک تمام مشتریان دیگر رقابت می‌کند؛ در حالی که در ظرفیت اختصاصی چنین رقابتی وجود ندارد. اگر توافق‌نامه‌ی سطح خدمت (SLA) محصول شما الزام می‌کند که صدک نود و نهم (P99) تاخیر تا اولین توکن زیر 100 میلی‌ثانیه باشد، یا باید در Azure واحد PTU بخرید، یا در Bedrock به سراغ Provisioned Throughput بروید، یا نوسان‌های پیش‌فرض را به عنوان بخشی از واقعیت سیستم بپذیرید.

محاسبات اقتصادی ظرفیت رزروشده

واحدهای PTU در Azure: یک بلوک رزروشده از توان محاسباتی استنتاج. این واحدها در بارهای کاری قابل پیش‌بینی، تا حدود 70 درصد صرفه‌جویی مالی در مقایسه با حالت برحسب تقاضا به همراه دارند. هزینه‌ی آن‌ها ساعتی و ثابت است و فرقی نمی‌کند چقدر ترافیک روانه‌ی سیستم شود؛ یعنی حتی در زمان بیکاری سرور نیز پول ظرفیت رزروشده را پرداخت می‌کنید. نقطه‌ی سر‌به‌سر معمولاً در استفاده‌ی مداوم 40 تا 60 درصدی رخ می‌دهد.

سرویس Provisioned Throughput در Bedrock: هزینه‌ای بین 21 تا 50 دلار در ساعت، بسته به مدل انتخابی و منطقه‌ی جغرافیایی. فرمول اقتصادی آن نیز مشابه است و نقطه‌ی سر‌به‌سر در حدود نیمی از اوج مصرف به دست می‌آید. این سرویس به تعهد قرارداد ماهانه نیاز دارد.

ظرفیت رزروشده در Vertex به‌ازای هر واحد محصول (SKU) در مدل‌های Gemini فروخته می‌شود؛ قیمت‌گذاری آن به مدل و منطقه وابسته است و اطلاعات کمتری از جزئیات آن به‌صورت عمومی در دسترس قرار دارد.

سازوکار فین‌اپس — مزیت رقابتی اصلی

پروفایل‌های استنتاج کاربردی در Bedrock (Application Inference Profiles) شفاف‌ترین سیستم تفکیک و انتساب هزینه را در میان این گزینه‌ها دارند. می‌توانید یک پروفایل را با برچسب‌های team، product و feature نشانه‌گذاری کنید و تمام فراخوانی‌های مدل را از مسیر آن هدایت کنید؛ در این صورت سرویس CloudWatch هزینه‌ها را بدون نیاز به هیچ‌گونه پردازش ثانویه به‌تفکیک هر پروفایل مشخص می‌کند. این قابلیت در سال 2025 افزوده شد و هنوز هم دقیق‌ترین راهکار بومی در میان سرویس‌های ابری است.

سیستم انتساب هزینه در Vertex بر پایه‌ی مدل «یک پروژه به‌ازای هر تیم» به‌همراه برچسب‌گذاری سراسری کار می‌کند. شما هر تیم را در قالب یک پروژه‌ی GCP تعریف می‌کنید، روی تک‌تک منابع برچسب می‌زنید و برای تجمیع داده‌ها از قابلیت خروجی صورت‌حساب به BigQuery (BigQuery Billing Export) و سپس DataStudio کمک می‌گیرید. این فرایند زحمت راه‌اندازی بیشتری دارد، اما BigQuery دست شما را برای نوشتن هر نوع کوئری SQL روی داده‌های هزینه باز می‌گذارد.

Azure بر دامنه‌های اشتراک (Subscription) و گروه‌های منابع (Resource Group) در کنار برچسب‌ها متکی است و در این میان، رزروهای PTU ماهیت مالی مستقلی دارند. برچسب‌ها از گروه‌های منابع به ارث می‌رسند و ربطی به درخواست‌های مجزا ندارند؛ بنابراین برای رهگیری هزینه به‌ازای هر درخواست، ناچارید از سنجه‌های سفارشی Application Insights یا گیت‌وی‌هایی استفاده کنید که روی هدرها نشان می‌زنند.

به‌طور کلی: Bedrock تمیزترین ساختار بومی را دارد، Vertex با اتکا به BigQuery بیشترین انعطاف را ارائه می‌دهد، و Azure در نبود سازوکارهای سنجش اختصاصی، از بقیه مبهم‌تر است.

وابستگی به پلتفرم: ریسک اساسی در سال 2026

وقتی یک مدل به بازار تسلط داشت، متعهد ماندن به یک سرویس ابری خاص منطقی به نظر می‌رسید. در سال 2026، مرزهای فناوری به‌صورت ماهانه جابه‌جا می‌شوند؛ یک فصل نوبت به Claude 3.7 می‌رسد، فصل بعد به Gemini 2.5، و سه ماه بعد GPT-5 از راه می‌رسد. تعهد انحصاری به یک پلتفرم به معنای از دست دادن دسترسی به دو‌سوم پیشرفت‌های حوزه‌ی هوش مصنوعی است.

الگویی که تیم‌های کاربلد به کار می‌گیرند، رعایت «حداقل دو ارائه‌دهنده» برای هر گونه فراخوانی حیاتی مدل‌های زبانی است. ترکیب Bedrock و Azure OpenAI رایج‌ترین الگو است؛ استفاده از Claude روی یکی و مدل‌های GPT روی دیگری، با قابلیت تغییر مسیر خودکار بین دو سیستم پشت یک گیت‌وی مشترک. افزایش هزینه‌ی ناشی از این معماری به دلیل مسیریابی بهینه‌ی گیت‌وی بسیار ناچیز است؛ اما افزایش میزان دردسترس‌بودن سیستم هنگام قطعی‌های بزرگ (مثل اختلالات ژانویه 2025 در Azure OpenAI یا قطعی‌های us-east-1 در AWS) تفاوت میان ادامه‌ی کار یا توقف کل محصول را رقم می‌زند.

محل استقرار داده‌ها، قراردادهای BAA و صنایع تحت نظارت

سرویس Bedrock: امکان انعقاد قرارداد BAA در اکثر مناطق؛ اندپوینت‌های VPC؛ و گاردریل‌ها (سازوکارهای ایمنی). این پلتفرم گزینه‌ی پیش‌فرض و رایج در صنعت فین‌تک است. سرویس Azure OpenAI: تاییدیه‌های HIPAA، SOC 2، ISO 27001؛ امکان تعیین محل ذخیره‌سازی داده‌ها در اتحادیه اروپا؛ گزینه‌ی پیش‌فرض در سازمان‌های سنتی و به‌شدت تحت نظارت. سرویس Vertex: تاییدیه‌های HIPAA، GDPR، سازگاری با محل اقامت داده‌ها به‌تفکیک منطقه؛ تکیه بر بسته‌ی انطباق استاندارد Google Cloud.

هر سه پلتفرم استانداردهای پایه و الزامات حقوقی را برآورده می‌کنند. تفاوت اصلی در سیاست‌های نگهداری داده‌ها (Data retention)، شیوه‌ی ثبت لاگ‌ها، و فعال بودن سامانه‌های پایش سوءاستفاده (Abuse-monitoring) روی ترافیک ورودی نهفته است (این سامانه در بیشتر پلتفرم‌ها به‌صورت پیش‌فرض روی ترافیک نظارت می‌کند، هرچند سازمان‌های بزرگ امکان غیرفعال‌سازی آن را دارند).

اعدادی که باید به خاطر بسپارید

  • میانه‌ی TTFT در Azure OpenAI روی مدل‌های معادل Llama 3.1 405B: حدود 50 میلی‌ثانیه (با استفاده از PTU).
  • میانه‌ی TTFT در حالت برحسب تقاضای Bedrock: حدود 75 میلی‌ثانیه.
  • هزینه‌ی Provisioned Throughput در Bedrock: بین 21 تا 50 دلار در ساعت برای هر واحد.
  • نقطه‌ی سر‌به‌سر خرید PTU در Azure: حدود 40 تا 60 درصد استفاده‌ی مداوم.
  • میزان صرفه‌جویی با PTU در برابر حالت برحسب تقاضا در بارهای کاری بالا: تا سقف 70 درصد.
خطوط پلتفرمظرفیت رزروشده PTU در مقابل اشتراکی on-demand
PLATFORM LANESThe hyperscaler latency gap is a capacity story, not a model story. Azure PTUs reserve throughput, so requests ride a dedicated lane at ~50 ms median. Bedrock on-demand shares a pool with every other tenant, and the same-scale model reads ~75 ms because your tokens queue behind theirs. Pick the platform for its catalog and FinOps surface, then decide which workloads deserve the reserved lane.خط رزروشده PTUاختصاصیمیانه ~50 msخط اشتراکی on-demandاستخر اشتراکیمیانه ~75 msدر صف پشت سر دیگرانمدل یکسان، قرارداد ظرفیت متفاوت: رزروشده حدود 25 ms سریع‌تر است
شکاف تاخیر بین ابرمقیاس‌پذیرها مسئله ظرفیت است نه مدل. واحدهای PTU در Azure نرخ پردازش را رزرو می‌کنند؛ بنابراین درخواست‌ها از خطی اختصاصی با میانه تاخیر حدود 50 میلی‌ثانیه عبور می‌کنند. سرویس on-demand در Bedrock استخری مشترک با سایر کاربران دارد و مدل هم‌اندازه تاخیری حدود 75 میلی‌ثانیه ثبت می‌کند، چون توکن‌های شما در صف پشت سر دیگران می‌مانند. پلتفرم را بر اساس کاتالوگ و امکانات FinOps انتخاب کنید، سپس تصمیم بگیرید کدام بار‌های کاری مستحق خط رزروشده هستند.

استفاده از ابزارهای واقعی

فایل code/main.py این سه پلتفرم را در مواجهه با یک بار کاری شبیه‌سازی‌شده مقایسه می‌کند؛ این اسکریپت مدل اقتصادی برحسب تقاضا در برابر PTU، میزان نوسان TTFT، و دقت تفکیک هزینه‌ها را می‌سنجد. با اجرای آن می‌توانید متوجه شوید که رزرو PTU در چه سناریوهایی صرفه‌ی اقتصادی دارد و در چه شرایطی تنوع کاتالوگ یک بازارگاه ارزش تحمل تاخیر بیشتر را خواهد داشت.

خروجی این درس

حاصل این درس یک فایل راهنما به آدرس outputs/skill-managed-platform-picker.md است. این راهنما با دریافت مشخصات بار کاری (مدل‌های مورد نیاز، SLA برای تاخیر TTFT، حجم روزانه، و الزامات انطباق و رگولاتوری)، پلتفرم اصلی، طرح پشتیبان (Fallback)، و برنامه‌ی پیاده‌سازی سازوکارهای سنجش فین‌اپس را به شما پیشنهاد می‌دهد.

تمرین‌ها

  1. اسکریپت code/main.py را اجرا کنید. در یک مدل رده‌ی 70B، خرید PTU در Azure با چه درصدی از استفاده‌ی مداوم ارزان‌تر از حالت برحسب تقاضا تمام می‌شود؟ نقطه‌ی سر‌به‌سر را محاسبه کنید و ببینید آیا با بازه‌ی اعلام‌شده‌ی 40 تا 60 درصد همخوانی دارد یا خیر.
  2. فرض کنید محصول شما به‌طور هم‌زمان به Claude 3.7 Sonnet و GPT-4o نیاز دارد. یک معماری با دو ارائه‌دهنده طراحی کنید؛ هر مدل روی کدام سرویس ابری مستقر شود؟ چه گیت‌وی‌ای پیش روی آن‌ها قرار گیرد؟ و سیاست تغییر مسیر خودکار هنگام خرابی (Failover) به چه شکلی باشد؟
  3. یک مشتری در حوزه‌ی تحت نظارت مراقبت‌های بهداشتی، نیازمند قرارداد BAA، استقرار داده‌ها در منطقه‌ی شرق آمریکا (US-East)، و تاخیر TTFT زیر 100 میلی‌ثانیه‌ای در صدک 99 (P99) است. یک پلتفرم را برای او انتخاب کنید و این تصمیم را بر اساس سه ویژگی فنی و مشخص توجیه کنید.
  4. متوجه می‌شوید که صورت‌حساب Bedrock شما در این ماه 4 برابر افزایش یافته، بدون آنکه ترافیک مصرفی فرقی کرده باشد. اگر از Application Inference Profiles استفاده نکرده باشید، چطور منشأ این جهش هزینه را شناسایی می‌کنید؟ استفاده از این پروفایل‌ها فرایند عیب‌یابی را چقدر کوتاه‌تر می‌کند؟
  5. صفحه‌ی قیمت‌گذاری APIهای Anthropic و Bedrock را مطالعه کنید. برای یک بار کاری با حجم 100 میلیون توکن در ماه با مدل Claude، کدام گزینه مقرون‌به‌صرفه‌تر است: استفاده‌ی مستقیم از API شرکت Anthropic، حالت برحسب تقاضای Bedrock، یا حالت Provisioned Throughput در Bedrock؟

اصطلاحات کلیدی

اصطلاح معنای رایج در گفتگوها تعریف فنی و واقعی
Bedrock «سرویس LLM شرکت آمازون» بازارگاهی برای دسترسی به مدل‌های Claude، Llama، Titan، Mistral و Cohere
Azure OpenAI «نسخه‌ی مایکروسافت از ChatGPT» دسترسی انحصاری به مدل‌های OpenAI در دیتاسنترهای Azure با ابزارهای کنترلی سازمانی
Vertex AI «پلتفرم LLM شرکت گوگل» پلتفرمی مبتنی بر اولویت با Gemini به‌همراه بخش Model Garden برای مدل‌های متفرقه
PTU «ظرفیت محاسباتی اختصاصی» واحد توان پردازشی رزروشده (Provisioned Throughput Unit) — پردازنده‌های گرافیکی استنتاج رزروشده با پرداخت ساعتی
Application Inference Profile «سیستم برچسب‌گذاری در Bedrock» پروفایل ردگیری مصرف و هزینه به‌ازای هر محصول به‌همراه برچسب‌گذاری بومی با CloudWatch
Model Garden «کاتالوگ مدل‌های Vertex» بخش ارائه‌ی مدل‌های متفرقه و متن‌باز در Vertex AI، مستقل از مدل‌های اصلی Gemini
Two-provider minimum «افزونگی برای مدل‌های زبانی» سیاست عملیاتی برای میزبانی مسیرهای حیاتی پردازش روی حداقل دو غول رایانش ابری
BAA «فرم‌های اداری مربوط به HIPAA» توافق‌نامه‌ی همکاری تجاری (Business Associate Agreement) برای کار با داده‌های حوزه‌ی سلامت، ارائه‌شده توسط هر سه شرکت
Abuse monitoring «ناظر لاگ‌ها» پایش امنیتی پرامپت‌ها و خروجی‌ها در لایه‌ی ارائه‌دهنده با هدف کنترل ایمنی؛ امکان لغو عضویت در طرح‌های سازمانی

برای مطالعه‌ی بیشتر

خودآزمایی

به سؤال‌ها جواب بدهید تا ببینید چقدر از درس در ذهنتان مانده است.

  1. پیش از درسپیش از این درس، اگر مشتری نیاز به دسترسی به Claude ،Llama و Cohere پشت یک API داشت، ابتدا سراغ کدام پلتفرم می‌رفتید؟
  2. پیش از درسرویکرد استراتژیک کدام ابرمقیاس‌پذیر به جای بازارچه، شراکت انحصاری توصیف شده است؟
  3. حین درساختلاف میانگین TTFT اندازه‌گیری‌شده بین Azure OpenAI (با PTU) و Bedrock on-demand روی مدل‌های معادل Llama 3.1 405B تقریباً چقدر است؟
  4. حین درسکدام ویژگی سال 2025 در Bedrock شفاف‌ترین انتساب هزینه به ازای هر محصول را به‌طور نیتیو در CloudWatch فراهم می‌کند؟
  5. حین درسهزینه‌های Azure PTU معمولاً در چه بازه‌ای از استفاده مداوم با مدل on-demand سر‌به‌سر می‌شود؟
  6. پس از درسچرا سیاست پیشنهادی این درس برای سال 2026 حداقل استفاده از دو ارائه‌دهنده برای فراخوانی‌های حیاتی LLM است؟
  7. پس از درسکدام عبارت سطح خدمات FinOps را در بین این سه پلتفرم بهتر توصیف می‌کند؟

سؤالات متداول

واحد توان پردازشی رزروشده (PTU) در Azure چیست و چه مزیتی دارد؟

واحدهای PTU بلوک‌های رزروشده از توان محاسباتی GPU برای سازمان شما هستند که بر خلاف ظرفیت اشتراکی برحسب تقاضا، تاخیر پایدارتر (حدود 50 میلی‌ثانیه برای TTFT) و تا 70 درصد صرفه‌جویی در بارهای کاری پایدار فراهم می‌کنند.

چرا وابستگی انحصاری به یک ارائه‌دهنده ابری در سال 2026 اشتباه است؟

مرزهای فناوری مدل‌های زبانی دائماً میان شرکت‌ها دست‌به‌دست می‌شود. اتکا به یک ارائه‌دهنده شما را از دسترسی به مدل‌های پیشرو دیگر محروم کرده و در زمان بروز اختلال در آن سرویس ابری، محصول شما را کاملاً متوقف می‌کند.

کدام پلتفرم ابری شفاف‌ترین ابزار تفکیک هزینه (FinOps) را دارد؟

سرویس AWS Bedrock به کمک Application Inference Profiles امکان برچسب‌گذاری دقیق تیم، محصول و ویژگی را بدون نیاز به پردازش ثانویه به‌طور بومی در CloudWatch ارائه می‌دهد.

ما رو توی گوگل بیشتر ببین

با افزودن نکست ادمین به «منابع ترجیحی» گوگل، درس‌ها و مطالب ما را در بخش اخبار برتر جستجو بیشتر می‌بینید.