Hugging Face Spaces یا Endpoints؛ دموی ارزان جای سرویس پایدار را نمی‌گیرد

برای نمایش تعاملی مدل، Hugging Face Spaces انتخاب مناسبی است. اگر برنامه فقط گاهی به یک API استنتاج نیاز دارد، Inference Providers را بررسی کنید؛ اگر مدل باید روی ظرفیت اختصاصی با تعداد replica قابل‌تنظیم اجرا شود، Inference Endpoints به نیاز نزدیک‌تر است. ارزان‌بودن یک دمو به‌تنهایی نشان نمی‌دهد که همان استقرار پاسخ‌گوی سرویس تولیدی خواهد بود.

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

کدام مسیر برای دمو، API و مدل اختصاصی مناسب است؟

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

برای فراخوانی‌های نامنظم API، تعرفهٔ Inference Providers دسترسی مصرف‌محور به بیش از ۲۰۰ مدل را بدون مدیریت مستقیم زیرساخت توضیح می‌دهد. در این مسیر، هزینه به مدل و ارائه‌دهندهٔ انتخابی و میزان استفاده بستگی دارد، نه به ساعت روشن‌ماندن یک GPU اختصاصی در حساب شما. کاربر حساب رایگان اعتبار ماهانهٔ شامل‌شده ندارد و برای استفاده باید اعتبار بخرد؛ اعتبار ماهانهٔ طرح PRO برابر ۲ دلار است.

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

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

برای مقایسه‌ای محدود، دو نمونه با شتاب‌دهندهٔ Nvidia T4 را مبنا می‌گیریم. تعرفهٔ سخت‌افزار Spaces قیمت T4 small را ۰٫۴۰ دلار در ساعت ثبت می‌کند و می‌گوید زمان شروع و اجرای سخت‌افزار به‌صورت دقیقه‌ای صورتحساب می‌شود، حتی اگر کسی از Space استفاده نکند. سخت‌افزار ارتقایافته به‌طور پیش‌فرض روشن می‌ماند، ولی می‌توان برای آن زمان خواب تعیین کرد یا Space را متوقف کرد. CPU Basic هزینهٔ ساعتی ندارد؛ ساخت Space محاسباتی تازه با Gradio یا Docker به طرح پولی نیاز دارد.

تعرفهٔ Inference Endpoints برای نمونهٔ AWS با یک Nvidia T4 نرخ ۰٫۵۰ دلار در ساعت را نشان می‌دهد؛ هزینهٔ واقعی بر پایهٔ دقیقه‌های اجرا و تعداد replicaها محاسبه می‌شود. این دو نمونه با وجود نام مشترک شتاب‌دهنده، از نظر مشخصات یکسان نیستند: در جدول‌ها، حافظهٔ GPU برای T4 small در Spaces برابر ۱۶ گیگابایت و برای نمونهٔ انتخابی AWS در Endpoints برابر ۱۴ گیگابایت است. بنابراین محاسبهٔ زیر قیمت ظرفیت روشن را کنار هم می‌گذارد، نه کارایی یا هزینهٔ هر پاسخ را.

• در سناریوی فرضیِ یک ساعت اجرای پیوسته با یک نمونه، هزینهٔ Spaces برابر ۰٫۴۰ دلار و هزینهٔ Endpoint برابر ۰٫۵۰ دلار است.
• برای هشت ساعت روشن‌ماندن همان نمونه، هزینه‌ها به‌ترتیب ۳٫۲۰ و ۴ دلار می‌شوند؛ کم‌بودن درخواست‌ها در این بازه، هزینهٔ ظرفیت روشن را حذف نمی‌کند.
• برای بیست‌وچهار ساعت اجرای پیوسته، هزینهٔ یک replica به‌ترتیب ۹٫۶۰ و ۱۲ دلار است. این ارقام فقط هزینهٔ یک شبانه‌روزِ نمونه‌های انتخابی‌اند.

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

خوابیدن نمونه و شروع سرد چه تغییری می‌دهد؟

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

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

این تفاوت در بار پراکنده مهم‌تر از اختلاف ظاهری نرخ دو GPU است. اگر فاصلهٔ بین درخواست‌ها طولانی باشد، پرداخت به‌ازای مصرف Inference Providers می‌تواند از نگه‌داشتن ظرفیت اختصاصی مناسب‌تر باشد. اگر درخواست‌ها پیوسته‌اند یا پاسخ نخست باید بدون انتظار برای راه‌اندازی برسد، هزینهٔ ظرفیت آماده بخشی از تصمیم عملیاتی است، نه مبلغی که بتوان با خواب‌کردن نمونه بدون پیامد حذف کرد.

مقیاس‌پذیری را همراه با هزینهٔ replica بسنجید

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

در Endpoints می‌توان حداقل و حداکثر replica را برای بار کاری تعیین کرد. وقتی replica تازه برای پاسخ به افزایش تقاضا شروع می‌شود، هزینهٔ آن به مدت اجرای همان ظرفیت افزوده بستگی دارد. به‌عنوان مثال فرضی، اگر replica دومِ هم‌قیمت با نمونهٔ T4 انتخابی یک شبانه‌روز کامل روشن بماند، هزینهٔ ظرفیت Endpoint از ۱۲ به ۲۴ دلار می‌رسد؛ اگر فقط هنگام اوج بار اجرا شود، هزینهٔ اضافی به همان مدت محدود می‌شود.

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

دسترسی، پایش و SLA از قیمت نمونه جدا هستند

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

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

اگر سرویس به SLA نیاز دارد، سطح دسترس‌پذیری، پشتیبانی و مسئولیت هنگام اختلال باید در شرایط قراردادی همان طرح روشن باشد. قیمت ساعتی GPU یا عبارت «مدیریت‌شده» به‌تنهایی تعهد خدمت ایجاد نمی‌کند. انتخاب نهایی به همین مرز برمی‌گردد: Spaces برای تجربهٔ تعاملی، Inference Providers برای مصرف API بدون ظرفیت اختصاصی، و Endpoints برای مدلی که کنترل ظرفیت و الزامات عملیاتی‌اش هزینهٔ روشن‌ماندن را توجیه می‌کند.

بیشتر بخوانید:

• رزومه یا GitHub؛ کد واقعی جای روایت شغلی را نمی‌گیرد
• Shopify یا WooCommerce؛ رایگان‌بودن افزونه هزینهٔ کل را تعیین نمی‌کند
• Hugging Face یا Replicate؛ ترافیک پراکنده هزینه را برعکس می‌کند