«تفکیک دقیق هزینه‌ها»؛ هدف سامانه جدید ردیابی مصرف در GPUStack

تصور کنید ماهانه هزاران دلار هزینه پردازش پرداخت می‌کنید، اما دقیقاً نمی‌دانید کدام مدل یا کدام کاربر در حال بلعیدن بودجه شماست. در ۸ ژوئیه ۲۰۲۶، GPUStack قابلیت جدید Usage را برای پایان دادن به این «جعبه سیاه» در خوشه‌های واحد پردازش گرافیکی (GPU) مشترک منتشر کرد. چون منابع محاسباتی گران هستند و محاسباتی که دیده نمی‌شوند حتی گران‌ترند، این ابزار محیط‌های سنتی و مبهم را به سیستمی قابل ردیابی تبدیل می‌کند که در آن هر واحد مصرف، دقیقاً به یک شخص یا اپلیکیشن خاص نسبت داده می‌شود.

مدیریت خوشه‌هایی که چندین کاربر و مدل‌های وزن‌های باز (Open Weights) — یعنی مدل‌هایی که دستور پخت‌شان علناً منتشر شده و هر کسی می‌تواند آن‌ها را اجرا کند — دارند، معمولاً با یک نقطه کور بحرانی همراه است: معمای «محاسبات کجا رفتند؟». در یک محیط مشترک، بزرگ‌ترین نقطه درد به‌ندرت کمبود مطلق سخت‌افزار است، بلکه ناتوانی در ردیابی دقیق مصرف است. این چالش به‌خوبی نشان می‌دهد که چگونه ضعف زیرساخت‌های توزیع‌شده می‌تواند در برابر بهینگی معماری مدل‌ها منجر به اتلاف منابع شود. مدیران سیستم اغلب برای محاسبه هزینه‌ها یا توجیه درخواست‌های افزایش ظرفیت دچار مشکل می‌شوند، زیرا جزئیات تفکیک‌شده‌ای از مصرف در اختیار ندارند. تیم‌های تجاری ممکن است ظرفیت GPU بیشتری درخواست کنند، اما هیچ‌کس نمی‌تواند به‌وضوح توضیح دهد که میزان بهره‌وری واقعی از منابع موجود چقدر است. GPUStack اکنون با اتصال کامل زنجیره از جمع‌آوری داده‌ها تا تجمیع و بصری‌سازی آن‌ها، تیم‌ها را از حدس و گمان به برنامه‌ریزی ظرفیت بر اساس داده‌های واقعی می‌برد.

ردیابی دقیق منابع

این سامانه داده‌ها را در پنج ستون اصلی سازمان‌دهی می‌کند تا هیچ منبعی بدون نظارت نماند. کاربران می‌توانند با کلیک بر روی آیکون نمودار میله‌ای در نوار پیمایش چپ، به پنج تب در دسترس دسترسی پیدا کنند:

• Summary: یک نمای کلی و جامع از میزان مصرف توکن‌ها، محاسبات و فضای ذخیره‌سازی.
• Tokens: میزان مصرف توکن‌های مدل‌های زبانی بزرگ (LLM)، تفکیک شده بر اساس مدل، کاربر و کلید API.
• GPU Instances: زمان اجرای نمونه‌های GPU و CPU، تفکیک شده بر اساس نوع نمونه، نام نمونه و کاربر.
• Storage: میزان مصرف فضای ذخیره‌سازی، تفکیک شده بر اساس حجم ذخیره‌سازی (Volume) و کاربر.
• Resource Events: گزارش‌های بازرسی (Audit Logs) چرخه حیات منابع که توضیح می‌دهد هر عدد در گزارشات از کجا آمده است.

به نقل از مستندات فنی این ابزار، برای تضمین دقت حداکثری، منابع مختلف در بازه‌ها و با محرک‌های متفاوتی اندازه‌گیری می‌شوند:

• توکن‌ها: به صورت روزانه و هر زمان که یک درخواست استنتاج (Inference) — یعنی همان لحظه تولید جواب توسط مدل — از طریق درگاه (Gateway) ارسال و پاسخ داده شود، اندازه‌گیری می‌شوند.
• نمونه‌های GPU/CPU: به صورت ساعتی، در زمانی که یک نمونه در وضعیت «در حال اجرا (قابل پرداخت)» یا Running (Billable) باشد، محاسبه می‌شوند. به محض اینکه نمونه متوقف یا حذف شود، انباشت مصرف فوراً متوقف می‌گردد.
• ذخیره‌سازی: به صورت ساعتی، از لحظه خلق تا لحظه حذف محاسبه می‌شود؛ فارغ از اینکه حجم ذخیره‌سازی در حال حاضر به سیستم متصل (Mounted) باشد یا مورد استفاده قرار گیرد یا خیر.

در حجم‌های کاری سنگین و محاسباتی، تب GPU Instances تمایزی حیاتی بین دو معیار ایجاد می‌کند که اغلب با هم اشتباه گرفته می‌شوند: «ساعات نمونه» (Instance Hours) و «ساعات GPU» (GPU Hours).

ساعت نمونه (Instance Hour) نماینده زمان واقعی اجرای یک نمونه (Wall-clock runtime) است، بدون توجه به اینکه آن نمونه از چند GPU استفاده می‌کند. اما ساعت GPU (GPU Hour) زمان واقعی اجرای شتاب‌دهنده است که از فرمول زمان اجرا × تعداد GPUها محاسبه می‌شود. برای مثال، یک نمونه با ۲ گرافیک که به مدت یک ساعت اجرا شود، برابر با دو ساعت GPU است، اما تنها یک ساعت نمونه محسوب می‌شود. این تفکیک تضمین می‌کند که مدیران سیستم بار واقعی شتاب‌دهنده‌ها را کمتر از مقدار واقعی تخمین نزنند. لازم به ذکر است که نمونه‌های CPU چون کارت شتاب‌دهنده ندارند، فقط در بخش «ساعت نمونه» شمارش می‌شوند.

ذخیره‌سازی نیز از طریق معیارهای «گیگابایت-روز» (GB-Days) و «گیگابایت-ساعت» (GB-Hours) ردیابی می‌شود که به صورت ظرفیت × مدت زمان تعریف می‌گردد. یک مکانیزم کلیدی در اینجا این است که ذخیره‌سازی از لحظه ایجاد تا حذف اندازه‌گیری می‌شود. این کار از ایجاد «نقاط کور» جلوگیری می‌کند؛ یعنی حجم‌هایی که بدون اتصال (Unmounted) و بیکار هستند اما همچنان بودجه را می‌بلعند، در گزارش‌ها ظاهر می‌شوند. حتی اگر به یک حجم دسترسی داده نشود، تا زمانی که وجود داشته باشد، مصرف آن در GB-Days محاسبه می‌شود.

تخصیص هزینه‌ها به کاربران و اپلیکیشن‌ها

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

• Admin: می‌تواند مصرف تمامی کاربران را مشاهده کرده و از طریق کنترل «فیلتر بر اساس کاربر»، جزئیات هر عضو را بررسی کند. این قابلیت به مدیران اجازه می‌دهد به سوالاتی مانند «چه کسی بیشترین ساعت GPU را مصرف کرده است؟» یا «این کاربر در این ماه چند توکن مصرف کرده است؟» پاسخ دهند.
• User: فقط می‌تواند صورت‌حساب اختصاصی خود را ببیند، شامل توکن‌های مصرف شده در ماه جاری، ساعات GPU اجرا شده و فضای اشغال شده. کاربران عادی به هیچ وجه نمی‌توانند داده‌های سایر کاربران را مشاهده کنند.

این ساختار به کاربران عادی کمک می‌کند تا از میزان مصرف خود آگاه بمانند و آن را با سهمیه‌های (Quotas) تخصیص‌یافته مقایسه کنند تا از مصرف بیش از حد جلوگیری شود. از سوی دیگر، چون جداول جزئیات در هر تب از گروه‌بندی بر اساس کاربر پشتیبانی می‌کنند، مدیران می‌توانند صورت‌حساب‌های دقیقی برای تخصیص هزینه‌ها و برنامه‌ریزی سهمیه‌ها ایجاد کنند.

از آنجا که بسیاری از خطوط لوله تجاری (Business Pipelines) از کلیدهای API اختصاصی استفاده می‌کنند، پلتفرم امکان گروه‌بندی توکن‌ها بر اساس «کلید» را فراهم می‌کند. این کار دیدگاه را از «شخص‌محور» به «اپلیکیشن‌محور» تغییر می‌دهد. در عمل، هر اپلیکیشن متصل یا هر خط لوله تجاری معمولاً از یک کلید API منحصربه‌فرد استفاده می‌کند. با استفاده از تب Tokens برای گروه‌بندی بر اساس API Key، تیم‌ها می‌توانند شناسایی کنند:

• کدام اپلیکیشن یا شریک یکپارچه‌ساز (Integration Partner) به‌طور مداوم در حال مصرف توکن است.
• آیا هزینه یک خط کسب‌وکار خاص به‌طور ناگهانی افزایش یافته است یا خیر.
• کدام کلیدها به‌ندرت استفاده می‌شوند و می‌توان آن‌ها را برای کاهش هزینه‌ها بازپس گرفت.

کارایی مدل‌ها و پاک‌سازی منابع «زامبی»

این ابزار پنجره‌ای مستقیم به عملکرد مدل‌های زبانی بزرگ (LLM)، مدل‌های بردار معنایی (Embedding) و مدل‌های متن‌باز در اندازه‌های مختلف باز می‌کند. در بالای تب توکن‌ها، سیستم معیارهای کلیدی را نمایش می‌دهد: مجموع درخواست‌های API، توکن‌های ورودی/خروجی/کل و تعداد مدل‌های مورد استفاده.

جدول جزئیات در زیر این معیارها می‌تواند بر اساس مدل گروه‌بندی شود تا موارد زیر را نشان دهد:

• توکن‌های ورودی (شامل توکن‌های ورودی کش‌شده که به‌طور مجزا علامت‌گذاری شده‌اند).
• توکن‌های خروجی.
• تعداد کل توکن‌ها.
• تعداد درخواست‌های API.
• آخرین زمان فعالیت (Last active time).

این داده‌ها به مهندسان اجازه می‌دهد شناسایی کنند کدام مدل‌ها بیشترین ترافیک را دریافت می‌کنند و کدام مدل‌ها باید آفلاین شوند یا مقیاس آن‌ها افزایش یابد. به‌ویژه فیلد «Input Tokens Cached» بخشی از توکن‌های ورودی را که به حافظه پنهان (Prompt Cache) برخورد کرده‌اند، علامت می‌زند. پس از اجرای بهینه‌سازی‌های کش، کاربران می‌توانند با بررسی نسبت این عدد، دقیقاً محاسبه کنند که چه مقدار از توکن‌های ورودی ذخیره شده‌اند.

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

برای مبارزه با هزینه‌های هدررفته، GPUStack ستونی به نام «Last Active» را برای مدل‌ها و نمونه‌ها معرفی کرده است. وقتی یک منبع دیگر توکن یا مصرف تولید نکند، برچسب زمانی آخرین فعالیت آن متوقف می‌شود. این ویژگی «منابع زامبی» — مانند مدل‌هایی که دیگر فراخوانی نمی‌شوند یا نمونه‌های متوقف‌شده‌ای که فراموش شده‌اند — را فوراً آشکار می‌کند تا پاک‌سازی هدفمند انجام شود. کاربران می‌توانند در تب Storage بر اساس GB-Days مرتب‌سازی کنند تا بزرگ‌ترین حجم‌ها را شناسایی کرده و قبل از حذف، بررسی کنند که آیا هنوز توسط هیچ نمونه‌ای استفاده می‌شوند یا خیر.

بازرسی چرخه حیات و تحلیل روندها

تب Resource Events داده‌های خام پشت اعداد را در قالب یک خط زمانی (Timeline) که به ترتیب معکوس زمانی مرتب شده است، ارائه می‌دهد. این بخش چرخه کامل حیات هر نمونه و حجم ذخیره‌سازی را با استفاده از برچسب‌های رنگی ثبت می‌کند:

• 🟢 Created (ایجاد منبع)
• 🔵 Started (شروع اندازه‌گیری مصرف)
• 🟠 Stopped (توقف انباشت مصرف)
• 🔴 Deleted (حذف کامل منبع)

این سطح از جزئیات به مدیران اجازه می‌دهد اعداد را تطبیق دهند (Reconcile). اگر مدیری بپرسد چرا یک نمونه تعداد خاصی «ساعت نمونه» دارد، می‌تواند بازه زمانی بین «Started» تا «Stopped» را بررسی کند. این تب همچنین از فیلتر کردن بر اساس تاریخ، نوع منبع، نوع رویداد یا نام پشتیبانی می‌کند تا سریعاً شناسایی شود کدام حجم‌ها در یک هفته خاص حذف شده‌اند یا کدام نمونه‌ها به‌طور مکرر باز و بسته شده‌اند.

در نهایت، پلتفرم نمودارهای روند (Trend Charts) با دانه‌بندی‌های قابل تنظیم (ساعتی، روزانه، هفتگی، ماهیانه) ارائه می‌دهد. این نمودارها به تیم‌ها کمک می‌کنند نقاط عطف رشد را شناسایی کنند — مثلاً اینکه آیا جهش در مصرف با یک عرضه تجاری خاص مطابقت دارد یا خیر — و تعیین کنند که آیا ظرفیت فعلی می‌تواند رشد پیش‌بینی‌‌شده را تحمل کند. نمودارهای روند را می‌توان بر اساس گروه تقسیم کرد تا تغییرات ساختاری در مصرف به‌راحتی شناسایی شوند.

تمامی داده‌ها از طریق آیکون دانلود در تب‌های Tokens، GPU Instances و Storage قابل استخراج هستند. کاربران می‌توانند جزئیات فیلتر شده را پیش‌نمایش کرده و سپس داده‌ها را برای صورت‌حساب‌های ماهیانه، تسویه حساب‌های مالی یا گزارش‌های داخلی دانلود کنند و بدین ترتیب نیاز مهندسان به نوشتن اسکریپت‌های دستی برای استخراج داده‌ها از بین می‌رود.

جزئیات قابلیت اطمینان و پیکربندی

برای تضمین اینکه داده‌ها قابل اعتماد هستند، GPUStack چندین استاندارد بک-اند را پیاده کرده است:

• منطقه زمانی واحد (Unified Time Zone): تمام برچسب‌های زمانی — شامل دسته‌های روند، آخرین فعالیت و زمان رویدادها — از یک منطقه زمانی تجمیعی (Rollup Time zone) استفاده می‌کنند تا مرزهای تقویمی هم‌تراز باشند. این تنظیم به‌طور پیش‌فرض از منطقه زمانی محلی سرور پیروی می‌کند اما از طریق متغیر محیطی GPUSTACK_USAGE_ROLLUP_TIMEZONE قابل پیکربندی است.
• کنترل‌های منعطف: کنترل‌های پیش‌فرض شامل بازه زمانی ۳۰ روزه، امکان تغییر معیار (Metric switching)، گروه‌بندی و تنظیمات دانه‌بندی است.
• حفظ داده‌ها (Data Retention): داده‌های تجمیعی مصرف توکن، محاسبات و ذخیره‌سازی تقریباً به مدت ۱۳ ماه نگهداری می‌شوند و سپس توسط کارهای پس‌زمینه (Background tasks) آرشیو می‌گردند. این بازه زمانی و برنامه زمان‌بندی آرشیو از طریق متغیرهای محیطی GPUSTACK_*_RETENTION_MONTHS و GPUSTACK_*_ARCHIVE_CRON قابل تنظیم هستند.

این تغییر در سطح شفافیت، تمرکز را از «صرفاً داشتن محاسبات کافی» به «بهینه‌سازی بازگشت سرمایه (ROI) برای هر ساعت GPU» منتقل می‌کند. با به نمایش گذاشتن هزینه دقیق مدل‌ها و کاربران خاص، GPUStack سطحی از پاسخگویی و مسئولیت‌پذیری را ایجاد می‌کند که به‌طور معمول نیازمند مهندسی سفارشی و گران‌قیمت است.

کاربران باید به آخرین نسخه GPUStack به‌روزرسانی کرده و صفحه Usage خود را بررسی کنند تا فرصت‌های فوری برای کاهش هزینه‌ها در خوشه‌های فعلی خود شناسایی نمایند.

گام بعدی شما

• به آخرین نسخه GPUStack به‌روزرسانی کنید تا از نشت بودجه در خوشه‌های مشترک جلوگیری کنید.
• ستون «Last Active» را بررسی کنید و مدل‌های بلااستفاده (زامبی) را فوراً حذف نمایید.
• گزارش‌های توکن را بر اساس API Key تحلیل کنید تا نقاط پرهزینه در اپلیکیشن‌های خود را پیدا کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ برای درک رابطه بین بهینه‎‌سازی حافظه و توکن‌های کش‌شده، به تحلیل ما درباره معماری KV Cache مراجعه کنید.