چطور مصرف توکن مدل‌های مختلف را در یک داشبورد واحد ردیابی کنیم؟

اگر از چندین مدل هوش مصنوعی برای توسعه استفاده می‌کنید، احتمالاً هزینه‌های پنهان استنتاج شما به یک نقطه کور تبدیل شده است. در ۸ سپتامبر ۲۰۲۶، یک راهنمای پیاده‌سازی دقیق نشان داد که چگونه می‌توان مصرف توکن (Token) — مثل برش‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — و تأخیر و هزینه‌های دلاری Claude Code، Codex و Ollama را در یک داشبورد Grafana یکپارچه کرد و این کار را از طریق Prometheus به انجام رساند.

بیشتر محیط‌های توسعه از سیستم‌های پرداخت پراکنده رنج می‌برند. در یک محیط آزمایشگاهی معمولی (Homelab)، شما ممکن است سه مدل پرداخت متفاوت را به‌طور هم‌زمان اجرا کنید: دو رابط خط فرمان (CLI) تعاملی که بر اساس اشتراک‌های ثابت کار می‌کنند (جایی که هزینه به صورت درصدی از سهمیه هفتگی اندازه‌گیری می‌شود) و یک عامل (Agent) خودکار که یک API میزبانی‌شده را فراخوانی می‌کند و هزینه را به ازای هر توکن پرداخت می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی مهارت‌های قابل‌اعتماد Claude اشاره کردیم، این رویکرد از مهندسی پرامپت فراتر رفته و بر اقتصاد عملیاتی لایه هوش مصنوعی تمرکز می‌کند.

استراتژی اندازه‌گیری چهارگانه

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

• تله‌متری بومی (Claude Code): این ابزار به‌طور بومی از OpenTelemetry (OTel) پشتیبانی می‌کند. با فعال کردن متغیرهای محیطی خاص شامل CLAUDE_CODE_ENABLE_TELEMETRY=1 ، OTEL_METRICS_EXPORTER=otlp ، OTEL_EXPORTER_OTLP_PROTOCOL=grpc و OTEL_EXPORTER_OTLP_ENDPOINT=http://10.0.0.5:4317 ، این ابزار معیارهای claude_code.token.usage (که به ورودی، خروجی و خوانش حافظه پنهان تقسیم می‌شود)، claude_code.cost.usage بر حسب دلار و claude_code.session.count را صادر می‌کند. از آنجا که Prometheus نمی‌تواند مستقیماً داده‌های OTLP را اسکرپ (Scrape) کند، یک OTel Collector روی میزبان نظارتی (۱۰.۰.۰.۵) روی پورت ۴۳۱۷ گوش می‌دهد و داده‌ها را روی پورت ۸۸۸۹ بازنشر می‌کند.
• دنبال کردن لاگ‌ها (عامل خودکار): برای عامل‌های خودکاری که فاقد صادرکننده‌های بومی هستند، یک اکسپورتر پایتونی با حدود ۲۰۰ خط کد (که فقط از کتابخانه‌های استاندارد استفاده می‌کند)، فایل‌های لاگ را با استفاده از Regex رصد می‌کند. این ابزار ارائه‌دهنده، مدل، تعداد توکن‌ها، تأخیر، نرخ برخورد با حافظه پنهان (Cache Hits) و رویدادهای «فعال شدن جایگزین» (Fallback Activated) را ثبت می‌کند. همچنین، این اکسپورتر پرس‌وجوهای فقط-خواندنی روی پایگاه داده وظایف عامل انجام می‌دهد تا معیارهای عمق صف (Queue-depth) را ارائه دهد؛ این کار به داشبورد اجازه می‌دهد نشان دهد که آیا عامل واقعاً در حال به پایان رساندن کارها است یا فقط در حال سوزاندن توکن‌هاست. این اکسپورتر داده‌ها را روی پورت ۹۱۰۹ در آدرس ۱۰.۰.۰.۷ ارائه می‌دهد.
• کاوش خارجی (Ollama): از آنجا که Ollama (در نسخه‌های ۰.۳۰) نقطه انتهایی Prometheus ندارد، سیستم لاگ‌های request در journald را برای بررسی وضعیت، تأخیر و IP فراخواننده اسکن می‌کند و نقطه انتهایی /api/ps را برای مشاهده مدل‌هایی که در حال حاضر بارگذاری شده‌اند، مورد پرس‌وجو قرار می‌دهد. یک اکسپورتر به ازای هر گره (۱۰.۰.۰.۱ تا ۱۰.۰.۰.۳) روی پورت ۹۱۱۰ اجرا می‌شود. برچسب IP فراخواننده به‌ویژه برای شناسایی اینکه کدام کاربران از مدل‌های محلی استفاده می‌کنند، مفید است.
• درگاه ارسال (Codex): برای سخت‌افزارهای متحرک مانند لپ‌تاپ‌هایی که Codex را اجرا می‌کنند و توکن‌ها و سهمیه‌ها را در فایل‌های نشست (Session files) ثبت می‌کنند، اسکن‌های معمولی غیرقابل‌اعتماد هستند زیرا لپ‌تاپ به حالت خواب (Sleep) می‌رود. یک تایمر systemd کاربر، این فایل‌های نشست را هر پنج دقیقه تحلیل کرده و مجموع کل عمر (Lifetime totals) و درصدهای سهمیه را به یک Prometheus Pushgateway روی پورت ۹۰۹۱ ارسال می‌کند.

پیکربندی عملیات جمع‌آوری

برای یکپارچه‌سازی این منابع، پیکربندی Prometheus به چهار Job اسکرپ مجزا نیاز دارد. Job مربوط به ai_claude_code هدف خود را OTel Collector در 10.0.0.5:8889 قرار می‌دهد، در حالی که Job مربوط به ai_codex هدف خود را Pushgateway در 10.0.0.5:9091 با تنظیم honor_labels: true قرار می‌دهد. Job مربوط به ai_agent به اکسپورتر لاگ در 10.0.0.7:9109 متصل می‌شود و Job مربوط به ai_ollama خوشه سه گره‌ای در آدرس‌های 10.0.0.1:9110 ، 10.0.0.2:9110 و 10.0.0.3:9110 را هدف قرار می‌دهد.

رفع تله‌های دقت در PromQL

به گزارش نویسندگان این راهنما، پیاده‌سازی این پشته نیازمند اجتناب از سه خطای رایج در پرس‌وجوهاست که می‌تواند منجر به داده‌های نادرست شود:

۱. شکاف‌های شمارنده در هر نشست: شمارنده‌های Claude Code زودگذر (Ephemeral) هستند. یک نشست کوتاه ممکن است تنها یک نمونه داده باقی بگذارد که باعث می‌شود تابع increase() هیچ مقداری برنگرداند. برای رفع این مشکل، سیستم آخرین مقدار گزارش‌شده توسط هر نشست را خوانده و آن‌ها را با استفاده از عبارت sum(max_over_time(claude_code_token_usage_tokens_total[1d])) جمع می‌کند.
۲. سقوط هزینه‌های ترکیبی: در PromQL، انجام عملیات ریاضی با یک عملوند خالی باعث می‌شود کل عبارت خالی شود. اگر خوانش‌های حافظه پنهان وجود نداشته باشند، کل هزینه به صورت $0.00 نمایش داده می‌شود. راه حل این است که هر جزء با or vector(0) محافظت شود. برای مثال: (sum(rate(input_tokens[1h])) or vector(0)) * 1.00 / 1e6 + (sum(rate(cache_tokens[1h])) or vector(0)) * 0.10 / 1e6 + (sum(rate(output_tokens[1h])) or vector(0)) * 5.00 / 1e6.
۳. مقادیر NaN در هیستوگرام: تابع histogram_quantile در بازه‌های بیکاری که هیچ مشاهده‌ای وجود ندارد، مقدار NaN برمی‌گرداند. این امر باعث ایجاد خطوط «زباله» در پنل‌های تأخیر می‌شود. با حذف نمونه‌های غیرمتناهی (non-finite)، پنل‌های Grafana در ساعات کم‌کار به‌سادگی خالی می‌مانند که نمایش صادقانه‌تری از فعالیت آزمایشگاه است.

حفاظ‌های حریم خصوصی و زیرساخت

اشتراک‌گذاری عمومی داشبوردهای هوش مصنوعی ریسک امنیتی دارد، زیرا تله‌متری OTel برچسب‌های هویتی — مانند ایمیل، شناسه‌های حساب (Account IDs) و شناسه‌های سازمان — را به هر معیار می‌چسباند. برای اینکه اسکرین‌شات‌ها قابل انتشار باشند، OTel Collector از یک پردازشگر attributes/scrub استفاده می‌کند تا کلیدهایی مانند user.email ، user.account_uuid ، user.account_id ، user.id و organization.id را پیش از رسیدن به Prometheus حذف کند.

برای داده‌های تاریخی که پیش‌تر روی دیسک ذخیره شده‌اند، این راهنما توصیه می‌کند یک پنجره مدیریتی موقت Prometheus را با استفاده از --web.enable-admin-api باز کنید و دو دستور curl را اجرا کنید: یکی برای حذف سری‌های داده‌ای که با {user_email!=""} مطابقت دارند و دیگری برای پاک‌سازی tombstones. در این میان، حفظ برچسب session_id حیاتی است؛ زیرا حذف آن باعث ادغام شمارنده‌های تجمعی شده و منجر به شمارش کمتر از مقدار واقعی (Undercount) در مجموع‌ها می‌شود.

همچنین برای جلوگیری از هشدارهای غیرضروری، پیکربندی نظارتی، Jobهای هوش مصنوعی را از اعلان‌های «Node Down» مستثنی می‌کند. از آنجا که خواب رفتن یک لپ‌تاپ به معنای قطعی زیرساخت نیست، هشدار به‌صورت up{job!~"ai_.*"} == 0 محدود شده است. این کار تضمین می‌کند که از کار افتادن یک اکسپورتر هوش مصنوعی فقط باعث ایجاد یک شکاف در داشبورد شود، در حالی که خرابی‌های واقعی زیرساخت همچنان باعث ارسال هشدار (Page) می‌شوند.

جمع‌بندی اقتصاد هوش مصنوعی

برای کاربر نهایی، حیاتی‌ترین معیار نه مجموع هزینه، بلکه نرخ برخورد (Hit Rate) حافظه پنهان است. در این پیکربندی خاص، نرخ ۷۸ درصدی ورودی‌های کش‌شده باعث می‌شود صورت‌حساب اندازه‌گیری شده در محدوده «قیمت یک فنجان قهوه» باقی بماند. افت این درصد، سیگنالی فوری است که نشان می‌دهد چیزی در نحوه ساخت پرامپت‌ها توسط عامل تغییر کرده است و اجازه می‌دهد اصلاحات در همان صبحی که بهره‌وری کاهش یافته، انجام شود.

این لایه اندازه‌گیری — متشکل از دو اکسپورتر کوچک پایتون، یک Collector، یک Gateway و یک شب از پیکربندی — هوش مصنوعی را از یک هزینه جعبه‌سیاه به یک ابزار قابل مدیریت تبدیل می‌کند.

گام بعدی شما

• بررسی متغیرهای محیطی Claude Code برای فعال‌سازی تله‌متری بومی.
• پیاده‌سازی یک اکسپورتر ساده برای رصد لاگ‌های مدل‌های محلی مانند Ollama.
• تنظیم فیلترهای scrub در OTel Collector برای حذف داده‌های حساس پیش از ذخیره‌سازی.

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