Wattage: شناسایی نقاط اتلاف توکن در عامل‌های هوش مصنوعی با گیت‌های رگرسیون

یک پیشوند ناکارآمد در پرامپت می‌تواند به‌طور نامحسوس بودجه تولید شما را تخلیه کند. ابزار Wattage که در ۲۶ ژوئیه ۲۰۲۶ منتشر شد، مانند یک «سنجاق‌سنج برق» (Kill-A-Watt meter) برای عامل‌های هوش مصنوعی عمل می‌کند تا توسعه‌دهندگان بتوانند دقیقاً مشخص کنند توکن‌ها کجا هدر می‌روند و این الگوهای اتلافی را به دلار محاسبه کنند.

بسیاری از توسعه‌دهندگان عامل‌ها در حال حاضر بدون دید کافی کار می‌کنند و تنها به داشبوردهای کلی صورت‌حساب تکیه دارند که مجموع هزینه را نشان می‌دهد، اما منطقِ ایجاد آن حلقه‌های هزینه‌زا را فاش نمی‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، با انتقال عامل‌ها از چت‌های ساده به گردش‌کارهای پیچیده و چندمرحله‌ای، ریسک «تلاطم» (Thrashing) — یعنی زمانی که یک عامل بدون پیشرفت واقعی در یک حلقه می‌چرخد — به عامل اصلی هزینه‌های پیش‌بینی‌نشده تبدیل شده است. این چالش‌های هزینه‌ای در محیط‌های ابری با پیچیدگی‌های متفاوتی در محیط‌های محلی همراه است؛ چنان‌که بررسی‌های ما نشان داد اجرای مدل‌های زبانی روی سخت‌افزار شخصی می‌تواند از نظر مصرف انرژی و هزینه، حتی از APIهای ابری نیز گران‌تر تمام شود.

زمینه و معماری

Wattage بر اساس یک مدل داده‌ای نرمال‌شده ساخته شده که اطلاعات را در سلسله‌مراتبی از جلسات (Sessions)، وظایف (Tasks)، حلقه‌ها (Loops)، تکرارها (Iterations) و فراخوانی‌ها (Calls) سازماندهی می‌کند. این مدل داده‌ای از استانداردهای ردیابی OpenTelemetry (OTel) و قراردادهای معنایی GenAI استخراج شده است.

این ابزار برای سرعت و حریم خصوصی طراحی شده و کاملاً آفلاین عمل می‌کند؛ به این معنا که هیچ نیازی به کلیدهای API یا فایل‌های پیکربندی خارجی ندارد. این ابزار خروجی‌های OTLP JSON trace را دریافت کرده و هر فراخوانی را بر اساس یک snapshot قیمت‌گذاری‌شده و تاریخ‌دار (که تا ۱۸ ژوئیه ۲۰۲۶ تأیید شده است) محاسبه می‌کند.

به نقل از مخزن گیت‌هاب faizannraza/wattage، این ابزار هشت شناسگر تخصصی را برای یافتن اتلاف‌ها اجرا می‌کند. این شناسگرها مواردی مثل prefix_churn برای شناسایی بسترهای متنی ثابتی که به‌جای استفاده از حافظه موقت (Cache) دوباره ارسال می‌شوند، یا nonconvergence برای عامل‌هایی که در حلقه‌ها متوقف شده‌اند و پیشرفتی ندارند، و همچنین model_mismatch برای مواردی که مدل‌های گران‌قیمت کارهایی را انجام می‌دهند که یک مدل ارزان‌تر می‌توانست مدیریت کند، را ردیابی می‌کنند.

جزئیات شناسایی اتلاف

در جزئیات فنی، Wattage الگوهای ناکارآمدی را شناسایی کرده و به هر یک یک سطح ریسک کیفی (quality_risk) شامل «بدون ریسک»، «پایین» یا «نیاز به بررسی» اختصاص می‌دهد. یک اصلاحیه که می‌تواند به‌طور پذیرفتنی کیفیت خروجی را تغییر دهد — مانند کاهش سطح مدل (Model Downgrade) — تنها زمانی بر امتیاز کارایی تأثیر می‌گذارد که یک نقشه کیفیت (--quality) شواهد لازم را ارائه دهد.

هشت شناسگر این ابزار بر مکانیزم‌های زیر تمرکز دارند:

• prefix_churn: ارسال مجدد بستر متنی ثابت به‌جای استفاده از حافظه پنهان (Prompt Caching).
• cache_gap: تلاش برای کش کردن که در خوانش‌های بعدی به‌درستی مورد استفاده قرار نمی‌گیرد.
• verbosity: تولید خروجی بسیار بیشتر از آنچه برای آن مرحله خاص لازم است.
• redundant_tool_calls: تکرار فراخوانی یک ابزار، چه به‌صورت دقیق و چه از طریق تطبیق تقریبی (Fuzzy Matching).
• nonconvergence: حلقه‌هایی که تلاطم می‌کنند، نوسان دارند یا بدون پیشرفت واقعی متوقف می‌شوند.
• retrieval_thrash: تلاش‌های مکرر برای بازیابی اطلاعات (Retrieval) که هرگز نتیجه مرتبطی نمی‌دهند.
• model_mismatch: استفاده از یک مدل گران‌تر برای کارهایی که یک مدل ارزان‌تر قادر به انجام آن است.
• reasoning_overspend: هزینه بالای توکن‌های استدلالی (Reasoning Tokens) برای یک مرحله ساده.

بر اساس بنچمارک‌های فنی ارائه شده توسط نویسنده، موتور همگرایی این ابزار (شناسگر nonconvergence) در شناسایی حلقه‌های مصنوعی به امتیاز F1 معادل ۱.۰۰ رسیده است. این یک جهش بزرگ نسبت به روش تطبیق دقیق SHA-256 است که تنها امتیاز ۰.۲۵ کسب کرد؛ زیرا روش‌های سنتی نمی‌توانند الگوهایی مثل تلاش مجدد با برچسب‌های زمانی جدید یا نوسان بین دو استراتژی مختلف را تشخیص دهند. این سطح از تحلیل دقیق، شباهت زیادی به رویکردهای مدرن نظارت دارد؛ برای مثال، استفاده از Llama 3.1 برای تحلیل ریشه‌ای خطاها نشان می‌دهد که چگونه اتوماسیون در تشخیص الگوهای خطا می‌تواند جایگزین داشبوردهای سنتی شود.

در یک مورد واقعی از ردیابی یک عامل، شبیه‌سازی اصلاح prefix_churn منجر به کاهش ۴۴.۷ درصدی هزینه‌ها شد و هزینه یک فراخوانی خاص را از ۰۰۰۱۹۹ دلار به ۰۰۰۱۱۰ دلار کاهش داد، که این امر از طریق فعال‌سازی کشینگ پرامپت روی پیشوند ثابت محقق شد.

یکپارچگی با CI و گیتینگ

فراتر از گزارش‌دهی ساده، این ابزار یک «گیت رگرسیون هزینه» برای CI/CD معرفی می‌کند. تیم‌ها می‌توانند با ثبت یک فایل baseline.json در مخزن خود، تنظیم کنند که اگر یک Pull Request باعث افت امتیاز کارایی توکن (مثلاً به زیر ۸۰) یا افزایش هزینه بیش از ۵٪ شود، بیلد (Build) در GitHub Actions با خطا مواجه شود.

یکپارچگی faizannraza/wattage/[email protected] می‌تواند به‌گونه‌ای پیکربندی شود که در صورت وجود هر مورد بحرانی (any_critical:true) خطا دهد و جدولی از تغییرات (Delta Table) هر شناسگر را در قالب یک کامنت در PR ارسال کند. همچنین این ابزار خروجی‌های SARIF برای تب امنیت گیت‌هاب و JUnit XML برای سایر سامانه‌های CI تولید می‌کند. این تلاش برای کاهش هزینه‌های عملیاتی، با تحولات اخیر در پروتکل‌های ارتباطی هم‌سو است؛ به‌طوری که پروتکل MCP پتانسیل آن را دارد که هزینه‌های تحلیل ریشه‌ای خطاها را به شدت کاهش داده و بهره‌وری عامل‌ها را بالا ببرد.

برای جلوگیری از قدیمی شدن خط مبنا (Baseline)، سیستم یک گردش‌کار دو مرحله‌ای را می‌طلبد: یک Job برای تست در PR و یک گردش‌کار دوم که پس از Push به شاخه پیش‌فرض (Default Branch) فعال شده تا خط مبنای به‌روزرسانی شده و نشان (Badge) فایل README را مجدداً در مخزن ثبت (Commit) کند.

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

برای توسعه‌دهنده، این به معنای پایان عصر «مهندسی پرامپت مبتنی بر امید» است. اکنون می‌توانید ثابت کنید که تغییر در پرامپت پیش از رسیدن به محیط تولید، کارآمدتر است و مطمئن شوید که بهبود کیفیت با هزینه‌های عملیاتی ناپایدار خریده نشده است.

برای شروع بهینه‌سازی، می‌توانید ابزار را از طریق دستور uvx wattage report trace.json اجرا کنید یا با استفاده از فلگ --html یک نمودار Flame Graph قابل اشتراک تولید نمایید. برای کسانی که ردیابی (Trace) ندارند، مخزن پروژه یک مسیر ۵ دقیقه‌ای از ابزارگذاری صفر تا گزارش قیمت‌گذاری شده ارائه می‌دهد، یا می‌توان یک نمونه آماده را از طریق دستور uv run wattage report examples/sample_trace.json اجرا کرد.

گام بعدی شما

• اگر از عامل‌های پیچیده استفاده می‌کنید، خروجی‌های Trace خود را با دستور uvx wattage report trace.json تحلیل کنید.
• برای تجسم بصری نقاط اتلاف، از فلگ --html برای تولید نمودار Flame Graph استفاده کنید.
• یک فایل baseline.json ایجاد کنید تا از رگرسیون هزینه‌ها در هر به‌روزرسانی کد جلوگیری کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.