YuE2 برای کنترلپذیرتر کردن تولید موسیقی راه متفاوتی را انتخاب کرده است: پیش از ساخت صوت، میتواند یک پارتیتور نمادین تولید کند که قابل مشاهده و ویرایش است.
گروه Multimodal Art Projection یا M·A·P وزنهای YuE2-3B و بسته اجرای آن را در Hugging Face منتشر کرده و همزمان وبسایت پروژه، نمونههای شنیداری و ارزیابی WildSongBench را در دسترس گذاشته است. مدل از روی متن ترانه و توصیف سبک، قطعهای کامل با آواز و همراهی سازها میسازد؛ اما ویژگی متمایز آن مرحله میانی است. در حالت پیشفرض، YuE2 ابتدا ملودی و آکوردها را به شکل پارتیتور ABC طرحریزی میکند و بعد سراغ توکنهای موسیقایی، نمایش صوتی فشرده و در نهایت صدای استریوی ۴۸ کیلوهرتز میرود.
در نتیجه پارتیتور فقط بخشی پنهان از فرایند مدل نیست؛ به یک سطح کنترل تبدیل میشود. کاربر یا یک عامل نرمافزاری میتواند ملودی و هارمونی را ببیند، تغییر دهد، برای ساخت کاور فقط ملودی را نگه دارد یا نسخه ویرایششده را دوباره به مدل بدهد.
پارتیتور، رابط کنترل مدل است
هسته YuE2 حدود ۳٫۵۹ میلیارد پارامتر دارد و از معماری ترکیبی AR–NAR Mixture-of-Transformers استفاده میکند. همین هسته هم برنامهریزی نمادین و هم تولید نمایش معنایی موسیقی را انجام میدهد. سپس مرحله flow matching نمایش صوتی را میسازد و یک VAE آن را به صدا تبدیل میکند.
برای سازندگان ابزار، نکته مهم اندازه مدل نیست؛ جدا شدن طراحی موسیقی از رندر صوتی است.
YuE2 سه حالت اصلی دارد. در حالت full ملودی و آکوردها از قبل طرحریزی میشوند. حالت melody فقط ملودی را نگه میدارد و سازندگان پروژه آن را برای کاور پیشنهاد میکنند. حالت off هم مرحله پارتیتور نمادین را کنار میگذارد. افزون بر این، رابط برنامهنویسی اجازه میدهد فقط طرح اولیه تولید شود؛ یعنی برنامه میتواند پارتیتور را بگیرد، بررسی یا اصلاح کند و بعد هزینه محاسباتی ساخت صدا را بپردازد.
این جداسازی از نظر مهندسی مهم است. بسیاری از سامانههای متنبهموسیقی عملاً نخستین خروجی قابل استفاده خود را به شکل موج صوتی تحویل میدهند. YuE2 در میانه مسیر یک ساختار استاندارد و قابل دستکاری قرار داده که انسان و نرمافزار میتوانند با ابزارهای معمول روی آن کار کنند.
«ویرایش عاملی» بیشتر یک الگوی ارکستراسیون است
پروژه قابلیتی را هم با عنوان agentic editing نمایش میدهد. در نمونه منتشرشده، یک عامل پارتیتور فعلی، توصیف سبک، متن ترانه و درخواست کاربر را میگیرد، آنها را اصلاح میکند و از YuE2 میخواهد نسخه بعدی را رندر کند. نمونه نمایشی یک قطعه را در ۹ مرحله و ۱۴ نسخه دنبال میکند.
اینجا باید مرز قابلیتها روشن بماند. YuE2 بهتنهایی یک تهیهکننده خودمختار نیست که گفتوگو را بفهمد و فایل صوتی را از ابتدا تا انتها ویرایش کند. تفسیر درخواست و تصمیم درباره تغییرات را عامل بیرونی انجام میدهد؛ YuE2 زیرساخت تولید پارتیتور و صدا را فراهم میکند.
با این حال همین تفکیک ارزشمند است. یک عامل متنی میتواند درباره متن و نتنویسی ABC بسیار دقیقتر از یک فایل صوتی طولانی استدلال کند. پارتیتور همچنین وضعیتی قابل بازرسی ایجاد میکند که میتوان آن را نسخهبندی، مقایسه و محدود کرد.
برای تیمهای محصول، شاید نکته مهمتر همین باشد: وجود یک نمایش میانی ساختیافته میتواند کنترل رسانه مولد را بسیار بهتر از مسیر مستقیم «پرامپت به خروجی» کند.
عدد benchmark را باید با احتیاط خواند
M·A·P گزارش میکند که نسخه best-of-8 مدل در WildSongBench به امتیاز ۶٫۹۶۳۲ در میانگین SongBench رسیده است. در همان جدول Suno v5 امتیاز ۶٫۸۷۲۱، Suno v6 امتیاز ۶٫۵۵۶۲ و Suno v6 Wild امتیاز ۶٫۴۱۹۵ دارد.
اما از این اعداد نمیتوان نتیجه ساده «YuE2 از Suno بهتر است» گرفت.
خود پروژه تفاوت روش انتخاب خروجیها را صریحاً نوشته است. نسخه best-of-8 هشت خروجی تولید میکند و با ترکیبی از معیارهای Musicality، Q3O و نرخ خطای واجی بهترین را انتخاب میکند. نسخه عادی YuE2 در همان معیار SongBench امتیاز ۶٫۷۳۱۶ دارد. Suno v6 و Suno v6 Wild با دو خروجی و چند بار ارزیابی ASR سنجیده شدهاند و برخی سامانههای تجاری قدیمیتر نیز با پروتکل اولیه خود در جدول ماندهاند.
پس بخشی از عدد برتر best-of-8 ناشی از بودجه بیشتر برای نمونهگیری و انتخاب است. این موضوع نتیجه را بیاعتبار نمیکند، اما معنای آن را محدودتر میکند.
نتیجه محتاطانهتر این است که YuE2 در ارزیابی منتشرشده پروژه، کیفیت رقابتی در تولید قطعه کامل نشان میدهد و در عین حال چیزی ارائه میکند که سامانههای تجاری مقایسهشده به این شکل در اختیار کاربر نمیگذارند: وزنهای قابل دریافت و مسیر تولیدی که از پارتیتور قابلویرایش عبور میکند.
WildSongBench شامل ۱۹۲ درخواست و ۱۷ تنظیم مختلف است. پروژه همچنین نتایج ساخت کاور بدون آموزش مخصوص را روی SHS100K منتشر کرده و جدولها و جزئیات پروتکل ارزیابی را در دسترس گذاشته است. با این همه، این نتایج هنوز متعلق به خود تیم سازندهاند و بازتولید مستقل گستردهای برای آنها منتشر نشده است.
اجرای محلی ممکن است، اما «باز بودن» محدودیت دارد
راهنمای Hugging Face برای Linux، Python 3.10 یا جدیدتر و GPU انویدیا با پشتیبانی BF16 نوشته شده است. پروژه GPU با ۲۴ گیگابایت حافظه را توصیه میکند. در اندازهگیری منتشرشده، یک RTX 4090 قطعهای ۳٫۶ دقیقهای را در حالت برنامهریزی کامل در حدود ۷۱ ثانیه تولید کرده و اوج مصرف VRAM حدود ۱۱٫۱۸ گیبیبایت بوده است.
برای تولید کامل موسیقی، این سطح از سختافزار نسبتاً در دسترس است. اجرای محلی همچنین میتواند برای فرایندهایی که متن منتشرنشده، پارتیتور خصوصی یا مواد دارای حساسیت تجاری دارند جذاب باشد، چون لازم نیست ورودیها به یک سرویس ابری ارسال شوند.
اما واژه «open» را نباید معادل مجوز آزاد تجاری دانست.
وزنهای YuE2 تحت مجوز CC BY-NC 4.0 منتشر شدهاند؛ یعنی استفاده تجاری بدون مجوز اضافی مجاز نیست. این با یک مدل متنباز دارای مجوز permissive یا حتی وزنهای عمومی قابل استفاده تجاری تفاوت اساسی دارد. پروژه همچنین تصریح میکند که کد، فایلهای tokenizer، داراییهای ارزیابی و اجزای ثالث ممکن است مجوزهای جداگانه داشته باشند.
برای پژوهش، استفاده شخصی و آزمایش غیرتجاری، دسترسی به وزنها ارزشمند است. برای یک استارتاپ یا شرکت رسانهای که قصد عرضه محصول دارد، مجوز یک مانع واقعی است نه نکتهای فرعی.
تیم سازنده میگوید داده آموزشی عمدتاً از موسیقی CC0 و داده مصنوعی تشکیل شده و برای YuE2 رقم ۳۴۶ هزار ساعت را اعلام میکند. این شفافیت مفید است، اما همچنان اظهار خود پروژه است و به معنای ممیزی مستقل منشأ همه دادهها نیست.
چرا پارتیتور میتواند مهمتر از رتبه benchmark باشد
مدلهای تولید موسیقی با مشکل ویرایش روبهرو هستند. کاربر ممکن است بگوید «کورس را روشنتر کن» یا «ملودی را نگه دار و هارمونی را عوض کن»، اما اگر سامانه فقط صوت نهایی را بیرون بدهد، برنامه کنترل دقیق و قابل تکرار کمی روی ساختار قطعه دارد.
در YuE2 لایه نمادین مسیر دیگری میسازد. ملودی و آکورد به دارایی قابل مشاهده تبدیل میشوند. کاربر میتواند یک بخش را ثابت نگه دارد و بخش دیگر را تغییر دهد. عامل میتواند به جای تولید دوباره کل آهنگ، تغییر مشخصی در پارتیتور پیشنهاد کند. تاریخچه نسخهها هم میتواند دقیقاً نشان دهد چه چیزی عوض شده است.
البته پارتیتور نمادین همه چیز موسیقی نیست. رنگ صوتی، جملهبندی، میکس، اجرای خواننده و جزئیات تولید در مراحل بعدی شکل میگیرند. طرح موسیقایی خوب میتواند بد رندر شود و صدای خوب هم ممکن است به تصمیمهایی وابسته باشد که در نتنویسی دیده نمیشوند.
با این حال معماری YuE2 نقطهای برای اعمال قید پیش از ساخت صوت ایجاد میکند. از نظر محصول، این ویژگی مهمتر از چند دهم اختلاف در جدول امتیاز است.
الگوی مشابهی در سامانههای مولد دیگر هم دیده میشود: یک مدل یا عامل ابتدا برنامهای ساختیافته میسازد، مدل تخصصی آن را به خروجی پرجزئیات تبدیل میکند و همان لایه میانی جایی میشود که انسان، سیاست و ابزار میتوانند مداخله کنند.
YuE2 این الگو را در موسیقی به شکل ملموسی نشان میدهد.
انتشار فنی مهم، نه جایگزین آماده Suno
YuE2 سه ویژگی را کنار هم قرار داده که کمتر در یک انتشار عمومی دیده میشوند: تولید قطعه کامل، برنامهریزی نمادین قابل ویرایش و اجرای محلی روی یک GPU ردهبالای مصرفی.
انتشار از نظر فنی جدی است و نمونهها را میتوان مستقیماً شنید. مستندات benchmark نیز نکته مثبتی دارد: پروژه تفاوت بودجه انتخاب خروجیها را پنهان نکرده و توضیح داده چرا عدد best-of-8 با همه رقبا کاملاً همشرایط نیست.
همین دقت باید در تیتر هم حفظ شود. نتایج کیفیت هنوز first-party هستند، پروتکلهای انتخاب متفاوتاند، استفاده تجاری از وزنها محدود است و حلقه گفتوگویی ویرایش را یک عامل بیرونی هدایت میکند، نه خود YuE2.
پس تحول اصلی این نیست که «مدل باز Suno را شکست داده». تحول مهمتر این است که یک مولد موسیقی با وزنهای عمومی، خودِ ساختار آهنگ را به وضعیت میانی قابل ویرایش تبدیل کرده است.
برای ساخت ابزارهای خلاقانه جدی، این قابلیت میتواند بسیار مهمتر از بردن یک جدول امتیاز باشد.