اگر امروز برای استقرار مدل‌های خود بودجه‌ای تخصیص داده‌اید، احتمالاً نیمی از پول شما صرف پردازش داده‌ها نمی‌شود، بلکه بابت «منتظر ماندن» مدل‌ها پرداخت می‌شود. صورت‌حساب GPU شما در واقع داستانی از زیربهره‌برداری از زیرساخت است، نه بازتابی از کارایی مدل. این تمایز در ۶ اوت ۲۰۲۶، طی یک بررسی عمیق در زمینه FinOps هوش مصنوعی، به‌طور شفاف تبیین شد.
برای سال‌ها، صنعت بر روی «قیمت به ازای هر توکن» به عنوان استاندارد طلایی اقتصاد هوش مصنوعی تمرکز کرده است. این معیار برای APIهای SaaS که در آن فقط بابت آنچه مصرف می‌کنید پرداخت می‌کنید، به‌خوبی عمل می‌کند؛ شما توکن‌ها را می‌فرستید، توکن‌ها را دریافت می‌کنید و یک سیستم صورت‌حساب، داشبورد شما را به‌روز می‌کند. اما برای تیم‌هایی که روی Kubernetes میزبانی شخصی (Self-hosting) می‌کنند، این معیار یک توهم خطرناک است که هزینه حمل و نقل و نگهداری برای آماده‌باش (Carrying cost of readiness) را نادیده می‌گیرد. این چالش با بحث‌های پیشین درباره گمراه‌کننده بودن مدل‌های قیمت‌گذاری توکنی همسو است که نشان می‌دهد معیارهای سنتی لزوماً بازتاب‌دهنده هزینه‌های واقعی بودجه نیستند.
با تکیه بر تکامل مدیریت هزینه‌های ابری، شکاف بین «مصرف» و «تخصیص» جایی است که اکثر بودجه‌های هوش مصنوعی شکست می‌خورند. یک GPU را مثل یک دفتر کار اجاره‌ای تصور کنید: هزینه مبتنی بر مصرف، شبیه به برق مصرف شده در زمان کار است، اما هزینه مبتنی بر تخصیص، همان اجاره‌بهایی است که حتی وقتی دفتر خالی است، باید پرداخت کنید. در دنیای میزبانی شخصی، شما فقط استنتاج (Inference) نمی‌خرید؛ بلکه در حال اجرای یک پشته پیچیده از GPUها، حافظه، گیت‌وی‌ها، پادها و وزن‌های مدل هستید که در حافظه ویدیویی (VRAM) جای گرفته‌اند.
پیشرفت OpenCost در ردیابی هزینه‌ها
پلتفرم OpenCost در نسخه ۱.۱۲۱.۰ قابلیت ردیابی تخصصی هزینه‌های استنتاج در Kubernetes را معرفی کرده است. این ابزار با ادغام معیارهای vLLM و llm-d، تیم‌های پلتفرم را مجبور می‌کند بین دو عدد حیاتی تمایز قائل شوند:
- هزینه مبتنی بر مصرف (Usage-based cost): محاسبات فعالی که هنگام پردازش توکن‌ها توسط مدل مصرف می‌شود. این بخش مربوط به کار واقعی است که در آن توکن‌های ورودی و خروجی هزینه‌های پردازشی واقعی دارند و نرخ برخورد با KV Cache این هزینه را تغییر می‌دهد.
- هزینه مبتنی بر تخصیص (Allocation-based cost): هزینه در دسترس بودن. این شامل حافظه رزرو شده GPU، پشته‌ی سرویس‌دهی، زیرساخت‌های مشترک و وزن‌هایی است که در VRAM نشسته‌اند، فارغ از اینکه ترافیک درخواست‌ها در خواب باشد یا بیدار.
این تفکیک حیاتی است زیرا گفتگو را از اسلایدهای فریبنده — که در آن GPUها به‌طور جادویی ۱۰۰٪ اشغال شده‌اند — به واقعیت خوشه‌های Kubernetes می‌کشاند. این رویکرد، تخصیص هزینه را دقیقاً به جایی متصل می‌کند که بار کاری واقعاً در حال اجراست.
تله‌ی مدل‌های «ارزان‌قیمت» در میزبانی شخصی
بسیاری از تیم‌ها از جداول اکسل برای توجیه میزبانی شخصی استفاده می‌کنند و هزینه داخلی ۱ دلار به ازای هر میلیون توکن را در برابر ۲ دلار برای APIهای خارجی قرار می‌دهند. این محاسبه تنها زمانی درست است که GPU به‌طور مداوم مشغول به کار باشد. اگر مدل نیمی از روز بیکار باشد، هزینه واقعی هر توکن دو برابر می‌شود، زیرا فاکتور نهایی شامل ساعات سکوت نیز هست.
یک GPU که مدل روی آن بارگذاری شده، فقط به این دلیل که صف درخواست‌ها خالی است، رایگان نمی‌شود؛ بلکه صرفاً به شکلی کمتر جذاب، گران است. هزینه‌های مبتنی بر مصرف با نادیده گرفتن هزینه آماده‌باش، به‌طور مودبانه‌ای دروغ می‌گویند. فاکتور ماهانه اهمیتی نمی‌دهد که بنچمارک شما برای هفت دقیقه بهینه بوده است؛ بلکه به کل تخصیص اهمیت می‌دهد.
ظرفیت گرم به عنوان یک تصمیم محصولی
نگه داشتن ظرفیت به‌صورت «گرم» (Warm) اغلب برای جلوگیری از راه‌اندازی سرد (Cold Start) و تأخیر بالا ضروری است. کاربران دوست ندارند منتظر بمانند تا پلتفرم یاد بگیرد چگونه مفید باشد و برخی از بارهای کاری نمی‌توانند هزینه‌ی یک «ماجراجویی در زمان‌بندی و مراسم بارگذاری» را متحمل شوند.
با این حال، این موضوع باید یک انتخاب معماری آگاهانه باشد، نه یک اتفاق تصادفی. اینجاست که AI FinOps به مهندسی پلتفرم تبدیل می‌شود. به‌جای پرسش «آیا این مدل گران است؟»، تیم‌ها باید بپرسند:
- کدام تیم‌ها واقعاً به گرم بودن این مدل نیاز دارند؟
- کدام ترافیک‌ها می‌توانند تأخیر در مقیاس‌دهی یا صف انتظار را تحمل کنند؟
- کدام بارهای کاری کم‌حجم باید به APIهای خارجی منتقل شوند؟
- کدام مدل‌ها می‌توانند برای بهبود بهره‌وری، ظرفیت مشترک داشته باشند؟
- کدام مسیرها باید ترافیک را تجمیع کنند؟
- کدام آزمایش‌ها سخت‌افزار سطح تولید (Production-grade) را برای استفاده‌های نمایشی (Demo-grade) رزرو کرده‌اند؟
برای مدیریت بهینه این ترافیک‌ها، استفاده از سیستم‌های مسیریابی لایه‌ای می‌تواند راهکاری موثر برای توقف اتلاف بودجه بدون کاهش کیفیت پاسخ‌دهی باشد.
عیب‌یابی فاکتور با برچسب‌ها
OpenCost سیستمی از برچسب‌گذاری را پیاده کرده که فاکتور را قابل عیب‌یابی می‌کند. با تگ کردن هزینه‌ها با متادیتای خاص، «مه غلیظ هزینه‌های هوش مصنوعی» کنار می‌رود. این برچسب‌ها شامل موارد زیر است:
- نام و نسخه مدل: شناسایی دقیق اینکه کدام تکرار مدل در حال مصرف پول است.
- فضای نام (Namespace): نسبت دادن هزینه‌ها به تیم‌ها یا محیط‌های خاص.
- نوع بار کاری: تمایز بین انواع مختلف وظایف هوش مصنوعی.
- مبنای هزینه: مشخص کردن صریح اینکه هزینه از نوع مصرف است یا تخصیص.
بدون این برچسب‌های خسته‌کننده، تشخیص این موضوع غیرممکن است که هزینه توسط چت‌بات یک تیم ایجاد شده، یا یک سامانه خلاصه‌ساز دسته‌ای، یا حتی یک استقرار آزمایشی فراموش‌شده از ماه مارس که هیچ‌کس جرات دست زدن به آن را ندارد. تخصیص هزینه، رفتار مهندسی را تغییر می‌دهد. وقتی تیم‌ها هزینه ثابت گرم نگه داشتن مدل را برای فضای نام خود می‌بینند، به‌جای بحث بر سر «حس و حال» (Vibes) با یک فایل اکسل، گفتگوهای واقعی درباره تأخیر و موازنه انجام می‌دهند.
پلتفرم مالک این شکاف است
ما این الگو را قبلاً در Kubernetes دیده‌ایم. درخواست‌های CPU جزئیات کوچکی در فایل‌های YAML به نظر می‌رسیدند تا اینکه بارهای کاری با درخواست بیش از حد، به پول واقعی تبدیل شدند. کلاس‌های ذخیره‌سازی شبیه به لوله‌کشی به نظر می‌رسیدند تا اینکه حجم‌های باقی‌مانده به صورت فاکتور ظاهر شدند. اکنون استنتاج هم همین مسیر را می‌رود: YAML به توکن متصل شده است.
شکاف بین مصرف و تخصیص، هزینه آماده‌باش است. گاهی این شکاف سالم است — مثلاً یک سیستم ضدتقلب یا دستیار مدیریت حوادث به دلیل بحرانی بودن زمان پاسخ، ظرفیت گرم را توجیه می‌کند. اما در موارد دیگر، این شکاف صرفاً اتلاف است؛ مثل یک پروژه آزمایشی با ۱۲ کاربر یا لایه‌ای از مسیریابی که ترافیک را چنان پخش می‌کند که هر مدل زیربهره‌برده به نظر برسد.
این یک مشکل مدل نیست؛ یک مشکل پلتفرم است. پلتفرم مالک مسیریابی، جداسازی، سهمیه‌ها، زمان‌بندی‌ها، سیاست‌های مقیاس‌دهی خودکار، رفتار حافظه پنهان (Cache) و دیدِ هزینه‌ای است. زیرساخت هوش مصنوعی در حال تبدیل شدن به زیرساخت معمولی است و به ابزارهای خسته‌کننده‌ای مثل گزارش‌های تخصیص، بودجه‌بندی و عملیات پاک‌سازی با قدرت اجرایی نیاز دارد.
از خوش‌بینی به بهره‌وری
میزبانی شخصی برای کسانی که می‌خواهند پشته سرویس‌دهی را تنظیم کنند و مالک زمان اجرا باشند، انتخابی قدرتمند است. اما میزبانی شخصی یک ویژگی شخصیتی نیست؛ بلکه نیازمند بهره‌وری است. اگر هزینه تخصیص به ازای هر میلیون توکن از قیمت API خارجی بیشتر است، راه حل تغییر معماری است، نه بحث با اکسل تا روحیه تیم بهبود یابد.
گام‌های عملی برای کاهش این شکاف عبارتند از:
- مسیریابی ترافیک بیشتر به مدل‌های گرم کمتر.
- استفاده از مدل‌های کوچک‌تر در جایی که برای وظیفه کافی هستند.
- جداسازی ترافیک‌های حساس به تأخیر از پردازش‌های دسته‌ای.
- مقیاس‌دهی نزولی تهاجمی برای آزمایش‌ها.
- نمایان کردن هزینه به ازای هر فضای نام و نسخه مدل برای شفاف‌سازی هزینه‌های ثابت.
نسخه کاربردی ردیابی هزینه هوش مصنوعی با یک تصمیم به پایان می‌رسد: یا مدل را گرم نگه دارید چون تأخیر مهم است، یا آن را به API منتقل کنید چون بهره‌وری پایین است، یا ترافیک را تجمیع کنید چون مدل‌های زیادی کار کمی انجام می‌دهند. فاکتور GPU شما مشکل مدل نیست، بلکه داستان بهره‌وری است که با برچسب‌های Kubernetes روایت می‌شود.
گام بعدی شما
- بررسی کنید آیا در خوشه‌ی Kubernetes خود تفکیک بین Request و Limit برای GPUها را به درستی تعریف کرده‌اید.
- اگر از vLLM استفاده می‌کنید، معیارهای مصرفی آن را به یک ابزار مانیتورینگ هزینه مانند OpenCost متصل کنید.
- لیستی از مدل‌های «گرم» در محیط Staging تهیه کنید و آن‌هایی که در ۲۴ ساعت گذشته ترافیکی نداشته‌اند را حذف کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو