بحث مدل‌های کدنویسی که به صورت لوکال اجرا میشن دیگه از فاز تئوری خارج شده و کاملاً کاربردی شده. اخیراً یه نفر مدل 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

خب می‌رسیم به RAG یا همون Retrieval-Augmented Generation. خیلیا فکر می‌کنن فقط چندتا فایل رو میریزی تو یه Vector Database و یه LLM بهش وصل می‌کنی و تمام. این تصور اولیه شاید برای یه دموی ساده جواب بده، ولی برای یه محصول واقعی، تازه اول ماجراست.

چندتا نکته کلیدی که کاش روز اول یکی بهم می‌گفت:

۱. فرایند Chunking یه هنر مهندسیه، نه یه کار روتین.
اینکه چطور داکیومنت‌هات رو به قطعات کوچیک‌تر تقسیم می‌کنی، مستقیم روی کیفیت جواب نهایی تأثیر داره. یه چانک زیادی بزرگ، کلی اطلاعات نامرتبط و نویز وارد کانتکست مدل می‌کنه. یه چانک زیادی کوچیک هم باعث میشه مفهوم اصلی و ارتباط بین جملات از بین بره. استراتژی‌های مختلفی هست، از fixed-size ساده گرفته تا RecursiveCharacterTextSplitter که ساختار متن رو بهتر درک می‌کنه. به نظر من، نقطه بهینه معمولاً با آزمون و خطا روی دیتای واقعی خودتون پیدا میشه. پارامتری مثل chunk_overlap هم مهمه تا ارتباط معنایی بین چانک‌های متوالی حفظ بشه.

۲. کانتکست بیشتر به معنی جواب بهتر نیست.
اینکه ۱۰ تا چانک رو از Vector DB بازیابی کنی و همه‌شو بریزی تو پرامپت، معمولاً نتیجه رو خراب می‌کنه. مدل‌های زبانی بزرگ با پدیده‌ای به اسم "Lost in the Middle" درگیرن؛ یعنی به اطلاعاتی که وسط یه کانتکست طولانی قرار گرفته، توجه کمتری می‌کنن. راه حل اینه که بعد از بازیابی اولیه، یه مرحله Re-ranking اضافه بشه. می‌تونین از یه مدل سبک cross-encoder یا سرویس‌هایی مثل Cohere Rerank استفاده کنین تا چانک‌ها رو بر اساس ارتباط واقعی‌شون با سوال کاربر دوباره مرتب کنین. اینطوری مرتبط‌ترین اطلاعات اول کانتکست قرار می‌گیره و مدل جواب دقیق‌تری تولید می‌کنه.

۳. انتخاب مدل Embedding یکی از حیاتی‌ترین تصمیماته.
مدل‌های Embedding مترجم‌های دیتای شما به زبان ریاضی هستن. اگه مترجم کارشو بلد نباشه، کل سیستم بازیابی فلج میشه. مدل‌های عمومی مثل text-embedding-3-small از OpenAI برای شروع خوبن، ولی برای دیتای تخصصی یا زبان‌های خاص، ممکنه بهترین نباشن. باید مدل‌های open-source مثل jina embedding رو هم بررسی کرد که روی تسک‌های multilingual retrieval عملکرد خوبی نشون دادن. برای انتخاب درست، به معیارهای استاندارد نگاه کنین.

📃 مرجع مقایسه مدل‌های Embedding
MTEB Leaderboard

در نهایت، RAG یه سیستم زنده‌س. باید به طور مداوم کیفیت بازیابی (retrieval precision) و وفاداری پاسخ مدل به منبع (faithfulness) رو ارزیابی کنین.

🛠 Join @LLMEngineers Community

یه مدل اپن‌سورس جدید به اسم XBai-o4 از شرکت MetaStone منتشر شده که روی بنچمارک‌های Reasoning تونسته از مدل‌هایی مثل o3-mini و Claude Opus 4 بهتر عمل کنه.

ایده‌ی اصلیش parallel test time scaling هست. یعنی به جای اینکه مدل فقط یک جواب تولید کنه، میاد چندتا «مسیر فکری» یا Thinking Trajectory رو به صورت موازی تولید می‌کنه. بعد با استفاده از یک مدل پاداش (Reward Model) که روی کیفیت فرآیند استدلال آموزش دیده، بهترین مسیر رو انتخاب می‌کنه و جواب نهایی رو بر اساس اون تولید می‌کنه. به این تکنیک Process Reward Learning یا SPRM هم میگن.

این مدل چندتا حالت اجرایی داره: Low, Medium, High. این حالت‌ها احتمالاً به تعداد مسیرهای فکری‌ای که به صورت موازی تولید میشن ربط داره. هر چی تعداد مسیرها بیشتر باشه، دقت میره بالاتر ولی سرعت inference به شدت پایین میاد. برای همین یکی از دولوپرها اشاره کرده که نسخه‌ی کوانتایز شده‌اش «فوق‌العاده کنده».

🤗 لینک وزن‌های مدل

🛠 Join @LLMEngineers Community

نکات فنی کلیدی این مدل این‌هاست:
یک. رابط یکپارچه مدل policy و مدل reward: مهم‌ترین بخش ماجرا اینه که backbone مدل اصلی (که policy model حساب میشه) و مدل پاداش فرآیند (Process Reward Model یا PRM) مشترکه. یه head خیلی سبک (حدود ۵۳ میلیون پارامتر برای مدل ۳۲ میلیاردی) به مدل اضافه شده که کارش امتیازدهی به مراحل استدلاله. این کار هزینه محاسباتی PRM رو موقع اینفرنس تا ۹۹٪ کاهش میده چون دیگه لازم نیست یه مدل غول‌پیکر جداگانه برای امتیازدهی لود بشه.

دو. یادگیری خودنظارتی برای مدل پاداش (SPRM): یکی از بزرگترین مشکلات ساخت PRM، نیاز به داده‌های لیبل‌گذاری شده در سطح فرآیندی (process-level annotation) هست که خیلی گرونه. این تیم اومده یه Self-supervised PRM یا SPRM ساخته که فقط با دیدن نتیجه نهایی (مثلاً جواب مسئله درسته یا غلط) یاد می‌گیره به مراحل مختلف استدلال امتیاز بده. این‌جوری دیگه نیازی به دیتاست‌های پیچیده و پرهزینه برای ترین PRM نیست.

کاربرد عملی این معماری تو Test-Time Scaling (TTS) مشخص میشه. مدل XBai o4 سه تا حالت داره: low و medium و high. این حالت‌ها در واقع Best-of-N با مقادیر N برابر ۲، ۸ و ۳۲ هستن. مدل k تا جواب مختلف تولید می‌کنه، بعد SPRM داخلیش به هر کدوم امتیاز میده و بهترینش رو انتخاب می‌کنه.

به نظر من، ایده shared backbone یه حرکت مهندسی هوشمندانه و بهینه‌ست. به جای اینکه یه PRM جدا رو به زور بچسبونن به یه مدل دیگه، کل سیستم به صورت یکپارچه طراحی شده. استفاده از یه loss سفارشی به اسم SPRLoss هم که حین آموزش جلوی نویز ناشی از لیبل‌های اشتباه رو می‌گیره، نشون میده که به چالش‌های عملی این روش فکر شده.

توی مقاله به یه پدیده جالب به اسم aha moment هم اشاره شده. ظاهراً موقع آموزش، مدل بعد از یه تعداد استپ خاص، ناگهان توانایی تفکیک بین استدلال درست و غلط رو پیدا می‌کنه و از اون نقطه به بعد، شکاف امتیازی که به جواب‌های درست و غلط میده به سرعت زیاد میشه.

در بنچمارک‌های ریاضی مثل AIME24 و AIME25، مدل XBai o4-high تونسته از مدل‌های قوی مثل Qwen3-32B و حتی DeepSeek-R1-671B هم عملکرد بهتری ثبت کنه.

📃 مقاله اصلی برای جزئیات بیشتر:
Test-Time Scaling with Reflective Generative Model


🛠 Join @LLMEngineers Community

یه نگاهی به چند صدتا کیس استادی جدید LLMOps که تو پروداکشن کار می‌کنن انداختم. چهارتا ترند اصلی خیلی داره تکرار می‌شه, اینا چیزاییه که تیمای جدی دارن انجام می‌دن، نه دموهای پرزرق و برق.

بحث Agent ها بالاخره از فاز دمو خارج شده و داره تو پروداکشن استفاده می‌شه. ولی این Agent ها هیچ شباهتی به سیستم‌های خودکار و همه‌کاره‌ای که تو مقاله‌ها می‌بینیم ندارن. Agent های موفق فعلی، به طرز شگفت‌آوری narrow و تک‌دامنه‌ای هستن. بیشتر شبیه اسکریپت‌های اتوماسیون خیلی هوشمند و context-aware عمل می‌کنن تا یه موجودیت مستقل. نظارت انسان هم تقریبا دائمیه. حتی سیستم‌هایی که لیبل multi-agent می‌گیرن، اغلب فقط یه الگوی ساده orchestrator-worker هستن که یه کنترلر اصلی، کارها رو به ماژول‌های تخصصی‌تر پاس می‌ده.

موضوع بعدی اینه که زمان بیشتری صرف ساخت زیرساخت evaluation می‌شه تا منطق اصلی اپلیکیشن. اگه اینطور نیست، احتمالاً دارید محصول باگ‌دار تحویل می‌دید. الگوی LLM-as-judge برای ارزیابی‌های بدون مرجع (reference-free) غالب شده، چون scale می‌شه. اما این یه راه‌حل کامل نیست. هر پیاده‌سازی موفقی که بررسی شده، یه سری golden dataset داره که توسط انسان اعتبارسنجی شدن. الگو اینه: با LLM judges سریع شروع کن، ولی همه چیز رو به یه ground truth انسانی متصل نگه دار. هزینه evals هم یه فاکتور مهمه؛ تیم‌ها متوجه شدن که اجرای eval های سنگین روی هر commit می‌تونه بودجه inference رو سریع‌تر از ترافیک پروداکشن تموم کنه. رویکرد درست، یه eval stack چندلایه است: تست‌های سبک مثل unit test برای prompt template ها به صورت مکرر و تست‌های سنگین‌تر offline در شرایط خاص.

اون روزا که RAG فقط به معنی "یه سری داکیومنت رو بریز تو vector DB و امیدوار باش خوب کار کنه" بود، تموم شده. معماری‌های RAG جدید خیلی عجیب و پیچیده شدن. الان سیستم‌هایی رو می‌بینیم که vector search، keyword matching، graph traversal و پایپلاین‌های reranking رو با هم ترکیب می‌کنن و یه LLM دیگه هم اینا رو ارکستریت می‌کنه. این پیچیدگی بعضی وقتا جواب می‌ده و دقت رو برای کوئری‌های تخصصی خیلی بالا می‌بره، اما هزینه‌ش پیچیدگی عملیاتی وحشتناکه.

در نهایت، Data Flywheels الگوییه که برنده‌ها رو از بازنده‌ها جدا می‌کنه: تبدیل تعاملات کاربر به دیتا برای آموزش. هر سیستم موفقی یه راهی پیدا کرده که وقتی کاربر خروجی AI رو اصلاح می‌کنه، اون اصلاح مستقیم به سیستم برگرده و prompt ها رو آپدیت کنه، مدل‌ها رو fine-tune کنه یا استراتژی‌های retrieval رو تغییر بده. برای شروع این چرخه هم، معمولاً از synthetic data استفاده می‌شه تا سیستم سرد نباشه. به نظر من، چالش اصلی اینجا فنی نیست؛ طراحی UX برای گرفتن فیدبک راحت از کاربر و گرفتن تأییدیه تیم حقوقی برای استفاده از اون دیتا، بخش سخت ماجراست.

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

🛠 Join @LLMEngineers Community