Top Non-Reasoning Modes

یه نکته قابل توجه اینه که قویترین مدل توی دسته مدل های none-reasoning (که بنظر من کاربردی ترن) یه مدل اوپن سورس هست.

🛠 Join @LLMEngineers Community

یه مدل اپن‌سورس جدید از چین منتشر شده که رقابت با مدل‌های کلوز-سورس رو خیلی جدی‌تر کرده.

مدل اصلی GLM-4.5 یه MoE با ۳۵۵ میلیارد پارامتره که ۳۲ میلیارد پارامترش در لحظه فعاله. نسخه سبک‌تر، GLM-4.5-Air هم یک مدل MoE با ۱۰۶ میلیارد پارامتر کل و ۱۲ میلیارد پارامتر فعاله.

عملکردشون توی بنچمارک‌ها قابل توجهه. GLM-4.5 در مجموع تقریباً پا به پای GPT-4o و Grok 4 حرکت می‌کنه. به طور خاص توی تسک‌های Agentic فوق‌العاده قویه و جایگاه دوم رو داره. توی Reasoning هنوز از تاپ‌های مارکت مثل Gemini 2.5 Pro و Grok 4 ضعیف‌تره ولی در حوزه Coding جزو سه تای اوله.

📃 لینک مدل:
https://huggingface.co/zai-org/GLM-4.5

🛠 Join @LLMEngineers Community

اینم کار قبلی این تیم بود, مشخصه تیم قوی ای دارن

مدلای GLM-4.5 و GLM-4.5-Air از لحاظ فنی نکات عمیق و قابل توجهی دارن و صرفاً یه مدل جدید تو لیدربوردها نیستن.

در بحث معماری، این مدل‌ها از MoE استفاده می‌کنن اما با یک تفاوت فلسفی مهم. تیم سازنده به جای عریض کردن مدل (یعنی hidden dimension بزرگ‌تر و تعداد expertهای بیشتر)، روی عمیق‌تر کردن اون (یعنی افزایش تعداد لایه‌ها) تمرکز کرده. استدلالشون اینه که مدل‌های عمیق‌تر، ظرفیت reasoning بهتری از خودشون نشون می‌دن. توی لایه‌های MoE هم از مکانیزم loss-free balance routing و sigmoid gates استفاده شده.
در بخش self-attention، از Grouped-Query Attention یا GQA به همراه partial RoPE استفاده کردن که دیگه تقریباً استاندارد شده. نکته جالب اینجا تعداد attention headهاست که ۲.۵ برابر بیشترش کردن (۹۶ هد برای hidden dimension پنج هزار و صد و بیست). به شکل عجیبی، این کار training loss رو بهتر نکرده ولی در بنچمارک‌های reasoning مثل MMLU و BBH به طور مداوم عملکرد رو بالا برده. برای پایداری attention logits هم از QK-Norm کمک گرفتن.

یکی از مهم‌ترین و کاربردی‌ترین نوآوری‌ها، اضافه شدن یک لایه Multi-Token Prediction یا MTP به معماریه. این لایه مستقیماً برای پیاده‌سازی speculative decoding طراحی شده و طبق ادعای مقالات مرتبط، می‌تونه سرعت inference رو بین ۲.۵ تا ۵ برابر بیشتر کنه. این یعنی اجرای مدل‌های MoE سنگین روی سخت‌افزارهای معمولی به شکل قابل توجهی بهینه‌تر می‌شه و این یک خبر فوق‌العاده برای اجرای مدل هاست.
یک قابلیت دیگه، Hybrid reasoning هست که دو حالت thinking mode و non-thinking mode رو ارائه می‌ده. حالت thinking برای مسائل پیچیده و استفاده از toolهاست که توکن بیشتری مصرف می‌کنه و حالت non-thinking برای پاسخ‌های سریع و آنی طراحی شده. این به کاربر اجازه می‌ده بین هزینه و عمق تحلیل، توازن ایجاد کنه.

برای ترینینگ، از حدود ۱۵ تریلیون توکن دیتاست عمومی و ۷ تریلیون توکن دیتاست تخصصی کد و reasoning استفاده شده. همچنین به جای اپتیمایزرهای رایج، از Muon optimizer استفاده کردن (مث kimi k2) که هم سرعت همگرایی رو بالا می‌بره و هم اجازه استفاده از batch sizeهای بزرگتر رو می‌ده.
در فاز Reinforcement Learning، زیرساخت اختصاصی خودشون به نام slime رو توسعه دادن که انعطاف‌پذیری و مقیاس‌پذیری بالایی داره. معماری slime به صورت decoupled طراحی شده، یعنی موتورهای rollout (که دیتا تولید می‌کنن) از موتورهای ترینینگ جدا هستن و می‌تونن روی سخت‌افزارهای مجزا به صورت موازی اجرا بشن. این مشکل گلوگاه بودن تولید دیتا در تسک‌های ایجنتی رو حل می‌کنه. برای سرعت بیشتر هم از mixed-precision استفاده می‌کنن؛ یعنی دیتا با FP8 تولید می‌شه ولی ترینینگ با BF16 انجام می‌شه. در نهایت هم از expert distillation برای تجمیع توانایی‌های تخصصی در مدل نهایی استفاده کردن.


📃 گزارش فنی مدل‌ها:
https://z.ai/blog/glm-4.5

🛠 Join @LLMEngineers Community

بحث مدل‌های کدنویسی که به صورت لوکال اجرا میشن دیگه از فاز تئوری خارج شده و کاملاً کاربردی شده. اخیراً یه نفر مدل GLM-4.5 Air رو روی یه مک‌بوک M2 با ۶۴ گیگ رم تست کرده و ازش خواسته یه بازی Space Invaders با جاوااسکریپت بنویسه. نتیجه یه فایل HTML و JS کامل بود که همون بار اول، بدون هیچ تغییری، اجرا شد و یه بازی کامل تحویل داد.

مدل GLM-4.5 Air در حالت اصلی ۱۰۶ میلیارد پارامتر داره (حدود ۲۰۶ گیگابایت)، اما نسخه‌ی کوانتایز شده‌ی ۳ بیتی اون برای MLX به ۴۴ گیگابایت رسیده که دقیقاً برای اجرا روی سیستم‌های ۶۴ گیگابایتی بهینه شده. موقع اجرا، مدل حدود ۴۸ گیگابایت از رم رو اشغال کرد. مدل قبل از تولید کد، توی بلاک <think> قدم به قدم برنامه‌ش برای ساخت بازی رو توضیح داد و بعد کد رو نوشت. این نشون‌دهنده یه پروسه استدلال داخلی خوبه.

برای مقایسه، مدل Qwen3-30B رو هم روی همین تسک تست کردم. با اینکه رم کمتری (حدود ۳۰ گیگ) نیاز داشت، کدی که تولید کرد کار نکرد و بازی اجرا نشد. به نظر من، این تفاوت در نتیجه‌گیری نشون میده که قابلیت "reasoning" در مدل‌های هیبریدی مثل GLM-4.5، در مقایسه با مدل‌های non-reasoning، تاثیر مستقیم روی کیفیت و صحت کد خروجی داره و باعث میشه کد پیچیده‌تر و سالم‌تری تولید کنن.

این روزها دیگه تقریبا تمام مدل‌های جدید با تمرکز ویژه روی کدنویسی منتشر میشن و این تمرکز داره نتیجه میده. اینکه یه لپ‌تاپ می‌تونه مدلی با این توانایی رو اجرا کنه، پیشرفت بزرگیه.

🛠 Join @LLMEngineers Community

معماری مدل ترکیب هوشمندانه‌ای از دو تکنیک کلیدیه:
یکی MOE مدل از مجموع ۳۰.۵ میلیارد پارامتر، فقط ۳.۳ میلیارد پارامتر رو در هر لحظه فعال می‌کنه. این یعنی از بین ۱۲۸ "متخصص"، فقط ۸ تای برتر برای پردازش هر توکن انتخاب می‌شن. نتیجه این کار، کاهش شدید بار محاسباتیه.

دوم، ترکیب این معماری با Grouped-Query Attention یا GQA. با داشتن ۳۲ تا Attention Head برای کوئری و فقط ۴ سر برای کلید و مقدار، مصرف حافظه VRAM برای نگهداری KV Cache به شکل چشمگیری کم می‌شه. این دو ویژگی با هم، مدلی سریع و سبک تحویل می‌دن که روی سخت‌افزارهای قابل دسترس اجرا می‌شه.

ترکیب MoE + GQA = سرعت بالاتر + حافظهٔ کمتر + قابلیت اجرای خانگی

با حذف تگ‌های <think> و اجرا در حالت non-reasonong باعث پاسخ‌های تمیزتر و سریع‌تر شده

این مدل برای ساختن ایجنت‌های محلی (Local Agents) که نیاز به تعامل با ابزارهای خارجی دارن، خیلی کاربردیه. مثلاً یه دستیار کدنویسی که روی سیستم خودتون اجرا می‌شه و می‌تونه فایل‌ها رو بخونه، دستورات شل رو اجرا کنه یا به API های دیگه وصل بشه، بدون اینکه به سرویس‌های پولی و آنلاین وابسته باشید. گفته شده می‌تونه چندین Tool Call زنجیره‌ای رو با دقت خوبی انجام بده؛ کاری که قبلاً نقطه ضعف مدل‌های محلی در مقایسه با GPT یا Claude بود.

اجرای لوکال مدل Qwen3-30B-A3B بسته به کوانتایز های مختلف داره، به صورت میانگین حدود ۱۸ گیگ VRAM نیاز داره.

🛠 Join @LLMEngineers Community

اینجا یه راهنمای عملی برای اجرای این مدل روی سخت‌افزارهای مختلف با استفاده از نسخه‌های کوانتایز شده جمع‌آوری شده. (quantization یعنی فشرده‌سازی مدل برای کاهش مصرف حافظه و افزایش سرعت، که طبیعتاً با مقداری افت کیفیت همراهه)

هدف اینه که بتونید این مدل رو حتی روی سیستم‌های با منابع محدودتر مثل کارت‌های گرافیک گیمینگ یا مک‌بوک‌ها اجرا کنید.

نسخه‌های مختلف مدل و روش‌های اجرا

برای اجرای مدل Qwen3 گزینه‌های مختلفی وجود داره که هر کدوم برای یک سناریو مناسبن:

نسخه‌ی پایه (BF16): این همون مدل اصلی و بدون فشرده‌سازیه. بیشترین دقت رو داره ولی سنگین‌ترینه. برای اجراش موتورهایی مثل vLLM یا SGLang روی سرورهای قوی با چند کارت گرافیک مناسبن. دستور vllm serve با tensor-parallel-size به همین منظور استفاده می‌شه.

نسخه‌ی GGUF: این فرمت به شدت محبوبه چون روی طیف وسیعی از سخت‌افزارها (شامل CPU و GPU های مختلف و مک) به خوبی کار می‌کنه. llama.cpp، Ollama و LMStudio بهترین ابزارها برای اجرای این فرمت هستن. Unsloth نسخه‌های بهینه‌ای از GGUF رو با کوانتیزیشن‌های مختلف منتشر کرده (مثل Q4_K_M, Q5_K_M, Q8_0). قانون کلی اینه که هرچی عدد کوانتیزیشن پایین‌تر باشه مدل کم‌حجم‌تر و سریع‌تره ولی دقتش پایین‌تر میاد. نسخه‌های _K_M معمولاً تعادل خوبی بین حجم و کیفیت دارن.

نسخه‌ی GPTQ: این فرمت برای کوانتیزیشن روی GPU های انویدیا بهینه شده. اگه سرور با GPU انویدیا دارید و می‌خواید از vLLM استفاده کنید، GPTQ با کوانتیزیشن ۴ بیت (Int4) یا ۸ بیت (Int8) گزینه‌ی خیلی خوبیه.

نسخه‌ی FP8: این یه روش کوانتیزیشن جدیده که بازدهی بالایی داره. موتورهای مدرنی مثل vLLM و SGLang از این فرمت پشتیبانی می‌کنن و می‌تونه جایگزین خوبی برای GPTQ باشه.

نسخه‌ی MLX: این فرمت اختصاصاً برای اجرا روی سخت‌افزارهای اپل سیلیکون (M1/M2/M3/M4) طراحی شده و بهترین پرفورمنس رو روی مک می‌ده. اگه کاربر مک هستید، حتماً از این نسخه استفاده کنید.

به نظر من، برای اکثر کاربرایی که می‌خوان مدل رو به صورت محلی تست کنن، ساده‌ترین و بهترین راه استفاده از فرمت GGUF هست. می‌تونید با ابزارهای ساده‌ای مثل LMStudio (که رابط گرافیکی داره) یا Ollama (که با یک دستور ساده مدل رو اجرا می‌کنه) راه‌اندازیش کنید.
اگه هدف‌تون سرویس‌دهی (Serving) با پرفورمنس بالا روی سرور مجهز به GPU انویدیاست، vLLM به همراه نسخه‌ی GPTQ یا FP8 انتخاب حرفه‌ای‌تریه.

🛠 Join @LLMEngineers Community

هاگینگ فیس یه کتابخونه جدید برای experiment tracking به اسم Trackio منتشر کرده. این ابزار برای ردگیری متریک‌ها، پارامترها و هایپرپارامترهای مدل‌های ماشین لرنینگ حین آموزش استفاده می‌شه.

کاربرد اصلیش اینه که یه جایگزین خیلی سبک و رایگان برای ابزارهایی مثل wandb باشه. نکته کلیدیش اینه که به عنوان یه drop-in replacement طراحی شده. یعنی کافیه توی کدتون import wandb رو به import trackio as wandb تغییر بدید و بقیه‌ی کد که از wandb.init و wandb.log استفاده می‌کنه، بدون تغییر کار می‌کنه.

مزایای کلیدیش ایناست:

Local-first: تمام لاگ‌ها و داشبورد به‌صورت پیش‌فرض روی سیستم خودتون ذخیره و اجرا می‌شه. دیگه نیازی به اینترنت یا سرویس‌های ابری برای دیدن نتایج اولیه نیست.

رایگان و متن‌باز: تمام قابلیت‌هاش، حتی هاست کردن داشبورد روی Hugging Face Spaces، رایگانه.

یکپارچگی با اکوسیستم Hugging Face: به‌صورت نیتیو با کتابخونه‌های transformers و accelerate کار می‌کنه.

اشتراک‌گذاری ساده: می‌تونید داشبوردتون رو با یه space_id روی Hugging Face Spaces سینک کنید و به راحتی با بقیه به اشتراک بذارید. حتی می‌شه با iframe توی بلاگ‌پست یا داکیومنت‌ها embed کرد.

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

pip install trackio

بعد توی کدتون لاگ‌ها رو ثبت می‌کنید و در نهایت با دستور trackio show توی ترمینال، داشبورد رو به‌صورت لوکال بالا میارید تا نتایج رو ببینید. دیتای لاگ‌ها هم هر ۵ دقیقه روی یک Hugging Face Dataset بکاپ گرفته می‌شه تا در صورت ری‌استارت شدن Space از بین نره.

به نظر من، Trackio برای پروژه‌های شخصی، تیم‌های کوچیک و کارهای تحقیقاتی که نمی‌خوان درگیر پیچیدگی و هزینه‌های ابزارهای بزرگتر بشن، یه گزینه‌ی عالیه. سادگی و local-first بودنش بزرگترین مزیتشه.
اما باید واقع‌بین بود. این کتابخونه هنوز تو فاز بتا قرار داره و قابلیت‌های پیشرفته‌ای مثل artifact management یا مصورسازی‌های خیلی پیچیده که توی wandb یا MLflow پیدا می‌شه رو نداره. اگه تیم بزرگی دارید و به این فیچرهای enterprise احتیاج دارید، Trackio هنوز به اون سطح از بلوغ نرسیده.

📃 معرفی کتابخانه Trackio در بلاگ Hugging Face

🛠 Join @LLMEngineers Community

گوگل یه چالش هکاتون برای مدل جدیدش Gemma 3n گذاشته که ۱۵۰ هزار دلار جایزه داره و حدود یک هفته دیگه تموم می‌شه. هدف، ساختن محصولی برای حل یه مشکل واقعیه، نه صرفا یه چت‌بات دیگه. تمرکز اصلی روی محصولاتیه که تأثیر واقعی دارن و از قابلیت‌های خاص این مدل استفاده می‌کنن.

مدل Gemma 3n چندتا ویژگی کلیدی داره که کار رو متفاوت می‌کنه:

اجرا روی دستگاه (On-Device): معماریش برای موبایل و دستگاه‌های با منابع محدود بهینه شده. با تکنیکی به اسم Per-Layer Embeddings یا PLE، مدل‌های 5B و 8B، حافظه‌ای معادل مدل‌های 2B و 4B مصرف می‌کنن که برای اجرا روی دیوایس عالیه.

معماری انعطاف‌پذیر: یه قابلیت mix’n’match داره که اجازه می‌ده یه مدل 4B به عنوان یه ساب‌مدل 2B هم استفاده بشه. اینطوری می‌شه بین پرفورمنس و کیفیت، بالانس ایجاد کرد.

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

چند وجهی (Multimodal): این مدل می‌تونه ترکیبی از صدا، متن و تصویر رو به صورت interleaved پردازش کنه و درک ویدیوی بهتری هم داره.

جوایز به دو بخش تقسیم می‌شن:

جوایز اصلی: ۱۰۰ هزار دلار در کل، که ۵۰ هزار دلار برای مقام اوله.

جوایز تکنولوژی خاص: پنج جایزه ۱۰ هزار دلاری برای بهترین پروژه‌ها که از ابزارهای مشخصی استفاده کردن:

LeRobot:
برای تبدیل Gemma 3n به یک action model.

NVIDIA Jetson:
برای بهترین پیاده‌سازی روی دستگاه Jetson.

Ollama:
برای بهترین پروژه که مدل رو با Ollama اجرا کرده.

Unsloth:
برای بهترین fine-tune با استفاده از Unsloth.

Google AI Edge:
برای بهترین پروژه با این ابزار.

به نظر من، این که بخش اصلی ارزیابی روی ویدیو دمو هست، یعنی مهارت ارائه محصول و داستان‌سرایی به اندازه مهندسی اهمیت داره. این یه مسابقه کدزنی محض نیست. وجود جوایز مجزا برای ابزارهایی مثل Ollama و Unsloth هم عالیه، چون یعنی لازم نیست حتما به زیرساخت‌های بزرگ دسترسی داشته باشین. می‌تونین با Unsloth روی GPU های معمولی fine-tune کنین و شانس برنده شدن داشته باشید. با توجه به زمان کم، باید روی یه Proof-of-Concept قوی با یه ویژگی کلیدی تمرکز کرد و همون رو خوب نمایش داد.

📃 جزئیات چالش و نوت‌بوک‌های نمونه برای فاین‌تیون:
google-gemma-3n-hackathon
gemma-3n-4b-multimodal-finetuning-inference

🛠 Join @LLMEngineers Community

🎯 100 Days of Reading ML / LLM Papers Challenge

Day 4: An overview of gradient descent optimization algorithms

🔗 https://arxiv.org/pdf/1609.04747

Additional Resources:
⦁ 📄 The Learning Process: How Machines Actually Learn
⦁ 📘 Dive into Deep Learning (d2l.ai)

🛠 @LLMEngineers

بالاخره Ollama از فاز ترمینال و کامندلاین خالص خارج شد و یه اپ دسکتاپ برای macOS و ویندوز منتشر کرد. تا پیش از این، Ollama ابزار خیلی خوبی برای دانلود و مدیریت مدل‌های زبان به صورت لوکال بود، ولی رابط گرافیکی نداشت و همین باعث می‌شد خیلیا سمتش نرن. این آپدیت جدید این مانع رو برداشته.

🛠 Join @LLMEngineers Community

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

پشتیبانی از Multimodality: قابلیت drag-and-drop کردن فایل، خصوصا عکس، یه قدم مهمه. حالا می‌تونید با مدل‌هایی مثل Gemma 3 به صورت بصری تعامل کنید. این قابلیت برای پردازش فایل‌های متنی، PDF و حتی کد هم فعاله که برای کارهایی مثل خلاصه‌سازی یا تولید داکیومنتیشن از روی کد خیلی کاربردیه.

بهبود پرفورمنس: این بخش برای من مهم‌تره. تو این نسخه، پرفورمنس مدل‌های سری gemma3n حدود ۲ تا ۳ برابر سریع‌تر شده. همچنین، برای سیستم‌هایی که چندتا GPU دارن، عملکرد موازی‌سازی ۱۰ تا ۳۰ درصد بهتر شده. این یعنی inference سریع‌تر و استفاده بهینه‌تر از سخت‌افزار.

بهبود API: اندپوینت سازگار با OpenAI حالا از فرمت عکس WebP هم پشتیبانی می‌کنه. علاوه بر این، با دستور ollama ps می‌تونید ببینید هر مدل با چه context length‌ای لود شده که برای دیباگ کردن مصرف مموری مفیده.

📃 بلاگ‌پست معرفی اپ جدید

🔗 صفحه دانلود

🛠 Join @LLMEngineers Community

خب Qwen یه مدل دیگه برای کدنویسی به اسم Qwen3-Coder-Flash منتشر کرد. این مدل ۳۰ میلیارد پارامتری، فقط ۳.۳ میلیارد پارامتر فعال داره که باعث می‌شه خیلی سریع باشه و بشه روی سخت‌افزارهای معمولی هم اجراش کرد.

تحلیل بنچمارک‌ها توی تصویر چند تا نکته‌ی جالب رو نشون می‌ده:

رقابت با مدل‌های پولی: توی تسک‌های Agentic که شامل استفاده از ابزار (Tool Use) و مرورگر (Browser Use) می‌شه، عملکردش به شکل عجیبی نزدیک به OpenAI GPT-4.1 هست.

برتری در مهندسی نرم‌افزار: توی بنچمارک SWE-bench که توانایی حل مسئله‌های واقعی مهندسی نرم‌افزار رو می‌سنجه، حتی از GPT-4.1 هم امتیاز بهتری گرفته.

فاصله با بهترین‌ها: البته هنوز با بهترین مدل‌های بسته مثل Claude Sonnet-4 و برادر بزرگتر خودش (480B) فاصله داره، اما برای یه مدل با این سایز و سرعت، نتایج خیلی خوبه.


🤗 مدل در Hugging Face

🛠 Join @LLMEngineers Community

چند تا نکته‌ی کلیدی در موردش:

کانتکست بالا: به صورت نیتیو از ۲۵۶ هزار توکن کانتکست پشتیبانی می‌کنه که با تکنیک YaRN می‌شه تا ۱ میلیون توکن هم افزایشش داد. این یعنی می‌تونید یک ریپازیتوری کامل رو بهش بدید و سوال بپرسید.

عملکرد ایجنتیک: برای کار با ابزارها و Function Calling بهینه شده. می‌شه راحت بهش ابزارهای مختلفی رو معرفی کرد تا در حین کد زدن ازشون استفاده کنه.

سرعت بالا: طبق تست‌های کامیونیتی، روی سخت‌افزارهای مختلف سرعت‌های خوبی ثبت شده. مثلاً با کوانتایز GGUF روی سیستمی با ۱۸ گیگابایت رم، سرعت بیشتر از ۶ توکن بر ثانیه بوده. روی مک M4 Pro به ۷۴ توکن بر ثانیه رسیده و روی کارت گرافیک RTX 4090 حتی تا ۱۷۰ توکن بر ثانیه هم گزارش شده.

چطور می‌شه ازش به عنوان دستیار کدنویسی محلی استفاده کرد؟

فرایند کلی اینه که مدل رو روی سیستم خودتون اجرا کنید و یه API محلی بسازید، بعد ابزارهایی مثل cline رو در VS Code به این API وصل کنید.

۱. اجرای مدل: ساده‌ترین راه استفاده از ابزارهایی مثل LM Studio یا Ollama هست. آخرین نسخه‌ی GGUF مدل رو از Hugging Face دانلود و داخل این ابزارها لود می‌کنید.
۲. راه‌اندازی سرور محلی: با ollama میتونید با کامند serve لود کنید و همچنین توی LM Studio یه تب به اسم Local Server وجود داره که با یک کلیک، یه اندپوینت OpenAI-Compatible روی آدرس localhost براتون می‌سازه.
۳. اتصال به IDE: حالا کافیه افزونه‌ای مثل cline رو روی VS Code نصب کنید و در تنظیماتش، آدرس API محلی که LM Studio ساخته رو به عنوان Provider وارد کنید.

با این روش، شما یه چیزی شبیه به Cursor دارید که به جای استفاده از مدل‌های OpenAI، از مدل قدرتمندی که روی سیستم خودتون اجرا می‌شه استفاده می‌کنه.

به نظر من، این مدل یه قدم خیلی مهم برای توسعه‌ی ابزارهای هوش مصنوعی به صورت local-first هست. اینکه بتونیم توی هرجایی بدون اینترنت و رایگان، یه دستیار کدنویسی در سطح GPT-4o داشته باشیم، دیگه یه رویای دور نیست. شکاف بین مدل‌های عظیم ابری و مدل‌های متن‌باز قابل اجرا روی دستگاه‌های شخصی، حداقل برای تسک کدنویسی، داره به سرعت کم می‌شه.



💬 Chat
🤗 Hugging Face
🦥 unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF
🦙 ollama/qwen3-coder

🛠 Join @LLMEngineers Community

یه سری مدل جدید و قوی به اسم Deep Cogito v2 به صورت اپن‌سورس منتشر شده. این مدل‌ها که در سایزهای مختلف تا ۶۷۱ میلیارد پارامتر (MoE) عرضه شدن،

مدل ۶۷۱ میلیارد پارامتری در بنچمارک‌ها عملکردی نزدیک به مدل‌های کلوز-سورس مثل Claude 3 Opus داره.

جزئیات فنی و بلاگ‌پست
لینک دانلود مدل‌ها در Hugging Face


🛠 Join @LLMEngineers Community

مکانیزم فنی Deep Think روی دو تا پایه اصلی استواره:
۱. تفکر موازی (Parallel Thinking): به جای تولید یک chain-of-thought خطی، مدل چندین مسیر استدلال یا فرضیه (hypotheses) رو به صورت همزمان تولید و ارزیابی می‌کنه. این مفهوم شبیه به روش‌های پیشرفته‌تری مثل Tree-of-Thoughts (ToT) یا Graph-of-Thoughts (GoT) هست، با این تفاوت که اینجا به صورت یکپارچه و بهینه‌شده در خود مدل پیاده‌سازی شده. مدل در طی این فرآیند می‌تونه ایده‌ها رو با هم ترکیب کنه یا حتی مسیرهای ضعیف‌تر رو در حین پردازش اصلاح کنه.

۲. افزایش زمان استنتاج (Extended Inference Time): به مدل به صورت عامدانه زمان و compute بیشتری داده می‌شه تا فضای راه‌حل (solution space) رو عمیق‌تر جستجو کنه. گوگل صراحتاً به دو نسخه اشاره کرده: یک نسخه تحقیقاتی برای المپیاد ریاضی (IMO) که حل مسائلش "ساعت‌ها" طول می‌کشه و به سطح مدال طلا رسیده، و نسخه عمومی که سریع‌تره و به سطح برنز دست پیدا کرده. این خودش نشون‌دهنده یک trade-off مستقیم بین زمان و عمق استدلاله.

نکته کلیدی فنی اینجاست: صرفاً دادن زمان بیشتر به مدل کافی نیست. گوگل از تکنیک‌های Reinforcement Learning جدیدی استفاده کرده تا مدل رو "تشویق" کنه که از این مسیرهای استدلال طولانی و موازی به شکل مؤثری استفاده کنه. در واقع، مدل با RL یاد گرفته که چطور این فضای جستجوی وسیع رو مدیریت کنه و بهترین خروجی رو از بین شاخه‌های مختلف انتخاب یا سنتز کنه.

تحلیل نتایج بنچمارک‌ها از دید فنی:

IMO 2025:
جهش از "بدون مدال" به "مدال برنز" در نسخه عمومی، یک تغییر کیفی در توانایی استدلال ریاضی انتزاعی رو نشون می‌ده. این بنچمارک نیازمند ساخت اثبات‌های چند مرحله‌ای و خلاقانه است، نه صرفاً بازخوانی دانش.

LiveCodeBench v6:
اختلاف ۱۳.۴ درصدی با نسخه Pro نشون می‌ده که این تکنیک برای مسائل کدنویسی الگوریتمی که نیاز به تحلیل trade-off ها و پیچیدگی زمانی دارن، بسیار کارآمده.

Humanity's Last Exam:
کسب امتیاز بالا بدون ابزار خارجی، تأکیدی بر افزایش توانایی استدلال ذاتی و پایگاه دانش داخلی خود مدله.

به نظر من، Deep Think یک استراتژی محصول هوشمندانه برای بخش‌بندی بازاره. گوگل عملاً داره compute-at-inference رو به عنوان یک محصول premium می‌فروشه. برای تسک‌های روزمره از نسخه Pro استفاده می‌شه، ولی برای حل یک مشکل واقعاً سخت، کاربر می‌تونه آگاهانه هزینه محاسباتی بیشتری رو برای دسترسی به یک reasoning engine قدرتمندتر پرداخت کنه. البته این افزایش قدرت با هزینه هم همراه بوده: طبق گزارش خود گوگل، مدل تمایل بیشتری به رد کردن درخواست‌های سالم (higher tendency to refuse benign requests) داره که این یک نمونه کلاسیک از alignment tax در مدل‌های بزرگ‌تر و تواناتره.

full blog post

🛠 Join @LLMEngineers Community

وقتشه در مورد Reinforcement Learning یا RL یه گپ عمیق و فنی بزنیم و ببینیم چطور می‌شه باهاش مدل‌های اپن‌سورس رو به سطح مدل‌های بسته نزدیک کرد. این خلاصه‌ای از نکات کلیدی و تجربیاته که از دل یه بحث فنی درآوردم.

اول یه نگاه سریع به تاریخچه بندازیم. یادتونه که با ریلیز شدن وزن‌های Llama 1، جنبش اپن‌سورس جون گرفت. اون مدل روی ۱.۴ تریلیون توکن آموزش دیده بود. الان Llama 4 روی ۳۰ تریلیون توکن آموزش دیده. این رشد عظیم داده نشون‌دهنده مسیر حرکته. با این حال یه دوره‌ای به اسم «خشکسالی اپن‌سورس» داشتیم. وقتی OpenAI مدل o1-preview رو داد بیرون، یهو یه شکاف بزرگ تو قابلیت «استدلال» یا reasoning بین مدل‌های بسته و اپن‌سورس ایجاد شد که ماه‌ها طول کشید تا پر بشه. این شکاف با مدل‌هایی مثل DeepSeek R1 تا حد زیادی جبران شد. به نظر من، این نشون می‌ده که قابلیت‌های اصلی از قبل تو مدل وجود دارن و ما با تکنیک‌های بهتر فقط اون‌ها رو «برجسته» می‌کنیم.

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

Pre-training:
آموزش روی دیتاست‌های عظیم وب برای پیش‌بینی کلمه‌ی بعدی.

Mid-training:
یه فاز میانی با داده‌های باکیفیت‌تر (مثل وزن دادن بیشتر به ویکی‌پدیا) و همینطور افزایش طول context مدل.

Supervised Fine-tuning یا SFT:
همون instruction-tuning که مدل پایه رو به یه مدل چت تبدیل می‌کنه.

Post-training:
فاز نهایی که شامل preference-tuning (مثل DPO) و مهم‌تر از اون، RL با پاداش‌های قابل تایید (RLVR) می‌شه.

ادامه 👇👇👇👇

🛠 Join @LLMEngineers Community

پارادایم جدیدی به اسم RL with Verifiable Rewards یا RLVR اومده که reward model های یادگیرنده رو با توابع پاداش صریح (explicit reward functions) جایگزین کرده. این کار هم بهینه‌تره و هم قابل اتکاتر.

تا چند وقت پیش الگوریتم استاندارد برای این کار PPO بود. PPO خیلی سنگین و پیچیده‌ست چون برای اجرا به سه تا مدل همزمان نیاز داره: مدل اصلی که داره آموزش می‌بینه، یه کپی ثابت از همون مدل به عنوان رفرنس، و یه مدل سوم به اسم value model که کارش فقط تخمین زدن امتیاز مورد انتظار بود. این ساختار خیلی منابع مصرف می‌کرد.

الگوریتم‌های جدیدتر مثل Group Relative Policy Optimization یا GRPO این بازی رو عوض کردن. GRPO خیلی هوشمندانه اون value model رو حذف کرده. به جاش، مدل چند بار برای یه پرامپت جواب تولید می‌کنه، reward function شما بهشون امتیاز می‌ده و بعد با یه سری محاسبات آماری ساده مثل میانگین و انحراف معیار، مشخص می‌کنه کدوم جواب‌ها «بهتر از میانگین» بودن. این سادگی باعث شده RL به قدری بهینه بشه که حتی روی GPUهای رایگان Colab هم قابل اجرا باشه.

به نظر من، سخت‌ترین و خلاقانه‌ترین بخش کار، طراحی reward function هست. اینجا جاییه که هنر مهندسی شما مشخص می‌شه. چند تا مثال عملی:

برای فرمت‌بندی: می‌شه با یه regex ساده چک کرد که خروجی فرمت درستی داره یا نه. اگر داشت امتیاز مثبت، نداشت منفی. حتی می‌شه برای وجود کلیدهای درست ولی مقادیر غلط، امتیاز نسبی داد.

برای ریاضیات: به جای چک کردن جواب نهایی، می‌شه امتیاز نسبی یا distance-based scoring داد. یعنی هر چی جواب مدل به جواب واقعی نزدیک‌تر بود، امتیاز بیشتری بگیره.

برای کدنویسی: ساده‌ترین حالت اینه که چک کنیم کد تولید شده بدون خطا اجرا می‌شه یا نه. if code_runs: return 1 else: return 0. این یه جایزه قابل تایید و شفافه.

یه نکته کلیدی که خیلیا نادیده می‌گیرن: هیچوقت یه مدل پایه (base model) رو مستقیما با RL آموزش ندین. این کار به پدیده‌ای به اسم reward starvation منجر می‌شه. یعنی مدل پایه اینقدر خروجی‌های پرت و بی‌ربط تولید می‌کنه که تقریباً هیچ‌وقت شانسی هم یه امتیاز مثبت نمی‌گیره و در نتیجه هیچی برای یادگرفتن وجود نداره. راه‌حل اینه که قبل از شروع RL، مدل رو با یه SFT سریع روی چند صد مثال باکیفیت «آماده‌سازی» (prime) کنین تا فرمت کلی جواب‌ها رو یاد بگیره و خروجی‌هاش حداقل قابل امتیازدهی باشن.

بحث کوانتیزیشن هم خیلی مهمه. می‌شه مدل‌ها رو تا ۸ برابر کوچک‌تر کرد در حالی که فقط ۱٪ افت دقت داشته باشن. کلیدش کوانتیزیشن پویا (dynamic quantization) هست. یعنی به جای اینکه همه لایه‌ها رو یکسان کوانتیزه کنیم، لایه‌های حساس‌تر مثل attention رو با دقت بالاتر نگه می‌داریم و بقیه رو فشرده می‌کنیم. برخلاف تصور قبلی، این فقط outlier ها یا مقادیر خیلی بزرگ نیستن که مهمن؛ گاهی مقادیر خیلی کوچیک در لایه‌های خاصی هستن که تاثیر حیاتی روی دقت دارن (مراجعه کنید به مقاله super weights).

در نهایت، سرعت پردازنده‌های گرافیکی به خاطر محدودیت‌های فیزیکی در دقت عددی (مثل FP4) احتمالاً به زودی به سقف خودش می‌رسه. این یعنی بهینه‌سازی نرم‌افزاری و الگوریتمی از همیشه مهم‌تر می‌شه. استفاده از torch.compile می‌تونه سرعت آموزش رو بالا ببره ولی همیشه سرراست نیست و نیاز به تنظیم دقیق داره.

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

📃 منبع : ویدیو ۳ ساعته فنی از Daniel Han، یکی از بنیان‌گذارهای Unsloth


🛠 Join @LLMEngineers Community