شیائومی با MiMo-V2-Flash نشون داد که "مهندسی عملگرا" دقیقا یعنی چی. مدل MoE با ۳۰۹ میلیارد پارامتر که فقط ۱۵ میلیاردش فعاله (Active Params)، ولی نکته اصلی سایز مدل نیست؛ شاهکار توی معماری و انتخابهای فنیشون برای بهینهسازیه.
معماری Hybrid Attention اینجا بازی رو عوض کرده. ترکیب Sliding Window Attention (SWA) با Global Attention با نسبت ۵ به ۱. نکته عجیب ماجرا اینه که Window Size رو روی ۱۲۸ بستن و نتیجه گرفتن (حتی بهتر از ۵۱۲). این یعنی ۶ برابر کاهش در مصرف حافظه KV Cache. فقط حواستون باشه، طبق گفته خودشون Attention Sink Bias رو به هیچ وجه نباید حذف کنید، چون برای حفظ کانتکست حیاتیه.
ماژول MTP یا همون Multi-Token Prediction رو هم جداگانه اپنسورس کردن. این ماژول ۳ لایه، سرعت خروجی رو ۳ برابر میکنه و مهمتر از اون، توی آموزش RL زمان بیکاری GPU رو برای نمونههای Long-tail به شدت کاهش میده. یه FFN متراکم سادهست (برعکس خود مدل که MoE هست) ولی تاثیرش توی پروداکشن وحشتناکه.
تکنیک MOPD برای Post-training هم درس بزرگیه. ایده اینه که Knowledge Distillation رو تبدیل کردن به یه فرآیند RL. دانش Teacher رو با هزینه محاسباتی ۱/۵۰ روشهای معمول (مثل SFT+RL) به Student منتقل کردن. عملا یه لوپ Self-reinforcing ساختن که مدل دانشآموز میتونه خودش تبدیل به معلم قویتری بشه.
به نظر من، MiMo-V2 فقط یه مدل زبانی نیست، یه کلاس درس برای کساییه که میخوان Inference ارزان و سریع داشته باشن و درگیر Hype سایز مدل نشن. وقتی ۱۵ میلیارد پارامتر فعال بتونه بنچمارکهای مدلهای ۳۰+ میلیاردی رو بزنه، یعنی معماری درست چیده شده.
📃 گزارش فنی و جزئیات معماری:
https://github.com/XiaomiMiMo/MiMo-V2-Flash/blob/main/paper.pdf
🤗 لینک مدل در هاگینگفیس:
https://huggingface.co/XiaomiMiMo/MiMo-V2-Flash
🛠 Join @LLMEngineers Community
معماری Hybrid Attention اینجا بازی رو عوض کرده. ترکیب Sliding Window Attention (SWA) با Global Attention با نسبت ۵ به ۱. نکته عجیب ماجرا اینه که Window Size رو روی ۱۲۸ بستن و نتیجه گرفتن (حتی بهتر از ۵۱۲). این یعنی ۶ برابر کاهش در مصرف حافظه KV Cache. فقط حواستون باشه، طبق گفته خودشون Attention Sink Bias رو به هیچ وجه نباید حذف کنید، چون برای حفظ کانتکست حیاتیه.
ماژول MTP یا همون Multi-Token Prediction رو هم جداگانه اپنسورس کردن. این ماژول ۳ لایه، سرعت خروجی رو ۳ برابر میکنه و مهمتر از اون، توی آموزش RL زمان بیکاری GPU رو برای نمونههای Long-tail به شدت کاهش میده. یه FFN متراکم سادهست (برعکس خود مدل که MoE هست) ولی تاثیرش توی پروداکشن وحشتناکه.
تکنیک MOPD برای Post-training هم درس بزرگیه. ایده اینه که Knowledge Distillation رو تبدیل کردن به یه فرآیند RL. دانش Teacher رو با هزینه محاسباتی ۱/۵۰ روشهای معمول (مثل SFT+RL) به Student منتقل کردن. عملا یه لوپ Self-reinforcing ساختن که مدل دانشآموز میتونه خودش تبدیل به معلم قویتری بشه.
به نظر من، MiMo-V2 فقط یه مدل زبانی نیست، یه کلاس درس برای کساییه که میخوان Inference ارزان و سریع داشته باشن و درگیر Hype سایز مدل نشن. وقتی ۱۵ میلیارد پارامتر فعال بتونه بنچمارکهای مدلهای ۳۰+ میلیاردی رو بزنه، یعنی معماری درست چیده شده.
📃 گزارش فنی و جزئیات معماری:
https://github.com/XiaomiMiMo/MiMo-V2-Flash/blob/main/paper.pdf
🤗 لینک مدل در هاگینگفیس:
https://huggingface.co/XiaomiMiMo/MiMo-V2-Flash
🛠 Join @LLMEngineers Community
GitHub
MiMo-V2-Flash/paper.pdf at main · XiaomiMiMo/MiMo-V2-Flash
MiMo-V2-Flash: Efficient Reasoning, Coding, and Agentic Foundation Model - XiaomiMiMo/MiMo-V2-Flash
🤏 مدل FunctionGemma: بازگشت به میکروسکوپ!
گوگل یه حرکت خلاف جهت بازار زده و مدل FunctionGemma رو با سایز عجیب ۲۷۰ میلیون پارامتر (270M) منتشر کرده. توی دنیایی که همه دنبال مدلهای ۱۰۰ میلیاردی هستن، این سایز یعنی "تقریبا هیچی". اما اشتباه نکنید، این مدل قرار نیست براتون شعر بگه یا فلسفه ببافه؛ این مدل یه آچار فرانسه تخصصی برای Function Calling روی Edge Device هاست.
معماری این مدل بر پایه Gemma 3 هست ولی برای دیالوگ مستقیم ساخته نشده. هدف اصلی اینه که به عنوان یه لایه واسط (Middleware) بین درخواست کاربر و APIهای سیستم عامل یا اپلیکیشنها قرار بگیره. گوگل ادعا میکنه این مدل رو باید Fine-tune کنید تا قدرت واقعیش رو ببینید.
نکته فنی جذاب ماجرا اینجاست: نسخه Base این مدل روی تسکهای Mobile Actions حدود ۵۸٪ دقت داره، اما وقتی روی دیتای دومینِ خودتون (مثلا کنترلرهای اندروید) Fine-tune میشه، دقتش میپره روی ۸۵٪. این یعنی یه مدل ۲۷۰ میلیونی که روی CPU گوشی سامسونگ S25 Ultra اجرا میشه، میتونه با دقت بالا بفهمه کاربر وقتی میگه "چراغ رو روشن کن"، باید کدوم تابع سیستمی رو با چه پارامترهایی صدا بزنه.
پرفورمنس و کاربرد عملی این مدل:
روی سختافزار محدود مثل گوشی یا Browser اجرا میشه و نیازی به اینترنت نداره (Privacy-first). برای توسعهدهندهها، دیتاسیت Mobile Actions رو هم منتشر کردن که نشون میده چطور میشه دستورات متنی رو به JSON برای اجرا تبدیل کرد. با ابزارهایی مثل Unsloth هم سازگاره و میتونید خیلی سریع روی دیتای خودتون شخصیسازیش کنید و توی LM Studio سرو کنید.
به نظر من، این حرکت گوگل نشوندهنده یه شیفت پارادایم توی معماری Agent هاست. تا الان فکر میکردیم یه مدل گنده (مثل GPT-4) باید همه کارها رو بکنه، اما آینده احتمالا "تیمسازی" از مدلهاست: یه مدل متوسط برای برنامهریزی (Planner) و چندین مدل میکرو مثل FunctionGemma برای اجرای دقیق ابزارها (Executors). اینجوری هم Latency میاد پایین، هم هزینه Inference نزدیک به صفر میشه و هم امنیت داده کاربر حفظ میشه چون لاجیک روی گوشی میمونه.
اگه دارید روی سیستمهای Agentic کار میکنید که نیاز به Tool Use دارن ولی منابع سرور محدود دارید، این مدل رو حتما تست کنید. فقط یادتون باشه، بدون Fine-tune کردن روی Task خودتون، احتمالا خروجی جالبی نمیده.
📃 لینک مدل در هاگینگفیس:
https://huggingface.co/collections/google/functiongemma
📃 دیتاسیت Mobile Actions برای تمرین:
https://huggingface.co/datasets/google/mobile-actions
🛠 Join @LLMEngineers Community
گوگل یه حرکت خلاف جهت بازار زده و مدل FunctionGemma رو با سایز عجیب ۲۷۰ میلیون پارامتر (270M) منتشر کرده. توی دنیایی که همه دنبال مدلهای ۱۰۰ میلیاردی هستن، این سایز یعنی "تقریبا هیچی". اما اشتباه نکنید، این مدل قرار نیست براتون شعر بگه یا فلسفه ببافه؛ این مدل یه آچار فرانسه تخصصی برای Function Calling روی Edge Device هاست.
معماری این مدل بر پایه Gemma 3 هست ولی برای دیالوگ مستقیم ساخته نشده. هدف اصلی اینه که به عنوان یه لایه واسط (Middleware) بین درخواست کاربر و APIهای سیستم عامل یا اپلیکیشنها قرار بگیره. گوگل ادعا میکنه این مدل رو باید Fine-tune کنید تا قدرت واقعیش رو ببینید.
نکته فنی جذاب ماجرا اینجاست: نسخه Base این مدل روی تسکهای Mobile Actions حدود ۵۸٪ دقت داره، اما وقتی روی دیتای دومینِ خودتون (مثلا کنترلرهای اندروید) Fine-tune میشه، دقتش میپره روی ۸۵٪. این یعنی یه مدل ۲۷۰ میلیونی که روی CPU گوشی سامسونگ S25 Ultra اجرا میشه، میتونه با دقت بالا بفهمه کاربر وقتی میگه "چراغ رو روشن کن"، باید کدوم تابع سیستمی رو با چه پارامترهایی صدا بزنه.
پرفورمنس و کاربرد عملی این مدل:
روی سختافزار محدود مثل گوشی یا Browser اجرا میشه و نیازی به اینترنت نداره (Privacy-first). برای توسعهدهندهها، دیتاسیت Mobile Actions رو هم منتشر کردن که نشون میده چطور میشه دستورات متنی رو به JSON برای اجرا تبدیل کرد. با ابزارهایی مثل Unsloth هم سازگاره و میتونید خیلی سریع روی دیتای خودتون شخصیسازیش کنید و توی LM Studio سرو کنید.
به نظر من، این حرکت گوگل نشوندهنده یه شیفت پارادایم توی معماری Agent هاست. تا الان فکر میکردیم یه مدل گنده (مثل GPT-4) باید همه کارها رو بکنه، اما آینده احتمالا "تیمسازی" از مدلهاست: یه مدل متوسط برای برنامهریزی (Planner) و چندین مدل میکرو مثل FunctionGemma برای اجرای دقیق ابزارها (Executors). اینجوری هم Latency میاد پایین، هم هزینه Inference نزدیک به صفر میشه و هم امنیت داده کاربر حفظ میشه چون لاجیک روی گوشی میمونه.
اگه دارید روی سیستمهای Agentic کار میکنید که نیاز به Tool Use دارن ولی منابع سرور محدود دارید، این مدل رو حتما تست کنید. فقط یادتون باشه، بدون Fine-tune کردن روی Task خودتون، احتمالا خروجی جالبی نمیده.
📃 لینک مدل در هاگینگفیس:
https://huggingface.co/collections/google/functiongemma
📃 دیتاسیت Mobile Actions برای تمرین:
https://huggingface.co/datasets/google/mobile-actions
🛠 Join @LLMEngineers Community
بالاخره یه منبع درستوحسابی پیدا شد که فرق اسکریپتنویسی توی Colab رو با یه سیستم Production-level واقعی نشون بده. کتاب LLM Engineer's Handbook که اوایل ۲۰۲۵ منتشر شده، دقیقاً دست میذاره رو نقطهی درد اکثر ما: خروج از "جهنم ژوپیتر نوتبوک" و ورود به دنیای مهندسی نرمافزار مقیاسپذیر.
نویسندههاش آدمایین که دستشون تو کاره؛ Maxime Labonne رو احتمالاً اگر تو توییتر یا هاسینگفیس فعال باشید میشناسید (بابت مدلها و آموزشهای دقیقش) و Paul Iusztin هم که سابقه سنگین MLOps داره. ترکیب این دو تا باعث شده کتاب هم از نظر تئوری مدلها قوی باشه و هم از نظر زیرساخت.
تمرکز اصلی کتاب روی ساخت یه پروژه End-to-End به اسم LLM Twin هست. ایده اینه که یه سیستم بسازید که سبک نوشتاری و شخصیت شما رو تقلید کنه. اما نکته اینجاست که هدف ساختن مدل نیست، هدف ساختن "پایپلاین" هست.
چیزایی که تو این کتاب پوشش داده میشه فراتر از
- مباحث RAG و Fine-tuning رو با دید عملیاتی بررسی میکنه (نه فقط تئوری).
- معماری سیستم رو بر اساس پترن FTI (Feature, Training, Inference) میچینه که برای جدا کردن نگرانیها تو سیستمهای بزرگ حیاتیه.
- ابزارهایی مثل ZenML برای ارکستراسیون، Comet ML برای ترک کردن آزمایشها و AWS SageMaker برای دیپلوی رو وسط میکشه.
به نظر من، برگ برنده این کتاب اینه که وارد جزئیات کثیف Production میشه. مثلاً چطوری Latency اینفرنس رو پایین بیاریم؟ چطوری دیتابیسهای برداری مثل Qdrant رو مدیریت کنیم؟ یا چطوری برای پرامپتها مانیتورینگ بذاریم؟ اینا چیزایی نیست که تو کورسهای یوتوب پیدا بشه.
استک فنی کتاب کاملاً پایتونی و مدرنه (Poetry, Docker, GitHub Actions) و دید خوبی میده که چطوری CI/CD رو برای مدلهای زبانی پیادهسازی کنیم. اگر دنبال این هستید که از فاز "مدلسازی" صرف بیاید بیرون و تبدیل بشید به کسی که میتونه یه سرویس AI پایدار رو نگهداری کنه، این کتاب مسیر رو شفاف میکنه.
کدهاش هم توی گیتهاب فعاله و بهروزرسانی میشه، که برای یه کتاب فنی امتیاز بزرگیه. البته حواستون باشه که این کتاب برای مبتدیها نیست؛ باید پایتون و اصول اولیه AWS و GenAI رو بلد باشید تا گیر نکنید.
📃 لینک ریپازیتوری گیتهاب پروژه:
https://github.com/PacktPublishing/LLM-Engineers-Handbook
📃 لینک کتاب در آمازون:
https://www.amazon.com/LLM-Engineers-Handbook-engineering-production/dp/1836200067
🛠 Join @LLMEngineers Community
نویسندههاش آدمایین که دستشون تو کاره؛ Maxime Labonne رو احتمالاً اگر تو توییتر یا هاسینگفیس فعال باشید میشناسید (بابت مدلها و آموزشهای دقیقش) و Paul Iusztin هم که سابقه سنگین MLOps داره. ترکیب این دو تا باعث شده کتاب هم از نظر تئوری مدلها قوی باشه و هم از نظر زیرساخت.
تمرکز اصلی کتاب روی ساخت یه پروژه End-to-End به اسم LLM Twin هست. ایده اینه که یه سیستم بسازید که سبک نوشتاری و شخصیت شما رو تقلید کنه. اما نکته اینجاست که هدف ساختن مدل نیست، هدف ساختن "پایپلاین" هست.
چیزایی که تو این کتاب پوشش داده میشه فراتر از
model.generate سادهست:- مباحث RAG و Fine-tuning رو با دید عملیاتی بررسی میکنه (نه فقط تئوری).
- معماری سیستم رو بر اساس پترن FTI (Feature, Training, Inference) میچینه که برای جدا کردن نگرانیها تو سیستمهای بزرگ حیاتیه.
- ابزارهایی مثل ZenML برای ارکستراسیون، Comet ML برای ترک کردن آزمایشها و AWS SageMaker برای دیپلوی رو وسط میکشه.
به نظر من، برگ برنده این کتاب اینه که وارد جزئیات کثیف Production میشه. مثلاً چطوری Latency اینفرنس رو پایین بیاریم؟ چطوری دیتابیسهای برداری مثل Qdrant رو مدیریت کنیم؟ یا چطوری برای پرامپتها مانیتورینگ بذاریم؟ اینا چیزایی نیست که تو کورسهای یوتوب پیدا بشه.
استک فنی کتاب کاملاً پایتونی و مدرنه (Poetry, Docker, GitHub Actions) و دید خوبی میده که چطوری CI/CD رو برای مدلهای زبانی پیادهسازی کنیم. اگر دنبال این هستید که از فاز "مدلسازی" صرف بیاید بیرون و تبدیل بشید به کسی که میتونه یه سرویس AI پایدار رو نگهداری کنه، این کتاب مسیر رو شفاف میکنه.
کدهاش هم توی گیتهاب فعاله و بهروزرسانی میشه، که برای یه کتاب فنی امتیاز بزرگیه. البته حواستون باشه که این کتاب برای مبتدیها نیست؛ باید پایتون و اصول اولیه AWS و GenAI رو بلد باشید تا گیر نکنید.
📃 لینک ریپازیتوری گیتهاب پروژه:
https://github.com/PacktPublishing/LLM-Engineers-Handbook
📃 لینک کتاب در آمازون:
https://www.amazon.com/LLM-Engineers-Handbook-engineering-production/dp/1836200067
🛠 Join @LLMEngineers Community
GitHub
GitHub - PacktPublishing/LLM-Engineers-Handbook: The LLM's practical guide: From the fundamentals to deploying advanced LLM and…
The LLM's practical guide: From the fundamentals to deploying advanced LLM and RAG apps to AWS using LLMOps best practices - PacktPublishing/LLM-Engineers-Handbook
آنتونیو گولی (Antonio Gulli)، مهندس ارشد و مدیر در گوگل، داکیومنتی رو منتشر کرده که عملاً یه کورس دانشگاهی کامل برای ساخت سیستمهای هوشمند و Agentic هست؛ از صفر تا صدِ دیزاین پترنهای مدرن هوش مصنوعی رو با کد پوشش داده.
اگر دنبال این هستید که از سطح "Hello World" با LLMها فراتر برید و سیستمهای واقعی بسازید، این داکیومنت دقیقاً همون چیزیه که لازم دارید. تمرکز اصلی روی Agentic Design Patterns هست، یعنی الگوهایی که مدلهای زبانی رو از یک تولیدکننده متن ساده، به یک عامل هوشمند تبدیل میکنن.
نکات کلیدی و فنی که در این کتاب یاد میگیرید:
۱. معماری جریان کار (Workflows):
فصلهای ابتدایی به اصول پایه مثل Prompt Chaining و Routing میپردازن. اینجا یاد میگیرید چطور تسکهای پیچیده رو بشکنید و بر اساس ورودی کاربر، تصمیم بگیرید کدوم مدل یا ابزار باید اجرا بشه. این پایه و اساس هر سیستم Agentic هست.
۲. استدلال و برنامهریزی (Reasoning & Planning):
تکنیکهایی مثل ReAct و Chain of Thought (CoT) دیگه فقط تئوری نیستن. اینجا پیادهسازی عملی اونها رو میبینید. اینکه چطور Agent قبل از اجرا، فکر کنه، پلن بریزه و بعد اقدام کنه (Chapter 6 & 17).
۳. پروتکلهای اتصال و ابزار (MCP & Tools):
یکی از بخشهای جذاب، بحث Model Context Protocol (MCP) هست. این استاندارد جدید برای اتصال LLMها به دیتاسورسها و ابزارهای خارجی داره تبدیل به استاندارد صنعت میشه. فصل ۱۰ و ۵ به طور عمیق وارد Function Calling و استفاده از ابزارها میشن.
۴. سیستمهای چند عاملی (Multi-Agent):
توی فصلهای ۷ و ۱۵، یاد میگیرید چطور چندین Agent تخصصی رو کنار هم بچینید تا با هم همکاری کنن (Collaboration). این دقیقا همون جاییه که فریمورکهایی مثل LangGraph و CrewAI میدرخشن و این کتاب با کد نشون میده چطور پیادهسازیش کنید.
۵. حافظه و یادگیری (Memory & RAG):
مدیریت حافظه (Short/Long term) و RAG پیشرفته (Chapter 8 & 14) برای اینکه Agent بتونه کانتکست رو در طول زمان حفظ کنه و به دیتای سازمان دسترسی داشته باشه، حیاتیه.
۶. قابلیت اطمینان و پروداکشن (Reliability):
به نظر من، مهمترین بخش برای مهندسهای سنیور، فصلهای مربوط به Guardrails (ایمنی)، Evaluation (ارزیابی) و Error Handling هست. ساختن دمو راحته، ولی ساختن ایجنتی که تو پروداکشن کرش نکنه و خروجی سمی نده، هنره.
فریمورکهای استفاده شده:
کدها عمدتاً با استفاده از LangChain، LangGraph و Google ADK نوشته شدن که الان استک استاندارد بازار محسوب میشن.
چرا باید این رو بخونید؟
تکنولوژی Agentic AI هنوز در لبهست (Frontier). اکثر منابع موجود پراکنده و ناقصن. این داکیومنت تمام پترنهایی که الان توی سیلیکونولی استفاده میشه رو یکجا و منسجم جمع کرده.
📥 لینکهای دانلود:
📄 دانلود مستقیم PDF از گوگل درایو:
https://drive.google.com/file/d/1-5ho2aSZ-z0FcW8W_jMUoFSQ5hTKvJ43/view?usp=drivesdk
📄 لینک میرور در گیتهاب (PDF):
https://github.com/sarwarbeing-ai/Agentic_Design_Patterns/blob/main/Agentic_Design_Patterns.pdf
🛠 Join @LLMEngineers Community
اگر دنبال این هستید که از سطح "Hello World" با LLMها فراتر برید و سیستمهای واقعی بسازید، این داکیومنت دقیقاً همون چیزیه که لازم دارید. تمرکز اصلی روی Agentic Design Patterns هست، یعنی الگوهایی که مدلهای زبانی رو از یک تولیدکننده متن ساده، به یک عامل هوشمند تبدیل میکنن.
نکات کلیدی و فنی که در این کتاب یاد میگیرید:
۱. معماری جریان کار (Workflows):
فصلهای ابتدایی به اصول پایه مثل Prompt Chaining و Routing میپردازن. اینجا یاد میگیرید چطور تسکهای پیچیده رو بشکنید و بر اساس ورودی کاربر، تصمیم بگیرید کدوم مدل یا ابزار باید اجرا بشه. این پایه و اساس هر سیستم Agentic هست.
۲. استدلال و برنامهریزی (Reasoning & Planning):
تکنیکهایی مثل ReAct و Chain of Thought (CoT) دیگه فقط تئوری نیستن. اینجا پیادهسازی عملی اونها رو میبینید. اینکه چطور Agent قبل از اجرا، فکر کنه، پلن بریزه و بعد اقدام کنه (Chapter 6 & 17).
۳. پروتکلهای اتصال و ابزار (MCP & Tools):
یکی از بخشهای جذاب، بحث Model Context Protocol (MCP) هست. این استاندارد جدید برای اتصال LLMها به دیتاسورسها و ابزارهای خارجی داره تبدیل به استاندارد صنعت میشه. فصل ۱۰ و ۵ به طور عمیق وارد Function Calling و استفاده از ابزارها میشن.
۴. سیستمهای چند عاملی (Multi-Agent):
توی فصلهای ۷ و ۱۵، یاد میگیرید چطور چندین Agent تخصصی رو کنار هم بچینید تا با هم همکاری کنن (Collaboration). این دقیقا همون جاییه که فریمورکهایی مثل LangGraph و CrewAI میدرخشن و این کتاب با کد نشون میده چطور پیادهسازیش کنید.
۵. حافظه و یادگیری (Memory & RAG):
مدیریت حافظه (Short/Long term) و RAG پیشرفته (Chapter 8 & 14) برای اینکه Agent بتونه کانتکست رو در طول زمان حفظ کنه و به دیتای سازمان دسترسی داشته باشه، حیاتیه.
۶. قابلیت اطمینان و پروداکشن (Reliability):
به نظر من، مهمترین بخش برای مهندسهای سنیور، فصلهای مربوط به Guardrails (ایمنی)، Evaluation (ارزیابی) و Error Handling هست. ساختن دمو راحته، ولی ساختن ایجنتی که تو پروداکشن کرش نکنه و خروجی سمی نده، هنره.
فریمورکهای استفاده شده:
کدها عمدتاً با استفاده از LangChain، LangGraph و Google ADK نوشته شدن که الان استک استاندارد بازار محسوب میشن.
چرا باید این رو بخونید؟
تکنولوژی Agentic AI هنوز در لبهست (Frontier). اکثر منابع موجود پراکنده و ناقصن. این داکیومنت تمام پترنهایی که الان توی سیلیکونولی استفاده میشه رو یکجا و منسجم جمع کرده.
📥 لینکهای دانلود:
📄 دانلود مستقیم PDF از گوگل درایو:
https://drive.google.com/file/d/1-5ho2aSZ-z0FcW8W_jMUoFSQ5hTKvJ43/view?usp=drivesdk
📄 لینک میرور در گیتهاب (PDF):
https://github.com/sarwarbeing-ai/Agentic_Design_Patterns/blob/main/Agentic_Design_Patterns.pdf
🛠 Join @LLMEngineers Community
مقاله جدیدی که از دانشگاه مسکو اومده بیرون، یه درد مشترک ما و روسها رو هدف گرفته: مدلهای خفن مثل LLaMa-3 و Mistral روی انگلیسی عالیان، ولی وقتی میخوایم برای زبان خودمون (Russian اونجا، Farsi اینجا) بهینهشون کنیم، یا باید کلی هزینه Pre-training بدیم یا با دیتاستهای کمکیفیت Instruction Tuning کنیم که نتیجهاش میشه یه مدل که "فارسی حرف میزنه ولی مغزش کوچیک شده" (Catastrophic Forgetting).
راهکار این مقاله Learned Embedding Propagation (LEP) هست.
ایده اصلی اینه: به جای اینکه مدل رو از اول روی دیتاستهای Instruction-Tuning زبان مقصد (که معمولا کمه یا بیکیفیته) آموزش بدیم، بیایم "دانشِ پیروی از دستورات" (Instruction Following) رو از مدل انگلیسی به مدل زبانمادری تزریق کنیم، اونم فقط با دستکاری Embeddingها.
روش کار به صورت خلاصه اینطوریه:
یک: ابتدا Vocabulary مدل رو دستکاری میکنن (تکنیک Vocabulary Conversion). توکنهای انگلیسی رو نگه میدارن ولی توکنهای اختصاصی زبان جدید رو با الگوریتمهایی مثل BPE یا Unigram اضافه میکنن تا Tokenization بهینه بشه.
دو: مدل Base رو روی متون خام زبان مقصد (Continued Pre-training) آموزش میدن. اینجا فقط Embeddingها آپدیت میشن تا مدل زبان رو بفهمه. هنوز Instruction بلد نیست.
سه: حالا بخش جذاب ماجراست. با یه تبدیل خطی (Linear Transformation)، فاصله بین Embeddingهای مدل Base و مدل Instruct انگلیسی رو یاد میگیرن و این تبدیل رو روی Embeddingهای مدل جدید اعمال میکنن. یعنی عملاً مغز Instruct-Tuned مدل انگلیسی رو "پورت" میکنن روی بدنه زبانفهم جدید.
نکته مهمی که تو بنچمارکگیریشون (که اسمش رو گذاشتن Darumeru) فهمیدن اینه که بنچمارکهای موجود (مثل MERA یا Open Leaderboardها) قابل اعتماد نیستن چون Data Leakage توشون زیاده. برای همین یه تسک جدید به اسم DaruCopy اضافه کردن.
تسک کپی کردن (Copy Task) یعنی مدل بتونه یه متن طولانی رو بدون تغییر کپی کنه. شاید مسخره به نظر بیاد، ولی وقتی Vocabulary عوض میشه، مدلها قاطی میکنن و شروع میکنن به هذیون گفتن (Hallucination). اگر مدلی نتونه متن ورودی رو کپی کنه، یعنی توکنهای جدید رو درست مپ نکرده.
به نظر من این مقاله برای کامیونیتی فارسی طلاست. ما همیشه مشکل دیتاست باکیفیت Instruction فارسی داریم (مثل Saiga که اونا دارن). با LEP میتونیم Qwen-3-Instruct رو برداریم، توکنهای فارسی رو بهش تزریق کنیم و بدون نیاز به هزاران سمپل فاینتیون، یه مدل اینستراکت فارسی تر و تمیز داشته باشیم که منطق مدل اصلی رو حفظ کرده.
نتایج نشون میده که این روش نه تنها هزینهها رو به شدت کاهش میده، بلکه در اکثر تسکها عملکردش با مدلهایی که فولفاینتیون شدن برابری میکنه یا حتی بهتره، چون دانش اصلی مدل Base کمتر دستکاری شده.
📃 عنوان مقاله: Facilitating large language model Russian adaptation with Learned Embedding Propagation
https://arxiv.org/abs/2412.21140v1
🛠 Join @LLMEngineers Community
راهکار این مقاله Learned Embedding Propagation (LEP) هست.
ایده اصلی اینه: به جای اینکه مدل رو از اول روی دیتاستهای Instruction-Tuning زبان مقصد (که معمولا کمه یا بیکیفیته) آموزش بدیم، بیایم "دانشِ پیروی از دستورات" (Instruction Following) رو از مدل انگلیسی به مدل زبانمادری تزریق کنیم، اونم فقط با دستکاری Embeddingها.
روش کار به صورت خلاصه اینطوریه:
یک: ابتدا Vocabulary مدل رو دستکاری میکنن (تکنیک Vocabulary Conversion). توکنهای انگلیسی رو نگه میدارن ولی توکنهای اختصاصی زبان جدید رو با الگوریتمهایی مثل BPE یا Unigram اضافه میکنن تا Tokenization بهینه بشه.
دو: مدل Base رو روی متون خام زبان مقصد (Continued Pre-training) آموزش میدن. اینجا فقط Embeddingها آپدیت میشن تا مدل زبان رو بفهمه. هنوز Instruction بلد نیست.
سه: حالا بخش جذاب ماجراست. با یه تبدیل خطی (Linear Transformation)، فاصله بین Embeddingهای مدل Base و مدل Instruct انگلیسی رو یاد میگیرن و این تبدیل رو روی Embeddingهای مدل جدید اعمال میکنن. یعنی عملاً مغز Instruct-Tuned مدل انگلیسی رو "پورت" میکنن روی بدنه زبانفهم جدید.
نکته مهمی که تو بنچمارکگیریشون (که اسمش رو گذاشتن Darumeru) فهمیدن اینه که بنچمارکهای موجود (مثل MERA یا Open Leaderboardها) قابل اعتماد نیستن چون Data Leakage توشون زیاده. برای همین یه تسک جدید به اسم DaruCopy اضافه کردن.
تسک کپی کردن (Copy Task) یعنی مدل بتونه یه متن طولانی رو بدون تغییر کپی کنه. شاید مسخره به نظر بیاد، ولی وقتی Vocabulary عوض میشه، مدلها قاطی میکنن و شروع میکنن به هذیون گفتن (Hallucination). اگر مدلی نتونه متن ورودی رو کپی کنه، یعنی توکنهای جدید رو درست مپ نکرده.
به نظر من این مقاله برای کامیونیتی فارسی طلاست. ما همیشه مشکل دیتاست باکیفیت Instruction فارسی داریم (مثل Saiga که اونا دارن). با LEP میتونیم Qwen-3-Instruct رو برداریم، توکنهای فارسی رو بهش تزریق کنیم و بدون نیاز به هزاران سمپل فاینتیون، یه مدل اینستراکت فارسی تر و تمیز داشته باشیم که منطق مدل اصلی رو حفظ کرده.
نتایج نشون میده که این روش نه تنها هزینهها رو به شدت کاهش میده، بلکه در اکثر تسکها عملکردش با مدلهایی که فولفاینتیون شدن برابری میکنه یا حتی بهتره، چون دانش اصلی مدل Base کمتر دستکاری شده.
📃 عنوان مقاله: Facilitating large language model Russian adaptation with Learned Embedding Propagation
https://arxiv.org/abs/2412.21140v1
🛠 Join @LLMEngineers Community
arXiv.org
Facilitating large language model Russian adaptation with Learned...
Rapid advancements of large language model (LLM) technologies led to the introduction of powerful open-source instruction-tuned LLMs that have the same text generation quality as the...
❤2
قبل از هر چیز، تسلیت صمیمانه به تمام مردم ایران و خانوادههایی که تو این مدت داغدار شدن. ۷ هفته سکوت این کانال نه از روی بیخبری بود و نه بیتفاوتی؛ پاسخی بود به فاجعهای که همهمون لمسش کردیم.
باید خیلی شفاف بگم: پست گذاشتن ما به معنی عادیسازی شرایط نیست. هیچچیز برای ما عادی نشده و هیچچیز هم تمام نشده. داغ این روزها روی تن جامعه و مخصوصاً کامیونیتی تکنولوژی میمونه. اما به اصرار و درخواست خیلی از شما بچهها که تو این شرایط برای بقا و جلو بردن پروژههاتون به دانش روز احتیاج داشتید، تصمیم گرفتیم فعالیت رو از سر بگیریم. ما برمیگردیم چون معتقدیم یاد گرفتن تکنولوژی های روز دنیا، خودش یه نوع ایستادگیه و نباید اجازه بدیم شکاف دانش ما با دنیا از این بیشتر بشه.
باید خیلی شفاف بگم: پست گذاشتن ما به معنی عادیسازی شرایط نیست. هیچچیز برای ما عادی نشده و هیچچیز هم تمام نشده. داغ این روزها روی تن جامعه و مخصوصاً کامیونیتی تکنولوژی میمونه. اما به اصرار و درخواست خیلی از شما بچهها که تو این شرایط برای بقا و جلو بردن پروژههاتون به دانش روز احتیاج داشتید، تصمیم گرفتیم فعالیت رو از سر بگیریم. ما برمیگردیم چون معتقدیم یاد گرفتن تکنولوژی های روز دنیا، خودش یه نوع ایستادگیه و نباید اجازه بدیم شکاف دانش ما با دنیا از این بیشتر بشه.
❤59👍9👎4
LLM Engineers pinned «قبل از هر چیز، تسلیت صمیمانه به تمام مردم ایران و خانوادههایی که تو این مدت داغدار شدن. ۷ هفته سکوت این کانال نه از روی بیخبری بود و نه بیتفاوتی؛ پاسخی بود به فاجعهای که همهمون لمسش کردیم. باید خیلی شفاف بگم: پست گذاشتن ما به معنی عادیسازی شرایط نیست.…»
مدل GLM-5 با معماری MoE و وزنهای باز منتشر شد و نشون داد که جنگ در سال ۲۰۲۶ دیگه روی صرفاً تعداد پارامتر نیست، بلکه روی بهینهسازی سیستم و زیرساخت پسآموزشه. این مدل با ۷۴۴ میلیارد پارامتر کل عرضه شده که موقع استنتاج فقط ۴۰ میلیارد پارامتر فعال داره. حجم دادههای پیشآموزش هم به ۲۸.۵ تریلیون توکن رسیده که نشوندهنده کیفیت و چگالی بالای اطلاعات توی وزنهاست.
معماری Sparse Attention که از DeepSeek قرض گرفته شده، مستقیماً هزینههای عملیاتی رو هدف قرار میده. استفاده از این تکنیک باعث میشه مدیریت Context پنجرههای طولانی بدون ترکیدن VRAM ممکن بشه. واقعیت اینه که داشتن مدل بزرگ بدون Sparse Attention توی محیط Production عملاً یعنی خودکشی مالی، و GLM-5 این رو خوب فهمیده.
زیرساخت Slime که همراه این مدل معرفی شده، به نظر من نقطه عطف اصلی این انتشار برای مهندسهای هوش مصنوعیه. این یه فریمورک RL ناهمگام (Asynchronous) هست که برای مقیاسپذیری الگوریتمهای پسآموزش طراحی شده. ترکیب Megatron برای آموزش سنگین و SGLang برای استنتاج سریع، نشون میده که تیم توسعهدهنده دنبال حل مشکل Train-Inference Mismatch بوده. پشتیبانی کامل از FP8 و FSDP توی Slime یعنی میتونید پروسه RL رو با کمترین هدررفت منابع انجام بدید.
توزیع وزنها در Hugging Face به همراه آرتیفکتهای ارزیابی و راهنمای سرو کردن (Serving Guidance)، استاندارد جدیدی رو برای پروژههای Open-weight تعریف کرده. این که فایلها چند روز قبل از اعلام رسمی آپلود شدن و همزمان مستندات فنی دقیق ارائه شده، نشون میده با یه محصول آماده برای استقرار (Production-ready) طرف هستیم، نه فقط یه مقاله علمی برای نمایش.
به نظر من، ارزش واقعی GLM-5 توی بنچمارکهاش نیست، بلکه توی "قابلیت دیپلوی شدن" و ابزارهای همراهشه. وقتی یه مدل ۷۴۴ میلیاردی رو با مکانیزمهای Sparse طوری بهینه میکنن که با منابع معقول قابل اجرا باشه، یعنی داریم به سمتی میریم که کارایی سیستم (System Efficiency) از تئوریهای معماری پیشی گرفته. اگه دنبال پیادهسازی RLhf یا پروژههای مبتنی بر استدلال (Reasoning) هستید، بررسی Slime واجبتر از خود مدله.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/zai-org/GLM-5
📃 زیرساخت آموزشی Slime در گیتهاب:
https://github.com/THUDM/slime
🛠 Join @LLMEngineers Community
معماری Sparse Attention که از DeepSeek قرض گرفته شده، مستقیماً هزینههای عملیاتی رو هدف قرار میده. استفاده از این تکنیک باعث میشه مدیریت Context پنجرههای طولانی بدون ترکیدن VRAM ممکن بشه. واقعیت اینه که داشتن مدل بزرگ بدون Sparse Attention توی محیط Production عملاً یعنی خودکشی مالی، و GLM-5 این رو خوب فهمیده.
زیرساخت Slime که همراه این مدل معرفی شده، به نظر من نقطه عطف اصلی این انتشار برای مهندسهای هوش مصنوعیه. این یه فریمورک RL ناهمگام (Asynchronous) هست که برای مقیاسپذیری الگوریتمهای پسآموزش طراحی شده. ترکیب Megatron برای آموزش سنگین و SGLang برای استنتاج سریع، نشون میده که تیم توسعهدهنده دنبال حل مشکل Train-Inference Mismatch بوده. پشتیبانی کامل از FP8 و FSDP توی Slime یعنی میتونید پروسه RL رو با کمترین هدررفت منابع انجام بدید.
توزیع وزنها در Hugging Face به همراه آرتیفکتهای ارزیابی و راهنمای سرو کردن (Serving Guidance)، استاندارد جدیدی رو برای پروژههای Open-weight تعریف کرده. این که فایلها چند روز قبل از اعلام رسمی آپلود شدن و همزمان مستندات فنی دقیق ارائه شده، نشون میده با یه محصول آماده برای استقرار (Production-ready) طرف هستیم، نه فقط یه مقاله علمی برای نمایش.
به نظر من، ارزش واقعی GLM-5 توی بنچمارکهاش نیست، بلکه توی "قابلیت دیپلوی شدن" و ابزارهای همراهشه. وقتی یه مدل ۷۴۴ میلیاردی رو با مکانیزمهای Sparse طوری بهینه میکنن که با منابع معقول قابل اجرا باشه، یعنی داریم به سمتی میریم که کارایی سیستم (System Efficiency) از تئوریهای معماری پیشی گرفته. اگه دنبال پیادهسازی RLhf یا پروژههای مبتنی بر استدلال (Reasoning) هستید، بررسی Slime واجبتر از خود مدله.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/zai-org/GLM-5
📃 زیرساخت آموزشی Slime در گیتهاب:
https://github.com/THUDM/slime
🛠 Join @LLMEngineers Community
🔥8
مدل Qwen3.5-397B-A17B که همین چند ساعت پیش آپدیت شد، یه قدرتنمایی توی مهندسی زیرساخته و نشون میده تیم توسعهدهنده کاملاً با چالشهای عملیاتی درگیر بوده. این مدل با ۳۹۷ میلیارد پارامتر کل و فقط ۱۷ میلیارد پارامتر فعال، عملاً داره مرزهای کارایی MoE رو جابهجا میکنه. چیزی که اینجا مهمه، معماری ترکیبی Gated DeltaNet و Gated Attention هست که در کنار MoE قرار گرفته. استفاده از DeltaNet که یه نوع Linear Attention بهینه هست، باعث میشه توی Context پنجرههای طولانی، گلوگاههای محاسباتی معمول رو نداشته باشیم.
تکنیک MTP یا Multi-token Prediction که به صورت Multi-steps پیادهسازی شده، یکی از نقاط قوت این مدل برای افزایش سرعت استنتاج و کیفیت خروجی در گامهای بلنده. با ۵۱۲ اکسپرت که ۱۰ تاشون مسیریابی میشن و ۱ دونهشون اشتراکیه، تعادل خوبی بین تخصصگرایی مدل و حفظ دانش عمومی برقرار شده. این چیدمان باعث میشه مدل توی کارهای پیچیده مثل استدلالهای چند مرحلهای، دقت بالاتری نسبت به MoEهای کلاسیک داشته باشه.
پشتیبانی از ۲۶۲ هزار توکن Context به صورت Native و قابلیت گسترش تا بیش از ۱ میلیون توکن با YaRN، این مدل رو برای پردازش داکیومنتهای حجیم بیرقیب میکنه. نکته مهندسی و جذاب ماجرا اینجاست که توی مستندات، آپشن Language-model-only رو گذاشتن. این یعنی میتونید بخشهای بینایی (Multimodal) رو موقع سرو کردن غیرفعال کنید تا KV Cache آزاد بشه و بتونید از حداکثر ظرفیت Context بدون کرش کردن کارت گرافیک استفاده کنید. این دقیقاً همون دیدگاه سینیوری هست که برای محیط Production لازمه؛ حذف اضافات برای گرفتن پرفورمنس ماکسیمم.
واقعیت اینه که Qwen3.5 ثابت کرد برای داشتن Context یک میلیونی، نباید فقط به سختافزار تکیه کرد؛ بلکه باید معماری رو طوری دستکاری کرد که "هوشمندانه" از حافظه استفاده کنه. قابلیت نادیده گرفتن کامپوننتهای Vision موقع استنتاج متنی، چیزیه که باید خیلی زودتر توی مدلهای مولتیمودال میدیدیم.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen3.5-397B-A17B
🛠 Join @LLMEngineers Community
تکنیک MTP یا Multi-token Prediction که به صورت Multi-steps پیادهسازی شده، یکی از نقاط قوت این مدل برای افزایش سرعت استنتاج و کیفیت خروجی در گامهای بلنده. با ۵۱۲ اکسپرت که ۱۰ تاشون مسیریابی میشن و ۱ دونهشون اشتراکیه، تعادل خوبی بین تخصصگرایی مدل و حفظ دانش عمومی برقرار شده. این چیدمان باعث میشه مدل توی کارهای پیچیده مثل استدلالهای چند مرحلهای، دقت بالاتری نسبت به MoEهای کلاسیک داشته باشه.
پشتیبانی از ۲۶۲ هزار توکن Context به صورت Native و قابلیت گسترش تا بیش از ۱ میلیون توکن با YaRN، این مدل رو برای پردازش داکیومنتهای حجیم بیرقیب میکنه. نکته مهندسی و جذاب ماجرا اینجاست که توی مستندات، آپشن Language-model-only رو گذاشتن. این یعنی میتونید بخشهای بینایی (Multimodal) رو موقع سرو کردن غیرفعال کنید تا KV Cache آزاد بشه و بتونید از حداکثر ظرفیت Context بدون کرش کردن کارت گرافیک استفاده کنید. این دقیقاً همون دیدگاه سینیوری هست که برای محیط Production لازمه؛ حذف اضافات برای گرفتن پرفورمنس ماکسیمم.
واقعیت اینه که Qwen3.5 ثابت کرد برای داشتن Context یک میلیونی، نباید فقط به سختافزار تکیه کرد؛ بلکه باید معماری رو طوری دستکاری کرد که "هوشمندانه" از حافظه استفاده کنه. قابلیت نادیده گرفتن کامپوننتهای Vision موقع استنتاج متنی، چیزیه که باید خیلی زودتر توی مدلهای مولتیمودال میدیدیم.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen3.5-397B-A17B
🛠 Join @LLMEngineers Community
❤6🔥2👍1
مدل Step 3.5 Flash از تیم StepFun یکی از جدیترین تلاشها برای بهینهسازی مدلهای زبانی در چرخههای عاملیت (Agent Loops) محسوب میشه. این مدل با معماری MoE و مجموع ۱۹۶ میلیارد پارامتر طراحی شده، اما در زمان استنتاج فقط ۱۱ میلیارد پارامتر فعال (Active Parameters) داره. این یعنی داریم با مدلی کار میکنیم که دانش یک غول ۲۰۰ میلیاردی رو داره ولی با سرعت و هزینه یک مدل سبک ۱۱ میلیاردی اجرا میشه.
معماری Interleaved 3:1 Sliding-window / Full Attention یک حرکت مهندسی هوشمندانه برای مدیریت Context است. در این ساختار، به جای استفاده از Full Attention در تمام لایهها که هزینه محاسباتی رو به شدت بالا میبره، از ترکیب ۳ به ۱ پنجرههای لغزان (Sliding-window) و توجه کامل استفاده شده. این یعنی مدل هم ارتباطات محلی رو خیلی سریع میفهمه و هم هر چند لایه یک بار، دید کلی (Global) پیدا میکنه. برای ایجنتهایی که نیاز به پردازش تاریخچه طولانی چت دارن، این یعنی تعادل بین دقت و سرعت.
پایپلاین RL این مدل هم از سیگنالهای قابل تایید (Verifiable Signals) و بازخورد ترجیحی (Preference Feedback) به صورت ترکیبی استفاده میکنه. برخلاف روشهای سنتی RLHF که فقط روی سلیقه انسانی تمرکز دارن، اینجا مدل بر اساس درستی خروجی (مثلاً اجرای کد یا حل ریاضی) هم جریمه یا تشویق میشه. این پایداری در آموزش Off-policy باعث شده که مدل در سناریوهای دنیای واقعی کمتر دچار توهم بشه و رفتارهای منطقیتری از خودش نشون بده.
به نظر من، Step 3.5 Flash نشون داد که دوران مدلهای General-purpose که فقط برای چت کردن ساخته میشدن تموم شده. ما الان نیاز به مدلهایی داریم که برای "کار انجام دادن" (Task Execution) بهینه شده باشن. تمرکز روی زیرساخت RL پایدار و معماری هیبریدی Attention، این مدل رو به یکی از بهترین گزینهها برای دیپلوی کردن سیستمهای Agentic در سال ۲۰۲۶ تبدیل کرده.
📃 مقاله فنی در arXiv:
https://arxiv.org/abs/2602.10604
📃 مخزن کد در گیتهاب:
https://github.com/stepfun-ai/Step-3.5-Flash
📃 مدل در هاگینگ فیس:
https://huggingface.co/stepfun-ai/Step-3.5-Flash
🛠 Join @LLMEngineers Community
معماری Interleaved 3:1 Sliding-window / Full Attention یک حرکت مهندسی هوشمندانه برای مدیریت Context است. در این ساختار، به جای استفاده از Full Attention در تمام لایهها که هزینه محاسباتی رو به شدت بالا میبره، از ترکیب ۳ به ۱ پنجرههای لغزان (Sliding-window) و توجه کامل استفاده شده. این یعنی مدل هم ارتباطات محلی رو خیلی سریع میفهمه و هم هر چند لایه یک بار، دید کلی (Global) پیدا میکنه. برای ایجنتهایی که نیاز به پردازش تاریخچه طولانی چت دارن، این یعنی تعادل بین دقت و سرعت.
پایپلاین RL این مدل هم از سیگنالهای قابل تایید (Verifiable Signals) و بازخورد ترجیحی (Preference Feedback) به صورت ترکیبی استفاده میکنه. برخلاف روشهای سنتی RLHF که فقط روی سلیقه انسانی تمرکز دارن، اینجا مدل بر اساس درستی خروجی (مثلاً اجرای کد یا حل ریاضی) هم جریمه یا تشویق میشه. این پایداری در آموزش Off-policy باعث شده که مدل در سناریوهای دنیای واقعی کمتر دچار توهم بشه و رفتارهای منطقیتری از خودش نشون بده.
به نظر من، Step 3.5 Flash نشون داد که دوران مدلهای General-purpose که فقط برای چت کردن ساخته میشدن تموم شده. ما الان نیاز به مدلهایی داریم که برای "کار انجام دادن" (Task Execution) بهینه شده باشن. تمرکز روی زیرساخت RL پایدار و معماری هیبریدی Attention، این مدل رو به یکی از بهترین گزینهها برای دیپلوی کردن سیستمهای Agentic در سال ۲۰۲۶ تبدیل کرده.
📃 مقاله فنی در arXiv:
https://arxiv.org/abs/2602.10604
📃 مخزن کد در گیتهاب:
https://github.com/stepfun-ai/Step-3.5-Flash
📃 مدل در هاگینگ فیس:
https://huggingface.co/stepfun-ai/Step-3.5-Flash
🛠 Join @LLMEngineers Community
arXiv.org
Step 3.5 Flash: Open Frontier-Level Intelligence with 11B Active Parameters
We introduce Step 3.5 Flash, a sparse Mixture-of-Experts (MoE) model that bridges frontier-level agentic intelligence and computational efficiency. We focus on what matters most when building...
❤6
مدل Qwen3-Coder-Next که اوایل فوریه ۲۰۲۶ منتشر شد، دقیقاً همون چیزیه که برای ساخت Coding Agentهای محلی و حرفهای لازم داشتیم. با ۸۰ میلیارد پارامتر کل و فقط ۳ میلیارد پارامتر فعال (Active)، این مدل عملاً روی سیستمهای میانرده هم با سرعت وحشتناکی اجرا میشه. وقتی فقط ۳ میلیارد پارامتر موقع استنتاج درگیر باشن، یعنی تأخیر (Latency) به حداقل میرسه و این برای محیطهای توسعه (Dev Workflows) که سرعت بازخورد توشون حیاتیه، یک پارامتر تعیینکننده است.
معماری این مدل هم مثل نسخههای پیشرفته Qwen3.5، ترکیبی از DeltaNet و Attention سنتی در کنار Sparse MoE هست. استفاده از DeltaNet یعنی مدیریت حافظه و محاسبات در پنجرههای طولانی ۲۶۲ هزار توکنی دیگه کابوس نیست. با این ظرفیت Context، میتونید کل داکیومنتها و بخش بزرگی از کدبیس (Codebase) پروژه رو یکجا به مدل بدید بدون اینکه نگران از دست رفتن تمرکز مدل یا پر شدن VRAM باشید. واقعیت اینه که برای ایجنتهای کدنویس، کانتکست بالا از نون شب واجبتره چون باید کل ساختار پروژه رو درک کنن.
چیزی که Qwen3-Coder-Next رو از بقیه متمایز میکنه، بهینهسازی اختصاصی برای سناریوهای Agentic هست. این مدل صرفاً کد تولید نمیکنه؛ بلکه برای استفاده طولانیمدت از ابزارها (Long-horizon tool use) و مهمتر از اون، "بازیابی بعد از شکست" (Failure recovery) تیون شده. یعنی اگه کدی که زد در مرحله اجرا با خطا مواجه شد، میتونه لاگ سیستم رو بخونه و خودش رو اصلاح کنه. این دقیقاً تفاوت یه مدل معمولی با یه "مهندس هوش مصنوعی" خودمختاره.
پتانسیل این مدل توی استفاده از ابزارهای خارجی (Tool Use) و پایداری در استدلالهای طولانی، اونو به یه انتخاب سینیور برای پروژههای اتوماسیون نرمافزار تبدیل میکنه. اگه دنبال ساخت یه Devin شخصی یا ابزارهای مشابه هستید، این مدل همون قطعه گمشده پازله.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen3-Coder-Next
🛠 Join @LLMEngineers Community
معماری این مدل هم مثل نسخههای پیشرفته Qwen3.5، ترکیبی از DeltaNet و Attention سنتی در کنار Sparse MoE هست. استفاده از DeltaNet یعنی مدیریت حافظه و محاسبات در پنجرههای طولانی ۲۶۲ هزار توکنی دیگه کابوس نیست. با این ظرفیت Context، میتونید کل داکیومنتها و بخش بزرگی از کدبیس (Codebase) پروژه رو یکجا به مدل بدید بدون اینکه نگران از دست رفتن تمرکز مدل یا پر شدن VRAM باشید. واقعیت اینه که برای ایجنتهای کدنویس، کانتکست بالا از نون شب واجبتره چون باید کل ساختار پروژه رو درک کنن.
چیزی که Qwen3-Coder-Next رو از بقیه متمایز میکنه، بهینهسازی اختصاصی برای سناریوهای Agentic هست. این مدل صرفاً کد تولید نمیکنه؛ بلکه برای استفاده طولانیمدت از ابزارها (Long-horizon tool use) و مهمتر از اون، "بازیابی بعد از شکست" (Failure recovery) تیون شده. یعنی اگه کدی که زد در مرحله اجرا با خطا مواجه شد، میتونه لاگ سیستم رو بخونه و خودش رو اصلاح کنه. این دقیقاً تفاوت یه مدل معمولی با یه "مهندس هوش مصنوعی" خودمختاره.
پتانسیل این مدل توی استفاده از ابزارهای خارجی (Tool Use) و پایداری در استدلالهای طولانی، اونو به یه انتخاب سینیور برای پروژههای اتوماسیون نرمافزار تبدیل میکنه. اگه دنبال ساخت یه Devin شخصی یا ابزارهای مشابه هستید، این مدل همون قطعه گمشده پازله.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen3-Coder-Next
🛠 Join @LLMEngineers Community
👍2
مدل GLM-4.7-Flash که اواخر ژانویه ۲۰۲۶ منتشر شد، دقیقاً همون نقطه تعادلیه که اکثر مهندسها دنبالش میگردن؛ یعنی نه اونقدر ضعیفه که نشه بهش کار سپرد و نه اونقدر سنگین که برای اجراش نیاز به کلاستر اختصاصی باشه. این مدل با معماری MoE و ۳۰ میلیارد پارامتر کل طراحی شده، اما موقع اجرا فقط ۳ میلیارد پارامتر رو درگیر میکنه. یعنی عملاً با هزینه و سرعت یک مدل ۳ میلیاردی، قدرت استدلال و دانش یک مدل ۳۰ میلیاردی رو در اختیار دارید.
معماری این مدل برای کارهای Agentic و کدنویسی بهینه شده و نکته طلایی برای ما مهندسها، ارائه دستورالعملهای دقیق برای Speculative Decoding هست. تیم Zhipu AI توی مستنداتش مستقیم گفته که برای گرفتن بالاترین سرعت، از نسخههای Main-branch ابزارهای vLLM و SGLang استفاده کنید. استفاده از کانفیگ EAGLE برای SGLang و تنظیمات MTP-style برای vLLM باعث میشه نرخ تولید توکن به قدری بالا بره که برای سیستمهای تعاملی و ایجنتهایی که نیاز به فکر کردن سریع دارن، هیچ گلوگاهی حس نشه.
واقعیت اینه که ریختن وزن مدل توی هاگینگ فیس دیگه کافی نیست. چیزی که GLM-4.7-Flash رو ارزشمند میکنه، وجود آرتیفکتهای ارزیابی (Evaluation Artifacts) و پارامترهای دقیق برای بنچمارکهای SWE و Terminal هست. این یعنی توسعهدهندهها میدونن مدلشون توی محیطهای عملیاتی مثل ترمینال لینوکس یا حل باگهای نرمافزاری چه رفتاری داره و پارامترهای بهینه رو هم همونجا گذاشتن تا ما وقتمون رو برای پیدا کردن بهترین Temperature یا Top-p تلف نکنیم.
به نظر من، این مدل پادشاه فعلی "پردازشهای محلی" (Local Serving) در لایه بیزنس هست. وقتی میتونید با یک یا دو کارت گرافیک معمولی، مدلی رو بالا بیارید که هم از Speculative Decoding پشتیبانی میکنه و هم توی تسکهای استدلالی رقیب مدلهای بزرگتره، دیگه دلیلی برای استفاده از APIهای گرونقیمت باقی نمیمونه. تمرکز روی کارایی به جای ابعاد بزرگ، نشون میده که بلوغ مهندسی توی تیمهای توسعهدهنده به سطح سینیور رسیده.
اگه دنبال راهاندازی یه سیستم RAG داخلی یا دستیار کدنویسی هستید که هم امنیت دادههاتون حفظ بشه و هم سرعت پاسخدهی زیر ثانیه باشه، GLM-4.7-Flash با این معماری MoE بهینه، بهترین خروجی رو بهتون میده. مخصوصاً اگه از پایپلاینهای SGLang استفاده میکنید، حتماً تنظیمات اختصاصی EAGLE رو که توی مدلکارت اومده تست کنید؛ تفاوت سرعتش با حالت عادی واقعاً چشمگیره.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/zai-org/GLM-4.7-Flash
🛠 Join @LLMEngineers Community
معماری این مدل برای کارهای Agentic و کدنویسی بهینه شده و نکته طلایی برای ما مهندسها، ارائه دستورالعملهای دقیق برای Speculative Decoding هست. تیم Zhipu AI توی مستنداتش مستقیم گفته که برای گرفتن بالاترین سرعت، از نسخههای Main-branch ابزارهای vLLM و SGLang استفاده کنید. استفاده از کانفیگ EAGLE برای SGLang و تنظیمات MTP-style برای vLLM باعث میشه نرخ تولید توکن به قدری بالا بره که برای سیستمهای تعاملی و ایجنتهایی که نیاز به فکر کردن سریع دارن، هیچ گلوگاهی حس نشه.
واقعیت اینه که ریختن وزن مدل توی هاگینگ فیس دیگه کافی نیست. چیزی که GLM-4.7-Flash رو ارزشمند میکنه، وجود آرتیفکتهای ارزیابی (Evaluation Artifacts) و پارامترهای دقیق برای بنچمارکهای SWE و Terminal هست. این یعنی توسعهدهندهها میدونن مدلشون توی محیطهای عملیاتی مثل ترمینال لینوکس یا حل باگهای نرمافزاری چه رفتاری داره و پارامترهای بهینه رو هم همونجا گذاشتن تا ما وقتمون رو برای پیدا کردن بهترین Temperature یا Top-p تلف نکنیم.
به نظر من، این مدل پادشاه فعلی "پردازشهای محلی" (Local Serving) در لایه بیزنس هست. وقتی میتونید با یک یا دو کارت گرافیک معمولی، مدلی رو بالا بیارید که هم از Speculative Decoding پشتیبانی میکنه و هم توی تسکهای استدلالی رقیب مدلهای بزرگتره، دیگه دلیلی برای استفاده از APIهای گرونقیمت باقی نمیمونه. تمرکز روی کارایی به جای ابعاد بزرگ، نشون میده که بلوغ مهندسی توی تیمهای توسعهدهنده به سطح سینیور رسیده.
اگه دنبال راهاندازی یه سیستم RAG داخلی یا دستیار کدنویسی هستید که هم امنیت دادههاتون حفظ بشه و هم سرعت پاسخدهی زیر ثانیه باشه، GLM-4.7-Flash با این معماری MoE بهینه، بهترین خروجی رو بهتون میده. مخصوصاً اگه از پایپلاینهای SGLang استفاده میکنید، حتماً تنظیمات اختصاصی EAGLE رو که توی مدلکارت اومده تست کنید؛ تفاوت سرعتش با حالت عادی واقعاً چشمگیره.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/zai-org/GLM-4.7-Flash
🛠 Join @LLMEngineers Community
👍2
مدل Nanbeige4.1-3B که اواسط فوریه ۲۰۲۶ آپدیت شد، یه مثال نقض برای کساییه که فکر میکنن مدلهای ۳ میلیاردی فقط برای چتهای ساده یا خلاصهسازی متن هستن. این مدل با تمرکز روی "عمق عاملیت" (Agentic Depth) طراحی شده و ادعای تکنیکال اصلیش، توانایی مدیریت زنجیرههای طولانی فراخوانی ابزار (Tool Invocations) تا بیش از ۵۰۰ مرحله است. برای یه مدل ۳ میلیاردی، این یعنی شکستن سقف شیشهای که همیشه بین استدلال عمومی و چرخههای کاری پیچیده وجود داشت.
پستتراینینگ (Post-training) این مدل با استفاده از ترکیب SFT و RL به شدت روی سناریوهای جستجوی عمیق (Deep-search) متمرکز بوده. مشکل همیشگی مدلهای کوچیک اینه که یا توی استدلال عمومی خوبن یا توی استفاده از ابزار، اما وقتی تعداد مراحل کار زیاد میشه، کانتکست رو گم میکنن یا دچار توهم میشن. Nanbeige4.1 نشون داده که با یه دیتای باکیفیت و پایپلاین RL درست، میشه مدلی ساخت که توی چرخههای طولانی "خسته" نشه و هدف اصلی تسک رو فراموش نکنه.
به نظر من، ارزش واقعی این مدل برای مهندسهایی هست که میخوان سیستمهای Agentic رو به صورت Local و با کمترین هزینه سختافزاری اجرا کنن. ۵۰۰ مرحله فراخوانی ابزار یعنی شما میتونید یه ایجنت محقق (Research Agent) بسازید که ساعتها توی وب بگرده، دیتای مختلف رو بخونه، ابزارهای تحلیل رو صدا بزنه و در نهایت یه گزارش دقیق بده؛ بدون اینکه نیاز باشه به مدلهای ابری گرونقیمت وصل بشید.
استراتژی تیم Nanbeige توی انتشار وزنها به همراه گزارش فنی دقیق (PDF) در هاگینگ فیس، نشوندهنده شفافیت در متدولوژی آموزشیشونه. اونا به جای هایپ روی تعداد پارامتر، روی "پایداری در مسیرهای طولانی" (Long Trajectories) تمرکز کردن که دقیقاً همون چیزیه که برای ساختن اپلیکیشنهای واقعی مبتنی بر هوش مصنوعی (و نه فقط دموهای جذاب) بهش نیاز داریم.
اگه دارید روی ایجنتهای خودمختار کار میکنید که نیاز به جستجوی عمیق دارن، Nanbeige4.1-3B میتونه جایگزین خیلی خوبی برای مدلهای سنگینتر باشه، به شرطی که پرامپتنویسی و ساختار ابزارهاتون رو دقیق تنظیم کرده باشید. این مدل ثابت میکنه که توی سال ۲۰۲۶، "هوشمندی" دیگه لزوماً به معنی "بزرگی" نیست، بلکه به معنی "تخصص در فرآیند" هست.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/Nanbeige/Nanbeige4.1-3B
🛠 Join @LLMEngineers Community
پستتراینینگ (Post-training) این مدل با استفاده از ترکیب SFT و RL به شدت روی سناریوهای جستجوی عمیق (Deep-search) متمرکز بوده. مشکل همیشگی مدلهای کوچیک اینه که یا توی استدلال عمومی خوبن یا توی استفاده از ابزار، اما وقتی تعداد مراحل کار زیاد میشه، کانتکست رو گم میکنن یا دچار توهم میشن. Nanbeige4.1 نشون داده که با یه دیتای باکیفیت و پایپلاین RL درست، میشه مدلی ساخت که توی چرخههای طولانی "خسته" نشه و هدف اصلی تسک رو فراموش نکنه.
به نظر من، ارزش واقعی این مدل برای مهندسهایی هست که میخوان سیستمهای Agentic رو به صورت Local و با کمترین هزینه سختافزاری اجرا کنن. ۵۰۰ مرحله فراخوانی ابزار یعنی شما میتونید یه ایجنت محقق (Research Agent) بسازید که ساعتها توی وب بگرده، دیتای مختلف رو بخونه، ابزارهای تحلیل رو صدا بزنه و در نهایت یه گزارش دقیق بده؛ بدون اینکه نیاز باشه به مدلهای ابری گرونقیمت وصل بشید.
استراتژی تیم Nanbeige توی انتشار وزنها به همراه گزارش فنی دقیق (PDF) در هاگینگ فیس، نشوندهنده شفافیت در متدولوژی آموزشیشونه. اونا به جای هایپ روی تعداد پارامتر، روی "پایداری در مسیرهای طولانی" (Long Trajectories) تمرکز کردن که دقیقاً همون چیزیه که برای ساختن اپلیکیشنهای واقعی مبتنی بر هوش مصنوعی (و نه فقط دموهای جذاب) بهش نیاز داریم.
اگه دارید روی ایجنتهای خودمختار کار میکنید که نیاز به جستجوی عمیق دارن، Nanbeige4.1-3B میتونه جایگزین خیلی خوبی برای مدلهای سنگینتر باشه، به شرطی که پرامپتنویسی و ساختار ابزارهاتون رو دقیق تنظیم کرده باشید. این مدل ثابت میکنه که توی سال ۲۰۲۶، "هوشمندی" دیگه لزوماً به معنی "بزرگی" نیست، بلکه به معنی "تخصص در فرآیند" هست.
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/Nanbeige/Nanbeige4.1-3B
🛠 Join @LLMEngineers Community
❤3🔥1
مدلهای سری Mox که توسط تیم VANTA Research منتشر شدن، یه رویکرد مهندسی متفاوت رو نسبت به مفهوم "شخصیت" (Persona) در هوش مصنوعی نشون میدن. به جای اینکه شخصیت رو صرفاً یه لایه پرامپتنویسی ساده ببینن، اون رو به عنوان یک مشخصه فنی (Technical Spec) در لایه Fine-tuning پیادهسازی کردن. این مدلها برای سناریوهایی طراحی شدن که شما به یک دستیار با "نظر مستقیم" و "توانایی مخالفت سازنده" نیاز دارید، نه فقط یه بات که با هر حرف کاربر موافقت میکنه.
مدل mox-small-1 که بر پایه OLMo 32B Instruct بنا شده، با استفاده از QLoRA روی ۱۸ هزار مکالمه دستچین شده تیون شده. نکته مهندسی اینجاست که دیتاستهای مورد استفاده (شامل ۱۷ دیتاست مختلف) دقیقاً برای رفتارهایی مثل "عدم قطعیت کالیبره شده" (Calibrated Uncertainty) بهینه شدن. یعنی مدل یاد گرفته وقتی جواب سوالی رو نمیدونه، به جای توهم زدن یا پیچوندن جواب، مستقیماً اعلام کنه که نمیدونه. این سطح از صداقت توی مدلهای RLHF شده معمولی که فقط برای راضی نگه داشتن کاربر (User Preference) آموزش دیدن، به ندرت پیدا میشه.
مدل mox-tiny-1 که از بیس Llama 3.1 8B استفاده میکنه، با تکنیک LoRA تیون شده و کانتکست ۱۳۱ هزار توکنی رو ساپورت میکنه. ارائه فرمتهای GGUF در کنار وزنهای اصلی نشون میده که هدف، استفاده محلی و سریع (Local Inference) بوده. ۱۳۱ هزار توکن برای یک مدل ۸ میلیاردی، فضای کافی رو برای تحلیل داکیومنتهای حجیم در کنار حفظ اون شخصیت منتقد و مستقیم فراهم میکنه.
به نظر من، حرکت VANTA Research برای انتشار مدلهایی که "جرئت مخالفت" دارن، یه واکنش درست به وضعیت فعلی مدلهای هوش مصنوعیه که به خاطر ترس از ایمنی (Safety) بیش از حد، عملاً بیاستفاده و بیش از حد مودب شدن. استفاده از OLMo به عنوان بیس مدل ۳۲ میلیاردی هم انتخاب هوشمندانهای بوده؛ چون برخلاف بسیاری از مدلهای دیگه، پشته آموزشی (Training Stack) شفافتری داره و برای کارهای تحقیقاتی و توسعه سیستمهای "ایمنی-محور" قابل اعتمادتره.
اگر دارید روی سیستمهای تصمیم یار (Decision Support Systems) کار میکنید، سری Mox به خاطر تمرکز روی "مخالفت سازنده" و "نظرات مستقیم"، ابزار بهتری نسبت به مدلهای عمومی برای به چالش کشیدن فرضیات شما هستن. در واقع این مدلها به درد کسایی میخورن که دنبال "حقیقت" هستن، نه لزوماً "تایید".
📃 مدل mox-small-1 در هاگینگ فیس:
https://huggingface.co/vanta-research/mox-small-1
📃 مدل mox-tiny-1 در هاگینگ فیس:
https://huggingface.co/vanta-research/mox-tiny-1
🛠 Join @LLMEngineers Community
مدل mox-small-1 که بر پایه OLMo 32B Instruct بنا شده، با استفاده از QLoRA روی ۱۸ هزار مکالمه دستچین شده تیون شده. نکته مهندسی اینجاست که دیتاستهای مورد استفاده (شامل ۱۷ دیتاست مختلف) دقیقاً برای رفتارهایی مثل "عدم قطعیت کالیبره شده" (Calibrated Uncertainty) بهینه شدن. یعنی مدل یاد گرفته وقتی جواب سوالی رو نمیدونه، به جای توهم زدن یا پیچوندن جواب، مستقیماً اعلام کنه که نمیدونه. این سطح از صداقت توی مدلهای RLHF شده معمولی که فقط برای راضی نگه داشتن کاربر (User Preference) آموزش دیدن، به ندرت پیدا میشه.
مدل mox-tiny-1 که از بیس Llama 3.1 8B استفاده میکنه، با تکنیک LoRA تیون شده و کانتکست ۱۳۱ هزار توکنی رو ساپورت میکنه. ارائه فرمتهای GGUF در کنار وزنهای اصلی نشون میده که هدف، استفاده محلی و سریع (Local Inference) بوده. ۱۳۱ هزار توکن برای یک مدل ۸ میلیاردی، فضای کافی رو برای تحلیل داکیومنتهای حجیم در کنار حفظ اون شخصیت منتقد و مستقیم فراهم میکنه.
به نظر من، حرکت VANTA Research برای انتشار مدلهایی که "جرئت مخالفت" دارن، یه واکنش درست به وضعیت فعلی مدلهای هوش مصنوعیه که به خاطر ترس از ایمنی (Safety) بیش از حد، عملاً بیاستفاده و بیش از حد مودب شدن. استفاده از OLMo به عنوان بیس مدل ۳۲ میلیاردی هم انتخاب هوشمندانهای بوده؛ چون برخلاف بسیاری از مدلهای دیگه، پشته آموزشی (Training Stack) شفافتری داره و برای کارهای تحقیقاتی و توسعه سیستمهای "ایمنی-محور" قابل اعتمادتره.
اگر دارید روی سیستمهای تصمیم یار (Decision Support Systems) کار میکنید، سری Mox به خاطر تمرکز روی "مخالفت سازنده" و "نظرات مستقیم"، ابزار بهتری نسبت به مدلهای عمومی برای به چالش کشیدن فرضیات شما هستن. در واقع این مدلها به درد کسایی میخورن که دنبال "حقیقت" هستن، نه لزوماً "تایید".
📃 مدل mox-small-1 در هاگینگ فیس:
https://huggingface.co/vanta-research/mox-small-1
📃 مدل mox-tiny-1 در هاگینگ فیس:
https://huggingface.co/vanta-research/mox-tiny-1
🛠 Join @LLMEngineers Community
🔥3❤1👍1
مدل Voxtral Realtime از Mistral AI بالاخره اون شکافی که بین مدلهای ASR آفلاین و سیستمهای استریمینگ وجود داشت رو پر کرد. برخلاف اکثر مدلها که صرفاً یه مدل آفلاین (مثل Whisper) رو با ترفند Windowing تبدیل به استریمینگ میکنن، این مدل از پایه برای پردازش در لحظه (End-to-end Streaming) طراحی شده. این یعنی مدل یاد گرفته که با جریان پیوسته صدا کار کنه، نه تکههای بریده شده.
معماری این مدل بر پایه Delayed Streams Modeling (DSM) بنا شده، اما با یه تغییر بزرگ: استفاده از یه Causal Audio Encoder جدید و Ada RMS-Norm. این یعنی انکودر مدل دیگه نگاه به آینده (Look-ahead) نداره و به صورت علیتی صدا رو پردازش میکنه. این کار باعث میشه شرطیسازی روی تاخیر (Delay Conditioning) خیلی دقیقتر انجام بشه و پایداری خروجی در لحظه حفظ بشه. استفاده از Ada RMS-Norm هم کمک کرده تا مدل با تغییرات ناگهانی در تاخیر شبکه یا ورودی، کیفیت خروجی رو از دست نده.
رسیدن به تأخیر ۴۸۰ میلیثانیه در حالی که کیفیت خروجی با مدلهای آفلاین سنگینی مثل Whisper برابری میکنه، یه دستاورد مهندسی جدی در سال ۲۰۲۶ محسوب میشه. این یعنی شما میتونید سیستمهای Voice-to-Text با تاخیر زیر نیم ثانیه بسازید که عملاً خطایی ندارن. پشتیبانی از ۱۳ زبان مختلف در مرحله پیشآموزش هم نشون میده که مدل روی دیتای چندزبانه (Multilingual) به خوبی تعمیم پیدا کرده و صرفاً برای انگلیسی بهینه نشده.
به نظر من، بزرگترین نقطه قوت این انتشار، لایسنس Apache 2.0 و وزنهای باز (Open Weights) مدل ۴ میلیاردی Mini هست. ما همیشه توی سیستمهای Real-time با مشکل Train-inference mismatch و پرشهای ناگهانی در متن خروجی مواجه بودیم، چون مدلهای آفلاین برای دیدن کل جمله آموزش دیدن. Voxtral با رویکرد Natively Streaming این مشکل رو از ریشه حل کرده. اگه دارید روی Voice Agents یا سیستمهای ترجمه همزمان کار میکنید، این مدل استاندارد جدید شماست.
واقعیت اینه که برای داشتن تجربه کاربری روون در صوت، تاخیر زیر ۵۰۰ میلیثانیه حیاتیه. Mistral با این مدل نشون داد که میشه بدون فدا کردن دقت، به سرعت استریمینگ واقعی رسید. مدل ۴ میلیاردی به قدری سبک هست که بشه اون رو روی GPUهای معمولی یا حتی Edge به راحتی سرو کرد.
📃 مقاله فنی در arXiv:
https://arxiv.org/abs/2602.11298
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/mistralai/Voxtral-Mini-4B-Realtime-2602
🛠 Join @LLMEngineers Community
معماری این مدل بر پایه Delayed Streams Modeling (DSM) بنا شده، اما با یه تغییر بزرگ: استفاده از یه Causal Audio Encoder جدید و Ada RMS-Norm. این یعنی انکودر مدل دیگه نگاه به آینده (Look-ahead) نداره و به صورت علیتی صدا رو پردازش میکنه. این کار باعث میشه شرطیسازی روی تاخیر (Delay Conditioning) خیلی دقیقتر انجام بشه و پایداری خروجی در لحظه حفظ بشه. استفاده از Ada RMS-Norm هم کمک کرده تا مدل با تغییرات ناگهانی در تاخیر شبکه یا ورودی، کیفیت خروجی رو از دست نده.
رسیدن به تأخیر ۴۸۰ میلیثانیه در حالی که کیفیت خروجی با مدلهای آفلاین سنگینی مثل Whisper برابری میکنه، یه دستاورد مهندسی جدی در سال ۲۰۲۶ محسوب میشه. این یعنی شما میتونید سیستمهای Voice-to-Text با تاخیر زیر نیم ثانیه بسازید که عملاً خطایی ندارن. پشتیبانی از ۱۳ زبان مختلف در مرحله پیشآموزش هم نشون میده که مدل روی دیتای چندزبانه (Multilingual) به خوبی تعمیم پیدا کرده و صرفاً برای انگلیسی بهینه نشده.
به نظر من، بزرگترین نقطه قوت این انتشار، لایسنس Apache 2.0 و وزنهای باز (Open Weights) مدل ۴ میلیاردی Mini هست. ما همیشه توی سیستمهای Real-time با مشکل Train-inference mismatch و پرشهای ناگهانی در متن خروجی مواجه بودیم، چون مدلهای آفلاین برای دیدن کل جمله آموزش دیدن. Voxtral با رویکرد Natively Streaming این مشکل رو از ریشه حل کرده. اگه دارید روی Voice Agents یا سیستمهای ترجمه همزمان کار میکنید، این مدل استاندارد جدید شماست.
واقعیت اینه که برای داشتن تجربه کاربری روون در صوت، تاخیر زیر ۵۰۰ میلیثانیه حیاتیه. Mistral با این مدل نشون داد که میشه بدون فدا کردن دقت، به سرعت استریمینگ واقعی رسید. مدل ۴ میلیاردی به قدری سبک هست که بشه اون رو روی GPUهای معمولی یا حتی Edge به راحتی سرو کرد.
📃 مقاله فنی در arXiv:
https://arxiv.org/abs/2602.11298
📃 مخزن مدل در هاگینگ فیس:
https://huggingface.co/mistralai/Voxtral-Mini-4B-Realtime-2602
🛠 Join @LLMEngineers Community
❤3👍2
اکوسیستم صوتی Qwen3 با انتشار مدلهای ASR و TTS، عملاً پازل ارتباط صوتی انسان و ماشین رو در لایه متنباز (Open-source) کامل کرد. این حرکت فراتر از انتشار چند وزن مدل ساده است؛ ما با یک پشته (Stack) کامل پردازش صوت طرف هستیم که برای استفاده در سیستمهای Real-time و Agentic بهینه شده. برخلاف رویکردهای قدیمی که ASR و TTS رو جدا میدیدن، Qwen3 روی یکپارچگی و کاهش تأخیر (Latency) تمرکز کرده تا بشه تجربههایی شبیه به GPT-4o رو به صورت محلی پیاده کرد.
مدل Qwen3-ASR با ظرفیت ۱.۷ میلیاردی، یک راهکار همهکاره برای شناسایی زبان (LID) و تبدیل گفتار به متن در ۵۲ زبان و گویش مختلفه. معماری این مدل طوری طراحی شده که همزمان از استنتاج استریمینگ (Streaming) و آفلاین پشتیبانی میکنه. چیزی که برای من به عنوان مهندس جذابه، انتشار Qwen3-ForcedAligner است. این ابزار با دقت بسیار بالا، زمانبندی (Timestamp) کلمات رو تا ۵ دقیقه صوت مداوم استخراج میکنه. برای پروژههایی که نیاز به زیرنویس دقیق یا همگامسازی لب (Lip-sync) دارن، این ابزار یک جایگزین جدی و سریع برای مدلهای سنگینتر محسوب میشه.
در بخش تولید صدا، Qwen3-TTS با قابلیت شبیهسازی ۳ ثانیهای (3-second Voice Cloning) و کنترل از طریق دستورات متنی، استاندارد جدیدی رو تعریف کرده. نکته کلیدی در مهندسی این مدل، استفاده از معماری Dual-track LM است. استفاده از دو توکنایزر مختلف (۲۵ هرتز برای یکپارچگی معنایی و ۱۲ هرتز برای کاهش نرخ بیت) باعث شده که اولین بسته صوتی (First-packet) در کمتر از ۹۷ میلیثانیه تولید بشه. این یعنی تأخیر در سیستمهای پاسخگویی صوتی عملاً به صفر نزدیک شده. به نظر من، این سطح از بهینهسازی در توکنایزرها، تفاوت اصلی بین یک پروژه آزمایشگاهی و یک محصول آماده برای بازار (Market-ready) رو رقم میزنه.
ارائه این مدلها تحت لایسنس Apache 2.0 و فراهم کردن تولکیتهای استنتاجی مبتنی بر vLLM نشون میده که هدف، دموکراتیزه کردن تکنولوژی Voice-to-Voice بوده. شما الان میتونید با ترکیب Qwen3-ASR برای شنیدن و Qwen3-TTS برای حرف زدن، یک دستیار صوتی کامل بسازید که هم هویت صوتی کاربر رو در ۳ ثانیه کپی میکنه و هم با تأخیر زیر ۱۰۰ میلیثانیه پاسخ میده.
به نظر من، ارزش واقعی این سری در مدلهای کوچیک 0.6B نهفته است. این حجم کم پارامتر یعنی میتونید کل سیستم پردازش صوت رو روی لبه (Edge) یا کارتهای گرافیک ارزانقیمت اجرا کنید، بدون اینکه نیاز به کلاسترهای سنگین داشته باشید. ترکیب Forced Aligner با مدلهای TTS، یک خط تولید محتوای صوتی خودکار رو میسازه که قبلاً پیادهسازیش ماهها زمان میبرد.
📃 مقاله فنی Qwen3-ASR در arXiv:
https://arxiv.org/abs/2601.21337
📃 مخزن مدل ASR در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen3-ASR-1.7B
📃 مقاله فنی Qwen3-TTS در arXiv:
https://arxiv.org/abs/2601.15621
📃 مخزن کد TTS در گیتهاب:
https://github.com/QwenLM/Qwen3-TTS
🛠 Join @LLMEngineers Community
مدل Qwen3-ASR با ظرفیت ۱.۷ میلیاردی، یک راهکار همهکاره برای شناسایی زبان (LID) و تبدیل گفتار به متن در ۵۲ زبان و گویش مختلفه. معماری این مدل طوری طراحی شده که همزمان از استنتاج استریمینگ (Streaming) و آفلاین پشتیبانی میکنه. چیزی که برای من به عنوان مهندس جذابه، انتشار Qwen3-ForcedAligner است. این ابزار با دقت بسیار بالا، زمانبندی (Timestamp) کلمات رو تا ۵ دقیقه صوت مداوم استخراج میکنه. برای پروژههایی که نیاز به زیرنویس دقیق یا همگامسازی لب (Lip-sync) دارن، این ابزار یک جایگزین جدی و سریع برای مدلهای سنگینتر محسوب میشه.
در بخش تولید صدا، Qwen3-TTS با قابلیت شبیهسازی ۳ ثانیهای (3-second Voice Cloning) و کنترل از طریق دستورات متنی، استاندارد جدیدی رو تعریف کرده. نکته کلیدی در مهندسی این مدل، استفاده از معماری Dual-track LM است. استفاده از دو توکنایزر مختلف (۲۵ هرتز برای یکپارچگی معنایی و ۱۲ هرتز برای کاهش نرخ بیت) باعث شده که اولین بسته صوتی (First-packet) در کمتر از ۹۷ میلیثانیه تولید بشه. این یعنی تأخیر در سیستمهای پاسخگویی صوتی عملاً به صفر نزدیک شده. به نظر من، این سطح از بهینهسازی در توکنایزرها، تفاوت اصلی بین یک پروژه آزمایشگاهی و یک محصول آماده برای بازار (Market-ready) رو رقم میزنه.
ارائه این مدلها تحت لایسنس Apache 2.0 و فراهم کردن تولکیتهای استنتاجی مبتنی بر vLLM نشون میده که هدف، دموکراتیزه کردن تکنولوژی Voice-to-Voice بوده. شما الان میتونید با ترکیب Qwen3-ASR برای شنیدن و Qwen3-TTS برای حرف زدن، یک دستیار صوتی کامل بسازید که هم هویت صوتی کاربر رو در ۳ ثانیه کپی میکنه و هم با تأخیر زیر ۱۰۰ میلیثانیه پاسخ میده.
به نظر من، ارزش واقعی این سری در مدلهای کوچیک 0.6B نهفته است. این حجم کم پارامتر یعنی میتونید کل سیستم پردازش صوت رو روی لبه (Edge) یا کارتهای گرافیک ارزانقیمت اجرا کنید، بدون اینکه نیاز به کلاسترهای سنگین داشته باشید. ترکیب Forced Aligner با مدلهای TTS، یک خط تولید محتوای صوتی خودکار رو میسازه که قبلاً پیادهسازیش ماهها زمان میبرد.
📃 مقاله فنی Qwen3-ASR در arXiv:
https://arxiv.org/abs/2601.21337
📃 مخزن مدل ASR در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen3-ASR-1.7B
📃 مقاله فنی Qwen3-TTS در arXiv:
https://arxiv.org/abs/2601.15621
📃 مخزن کد TTS در گیتهاب:
https://github.com/QwenLM/Qwen3-TTS
🛠 Join @LLMEngineers Community
❤3👍2
مدل Pocket-TTS از آزمایشگاه Kyutai یه حرکت جالب توی دنیای سنتز صداست که بر خلاف اکثر سیستمهای فعلی، به جای استفاده از توکنهای گسسته (Discrete Tokens)، بر پایه مفهوم "مدلسازی پیوسته صوت" (Continuous Audio Modeling) ساخته شده. مقاله فنی این تیم که نسخه سومش همین ژانویه ۲۰۲۶ منتشر شد، نشون میده که چطور میشه با استفاده از جریانهای پیوسته صوتی، به خروجیهایی رسید که هم طبیعیتر هستن و هم آرتیفکتهای کمتری دارن.
تکنولوژی CALM یا همان Continuous Audio Language Models، ستون فقرات این پروژهست. ایده اصلی اینه که صوت رو به صورت یک جریان مداوم و بدون تکهتکه کردن (Quantization) به کدهای دیجیتال، مدلسازی کنن. این رویکرد باعث میشه لحن صدا (Prosody) و جزئیات ظریف انسانی خیلی بهتر حفظ بشه. نکته مهندسی ماجرا اینجاست که Kyutai موفق شده این تئوری سنگین رو در قالب Pocket-TTS به یه ابزار کاربردی و سبک تبدیل کنه که برای محدودیتهای سختافزاری واقعی طراحی شده.
تمرکز Pocket-TTS روی "قابلیت استفاده" (Deployability) است. در حالی که مدلهای بزرگ TTS برای خروجیهای استودیویی عالی هستن، اما برای استفاده در دستگاههای موبایل یا ایجنتهایی که نیاز به پاسخگویی در لحظه دارن، سنگین و کند محسوب میشن. این پروژه با ارائه کد و کانفیگهای بهینه در گیتهاب، هدفش اینه که سنتز صدای باکیفیت رو به محیطهای با منابع محدود بیاره. به نظر من، این که یه آزمایشگاه تحقیقاتی مثل Kyutai به جای انتشار یه مدل غولآسا، روی "Pocket-sized" کردن تکنولوژی تمرکز کرده، نشوندهنده درک درستشون از نیاز بازار در سال ۲۰۲۶ هست.
واقعیت اینه که مدلسازی پیوسته صوت پتانسیل این رو داره که استاندارد طلایی TTS بشه، چون مشکل همیشگی "روباتیک بودن" صدا در سیستمهای مبتنی بر Codec رو حل میکنه. اگه دارید روی اپلیکیشنهایی کار میکنید که نیاز به تعامل صوتی سریع و در عین حال باکیفیت دارن، Pocket-TTS یه گزینه سینیور و مهندسیشدهست که نباید ازش بگذرید.
📃 مقاله فنی Continuous Audio Language Models در arXiv:
https://arxiv.org/abs/2509.06926
📃 مخزن کد Pocket-TTS در گیتهاب:
https://github.com/kyutai/pocket-tts
🛠 Join @LLMEngineers Community
تکنولوژی CALM یا همان Continuous Audio Language Models، ستون فقرات این پروژهست. ایده اصلی اینه که صوت رو به صورت یک جریان مداوم و بدون تکهتکه کردن (Quantization) به کدهای دیجیتال، مدلسازی کنن. این رویکرد باعث میشه لحن صدا (Prosody) و جزئیات ظریف انسانی خیلی بهتر حفظ بشه. نکته مهندسی ماجرا اینجاست که Kyutai موفق شده این تئوری سنگین رو در قالب Pocket-TTS به یه ابزار کاربردی و سبک تبدیل کنه که برای محدودیتهای سختافزاری واقعی طراحی شده.
تمرکز Pocket-TTS روی "قابلیت استفاده" (Deployability) است. در حالی که مدلهای بزرگ TTS برای خروجیهای استودیویی عالی هستن، اما برای استفاده در دستگاههای موبایل یا ایجنتهایی که نیاز به پاسخگویی در لحظه دارن، سنگین و کند محسوب میشن. این پروژه با ارائه کد و کانفیگهای بهینه در گیتهاب، هدفش اینه که سنتز صدای باکیفیت رو به محیطهای با منابع محدود بیاره. به نظر من، این که یه آزمایشگاه تحقیقاتی مثل Kyutai به جای انتشار یه مدل غولآسا، روی "Pocket-sized" کردن تکنولوژی تمرکز کرده، نشوندهنده درک درستشون از نیاز بازار در سال ۲۰۲۶ هست.
واقعیت اینه که مدلسازی پیوسته صوت پتانسیل این رو داره که استاندارد طلایی TTS بشه، چون مشکل همیشگی "روباتیک بودن" صدا در سیستمهای مبتنی بر Codec رو حل میکنه. اگه دارید روی اپلیکیشنهایی کار میکنید که نیاز به تعامل صوتی سریع و در عین حال باکیفیت دارن، Pocket-TTS یه گزینه سینیور و مهندسیشدهست که نباید ازش بگذرید.
📃 مقاله فنی Continuous Audio Language Models در arXiv:
https://arxiv.org/abs/2509.06926
📃 مخزن کد Pocket-TTS در گیتهاب:
https://github.com/kyutai/pocket-tts
🛠 Join @LLMEngineers Community
arXiv.org
Continuous Audio Language Models
Audio Language Models (ALM) have emerged as the dominant paradigm for speech and music generation by representing audio as sequences of discrete tokens. Yet, unlike text tokens, which are...
❤5
دنیای مدلهای بینایی-زبانی (VLM) در شروع سال ۲۰۲۶ از مرحله "فقط توصیف تصویر" عبور کرده و مستقیماً وارد فاز استدلال بصری و خودکارسازی رابط کاربری (UI Automation) شده است. مدلهایی که اخیراً منتشر شدند، نشان میدهند که تمرکز مهندسی از مدلهای غولآسا به سمت مدلهای بهینه (زیر ۱۰ میلیارد پارامتر) با قابلیت فهم ویدیوهای طولانی و استخراج دقیق متن (OCR) تغییر کرده است.
مدل Qwen3-VL-8B-Instruct که در آخرین روزهای ۲۰۲۵ آپدیت شد، یک نقطه عطف برای ساخت "ایجنتهای بصری" است. استفاده از مکانیزم Interleaved MRoPE به این مدل اجازه میدهد که دادههای متن، تصویر و ویدیو را در کانتکستهای طولانی بدون از دست دادن موقعیتسنجی (Position Encoding) پردازش کند. قابلیت "Time Anchor" در پاسخهای این مدل، یعنی مدل میتواند به ثانیههای دقیق در یک ویدیوی طولانی ارجاع دهد؛ این ویژگی برای مهندسهایی که روی سیستمهای نظارتی یا تحلیل محتوا کار میکنند، یک ابزار کلیدی است. همچنین پشتیبانی از ۳۲ زبان در OCR و بهینهسازی برای تسکهای Visual Agent (مثل کار با محیط GUI)، نشان میدهد که Qwen3-VL فراتر از یک مدل ساده، یک اپراتور بصری است.
استدلال چندوجهی (Multimodal Reasoning) در مدلهای GLM-4.5V و GLM-4.1V Thinking به یک هدف آموزشی درجه اول تبدیل شده است. برخلاف مدلهای قدیمی که فقط پیکسلها را به کلمات تبدیل میکردند، این مدلها یاد گرفتهاند که بر اساس شواهد بصری "فکر" کنند. این یعنی مدل قبل از ارائه جواب، یک زنجیره استدلال داخلی (Chain of Thought) ایجاد میکند تا مطمئن شود خروجی با جزئیات تصویر مطابقت دارد.
مدل GLM-OCR یک رویکرد مهندسی هوشمندانه را برای حل مشکل کندی در پردازش اسناد سنگین پیش گرفته است. این مدل به جای یک پردازش خطی ساده، از پایپلاین "Layout -> Parallel Recognize -> Merge" استفاده میکند. با استفاده از یک انکودر CogViT و یک دیکودر سبک ۰.۵ میلیاردی، این مدل میتواند نواحی مختلف سند را شناسایی کرده، آنها را به صورت موازی بازخوانی کند و در نهایت خروجی Markdown تمیز تحویل دهد. استفاده از Loss اختصاصی MTP (پیشبینی چند توکنی) باعث شده که سرعت و دقت در بازسازی ساختار جداول و متون پیچیده به شدت بالا برود.
مدل LightOnOCR-2-1B نیز با استفاده از تکنیک RLVR (یادگیری تقویتشده با پاداشهای قابل تایید)، استانداردهای جدیدی برای تبدیل تصاویر اسناد به متن تمیز تعریف کرده است. استفاده از RL در OCR به این معناست که مدل بر اساس "درستیِ قابل سنجش" خروجی (مثل مطابقت دقیق با متن اصلی سند) جریمه یا تشویق شده است. این رویکرد باعث کاهش توهم (Hallucination) در بازخوانی اعداد و کلمات خاص در اسناد رسمی و علمی میشود.
به نظر من، ما داریم به پایان دوران سیستمهای OCR سنتی و سنگین (مثل Tesseract) نزدیک میشویم. وقتی مدلهای ۱ تا ۸ میلیاردی میتوانند با دقت انسانی اسناد را بفهمند، ساختار لایوت را حفظ کنند و حتی روی ویدیوها استدلال کنند، یعنی زیرساختهای هوش مصنوعی آماده جایگزینی با فرآیندهای دستی در مقیاس صنعتی هستند. برای مهندسها، الان زمان استفاده از این مدلها در قالب SGLang یا vLLM است تا سیستمهای "سند-فهم" (Document-understanding) واقعی بسازند.
📃 مدل Qwen3-VL در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen3-VL-8B-Instruct
📃 مقاله فنی استدلال چندوجهی GLM:
https://arxiv.org/abs/2507.01006
📃 مخزن GLM-OCR برای پردازش اسناد:
https://github.com/zai-org/GLM-OCR
📃 مدل LightOnOCR-2-1B برای متون چندزبانه:
https://huggingface.co/lightonai/LightOnOCR-2-1B
🛠 Join @LLMEngineers Community
مدل Qwen3-VL-8B-Instruct که در آخرین روزهای ۲۰۲۵ آپدیت شد، یک نقطه عطف برای ساخت "ایجنتهای بصری" است. استفاده از مکانیزم Interleaved MRoPE به این مدل اجازه میدهد که دادههای متن، تصویر و ویدیو را در کانتکستهای طولانی بدون از دست دادن موقعیتسنجی (Position Encoding) پردازش کند. قابلیت "Time Anchor" در پاسخهای این مدل، یعنی مدل میتواند به ثانیههای دقیق در یک ویدیوی طولانی ارجاع دهد؛ این ویژگی برای مهندسهایی که روی سیستمهای نظارتی یا تحلیل محتوا کار میکنند، یک ابزار کلیدی است. همچنین پشتیبانی از ۳۲ زبان در OCR و بهینهسازی برای تسکهای Visual Agent (مثل کار با محیط GUI)، نشان میدهد که Qwen3-VL فراتر از یک مدل ساده، یک اپراتور بصری است.
استدلال چندوجهی (Multimodal Reasoning) در مدلهای GLM-4.5V و GLM-4.1V Thinking به یک هدف آموزشی درجه اول تبدیل شده است. برخلاف مدلهای قدیمی که فقط پیکسلها را به کلمات تبدیل میکردند، این مدلها یاد گرفتهاند که بر اساس شواهد بصری "فکر" کنند. این یعنی مدل قبل از ارائه جواب، یک زنجیره استدلال داخلی (Chain of Thought) ایجاد میکند تا مطمئن شود خروجی با جزئیات تصویر مطابقت دارد.
مدل GLM-OCR یک رویکرد مهندسی هوشمندانه را برای حل مشکل کندی در پردازش اسناد سنگین پیش گرفته است. این مدل به جای یک پردازش خطی ساده، از پایپلاین "Layout -> Parallel Recognize -> Merge" استفاده میکند. با استفاده از یک انکودر CogViT و یک دیکودر سبک ۰.۵ میلیاردی، این مدل میتواند نواحی مختلف سند را شناسایی کرده، آنها را به صورت موازی بازخوانی کند و در نهایت خروجی Markdown تمیز تحویل دهد. استفاده از Loss اختصاصی MTP (پیشبینی چند توکنی) باعث شده که سرعت و دقت در بازسازی ساختار جداول و متون پیچیده به شدت بالا برود.
مدل LightOnOCR-2-1B نیز با استفاده از تکنیک RLVR (یادگیری تقویتشده با پاداشهای قابل تایید)، استانداردهای جدیدی برای تبدیل تصاویر اسناد به متن تمیز تعریف کرده است. استفاده از RL در OCR به این معناست که مدل بر اساس "درستیِ قابل سنجش" خروجی (مثل مطابقت دقیق با متن اصلی سند) جریمه یا تشویق شده است. این رویکرد باعث کاهش توهم (Hallucination) در بازخوانی اعداد و کلمات خاص در اسناد رسمی و علمی میشود.
به نظر من، ما داریم به پایان دوران سیستمهای OCR سنتی و سنگین (مثل Tesseract) نزدیک میشویم. وقتی مدلهای ۱ تا ۸ میلیاردی میتوانند با دقت انسانی اسناد را بفهمند، ساختار لایوت را حفظ کنند و حتی روی ویدیوها استدلال کنند، یعنی زیرساختهای هوش مصنوعی آماده جایگزینی با فرآیندهای دستی در مقیاس صنعتی هستند. برای مهندسها، الان زمان استفاده از این مدلها در قالب SGLang یا vLLM است تا سیستمهای "سند-فهم" (Document-understanding) واقعی بسازند.
📃 مدل Qwen3-VL در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen3-VL-8B-Instruct
📃 مقاله فنی استدلال چندوجهی GLM:
https://arxiv.org/abs/2507.01006
📃 مخزن GLM-OCR برای پردازش اسناد:
https://github.com/zai-org/GLM-OCR
📃 مدل LightOnOCR-2-1B برای متون چندزبانه:
https://huggingface.co/lightonai/LightOnOCR-2-1B
🛠 Join @LLMEngineers Community
❤5
مدلهای تولید تصویر و ویدیو در ابتدای سال ۲۰۲۶ از مرحله "فقط پیکسل ساختن" رد شدن و دارن روی دو جبهه متضاد اما مکمل حرکت میکنن: سرعت دیوانهوار برای مصرفکننده نهایی و کنترلپذیری عمیق برای مهندسها. خانواده FLUX.2 [klein] با معماری Rectified Flow Transformer و استفاده از تکنیک Step Distillation، استانداردی رو تعریف کرده که تولید تصویر رو به زیر ۱ ثانیه رسونده. این مدل ۹ میلیاردی با استفاده از Qwen Text Embedder و خروجی FP8، نشون میده که بهینهسازی برای GPUهای معمولی (Consumer GPUs) اولویت اول تیم Black Forest Labs بوده. تقطیر مدل به ۴ مرحله (4-step) یعنی شما عملاً دارید Real-time تصویر میسازید، هرچند که برای کارهای سنگینتر، نسخه ۵۰ مرحلهای بیس هنوز مرجع اصلی کیفیته.
معماری Single-stream DiT در مدل Z-Image مسیر دیگهای رو باز کرده. اینجا توکنهای متنی و بصری در یک جریان واحد (Single-stream) با هم ترکیب میشن که باعث درک بهتر جزئیات متن در تصویر میشه. برخلاف مدلهای تقطیر شده، نسخه بیس Z-Image بدون Distillation منتشر شده تا قابلیت CFG و استفاده از Negative Prompt به شکل کامل حفظ بشه. به نظر من، این حرکت برای مهندسهایی که دنبال Fine-tune کردن روی استایلهای خاص هستن حیاتیه، چون مدلهای تقطیر شده (Distilled) معمولاً انعطافپذیری لازم برای یادگیری مفاهیم جدید رو ندارن و "پخته شده" به نظر میرسن.
آپدیت Qwen-Image-2512 روی نقاط ضعف کلاسیک مدلهای نفوذی (Diffusion Models) یعنی رندر کردن متن (Typography) و رئالیسم انسانی تمرکز کرده. ارائه این مدل به صورت Diffusers-native یعنی زنجیره ابزارهای Python آماده پذیرش این مدل هستن و نیازی به بازنویسی اسکریپتهای پیچیده استنتاج نیست. تمرکز روی جزئیات طبیعی نشون میده که رقابت از "ساختن تصویر کلی" به سمت "دقت در بافت" (Fine Detail) حرکت کرده و مدلها دیگه توی کشیدن انگشتها یا متون ریز کمتر سوتی میدن.
در حوزه ویدیو و مدلهای جهان (World Models)، پروژه HY-WorldPlay از شرکت Tencent با انتشار کدهای آموزش و نسخههای بهینه شده، مسیر تعاملی کردن ویدیو رو هموار کرده. ارائه نسخه ۵ میلیاردی در کنار مدل ۸ میلیاردی نشوندهنده تلاش برای مدیریت VRAM در سیستمهای محلیه. بهینهسازیهای مهندسی مثل کوانتیزاسیون مستقیم در کد استنتاج، HY-WorldPlay رو از یه پروژه تحقیقاتی به یه ابزار کاربردی برای ساخت محیطهای شبیهسازی شده و "Interactive Streaming" تبدیل کرده.
به نظر من، سال ۲۰۲۶ سالِ پیروزی مطلق DiT (Diffusion Transformers) بر معماریهای قدیمی UNet هست. ترکیب Single-stream برای درک بهتر متن و تکنیکهای Flow Matching برای سرعت بالاتر، داره فاصله بین تصور و خروجی رو به صفر میرسونه. اگه دنبال پایداری و کنترل هستید، Z-Image Base و اگه دنبال سرعت فضایی و دموهای لحظهای هستید، FLUX.2 [klein] بهترین گزینههای روی میز هستن.
📃 مخزن FLUX.2 در گیتهاب:
https://github.com/black-forest-labs/flux2
📃 مدل Z-Image در هاگینگ فیس:
https://huggingface.co/Tongyi-MAI/Z-Image
📃 پروژه HY-WorldPlay در گیتهاب:
https://github.com/Tencent-Hunyuan/HY-WorldPlay
📃 مدل Qwen-Image-2512 در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen-Image-2512
🛠 Join @LLMEngineers Community
معماری Single-stream DiT در مدل Z-Image مسیر دیگهای رو باز کرده. اینجا توکنهای متنی و بصری در یک جریان واحد (Single-stream) با هم ترکیب میشن که باعث درک بهتر جزئیات متن در تصویر میشه. برخلاف مدلهای تقطیر شده، نسخه بیس Z-Image بدون Distillation منتشر شده تا قابلیت CFG و استفاده از Negative Prompt به شکل کامل حفظ بشه. به نظر من، این حرکت برای مهندسهایی که دنبال Fine-tune کردن روی استایلهای خاص هستن حیاتیه، چون مدلهای تقطیر شده (Distilled) معمولاً انعطافپذیری لازم برای یادگیری مفاهیم جدید رو ندارن و "پخته شده" به نظر میرسن.
آپدیت Qwen-Image-2512 روی نقاط ضعف کلاسیک مدلهای نفوذی (Diffusion Models) یعنی رندر کردن متن (Typography) و رئالیسم انسانی تمرکز کرده. ارائه این مدل به صورت Diffusers-native یعنی زنجیره ابزارهای Python آماده پذیرش این مدل هستن و نیازی به بازنویسی اسکریپتهای پیچیده استنتاج نیست. تمرکز روی جزئیات طبیعی نشون میده که رقابت از "ساختن تصویر کلی" به سمت "دقت در بافت" (Fine Detail) حرکت کرده و مدلها دیگه توی کشیدن انگشتها یا متون ریز کمتر سوتی میدن.
در حوزه ویدیو و مدلهای جهان (World Models)، پروژه HY-WorldPlay از شرکت Tencent با انتشار کدهای آموزش و نسخههای بهینه شده، مسیر تعاملی کردن ویدیو رو هموار کرده. ارائه نسخه ۵ میلیاردی در کنار مدل ۸ میلیاردی نشوندهنده تلاش برای مدیریت VRAM در سیستمهای محلیه. بهینهسازیهای مهندسی مثل کوانتیزاسیون مستقیم در کد استنتاج، HY-WorldPlay رو از یه پروژه تحقیقاتی به یه ابزار کاربردی برای ساخت محیطهای شبیهسازی شده و "Interactive Streaming" تبدیل کرده.
به نظر من، سال ۲۰۲۶ سالِ پیروزی مطلق DiT (Diffusion Transformers) بر معماریهای قدیمی UNet هست. ترکیب Single-stream برای درک بهتر متن و تکنیکهای Flow Matching برای سرعت بالاتر، داره فاصله بین تصور و خروجی رو به صفر میرسونه. اگه دنبال پایداری و کنترل هستید، Z-Image Base و اگه دنبال سرعت فضایی و دموهای لحظهای هستید، FLUX.2 [klein] بهترین گزینههای روی میز هستن.
📃 مخزن FLUX.2 در گیتهاب:
https://github.com/black-forest-labs/flux2
📃 مدل Z-Image در هاگینگ فیس:
https://huggingface.co/Tongyi-MAI/Z-Image
📃 پروژه HY-WorldPlay در گیتهاب:
https://github.com/Tencent-Hunyuan/HY-WorldPlay
📃 مدل Qwen-Image-2512 در هاگینگ فیس:
https://huggingface.co/Qwen/Qwen-Image-2512
🛠 Join @LLMEngineers Community
❤4
نقشه راه هوش مصنوعی در ابتدای سال ۲۰۲۶ از "تئوریهای معماری" فاصله گرفته و کاملاً وارد قلمرو "مهندسی سیستم" شده. مدلهای جدید مثل Qwen3.5 و GLM-5 نشون دادن که جنگِ پارامترها جای خودش رو به جنگِ نرخ توکن (Throughput) و مدیریت حافظه داده. واقعیت اینه که داشتن یه مدل ۷۴۴ میلیاردی بدون زیرساخت استنتاج بهینه، عملاً بیاستفادهست.
معماری Sparse MoE حالا دیگه انتخاب اول برای اسکیل کردن مدلهاست. مدل Qwen3.5 با ۳۹۷ میلیارد پارامتر که فقط ۱۷ میلیاردش فعاله، ثابت کرد که میشه با ۵۱۲ اکسپرت به دقت مدلهای متراکم رسید ولی با هزینهای بسیار کمتر. استفاده از Gated Delta Networks و Hybrid Linear Attention توی این مدلها، مشکل همیشگی حافظه در کانتکستهای طولانی رو حل کرده. به نظر من، نکته طلایی این انتشارها Multi-Token Prediction (MTP) هست؛ تکنیکی که اجازه میده مدل در هر گام چندین توکن رو پیشبینی کنه و سرعت استنتاج رو تا ۱۹ برابر بالا ببره. این یعنی ایجنتهای هوشمند دیگه نباید ثانیهها منتظر جواب بمونن.
زیرساخت Slime نشون داد که RL (یادگیری تقویتشده) از یه مرحله فرعی در پسآموزش، به یه "سیستم توزیعشده سنگین" تبدیل شده. جدا کردن بخش تولید داده (Rollout) از بخش آموزش (Training) در Slime، اجازه میده که مدلهای MoE غولآسا با پایداری بالا تیون بشن. این یعنی ما دیگه دنبال معماری جدید نیستیم، بلکه دنبال پایپلاینهای RL پایدارتری هستیم که بتونن رفتار ایجنت رو در سناریوهای طولانی اصلاح کنن.
صوت و OCR هم دارن به سمت "نیتیو" شدن حرکت میکنن. مدلهایی مثل Voxtral Realtime و Nemotron نشون دادن که دوران تکهتکه کردن صوت (Chunking) تموم شده. ما الان مدلهای ASR با تاخیر زیر ۵۰۰ میلیثانیه داریم که مستقیماً با انکودرهای علّی (Causal) آموزش دیدن. در بخش OCR هم مدل LightOnOCR ثابت کرد که دیدگاه VLM (مدل بینایی-زبانی) برای فهم اسناد، بسیار برتر از پایپلاینهای قدیمی تشخیص و بازشناسیه. تبدیل مستقیم تصویر سند به Markdown تمیز، حالا دیگه یک مسئله حل شدهست.
تولید ویدیو هم با تکنیک QVG و کوانتیزاسیون ۲ بیتی KV-cache وارد فاز عملیاتی شده. وقتی میتونید مصرف حافظه رو ۷ برابر کم کنید بدون اینکه کیفیت ویدیو نابود بشه، یعنی امکان اجرای مدلهای جهان (World Models) روی کارتهای گرافیک معمولی فراهم شده. به نظر من، تمرکز روی بهینهسازی KV-cache مهمترین روند مهندسی در سال جاریه، چون کانتکستهای یک میلیونی بدون این تکنیکها عملاً VRAM رو منفجر میکنن.
وضعیت کانتکست طولانی هم روی ۲۶۲ هزار توکن تثبیت شده. مدلکارتها دیگه فقط بنچمارک نمیدن، بلکه دستورالعملهای دقیق سرو کردن (Serving Recipes) رو منتشر میکنن که چطور با YaRN یا اسکیپ کردن بخشهای بینایی، حافظه رو برای استدلالهای سنگین آزاد نگه داریم.
در نهایت، ما از عصر "مدلهای بزرگ" وارد عصر "سیستمهای کارا" شدیم. اگه میخواید عقب نمونید، به جای خوندن مقالات معماری، روی یادگیری زیرساختهای استنتاج مثل vLLM، SGLang و فریمورکهای RL توزیعشده مثل Slime تمرکز کنید.
📃 گزارش فنی Qwen3.5 MoE:
https://qwenlm.github.io/blog/qwen3.5/
📃 زیرساخت آموزشی Slime:
https://github.com/THUDM/slime
📃 مقاله Voxtral Realtime:
https://arxiv.org/abs/2602.11298
📃 تکنیک کوانتیزاسیون QVG:
https://arxiv.org/abs/2602.04139
🛠 Join @LLMEngineers Community
معماری Sparse MoE حالا دیگه انتخاب اول برای اسکیل کردن مدلهاست. مدل Qwen3.5 با ۳۹۷ میلیارد پارامتر که فقط ۱۷ میلیاردش فعاله، ثابت کرد که میشه با ۵۱۲ اکسپرت به دقت مدلهای متراکم رسید ولی با هزینهای بسیار کمتر. استفاده از Gated Delta Networks و Hybrid Linear Attention توی این مدلها، مشکل همیشگی حافظه در کانتکستهای طولانی رو حل کرده. به نظر من، نکته طلایی این انتشارها Multi-Token Prediction (MTP) هست؛ تکنیکی که اجازه میده مدل در هر گام چندین توکن رو پیشبینی کنه و سرعت استنتاج رو تا ۱۹ برابر بالا ببره. این یعنی ایجنتهای هوشمند دیگه نباید ثانیهها منتظر جواب بمونن.
زیرساخت Slime نشون داد که RL (یادگیری تقویتشده) از یه مرحله فرعی در پسآموزش، به یه "سیستم توزیعشده سنگین" تبدیل شده. جدا کردن بخش تولید داده (Rollout) از بخش آموزش (Training) در Slime، اجازه میده که مدلهای MoE غولآسا با پایداری بالا تیون بشن. این یعنی ما دیگه دنبال معماری جدید نیستیم، بلکه دنبال پایپلاینهای RL پایدارتری هستیم که بتونن رفتار ایجنت رو در سناریوهای طولانی اصلاح کنن.
صوت و OCR هم دارن به سمت "نیتیو" شدن حرکت میکنن. مدلهایی مثل Voxtral Realtime و Nemotron نشون دادن که دوران تکهتکه کردن صوت (Chunking) تموم شده. ما الان مدلهای ASR با تاخیر زیر ۵۰۰ میلیثانیه داریم که مستقیماً با انکودرهای علّی (Causal) آموزش دیدن. در بخش OCR هم مدل LightOnOCR ثابت کرد که دیدگاه VLM (مدل بینایی-زبانی) برای فهم اسناد، بسیار برتر از پایپلاینهای قدیمی تشخیص و بازشناسیه. تبدیل مستقیم تصویر سند به Markdown تمیز، حالا دیگه یک مسئله حل شدهست.
تولید ویدیو هم با تکنیک QVG و کوانتیزاسیون ۲ بیتی KV-cache وارد فاز عملیاتی شده. وقتی میتونید مصرف حافظه رو ۷ برابر کم کنید بدون اینکه کیفیت ویدیو نابود بشه، یعنی امکان اجرای مدلهای جهان (World Models) روی کارتهای گرافیک معمولی فراهم شده. به نظر من، تمرکز روی بهینهسازی KV-cache مهمترین روند مهندسی در سال جاریه، چون کانتکستهای یک میلیونی بدون این تکنیکها عملاً VRAM رو منفجر میکنن.
وضعیت کانتکست طولانی هم روی ۲۶۲ هزار توکن تثبیت شده. مدلکارتها دیگه فقط بنچمارک نمیدن، بلکه دستورالعملهای دقیق سرو کردن (Serving Recipes) رو منتشر میکنن که چطور با YaRN یا اسکیپ کردن بخشهای بینایی، حافظه رو برای استدلالهای سنگین آزاد نگه داریم.
در نهایت، ما از عصر "مدلهای بزرگ" وارد عصر "سیستمهای کارا" شدیم. اگه میخواید عقب نمونید، به جای خوندن مقالات معماری، روی یادگیری زیرساختهای استنتاج مثل vLLM، SGLang و فریمورکهای RL توزیعشده مثل Slime تمرکز کنید.
📃 گزارش فنی Qwen3.5 MoE:
https://qwenlm.github.io/blog/qwen3.5/
📃 زیرساخت آموزشی Slime:
https://github.com/THUDM/slime
📃 مقاله Voxtral Realtime:
https://arxiv.org/abs/2602.11298
📃 تکنیک کوانتیزاسیون QVG:
https://arxiv.org/abs/2602.04139
🛠 Join @LLMEngineers Community
🔥7❤2