یک باگ مخفی در کتابخانه Transformers تقریباً دو ماه در شاخه اصلی (main) باقی ماند تا اینکه یک مدل کوچک آزمایشی آن را شناسایی کرد. حالا تیم Hugging Face با معرفی Model Integration Contracts یا MIC، راه‌حلی سیستماتیک برای جلوگیری از تکرار چنین اتفاقاتی ارائه داده است.
چطور باگها به main می‌رسند؟
کتابخانه Transformers از بیش از ۷۵۰ نوع مدل پشتیبانی میکند. مجموعه تست آن بسیار بزرگ است: بیش از ۸۸ هزار تست روی CPU در شاخه اصلی، به علاوه بیش از ۲۰۰ هزار تست GPU که روزانه اجرا می‌شوند. تست مدلها فقط بخشی از این مجموعه است و مواردی مانند پایپلاین‌ها، آموزش، اجرای توزیع‌شده، کوانتیزیشن و کرنل‌های توجه را نیز شامل میشود.
تستهای یکپارچهسازی، چک‌پوینت‌های واقعی را بارگذاری کرده و API مدل را روی سخت‌افزار واقعی آزمایش می‌کنند. اجرای همه این تست‌ها روی هر درخواست ادغام (PR) عملاً غیرممکن است، زیرا به تعداد زیادی GPU نیاز دارد. در نتیجه، ممکن است یک رگرسیون توسط اجراهای زمان‌بندی‌شده شناسایی شود، اما تا آن زمان уже در شاخه اصلی قرار گرفته باشد.
راه‌حل: کوچک‌سازی مدل
رویکرد Hugging Face کوچک‌کردن مدل برای تست است. آنها یک «فیکسچر» می‌سازند: یک مدل کوچک که از پیکربندی چک‌پوینت واقعی ساخته شده، با لایه‌های کمتر و باریک‌تر، اما شامل هر نوع لایه‌ای که مدل اصلی دارد. توکنایزر و فایل‌های پردازشگر بدون تغییر باقی می‌مانند.
این فیکسچر یک بار منتشر شده و سپس مجدداً استفاده میشود. تستهای «یکپارچهسازی سریع» روی آن و روی یک رانر ارزان CPU اجرا می‌شوند. به عنوان مثال، در مطالعه موردی UMT5، فیکسچر آزمایشی تنها از ۶۶ مگابایت وزن استفاده کرد، در حالی که چک‌پوینت اصلی ۱۲۲۷ مگابایت حجم داشت.
این روش برای مدل‌های بسیار بزرگ نیز کاربرد دارد. برخی از این مدلها روی رانرهای استاندارد GPU جا نمی‌شوند، اما فیکسچرهای آنها روی CPU قابل اجرا هستند.
معرفی Model Integration Contracts
transformers-mic یک استاندارد پیشنهادی برای بستهبندی این تست‌ها است. یک Model Integration Contract یا MIC سه بخش اصلی دارد:
- یک فیکسچر: مدل کوچکشده توصیف شده در بالا که یک بار منتشر شده و ثابت می‌ماند.
- یک مسیر استفاده: یک مثال اجرایی مارک‌داون از کاری که کاربران با مدل انجام می‌دهند، مانند تولید متن یا اجرای یک مرحله آموزش.
- خروجیهای پایه: خروجیهای ثبت‌شده هنگام اجرای آن مثال که توسط یک انسان بررسی شده‌اند.
قرارداد برقرار است اگر اجرای مسیر استفاده روی فیکسچر، همچنان خروجیهای پایه را تولید کند. یک قرارداد یک معماری و یک مسیر استفاده را پوشش می‌دهد، نه یک چک‌پوینت منفرد. چک‌پوینت‌های سازگار می‌توانند یک فیکسچر را به اشتراک بگذارند، در حالی که هر کدام نتایج مورد انتظار خود را حفظ می‌کنند.
این قراردادها در مخزن huggingface-mic منتشر می‌شوند.
مثال قرارداد SmolLM
به عنوان مثال، قرارداد SmolLM از روی پرامپت‌هایی مانند «پایتخت فرانسه ... است» متن تولید میکند و شناسه توکن‌های خروجی را با پاسخ ثبت‌شده مقایسه میکند. کد تولید پس از بارگذاری مدل و توکنایزر، به صورت ساده‌شده برای یک پرامپت به این شکل است:
inputs = tokenizer("The capital of France is", return_tensors="pt") outputs = model.generate(**inputs, max_new_tokens=4, do_sample=False) new_tokens = outputs[:, inputs["input_ids"].shape[1]:] print(tokenizer.batch_decode(new_tokens, skip_special_tokens=True))این قرارداد همچنین loss آموزش، محدود بودن گرادیان‌ها و تغییر وزن‌ها پس از یک گام بهینه‌ساز را بررسی میکند.
شناسایی رگرسیون UMT5
تیم Hugging Face قراردادهای منجمد MIC را روی پنج ماه کامیت‌های Transformers بازاجرا کرد. فیکسچر کوچک UMT5 رگرسیون را از زمان معرفی آن در ۳۰ جولای ۲۰۲۶ تا زمان رفع آن در ۲۸ سپتامبر همان سال شناسایی کرد. احتمال‌های log برچسب‌ها از خط پایه بررسیشده حدود ۱.۲۲ و loss آموزش حدود ۰.۲۰ تفاوت داشت.
یک نکته مهم این بود که قرارداد از SDPA (توجه حاصل‌ضرب نقطه‌ای مقیاس‌شده) استفاده می‌کرد که مسیر توجه پیش‌فرض بود. اجرای تنها واریانت توجه eager این باگ را از دست می‌داد. یک فیکسچر فقط در صورتی کمک میکند که از همان کد چک‌پوینت واقعی عبور کند.
چطور مدلها کوچک می‌شوند؟
دستورالعمل اولیه ساده بود: ابعاد را کوچک کنید و لایه‌های کمتری نگه دارید. اما این برای معماری‌های ترکیبی کافی نبود. نگه‌داشتن دو لایه فایده‌ای ندارد اگر هر دو از توجه sliding استفاده کنند و لایه‌های توجه کامل ناپدید شوند.
دستورالعمل فعلی چهار مرحله دارد:
- کوچک‌سازی پیکربندی: از یک چک‌پوینت واقعی شروع کنید و اندازه‌های مخفی، هدهای توجه و عمق را کاهش دهید. انواع مختلف لایه‌ها، از جمله ترکیب‌های توجه sliding و کامل یا لایه‌های dense و MoE را حفظ کنید.
- پیش‌پردازش بدون تغییر: واژگان، توکن‌های ویژه و ابعاد ورودی را حفظ کنید و فایل‌های توکنایزر و پردازشگر را عیناً کپی کنید.
- ساخت و اعتبارسنجی وزن‌ها: وزنهای تصادفی با seed ثابت را امتحان کنید و ورودی‌ها را تغییر دهید تا پاسخ مدل بررسی شود. اگر پاسخ نداد، سعی کنید آن را روی دسته کوچکی از مثال‌های قرارداد آموزش دهید. مدل ذخیره‌شده را دوباره بارگذاری کرده و خروجی‌ها، loss و گرادیان‌ها را از نظر محدود بودن بررسی کنید.
- انجماد و ثبت: وزنهای پذیرفته‌شده را ذخیره کرده و خروجیهای تکرارپذیر را روی یک نسخه شناخته‌شده Transformers اندازه بگیرید. خروجیهای پایه برای هر پلتفرم و دقت پشتیبانی‌شده بررسی شده و سپس یک نسخه ثابت منتشر میشود.
فرمت فایل وزن اصلی نیز حفظ میشود تا کد تبدیل هنگام بارگذاری چک‌پوینت واقعی توسط کاربر تست شود.
ساخت MIC با ایجنت‌ها
ابزار خط فرمان tmic قرارداد را ایجاد کرده و فیکسچر را می‌سازد. برای یک مدل جدید، یک مدل زبانی بزرگ کد استفاده و مانیفست را پیش‌نویس میکند و اجراهای CPU و GPU خروجیهای پایه کاندید را اندازه می‌گیرند. این مدل فقط پیش‌نویس می‌دهد؛ تایید نمی‌کند. تغییر در انتظارات نیاز به بررسی انسانی دارد.
سوالات باز و آینده
تا تاریخ ۱ نوامبر ۲۰۲۶، وظیفه MIC در CI Transformers شکست‌ها را گزارش میکند اما PRها را مسدود نمی‌کند. تصمیم درباره مسدود کردن به عواملی بستگی دارد که هنوز اندازه‌گیری نشده‌اند:
- چند باگ واقعی را روی PRها شناسایی میکند (نه فقط در بازاجراها)؟
- چند بار ما را به دنبال هشدارهای کاذب می‌فرستد؟
- بررسی خروجیهای پایه چقدر زمان می‌برد؟
همچنین مشخص نیست که چند باگ، مانند باگ assisted-decoding در Whisper، فقط با وزنهای واقعی ظاهر می‌شوند یا آیا overfitting (آموزش بیش‌ازحد روی مثال‌های محدود) باگ‌های واقعی‌ای را شناسایی میکند که وزنهای تصادفی از دست می‌دهند.
پوشش هنوز در بین خانواده‌های مدل و APIهایی که مردم استفاده می‌کنند جزئی است. هدف نهایی این است که صفحات مدل اصلی در Hugging Face Hub به MICهای مربوطه پیوند داده شوند تا توسعه‌دهندگان یا ایجنت‌هایی که از یک چک‌پوینت استفاده می‌کنند، بتوانند از یک مثال تست‌شده روی آن چک‌پوینت، محیط آن و خروجیهای مورد انتظارش شروع کنند.
پرسش‌های متداول
Model Integration Contracts چیست؟
یک استاندارد پیشنهادی برای بستهبندی تستهای یکپارچهسازی مدلها در Hugging Face که شامل یک فیکسچر کوچکشده، یک مسیر استفاده نمونه و خروجیهای پایه بررسیشده است.
فیکسچر در MIC چه کمکی میکند؟
فیکسچر یک مدل کوچکشده از کانفیگ اصلی است که روی رانرهای ارزان CPU اجرا میشود و امکان شناسایی رگرسیونها را قبل از مرج شدن در main فراهم میکند.
آیا MIC جایگزین تستهای کامل یکپارچهسازی میشود؟
خیر. MIC تستهای سریعی است که روی PRها اجرا میشود تا باگها زودتر شناسایی شوند، اما تستهای کامل روی GPU و با وزنهای واقعی همچنان ضروری هستند.
منبع: Hugging Face
