به گزارش از وبسایت cncf

صورتحساب‌های GPU شما در حال افزایش است و مدل‌ها میلیاردها توکن تولید می‌کنند 💸. با این حال یک پرسش کلیدی بی‌پاسخ مانده: هر توکن واقعاً چه هزینه‌ای دارد؟ این مسئله نظری نیست؛ تیم‌های پلتفرم اکنون در تلاش برای مدیریت هزینه‌های استنتاج AI هستند اما پیوند بین اعداد زیرساختی و توان عملیاتی رمز برایشان نامشهود باقی مانده است 🤔.

تیم‌ها هزینه‌های زیرساختی را می‌بینند و throughput رمز را دنبال می‌کنند، اما بدون دانستن هزینه واقعی هر مدل و هر توکن که از مصرف منابع حاصل می‌شود، تصمیم‌گیری تبدیل به قمار می‌شود: آیا میزبانی خودی ارزان‌تر از استفاده از SaaS API است؟ کدام مدل در ترافیک شما مقرون‌به‌صرفه‌تر است؟ چه حجمی از کار بودجه AI شما را مصرف می‌کند؟ پاسخ‌ها اغلب وجود ندارند و در نتیجه صورتحساب ماهانه بزرگ و سؤالات جدی درباره ROI پیش می‌آید 🧾.

توجه داشته باشید که Cost ≠ Price: ارائه‌دهندگان SaaS ممکن است برای جذب بازار قیمت‌های پایین‌تر یا برای مدل‌های پریمیوم قیمت‌هایی بالاتر از هزینه تمام‌شده ارائه دهند. وقتی هزینه میزبانی خودتان را با قیمت API مقایسه می‌کنید، این تمایز مهم است. هزینه شرکت برای استنتاج SaaS عبارت است از قیمت ارائه‌دهنده.

برای پر کردن این شکاف، ما OpenCost (پروژه انکوباتور CNCF) را با llm-d (پروژه sandboxing CNCF برای استنتاج LLM توزیع‌شده در Kubernetes) یکپارچه می‌کنیم. این متن نحوه کار یکپارچه‌سازی، معیارهای تولیدشده و کاربرد آن‌ها برای تصمیم‌گیری مبتنی بر داده در تیم‌های پلتفرم را توضیح می‌دهد 🔍.

نکته: کاربران vLLM که از llm-d استفاده نمی‌کنند نیز می‌توانند از این قابلیت بهره ببرند، زیرا معیارهای اصلی محاسبه هزینه‌ها از vLLM استخراج می‌شوند.

در حالی که GPU ها صرفاً پردازنده‌هایی با برچسب قیمت بالاتر نیستند، منطق تخصیص هزینه Kubernetes در OpenCost پیش‌تر هزینه‌های عمومی CPU، RAM و GPU را مدیریت می‌کرد. آنچه کمبود داشت، لایه استنتاج بود: توانایی مرتبط ساختن هزینه‌های زیرساخت با جریان توکنی که از طریق vLLM حرکت می‌کند و ارائه هزینه‌ها به شکلی که برای تصمیم‌گیری پلتفرم معنی‌دار باشد ⚙️.

تخصیص منابع در Kubernetes همیشه چالش کارایی بوده است. درخواست‌های CPU و حافظه بر پایه تخمین تعیین می‌شوند که اغلب به بارهای کاری کم یا ظرفیت بیکار منجر می‌شود. با GPU، هزینه اشتباه یک مرتبه بزرگ‌تر است؛ GPU ای که مدلی را بارگذاری کرده اما در حالت بیکاری است هم هزینه‌بر است چون VRAM را اشغال می‌کند—حتی اگر استنتاجی انجام ندهد. برای مثال مدلی با ترافیک پایین ممکن است 95٪ زمان «گرم اما بیکار» باشد و در عین حال هیچ توکنی تولید نکند. همچنین ضربه‌های KV cache مستقیماً بر هزینه پردازش توکن‌های ورودی تأثیر می‌گذارد و باید اندازه‌گیری شود 🧮.

دو رویکرد هزینه‌ای و دو سؤال متفاوت: بینش اصلی این ادغام این است که دو سؤال بنیادین وجود دارد که تیم پلتفرم باید به هر یک پاسخ دهد و هر سؤال به معیارهای هزینه متفاوتی نیاز دارد.

1) هزینه مبتنی بر تخصیص (per-model allocation): شامل تمام هزینه‌های مرتبط با اجرای یک مدل است؛ از جمله حافظه GPU برای وزن‌ها، محاسبات در طول استنتاج فعال و سهمی از اجزای زیرساخت مشترک مانند gateway و KV cache. این رقم مربوط به در دسترس‌بودن مدل است و با صورت‌حساب زیرساخت شما مطابقت دارد: «این مدل برای ما چه هزینه‌ای دارد؟»

2) هزینه مبتنی بر استفاده (per-model usage): فقط هزینه‌های GPU و سایر زیرساخت‌های مصرف‌شده در طول استنتاج فعال را شامل می‌شود. این هزینه‌ها را به توکن‌هایی که واقعاً پردازش شده‌اند نسبت می‌دهد و تأثیر بازدیدهای KV cache را محاسبه می‌کند. این پاسخ می‌دهد: «هزینه واقعی اجرای این مدل چقدر بوده است؟»

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

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

رابطه بین این دو معیار به سادگی استفاده GPU را نشان می‌دهد: Utilization = cost_based_on_usage_per_million / cost_based_on_allocation_per_million

مثال: مبتنی بر استفاده: $1.00 / million tokens (فقط محاسبه) مبتنی بر تخصیص: $4.00 / million tokens اگر بهره‌برداری 25٪ باشد، هزینه واقعی میزبانی خودتان $4.00 به ازای هر میلیون توکن خواهد بود، نه $1.00. بنابراین مقایسه صحیح باید هزینه مبتنی بر تخصیص را با قیمت API خارجی مقایسه کند؛ میزبانی خودی زمانی مقرون‌به‌صرفه می‌شود که بهره‌برداری کافی بالا رود (مثلاً بیش از ~50٪ در این سناریو) 📈.

این چارچوب هدف روشنی برای بهینه‌سازی ارائه می‌دهد: با افزایش استفاده از طریق مسیریابی هوشمندتر، به اشتراک‌گذاری مدل یا تجمیع ترافیک می‌توان هزینه مبتنی بر تخصیص را کاهش داد و میزبانی داخلی را مقرون‌به‌صرفه‌تر کرد.

چه چیزی واقعاً اندازه‌گیری شده است: ادغام از معیارهایی که در یک استقرار llm-d موجودند استفاده می‌کند: throughput توکن از vLLM (مثل vllm:prompt_tokens_total و vllm:generation_tokens_total)، هزینه‌های GPU از موتور تخصیص OpenCost، و معیارهای زمان پردازش برای پشتیبانی از محاسبات هزینه و خروجی‌های تفکیک‌شده.

نتیجه تولید مجموعه‌ای جدید از معیارهای هزینه استنتاج است که برای Prometheus منتشر می‌شوند و از طریق OpenCost REST API قابل دسترسی‌اند. مهم‌ترین آن‌ها عبارتند از llm_total_hourly_cost (هزینه ساعتی به ازای مدل) و llm_cost_per_million_tokens (هزینه ترکیبی به ازای هر میلیون توکن). معیارها شامل برچسب‌هایی مانند name_model، version_model، namespace، cost_basis (usage vs allocation) و workload_type (در حال حاضر همیشه “inference”) هستند.

توکن‌های ورودی و خروجی جداگانه گزارش می‌شوند چون بار محاسباتی متفاوتی دارند: توکن‌های ورودی فاز پیش‌پر را راه‌اندازی می‌کنند و توکن‌های خروجی فاز decode را هدایت می‌کنند. در استقرارهایی که prefill و decode روی سخت‌افزار جداگانه اجرا می‌شوند، این تفکیک برای تخصیص دقیق هزینه ضروری است. همچنین معیارها تأثیر cache hits در KV را بر هزینه پردازش توکن‌های ورودی لحاظ می‌کنند.

فراتر از GPU: هزینه کامل یک مدل باید اجزای پیرامونی llm-d را نیز در بر گیرد، از جمله Inference Scheduler (EPP) که مسیریابی در سطح gateway را انجام می‌دهد (بخش CPU ولی دارای هزینه عملیاتی واقعی)، proxy دروازه llm-d، ذخیره‌سازی KV cache (که در برخی استقرارها می‌تواند تا چندین ترابایت باشد) و یک variable workload autoscaler که از همه InferencePool‌ها مراقبت می‌کند. این هزینه‌های مشترک به عنوان هزینه تخصیص در نظر گرفته می‌شوند اما از هزینه‌های مبتنی بر استفاده مستثنی می‌شوند.

رویکرد SharedLabels موجب می‌شود llm-d و OpenCost به‌خوبی از هم جدا بمانند: اجزای llm-d در زمان استقرار برچسب‌گذاری می‌شوند و منطق توزیع هزینه مشترک OpenCost بدون نیاز به درک معماری داخلی llm-d، تخصیص را مدیریت می‌کند.

نتایج عملی: ماتریس هزینه که ترکیب هزینه تخصیص و هزینه استفاده را نشان می‌دهد، به تیم‌ها کمک می‌کند تا تشخیص دهند آیا مدل برای در دسترس نگه داشتن خیلی گران است، یا استنتاج در خود گران است. تیم‌ها می‌توانند تصمیم بگیرند مدل را به اشتراک بگذارند، ترافیک را یکپارچه کنند، یا اندازه/quantization و تناسب سخت‌افزار را بازبینی کنند. تیم‌های مالی و FinOps می‌توانند با کوئری گرفتن از هزینه‌ها بر اساس namespace و برچسب تیم، گزارش‌های دوره‌ای و برنامه‌های بازپرداخت تولید کنند و مدل‌های کم‌استفاده را شناسایی نمایند. همچنین یک روتر هوشمند می‌تواند از REST API برای تعیین هزینه هر توکن در تصمیمات مسیریابی در کنار latency و throughput استفاده کند 🤝.

این قابلیت از طریق معیارهای Prometheus و OpenCost REST API در دسترس قرار می‌گیرد و کاربران vLLM حتی در صورت عدم استفاده از llm-d نیز می‌توانند از معیارهای استخراجی بهره ببرند. نتیجه، شفافیت بیشتر در هزینه‌های استنتاج و توانایی تصمیم‌گیری مبتنی بر داده برای تیم‌های پلتفرم است ✨.

این ویژگی هم‌اکنون در OpenCost و llm-d قابل استفاده است و می‌تواند به تیم‌ها کمک کند هزینه‌ها را بهتر ردیابی و بهینه‌سازی کنند 📊.