شرکت 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

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

an AI Agent is five parts ...

🛠 Join @LLMEngineers Community

معماری مدل Qwen3.8-27B ترکیبی ساخته شده؛ یعنی از ۶۴ لایه، فقط ۱۶ لایه‌اش به سبک کلاسیک توجه کامل دارند و ۴۸ لایه دیگه به‌صورت خطی (با معماری Gated DeltaNet) کار می‌کنند. این طراحی باعث شده حافظه موقت پردازش متن یا همون KV Cache بسیار سبک‌تر از مدل‌های عادی باشه و کانتکست ۲۶۲ هزار توکنی مدل روی سیستم‌های خانگی رم زیادی مصرف نکنه.

توی بنچمارک‌های رسمی برای کارهای ایجنتیک، برنامه‌نویسی و کنترل سیستم نمرات بالایی ثبت کرده (مثل شاخص ۵۲ در ارزیابی مستقل Artificial Analysis). اما در استفاده واقعی یک ضعف مشخص داره: تمایل به تفکر بیش‌ازحد یا همون Overthinking. اگر متغیر تلاش تفکر یعنی reasoning_effort رو روی حالت متوسط یا کم تنظیم نکنید، برای سوال‌های ساده توکن‌های بسیار زیادی می‌سوزونه و خروجی کند می‌شه.

واقعیت اجرای مدل روی سیستم‌ها و کارت‌های مختلف:

کارت‌های ۲۴ گیگابایت (مثل 3090 یا 4090):
نقطه تعادل مدل نسخه ۴ بیتی مثل Q4_K_M با حجم حدود ۱۷ گیگابایته. روی این کارت‌ها به راحتی اجرا می‌شه و فضای کافی برای کانتکست ۳۲ تا ۶۴ هزار توکنی باقی می‌مونه.

کارت‌های ۱۶ گیگابایت (مثل 5080 لپ‌تاپ یا 4060Ti):
نسخه ۴ بیتی کامل جا نمی‌شه. باید برید سراغ کوانت ۳ بیتی مثل UD-Q3_K_XL (حدود ۱۳.۵ گیگابایت) و برای مصرف کمتر حافظه، کش کانتکست رو هم ۴ بیتی کنید (--cache-type-k q4_0). سرعت بین ۲۰ تا ۵۰ توکن بر ثانیه میده و برای کدنویسی واقعی جوابه.

کارت‌های زیر ۱۲ گیگابایت یا ۶ گیگ (مثل 3050):
اجرای مدل عملاً منطقی نیست. نسخه‌های ۱ یا ۲ بیتی بالا میان ولی افت کیفیت در منطق و برنامه‌نویسی بسیار شدیده و سرعت با فرستادن لایه‌ها روی پردازنده اصلی به زیر ۲ توکن بر ثانیه می‌رسه.

وضعیت روی سیستم‌های مک و حافظه یکپارچه:
- مک‌های ۱۶ گیگابایت: به خاطر اشغال رم توسط سیستم‌عامل، فقط کوانت‌های خیلی ضعیف ۲ بیتی جا می‌شن که خروجی بی‌کیفیت و کندی دارن.
- مک ۲۴ گیگابایت (مثل M2 یا پایه M5 Pro): با کوانت ۳ بیتی یا ۴ بیتی هماهنگ کار می‌کنه و سرعت حدود ۸ تا ۱۵ توکن بر ثانیه می‌ده.
- مک‌های ۳۶ گیگابایت به بالا (مثل M3 Pro یا M5 Pro): محیط ایده‌آل اجرای روان نسخه ۴ بیتی با فریم‌ورک MLX و سرعت بالای ۲۰ توکن بر ثانیه است.

برای گرفتن بالاترین سرعت روی تمام سیستم‌ها، مدل دارای یک head داخلی برای حدس کلمات بعدی یا همون Multi-Token Prediction هست. با فعال کردن پیش‌بینی کمکی (Speculative Decoding)، سرعت پردازش کلمات بین ۳۰ تا ۱۰۰ درصد بدون افت دقت بالا می‌ره.

برای اجرا با Llama.cpp server روی GPU ی‌تونید از دستور بهینه‌شده زیر استفاده کنید:
llama-server -m Qwen3.8-27B-UD-Q3_K_XL.gguf -c 32768 -ngl 99 -fa on --jinja --cache-type-k q4_0 --cache-type-v q4_0 --spec-type draft-mtp --spec-draft-n-max 2

ساده‌ترین روش برای شروع سریع هم استفاده از LMstudio یا Ollama با اجرای دستور ollama run qwen3.8:27b در سیستم‌های عادی و فلگ qwen3.8:27b-mlx برای سیستم‌های اپل سیلیکون هست.

https://unsloth.ai/docs/models/qwen3.8

🛠 Join @LLMEngineers Community