مقاله ReAct یه الگوی ساده ولی خیلی قدرتمند رو برای مدل‌های زبانی بزرگ (LLM) معرفی می‌کنه که بهشون اجازه می‌ده همزمان هم استدلال (Reasoning) کنن و هم عمل (Acting). کاربرد اصلیش ساختن ایجنت‌های هوشمندیه که بتونن با ابزارهای خارجی (مثل API یا محیط‌های تعاملی) کار کنن و تسک‌های پیچیده رو حل کنن، بدون اینکه دچار توهم (hallucination) بشن.

ایده‌ی اصلی اینه که مدل‌ها CoT فقط در ذهن خودشون استدلال می‌کنن و به دنیای خارج دسترسی ندارن. این باعث می‌شه خیلی وقت‌ها اطلاعات غلط یا تاریخ مصرف گذشته رو به عنوان فکت ارائه بدن. از طرف دیگه، مدل‌های Act-only فقط می‌تونن یه سری اکشن رو پشت سر هم تولید کنن، ولی توانایی برنامه‌ریزی سطح بالا، ردیابی وضعیت، یا اصلاح برنامه در صورت بروز خطا رو ندارن.

معماری ReAct این دو تا رو با هم ترکیب می‌کنه و یک حلقه Thought -> Action -> Observation به وجود میاره:
۱. فکر (Thought): مدل اول یه استدلال درونی تولید می‌کنه. مثلاً "برای حل این مسئله، باید اول فلان اطلاعات رو از ویکی‌پدیا پیدا کنم." این thought به مدل کمک می‌کنه تسک رو به مراحل کوچیک‌تر بشکنه و استراتژی بچینه.
۲. عمل (Action): بر اساس اون فکر، مدل یه اکشن قابل اجرا تولید می‌کنه. مثلاً search['some entity'].
۳. مشاهده (Observation): این اکشن در یک محیط خارجی (مثلاً API ویکی‌پدیا) اجرا می‌شه و نتیجه‌ش به عنوان یه مشاهده به مدل برمی‌گرده.

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

نتایج مقاله روی چندتا بنچمارک:
روی تسک‌های دانش‌محور مثل HotpotQA (پرسش و پاسخ چند مرحله‌ای)، ReAct به شکل قابل توجهی از CoT قابل اعتمادتره. تحلیل خطاها نشون می‌ده که ۵۶٪ از شکست‌های CoT به خاطر توهم اطلاعاته، در حالی که ReAct با دسترسی به اطلاعات خارجی، این مشکل رو تا حد زیادی نداره.

روی تسک‌های تصمیم‌گیری تعاملی مثل ALFWorld (یه بازی متنی) و WebShop (شبیه‌ساز خرید آنلاین)، ReAct با اختلاف زیاد، مدل‌های مبتنی بر Imitation Learning و Reinforcement Learning رو شکست می‌ده. مثلا روی ALFWorld نرخ موفقیت رو تا ۳۴٪ و روی WebShop تا ۱۰٪ بالا می‌بره، اونم در حالی که فقط با یکی دو تا مثال (few-shot) پرامپت شده. این نشون می‌ده که توانایی استدلال پویا، یک مهارت بسیار عمومی‌تر و کارآمدتر از تقلید صرف از روی هزاران نمونه‌ی انسانیه.

به نظر من، ReAct فقط یه تکنیک پرامپتینگ نیست؛ یه الگوی معماری (architectural pattern) برای ساخت ایجنت‌های خودمختاره. تمام فریمورک‌های مدرن مثل LangChain یا LlamaIndex که بحث Tool-use رو پیاده‌سازی می‌کنن، در هسته‌ی خودشون از همین ایده الهام گرفتن. این مقاله، پشتوانه‌ی علمی و تجربی این معماریه.

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

در نهایت، ReAct به ما نشون می‌ده که ترکیب استدلال درونی با تعامل با دنیای بیرون، کلید ساختن سیستم‌های هوش مصنوعی قدرتمندتر، قابل اعتمادتر و البته قابل تفسیرتره. چون می‌تونیم قدم به قدم ببینیم مدل به چی فکر کرده و چرا یه تصمیم خاص رو گرفته.

📃 ReAct: Synergizing Reasoning and Acting in Language Models

🛠 Join @LLMEngineers Community

ایده‌ی اصلی ایجنت‌ها خیلی ساده‌تر از چیزیه که به نظر میاد: یه LLM، یه حلقه تکرار و چندتا ابزار. کل داستان همینه. بیشتر پیچیدگی‌هایی که می‌بینیم، مربوط به هندل کردن خطاها و موارد خاصه، نه منطق اصلی.

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

🛠 Join @LLMEngineers Community

مقاله‌ی Pre-Act یه بهبود مستقیم و منطقی روی معماری معروف ReAct ارائه می‌ده. کاربرد اصلیش اینه که به ایجنت‌های مبتنی بر LLM کمک می‌کنه تسک‌های پیچیده که به چند مرحله و ابزار نیاز دارن رو با برنامه‌ریزی قبلی و دقت بالاتری انجام بدن. این روش هم برای ایجنت‌های مکالمه‌محور (conversational) و هم غیرمکالمه‌محور کاربرد داره.

مشکل اصلی ReAct اینه که استدلالش (Thought) معمولاً کوته‌بینانه است و فقط برای اکشن بعدی تولید می‌شه. برای کارهای چند مرحله‌ای، این مدل تفکر کافی نیست و ایجنت ممکنه مسیر رو گم کنه. Pre-Act این مشکل رو با مجبور کردن مدل به تولید یک "نقشه راه چند مرحله‌ای" (multi-step plan) در همون ابتدای کار حل می‌کنه.

روند کار به این شکله:
۱. برنامه‌ریزی (Plan): به جای یه Thought ساده، مدل یه پلن کامل با تمام مراحل لازم برای رسیدن به جواب نهایی رو تولید می‌کنه. مثلاً:
* مرحله ۱: اول باید از ابزار get_user_info استفاده کنم چون به اطلاعات کاربر نیاز دارم.
* مرحله ۲: بعد با اطلاعات دریافتی، ابزار check_inventory رو فراخوانی می‌کنم.
* مرحله ۳: در نهایت بر اساس موجودی، به کاربر جواب می‌دم.
۲. اجرا و بازبینی (Act & Revise): مدل مرحله اول پلن رو اجرا می‌کنه، observation رو از ابزار می‌گیره و بعد پلن رو برای مراحل بعدی بازبینی می‌کنه. یعنی وضعیت مراحل قبلی (Previous Steps) و مراحل بعدی (Next Steps) رو همیشه در context خودش نگه می‌داره. این باعث می‌شه ایجنت همیشه بدونه کجای مسیره و قدم بعدیش چیه.

نکته‌ی کلیدی این مقاله که خیلی برای ما مهمه، بحث fine-tuning مدل‌های کوچیک‌تره. نویسنده‌ها نشون می‌دن که با این روش می‌شه مدل‌های اپن سورس مثل Llama-3.1-70B رو طوری fine-tune کرد که عملکردشون حتی از مدل‌های غول‌پیکر و بسته‌ای مثل GPT-4 هم بهتر بشه. این یعنی کاهش هزینه و تأخیر (latency) در کاربردهای واقعی.

نتایج تجربی خیلی قویه:
روی دیتاست Almita (که برای مدل out-of-domain حساب می‌شه)، مدل Llama-3.1-70B که با روش Pre-Act فاین‌تیون شده، در دقت اکشن (action accuracy) تا ۶۹.۵٪ و در نرخ تکمیل هدف (goal completion rate) تا ۲۸٪ از GPT-4 بهتر عمل کرده. این یه دستاورد خیلی مهمه و نشون می‌ده که با داده‌های باکیفیت و یه استراتژی هوشمندانه، می‌تونیم از مدل‌های اپن‌سورس نتایج فوق‌العاده‌ای بگیریم.

استراتژی fine-tuning اون‌ها هم جالبه و از curriculum learning استفاده می‌کنه:
۱. مرحله اول: مدل رو روی یه دیتاست بزرگ (مثل Glaive) با فرمت ساده‌ی ReAct فاین‌تیون می‌کنن تا اصول اولیه‌ی استفاده از ابزار رو یاد بگیره.
۲. مرحله دوم: با استفاده از LoRA، مدل رو روی یه دیتاست کوچیک‌تر ولی باکیفیت‌تر که با فرمت Pre-Act و توسط انسان لیبل‌گذاری شده، بیشتر فاین‌تیون می‌کنن تا توانایی برنامه‌ریزی چند مرحله‌ای رو یاد بگیره.

به نظر من، Pre-Act تکامل طبیعی ReAct هست. اگه ReAct به مدل‌ها یاد داد که چطور "عمل" کنن، Pre-Act بهشون یاد می‌ده که چطور "استراتژی" بچینن. این یه جهش از یه کارگر ساده به یه مدیر پروژه‌ست. بزرگترین چالش عملیاتی این روش، تهیه‌ی دیتاست باکیفیت برای fine-tuning هست که نیاز به تخصص و هزینه داره، ولی نتایج نشون می‌ده که این سرمایه‌گذاری کاملاً ارزشش رو داره.

📃 Pre-Act: Multi-Step Planning and Reasoning Improves Acting in LLM Agents

🛠 Join @LLMEngineers Community

مقاله‌ی TURA یه معماری خیلی مهم رو برای حل یکی از بزرگترین مشکلات سیستم‌های جستجوی مبتنی بر RAG معرفی می‌کنه. مشکل اینه که RAG استاندارد، فقط روی داده‌های استاتیک و از قبل ایندکس شده (مثل صفحات وب) کار می‌کنه و نمی‌تونه به کوئری‌های داینامیک، real-time یا تراکنشی جواب بده. مثلاً نمی‌تونه قیمت بلیط هواپیما برای فردا رو چک کنه یا موجودی یه کالا رو از دیتابیس دربیاره.

معماری TURA یا Tool-Augmented Unified Retrieval Agent این شکاف رو با ترکیب RAG و یک ایجنت هوشمند که از ابزارها (tools) استفاده می‌کنه، پر می‌کنه. این سیستم در یک محصول واقعی با ده‌ها میلیون کاربر پیاده‌سازی شده و نتایجش فوق‌العاده‌ست.

ساختار TURA سه مرحله‌ی اصلی داره:
۱. بازیابی هوشمند ابزار (Intent-Aware Retrieval): اول، یه LLM کوئری پیچیده‌ی کاربر رو به چندتا زیر-کوئری اتمی و مستقل می‌شکنه. بعد، به جای جستجو در وب، در یک کاتالوگ از ابزارها جستجو می‌کنه. برای اینکه ابزارها بهتر پیدا بشن، از یه تکنیک هوشمندانه به اسم index augmentation استفاده شده؛ یعنی برای هر ابزار، کلی کوئری مصنوعی تولید می‌کنن تا فضای معنایی اون ابزار غنی‌تر بشه و راحت‌تر پیدا بشه.

۲. برنامه‌ریزی تسک مبتنی بر DAG: این ماژول، زیر-تسک‌ها و ابزارهای پیدا شده رو می‌گیره و یک گراف جهت‌دار غیرمدور (DAG) ازشون می‌سازه. این کار برای بهینه‌سازی تأخیر (latency) حیاتیه. سیستم تشخیص می‌ده کدوم تسک‌ها به هم وابسته‌ان (مثلاً اول باید آدرس هتل رو بگیری بعد مسیر رو برنامه‌ریزی کنی) و کدوم‌ها مستقلن و می‌تونن به صورت موازی اجرا بشن (مثلاً چک کردن وضعیت آب‌وهوا و پیدا کردن جاذبه‌های توریستی). این موازی‌سازی، سرعت پاسخ رو برای کوئری‌های پیچیده به شدت بالا می‌بره.

۳. اجرای ایجنت تقطیر شده (Distilled Agent Executor): این بخش، شاهکار مهندسی این مقاله است. استفاده از یه مدل غول‌پیکر مثل Deepseek-V3 برای اجرای هر مرحله از تسک، در عمل به خاطر هزینه و latency غیرممکنه. برای حل این مشکل، از تقطیر ایجنت (agent distillation) استفاده شده.
* اول با مدل بزرگ (معلم)، کلی مسیر اجرای بهینه (expert trajectories) به همراه استدلال chain-of-thought تولید می‌کنن.
* این داده‌ها رو به صورت خودکار فیلتر می‌کنن تا فقط مسیرهای درست و بهینه باقی بمونن.
* بعد یه مدل خیلی کوچیک‌تر (دانش‌آموز) مثل Qwen3-4B رو روی این داده‌های باکیفیت fine-tune می‌کنن.
* تکنیک کلیدی اینجا Mixed-Rationale SFT هست: مدل دانش‌آموز با استدلال chain-of-thought آموزش می‌بینه، ولی در زمان اجرا (inference)، ازش خواسته می‌شه که فقط اکشن نهایی رو بدون تولید متن استدلال، خروجی بده. اینطوری، مدل استدلال رو به صورت ضمنی یاد گرفته ولی هزینه‌ی تولید توکن‌های اضافه رو در زمان اجرا نداره.

نتایجش فوق‌العاده است:
مدل تقطیر شده‌ی Qwen3-4B در دقت استفاده از ابزار (۸۸.۳٪) حتی از مدل معلم خودش (Deepseek-V3) و GPT-4o (با دقت ۸۱.۷٪) بهتر عمل کرده. همزمان، latency رو از ۶.۸ ثانیه به ۷۵۰ میلی‌ثانیه کاهش داده. در تست آنلاین A/B هم نرخ موفقیت (Session Success Rate) رو ۸.۹٪ افزایش داده که در مقیاس صنعتی یک عدد عظیمه.

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


📃 TURA: Tool-Augmented Unified Retrieval Agent for AI Search

🛠 Join @LLMEngineers Community

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

معماری این شرکت بر اساس یک ایده کلیدی ساخته شده: به جای وصل کردن صدها GPU کوچیک به هم، یک چیپ غول‌پیکر به اندازه کل یک ویفر سیلیکونی ساخته بشه. این تکنولوژی که بهش Wafer-Scale Integration گفته می‌شه، تمام هسته‌های پردازشی و حافظه رو روی یک چیپ یکپارچه می‌کنه. اینجوری دیگه خبری از ارتباط کند بین چیپ‌ها و وابستگی به حافظه‌های خارج از چیپ مثل HBM نیست.

🛠 Join @LLMEngineers Community

تحلیل دقیق تر:

قضیه از این قراره که Cerebras با سیستم‌هاش داره رکوردهای سرعت Inference رو برای مدل‌های غول‌پیکر جابجا می‌کنه. چندتا عدد واقعی از بنچمارک‌های اخیر:

Llama 3.1 405B: حدود ۹۷۰ توکن بر ثانیه

Qwen3-Coder 480B: حدود ۲۰۰۰ توکن بر ثانیه

GPT-OSS 120B: حدود ۳۰۰۰ توکن بر ثانیه

این اعداد نشون می‌ده معماری Wafer-Scale دیگه یه پروژه تحقیقاتی جالب نیست، بلکه یه راه حل عملی برای رسیدن به سرعت‌های خیلی بالاست.

چرا Cerebras اینقدر سریعه؟ معماری Wafer-Scale

برخلاف رویکرد سنتی که توش چندین GPU رو با شبکه به هم وصل می‌کنیم، Cerebras یه تراشه غول‌پیکر به اندازه کل یک ویفر سیلیکونی ساخته. جدیدترین مدلش، WSE-3، حدود ۹۰۰ هزار هسته پردازشی بهینه شده برای هوش مصنوعی و ۴۴ گیگابایت حافظه SRAM فوق سریع رو روی یک چیپ یکپارچه کرده.

این معماری چندتا گلوگاه اصلی که تو کلاسترهای GPU وجود داره رو حذف می‌کنه:

۱. پهنای باند حافظه فضایی: بزرگترین مزیت Cerebras، حافظه On-Chip یا همون SRAM هست. WSE-2 پهنای باند حافظه داخلی حدود 20 PB/s (پتابایت بر ثانیه) داره. این عدد رو مقایسه کنید با پهنای باند حافظه HBM یه GPU مثل H100 که حدود 3 TB/s (ترابایت بر ثانیه) هست. یعنی بیش از ۷۰۰۰ برابر پهنای باند بیشتر. وقتی پارامترهای مدل و KV Cache داخل همین حافظه فوق سریع قرار می‌گیرن، دیگه نیازی به رفت‌وآمد به حافظه کندترِ خارج از چیپ نیست و عملیات‌های Memory-Bound مثل Attention به شدت سریع میشن.

۲. حذف گلوگاه شبکه: تو کلاسترهای GPU، مدل‌های بزرگ باید بین چندین چیپ Shard بشن. این یعنی بخش زیادی از زمان صرف ارتباط بین GPUها از طریق شبکه‌هایی مثل NVLink یا InfiniBand می‌شه. توی Cerebras، چون همه هسته‌ها روی یک ویفر هستن، با یه Fabric یا شبکه داخلی 2D Mesh با پهنای باند 220 Pb/s (پتابیت بر ثانیه) به هم وصلن. این یعنی ارتباط بین هسته‌ها هزاران برابر سریع‌تر از ارتباط بین GPUهاست و عملاً سربار ارتباطی حذف می‌شه.

۳. پشتیبانی سخت‌افزاری از Sparsity: هسته‌های پردازشی Cerebras که بهشون SLAC میگن، طوری طراحی شدن که عملیات ضرب در صفر رو به صورت سخت‌افزاری نادیده می‌گیرن. از اونجایی که وزن‌ها و Activationهای مدل‌های زبانی می‌تونن تا ۹۰٪ اسپارس باشن، این قابلیت بدون کاهش دقت، حجم محاسبات رو ۲ تا ۳ برابر کم می‌کنه.

۴. تکنیک Weight Streaming: برای مدل‌هایی که بزرگتر از حافظه SRAM هستن (مثلاً مدل‌های 400B)، پارامترها از حافظه خارجی (تا ۱.۲ پتابایت DRAM) به داخل چیپ استریم می‌شن. این کار با سخت‌افزار اختصاصی مدیریت می‌شه تا latency به حداقل برسه و نیاز به Sharding سنتی از بین بره.

چرا کلاسترهای GPU کندتر عمل می‌کنن؟

مشکل اصلی GPUها برای Inference مدل‌های بزرگ، معماری توزیع‌شده‌شونه. وقتی یه مدل مثل Llama 3 405B رو روی کلاستر H100 اجرا می‌کنید، مجبورید مدل رو بین ده‌ها GPU تقسیم کنید. هر توکن که تولید می‌شه، نیاز به ارتباط all-reduce بین همه GPUها برای محاسبات Attention داره. اینجاست که سرعت کلاستر توسط پهنای باند و latency شبکه محدود می‌شه، نه قدرت محاسباتی خود GPUها. حتی با سریع‌ترین شبکه‌ها، این ارتباطات سربار قابل توجهی ایجاد می‌کنن که Cerebras با معماری یکپارچه‌اش اون رو حذف کرده.

Wafer-scale Computing: Advancements, Challenges, and Future Perspectives

🛠 Join @LLMEngineers Community

ترکیب مدل‌های زبان بزرگ یا LLM Merging یه تکنیک خیلی کاربردیه. به جای اینکه یه مدل رو از صفر برای چند تا کار مختلف fine-tune کنی، میای چند تا مدل که هر کدوم تو یه چیزی خوبن رو با هم ترکیب می‌کنی. مثلاً توانایی کدنویسی یه مدل با خلاقیت نوشتاری یه مدل دیگه.

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

The Ultimate Guide to Merging LLMs

🛠 Join @LLMEngineers Community

گزارش فنی مدل GLM-4.5 از طرف Zhipu AI و دانشگاه Tsinghua منتشر شده که ارزش بررسی داره.

این مدل به طور خاص توی تسک‌های ایجنت (Agentic)، استدلال (Reasoning) و کدنویسی (Coding) خیلی قویه. این مدل با پارامترهای فعال کمتر، تونسته با مدل‌های بزرگ و اختصاصی مثل Claude و GPT رقابت کنه و در بعضی بنچمارک‌ها حتی ازشون بهتر عمل کنه. معماریش MoE هست با ۳۵۵ میلیارد پارامتر کلی و ۳۲ میلیارد پارامتر فعال در هر لحظه. یه نسخه سبک‌تر به اسم GLM-4.5-Air با ۱۰۶ میلیارد پارامتر هم داره.

نکته مهم و کلیدی این مدل، استراتژی ترینینگ چندمرحله‌ای و خیلی هوشمندانه‌شه.
اول، یه pre-training عمومی روی ۲۳ تریلیون توکن انجام شده.
دوم، وارد فاز mid-training شدن که اینجا قابلیت‌های خاص مدل رو تقویت کردن. توی این فاز، کانتکست رو تا ۱۲۸ هزار توکن افزایش دادن و روی دیتاست‌های تخصصی تمرکز کردن:

کد در سطح ریپازیتوری (Repo-level Code): برای اینکه مدل وابستگی بین فایل‌های مختلف یه پروژه نرم‌افزاری رو یاد بگیره.

دیتای استدلال سنتتیک (Synthetic Reasoning Data): برای تقویت توانایی حل مسائل پیچیده ریاضی و علوم.

دیتای ایجنت و کانتکست طولانی: شامل مسیرهای تعاملی (trajectories) سنتتیک برای ایجنت‌ها.

جذاب‌ترین بخش به نظر من، فاز post-training هست که بهش میگن Expert Model Iteration. اینجا اول چندتا مدل متخصص (expert) برای حوزه‌های مشخص مثل استدلال، ایجنت و چت عمومی ترین کردن. بعد با تکنیک self-distillation، قابلیت‌های این مدل‌های متخصص رو توی یه مدل واحد و یکپارچه ترکیب کردن. این رویکرد باعث شده مدل نهایی بتونه برای هر تسک، بهترین استراتژی رو انتخاب کنه.

این مدل یه حالت استدلال هیبریدی (hybrid reasoning) هم داره. یعنی برای تسک‌های پیچیده که نیاز به فکر کردن دارن، از حالت thinking استفاده می‌کنه و برای جواب‌های سریع، مستقیم پاسخ میده.

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

یادگیری تقویتی مبتنی بر سختی (Difficulty-based RL): برای Reinforcement Learning، از یه curriculum دو مرحله‌ای استفاده کردن. اول با مسائل متوسط شروع کردن و بعد که مدل قوی‌تر شد، مسائل خیلی سخت رو بهش دادن تا از پدیده reward hacking و درجا زدن جلوگیری کنن.

تمپلیت جدید برای Function Calling: یه تمپلیت جدید شبیه XML برای فراخوانی فانکشن‌ها طراحی کردن که نیاز به escape کردن کاراکترهای زیاد توی کد رو از بین می‌بره. این یه مشکل کوچیک ولی خیلی مهم برای مدل‌های ایجنته.

تست RL روی کانتکست طولانی: به این نتیجه رسیدن که ترین کردن RL به صورت تک‌مرحله‌ای روی حداکثر طول خروجی (مثلاً 64K)، بهتر از افزایش تدریجی طول خروجیه.

از نظر عملکرد، GLM-4.5 توی بنچمارک SWE-bench Verified از GPT-4.1 و Gemini-2.5-Pro بهتر عمل کرده و توی تسک‌های ایجنت، رقیب جدی Claude Sonnet 4 محسوب میشه.

به نظر من، این استراتژی ترینینگ چندمرحله‌ای و ترکیب مدل‌های متخصص، یه رویکرد مهندسی خیلی عملی و هوشمندانه برای ساختن مدل‌های چندکاره‌ست. به جای اینکه فقط دیتا و پارامتر رو به صورت کورکورانه زیاد کنن، روی کیفیت و تخصص‌گرایی متمرکز شدن. اینکه با پارامتر فعال ۳۲ میلیارد به این سطح از عملکرد رسیدن، برای کاربردهای عملی و پیاده‌سازی خیلی ارزشمنده. اوپن‌سورس کردن مدل و زیرساخت RL به اسم Slime هم یه کمک بزرگ به جامعه هوش مصنوعیه.

📃 گزارش فنی GLM-4.5

🛠 Join @LLMEngineers Community

یه مدل جدید ۴ میلیاردی به اسم Jan-v1 معرفی شده که کار اصلیش سرچ وب و ریسرچ عمیقه. تیم سازنده‌ش اون رو به عنوان یه جایگزین open-source برای Perplexity Pro معرفی کرده که به صورت کاملاً local هم اجرا میشه.

این مدل روی نسخه‌ی جدید Qwen یعنی Qwen3-4B-Thinking ساخته شده که تا ۲۵۶ هزار توکن context length داره. به طور مشخص برای reasoning و استفاده از ابزارها (tool use) فاین‌تیون شده که این یعنی برای کارهای agentic و حل مسائل پیچیده بهینه شده.

توی ارزیابی SimpleQA، به دقت ۹۱.۱٪ رسیده که طبق بنچمارک‌های منتشر شده، عملکردش یه مقدار از Perplexity Pro بهتره. این نشون میده که مدل‌های با این سایز هم میتونن توی تسک‌های واقعی مثل پرسش و پاسخ مبتنی بر فکت، عملکرد خیلی خوبی داشته باشن.

برای استفاده، میشه اون رو توی Jan App، یا با فریمورک‌های llama.cpp و vLLM اجرا کرد. اگه از Jan App استفاده می‌کنید، برای فعال کردن قابلیت سرچ باید از تنظیمات، Experimental Features رو روشن کنید و بعدش یه سرور MCP مثل Serper رو فعال کنید تا به اینترنت دسترسی داشته باشه.

به نظر من، حرکت به سمت مدل‌های کوچیک‌تر و تخصصی که به صورت local هم اجرا میشن، خیلی مهمه. این مدل‌ها کنترل بیشتری به دولوپر میدن و وابستگی به API های پولی رو کم می‌کنن. اینکه یه مدل 4B داره با سرویسی مثل Perplexity رقابت می‌کنه، نشون میده که آینده فقط دست مدل‌های غول‌پیکر نیست و مدل‌های بهینه شده برای تسک‌های خاص، جایگاه خودشون رو دارن.

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

📃 مدل اصلی Jan-v1-4B

📃 نسخه GGUF برای llama.cpp

🛠 Join @LLMEngineers Community

🛠 Join @LLMEngineers Community

یه تست سریع و عملی روی چندتا LLM برای یه تسک ساده‌ی NLP تشخیص زبان انجام دادم.

شرایط تست مشخص بود: همه مدل‌ها به وب دسترسی داشتن، پس پیدا کردن بهترین و سریع‌ترین راه‌حل هم بخشی از آزمون بود. مهم‌تر اینکه، تست کاملاً Zero-Shot بود؛ یعنی کد تولید شده باید در اولین تلاش، بدون هیچ دخالت یا اصلاح دستی، اجرا می‌شد.

نتایج خیلی جالب بود. Claude Sonnet 4 با اختلاف بهترین عملکرد رو داشت. نه فقط کد رو Zero-Shot و بدون خطا تحویل داد، بلکه بهینه‌ترین الگوریتم رو با latency فقط 0.63 میلی‌ثانیه انتخاب کرد. نکته جالب‌تر این بود که توی کدش ۴ تا روش مختلف رو هم مقایسه کرده بود که این نشون‌دهنده فهم عمیق مسئله‌ است.

در مقابل، مدل‌هایی مثل Qwen Coder یا DeepSeek R1 که ادعای زیادی روی کد دارن، روی این تسک و با این شرایط fail شدن.

🛠 Join @LLMEngineers Community

گوگل از یه ورژن خیلی کوچیک Gemma 3 رونمایی کرده که ۲۷۰ میلیون پارامتریه.

کاربرد اصلی این مدل برای fine-tune کردن سریع و اجرای تسک‌های هوش مصنوعی روی دستگاه‌های کاربر (on-device) هست. نقطه قوت کلیدی این مدل، توانایی بالای اون در دنبال کردن دستورات یا instruction following هست که توی بنچمارک IFEval سنجیده شده.

توی نمودار مقایسه‌ای، نسخه 270M با اینکه سایز کوچیکی داره، مدل‌های بزرگتری مثل Qwen 2.5 0.5B و SmolLM2-360M رو با اختلاف کنار زده. این موضوع نشون‌دهنده بهینگی بالا در معماری و کیفیت دیتاست pre-train هست.

🛠 Join @LLMEngineers Community

جزئیات فنی معماری و آموزش

معماری این مدل ۲۷۰ میلیون پارامتری خیلی جالبه. از این عدد، ۱۷۰ میلیون پارامتر فقط برای embeddingهاست و ۱۰۰ میلیون پارامتر به بلوک‌های transformer اختصاص داده شده. این یعنی بخش بزرگی از ظرفیت مدل صرف درک توکن‌ها شده. دلیلش هم داشتن یک vocabulary بسیار بزرگ با ۲۵۶ هزار توکنه. این ویژگی باعث میشه مدل پایه (base model) خیلی قوی باشه و برای fine-tune شدن روی دامنه‌های تخصصی یا زبان‌های مختلف که توکن‌های نادری دارن، عملکرد فوق‌العاده‌ای از خودش نشون بده.

نکته کلیدی دیگه، حجم دیتای آموزشیه. این مدل ۲۷۰ میلیون پارامتری روی ۶ تریلیون توکن آموزش دیده. در حالی که نسخه‌های بزرگتر مثل Gemma 3 1B روی ۲ تریلیون و 4B روی ۴ تریلیون توکن آموزش دیدن. این نسبت بالای دیتا به پارامتر (data-to-parameter ratio) یکی از دلایل اصلی عملکرد قوی این مدل در زمینه instruction following هست. امتیاز ۵۱.۲ در بنچمارک IFEval برای مدلی در این سایز، نشون‌دهنده همین بهینگی در آموزشه.

برای بهینگی بیشتر، گوگل نسخه‌های Quantization-Aware Trained یا QAT رو هم منتشر کرده. این یعنی مدل از همون ابتدا با در نظر گرفتن کوانتایز شدن آموزش دیده و میشه اون رو با دقت INT4 و با کمترین افت عملکرد اجرا کرد. تست‌های داخلی روی چیپست Pixel 9 Pro نشون داده که نسخه INT4 این مدل برای ۲۵ مکالمه فقط ۰.۷۵٪ از باتری رو مصرف کرده که اون رو به بهینه‌ترین مدل Gemma از نظر مصرف انرژی تبدیل می‌کنه.

چطور ازش استفاده کنیم؟

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

ابزارهایی مثل Unsloth و فریمورک‌های استاندارد مثل JAX و Hugging Face به طور کامل ازش پشتیبانی می‌کنن. برای اجرا هم می‌تونید از پلتفرم‌هایی مثل Ollama، LM Studio یا llama.cpp استفاده کنید.

🤗 صفحه مدل در Hugging Face

🛠 Join @LLMEngineers Community

یکی از ابزارهای خفن برای فاین‌تونینگ مدل‌های زبانی Axolotl عه،
خیلی ساده، Axolotl یه فریم‌ورک اوپن‌سورس برای فاین‌تون کردن LLMهاست. تمرکزش روی اینه که بهترین و جدیدترین تکنیک‌ها رو خیلی سریع در اختیارت بذاره. از مدل‌های Llama و Qwen گرفته تا Gemma و حالا gpt-oss.

این فریم‌ورک با بهینه‌سازی‌های پیشرفته‌ای مثل FlashAttention برای محاسبات سریع‌تر attention، و gradient checkpointing برای صرفه‌جویی تو مصرف مموری، خودش رو مجهز کرده. قابلیت‌هایی مثل multipacking (استفاده بهینه از مموری با پک کردن چند سکانس کوتاه کنار هم) و RoPE scaling (برای کار با context lengthهای متغیر) هم جزو ویژگی‌های استانداردشه.

نقطه قوت اصلی Axolotl، توانایی‌هاش توی distributed training هست. یعنی اگه بخوای روی چندتا GPU یا حتی چندتا سرور (multi-node) یه مدل غول‌پیکر رو ترین کنی، Axolotl با پشتیبانی از DeepSpeed (ZeRO stages 1-3) و FSDP (Fully Sharded Data Parallel) کارت رو راه میندازه.

Axolotl یا Unsloth؟ مسئله این است

هر دو ابزار عالین، ولی انتخاب بینشون بستگی به نیازت داره.

چرا باید Axolotl رو انتخاب کنی؟

مقیاس‌پذیری و Multi-GPU: اگه می‌خوای مدل‌های واقعاً بزرگ رو روی چندین GPU رده‌بالا فاین‌تون کنی، Axolotl بهترین گزینه‌ست. استراتژی‌های distributed training توش به بلوغ رسیدن، چیزی که Unsloth هنوز توش خیلی کار داره.

انعطاف‌پذیری و کنترل کامل: Axolotl گزینه‌های کانفیگ خیلی زیادی برای کنترل دقیق پروسه ترینینگ بهت می‌ده. از sequence parallelism برای contextهای خیلی طولانی گرفته تا یکپارچه‌سازی با ابزارهایی مثل Weights & Biases برای مانیتورینگ.

چه زمانی Unsloth برنده می‌شه؟

سرعت و بهینه‌سازی VRAM روی تک GPU: اگه سخت‌افزار محدودی داری (مثلاً یه کارت گرافیک گیمینگ یا سرورهای قدیمی‌تر Colab)، Unsloth معجزه می‌کنه. با کرنل‌های سفارشی که برای GPU نوشته، می‌تونه تا ۲-۵ برابر سریع‌تر باشه و تا ۸۰٪ VRAM کمتری مصرف کنه.

به نظر من، اگه اولویتت سرعت حداکثری و بازدهی روی یک یا دوتا GPU هست و با مدل‌های محبوب کار می‌کنی، Unsloth کارت رو خیلی سریع و تمیز راه میندازه. اما برای کارهای تحقیقاتی، فاین‌تونینگ مدل‌های عظیم و نیاز به کنترل کامل روی محیط‌های distributed، قطعاً Axolotl برتری داره.

فاین‌تونینگ مدل‌های GPT-OSS با Axolotl

اخیراً OpenAI دو مدل Mixture-of-Experts (MoE) به اسم gpt-oss-20B و gpt-oss-120B رو به صورت اوپن‌ویت منتشر کرده. خبر خوب اینه که Axolotl خیلی سریع پشتیبانی از فاین‌تونینگ این مدل‌ها رو اضافه کرده.

یکی از نکات مهمی که جامعه بهش رسیده اینه که تکنیک‌های Parameter-Efficient Fine-Tuning (PEFT) مثل QLoRA، به‌خصوص روی تسک‌های پیچیده، عملکرد ضعیف‌تری نسبت به full-parameter fine-tuning دارن. برای همین Axolotl روی قابلیت‌های distributed training خودش سرمایه‌گذاری کرده تا بتونی مدل‌های 70B+ رو بدون افت کیفیت، به صورت کامل فاین‌تون کنی.
پروسه فاین‌تونینگ با Axolotl حول یک فایل کانفیگ YAML می‌چرخه که توش همه‌چیز رو تعریف می‌کنی.

نیازمندی‌های سخت‌افزاری:

QLoRA: برای این تکنیک روی مدل gpt-oss-20B، یه GPU با حدود ۱۶ تا ۲۴ گیگ VRAM کافیه.

Full Fine-Tuning (FFT): برای فاین‌تونینگ کامل، به سخت‌افزار سنگین مثل H100 با ۸۰ گیگ VRAM نیاز داری. البته با استراتژی‌هایی مثل FSDP و offloading می‌شه مدل gpt-oss-20B رو روی دوتا GPU با ۲۴ گیگ VRAM هم ترین کرد.

مدل 120B: طبق داکیومنت‌های Axolotl، می‌شه مدل gpt-oss-120B رو با FFT و offloading روی یک نود با ۸ تا H100 (هر کدوم ۸۰ گیگ) فاین‌تون کرد.

کانفیگ YAML:
توی فایل کانفیگ، base_model رو openai/gpt-oss-20b می‌ذاری و دیتاست خودت رو مشخص می‌کنی. برای تکنیک‌های مختلف، کانفیگ‌های متفاوتی وجود داره:

برای QLoRA، گزینه‌ی load_in_4bit: true و adapter: qlora رو فعال می‌کنی.

برای FFT، این گزینه‌ها رو حذف می‌کنی.

چون این مدل‌ها MoE هستن، باید lora_target_modules رو روی لایه‌های درستی مثل gate_proj تنظیم کنی.

ویژگی‌های جدید:
با آپدیت‌های اخیر، Axolotl از FP8 هم پشتیبانی می‌کنه که مصرف مموری رو از این هم کمتر می‌کنه. همچنین با همکاری Hugging Face، امکان ترکیب Context Parallelism، Tensor Parallelism و FSDP برای ترین کردن مدل‌های عظیم در مقیاس multi-node فراهم شده.

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

📃 بلاگ رسمی Hugging Face درباره ND Parallelism

📃 مثال‌های کانفیگ برای فاین‌تونینگ GPT-OSS

🛠 Join @LLMEngineers Community

یه مقایسه عملی و سریع بین Ollama و LM Studio موقع اجرای یه مدل GGUF یکسان. نتایج جالبه و شاید برای انتخاب ابزار کمکتون کنه.

توی این تست، مدل gemma-2-2b-fa یک بار با LM Studio و یک بار با Ollama روی یه مجموعه سوال یکسان ارزیابی شده.

نتایج خلاصه:

LM Studio:
دقت 31.04% و میانگین latency برابر 0.15s.

Ollama:
دقت 29.40% و میانگین latency برابر 0.43s.

همونطور که مشخصه، LM Studio هم دقت بالاتری داشته و هم تقریباً ۳ برابر سریع‌تر بوده. علاوه بر این، مصرف VRAM در Ollama هم بیشتر بود.

🛠 Join @LLMEngineers Community

داشتم قابلیت function calling یا tool use رو با مدل‌های لوکال تست می‌کردم که یه نتیجه جالب گرفتم.

مدل کوچیک jan-v1-4b که قبلتر راجبش گفته بودنم رو توی LM Studio ران کردم و بهش MCP جستجوی وب با DuckDuckGo وصل کردم. وقتی ازش خواستم آخرین اخبار هوش مصنوعی رو بهم بگه، به جای اینکه از دانش داخلی و تاریخ گذشته‌ش استفاده کنه، خودش تشخیص داد که باید از ابزار search استفاده کنه.

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

به نظر من، این قابلیت که مدل‌های کوچیک و open-source هم بتونن از ابزارهای خارجی استفاده کنن، بازی رو عوض می‌کنه. این یعنی دیگه محدود به دانش داخلی مدل نیستیم و می‌تونیم مدل‌ها رو برای کاربردهای واقعی و ساختن agent های ساده آماده کنیم.

🛠 Join @LLMEngineers Community

مجموع دانلود مدل‌های فارسی gemma-3-4b که چند ماه پیش منتشر کردم، از مرز ۴ هزار دانلود عبور کرد.
این آمار شامل تمام نسخه‌های کوانتایز شده GGUF، نسخه‌ی Ollama و ...

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

با همین انرژی، کار روی پروژه‌ی بعدی شروع شده.
منتظر نسخه‌ی فاین‌تیون شده‌ی فارسی Qwen3-4B یا gemma-3n-e4b باشید. به‌زودی ...

🤗 صفحه من توی هاگینگ فیس

🛠 Join @LLMEngineers Community

نتیجه تست مدل های زبانی کوچک SLM روی بنچمارک ParsiEval برای سنجش دانش زبان فارسی

پ.ن: لازم به ذکره qwen thinking هم خیلی کند تر بود هم gpu داغ کن تر

▫️ لیست کامل

🛠 Join @LLMEngineers Community