اگر برای اجرای یک مدل ۷۰ میلیارد پارامتری هزینه می‌کنید اما فقط به خلاصه‌سازی متون ساده یا نوشتن اسکریپت‌های ابتدایی پایتون نیاز دارید، احتمالاً هزاران دلار بودجه محاسباتی را دور می‌ریزید. تصور کنید اگر یک مدل ۳۲ میلیارد پارامتری بتواند همان وظیفه را با دقت ۹۵٪ انجام دهد، چه مقدار در هزینه‌ها صرفه‌جویی شود. پیدا کردن کوچک‌ترین مدلی که بدون تخریب جریان کاری تولید (Production Workflow)، پاسخگو باشد، بزرگ‌ترین چالش در فشرده‌سازی مدل‌های زبانی بزرگ (LLM) است.
در ۲۸ سپتامبر ۲۰۲۶، جزئیات یک ارزیاب خودکار برای هرس کردن (Pruning) منتشر شد که به توسعه‌دهندگان اجازه می‌دهد مدل‌های کوچک‌تر Oxlo.ai را در برابر یک مدل مرجع بزرگ (معلم) بسنجند تا بهینه ترین جایگزین را برای هر workload شناسایی کنند. این ابزار حدس و گمان را حذف کرده و یک خط لوله بازتولیدپذیر برای تست فرضیات ایجاد می‌کند. هرس کردن — شبیه حذف شاخه‌های اضافی یک درخت برای تمرکز روی تنه اصلی — یعنی حذف وزن‌ها یا لایه‌های شبکه عصبی برای کوچک کردن مدل، اما افت کیفیت حاصل از این کار معمولاً غیرقابل‌پیش‌بینی است. این رویکرد در راستای تلاش‌های گسترده‌تر این شرکت برای بهره‌وری است، همان‌طور که بهینه‌سازی تنظیمات GPU در گزارشات قبلی Oxlo.ai به عنوان راهکاری برای جلوگیری از اتلاف منابع محاسباتی معرفی شده بود.
همان‌طور که در تحلیل قبلی ما درباره‌ی Cloudflare Workers AI و مجموعه‌ی مدل‌های آن اشاره کردیم، صنعت اکنون به سمت رویکردی جراحی‌گونه در انتخاب مدل حرکت می‌کند؛ جایی که عملکرد به جای بنچمارک‌های کلی، با یک امتیاز کیفیت ملموس سنجیده می‌شود. اگر در حال تحقیق روی هرس ساختاریافته (Structured Pruning) یا تقطیر (Distillation) — که مثل انتقال دانش یک استاد به یک شاگرد در قالب یک مدل کوچک‌تر است — هستید، این ابزار یک معیار عددی برای تصمیم‌گیری به شما می‌دهد.
معماری ارزیابی
این سامانه بر اساس چارچوب معلم-شاگرد عمل می‌کند. یک مدل بزرگ و هرس‌نشده، مانند Llama 3.3 70B، نقش معلم را ایفا کرده و داده مرجع (Ground Truth) را برای هر تکلیف تعیین می‌کند. سپس مدل‌های کاندید که نسبت‌های هرس متفاوتی دارند، در برابر این مرجع تست می‌شوند. در این پیاده‌سازی، مدل‌های qwen-3-32b، kimi-k2.6 و deepseek-v3.2 به عنوان کاندیدها انتخاب شده‌اند.
طبق مستندات این سیستم، ارزیابی روی سه نقطه حساس متمرکز است که هرس معمولاً بیشترین آسیب را به آن‌ها می‌زند:
- استدلال چندمرحله‌ای: بررسی جریان منطقی و توضیحات گام‌به‌گام. برای مثال، یک تکلیف از مدل می‌خواهد معمایی را حل کند: «یک کشاورز ۱۷ گوسفند دارد و همه به جز ۹ تا می‌میرند. چند تا باقی مانده‌اند؟ استدلال خود را گام‌به‌گام توضیح دهید.»
- لبه‌های کدنویسی: اجبار مدل به حل مسائل بدون استفاده از میان‌برهای رایج. ارزیاب به‌طور مشخص یک تابع پایتون را تست می‌کند که باید تکراری‌ها را از یک لیست حذف کند در حالی که ترتیب عناصر حفظ شود و از تابع
set()استفاده نشود. - حفظ زمینه بلند: تست توانایی خلاصه‌سازی متون با محدودیت‌های سخت‌گیرانه. سیستم خلاصه‌ای از متنی را می‌خواهد که هرس ساختاریافته (حذف کانال‌ها یا لایه‌های کامل) و هرس غیرساختاریافته (حذف وزن‌های تک‌به‌تک) را توصیف می‌کند، با این شرط که خلاصه دقیقاً ۲۰ کلمه باشد.
مکانیزم داوری
به جای تکیه بر تطبیق دقیق رشته‌های متنی (Exact String Matching)، این سیستم از یک مدل داور — به‌طور مشخص Qwen 3 32B — برای مقایسه خروجی کاندید با خروجی معلم استفاده می‌کند. انتخاب این مدل به دلیل توانایی‌های استدلال چندزبانه آن در تحلیل تفاوت‌های ظریف است، هرچند هر مدل بزرگ Oxlo.ai می‌تواند در این نقش قرار گیرد.
داور توسط یک پرامپت سیستمی (System Prompt) سخت‌گیرانه هدایت می‌شود تا خروجی را فقط در قالب یک شیء JSON شامل امتیازی بین ۱ تا ۱۰ و دلیل تفصیلی آن برگرداند. در این دستورالعمل صراحتاً ذکر شده: «امتیاز ۱۰ یعنی پاسخ به اندازه مدل مرجع دقیق و کامل است، و امتیاز ۱ یعنی پاسخ غلط است یا اطلاعات حیاتی را گم کرده است.» همچنین داور موظف است فقط و فقط شیء JSON را برگرداند و هرگونه متن اضافی خارج از ساختار JSON ممنوع است.
این امتیازدهی عینی به توسعه‌دهندگان اجازه می‌دهد یک «نقطه قطع هرس» (Pruning Cutoff) تعیین کنند. در این پیاده‌سازی، آستانه روی ۸.۰ تنظیم شده است؛ یعنی هر مدلی که میانگین امتیازی کمتر از این عدد بگیرد، فارغ از اینکه چقدر سریع‌تر یا کوچک‌تر باشد، به عنوان جایگزین غیرقابل‌قبول علامت‌گذاری می‌شود.
جزئیات فنی پیاده‌سازی
این خط لوله با پایتون ۳.۱۰ یا نسخه‌های جدیدتر و SDK شرکت OpenAI ساخته شده و از طریق API شرکت Oxlo.ai با آدرس https://api.oxlo.ai/v1 متصل می‌شود. پیش‌نیازها بسیار اندک هستند: پایتون ۳.۱۰ به بالا، SDK شرکت OpenAI و یک کلید API از پورتال https://portal.oxlo.ai.
فرآیند از شش گام ساختاریافته پیروی می‌کند:
- پیکربندی: راه‌اندازی کلاینت سازگار با OpenAI و تعریف مدل معلم (Llama 3.3 70B) و مدل‌های کاندید (qwen-3-32b, kimi-k2.6, deepseek-v3.2).
- ساخت مجموعه داده: تعریف پرامپت‌هایی که استدلال، کدنویسی و پیروی از دستورات را تحت فشار قرار می‌دهند تا نقاط ضعف ناشی از هرس سریع‌تر شناسایی شوند.
- پرامپت‌نویسی داور: تعیین معیارهای سخت‌گیرانه مبتنی بر JSON برای حفظ عینیت و قابلیت بازتولید فرآیند.
- تولید خط پایه: اجرای تکالیف توسط مدل معلم با دمای (Temperature) ۰.۲ و حداکثر ۵۱۲ توکن، و سپس ذخیره (Cache) نتایج برای جلوگیری از فراخوانی‌های تکراری و هزینه‌های اضافی API.
- جمع‌آوری پاسخ کاندیدها: پرس‌وجو از هر مدل کاندید برای هر تکلیف با همان تنظیمات دما (۰.۲) و محدودیت توکن (۵۱۲).
- امتیازدهی: جفت کردن پاسخ‌های مرجع و کاندید و ارسال آن‌ها به مدل داور که با دمای ۰.۱ و حداکثر ۲۵۶ توکن عمل می‌کند. سیستم شامل منطقی برای مدیریت احتمالی «فنس‌های مارک‌داون» (Markdown Fences) در پاسخ داور است تا پارس کردن JSON با خطا مواجه نشود.
هزینه و بهره‌وری عملیاتی
به گزارش منابع توسعه‌دهنده در dev.to، یکی از مزایای فنی کلیدی این پلتفرم ساختار قیمت‌گذاری آن است. چون Oxlo.ai به جای هر توکن (Token) — تکه‌های کوچکی از متن که مدل می‌خورد — هزینه ثابت به‌ازای هر درخواست (Flat Rate per Request) می‌گیرد، اجرای آزمایش‌های هرس در مقیاس بزرگ با پرامپت‌های دارای زمینه طولانی، هزینه‌ها را به شدت کاهش می‌دهد. این مدل اقتصادی که در تحلیل ما درباره‌ی رویکرد «بدون نگرانی از توکن‌ها» بررسی شد، امکان اجرای مدل‌های گروهی با دقت بالا را فراهم می‌کند. فرقی نمی‌کند زمینه متن ۱۰۰ توکن باشد یا ۱۰,۰۰۰ توکن؛ هزینه یکسان باقی می‌ماند و این امر آزمایش‌های گسترده را عملی می‌کند. جزئیات قیمت‌گذاری در https://oxlo.ai/pricing در دسترس است.
در یک اجرای نمونه، نتایج تفاوت‌های آشکاری را نشان داد:
- Kimi-k2.6 با امتیاز ۹.۰ یک جایگزین ایده‌آل بود. این مدل تطابق کامل در گام‌های استدلال و دقت در تعداد کلمات برای خلاصه‌ها نشان داد.
- Qwen-3-32b با امتیاز ۸.۷ حد نصاب را رد کرد. اگرچه استدلال آن درست و واضح بود، اما اشاره شد که کدنویسی آن از رویکردی کمی کمتر بهینه استفاده کرده است.
- DeepSeek-v3.2 با امتیاز ۷.۳ شکست خورد. دلیل رد شدن این مدل، حذف توضیحات گام‌به‌گام در استدلال و حذف جزئیات هرس ساختاریافته در خلاصه بود که منجر به تولید متنی ۱۹ کلمه‌ای به جای ۲۰ کلمه شد.
گسترش ابزار ارزیابی
توسعه‌دهندگان می‌توانند این چارچوب را با افزودن اندازه‌گیری‌های تأخیر (Latency) برای هر مدل گسترش دهند. این کار اجازه می‌دهد یک «جبهه پارتو» (Pareto Frontier) از دقت در برابر سرعت رسم شود تا موازنه بهینه بین اندازه مدل و عملکرد به‌صورت بصری نقشه‌برداری شود. علاوه بر این، سیستم از تست چک‌پوینت‌های Fine-tune شده که در Oxlo.ai آپلود شده‌اند پشتیبانی می‌کند تا مشخص شود آیا هرس آگاه از کوانتیزاسیون (Quantization-aware Pruning) رفتارهای خاص دامنه (Domain-specific) را حفظ می‌کند یا خیر.
این تغییر رویکرد به سمت ارزیابی خودکار و وظیفه‌محور، شیوه‌ی بنچمارک در این حوزه را تغییر می‌دهد. به جای اعتماد به یک امتیاز کلی MMLU، توسعه‌دهندگان اکنون می‌توانند ثابت کنند که یک مدل هرس‌شده، لبه‌های خاص پروژه آن‌ها را پیش از استقرار در محیط تولید مدیریت می‌کند. برای کسانی که اپلیکیشن‌های AI با ترافیک بالا مدیریت می‌کنند، این به معنای توانایی کاهش تهاجمی اندازه مدل‌ها برای صرفه‌جویی در تأخیر و هزینه، بدون ریسک افت پنهان در کیفیت استدلال است.
گام بعدی شما
- خط لوله ارزیابی را در فایلی به نام
prune_eval.pyذخیره، متغیرOXLO_API_KEYرا اکسپورت و با کلید API خود اجرا کنید. - مجموعه داده‌های اختصاصی پروژه خود را جایگزین تکالیف پیش‌فرض کنید تا نقطه قطع هرس واقعی خود را بیابید.
- تأخیر هر مدل را اندازه‌گیری کرده و آن را با امتیاز کیفیت تطبیق دهید تا ارزان‌ترین مدل ممکن را پیدا کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو