مقایسه برترین LLM های اوپن سورس
🛠 Join @LLMEngineers Community

ااینم مقایسه چنتا از SLM های اوپن سورس (زیر 10b)
🛠 Join @LLMEngineers Community

آقا این مقاله یه Position Paperئه، یعنی اومده یه دیدگاه رو مطرح کنه و بگه آینده این شکلیه. خلاصه حرفش اینه که آینده‌ی ایجنت‌ها دست مدل‌های کوچیک (SLMs) هست، نه این LLMهای غول‌پیکر. استدلالش هم اینه که اکثر کارهایی که یه ایجنت می‌کنه، تکراری و تخصصیه. پس چرا برای یه کار ساده، یه مدل ۱۷۵ میلیاردی رو صدا بزنیم؟ به جاش بیایم برای هر تسک یه SLM متخصص و fine-tune شده بذاریم که هم سریع‌تره، هم ارزون‌تر. برای اون بخش‌هایی هم که نیاز به فکر کردن و استدلال عمیق داره، یه LLM رو به عنوان مغز متفکر یا orchestrator می‌ذاریم که کارها رو به SLMهای کارگر پاس بده. یه معماری heterogeneous.

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

اقتصاد Inference رو درست فهمیدن: اینکه هزینه سرو کردن یه مدل ۷ میلیاردی ۱۰ تا ۳۰ برابر ارزون‌تر از یه مدل ۷۰ میلیاردیه، یه فکت کاملاً تجربه‌شده‌ست. وقتی نیاز به parallel کردن مدل روی کلی GPU نداری، هزینه‌های نگهداری و عملیات (operational cost) به شدت میاد پایین. اینو هرکی یه مدل رو production برده باشه با گوشت و پوستش حس کرده.

زدن تو خال با Behavioral Alignment: این یکی از بهترین نکته‌های فنی مقاله‌ست. توی سیستم‌های ایجنتیک، مدل باید یه خروجی با فرمت دقیق (مثلاً JSON) بده تا tool بعدی کار کنه. هرکی ایجنت واقعی نوشته باشه می‌دونه LLMهای بزرگ گاهی زیادی خلاق می‌شن و فرمت رو یه جوری می‌دن که کل پایپ‌لاین می‌خوابه. یه SLM که فقط برای تولید یه فرمت خاص fine-tune شده، خروجی به شدت قابل اعتمادتر و deterministicتری می‌ده. این یه درد واقعی تو مهندسی ایجنته.

ایده‌ی Data Flywheel درسته: اینکه تعاملات ایجنت بهترین منبع برای جمع‌آوری دیتا و بهبود مدل‌های آینده‌ست، یه استراتژی MLOps کلاسیک و درسته. لاگ‌هایی که از ایجنت جمع می‌شه، بهترین و تمیزترین دیتاست دنیاست برای fine-tune کردن یه SLM متخصص و این یه نکته‌ی کاملاً فنی و قابل دفاعه.

ولی خب، بریم سراغ جاهایی که مقاله زیادی خوش‌بین بوده:

الگوریتم مهاجرتشون یه شوخیه: الگوریتمی که تو بخش ۶ داده، روی کاغذ قشنگه ولی تو دنیای واقعی کابوسه. مرحله Data Curation که میگه داده‌های حساس (PII) رو با "ابزارهای اتوماتیک" پاک کنیم؟ تو محیط enterprise، این کار به شدت پرریسک و گرونه. یه اشتباه کوچیک تو این مرحله کل مدل fine-tune شده رو سمی می‌کنه و می‌تونه یه فاجعه امنیتی به بار بیاره.

پیدا کردن تسک با کلاسترینگ؟ جدی؟ اینکه بشینی با الگوریتم‌های unsupervised کلاسترینگ روی promptها، تسک‌های بیزینس رو پیدا کنی بیشتر شبیه یه پروژه‌ی دانشگاهیه تا کار واقعی. تو دنیای واقعی، تسک رو بیزینس و مدیر محصول تعریف می‌کنه، نه k-means. این بخش از مقاله خیلی از واقعیت دوره.

هزینه کل مالکیت (TCO) رو ندیدن: مقاله فقط روی هزینه‌ی inference زوم کرده، ولی هزینه‌ی کل مالکیت یه معماری با صدها SLM رو کلاً فراموش کرده. مدیریت، مانیتورینگ، آپدیت و ارزیابی این "باغ‌وحش مدل" (model zoo) یه جهنم عملیاتیه. واسه همین خیلی از شرکت‌ها ترجیح می‌دن پول API یه مدل خفن مثل GPT-4o رو بدن ولی سردرد نگهداری صدتا مدل ریز و درشت رو نداشته باشن.

ریسک Edge Caseها رو دست‌کم گرفتن: مهم‌ترین ریسک فنی که مقاله بهش وزن نداده، همین edge caseهاست. اون قدرت استدلال عمومی (general reasoning) توی یه LLM بزرگ، مثل یه safety net عمل می‌کنه. وقتی یه سناریوی پیش‌بینی‌نشده پیش میاد، LLM یه شانس برای هندل کردنش داره. ولی یه SLM که فقط روی تسک خودش ترین شده، وقتی با یه ورودی عجیب و خارج از توزیع (out-of-distribution) روبه‌رو بشه، یه شکست فاجعه‌بار می‌خوره که توی یه سیستم بیزینسی یعنی فاجعه.

به نظر من، جهت‌گیری کلی مقاله درسته؛ آینده‌ی سیستم‌های AI به سمت معماری‌های ترکیبی (heterogeneous) میره. اما این مسیر رو خیلی صاف و ساده و بدون چالش نشون داده. واقعیت اینه که پیاده‌سازی این چشم‌انداز تو مقیاس enterprise پر از چالش‌های مهندسی، MLOps و مدیریتیه که مقاله خیلی راحت از کنارشون گذشته.

🛠 Join @LLMEngineers Community

یه مدل جدید از انویدیا اومده که می‌تونه محاسبات سنگین reasoning رو با context طولانی ۱۲۸ هزار توکنی، روی یه کارت گرافیک با ۲۲ گیگ VRAM اجرا کنه. این یعنی دسترسی‌پذیری بالاتر برای تسک‌هایی که نیاز به "فکر کردن" طولانی دارن، بدون نیاز به سخت‌افزارهای فضایی.

مدل Nemotron-Nano-9B-v2 یه مدل هیبرید Mamba-Transformer هست. معماریش به این صورته که اکثر لایه‌های self-attention با لایه‌های Mamba-2 جایگزین شدن. این کار باعث شده سرعت inference و throughput مدل، مخصوصاً در سناریوهایی با ورودی و خروجی طولانی (مثلاً ورودی ۸ هزار و خروجی ۱۶ هزار توکن)، تا ۶ برابر بیشتر از مدل‌هایی مثل Qwen3-8B بشه، در حالی که دقتش رو هم حفظ کرده.

ساخت این مدل چندتا مرحله‌ی کلیدی داشته که برای ماها هم قابل استفاده‌ست:
اول یه مدل پایه ۱۲ میلیارد پارامتری (12B) روی ۲۰ تریلیون توکن با استفاده از FP8 training recipe آموزش داده شده. دیتاست عظیم و باکیفیتی هم براش ساختن، از جمله یه دیتاست ریاضی جدید به اسم Nemotron-CC-Math که میگن از پایپ‌لاین‌های قبلی خیلی بهتره.

بعد از آموزش اولیه و alignment با تکنیک‌هایی مثل SFT، DPO، GRPO و RLHF، مدل اصلی رو با یه استراتژی هوشمندانه فشرده کردن. از فریمورک Minitron برای pruning استفاده شده. توی این فرآیند، هم لایه‌های کامل (depth) و هم ابعاد FFN و embedding (width) رو هرس کردن تا مدل از ۱۲ میلیارد به ۹ میلیارد پارامتر برسه و توی حافظه‌ی 12 گیگی A10G جا بشه.

برای اینکه افت دقت ناشی از pruning جبران بشه، از knowledge distillation استفاده شده. یعنی مدل ۱۲ میلیاردی به عنوان "معلم"، دانشش رو به مدل ۹ میلیاردیِ "شاگرد" منتقل کرده تا دقتش بازیابی بشه.

یه نکته‌ی جالب دیگه در فاز alignment، استفاده از model merging بوده. دوتا checkpoint مختلف که یکی در reasoning و دیگری در chat قوی‌تر بوده رو با هم ترکیب کردن (interpolation) تا به یه تعادل مناسب بین این دو قابلیت برسن. همچنین یه قابلیت budget control برای "فکر کردن" مدل پیاده‌سازی کردن که به کاربر اجازه می‌ده مشخص کنه مدل قبل از دادن جواب نهایی، چند توکن برای خودش تحلیل بنویسه.

رسما اومدن بهترین تکنیک‌ها رو یاهم ترکیب کردن!

انویدیا هم مدل‌های 9B و 12B-Base و هم بخش بزرگی از دیتاست‌های pre-training و post-training رو به صورت متن‌باز منتشر کرده.

📃 مقاله فنی Nemotron Nano 2

🛠 Join @LLMEngineers Community

مایکروسافت یه مدل Text-to-Speech جدید و open-source به اسم VibeVoice داده که تمرکزش روی حل مشکلات مدل‌های فعلیه. این مدل برای ساختن محتوای صوتی طولانی مثل پادکست و کتاب صوتی که چند نفر توش صحبت می‌کنن، عالیه.

برتری‌ها و ویژگی‌های کلیدیش نسبت به بقیه اینه:

۱. تولید صدای خیلی طولانی: بزرگترین مزیتش اینه که می‌تونه تا ۹۰ دقیقه صدای پیوسته تولید کنه. مدل‌های دیگه معمولاً برای متن‌های کوتاه خوبن و توی محتوای طولانی به مشکل می‌خورن، اما VibeVoice برای یه اپیزود کامل پادکست طراحی شده.

۲. پشتیبانی از چند گوینده: می‌تونه مکالمه بین حداکثر ۴ نفر رو با صدای متفاوت و طبیعی شبیه‌سازی کنه. دیگه لازم نیست صدای هر کس رو جدا بسازی و به هم بچسبونی؛ مدل خودش جریان و نوبت‌دهی صحبت رو مدیریت می‌کنه تا حس یه گفتگوی واقعی رو بده.

۳. کیفیت صدای بالاتر از رقبا: توی مقایسه‌هایی که انجام شده، کیفیت صدای VibeVoice توی معیارهایی مثل "طبیعی بودن" و "غنی بودن حس صدا" از مدل‌های خیلی قوی و تجاری مثل Gemini 2.5 گوگل و ElevenLabs هم بهتر بوده.

۴. کارایی بالا: یه تکنیک هوشمندانه برای فشرده‌سازی صدا داره. این باعث می‌شه بتونه حجم عظیمی از صدا رو با سرعت بالا پردازش کنه بدون اینکه کیفیت خراب بشه. این همون راز تواناییش در تولید محتوای ۹۰ دقیقه‌ایه.

به نظر من، VibeVoice یه ابزار خیلی قدرتمند برای تولیدکننده‌های محتواست. تا امروز ساختن یه پادکست چند نفره‌ی باکیفیت از روی متن، تقریباً غیرممکن یا خیلی پرهزینه بود. این مدل این کار رو به شکل open-source در دسترس قرار داده و می‌تونه استاندارد جدیدی برای محتوای صوتی تولید شده با هوش مصنوعی تعریف کنه.

البته این مدل فعلاً فقط برای کارهای تحقیقاتی منتشر شده و مایکروسافت برای جلوگیری از سوءاستفاده و ساخت deepfake، یه پیام صوتی کوتاه که میگه "این صدا با هوش مصنوعی ساخته شده" و یه واترمارک نامرئی به تمام خروجی‌ها اضافه کرده.

📃 گزارش فنی VibeVoice

💻 صفحه پروژه و کد

🛠 Join @LLMEngineers Community

نکات کلیدی این سری مدل‌ها اینه که روی یک مجموعه داده‌ی بسیار بزرگ و با کیفیت آموزش دیدن. حجم دیتاست به حدود ۶۰ میلیارد توکن رسیده که بخش عمده‌ای از اون به صورت سینتتیک و با تمرکز بر روی reasoning تولید شده.

یکی از ویژگی‌های جالب این مدل، حالت استدلال هیبریدی یا Hybrid Reasoning Mode هست. مدل قبل از ارائه‌ی پاسخ نهایی، فرآیند فکر کردن خودش رو داخل تگ‌های <think>...</think> قرار می‌ده. این باعث می‌شه که بشه مسیر استدلال مدل رو دنبال کرد و همچنین کیفیت پاسخ نهایی در تسک‌های پیچیده بالاتر بره.

در فرآیند آموزش، از تکنیک‌های جالبی استفاده شده:

دیتاست سینتتیک: با استفاده از یک ابزار داخلی به اسم DataForge، دیتاست‌های متنوعی برای آموزش مدل تولید شده.

یادگیری تقویتی: از یک محیط به اسم Atropos برای Rejection Sampling استفاده شده تا مدل در تسک‌های خاصی مثل Schema Adherence (تولید JSON معتبر بر اساس اسکیما) و Tool Use (استفاده از ابزار و فانکشن) به شدت بهینه بشه.

کنترل طول استدلال: یه مشکل رایج در مدل‌های reasoning اینه که ممکنه زنجیره‌ی فکر کردنشون بی‌نهایت طولانی بشه. تیم Nous با یه مرحله فاین‌تیونینگ اضافه، به مدل یاد داده که بعد از حدود ۳۰ هزار توکن، تگ </think> رو ببنده و پاسخ رو تولید کنه. یه راه‌حل مهندسی و عملی برای یه مشکل واقعی.

به نظر من، Hermes 4 یه نمونه‌ی عالی از یک فاین‌تیون مهندسی‌شده و باکیفیته. تمرکز روی کیفیت و تنوع دیتا، به خصوص داده‌های سینتتیک برای قابلیت‌های خاص مثل JSON generation و Tool Use، دقیقا همون چیزیه که یه مدل رو از سطح معمولی به سطح حرفه‌ای می‌رسونه. گزارش فنی شفافی هم ارائه دادن که ارزش کارشون رو دوچندان می‌کنه.

فرمت پرامپت همون Llama 3 Chat هست و برای فعال کردن حالت reasoning، می‌شه از System Prompt خاصی استفاده کرد یا فلگ thinking=True رو در تمپلیت چت قرار داد.
📃 گزارش فنی Hermes 4

🤗 مدل 70B در هاگینگ‌فیس
🤗 مدل 405B در هاگینگ‌فیس

🛠 Join @LLMEngineers Community

گوگل یه مدل تصویر جدید به اسم Gemini 2.5 Flash Image رو منتشر کرده که قبل از معرفی رسمی، با اسم مستعار Nano-Banana توی پلتفرم‌های بنچمارک مثل lmarena تست می‌شد و ترکونده بود.

کاربرد اصلی و نقطه‌ی قوت این مدل، image editing هست. این مدل فقط برای تولید عکس از متن (text-to-image) نیست، بلکه توی ویرایش، دستکاری و in-painting تصاویر موجود، به شکل قابل توجهی بهتر از رقبا عمل می‌کنه. نتایج بنچمارک‌های Artificial Analysis هم همینو نشون میده؛ مدل‌هایی مثل GPT-4o و Qwen-Image-Edit رو با اختلاف زیاد کنار زده و در جایگاه اول قرار گرفته.

دو تا از قابلیت‌های کلیدی که این مدل رو واقعاً متمایز می‌کنه، character consistency و درک عمیق دستورات پیچیده‌ست. یعنی می‌شه یه کاراکتر رو توی صحنه‌ها، لباس‌ها و حالت‌های مختلف با حفظ کامل ظاهر و هویتش ویرایش کرد. این قابلیت برای تولید محتوای داستانی یا هر سناریویی که نیاز به هویت بصری ثابت داره، یه مشکل اساسی رو حل کرده. دیگه نیازی به تکنیک‌های پیچیده‌ی prompt engineering برای حفظ چهره نیست.

عملکرد این مدل توی lmarena هم با اختلاف امتیاز Elo بسیار بالا، رتبه‌ی اول رو تو بخش Image Edit Arena به دست آورده. این اختلاف زیاد نشون می‌ده که عملکردش فقط یه بهبود جزئی نیست، بلکه یه جهش نسلی توی توانایی‌های ویرایش تصویره. استراتژی عرضه‌ی ناشناس این مدل باعث شد کیفیتش بدون تاثیر از برند، توسط کامیونیتی تأیید بشه و یه هایپ ارگانیک شکل بگیره.

به نظر من، Gemini 2.5 Flash Image بازی رو تو حوزه‌ی generative image editing عوض کرده. تمرکز از تولید عکس خام، به سمت یه ورک‌فلوی کامل ویرایشی و تعاملی شیفت پیدا کرده که کنترل خیلی بیشتری به کاربر می‌ده. این مدل الان به صورت رایگان توی اپلیکیشن Gemini و Google AI Studio در دسترسه و API اون هم با قیمت حدوداً ۰.۰۴ دلار برای هر تصویر ارائه شده.

🛠 Join @LLMEngineers Community

یه نفر تجربه ساخت حدود ۳۰۰ ایجنت AI و کار توی ۵ استارتاپ مختلف رو منتشر کرده. نکاتش حاصل کار عملیه، نه تئوری‌های آکادمیک و به درد جامعه مهندسی می‌خوره.

نکته اصلی اینه که ساخت ایجنت، اون چیزی نیست که خیلیا فکر می‌کنن. بیشتر از اینکه یه کار AI/ML باشه، یه تخصص مهندسی نرم‌افزار و بک‌اند به حساب میاد. کسی که پایه‌های مهندسی نرم‌افزار قوی‌ای نداره، تو این حوزه به مشکل می‌خوره. فرمول اصلی خیلی ساده‌ست:
Agent = LLM + Tools + Memory
الگوریتم‌های Reasoning الان دیگه بخشی از خود LLM ها شدن.

یکی از مهم‌ترین یافته‌هاش اینه که ایجنت‌ها بدون ابزار (Tools) تقریباً بی‌فایده‌ان. یه LLM که فقط فکر می‌کنه و به هیچ API یا دیتابیسی وصل نیست، سریع به بن‌بست می‌رسه. قدرت واقعی ایجنت زمانی مشخص میشه که بهش اجازه بدی یه کاری تو دنیای واقعی انجام بده.

برخلاف تصور، چارچوب‌ها و فریمورک‌ها اونقدرام کلیدی نیستن. بعد از کار با crewai, dspy, langgraph, autogen و حتی SDK های خود OpenAI و گوگل، نتیجه‌گیری شده که تمرکز باید روی معماری و پایپ‌لاین اپلیکیشن باشه، نه محدود شدن به یه فریمورک خاص.

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

تجربه نشون داده که موثرترین ایجنت‌ها، ساده‌ترین‌ها بودن: یه پرامپت شفاف، یکی دوتا ابزار مشخص و یه مسئولیت واحد. پیچیدگی زیاد، سیستم رو شکننده می‌کنه. بهترین کاربرد برای ایجنت‌ها، تعریف یک تسک مشخص و اجرای بی‌نقص همونه.

موضوع ارزیابی (Evaluation) هم خیلی دست‌کم گرفته میشه. ساختن یه دموی پر زرق و برق ساده‌ست، اما اندازه‌گیری عملکرد واقعی یه ایجنت تو شرایط مختلف، کار سختیه. همین ارزیابی و گرفتن فیدبک، تفاوت بین یه پروژه اسباب‌بازی و یه سیستم پروداکشن رو مشخص می‌کنه.

به نظرش، DSPy آینده این حوزه است. ساختار Signatures و Optimizers و مخصوصاً متد .compile()ـش خیلی طبیعی و درست به نظر میاد و حس می‌کنیم که ابزارها باید از اول همین‌طوری طراحی می‌شدن.

در نهایت، نتیجه‌گیری اینه که ایجنت‌ها محصول نهایی نیستن، بلکه توانمندساز (enabler) هستن. جادو زمانی اتفاق میفته که ایجنت‌ها در پس‌زمینه یک محصول یا سرویس قرار بگیرن، طوری که کاربر اصلاً متوجه حضورشون نشه و کارها «فقط انجام بشن».

منبع

🛠 Join @LLMEngineers Community

کنترل رفتار Agent های هوش مصنوعی یه چالش بزرگه. مدل‌های زبانی بزرگ (LLMs) ذاتا غیرقطعی (non-deterministic) هستن و همین باعث می‌شه نتونیم بهشون اعتماد کامل کنیم تا یه تسک مشخص رو هر بار دقیقاً مثل قبل انجام بدن. ممکنه وسط کار متوقف بشن، اطلاعات رو جا بندازن یا تصمیمات غیرمنتظره بگیرن.

برای حل این مشکل، یه راهکار عملی، استفاده از ماشین حالت متناهی یا Finite State Machine (FSM) هست که منطق و جریان کار Agent رو خارج از خود LLM تعریف و کنترل می‌کنه. این کار باعث می‌شه رفتار Agent قابل پیش‌بینی و قابل اعتماد بشه.

روش کار به این صورته که کل منطق Agent، حالت‌ها (states)، انتقال‌ها (transitions) و اکشن‌های مربوط به هر حالت، توی یه فایل YAML تعریف می‌شه. این فایل YAML به عنوان "منبع حقیقت" (source of truth) برای رفتار Agent عمل می‌کنه. دیگه محدودیت حجم پرامپت رو نداریم و منطق پیچیده‌تری رو می‌شه پیاده کرد.

نکته کلیدی اینه که در هر مرحله از اجرای FSM، یه اسکریپت پایتون وضعیت فعلی رو از فایل YAML می‌خونه و به LLM میگه دقیقاً چه کاری باید انجام بده. اینطوری، Agent برای فهمیدن اینکه الان کجای پروسه است و مرحله بعد چی هست، به حافظه داخلی و context خودش که ممکنه خطاپذیر باشه، تکیه نمی‌کنه. هر بار وضعیت دقیق از فایل YAML خونده می‌شه. این کار تاثیر "temperature" و حواس‌پرتی‌های احتمالی LLM رو به حداقل می‌رسونه و وفاداری Agent به سناریوی تعریف‌شده رو تضمین می‌کنه.

به نظر من، این روش یه تغییر نگرش مهمه. به جای اینکه سعی کنیم با prompt engineering پیچیده، رفتار LLM رو کنترل کنیم، منطق کنترلی رو به یه سیستم دترمنیستیک خارجی (FSM در YAML) منتقل می‌کنیم و از LLM فقط به عنوان یه موتور پردازش زبان برای انجام تسک‌های مشخص در هر حالت استفاده می‌کنیم. اینطوری، از نقاط قوت هر دو دنیا بهره می‌بریم: قابلیت اطمینان FSM و قدرت پردازش زبان طبیعی LLM.

برای پیاده‌سازی این الگو:
۱. تمام حالت‌های ممکن Agent رو شناسایی و در یک فایل YAML تعریف کنید.
۲. برای هر حالت، اکشن‌ها (دستورالعمل‌هایی که باید به LLM داده بشه) و انتقال‌های ممکن به حالت‌های بعدی رو مشخص کنید.
۳. یک اسکریپت پایتون بنویسید که به عنوان هماهنگ‌کننده (orchestrator) عمل کنه. این اسکریپت در هر مرحله، وضعیت فعلی رو از YAML می‌خونه، دستورات لازم رو به LLM می‌ده و بر اساس خروجی یا ورودی کاربر، به حالت بعدی منتقل می‌شه.

این رویکرد، ساخت Agent های قابل اعتماد برای تسک‌های ترتیبی (sequential tasks) رو به شدت ساده‌تر و عملی‌تر می‌کنه.

📃 Mastering AI Agent Behavior: From LLMs to FSM/YAML

🛠 Join @LLMEngineers Community

یه مدل جدید برای ترجمه از طرف Cohere منتشر شده به اسم Command A Translate.

کاربرد اصلیش اینه که یه مدل تخصصی برای ترجمه با کیفیت بالا در سطح سازمانی ارائه بده. مدل‌های عمومی گاهی تو ترجمه‌های حساس و تخصصی خطا دارن، ولی این مدل مشخصاً برای همین کار post-train شده.

مشخصات فنیش اینه که مدل ۱۱۱ میلیارد پارامتریه و بر پایه‌ی مدل Command A ساخته شده. معماریش همون ترنسفورمر بهینه‌سازی شده‌ست با context length هشت هزارتایی برای ورودی و خروجی. برای ۲۳ زبان از جمله فارسی، عربی، آلمانی و روسی آموزش دیده.

نکته‌ی جالبش یه رویکرد agentic به اسم Deep Translation هست. تو این روش، مدل ترجمه رو تو چند مرحله بازبینی و اصلاح می‌کنه تا خروجی نهایی روان‌تر و طبیعی‌تر باشه. این مکانیزم برای متون پیچیده مثل اسناد حقوقی که دقت بالایی می‌خوان، خیلی کاربردیه.
از لحاظ عملکرد، روی بنچمارک‌های ترجمه مثل WMT24++ نتایج خوبی گرفته و با مدل‌های بزرگ دیگه رقابت می‌کنه.

برای استفاده، مدل با لایسنس غیرتجاری (CC-BY-NC) روی هاگینگ‌فیس برای کارهای تحقیقاتی در دسترسه. نکته‌ی مهم برای دولوپرها اینه که به خاطر معماری بهینه‌ش، می‌شه با کوانتیزیشن ۴-بیت، مدل رو روی یه GPU تکی مثل H100 یا A100 اجرا کرد بدون اینکه افت کیفیت محسوسی داشته باشه. این یعنی برای دیپلوی کردنش نیاز به سخت‌افزار عجیب و غریبی نیست.

به نظر من، عرضه یه مدل بزرگ که فقط روی ترجمه تمرکز کرده، حرکت هوشمندانه‌ایه. به جای اینکه یه مدل همه‌کاره بسازن، روی یه تسک مشخص سرمایه‌گذاری کردن که معمولاً نتیجه‌ی بهتری می‌ده. اون قابلیت Deep Translation هم صرفاً یه ویژگی فانتزی نیست و می‌تونه مشکل کیفیت ترجمه تو موارد خیلی حساس رو واقعاً حل کنه.

🤗 مدل در هاگینگ‌فیس

🛠 Join @LLMEngineers Community

برای ساختن voice agent های حرفه‌ای که واقعاً در محیط production کار کنن، OpenAI مدل و API خودش رو آپدیت کرده. کاربرد اصلیش برای شرکت‌هایی هست که می‌خوان سیستم‌های پشتیبانی مشتری، دستیارهای صوتی هوشمند یا IVR های نسل جدید بسازن که بتونن به تلفن وصل بشن، تصویر ببینن و با ابزارهای دیگه مثل سیستم پرداخت کار کنن.

مدل جدیدی به اسم gpt-realtime معرفی شده که یه مدل speech-to-speech یکپارچه (end-to-end) هست. این یعنی دیگه خبری از زنجیره‌ی مدل‌های Speech-to-Text، بعد LLM و در آخر Text-to-Speech نیست.
یک مدل واحد ورودی صوتی رو می‌گیره و خروجی صوتی تولید می‌کنه. این معماری ذاتاً latency رو پایین میاره و باعث می‌شه لحن و احساسات در مکالمه بهتر حفظ بشه.بهبودهای کلیدی مدل gpt-realtime این‌هاست:ت
وانایی دنبال کردن دستورات (Instruction Following) به شکل قابل توجهی بهتر شده. مثلاً می‌تونه اسکریپت‌های دقیق رو کلمه به کلمه بخونه یا وسط مکالمه بین دو زبان سوییچ کنه.

فراخوانی ابزار (Function Calling) هم دقیق‌تر شده و هم حالا به صورت asynchronous کار می‌کنه. این یعنی ایجنت می‌تونه همزمان با اینکه منتظر جواب یک API هست، به مکالمه با کاربر ادامه بده و مکث نکنه؛ این برای تجربه کاربری در دنیای واقعی حیاتیه.

کیفیت صدای خروجی طبیعی‌تر شده و می‌تونه دستورات مربوط به لحن رو اجرا کنه. مثلاً می‌شه ازش خواست "سریع و حرفه‌ای" صحبت کنه یا "با لحنی همدلانه".
دو صدای جدید به نام‌های Cedar و Marin هم اضافه شده.
درک مطلب و هوش مدل هم بالاتره و می‌تونه نشانه‌های غیرکلامی مثل خنده رو تشخیص بده.

در کنار مدل، Realtime API هم چند قابلیت مهم و کاربردی گرفته:
پشتیبانی از MCP (Media Control Protocol) به صورت remote اضافه شده. با این قابلیت می‌شه ایجنت رو به یک سرور خارجی (مثلاً سرور Stripe) وصل کرد تا ابزارهای جدیدی برای پردازش پرداخت یا کارهای دیگه در اختیارش قرار بگیره، بدون اینکه نیاز به یکپارچه‌سازی دستی و پیچیده باشه.

ورودی تصویر (Image Input) حالا پشتیبانی می‌شه. کاربردش مشخصه؛
ایجنت می‌تونه اسکرین‌شات‌ها رو تحلیل کنه یا در مورد تصاویری که کاربر می‌فرسته، صحبت کنه.

پشتیبانی از SIP (Session Initiation Protocol) یک قابلیت کاملاً enterprise-level هست. این ویژگی اجازه می‌ده ایجنت‌های صوتی مستقیماً به شبکه‌های تلفن عمومی (PBX) و تلفن‌های شرکتی وصل بشن.

این آپدیت‌ها نشون می‌ده که OpenAI بازار enterprise رو خیلی جدی هدف گرفته. قابلیت‌هایی مثل SIP و MCP دقیقاً برای حل مشکلات شرکت‌ها در دنیای واقعی طراحی شدن. حرکت به سمت مدل‌های end-to-end برای صوت، یک تغییر مهم در این حوزه است چون بزرگترین مانع voice agent ها یعنی latency رو تا حد زیادی برطرف می‌کنه.

بهبود در asynchronous function calling هم به تنهایی می‌تونه تجربه کاربری رو متحول کنه، چون ایجنتی که برای هر کار ساده‌ای چند ثانیه سکوت کنه، در عمل قابل استفاده نیست.این API از حالت بتا خارج شده و به صورت عمومی (GA) در دسترسه. قیمت مدل جدید هم ۲۰٪ از نسخه preview کمتر شده که برای پروژه‌های بزرگ خبر خوبیه.

🛠 Join @LLMEngineers Community

یک مدل end-to-end multi-modal به نام Step-Audio 2 Mini با ۸ میلیارد پارامتر منتشر شده. این مدل برای پردازش speech-to-speech طراحی شده و هدف اصلیش درک عمیق صوت و مکالمات هوشمنده.

معماری مدل بر پایه‌ی Multimodal Discrete Token Modelling است که توکن‌های صوتی و متنی رو در یک جریان یکپارچه مدل می‌کنه. این ساختار به مدل اجازه می‌ده استدلال رو به صورت همزمان روی هر دو مودالیته انجام بده. یکی از قابلیت‌های فنی اون، استفاده از RAG چندوجهی در زمان inference هست که بهش اجازه می‌ده با بازیابی زمینه متنی یا صوتی، پاسخ تولید کنه یا حتی استایل صدای خروجی رو بر اساس صدای بازیابی شده تغییر بده.

عملکرد مدل در بنچمارک‌ها به صورت کمی قابل بررسیه.
در بنچمارک StepEval-Audio-Paralinguistic که توانایی درک مشخصات فرازبانی مثل احساسات، سن، جنسیت و لحن رو می‌سنجه، این مدل به امتیاز 80.00 رسیده در حالی که GPT-4o Audio امتیاز 43.45 رو کسب کرده. این نشون‌دهنده تمرکز اصلی مدل روی درک جنبه‌های غیرمتنی صداس.

در بنچمارک MMAU برای درک و استدلال صوتی، مدل Step-Audio 2 (نسخه بزرگتر) با امتیاز 78.0 بالاتر از Gemini 2.5 Pro با امتیاز 71.6 قرار گرفته. نسخه mini هم با امتیاز 73.2 عملکرد رقابتی داره.

در تسک‌های ASR، به خصوص در زبان چینی و لهجه‌های مختلف، بهترین عملکرد رو بین مدل‌های مقایسه شده داره (Average CER: 3.19). در زبان انگلیسی هم با WER: 3.50، نزدیک به بهترین مدل‌هاست.

توانایی Tool Calling مدل هم در بنچمارک داخلی StepEval-Audio-Toolcall ارزیابی شده که برای ساخت ایجنت‌های صوتی یک قابلیت کلیدیه.

به نظر من، ارزش اصلی Step-Audio 2 Mini در ترکیب توانایی درک عمیق paralinguistic با یک لایسنس آزاد مثل Apache 2.0 هست. این مدل یک ابزار تخصصی برای کاربردهاییه که فقط trannoscription کافی نیست و درک لحن و احساسات اهمیت داره.

🤗 مدل در Hugging Face

📃 گزارش فنی و مقاله

💻 کد و جزئیات در GitHub

🛠 Join @LLMEngineers Community

یه مدل جدید MoE به اسم LongCat-Flash-Chat توسط Meituan (همون اسنپ‌فود چین) منتشر شده.

مشخصات اصلی:
▫️ کل پارامترها: 560 میلیارد
▫️ پارامترهای فعال: بین 18.6 تا 31.3 میلیارد (به طور میانگین 27 میلیارد)
▫️ داده آموزش: 20 تریلیون توکن
▫️ سرعت اینفرنس: بالای 100 توکن بر ثانیه

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

🔗 لینک مدل در Hugging Face
💻 دموی آنلاین

🛠 Join @LLMEngineers Community