از یک کاربر تا سرویس سازمانی؛ چه زمانی مدل، تعداد نسخه‌ها یا GPU را تغییر دهیم؟

یک دستیار سازمانی معمولاً با یک آزمایش امیدوارکننده شروع می‌شود: مدل روی یک GPU اجرا شده، چند سند را خوانده و به پرسش‌های تیم پاسخ داده است. مسئله وقتی عوض می‌شود که همکاران بیشتری به سرویس وصل می‌شوند، طول گفت‌وگوها افزایش پیدا می‌کند و دیگر نمی‌توان هنگام به‌روزرسانی سرور، دستیار را برای مدتی از دسترس خارج کرد. در این مرحله، خرید یک کارت گران‌تر وسوسه‌انگیز است؛ اما صف طولانی، پاسخ نادرست، کمبود حافظه و قطع‌شدن سرویس چهار مسئلهٔ متفاوت‌اند و الزاماً با یک خرید حل نمی‌شوند.

برای رشد این سرویس، سه انتخاب جداگانه داریم: تغییر مدل، افزایش تعداد نمونه‌های اجرا و تغییر سخت‌افزار هر نمونه. یک مدل کوچک‌تر که کیفیت لازم را تأمین می‌کند، ممکن است روی چند سرور متعارف به کاربران بیشتری خدمت بدهد و امکان نگهداری بدون توقف را هم فراهم کند. در مقابل، بعضی درخواست‌ها واقعاً به مدل توانمندتر، حافظهٔ بیشتر یا ارتباط سریع میان GPUها نیاز دارند. انتخاب اقتصادی از تشخیص این مرز به دست می‌آید؛ سپس می‌توان ظرفیت پایه را خرید یا اجاره کرد و برای بخش متغیر تقاضا از ابر با پرداخت به‌اندازهٔ مصرف استفاده کرد.

سازمانی‌بودن با تعداد کارکنان اندازه‌گیری نمی‌شود

اینکه سازمانی هزار کارمند دارد، نمی‌گوید چند GPU لازم دارد. ممکن است بیشتر کارکنان روزی چند پرسش کوتاه بپرسند؛ در سازمانی کوچک‌تر، یک عامل برنامه‌نویسی یا فرایند تحلیل اسناد می‌تواند پیوسته چندین بار مدل را فراخوانی کند. حتی «کاربر هم‌زمان» هم کافی نیست: کاربری که مشغول خواندن پاسخ است با درخواستی که همین حالا در حال تولید خروجی است، مصرف یکسانی ندارد. برای ظرفیت‌سنجی باید نرخ ورود درخواست، طول ورودی و خروجی و تعداد فراخوانی‌های مدل برای انجام هر کار را شناخت.

پیش از انتخاب سخت‌افزار، یک تعریف قابل‌آزمون از خدمت بنویسید. برای یک چت‌بات، زمان شروع پاسخ و پیوستگی نمایش متن اهمیت دارد؛ برای استخراج شبانهٔ اطلاعات، تعداد اسناد درست پردازش‌شده تا ابتدای روز مهم‌تر است. هدف سطح خدمت یا SLO همین انتظار را قابل‌اندازه‌گیری می‌کند. مثلاً «در شرایط بار مشخص، ۹۵ درصد درخواست‌های تعاملی حداکثر ظرف دو ثانیه شروع به پاسخ کنند» یک هدف فرضی قابل‌آزمون است؛ «سرویس سریع باشد» مبنای خرید نیست. این عدد نمونهٔ تعریف هدف است و توصیهٔ عمومی برای همهٔ کاربردها محسوب نمی‌شود.

این اندازه‌گیری‌ها به تجهیزات اختصاصی آزمایشگاه نیاز ندارند. موتورهایی مانند vLLM معیارهای صف، تأخیر، توکن‌های ورودی و خروجی و مصرف KV cache را منتشر می‌کنند؛ مشاهدهٔ آن‌ها در کنار زمان‌سنجی کل برنامه، نقطهٔ شروع مناسبی است. نام و دسترس‌پذیری معیارها را باید با نسخهٔ نصب‌شده تطبیق داد.

پیش از خرید، باید مشخص کنید انتظار در کدام بخش اتفاق می‌افتد

در یک دستیار اسناد، کاربر فقط منتظر مدل زبانی نیست. دریافت درخواست، کنترل دسترسی، جست‌وجو، بازرتبه‌بندی نتایج، ساخت ورودی و تولید پاسخ همگی زمان می‌گیرند. اگر جست‌وجوی پایگاه داده کند شده یا هر پرسش ده‌ها سند نامرتبط وارد کانتکست می‌کند، افزودن GPU به مدل زبانی ممکن است اثر کمی داشته باشد. زمان هر مرحله را جدا ثبت کنید تا هزینهٔ حل یک گلوگاه، صرف تقویت بخش دیگری نشود.

در خود تولید متن هم دو مرحله وجود دارد: پردازش ورودی یا prefill و تولید تدریجی پاسخ یا decode. ورودی بلند معمولاً فشار بیشتری بر مرحلهٔ اول می‌آورد؛ خروجی بلند مدت بیشتری مرحلهٔ دوم را درگیر نگه می‌دارد. بنابراین دو درخواست با تعداد توکن کل مشابه نیز الزاماً رفتار یکسانی ندارند. کوتاه‌کردن ورودی‌های اضافی، انتخاب اسناد مرتبط‌تر و تعیین طول خروجی متناسب با کار می‌تواند ظرفیت آزاد کند، به شرط آنکه اطلاعات لازم یا کیفیت پاسخ قربانی نشود.

تنظیم موتور اجرا نیز مهم است. در continuous batching، زمان‌بندی در طول فرایند تولید انجام می‌شود و لازم نیست برای ورود کار جدید همیشه منتظر پایان همهٔ درخواست‌های یک دسته ماند؛ پژوهش Orca از مراجع اصلی این رویکرد است. اما افزایش اندازهٔ دسته، خودبه‌خود به معنای تجربهٔ بهتر برای همه نیست: باید افزایش خروجی کل را در کنار تأخیر درخواست‌های تعاملی سنجید. امکانات و سازگاری موتور اجرا با مدل و قالب وزن نیز در جدول نرم‌افزارهای سرویس‌دهی قابل پیگیری است.

کش‌کردن هم باید به مسئلهٔ درست پاسخ بدهد. برای ورودی‌هایی که پیشوند یکسان دارند، prefix caching می‌تواند محاسبات قبلی آن پیشوند را دوباره استفاده کند؛ در پیاده‌سازی توضیح‌داده‌شده در مستندات vLLM، صرفه‌جویی اصلی در پردازش ورودی است و نباید آن را شتاب عمومی تولید توکن‌های تازه دانست. همچنین این روش با ذخیره‌کردن و تحویل دوبارهٔ یک پاسخ نهایی تفاوت دارد. هرکدام از این کش‌ها باید با شیوهٔ جداسازی داده و دسترسی کاربران سازگار باشد.

مدل را وقتی تغییر دهید که مسئلهٔ کار تغییر کرده است

اگر پاسخ‌ها در آزمون تک‌کاربره درست‌اند و فقط در زمان شلوغی دیر می‌رسند، بزرگ‌ترکردن مدل انتخاب بدیهی نیست. مدل بزرگ‌تر ممکن است حافظه و زمان بیشتری بخواهد و فشار موجود را افزایش دهد. در این وضعیت، ابتدا تنظیم اجرا، تقسیم بار و تعداد نمونه‌ها بررسی می‌شود؛ تغییر مدل زمانی موضوعیت پیدا می‌کند که کیفیت، نوع ورودی، طول زمینه یا ماهیت استدلال موردنیاز با مدل فعلی سازگار نباشد.

برای دسته‌بندی تیکت، استخراج فیلدهای مشخص، بازنویسی محدود یا پاسخ‌گویی مستند در دامنه‌ای روشن، مدل تخصصی یا یک مدل کوچک می‌تواند نامزد اول آزمون باشد. مثلاً بررسی یک مدل ۲ تا ۴ میلیاردپارامتری برای کار محدود، یا مدلی در حدود ۸ میلیارد پارامتر برای یک دستیار اسناد، نقطهٔ شروع قابل‌دفاعی است؛ این اندازه‌ها تضمین کیفیت نیستند. تحلیل چند سند متعارض، حل مسئلهٔ چندمرحله‌ای و اجرای مستقل وظایف پیچیده به بررسی سخت‌گیرانه‌تری نیاز دارد. روش این انتخاب در برای هر کاربرد واقعاً چه اندازه مدلی لازم داریم؟ و انتخاب مدل زبانی، embedding و reranker برای اسناد سازمانی توضیح داده شده است.

مزیت مدل کوچک فقط کاهش هزینهٔ یک پاسخ نیست. وقتی هر نمونه روی یک GPU متعارف جا می‌شود، افزودن ظرفیت و ساخت مسیر جایگزین ساده‌تر می‌شود؛ در عین حال، باید برای کانتکست واقعی و درخواست‌های هم‌زمان هم حافظه باقی بماند. بخشی از این حافظه به KV cache اختصاص دارد: داده‌های میانی مربوط به توکن‌های قبلی که برای ادامهٔ تولید نگه داشته می‌شوند. «وزن مدل بارگذاری شد» با «سرویس در بار هدف پایدار است» تفاوت دارد. کوچک‌کردن وزن‌ها با کوانتیزاسیون نیز لزوماً همهٔ اجزای حافظه را به همان نسبت کوچک نمی‌کند؛ این موضوع در چهاربیتی‌کردن مدل چه چیزی را ارزان می‌کند و چه چیزی را تغییر می‌دهد؟ بررسی شده است.

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

افزایش تعداد نمونه با تقسیم یک مدل روی چند GPU فرق دارد

منظور از «نمونه» یا replica در این مقاله، یک اجرای کامل و مستقل از مدل است که می‌تواند درخواست بپذیرد؛ افزایش تعداد نمونه‌ها با انتشار نسخهٔ جدید وزن مدل تفاوت دارد. اگر چهار GPU هرکدام یک نمونهٔ کامل اجرا کنند، چهار واحد خدمت‌رسانی داریم. اگر همان چهار GPU برای نگه‌داشتن و محاسبهٔ یک مدل تقسیم‌شده لازم باشند، ممکن است تنها یک واحد خدمت‌رسانی داشته باشیم. این تمایز هم ظرفیت‌سنجی و هم طراحی دسترس‌پذیری را تغییر می‌دهد.

در راهنمای vLLM نیز اجرای چند GPU برای یک نمونه، از مقیاس‌دادن تعداد نمونه‌ها جدا شده است. اگر مدل در یک GPU جا شود، اجرای توزیع‌شده الزام اولیه نیست؛ اگر جا نشود، روش‌هایی مانند tensor parallelism یا pipeline parallelism مطرح می‌شوند. نام‌هایی مانند data parallel نیز در معماری‌های پیچیده ممکن است به گروه‌های توزیع‌شدهٔ مرتبط اشاره کنند؛ برای ادعای استقلال، باید وابستگی واقعی فرایندها و GPUها را بررسی کرد.

درخواست‌های مستقل معمولاً به همان نوع ارتباط پیوسته‌ای نیاز ندارند که GPUهای مشارکت‌کننده در یک نمونه لازم دارند؛ بنابراین می‌توان آن‌ها را روی میزبان‌های جدا با توازن بار توزیع کرد. البته انتقال ورودی، دسترسی به اسناد و هماهنگی برنامه همچنان شبکه مصرف می‌کند. در سمت دیگر، تقسیم مدل می‌تواند به پهنای باند و تأخیر ارتباط میان GPUها حساس باشد. این یکی از دلایلی است که نتیجهٔ اقتصادی یک کلاستر آموزش را نباید مستقیماً به سرویس استنتاج با درخواست‌های مستقل تعمیم داد.

یک مثال: چهار GPU چه زمانی واقعاً بهتر از سه GPU هستند؟

فرض کنید یک نمونه از مدل انتخاب‌شده، با ترکیب مشخصی از پرسش‌ها و طول پاسخ‌ها، در آزمون بار شما ۴۰ درخواست در دقیقه را در محدودهٔ کیفیت و تأخیر مطلوب پاسخ می‌دهد. این عدد صرفاً برای محاسبهٔ مثال است و به RTX 4090 یا هیچ مدل مشخصی نسبت داده نمی‌شود. فرض دوم این است که اوج تقاضا ۹۰ درخواست در دقیقه است، هر نمونه روی یک میزبان مستقل قرار دارد و اجزای مشترک سامانه گلوگاه نیستند. ظرفیت ۴۰ را نیز ظرفیت عملیاتیِ انتخاب‌شده در نظر می‌گیریم، نه سقفی که در آن صف رو به رشد است.

سه نمونه از نظر مجموع ظرفیت سالم کافی به نظر می‌رسند؛ نمونهٔ چهارم امکان حفظ ظرفیت هنگام خروج یک میزبان را فراهم می‌کند. محاسبهٔ ابتدایی برای نمونه‌های هم‌ظرفیت، گردکردن نسبت بار هدف به ظرفیت هر نمونه به بالا است؛ برای تحمل خروج یک نمونه، یک واحد دیگر به آن اضافه می‌شود. این محاسبه جای آزمون کل سامانه را نمی‌گیرد: نامتوازنی بار، کوچک‌شدن دسته‌های پردازش هنگام تقسیم درخواست‌ها، کش سرد پس از جابه‌جایی و موج درخواست‌های تکراری می‌توانند ظرفیت واقعی را تغییر دهند. بنابراین ظرفیت کل اندازه‌گیری‌شده الزاماً مضرب دقیقی از نتیجهٔ تک‌نمونه نیست.

اکنون همان چهار GPU را دو‌به‌دو در دو سرور بگذارید. با خرابی یکی از سرورها، دو نمونه از دست می‌روند و ظرفیت باقی‌مانده به ۸۰ می‌رسد؛ هدف مثال تأمین نمی‌شود. با همین فرض‌ها، سه سرورِ دو‌نمونه‌ای پس از خروج یک سرور چهار نمونه نگه می‌دارند. پس تعداد کارت به‌تنهایی معیار تحمل خرابی نیست: باید محاسبه را برای بزرگ‌ترین مجموعه‌ای که با یک خرابی موردنظر از دست می‌رود انجام داد. اگر هدف تحمل قطع یک ناحیهٔ ابری است، ظرفیت باقی‌مانده بیرون از آن ناحیه باید کفایت کند.

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

دو نمونهٔ مدل وقتی مفیدند که درخواست به نمونهٔ سالم برسد و وابستگی‌های آن نیز کار کنند. توازن‌دهندهٔ بار، پایگاه دادهٔ گفت‌وگو، سامانهٔ بازیابی اسناد، احراز هویت و مسیر شبکه می‌توانند نقطهٔ خرابی مشترک باشند. تاریخچهٔ لازم برای ادامهٔ گفت‌وگو را در لایه‌ای پایدار و قابل‌دسترسی برای نمونه‌های جایگزین نگه دارید؛ اتکا به حافظهٔ محلی یک فرایند، جابه‌جایی را شکننده می‌کند. وجود نسخهٔ دوم مدل، به‌تنهایی درصد مشخصی از دسترس‌پذیری را تضمین نمی‌کند.

در تجربهٔ دو سرور مستقل ترگمان، هر سرور یک RTX 4090 داشت و در حالت عادی هر دو فعال بودند. هنگام بارگذاری مجدد مدل روی یکی از آن‌ها، سرور دیگر هر سه خدمت را ادامه داد، اما انتظار بیشتر و لغو بخشی از درخواست‌ها را هم داشتیم. ارزش نمونهٔ دوم در عمل روشن شد؛ در عین حال، ادامهٔ دسترسی به سامانه با حفظ همان کیفیت خدمت در زمان خروج یک سرور یکسان نبود. برای ظرفیت پس از خرابی باید جداگانه بودجه گذاشت.

توزیع نمونه‌ها باید با خرابی موردانتظار هماهنگ باشد. Kubernetes برای پخش‌کردن نمونه‌ها میان میزبان‌ها یا ناحیه‌ها، topology spread constraints دارد؛ این قابلیت به اجرای سیاست استقرار کمک می‌کند. PodDisruptionBudget هم برای محدودکردن اختلال‌های داوطلبانه، مانند بخشی از عملیات نگهداری، مفید است؛ اما جلوی خرابی ناگهانی میزبان را نمی‌گیرد. این ابزارها زمانی نتیجه می‌دهند که ظرفیت، دامنه‌های خرابی و رفتار برنامه نیز درست طراحی شده باشند.

برای نگهداری روزمره، نمونهٔ تازه باید مدل را بارگذاری کند و آمادهٔ پاسخ‌گویی شود؛ سپس ترافیک بگیرد و نمونهٔ قبلی با فرصت مناسب برای پایان درخواست‌های جاری خارج شود. در خرابی ناگهانی، پاسخ در حال تولید ممکن است قطع شود و کاربر به تلاش دوباره نیاز پیدا کند. در عامل‌هایی که عملیات بیرونی انجام می‌دهند، تلاش دوباره نباید یک پرداخت، ثبت سند یا تغییر را دوباره اجرا کند؛ شناسهٔ عملیات و کنترل تکرار باید در خود برنامه پیش‌بینی شود. دسترس‌پذیری مسیر پذیرش درخواست، با ادامهٔ بی‌وقفهٔ هر پاسخ در حال تولید یکسان نیست.

چه زمانی GPU بزرگ‌تر واقعاً توجیه دارد؟

اگر مدل مناسب روی یک کارت متعارف، با کانتکست و بار هدف، کیفیت و تأخیر لازم را تأمین کند، افزودن نمونه‌های مستقل گزینه‌ای جدی است. برای مقایسهٔ مشخصات، RTX 4090 استاندارد ۲۴ گیگابایت حافظه دارد و از NVLink پشتیبانی نمی‌کند؛ H200 دارای ۱۴۱ گیگابایت HBM3e با پهنای باند اعلامی ۴٫۸ ترابایت‌برثانیه است. این اختلاف حافظه واقعی و مهم است، اما مشخصات اسمی به‌تنهایی نمی‌گویند کدام چیدمان برای سرویس شما هزینهٔ کمتری دارد.

GPU بزرگ‌تر زمانی ارزش بیشتری پیدا می‌کند که مدل ضروری در حافظهٔ گزینهٔ کوچک‌تر جا نشود، کانتکست و KV cache ظرفیت آن را محدود کنند، یا تأخیر تک‌درخواست با افزودن نمونه‌ها حل نشود. ممکن است یک GPU حرفه‌ای بتواند همان بار را با مصرف انرژی، فضای رک یا هزینهٔ عملیاتی کمتری از چند کارت کوچک پاسخ دهد. در چنین مقایسه‌ای، توان عملیاتی در تأخیر و کیفیت یکسان ملاک است؛ افزایش تعداد کارت هم باید همراه با هزینهٔ سرور، برق، خنک‌سازی، قطعهٔ یدکی و نگهداری محاسبه شود.

در مقابل، داشتن یک GPU بسیار توانمند همچنان یک نمونهٔ جایگزین مستقل ایجاد نمی‌کند. اگر برای دسترس‌پذیری به سرور دوم نیاز دارید، هزینهٔ معماری کامل را مقایسه کنید؛ این محاسبه برای انتخاب H100 یا H200 هم لازم است. همچنین دو کارت ۲۴ گیگابایتی، خودبه‌خود یک کارت با حافظهٔ یکپارچهٔ ۴۸ گیگابایت نمی‌شوند؛ و RTX 4090 با حافظهٔ تغییریافتهٔ ۴۸ گیگابایت را باید جدا از مشخصات محصول استاندارد بررسی کرد. جزئیات در مدل‌های قابل‌اجرا روی RTX 4090 و تفاوت ۲۴ و ۴۸ گیگابایت و جدول امکان‌پذیری سخت‌افزاری آمده است.

ابر با پرداخت به‌اندازهٔ مصرف، راهی برای خریدن ظرفیت در زمان مناسب

در شروع پروژه هنوز معلوم نیست چه تعداد کاربر بازمی‌گردند، طول درخواست‌ها چقدر است و کدام مدل کیفیت لازم را دارد. اجارهٔ کوتاه‌مدت ظرفیت پردازشی در این مرحله، امکان امتحان‌کردن چند ترکیب مدل و سخت‌افزار را بدون تعهد به خرید فراهم می‌کند. بعد از روشن‌شدن الگوی مصرف، می‌توان برای بار پایه تصمیم گرفت و بارهای مقطعی، آزمایش مدل جدید یا پردازش‌های دوره‌ای را همچنان به ظرفیت موقت سپرد. برای اجرای گاه‌به‌گاه یک مدل بزرگ نیز اجارهٔ GPU مناسب می‌تواند از خرید تجهیزی که بیشتر روز بیکار است منطقی‌تر باشد.

اما Pay as you go شیوهٔ پرداخت است و autoscaling سازوکار تغییر ظرفیت؛ یکی وجود دیگری را تضمین نمی‌کند. در یک ماشین GPU اجاره‌ای، بستن برنامه الزاماً صورتحساب ماشین را متوقف نمی‌کند. مثلاً در Amazon EC2، ماشین روشن حتی هنگام بیکاری هزینه دارد و پس از توقف آن نیز بعضی منابع، از جمله دیسک‌های EBS، همچنان هزینهٔ مستقل دارند. در Serverless هم تعریف زمان قابل‌صورتحساب مهم است: Runpod زمان راه‌اندازی worker، پردازش درخواست و انتظار پیش از خاموشی را در هزینهٔ پردازش منظور می‌کند. پس برای مقایسهٔ دو خدمت باید روشن باشد چه چیزی اندازه‌گیری می‌شود و هزینهٔ آن چه زمانی آغاز و متوقف می‌شود.

برای سرویسی که دائماً ظرفیت کامل یک کارت را لازم ندارد، اشتراک‌گذاری GPU یا GPU Sharing انتخاب دیگری است. چند سرویس با تخصیص مدیریت‌شده از منابع مشترک استفاده می‌کنند و هرکدام مجبور نیستند هزینهٔ یک کارت کامل را بپردازند. ترگمان این خدمت را بر بستر سکوی دماوند، نخستین بار در زیرساخت افرانت ارائه کرد و بنا بر اعلام این شرکت، تنها ارائه‌دهندهٔ GPU Sharing با قابلیت Pay as you go در ایران است. تخصیص منابع در این راهکار پویاست و با کنترل مصرف و قواعد استفادهٔ منصفانه انجام می‌شود؛ هزینه نیز از سهم تخصیص‌یافتهٔ منابع و میزان استفاده تشکیل می‌شود. برای یک دستیار سازمانی با بار متغیر یا محیط توسعه و آزمایش، این مدل می‌تواند هزینهٔ ظرفیت کم‌استفاده را کاهش دهد؛ البته سهم حافظه و زمان پاسخ زیر بار هم‌زمان همچنان باید نیاز سرویس را پوشش دهند.

قابلیت اشتراک‌گذاری در راهکار ترگمان در لایهٔ مدیریت منابع و سرویس پیاده شده و به خرید و تمدید لایسنس تجاری مجازی‌سازی GPU وابسته نیست؛ سابقهٔ بهره‌برداری روی کارت‌هایی مانند RTX 4090 را هم دارد. بنابراین برای ایجاد چنین خدمتی، الزاماً نیازی به خرید کارت‌های گران‌قیمت مخصوص مجازی‌سازی نیست. تفاوت خانواده‌های سخت‌افزار و معیار اقتصادی انتخاب آن‌ها در یادداشت‌های انواع پردازنده‌های گرافیکی و انتخاب GPU متناسب با کاربرد توضیح داده شده است. در اینجا نتیجه برای طراحی خدمت مهم است: چند تیم یا سرویس کم‌بار می‌توانند از منابع موجود استفاده کنند، بدون آنکه برای هرکدام یک کارت کامل کنار گذاشته شود.

ترگمان آمادگی دارد این راهکار را برای سازمان‌ها، مراکز داده و دیگر ارائه‌دهندگان خدمات پردازشی نیز مستقر کند؛ هم برای استفادهٔ مشترک تیم‌های داخلی و هم برای عرضهٔ خدمت به مشتریان بیرونی. اگر ظرفیت موجود بیشتر روز کم‌بار است، می‌توان مدل‌های مورد استفاده، مشخصات زیرساخت، تعداد درخواست‌های هم‌زمان و زمان پاسخ موردانتظار را با تیم ترگمان در میان گذاشت و طرح استقرار متناسب با همان بار را بررسی کرد. برای پردازشی که پیوسته تمام کارت را اشغال می‌کند یا به منابع کاملاً اختصاصی نیاز دارد، گزینهٔ اختصاصی هم باید در مقایسه باقی بماند.

Spot را با اجارهٔ معمولیِ بدون تعهد زمانی یا منابع اشتراکی یکی نگیرید. برای نمونه، AWS می‌تواند ظرفیت Spot را پس بگیرد؛ در نتیجه، این گزینه برای پردازش قابل‌تکرار جذاب‌تر است و نباید بدون طراحی جایگزین، تنها تکیه‌گاه خدمت تعاملی حیاتی باشد. اشتراکی‌بودن منابع به‌خودی‌خود به معنای قابل‌پس‌گرفتن بودن آن‌ها نیست؛ شرایط دسترسی و ظرفیت تضمین‌شده را قرارداد همان خدمت تعیین می‌کند.

یک مثال ابری: برای قلهٔ مصرف، تمام ماه ظرفیت نگه نداریم

به مثال قبلی برگردیم و این بار فرض کنیم بار معمول ۳۰ درخواست در دقیقه است؛ دو نمونهٔ آماده، در محاسبهٔ ظرفیت، خروج یکی از آن‌ها را پوشش می‌دهند. فقط در ساعت‌های اوجِ ۹۰ درخواست در دقیقه به چهار نمونه نیاز داریم. در یک ماه فرضی ۷۲۰ساعته، روشن‌نگه‌داشتن چهار نمونه برای تمام ماه ۲۸۸۰ نمونه‌ساعت مصرف می‌کند. اگر دو نمونه همیشه آماده باشند و دو نمونهٔ اضافه، هرکدام مجموعاً ۶۰ ساعت ــ شامل زمان آماده‌سازی و انتظار پیش از خاموشی ــ روشن بمانند، مقدار مصرف ۱۵۶۰ نمونه‌ساعت می‌شود.

در این مثال، زمان قابل‌صورتحساب نمونه‌ها حدود ۴۶ درصد کمتر است. چون هر نمونهٔ فرضی یک GPU دارد، عدد GPU‌ساعت هم همین است؛ با تغییر معماری این دو واحد لزوماً برابر نیستند. کاهش ساعت مصرف را نیز نباید مستقیماً کاهش ۴۶درصدی کل صورتحساب خواند: تعرفهٔ ظرفیت ثابت و موقت، دیسک، شبکه، کنترل سرویس و هزینهٔ مدیریت می‌توانند متفاوت باشند. این محاسبه فقط نشان می‌دهد چرا دنبال‌کردن شکل تقاضا مهم است؛ دربارهٔ سرعت یک مدل یا قیمت یک عرضه‌کننده ادعایی ندارد. در مدلی مانند GPU Sharing ترگمان، هر نمونه الزاماً یک کارت کامل در اختیار ندارد؛ محاسبهٔ هزینه باید بر سهم تخصیص‌یافته و مصرف ثبت‌شده تکیه کند. کم‌کردن تعداد نمونه‌ها نیز فقط وقتی هزینه را کاهش می‌دهد که منابع متناظر آزاد شوند و این تغییر در مبنای صورتحساب منعکس شود.

برای معتبرماندن همین مثال، نمونه‌های اضافه باید پیش از رسیدن بار اوج آماده باشند و محل استقرارشان شرط تحمل خرابی را حفظ کند. اگر پس از تشکیل صف تصمیم به روشن‌کردن آن‌ها بگیریم، زمان تأمین ماشین، دریافت وزن‌ها، بارگذاری و گرم‌شدن موتور به انتظار کاربران اضافه می‌شود. مستندات Ray Serve نیز تصریح می‌کند که کاهش تعداد نمونه‌ها تا صفر، تأخیر شروع سرد دارد؛ و افزایش نمونه‌های برنامه در صورت کمبود منابع، به مقیاس‌دهی زیرساخت وابسته است. کم‌کردن تعداد فرایندهای مدل، الزاماً ماشین ابری را آزاد نمی‌کند.

برای اوج‌های قابل‌پیش‌بینی، ظرفیت را از قبل گرم کنید؛ برای جهش‌های ناگهانی، بخشی از ظرفیت آماده و سیاست پذیرش درخواست لازم است. آستانهٔ افزایش ظرفیت را از آزمون بار و زمان آماده‌شدن نمونهٔ تازه به دست آورید: رشد عمر صف و نزدیک‌شدن تأخیر به مرز هدف، همراه با وضعیت حافظه و درخواست‌های جاری، از نگاه‌کردن به درصد مشغولی GPU به‌تنهایی مفیدتر است. برای کاهش ظرفیت هم یک بازهٔ آرامش در نظر بگیرید تا نوسان کوتاه بار باعث خاموش و روشن‌شدن پی‌درپی نشود؛ حداقل نمونه‌های لازم برای تحمل خرابی و سقف هزینه نیز باید در سیاست مقیاس‌دهی باقی بمانند.

در معماری ترکیبیِ داخل سازمان و ابر، مدل، قالب ورودی، دسترسی به منابع مجاز و مسیر شبکهٔ بخش ابری باید از قبل آماده باشد. ابرِ جایگزینی که هنگام بحران تازه باید وزن‌ها را دانلود کند یا به اسناد سازمان دسترسی پیدا کند، همان نقش نمونهٔ آماده را ندارد. همچنین اگر ظرفیت لازم در سهمیه یا ناحیهٔ انتخابی موجود نباشد، صرف فعال‌کردن autoscaling آن را ایجاد نمی‌کند. این محدودیت به معنای کنارگذاشتن ظرفیت موقت نیست؛ زمان و شرایط فراهم‌شدن آن باید جزئی از طراحی خدمت باشد.

مقیاس‌پذیری با صف نامحدود به دست نمی‌آید

کنترل ظرفیت فقط افزودن GPU نیست؛ باید مشخص باشد هر کاربر یا برنامه تا چه حد می‌تواند سرویس را اشغال کند. برای گفت‌وگوی کوتاه، تحلیل طولانی و کارهای پس‌زمینه، صف یا اولویت جدا در نظر بگیرید و برای ورودی، خروجی و زمان اجرا بودجهٔ متناسب تعیین کنید. وقتی ظرفیت کافی نیست، انتظار محدود با پیام روشن یا انتقال کار به پردازش غیرهم‌زمان می‌تواند از صفی که همه را معطل می‌کند بهتر باشد. کاهش کیفیت نیز اگر لازم شد باید مطابق سیاست محصول باشد؛ جایگزین‌کردن خاموشِ تحلیل حساس با پاسخ ضعیف‌تر راه‌حل ظرفیت نیست.

درخواست‌های تکراری هم می‌توانند بحران را تشدید کنند. وقتی سرویس کند می‌شود، تلاش مجدد هم‌زمان کاربران بار بیشتری تولید می‌کند؛ محدودکردن تعداد تلاش‌ها و فاصله‌گذاری افزایشی، همراه با کمی تصادفی‌سازی، به مهار این موج کمک می‌کند. هنگام لغو درخواست نیز تا حد پشتیبانی موتور، اجرای بی‌مصرف را متوقف کنید. این سیاست‌ها بخشی از طراحی تحمل اضافه‌بارند و باید با توازن بار و محدودیت هم‌زمانی هماهنگ شوند.

آزمون ظرفیت را هم با بار سالم و مرتب تمام نکنید. ورود هم‌زمان درخواست‌ها، ورودی‌های بلند، خروج یک نمونه، بازگشت نمونه با کش سرد و قطع یک وابستگی را بررسی کنید؛ نرخ خطا، کارهای لغوشده و درخواست‌های خارج از زمان هدف را کنار خروجی موفق ثبت کنید. ظرفیت مفید، تعداد کارهایی است که در کیفیت و زمان پذیرفته‌شده تکمیل می‌شوند. سامانه‌ای که توکن بیشتری تولید می‌کند ولی کاربران بیشتری پاسخ دیرهنگام یا نامعتبر می‌گیرند، الزاماً سرویس بهتری نیست.

برای مقایسهٔ اقتصادی، یک شاخص عملی هزینهٔ کل دوره تقسیم بر تعداد کارهای پذیرفته‌شده در همان دوره است. هزینهٔ نمونه‌های آماده، تلاش‌های ناموفق، مسیر مدل دوم و اجزای جانبی در صورت کسر می‌آیند؛ کاری که به زمان یا کیفیت لازم نرسیده، در مخرج موفقیت شمرده نمی‌شود. این شیوه روشن می‌کند چه زمانی چند GPU متعارف مقرون‌به‌صرفه‌ترند و چه زمانی سخت‌افزار حرفه‌ای با خروجی مفید بیشتر، هزینهٔ بالاتر خود را جبران می‌کند. برای مقایسهٔ دو معماری، تعریف کار پذیرفته‌شده و ترکیب درخواست‌ها باید یکسان بماند.

برای هر نشانه، تغییر متناسب انتخاب کنید

تصمیم ارتقا را می‌توان به چند مشاهدهٔ روشن گره زد. جدول زیر ترتیب ثابت و اجباری برای همهٔ پروژه‌ها نیست؛ راهی است برای اینکه بودجه به بخشی برسد که واقعاً محدودیت ایجاد کرده است. معیارهای مدل و سخت‌افزار را نیز می‌توان در راهنمای انتخاب مدل زبانی کنار هم دید. برای تعریف کیفیت قابل قبول، راهنمای ارزیابی مدل‌های زبانی برای فارسی روش ساخت نمونه و ثبت خطا را توضیح می‌دهد؛ هزینهٔ هر معماری را بر تعداد کارهایی تقسیم کنید که از همین معیارها عبور می‌کنند.

سرویسی که امروز برای چند نفر ساخته می‌شود، لازم نیست از ابتدا همهٔ تجهیزات ظرفیت نهایی را داشته باشد؛ کافی است واحدهای آن قابل‌تکثیر باشند و نقطهٔ افزایش ظرفیت از روی داده مشخص شود. انتخاب مدل متناسب، امکان اجرای مستقل روی سخت‌افزار در دسترس و جداسازی دامنه‌های خرابی، رشد مرحله‌ای را ممکن می‌کند. در چنین معماری‌ای می‌توان ظرفیت را هرجا لازم شد افزود، بخشی را موقتاً از ابر گرفت و GPU بزرگ‌تر را زمانی وارد کرد که حافظه، تأخیر یا هزینهٔ کل، نیاز به آن را نشان می‌دهد.