LLM Engineers

INCREDIBLE Qwen 3.8 27B scored 51 on the Artificial Analysis Agentic Index Ahead of GLM 5.2 and DeepSeek V4 Pro 0813 Only behind a few SoTA models several to tens of times its size Runs on ~2-3k USD hardware btw Permanent underclass is officially cancelled

یه ایده جالب برای بهتر کردن LLM-as-a-Judge 👀

یکی از مشکلات مهم توی سیستم‌های Agentic اینه که وقتی چند جواب یا چند مسیر مختلف برای حل یک مسئله داریم، چطور بفهمیم کدومش بهتره؟

روش معمول اینه که از یک LLM به‌عنوان Judge استفاده کنیم و مثلاً بگیم:

«این دو جواب رو بررسی کن و از ۱ تا ۵ نمره بده.»

مدل هم ممکنه بگه:

Answer A → 4
Answer B → 4

خب حالا کدوم بهتره؟ 🤔

مشکل اینجاست که مدل واقعاً فقط «۴» رو نمی‌بینه؛ پشت این جواب یک Probability Distribution وجود داره. مثلاً ممکنه برای جواب A داشته باشیم:

۴ با احتمال ۵۱٪
۳ با احتمال ۳۰٪
۵ با احتمال ۱۹٪

ولی برای جواب B:

۴ با احتمال ۹۰٪
۳ با احتمال ۵٪
۵ با احتمال ۵٪

هر دو در نهایت نمره ۴ می‌گیرن، ولی مشخصه که مدل نسبت به B خیلی مطمئن‌تره.

اینجاست که ایده LLM-as-a-Verifier جالب می‌شه.

به‌جای اینکه فقط محتمل‌ترین نمره رو برداریم، کل Probability Distribution نمره‌ها رو از مدل می‌گیریم و ازش Expected Score حساب می‌کنیم.

مثلاً:

1×0.02 + 2×0.05 + 3×0.15 + 4×0.45 + 5×0.33 ≈ 4.02

پس به‌جای اینکه فقط بگیم «۴»، یک نمره دقیق‌تر مثل 4.02 داریم.

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

ولی مقاله فقط به همین محدود نمی‌شه. برای بهتر کردن Verification، سه کار دیگه هم انجام می‌ده:

🔹 Score Granularity
تعداد نمره‌های ممکن رو بیشتر می‌کنه تا تفاوت بین جواب‌ها دقیق‌تر مشخص بشه.

🔹 Repeated Evaluation
ارزیابی رو چند بار تکرار می‌کنه و میانگین می‌گیره تا نوسان نتیجه کمتر بشه.

🔹 Criteria Decomposition
به‌جای اینکه یک نمره کلی بدیم، معیارهای مختلف رو جداگانه بررسی می‌کنه؛ مثلاً Correctness، Completeness و Quality.

بعد این نمره‌ها رو با هم ترکیب می‌کنه تا بتونه بین چند جواب یا چند مسیر مختلف، گزینه بهتر رو انتخاب کنه.

نتایج هم جالبه:

Terminal-Bench V2 → 86.5%
SWE-Bench Verified → 78.2%
RoboRewardBench → 87.4%
MedAgentBench → 73.3%

نکته جالب‌تر اینه که این Continuous Score فقط برای انتخاب بهترین جواب نیست. مقاله نشون می‌ده که می‌شه ازش برای فهمیدن میزان پیشرفت یک Agent در طول حل مسئله و حتی به‌عنوان Reward در Reinforcement Learning هم استفاده کرد.

به نظرم ایده اصلی مقاله خیلی ساده و مهمه:

ما معمولاً از LLM می‌خوایم جواب تولید کنه؛ ولی شاید به همون اندازه مهم باشه که یاد بگیریم چطور جواب‌های تولیدشده رو دقیق‌تر ارزیابی کنیم.

یعنی به‌جای:

Generate → Generate → Generate

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

Generate → Verify → Select → Improve

📄 Paper:
https://arxiv.org/html/2607.05391v2

🛠 Join Community

یه theme برای Hermes Desktop ساختم به اسم Noir - Vazirmatn
تمرکزش بیشتر روی راحت‌ترشدن خواندن متن‌های فارسی توی استفاده‌ی طولانیه

فونت Vazirmatn به‌عنوان fontSans برای متن معمولی رابط کاربری استفاده می‌شه؛ یعنی نوشته‌های چت، منوها، تنظیمات، دکمه‌ها و labelها خواناتر می‌شن. برای code و terminal هم فونت‌های monospace مثل JetBrains Mono و Cascadia Code سر جاشون موندن و Vazirmatn فقط به‌عنوان fallback برای حروف فارسی وارد می‌شه.

از نظر ظاهر، theme روی پس‌زمینه‌های charcoal، متن روشن، borderهای ظریف و blue accent محدود ساخته شده تا رابط کاربری شلوغ و خسته‌کننده نشه. نصبش هم با یک command از GitHub انجام می‌شه و بعد از Reload desktop plugins از داخل Appearance قابل انتخابه.

https://github.com/mshojaei77/hermes-noir-vazirmatn-theme

🛠 Join Community

دیروز Andrew Ng یه نقشه برای مهارت‌های AI Engineering منتشر کرده که به نظرم برای انتخاب مسیر یادگیری از خیلی از لیست‌های کلیشه‌ای کاربردی‌تره. نه چون قرار باشه همه‌چیز رو پوشش بده، بلکه چون تمرکزش روی مهارت‌هایی‌ه که هم برای ساخت محصول لازم‌اند و هم برای کار کردن با Coding Agentها.

نکته‌ی کلیدی اینه که AI Engineering فقط یعنی کار با مدل یا داشتن عنوان «AI Engineer» نیست. طبق تحلیل تیم Andrew Ng از بیش از ۱۰هزار آگهی شغلی، مصاحبه با متخصص‌ها، مدیرهای استخدام و داده‌های آنلاین، چهار مهارت اصلی این‌ها هستند:

• ساخت و Deploy کردن AI Applicationها
• مبانی Software Engineering
• استفاده‌ی مؤثر از Coding Agentها
• شکل‌دادن به خود مسئله و محصول

اصل داستان در ساخت AI Application اینه که خروجی سیستم قابل‌پیش‌بینی نیست. برای همین فقط بلد بودن LLM، RAG یا Agentic Workflow کافی نیست؛ باید بتونی با Evals، تحلیل خطا و روش‌های آماری رفتار سیستم رو اندازه بگیری، هدایتش کنی و قابل‌کنترل‌تر نگهش داری.

از طرف دیگه، مبانی Software Engineering حتی با وجود Agentها مهم‌تر شده. کسی که trade-offهای cost، scalability، reliability، security و privacy رو نمی‌شناسه، عملاً نمی‌فهمه Agent چه تصمیم‌هایی برای معماری و کد گرفته. نتیجه معمولاً یه راه‌حل سریع و شکننده‌ست؛ چیزی که شاید تو دمو جواب بده، ولی تو production نه.

مهارت کار با Coding Agent هم فقط prompt نوشتن نیست. باید context رو مدیریت کنی، بدونی کجا planning لازمه و کجا نه، برای Agent verifier و eval بسازی، چندتا Agent رو درست orchestrate کنی و حواست باشه یه اشتباه ساده به production database نرسه. یعنی Agent بیشتر شبیه همکار سریعیه که باید با تست و محدودیت هدایتش کنی، نه یه دکمه‌ی جادویی برای جایگزین کردن مهندسی.

اما بخش چهارم شاید از همه مهم‌تر باشه: shaping the build. وقتی Agentها تو اجرای spec بهتر می‌شن، ارزش مهندس فقط تو نوشتن کد نیست؛ تو تشخیص مسئله‌ی درست، فهم business context، تصمیم‌گیری درباره‌ی MVP و دونستن زمان مناسب برای سرعت گرفتن یا دقیق‌تر ساختن هم هست.

به نظر من پیام اصلی این نقشه ساده‌ست: آینده فقط مال کسی نیست که مدل بیشتری می‌شناسه. کسی جلوتره که هم سیستم AI می‌سازه، هم Software Engineering رو می‌فهمه، هم Agent رو کنترل می‌کنه و هم می‌دونه اصلاً چه چیزی ارزش ساختن داره.

http://x.com/AndrewYNg/article/2088302050706686198

🛠 Join Community

یه اشتباه رایج اینه که فکر کنیم برای فشرده سازی کانتکس ( context compaction) کافیه فقط آخر چت طولانی یه خلاصه درست کنیم. ولی وقتی داریم با Agentهایی کار می‌کنیم که چند ساعت یا چند روز فعالن و state نگه می‌دارن، خلاصه‌نویسی ساده کافی نیست.

اصل قضیه اینه که context window حافظه کاری مدله، نه کل حافظه سیستم. پس اطلاعات کلیدی مثل شناسه، مبلغ، تاریخ و ارجاعات باید دقیق ذخیره بشن یا به جاهای قابل بازیابی اشاره کنن، بعد یه خلاصه ساختاریافته برای حفظ پیوستگی ساخته بشه.

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

خلاصه اینکه compaction شبیه checkpoint کردن و جمع‌آوری زباله کردن حافظه است تا یه خلاصه ساده چت. اطلاعات کمتری داخل context باشه ولی سیستم بتونه به راحتی بازیابی کنه و قابل حسابرسی باشه.

- http://developers.openai.com/api/docs/guides/compaction
- http://platform.claude.com/docs/en/build-with-claude/compaction
- http://google.github.io/adk-docs/context/compaction/
- http://docs.openclaw.ai/concepts/compaction
- http://arxiv.org/html/2608.01326v1

🛠 Join Community

مشکل اصلی خیلی از این ابزارای «کاهش توکن» اینه که کم شدن توکن توی یه پاسخ ابزار، لزوماً معنی‌ش این نیست که کل ایجنت ارزون‌تر یا سبک‌تر کار می‌کنه. ایجنت یه حلقه‌ی بازخوردی چندمرحله‌ایه؛ اگه اطلاعات مهم رو حذف کنی، ممکنه مجبور بشه دوباره جست‌وجو کنه، فایل رو بخونه، ابهام رو رفع کنه و حتی پچ یا تست رو تکرار کنه. یعنی یه جورایی مثل اینه که حین بازی، نصف نقشه‌ی مهم رو پاک کنی و بعد مجبور شی دوباره بری همونجا رو کشف کنی.

مستقیم‌ترین مدرک یه مقاله‌ست با عنوان https://arxiv.org/abs/2607.12161که روی ۲۹۰۸ اجرای صورتحساب‌شده از سمت ارائه‌دهنده روی Claude Code آزمایش کرده. نتیجه؟ خروجی خام ابزارها ۳۸.۴٪ کمتر شده، ولی هزینه‌ی واقعی ۶.۸٪ بیشتر شده. تو یه آزمایش دیگه، موفقیت ویرایش کد از ۲۷ مورد اومده پایین به ۱۵ تا؛ چون فشرده‌سازی دقیقاً همون شواهد دقیق و نقطه‌های ویرایش لفظ‌به‌لفظ رو خراب کرده بود که برای اعمال پچ لازم بود.

علتش کاملاً قابل‌فهمه: فشردن ۱۰ هزار توکن به ۲ هزار فقط وقتی صرفه‌جویی حساب می‌شه که همون ۲ هزار تا برای تصمیم بعدی کافی باشه. اگه نباشه، مسیر می‌شه «جست‌وجو ← خواندن ← استدلال ← تلاش مجدد» و هر مرحله ممکنه بافت قبلی رو دوباره به مدل بفرسته. ضمن اینکه تو همون مطالعه، حدود ۸۷٪ هزینه‌ی بازسازی‌شده مربوط به ساخت و خواندن حافظه‌ی سریع درخواست بوده، نه صرفاً خروجی ابزارها. یعنی بخش عمده‌ی صورتحساب، همون چیزاییه که مرتب دوباره خونده می‌شه، نه متن تازه‌ی ابزار.

البته نتیجه این نیست که هر نوع فشرده‌سازی بده. پژوهش‌های ACL و EMNLP نشون می‌دن فشرده‌سازی شدید و کور می‌تونه اطلاعات کلیدی رو حذف کنه و عملکرد کارهای پیچیده رو خراب کنه؛ ولی روش‌های آگاه از پرسش و انتخاب محتوای مرتبط گاهی هم کیفیت رو بهتر می‌کنن و هم توکن کمتری می‌خورن. مسئله فقط مقدار اطلاعات نیست؛ اطلاعات نامرتبط و بدجای‌گذاری‌شده هم می‌تونه مدل رو گیج کنه.

نمونه‌های ابزارها هم همین تفاوت رو نشون می‌دن. https://github.com/repowise-dev/repowise با وارد کردن بافت بیشتر و هوشمندانه‌تر تو هر مرحله، تعداد گام‌ها و فراخوانی ابزارها رو کم کرده. https://github.com/colbymchenry/codegraph تو بعضی مخزن‌ها بافت باقی‌مونده‌ی بیشتری نگه داشته، ولی کار کلی کمتری انجام داده. در مقابل، Caveman و بعضی حالت‌های Ponytail نشون دادن که کوتاه‌تر کردن پاسخ می‌تونه تعداد توکن، هزینه یا زمان رو بیشتر کنه. RTK هم هشدار داده که خروجی‌های کوتاه‌تر ممکنه نشانگر موفقیت، ساختار داده، شماره‌ی خط یا حتی معنای داده رو خراب کنن.

پس معیار درست «درصد توکن ذخیره‌شده» نیست. باید هزینه‌ی واقعی هر کار موفق رو سنجید: موفقیت کار، هزینه‌ی صورتحساب‌شده، تعداد نوبت‌ها، ترافیک حافظه‌ی سریع، تلاش مجدد، جست‌وجوهای تکراری، فراخوانی ابزارها، زمان و سربار خود فشرده‌ساز. نتیجه‌ی عملی اینه: فشرده‌سازی باید انتخابی، آگاه از کار، قابل‌بازگشت و روی کل مسیر ارزیابی بشه. ابزاری که فقط «توکن کمتر» رو گزارش می‌کنه، هنوز ثابت نکرده که ایجنت رو ارزون‌تر یا کارآمدتر کرده.

🛠 Join Community

تیم EXO Labs پلتفرم https://local.ai/shojaei/invite را در فاز دسترسی زودهنگام راه‌اندازی کرده است؛ پلتفرمی تخصصی برای اندازه‌گیری عملکرد واقعی مدل‌های هوش مصنوعی روی سخت‌افزار محلی.
چه چیزی ارائه می‌ده؟
بنچمارک‌های مستقل روی سخت‌افزار واقعی (Mac، RTX، DGX و…)
• معیارهای دقیق: سرعت، هزینه، مصرف انرژی و قابلیت‌های مدل
مرتبط با پروژه متن‌باز exo برای کلاستر کردن دستگاه‌های محلی و اجرای مدل‌های بزرگ به‌صورت خصوصی

https://local.ai/shojaei/invite

شرکت Unsloth اپ دسکتاپش رو منتشر کرد؛ اولین اپلیکیشنی که هم اجرا و هم فاین‌تیون مدل‌ها رو کامل لوکال روی سیستم خودت میاره. متن‌بازه و روی مک، ویندوز و لینوکس کار می‌کنه.

فایده‌ش برای کساییه که نمی‌خوان مدل‌هاشون به جای دیگه‌ای بره. از MLX و GGUF بگیر تا مدل‌های دیفیوژن تصویر/ویدیو و صدا رو پشتیبانی می‌کنه، و از همه جالب‌تر اینکه می‌شه Claude Code و Codex رو به LLMهای محلی وصل کرد. علاوه بر اون یه API سازگار با OpenAI هم داره که مثل یه سرور شخصی، مدل‌های محلی و ابری رو در دسترس قرار می‌ده — حتی استقرار از راه دور و دسترسی از هر جا هم براش در نظر گرفتن.

طبق ادعای خودشون، فراخوانی ابزارها (tool calls) ۵۰٪ دقیق‌تر و خودترمیم‌شونده‌ست با اجرای کد توی محیط ایزوله (sandbox)، آموزش مدل هم ۲ برابر سریع‌تر با ۷۰٪ حافظه VRAM کمتر انجام می‌شه. جستجوی وب خصوصی، deep research، RAG و MCP هم داخلش هست.

اگه دنبال یه راه‌حل متن‌باز برای اجرا و فاین‌تیون مدل‌های لوکال بودی، این یه گزینه جدیه. دانلود و مستنداتش از http://unsloth.ai/ و گیت‌هاب در دسترسه:

- https://github.com/unslothai/unsloth
- https://unsloth.ai/docs/desktop

🛠 Join Community

بالاخره جامعهٔ ساخت هوش مصنوعی فارسی متن‌باز رو عمومی کردیم.
اینجا قراره روی مدل‌های زیر کار کنیم:
شنوا (تشخیص گفتار)
گویا (تبدیل متن به گفتار)
بینا (بینایی و OCR)
دانا (مدل زبانی)
دادگان (دیتاست‌ها)

هر کی دوست داره بیاد کمک کنه یا ایده بده، خوشحال می‌شیم.
لینک گروه:
https://t.me/PersianML
هاگینگ‌فیس:
https://huggingface.co/PersianML

Game on …

بعد از لیدربورد کنکور، لازم بود یه بنچمارک جدی برای سنجش "روانیِ کلام" (Linguistic Fluency) داشته باشیم تا بفهمیم کدوم مدل مثل یه آدم حسابی فارسی حرف می‌زنه و کدوم یکی فقط کلمات رو پشت هم قطار می‌کنه. توی این لیدربورد که خودم طراحیش کردم، پارامترهایی مثل رعایت قواعد دستوری، لحن طبیعی (Naturalness) و اصطلاحات (Idiomatic) رو با داوری Gemini 2.5 Flash سنجیدم تا عمقِ فهم زبانی مدل‌ها مشخص بشه.

معماری MoE در مدل Qwen3-30B-A3B باز هم صدرنشین شد. این مدل با امتیاز ۴۲.۱ نشون داد که توی "پیروی از دستورات" (Instruction Following) و "حفظ کانتکست" فوق‌العاده عمل می‌کنه. با اینکه توی بخش گرامر از مدل‌های گوگل ضعیف‌تره، ولی توی خروجی نهایی، پکیج کامل‌تری برای بیزنس و چت‌بات‌های فارسی ارائه میده.

گوگل با Gemini 2.5 و خانواده Gemma 3 توی "گرامر" و "طبیعی بودن" (Naturalness) امتیازات بالایی گرفتن، اما توی "ایمنی" (Safety) و "پیروی از محدودیت‌های پرامپت" (Instruction Following) قافیه رو به Qwen و Saba باختن. این یه نکته سینیوریه: مدل‌های گوگل خیلی "کتابی" و تمیز حرف می‌زنن، اما وقتی بهشون دستور میدی که با یه لحن خاص یا محدودیت خاص بنویسن، انعطاف‌شون کمتر میشه.

به نظر من، اگه اولویت شما "لحن طبیعی" و "حفظ کانتکست" در مکالمات فارسیه، Qwen3 بهترین خروجی رو بهتون میده. گوگل برای ویراستاری و چک کردن گرامر عالیه، اما برای یه دیالوگِ روون که کاربر حس نکنه داره با ربات حرف می‌زنه، هنوز مدل‌های MoE و تیون‌شده روی دیتای فارسی جلوترن.


🏆 لیدربورد روانی کلام فارسی (Persian Linguistic Fluency):
https://huggingface.co/spaces/mshojaei77/Persian-linguistic-llm-leaderboard

🛠 Join Community

لیدربورد کنکور ۱۴۰۴ برای سنجش مدل‌های هوش مصنوعی روی دانش فارسی راه‌اندازی شد!

فقط مدل‌های اوپن سورس با قابلیت‌ پردازش متن (LLM) و پردازش تصویر (VLM) در این رقابت حضور دارند.

🏆 https://huggingface.co/spaces/mshojaei77/konkur1404-llm-leaderboard

pinned «لیدربورد کنکور ۱۴۰۴ برای سنجش مدل‌های هوش مصنوعی روی دانش فارسی راه‌اندازی شد! فقط مدل‌های اوپن سورس با قابلیت‌ پردازش متن (LLM) و پردازش تصویر (VLM) در این رقابت حضور دارند. 🏆 https://huggingface.co/spaces/mshojaei77/konkur1404-llm-leaderboard»

مدل‌های تولید تصویر و ویدیو در ابتدای سال ۲۰۲۶ از مرحله "فقط پیکسل ساختن" رد شدن و دارن روی دو جبهه متضاد اما مکمل حرکت می‌کنن: سرعت دیوانه‌وار برای مصرف‌کننده نهایی و کنترل‌پذیری عمیق برای مهندس‌ها. خانواده 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 Community

نقشه راه هوش مصنوعی در ابتدای سال ۲۰۲۶ از "تئوری‌های معماری" فاصله گرفته و کاملاً وارد قلمرو "مهندسی سیستم" شده. مدل‌های جدید مثل 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 Community

بنچمارک‌های عمومی هوش مصنوعی معمولاً برای زبان فارسی نیستن و اصلاً عمق فهم مدل رو نشون نمی‌دن. برای همین خودم دست‌به‌کار شدم و لیدربورد کنکور ۱۴۰۴ (نوبت اول) رو راه انداختم تا ببینم این مدل‌های متن‌باز واقعاً توی استدلال‌های پیچیده و زبان فارسی چند مرده حلاج‌ان. کنکور به خاطر ترکیب سوالات مفهومی، محاسباتی و تصاویر هندسی، عملاً سخت‌ترین تست برای سنجش Reasoning و Multimodal بودن یک مدله.

معماری MoE توی این تست ثابت کرد که پادشاه بلامنازع هست. مدل Qwen3-VL-235B با ۲۲ میلیارد پارامتر فعال، نه تنها در بخش متنی اول شد، بلکه توی بخش بینایی هم با اختلاف بقیه رو جا گذاشت. برای من به عنوان یه مهندس، رتبه سوم Qwen3-Next-80B جذاب‌تره؛ این مدل با فقط ۳ میلیارد پارامتر فعال (Active Parameters) تونسته مدل‌های غولی مثل Llama-3.1-70B رو شکست بده. این یعنی بهینه‌سازی معماری و کیفیت داده، خیلی بیشتر از تعداد خام پارامترها توی زبان فارسی تاثیر داره.

شکاف بین Text-only Score و Standard Score نشون‌دهنده یه حقیقت تلخه: مدل‌ها هنوز توی فهم تصاویر فارسی (OCR بصری و تحلیل نمودار) لنگ می‌زنن. وقتی سوال تصویری میشه، دقت اکثر مدل‌ها سقوط می‌کنه. اگه قصد دارید سیستم آموزشی یا ایجنتی بسازید که با داکیومنت‌های فارسی سر و کار داره، فعلاً باید روی خانواده Qwen3 حساب کنید. مدل Kimi-k2 هم نشون داد که توی استدلال متنی (Text Reasoning) فوق‌العاده‌ست، هرچند که توی بخش بینایی کلاً حضور نداره.

به نظر من، این لیدربورد نشون داد که عصر مدل‌های Dense تموم شده. اگر پروژه‌ای دارید که نیاز به فهم عمیق فارسی و استدلال داره، وقتتون رو روی مدل‌هایی که MoE نیستن تلف نکنید. این نتایج ثابت می‌کنه که "کارایی سیستم" (System Efficiency) و "تخصص اکسپرت‌ها" توی MoE، کلید حل پازل زبان‌های پیچیده‌ای مثل فارسیه.

🏆 لیدربورد کنکور ۱۴۰۴ در هاگینگ فیس:
https://huggingface.co/spaces/mshojaei77/konkur1404-llm-leaderboard

🛠 Join Community

مدل 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 Community

دنیای مدل‌های بینایی-زبانی (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 Community

مدل 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 Community

اکوسیستم صوتی 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 Community

مدل‌های سری 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 Community

مدل 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 Community