تصور کنید تنها با تغییر مسیرِ چند درخواست ساده، بتوانید ۳۷٪ از هزینه‌های ماهانه مدل‌های زبانی خود را حذف کنید، بدون اینکه کیفیت خروجی ذره‌ای تغییر کند. Frugon که در ۷ جولای ۲۰۲۶ به عنوان یک تحلیلگر هزینهٔ متن‌باز معرفی شد، به توسعه‌دهندگان این امکان را می‌دهد تا با تحلیل لاگ‌های درخواست‌ها مستقیماً روی دستگاه خودشان، بفهمند دقیقاً کجا در صورت‌حساب‌های API نشت هزینه رخ می‌دهد.
بسیاری از تیم‌های هوش مصنوعی در حال حاضر به داشبورد ارائه‌دهندگان تکیه می‌کنند؛ داشبورد‌هایی که فقط می‌گویند «چقدر هزینه شده»، اما نمی‌گویند «چطور کمتر هزینه کنید». در پوشش پیشین ما از مدل‌های با وزن‌های باز، دیدیم که حذف وابستگی به یک فروشنده گام نخست است؛ اما چالش اصلی این است که بدانیم کدام فراخوانی‌های خاص برای یک مدل گران‌قیمت بیش از حد ساده هستند و استفاده از مدل Premium برای آن‌هاK overkill است. Frugon این شکاف را با تبدیل بهینه‌سازی هزینه به یک مسئلهٔ داده‌ای محلی پر می‌کند، به جای اینکه آن را به یک تکلیف پیکربندی ابری بسپارد.
مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در حال حاضر هزینه‌های استنتاج بالایی دارد. استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی است نه دوره‌ی آموزش آشپز — دقیقاً جایی است که هزینه‌ها انباشته می‌شوند.
سازوکار ثبت و تحلیل داده‌ها
به نقل از مستندات این پروژه در گیت‌هاب، کاربران می‌توانند فایل‌های JSONL را با فرمت درخواست/پاسخ OpenAI به ابزار تحویل دهند. برای تولید این لاگ‌ها دو راه اصلی وجود دارد:
- پراکسی شیم (Proxy Shim): دستور
frugon captureیک پراکسی HTTP محلی می‌سازد که بین اپلیکیشن و ارائه‌دهنده قرار می‌گیرد. با تغییر URL پایه اپلیکیشن به این شیم (پورت پیش‌فرض ۸۷۸۷)، هر فراخوانی بدون تغییر به ارائه‌دهنده واقعی ارسال شده و به صورت یک خط در فایل JSONL ذخیره می‌شود. این شیم هیچ تأخیری (Latency) در لوکال‌هاست ایجاد نمی‌کند و به طور پیش‌فرض تنظیمات HTTP_PROXY/HTTPS_PROXY محیطی را نادیده می‌گیرد تا اطمینان حاصل شود که کلیدهای API هرگز از پراکسی‌های شخص ثالث عبور نمی‌کنند. در این راستا، رعایت امنیت در لایه‌های واسط حیاتی است، چرا که برخی روترهای هوش مصنوعی پیش از این با نشت داده‌های حساس مورد انتقاد قرار گرفته‌اند. - ثبت مستقیم: توسعه‌دهندگانی که از قبل لاگ‌ها را از طریق میان‌افزار (Middleware) یا کال‌بک‌های SDK ارائه‌دهنده ضبط می‌کنند، می‌توانند اشیای JSON را بنویسند. ساختار مورد نیاز شامل فیلد
modelاست و استفاده ازusage.prompt_tokens،usage.completion_tokensو یکtimestamp(برچسب زمانی) توصیه می‌شود تا Frugon بتواند هزینه‌ها را بر اساس یک بازه زمانی واقعی مشاهده شده پیش‌بینی کند.
پس از جمع‌آوری داده‌ها، دستور frugon analyze آن‌ها را به‌صورت محلی پردازش می‌کند. این ابزار از یک توکن‌ساز داخلی و یک فهرست قیمت‌های همگام‌شده استفاده می‌کند که آخرین به‌روزرسانی آن در ۲ جولای ۲۰۲۶ از ریجستری LiteLLM بوده است. این سازوکار تضمین می‌کند که هزینه‌ها بدون ارسال حتی یک بایت داده به سرورهای خارجی محاسبه شوند.
جزئیات پیاده‌سازی
Frugon به عنوان یک ابزار کوچک و متمرکز با ۶ دستور اصلی طراحی شده است: analyze ،capture ،models ،update ،pricing و quality. این ابزار تعمداً از تبدیل شدن به یک گیت‌وی (Gateway)، رابط کاربری وب یا سامانه مدیریت حساب‌های چندکاربره (Multi-tenant) پرهیز کرده است تا روی هدف اصلی خود متمرکز بماند.
- نصب: کاربران می‌توانند یک تحلیل یک‌باره را با دستور
uvx frugon analyze ./logs.jsonlاجرا کنند یا برای استفاده دائمی، آن را از طریقpipx install frugonنصب نمایند. - جریان اجرا: یک مسیر ۵ دقیقه‌ای معمولی شامل این مراحل است: نصب ابزار، اجرای دستور
frugon capture --out ./logs.jsonl &در پس‌زمینه، اجرای اپلیکیشن برای تولید فراخوانی‌ها و در نهایت اجرایfrugon analyze ./logs.jsonlبرای مشاهده تفکیک دقیق هزینه‌ها. - تنظیمات پیشرفته: کاربران پیشرفته می‌توانند از پرچم
--upstreamبرای بازنویسی هدف ارسال درخواست‌ها و یا از--verboseبرای چاپ هر خط فراخوانی ثبت شده (جهت تأیید صحت ضبط) استفاده کنند.
مسیریابی مدل و کنترل کیفیت
Frugon فراتر از شمارش توکن (Token) — تکه‌های کوچکی از متن، شبیه برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — عمل می‌کند. این ابزار بر اساس مجموعه‌ای منتخب از برترین مدل‌ها در رتبه‌بندی‌های مصرفی OpenRouter، توصیه‌های مسیریابی می‌دهد. طبق گزارش یک دموی bundled شامل ۵۶,۱۰۰ فراخوانی، Frugon شناسایی کرد که ۶۴.۴٪ از درخواست‌های «ساده» می‌توانستند از gpt-5.5 به deepseek-v4-flash منتقل شوند. این جابجایی، هزینه ماهانه را از ۵۴۹.۴۶ دلار به ۳۴۳.۹۱ دلار کاهش می‌دهد که معادل ۳۷.۴٪ صرفه‌جویی است.
برای جلوگیری از افت کیفیت، ابزار یک تقسیم‌بندی حفاظتی را پیاده می‌کند:
۱. درخواست‌های ساده (Easy Calls): به مدل کاندید ارزان‌تر مسیریابی می‌شوند.
۲. درخواست‌های سخت (Hard Calls): روی مدل Baseline ممتاز باقی می‌مانند.
۳. درخواست‌های بهینه (Optimal Calls): روی مدل‌هایی که در حال حاضر هم مقرون‌به‌صرفه هستند حفظ می‌شوند.
این رویکرد یادآور سه رکن حیاتی برای جلوگیری از افت کیفیت در محیط‌های عملیاتی است که توازن میان هزینه و دقت را هدف قرار می‌دهند. در دمو مذکور، این حسابرسی به صورت ۳۶,۱۰۰ فراخوانی مسیریابی شده + ۱۰,۰۰۰ مورد حفظ شده روی gpt-5.5 + ۱۰,۰۰۰ مورد که از قبل روی deepseek-v4-flash بودند، دیده می‌شود. ابزار این‌ها را بر اساس لایه‌های کیفی طبقه‌بندی می‌کند؛ مثلاً انتقال از سطح «Elite» (مانند gpt-5.5) به سطح «Strong» (مانند deepseek-v4-flash) بر اساس داده‌های LMArena. برای مدل‌های استدلالی، این لایه‌ها بازتاب‌دهنده «تلاش پیش‌فرض» (Typical effort) هستند، زیرا توکن‌های استدلالی حجم فراخوانی را تغییر می‌دهند اما نرخ هر توکن را تغییر نمی‌دهند.
اگر کاربر بخواهد این تخمین‌ها را 검증 کند، پرچم اختیاری --measure (که نیازمند pip install 'frugon[measure]' است) اجازه می‌دهد نمونه‌ای از ترافیک واقعی را از طریق مدل‌های کاندید با استفاده از کلیدهای API خود کاربر ارسال کند. این کار تضمین می‌کند که تخمین «در محدوده تلورانس» (که یک تخمین آفلاین است) پیش از commit نهایی توسعه‌دهنده به تغییر مدل، با خروجی‌های واقعی اعتبارسنجی شود. برای ارزیابی دقیق‌تر کیفیت، کاربران می‌توانند --measure --judge را اجرا کنند تا به هر کاندید امتیاز داده شود.
عملکرد و همکاری تیمی
سرعت پردازش در Frugon بسیار بالاست. دمو با ۵۶,۱۰۰ درخواست در عرض چند ثانیه قیمت‌گذاری شد. این ابزار در حجم بالای ۱۰۰,۰۰۰ رکورد نیز عملکرد راحتی دارد. برای لاگ‌های بسیار حجیم که از ۲۰۰,۰۰۰ رکورد فراتر می‌روند، Frugon یک نوار پیشرفت زنده (Live progress bar) و یک هشدار تک‌خطی نمایش می‌دهد تا کاربر بداند پردازش همچنان در جریان است، زیرا هیچ محدودیت سخت‌گیرانه‌ای برای اندازه لاگ‌ها وجود ندارد.
برای همکاری تیمی، پرچم --report اضافه شده است. این قابلیت اجازه می‌دهد کاربر نام فایلی مانند --report savings.html یا --report savings.md را مشخص کند. این کار یک گزارش تمیز و قابل اشتراک تولید می‌کند که توسعه‌دهندگان می‌توانند آن را به یک Pull Request، یک رشته گفتگو در Slack یا جلسه بررسی بودجه پیوست کنند تا تغییرات معماری در استک هوش مصنوعی را توجیه نمایند.
اقتصاد لایه‌بندی مدل‌ها
منطق Frugon بر پایه پژوهش‌های RouteLLM (LMSYS) است که نشان می‌دهد نوع workload، میزان صرفه‌جویی را تعیین می‌کند. ابزار اعداد را بزرگ‌نمایی نمی‌کند، بلکه ریاضیات خام بر اساس لاگ‌های خاص کاربر را ارائه می‌دهد:
- کارهای ترکیبی عمومی: صرفه‌جویی معمول بین ۳۰ تا ۵۰٪.
- کارهای تکراری و ساده: شباهت بالای MT-Bench می‌تواند منجر به صرفه‌جویی تا ۸۵٪ شود.
- کارهای دشوار استدلالی: حجم‌های کاری با تمرکز بر MMLU عموماً حدود ۳۰٪ صرفه‌جویی ایجاد می‌کنند.
این ابزار به‌ویژه برای گروه‌های زیر حیاتی است:
- سازندگان عامل (Agent): عامل‌های GPT-4o گران هستند؛ اکثر «پرش‌های ساده» (Easy hops) در یک جریان کاری به مدل‌های Elite نیاز ندارند.
- خط‌لوله‌های RAG: در تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — اگرچه بازیابی و رتبه‌بندی (Reranking) ارزان است، اما سنتز نهایی پاسخ همیشه به مدل سطح بالایی مثل Opus نیاز ندارد.
- خط‌لوله‌های ETL: استخراج دسته‌ای (Batch extraction) ۱۰۰٪ تکرارپذیر است و اغلب به طور کامل توسط مدل‌های mini مدیریت می‌شود. به عنوان مثال، اتوماسیون استخراج پاسخ‌ها با ترکیب n8n و Scrapeless نشان می‌دهد که چگونه می‌توان فرآیندهای تکراری را بهینه‌تر کرد.
- هکرهای مستقل (Indie Hackers): هر دلار صرفه‌جویی در API، مستقیماً بازه زمانی بقای مالی (Runway) آن‌ها را افزایش می‌دهد.
با خودکارسازی شناسایی این فراخوانی‌های «ساده»، Frugon هدف مبهم «کاهش هزینه» را به مجموعه‌ای concrete از دستورات مسیریابی تبدیل می‌کند. توسعه‌دهندگان می‌توانند با اجرای frugon models (یا frugon models gpt-4o برای فیلتر کردن) نام مدل‌های کاندید موجود را مشاهده کنند.
این تغییر رویکرد نشان می‌دهد آینده معماری هوش مصنوعی، انتخاب «بهترین» مدل نیست، بلکه ساخت یک کنترل‌کننده ترافیک پیچیده است که هزینه و هوشمندی را در لحظه متعادل کند. توسعه‌دهندگان می‌توانند با اجرای دموی موجود از طریق frugon analyze --demo ممیزی هزینه فعلی خود را آغاز کرده و صرفه‌جویی‌های بالقوه را روی سخت‌افزار خود ببینند.
گام بعدی شما
- اگر از چندین مدل مختلف استفاده می‌کنید، لاگ‌های OpenAI خود را استخراج کرده و با
frugon analyzeمیزان نشت هزینه را بسنجید. - با اجرای دستور
frugon modelsلیست مدل‌های جایگزین و ارزان‌تر را برای هر سطح از پیچیدگی بررسی کنید. - برای توجیه تغییر مدل در تیم فنی، از پرچم
--reportبرای تولید مستندات عددی استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — برای درک اینکه چگونه مدل‌های کوچک در حال بلعیدن مدل‌های بزرگ هستند، به تحلیل ما درباره مدل‌های SLM مراجعه کنید.
گفتگو