هزینه استنتاج در Hugging Face: تقابل مدل‌های بدون سرور با GPUهای اختصاصی

تصور کنید یک نمونه اولیه سریع در Hugging Face را توسعه داده‌اید، اما در لحظه مقیاس‌دهی به تولید، کل سیستم به دلیل انتخاب اشتباه حالت استنتاج از هم می‌پاشد. در حالی که حالت بدون سرور (Serverless) مسیر ساده‌ای به نظر می‌رسد، اما هیچ تضمینی برای تأخیر (Latency) یا در دسترس بودن در شرایط بار شدید (Under Load) ارائه نمی‌دهد؛ واقعیتی که صراحتاً در مستندات ذکر شده است. بدون در نظر گرفتن پیش‌بینی‌پذیری تأخیر و بار ترافیکی، انتخاب بین حالت بدون سرور و اختصاصی ناقص pozost می‌ماند. باید درک کرد که پایین بودن سد ورود، با مناسب بودن حالت عملیاتی یکسان نیست.

بسیاری از توسعه‌دهندگان مسیر بدون سرور را انتخاب می‌کنند چون در یک دقیقه فعال می‌شود و نیازی به انتخاب سخت‌افزار ندارد. اما طبق مستندات به‌روزرسانی شده در جولای ۲۰۲۶، این سادگی در واقع تغییر بنیادین در نحوه مدیریت درخواست‌ها را می‌پوشاند. پلتفرم از محدودیت‌های ساعتی ثابت فاصله گرفته و به یک سامانه مبتنی بر اعتبار (Credit-based) تغییر یافته است. اگر مقالاتی از سال ۲۰۲۴ می‌خوانید که از «چند صد درخواست در ساعت» می‌گویند، بدانید که آن اعداد توصیف‌کننده مدلی هستند که دیگر در اسناد رسمی فعلی وجود ندارد. این رویکرد مدیریت منابع و سهمیه‌ها، شباهت زیادی به نحوه مدیریت لایه‌های رایگان و هزینه‌های پنهان در گوگل AI API دارد که در آن مرز میان دسترسی رایگان و تجاری بسیار حساس است.

در گذشته, Inference API به عنوان یک دروازه مستقیم عمل می‌کرد. اما امروزه، این سیستم به عنوان یک لایه «ارائه‌دهنده‌ استنتاج» (Inference Providers) عمل می‌کند. این پروکسی درخواست‌ها را به بک‌اند داخلی hf-inference یا یکی از بیش از ۱۵ شریک تجاری ثالث، از جمله Groq، Cerebras، Together، fal، Novita و دیگران هدایت می‌کند.

این تغییر ساختاری به این معنی است که پروفایل عملکرد دیگر تنها توسط Hugging Face تعیین نمی‌شود، بلکه توسط ارائه‌دهنده شریک تعیین می‌گردد. صورت‌حساب اکنون به اعتبارهای ماهانه بر اساس نوع حساب گره خورده است:

• حساب‌های رایگان: ۰.۱۰ دلار اعتبار در ماه
• حساب‌های PRO: ۲.۰۰ دلار اعتبار در ماه
• حساب‌های تیمی/سازمانی: ۲.۰۰ دلار به ازای هر کاربر در ماه

به محض اینکه اعتبارها به پایان برسند، کاربران برای ادامه ارسال درخواست‌ها باید به مدل قیمت‌گذاری پرداخت به‌ازای مصرف (Pay-as-you-go) منتقل شوند. Hugging Face نرخ‌های ارائه‌دهنده را بدون افزودن هیچ‌گونه مبلغ اضافی (Markup) منتقل می‌کند.

نکته کلیدی این است که بک‌اند داخلی hf-inference دیگر موتور اصلی برای مدل‌های زبانی بزرگ (LLM) نیست. طبق یادداشتی در مستندات جولای ۲۰۲۵، این زیرساخت عمدتاً بر استنتاج مبتنی بر CPU برای بردارهای معنایی (Embeddings)، رتبه‌بندی متن، طبقه‌بندی و مدل‌های قدیمی مانند BERT یا GPT-2 متمرکز شده است. مدل‌های زبانی بزرگ تقریباً به‌طور کامل به شرکای GPU خارجی هدایت می‌شوند. در واقع شما هزینه قدرت سخت‌افزاری شخص ثالث را از طریق یک پروکسی می‌پردازید؛ بنابراین پروفایل تأخیر توسط شریک تعیین می‌شود و نه توسط HF.

همان‌طور که در تحلیل‌های قبلی ما درباره امنیت و زیرساخت مدل‌های بازمتن اشاره کردیم، لایه‌های انتزاعی می‌توانند هزینه‌های پنهان ایجاد کنند. در این زمینه، باید به ریسک‌های امنیتی لایه‌های واسط توجه داشت؛ برای مثال، پدیده HalluSquatting نشان می‌دهد چگونه توهمات مدل‌ها می‌توانند به درگاه‌هایی برای اجرای بدافزارها تبدیل شوند. Hugging Face صراحتاً حالت بدون سرور را به عنوان راهکاری برای «تحقیق و ارزیابی» تعریف کرده است که روی «منابع اشتراکی» کار می‌کند و نه یک سطح گرید تولیدی (Production-grade). اگر حجم درخواست‌های شما اعتبار ماهانه را در چند روز اول ماه می‌بلعد، یعنی از مرحله تحقیق وارد جریان تولید شده‌اید؛ جریانی که حالت بدون سرور برای پشتیبانی از آن طراحی نشده است. پیش از انتخاب، حجم درخواست ماهانه مورد انتظار خود را محاسبه کنید، میانگین هزینه هر فراخوانی را از طریق نرخ ارائه‌دهنده تخمین بزنید و آن را با سقف اعتبار حساب خود مقایسه کنید.

قطعیت در نقاط پایانی اختصاصی

برای کسانی که به دنبال هزینه و عملکرد پیش‌بینی‌پذیر هستند، Hugging Face Inference Endpoints در حالت اختصاصی (Dedicated mode) وعده عملیاتی متفاوتی می‌دهد. در اینجا شما سخت‌افزار خاص — CPU یا GPU — را از طریق ارائه‌دهندگانی مثل AWS، Azure یا GCP انتخاب می‌کنید.

برخلاف اعتبار مدل بدون سرور، صورت‌حساب حالت اختصاصی دقیقه به دقیقه و بر اساس نرخ نمونه (Instance rate) است. هزینه‌ها فقط زمانی اعمال می‌شوند که نقطه پایانی در وضعیت «در حال مقدارزنی» (Initializing) یا «در حال کار» (Working) باشد. یک نقطه پایانی متوقف‌شده (Paused) هیچ هزینه‌ای در بخش محاسبات ندارد. این ساختار اجازه می‌دهد هزینه کل مالکیت (TCO) را به‌صورت قطعی با فرمول زیر محاسبه کنید:

نرخ ساعتی نمونه × (ساعات پایه رپلیکا + ساعات مقیاس‌دهی خودکار رپلیکا)

نرخ‌ها بسته به سخت‌افزار به‌طور گسترده‌ای متفاوت است. طبق داده‌های ۱۸ جولای ۲۰۲۶، نرخ‌های ثبت شده عبارتند از:

• AWS Intel-spr x1 CPU: شروع از ۰.۰۳۳ دلار در ساعت
• GCP NVIDIA H100 GPU: تا ۱۰.۰۰ دلار در ساعت

مکانیسم‌های مقیاس‌دهی خودکار و آستانه‌ها

حالت اختصاصی دارای محرک‌های دقیقی برای مقیاس‌دهی خودکار (Autoscaling) است تا تعیین کند آیا سیستم می‌تواند پیش از یک پیک ترافیکی قدرت سخت‌افزاری را مستقر کند یا درخواست‌ها با رپلیکاهای مشغول مواجه خواهند شد:

• بهره‌وری CPU/GPU: زمانی که میانگین بهره‌وری به ۸۰٪ برسد، یک رپلیکای جدید اضافه می‌شود (برای GPU، این میانگین در یک پنجره یک‌دقیقه‌ای محاسبه می‌شود).
• مقیاس‌دهی مبتنی بر درخواست (بتا): زمانی فعال می‌شود که بیش از ۱.۵ درخواست منتظر به‌ازای هر رپلیکا برای ۲۰ ثانیه وجود داشته باشد.
• فواصل بررسی: بررسی مقیاس‌دهی به بالا هر یک دقیقه و بررسی مقیاس‌دهی به پایین هر دو دقیقه یک‌بار انجام می‌شود.
• تثبیت (Stabilization): یک تأخیر ۳۰۰ ثانیه‌ای در طول تثبیت اعمال می‌شود تا از نوسانات سریع (Oscillation) جلوگیری شود.

هزینه پنهان مقیاس‌دهی به صفر

اگرچه مقیاس‌دهی به صفر هزینه‌های زمان بیکاری را با خاموش کردن سیستم پس از ۱۵ دقیقه عدم فعالیت حذف می‌کند، اما یک نقطه شکست بحرانی ایجاد می‌کند: راه‌اندازی سرد (Cold Start). در طول یک ری‌بوت، نقطه پایانی درخواست‌ها را در صف نگه نمی‌دارد؛ بلکه صرفاً یک خطای HTTP 502 باز می‌گرداند.

چون هیچ صفی داخلی وجود ندارد، بار پایداری کاملاً بر عهده کلاینت منتقل می‌شود. مدت زمان راه‌اندازی سرد متغیر است و «به اندازه مدل بستگی دارد» و هیچ عدد ثابتی در منابع منتشر نشده است. اگر کد شما برای مدیریت این خطاهای ۵۰۲ طراحی نشده باشد، کاربران در هر چرخه بیدار شدن سیستم با خطا مواجه می‌شوند. تحت بار شدید، سیستم ممکن است خطاهای ۵۰۳ را نیز صادر کند.

برای کاهش این اثرات، توصیه رسمی FAQ شرکت Hugging Face این است که برای محیط تولید حداقل دو رپلیکا نگه دارید. این پیکربندی، در ترکیب با یک مسیر بررسی سلامت (که در صورت آمادگی HTTP 200 برمی‌گرداند) و هدر X-Scale-Up-Timeout تضمین می‌کند که سیستم می‌تواند شوک‌های ترافیکی را بدون حذف درخواست‌ها جذب کند. استفاده از دو رپلیکا به این معنی است که شما هزینه آگاهانه‌ای را برای اجتناب از خطاهای استارت‌آپ می‌پردازید و از منطق «ارزان‌تر از بدون سرور» فاصله می‌گیرید.

مهندسی یک کلاینت تاب‌آور نیازمند استراتژی «پس‌کشی نمایی» (Exponential Backoff) است. یک پیاده‌سازی حداقلی شامل محصور کردن درخواست‌ها در یک حلقه تکرار (Retry Loop) است که در صورت شناسایی کدهای ۵۰۲ یا ۵۰۳، بین تلاش‌ها زمان انتظار (Sleep) را افزایش می‌دهد. بدون یک حلقه تکرار، صف یا بررسی سلامت، انتخاب حالت عملیاتی (چه بدون سرور و چه اختصاصی) ناقص است.

import time, httpx

def call_endpoint(client, url, payload, retries=5):
    for attempt in range(retries):
        r = client.post(
            url, 
            json=payload, 
            headers={"X-Scale-Up-Timeout": "180"},
        )
        if r.status_code in (502, 503):
            time.sleep(min(2 ** attempt, 30)) # exponential backoff
            continue
        return r
    raise RuntimeError("endpoint failed to start within allocated attempts")

مقایسه بدون سرور در برابر اختصاصی

جایگزین‌های استراتژیک و واقعیت‌های SLA

یک تصور رایج این است که نقاط پایانی اختصاصی به‌طور خودکار تضمین دسترسی بالا دارند. اما به‌صورت رسمی، یک SLA ۲۴/۷ تنها برای سطح Enterprise در دسترس است؛ این سطح شامل قیمت سفارشی با قرارداد سالانه و تعهدات حجمی است. در یک نقطه پایانی اختصاصی استاندارد (Pay-as-you-go)، هیچ درصد آپ‌تایم مشخصی (مانند ۹۹.۹٪) به‌طور عمومی منتشر نشده است.

برای توسعه‌دهندگانی که نیاز به میزبانی یک مدل اختصاصی ندارند اما برای دسترسی پایدار به مدل‌های LLM از روسیه نیاز به راهکار دارند، سرویس‌هایی مثل provod.ai مسیر متفاوتی ارائه می‌دهند. این سرویس به عنوان یک آنالوگ روسی برای OpenRouter عمل کرده و یک API واحد و سازگار با OpenAI را برای مدل‌های Claude، GPT، DeepSeek، Gemini، Grok، Qwen و دیگران فراهم می‌کند.

با جایگزینی base_url و کلید API، تیم‌ها می‌توانند به این مدل‌ها با مبالغ روبلی و بدون نیاز به VPN دسترسی داشته باشند. این ادغام از نظر پروتکل سازگار است:

from openai import OpenAI
client = OpenAI(
    api_key="YOUR_KEY",
    base_url="https://api.provod.ai/v1", # OpenAI-compatible route
)

دو ویژگی کلیدی این رویکرد را مرتبط می‌کند: مسیریابی چندکاناله پایدار (اگر یک کانال بالادستی موقتاً قطع شود، درخواست‌ها ادامه می‌یابند) و دسترسی به مدل‌ها با قیمت‌های رسمی ارائه‌دهنده بدون Markup، که به‌صورت روبلی قابل پرداخت است. اگرچه این روش جایگزینی برای نیاز به میزبانی مدل اختصاصی شما در Hugging Face نیست، اما سربار زیرساختی را برای کسانی که از مدل‌های پیشرو (Frontier) استاندارد استفاده می‌کنند، حذف می‌کند.

انتخاب حالت عملیاتی

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

• بدون سرور را انتخاب کنید اگر: وظیفه شما تحقیق روی مدل‌ها، اجرای Embeddings، طبقه‌بندی یا استفاده از LLMهای قدیمی و سبک با ترافیک نادر و غیرقابل‌پیش‌بینی است. در این حالت، منابع اشتراکی و اعتبارها یک پیش‌فرض معقول هستند.
• اختصاصی را انتخاب کنید اگر: زمان پاسخگویی (Response Time) یک وعده محصولی است، ترافیک شما به‌طور مداوم از سقف اعتبار فراتر می‌رود و پیک‌های ترافیکی باید بدون خطاهای کاربر-رو مدیریت شوند. این انتخاب مستلزم برنامه‌ای برای TCO قطعی، حداقل دو رپلیکا و پیاده‌سازی Retry در کلاینت است.

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

محدودیت‌های این مقایسه

فرمول TCO یک مرز برای تخمین فراهم می‌کند، اما مبلغ دقیق ماهانه به ترافیک خاص و انتخاب نمونه (Instance) شما بستگی دارد. نرخ‌های دلاری، عکس‌برداری لحظه‌ای (Snapshot) از صفحه قیمت‌گذاری زنده هستند و ممکن است بدون اطلاع قبلی تغییر کنند. این یک بنچمارک نیست؛ هیچ اندازه‌گیری مستقل از تأخیر یا حسابرسی هزینه خارجی وجود ندارد و تنها مستندات प्राथमिक HF ملاک است. علاوه بر این، این مقایسه در اکوسیستم Hugging Face باقی می‌ماند. جایگزین‌هایی مانند سخت‌افزار محلی (On-prem) یا GigaChat باید به‌طور جداگانه و بر اساس معیارهای خودشان محاسبه شوند.