همیشه با MCP مخالف بودم
خوشم نمیاد ازش 😂

با 10 هزار دلار میشه دسترسی نامحدود و همیشه رایگان به DeepSeek V4 Flash داشت.

پیش بینی: در آینده با کوچیکتر شدن و قویتر شدن مدل های لوکال این مبلغ کمتر و کمتر خواهد شد…

🛠 Join @LLMEngineers Community

Langchain vs LangGraph

Game on …

متا وزن‌های Muse Glimmer رو به‌صورت آزاد منتشر کرد... یه مدل ۳۰ میلیاردی متراکم (Dense) که برخلاف لاما، با لایسنس Apache 2.0 اومده. یعنی محدودیت استفاده تجاری نداره و کاملاً بازه.

این مدل رو برای چت کردن ساده نساختن، هدف اصلیش «ایجنت‌ها» هستن. یعنی مدل رو طوری آموزش دادن که بتونه برای یه کار چندمرحله‌ای برنامه‌ریزی کنه، از ابزارهای مختلف استفاده کنه و اگه جایی مسیر رو اشتباه رفت، خودش رو اصلاح کنه. در واقع این مدل رو از دل مدل قوی‌ترشون یعنی Muse Spark بیرون کشیدن (Distill کردن) تا رفتارهای هوشمندانه رو توی سایز کوچک‌تر داشته باشه.

از نظر فنی، معماری مدل ترکیبی از متن و تصویره. یه بخش ۲۸ میلیاردی برای متن و یه بخش ۱.۸ میلیاردی هم برای تحلیل تصویر (Perception Encoder) داره. این یعنی می‌تونه اسکرین‌شات، نمودار یا فایل‌های PDF رو مستقیم بررسی کنه. ظرفیت حافظه‌اش هم حدود ۱۳۱ هزار توکن هست که برای خوندن مستندات طولانی یا لاگ‌های حجیم سیستم عالیه.

برای ما که دنبال اجرای مدل روی سیستم خودمون هستیم، متا یه حرکت خوب زده: بهینه‌سازی مصرف رم گرافیک. اگه از نسخه‌های فشرده‌شده (۴ بیتی) استفاده کنی، بخش زبانی مدل زیر ۲۰ گیگابایت فضا می‌گیره. یعنی روی یه کارت RTX 3090 یا 4090 که ۲۴ گیگ رم دارن، راحت اجرا می‌شه و هنوز فضا برای پردازش تصویر و حافظه موقت متن باقی می‌مونه. جالب اینجاست که طبق تست‌های خودشون، این فشرده‌سازی فقط حدود ۱ درصد روی دقت مدل اثر منفی گذاشته.

یه تکنیک باحال به اسم DFlash هم اعمال کردن که یه جور حدس‌زدن کلمات بعدی توسط یه مدل خیلی کوچک‌تره (Speculative Decoding). اینجوری سرعت خروجی گرفتن روی گرافیک‌های جدید مثل 5090 تا ۳ برابر بیشتر می‌شه؛ روی مک‌های سری M4 و M5 هم بین ۱.۵ تا ۱.۸ برابر سرعت رو بالا می‌بره.

توی بنچمارک‌ها، Glimmer برای کارهای ایجنتی و منطقی (مثل MCP Atlas یا GAIA2) از مدل‌های هم‌رده‌اش مثل Gemma 4 یا Qwen 3.6 27B بهتر عمل کرده. اما یه نکته وجود داره: اگه فقط برای «کد زدن» خالص می‌خوایدش، Qwen هنوز توی تست‌های تخصصی برنامه‌نویسی امتیازهای بالاتری داره. در واقع Glimmer یه مدل «همه‌کاره» برای ایجنت‌هاست، نه فقط یه ابزار کدنویسی.

خبر مهم‌تر اینه که مدل اصلی و غول‌پیکرشون، یعنی Muse Spark 1.2 با کانتکست ۱ میلیونی هم قراره به‌زودی وزن‌هاش باز بشه.
فعلاً Glimmer برای پروژه‌های محلی مثل Hermes یا دستیارهای شخصی که قراره روی سیستم خودمون بمونن، بهترین گزینه ۳۰ میلیاردی فعلیه.


https://research.meta.ai/blog/introducing-muse-glimmer-open-agentic-model
https://huggingface.co/meta-models/Muse-Glimmer-30B
https://huggingface.co/blog/muse-glimmer

🛠 Join @LLMEngineers Community

سایت paperswithcode.co یه مرجع برای پیدا کردن بهترین مدل‌های هوش مصنوعی توی هر حوزه‌ست. برای هر تسکی، از بینایی ماشین تا پردازش متن، یه جدول امتیازات داره که نشون می‌ده کدوم مدل الان رکوردداره یا اصطلاحاً SOTA محسوب می‌شه.

توی ویدیو قابلیت جدید Ask رو می‌بینید؛ یه دستیار پژوهشی که بین هزاران مقاله می‌گرده و جواب سوالای فنی رو با منبع می‌ده. مثلاً می‌تونه معماری دو تا مدل رو با هم مقایسه کنه و مستقیم بگه کجای مقاله در موردش حرف زده شده.

مدیریت سایت با تیم Hugging Face هست و برای استخراج داده‌ها از ۱۰۸ هزار مقاله، از ایجنت‌های هوش مصنوعی استفاده کردن. هر مقاله هم لینک مستقیم به کد گیت‌هاب و دیتاسِت مربوطه‌ش رو داره. API عمومی هم باز کردن که می‌شه دیتای بنچمارک‌ها رو راحت کشید.

🛠 Join @LLMEngineers Community

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

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

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

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

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

🛠 Join @LLMEngineers Community

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

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

نسخه جدید مدل DeepSeek-V4-Pro-0813 منتشر شد!
نسخه رسمی Production مدل پرچمدار DeepSeek (جایگزین Preview آوریل).
مشخصات اصلی: • MoE با ~۱.۶T پارامتر (۴۹B فعال) • کانتکس ۱M توکن • تمرکز قوی روی Agentic Coding و Tool Use • وزن‌های MIT روی Hugging Face
در مقایسه با Fable 5 ، کلاد حدود ۵٪ بهتره توی بنچمارک‌های agentic، اما قیمتش تقریباً ۴۵ برابر بالاتره ($۱۰/$۵۰ در مقابل $۰.۴۳/$۰.۸۷).
دیپ سیک با قیمت خیلی پایین‌تر و وزن‌های باز، گزینه جذاب‌تری برای production و agentهای واقعیه.
اگر تست کردید بگید.

🛠 Join @LLMEngineers Community

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

Local.ai

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

مستقیم‌ترین مدرک یه مقاله‌ست با عنوان *Token Reduction Is Not Cost Reduction* که روی ۲۹۰۸ اجرای صورتحساب‌شده از سمت ارائه‌دهنده روی Claude Code آزمایش کرده. نتیجه؟ خروجی خام ابزارها ۳۸.۴٪ کمتر شده، ولی هزینه‌ی واقعی ۶.۸٪ بیشتر شده. تو یه آزمایش دیگه، موفقیت ویرایش کد از ۲۷ مورد اومده پایین به ۱۵ تا؛ چون فشرده‌سازی دقیقاً همون شواهد دقیق و نقطه‌های ویرایش لفظ‌به‌لفظ رو خراب کرده بود که برای اعمال پچ لازم بود.

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

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

نمونه‌های ابزارها هم همین تفاوت رو نشون می‌دن. RepoWise با وارد کردن بافت بیشتر و هوشمندانه‌تر تو هر مرحله، تعداد گام‌ها و فراخوانی ابزارها رو کم کرده. CodeGraph تو بعضی مخزن‌ها بافت باقی‌مونده‌ی بیشتری نگه داشته، ولی کار کلی کمتری انجام داده. در مقابل، Caveman و بعضی حالت‌های Ponytail نشون دادن که کوتاه‌تر کردن پاسخ می‌تونه تعداد توکن، هزینه یا زمان رو بیشتر کنه. RTK هم هشدار داده که خروجی‌های کوتاه‌تر ممکنه نشانگر موفقیت، ساختار داده، شماره‌ی خط یا حتی معنای داده رو خراب کنن.

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

🛠 Join @LLMEngineers 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 @LLMEngineers 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 رو کنترل می‌کنه و هم می‌دونه اصلاً چه چیزی ارزش ساختن داره.

x.com/AndrewYNg/article/2088302050706686198

🛠 Join @LLMEngineers Community

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

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

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

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

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

🛠 Join @LLMEngineers Community

یه ایده جالب برای بهتر کردن 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 @LLMEngineers Community