AI Engineers

تیم Qwen یه مدل جدید به اسم Qwen-Image رو اوپن سورس کرده که تمرکزش روی تولید تصویر با رندر متن خیلی قویه، مخصوصا برای زبان چینی و انگلیسی. این مدل ۲۰ میلیارد پارامتری، متن رو به صورت in-pixel یعنی به عنوان بخشی از خود تصویر تولید می‌کنه، نه یه لایه جدا.

اما نکته فنی کلیدی، استفاده از GRPO هست. این رویکرد، تولید تصویر رو به عنوان یک مسئله رتبه‌بندی فرموله می‌کنه. یعنی مدل به جای اینکه فقط یک خروجی «خوب» تولید کنه، یاد می‌گیره از بین چندتا تصویر تولید شده، اونی که به سلیقه انسان نزدیک‌تره رو انتخاب کنه. این فرآیند دقیقاً شبیه به مکانیزم RLHF در مدل‌های زبانی برای همسو شدن با اولویت‌های انسانیه. نتیجه‌اش هم خروجی‌هاییه که نه تنها دقیقن، بلکه از نظر زیبایی‌شناسی هم قوی‌ترن.

🤗 هاگینگ فیس

🛠 Join @LLMEngineers Community

مقایسه لانچرهای لوکال مدل‌های زبانی بر اساس تجربه شخصی و بحث‌های کامیونیتی

🟣 LM Studio
نقطه‌ی قوت اصلیش، رابط کاربری (GUI) و تجربه‌ی کاربری (UX) خیلی خوبشه. برای کسی که می‌خواد بدون دردسر و سریع یه مدل GGUF رو تست کنه، عالیه.

مزایا: همه‌چیز توی یه پکیجه. دانلودر داخلی از Hugging Face داره، تنظیمات مدل مثل context size و GPU offload به‌راحتی قابل کنترله و یه حالت سرور OpenAI-compatible داره که مدل‌ها رو بر اساس درخواست، به صورت on-demand لود و آنلود می‌کنه. این قابلیت آخر خیلی مهمه.

معایب: رابط کاربریش closed-source هست. یعنی نمی‌تونی کدش رو ببینی یا تغییر بدی. برای بعضی‌ها این یه خط قرمزه. گاهی هم باگ‌هایی داره که البته معمولاً تو نسخه‌های بتا رفع میشن.

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

⚪️ Ollama
Ollama بیشتر یه backend یا ابزار CLI هست تا یه اپلیکیشن کامل. هدفش اینه که اجرای مدل‌ها و سرویس‌دهی از طریق API رو تا حد ممکن ساده کنه.

مزایا: خیلی سبکه، نصبش ساده‌ست و به قول معروف set it and forget it هست. مدل‌ها رو از لایبرری خودش می‌کشه و آپدیت می‌کنه.

معایب: یه GUI حداقلی اخیراً اضافه شده ولی برای یه تجربه کامل، معمولاً باید با یه فرانت‌اند مثل OpenWebUI ترکیب بشه. بعضی کاربران حرفه‌ای معتقدن وقتی کار پیچیده میشه، Ollama گزینه‌های کنترلی کمتری نسبت به llama.cpp خام بهت میده.

کاربرد: عالیه برای وقتی که فقط یه API endpoint پایدار برای مدل‌هات می‌خوای و قراره از یه UI دیگه بهش وصل بشی. ترکیب Ollama + OpenWebUI یه ترکیب خیلی محبوبه.

🟡 Jan
Jan سعی کرده یه تعادل بین LM Studio و Ollama برقرار کنه. رابط کاربری داره ولی کاملاً open-source هست.

مزایا: کل اپلیکیشن (فرانت و بک) تحت لایسنس Apache-2.0 هست. بزرگترین ویژگی منحصربه‌فردش اینه که می‌تونه به صورت transparent ترافیک رو بین مدل‌های لوکال و مدل‌های کلاد (مثل GPT-4o یا Claude) جابجا کنه، بدون اینکه نیاز باشه کد سمت کلاینت رو تغییر بدی.

معایب: بعضی‌ها حس می‌کنن هنوز به پختگی LM Studio نرسیده و یه مقدار featureless به نظر میاد.

کاربرد: برای کسایی که به open-source بودن اهمیت میدن و نیاز دارن به‌راحتی بین مدل‌های لوکال و APIهای خارجی سوییچ کنن، بهترین گزینه‌ست.

🟠 Llama.cpp
این خودِ موتوره. ابزارهای دیگه مثل LM Studio و Jan در هسته‌ی خودشون از llama.cpp استفاده می‌کنن.

مزایا: حداکثر پرفورمنس و کنترل. هیچ لایه‌ی اضافه‌ای وجود نداره. برای کارهای جدی، اجرا روی سرورهای headless و برای دولوپرهایی که می‌خوان روی خود انجین کار کنن، انتخاب اوله.

معایب: کار باهاش دانش فنی می‌خواد. همه چیز از طریق CLI و پارامترها کنترل میشه و خبری از GUI نیست.

کاربرد: برای حرفه‌ای‌ها و کارهای جدی.

اپلیکیشن Jan یه رابط کاربری دسکتاپه برای اجرای llm ها که هم آفلاین کار می‌کنه و هم به سرویس‌های ابری وصل می‌شه. کاربرد اصلیش اینه که بهت اجازه می‌ده بدون نگرانی بابت حریم خصوصی، مدل‌های زبانی بزرگ رو روی سیستم شخصی خودت اجرا کنی. اخیراً هم یه قابلیت مهم بهش اضافه شده که می‌شه با اکانت Hugging Face PRO مدل‌ها رو مستقیم داخلش اجرا کرد. کل کدبیسش هم کاملاً اوپن‌سورسه و می‌شه اون رو تغییر داد یا خودتون هاست کنین.

برگ برنده‌اش قابلیت سوییچ یکپارچه بین مدل‌های محلی و ابریه. Jan به شما اجازه می‌ده توی یک محیط چت، هم مدل‌های GGUF رو با llama.cpp به صورت آفلاین اجرا کنین و هم به APIهای کلاد مثل OpenAI، Groq و Mistral وصل بشین. مهم‌تر اینکه، API سرور محلیش (روی localhost:1337) می‌تونه ترافیک رو به صورت شفاف بین یه مدل لوکال Llama 3 و یه مدل ابری مثل GPT-4o جابجا کنه. این یعنی کدی که برای توسعه می‌زنین، بدون هیچ تغییری می‌تونه از هر دو مدل استفاده کنه.

دانلود

🛠 Join @LLMEngineers Community

نقاط قوت مشخص: شکی نیست که Hunyuan-7B در حوزه استدلال ریاضی و منطق خیلی قویه. امتیازهای بالا در بنچمارک‌های MATH، GSM-8K و به‌خصوص AIME این رو ثابت می‌کنه. در این حوزه‌ها، با بهترین‌های کلاس خودش کل‌کل می‌کنه.

نقاط ضعف یا نکات انحرافی:

بنچمارک MMLU: این یه بنچمارک استاندارد و مهمه که دانش عمومی مدل رو می‌سنجه. تو نمودارهای رنگی تنسنت اثری ازش نیست، ولی طبق داده‌های دیگه، Hunyuan-7B با امتیاز حدود ۷۹.۸، به شکل محسوسی از رقیب اصلیش یعنی Qwen3-8B (با امتیاز ۸۷.۵ در MMLU-Redux) ضعیف‌تره. این اختلاف مهمه و نشون میده در دانش عمومی، Qwen3 برتری داره.

بنچمارک IFEval: این بنچمارک توانایی مدل در دنبال کردن دستورالعمل‌ها رو می‌سجه. اینجا هم Hunyuan از مدل OpenAI o1-mini عقب‌تره. این یعنی ممکنه برای تسک‌هایی که نیاز به پیروی دقیق و پیچیده از دستورالعمل دارن، بهترین گزینه نباشه.

دستچین کردن رقبا: در بنچمارک AIME 2024، نمودار تنسنت نشون میده که Hunyuan با امتیاز ۸۱.۱ از بقیه بهتره. اما این "بقیه" شامل مدل تخصصی DeepSeek-R1-0528-Qwen3-8B نمیشه که امتیاز ۸۶.۰ رو در همین بنچمارک کسب کرده. پس Hunyuan بهترین نیست، فقط از رقبایی که تنسنت انتخاب کرده بهتره.

ارزش واقعی Hunyuan-7B کجاست؟

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

۱. عملکرد استدلالی خیلی خوب (Good Enough): شاید بهترین نباشه، ولی به اندازه‌ی کافی قوی هست که کارهای پیچیده رو انجام بده.
۲. پنجره context نیتیو و عظیم 256K: این برگ برنده‌ی اصلیه. هیچکدوم از رقبای مستقیمش چنین پنجره‌ی بزرگی رو به صورت نیتیو و بدون افت کیفیت ارائه نمیدن.
۳. کوانتیزاسیون فوق‌العاده: مدل‌های کوانتایزشده‌ی FP8 و INT4 افت عملکرد بسیار کمی دارن. این یعنی می‌تونید یک مدل با توانایی پردازش ۲۵۶ هزار توکن رو روی یک کارت گرافیک خانگی مثل RTX 4090 اجرا کنید.

🛠 Join @LLMEngineers Community

تنسنت (Tencent) یه خانواده جدید از مدل‌های زبانی متن‌باز به اسم Hunyuan رو در سایزهای کوچک (0.5B, 1.8B, 4B, 7B) منتشر کرده. این مدل‌ها برای سناریوهای کم‌مصرف مثل اجرا روی GPU های خانگی، موبایل‌ها و کامپیوترهای شخصی طراحی شدن.
🛠 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

نکات فنی کلیدی این مدل این‌هاست:
یک. رابط یکپارچه مدل 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

یه مدل اپن‌سورس جدید به اسم 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

خب می‌رسیم به 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

پارادایم جدیدی به اسم 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

وقتشه در مورد 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

مکانیزم فنی 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

گوگل از قابلیت Deep Think برای Gemini 2.5 رونمایی کرد.

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

نکته‌ی قابل توجه اینه که یه نسخه‌ی پیشرفته از همین مدل تونسته تو المپیاد جهانی ریاضی (IMO) به سطح مدال طلا دست پیدا کنه که نشون‌دهنده‌ی قدرت استدلال بالای اونه.

در واقع، ایده اینه که با صرف زمان و هزینه محاسباتی بیشتر در لحظه استنتاج (inference time)، کیفیت خروجی برای تسک‌های پیچیده به شکل چشمگیری افزایش پیدا کنه. این قابلیت فعلاً برای مشترکین Google AI Ultra در دسترسه.

🛠 Join @LLMEngineers Community

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

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

جزئیات فنی و بلاگ‌پست
لینک دانلود مدل‌ها در 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

خب 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

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

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

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

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

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

🔗 صفحه دانلود

🛠 Join @LLMEngineers Community

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

🛠 Join @LLMEngineers Community