LLM Engineers
فرمتبندی Diff برای کدنویسی
واقعیت اینه که ساختن ایجنتهای کدنویس که واقعا به درد بخورن، یه چالش کلیدی داره: نحوهی اعمال تغییرات. به جای بازنویسی کامل فایلها که هم کند و سنگینه و هم ریویو کردنش عذابه، باید روی تولید
مسئله اصلی اینه که مدلهای زبانی بزرگ، با پیشبینی توکن به توکن، مجبور میشن کل فایل رو از اول بنویسن. این کار هم توکن زیادی مصرف میکنه و هم پنجرهی خطا رو بزرگتر میکنه. راه حلش، آموزش مدل روی
چندتا الگوی طراحی مهم از مقالات اخیر که میشه ازشون استفاده کرد:
* آموزش در سطح پچ: ایده اینه که مدل رو جوری train کنیم که به جای next token، یک patch کامل رو در فرمت unified-diff پیشبینی کنه. این کار خروجی رو با ورکفلوی توسعهدهندهها هماهنگ میکنه.
* پرامپتنویسی ساختاریافته: برای دقت بالاتر در پیدا کردن محل تغییر، میشه از پرامپتهای دو بخشی مثل
* کانتکست ریپازیتوری: ایجنت باید تاریخچهی تغییرات قبلی رو به یاد داشته باشه. میتونیم چند
* تعمیر خودکار باگ: به جای اینکه فقط باگ رو به مدل بدیم، باید خروجی تستهای fail شده و stack trace ها رو هم به عنوان کانتکست اضافه کنیم. این کار به مدل اجازه میده هم محل باگ رو پیدا کنه و هم خودش patch مناسب رو تولید کنه.
* افزودن هدر: یه ترفند ساده ولی موثر اینه که تو پرامپت از هدرهای
مقایسه ابزارهای معروف تو این زمینه هم جالبه:
* Cursor:
این ابزار به خوبی
* VS Code + Copilot:
متاسفانه Copilot هنوز در سطح بازنویسی کل فایل کار میکنه. این باعث میشه
* Windsurf:
برای تغییرات چندفایلی و ریفکتورینگهای بزرگ تحسین شده، چون کانتکست گلوبال بهتری داره.
به نظر من، کلید موفقیت اینه که
📃 مقاله آموزش در سطح پچ:
https://arxiv.org/abs/2407.12665
📃 مقاله FineEdit برای ویرایش دقیق:
https://arxiv.org/html/2502.13358v1
📃 مقاله Coeditor برای کانتکست ریپازیتوری:
https://arxiv.org/html/2305.18584v2
🛠 Join @LLMEngineers Community
diff تمرکز کنیم. یعنی ایجنت باید یاد بگیره یک patch تمیز و مینیمال تولید کنه که بشه راحت با git اعمالش کرد و کنترلش کرد.مسئله اصلی اینه که مدلهای زبانی بزرگ، با پیشبینی توکن به توکن، مجبور میشن کل فایل رو از اول بنویسن. این کار هم توکن زیادی مصرف میکنه و هم پنجرهی خطا رو بزرگتر میکنه. راه حلش، آموزش مدل روی
patch-level هست. یعنی مدل یاد میگیره به جای توکن بعدی، patch بعدی رو پیشبینی کنه. این روش هزینههای آموزش رو تا ۵۰٪ کم میکنه و خروجیای تولید میکنه که مستقیم با git apply کار میکنه.چندتا الگوی طراحی مهم از مقالات اخیر که میشه ازشون استفاده کرد:
* آموزش در سطح پچ: ایده اینه که مدل رو جوری train کنیم که به جای next token، یک patch کامل رو در فرمت unified-diff پیشبینی کنه. این کار خروجی رو با ورکفلوی توسعهدهندهها هماهنگ میکنه.
* پرامپتنویسی ساختاریافته: برای دقت بالاتر در پیدا کردن محل تغییر، میشه از پرامپتهای دو بخشی مثل
⟨where, what⟩ استفاده کرد. مثلا به مدل میگی @@ line 42 @@ REPLACE …. این ساختار به مدل کمک میکنه دقیقاً بفهمه کجا و چه چیزی رو باید تغییر بده.* کانتکست ریپازیتوری: ایجنت باید تاریخچهی تغییرات قبلی رو به یاد داشته باشه. میتونیم چند
diff آخر رو توی یه بافر نگه داریم و به عنوان کانتکست به مدل بدیم تا تغییرات تجمعی رو درک کنه، نه فقط کد خام رو.* تعمیر خودکار باگ: به جای اینکه فقط باگ رو به مدل بدیم، باید خروجی تستهای fail شده و stack trace ها رو هم به عنوان کانتکست اضافه کنیم. این کار به مدل اجازه میده هم محل باگ رو پیدا کنه و هم خودش patch مناسب رو تولید کنه.
* افزودن هدر: یه ترفند ساده ولی موثر اینه که تو پرامپت از هدرهای
diff مثل --- a/foo.py\n+++ b/foo.py استفاده کنیم. این کار به طرز چشمگیری نرخ موفقیت تغییرات چندفایلی رو بالا میبره.مقایسه ابزارهای معروف تو این زمینه هم جالبه:
* Cursor:
این ابزار به خوبی
diff رو پیادهسازی کرده. تغییرات رو به شکل side-by-side نشون میده و به راحتی میشه هر تیکه (hunk) رو اعمال یا رد کرد. تمام تغییرات رو به شکل commit های تدریجی ذخیره میکنه و rollback خیلی سادهست.* VS Code + Copilot:
متاسفانه Copilot هنوز در سطح بازنویسی کل فایل کار میکنه. این باعث میشه
diff های شلوغ و کندی تولید کنه و خیلیها برای دیدن تغییرات مجبورن از ابزارهای جانبی استفاده کنن.* Windsurf:
برای تغییرات چندفایلی و ریفکتورینگهای بزرگ تحسین شده، چون کانتکست گلوبال بهتری داره.
diff ها رو مستقیم به فرمتی تبدیل میکنه که با git سازگاره.به نظر من، کلید موفقیت اینه که
diff رو به عنوان خروجی اصلی و ground-truth در نظر بگیریم. باید مدل رو برای تولیدش آموزش بدیم، در پرامپت ازش بخوایم، اعتبارسنجیش کنیم و در نهایت به کاربر نشونش بدیم. اینطوری هم مدل با ورکفلوی واقعی توسعهدهندهها هماهنگ میشه، هم هزینهی توکن نصف میشه و هم از دردسرهای بازنویسیهای مرموز فایلها راحت میشیم.📃 مقاله آموزش در سطح پچ:
https://arxiv.org/abs/2407.12665
📃 مقاله FineEdit برای ویرایش دقیق:
https://arxiv.org/html/2502.13358v1
📃 مقاله Coeditor برای کانتکست ریپازیتوری:
https://arxiv.org/html/2305.18584v2
🛠 Join @LLMEngineers Community
arXiv.org
Beyond Next Token Prediction: Patch-Level Training for Large...
The prohibitive training costs of Large Language Models (LLMs) have emerged as a significant bottleneck in the development of next-generation LLMs. In this paper, we show that it is possible to...
یه توصیه برای وقتی که به دیوار ریاضیات تو مقالههای دیپلرنینگ میخورین.
همهمون این تجربه رو داشتیم: مقاله رو باز میکنی، abstract و introduction رو میخونی، همه چی عالیه. بعد میرسی به بخش متدولوژی و فرمولها. یهو حس میکنی تو یه دنیای دیگه فرود اومدی. مغزت قفل میکنه و مقاله رو میبندی. بذار یه چیزی رو رک بهتون بگم: مشکل از شما نیست، مشکل از روشتونه.
فرمول ریاضی رو نباید «خوند». باید باهاش کشتی گرفت. باید تجزیهش کرد. هدف اینه که یه «شهود» بسازی از کاری که اون فرمول انجام میده. لازم نیست تکتک نمادهاشو حفظ کنی. باید داستان پشتش رو بفهمی.
این چهارتا قدم رو برو، مشکلت حل میشه:
۱. اول تمام فرمولها رو پیدا کن و یه جا جمع کن. فقط اونایی که تو متن هستن نه، حتی اونایی که فقط بهشون ارجاع داده شده (مثلاً میگه ما از Adam استفاده کردیم). اینها پایههای کارت هستن.
۲. همهشون رو از مانیتور بکش بیرون و روی یه تیکه کاغذ واقعی بنویس. این مهمترین بخشه. وقتی فرمول رو کاغذ میاد، دستت بازه. میتونی دورش خط بکشی، فلش بزنی، قطعههاشو از هم جدا کنی و کنارش نوت برداری کنی. محدودیتهای دیجیتال رو نداری و تمرکزت هزار برابر میشه.
۳. حالا وقت ترجمهست. سمبلها رو به مفهوم تبدیل کن.
اول ببین هر حرف یونانی (مثل α, θ, L) چه معنیای داره. معمولاً اول مقاله تو بخش Preliminaries یا Notation توضیح دادن. مثلاً θ همون وزنهای مدله. α نرخ یادگیریه. L هم تابع هزینه.
بعد ببین اینا چطوری با عملیات ریاضی (+, -, √) به هم وصل شدن. مثلاً وقتی میگه θ_new = θ_old - α * ∇L یعنی وزنهای جدید میشه وزنهای قدیمی منهای یه قدم کوچیک در جهت مخالف گرادیان. این یعنی داریم loss رو کم میکنیم.
۴. در آخر، از خودت بپرس «خب که چی؟». اون شهود کلی رو بساز.
بعد از اینکه فهمیدی هر تیکه داره چیکار میکنه، یه جمله ساده برای خودت بساز. مثلاً الگوریتم QHM چیه؟ یه میانگین وزندار بین آپدیت momentum و آپدیت SGD سادهست. یا QHAdam چیه؟ همین ایده رو برداشته و روی Adam پیاده کرده تا انعطاف بیشتری داشته باشه. همین. حالا دیگه اون فرمول طولانی و ترسناک برات یه مفهوم ساده و قابل فهم داره.
به نظر من، این فقط یه تکنیک مقاله خوندن نیست، یه مهارت مهندسیه. یاد میگیری چطور یه سیستم پیچیده رو بشکنی به اجزای کوچیکتر، هر جز رو بفهمی و بعد تصویر بزرگ رو ببینی.
🛠 Join @LLMEngineers Community
همهمون این تجربه رو داشتیم: مقاله رو باز میکنی، abstract و introduction رو میخونی، همه چی عالیه. بعد میرسی به بخش متدولوژی و فرمولها. یهو حس میکنی تو یه دنیای دیگه فرود اومدی. مغزت قفل میکنه و مقاله رو میبندی. بذار یه چیزی رو رک بهتون بگم: مشکل از شما نیست، مشکل از روشتونه.
فرمول ریاضی رو نباید «خوند». باید باهاش کشتی گرفت. باید تجزیهش کرد. هدف اینه که یه «شهود» بسازی از کاری که اون فرمول انجام میده. لازم نیست تکتک نمادهاشو حفظ کنی. باید داستان پشتش رو بفهمی.
این چهارتا قدم رو برو، مشکلت حل میشه:
۱. اول تمام فرمولها رو پیدا کن و یه جا جمع کن. فقط اونایی که تو متن هستن نه، حتی اونایی که فقط بهشون ارجاع داده شده (مثلاً میگه ما از Adam استفاده کردیم). اینها پایههای کارت هستن.
۲. همهشون رو از مانیتور بکش بیرون و روی یه تیکه کاغذ واقعی بنویس. این مهمترین بخشه. وقتی فرمول رو کاغذ میاد، دستت بازه. میتونی دورش خط بکشی، فلش بزنی، قطعههاشو از هم جدا کنی و کنارش نوت برداری کنی. محدودیتهای دیجیتال رو نداری و تمرکزت هزار برابر میشه.
۳. حالا وقت ترجمهست. سمبلها رو به مفهوم تبدیل کن.
اول ببین هر حرف یونانی (مثل α, θ, L) چه معنیای داره. معمولاً اول مقاله تو بخش Preliminaries یا Notation توضیح دادن. مثلاً θ همون وزنهای مدله. α نرخ یادگیریه. L هم تابع هزینه.
بعد ببین اینا چطوری با عملیات ریاضی (+, -, √) به هم وصل شدن. مثلاً وقتی میگه θ_new = θ_old - α * ∇L یعنی وزنهای جدید میشه وزنهای قدیمی منهای یه قدم کوچیک در جهت مخالف گرادیان. این یعنی داریم loss رو کم میکنیم.
۴. در آخر، از خودت بپرس «خب که چی؟». اون شهود کلی رو بساز.
بعد از اینکه فهمیدی هر تیکه داره چیکار میکنه، یه جمله ساده برای خودت بساز. مثلاً الگوریتم QHM چیه؟ یه میانگین وزندار بین آپدیت momentum و آپدیت SGD سادهست. یا QHAdam چیه؟ همین ایده رو برداشته و روی Adam پیاده کرده تا انعطاف بیشتری داشته باشه. همین. حالا دیگه اون فرمول طولانی و ترسناک برات یه مفهوم ساده و قابل فهم داره.
به نظر من، این فقط یه تکنیک مقاله خوندن نیست، یه مهارت مهندسیه. یاد میگیری چطور یه سیستم پیچیده رو بشکنی به اجزای کوچیکتر، هر جز رو بفهمی و بعد تصویر بزرگ رو ببینی.
🛠 Join @LLMEngineers Community
این روزها همه جا صحبت از Agent شده. یه اصطلاح که اونقدر زیاد و بیجا استفاده میشه که دیگه معنی اصلیش رو از دست داده. هر اپلیکیشنی که یه LLM توش به کار رفته باشه، یه عده بهش میگن Agent. بذارید این موضوع رو یه بار برای همیشه باز کنیم، چون این فقط یه بحث سر کلمات نیست، یه تفاوت پایهای تو معماری سیستمه.
مسئله اصلی سر کلمهی «خودگردانی» یا
یک Workflow مجموعهای از مراحل از پیش تعریف شدهست. شما به سیستم میگین: «اول کار X رو انجام بده، بعد Y و در نهایت Z». مسیر کاملاً مشخص و ثابته. مثل یک
یک Agent اما داستانش فرق داره. به Agent یک «هدف» داده میشه، نه یک «دستورالعمل». مثلاً بهش میگی: «من رو به مقصد Z برسون». خود Agent باید بفهمه که برای این کار باید مراحل X و Y رو طی کنه. Agentها معمولاً تو یک حلقه یا
اگه بخوایم فنیتر نگاه کنیم، یک ایجنت واقعی معمولاً چهارتا بخش اصلی داره:
۱. برنامهریزی (Planning): توانایی شکستن یک هدف بزرگ به تسکهای کوچکتر و قابل اجرا.
۲. ابزارها (Tools): قابلیت استفاده از API ها یا فانکشنهای دیگه برای تعامل با دنیای خارج از خودش و انجام کارهای واقعی.
۳. حافظه (Memory): داشتن یک حافظه کوتاه و بلندمدت برای به خاطر سپردن اقدامات گذشته، نتایجشون و یادگیری از اونها.
۴. بازاندیشی (Reflection): توانایی نقد عملکرد خودش، فهمیدن اشتباهات و اصلاح برنامهی آینده بر اساس اون.
به نظر من، این تفاوتها تو دنیای مهندسی خیلی مهمن. ساختن و مدیریت یک Workflow قابل پیشبینیه. میتونی راحت تستش کنی و مطمئن باشی که همیشه یک رفتار مشخص داره. اما یک Agent واقعی به خاطر ماهیت خودگردانش، رفتار غیرقطعی (non-deterministic) داره. دیباگ کردن، تست کردن و تضمین عملکردش تو محیط پروداکشن یک چالش خیلی بزرگه. اینکه هر سیستمی که دو بار یک LLM رو صدا میزنه اسمشو Agent بزاریم، بیشتر هایپ و بازی با کلماته.
خلاصه اینکه دفعه بعدی که کلمه Agent رو شنیدید، ببینید آیا سیستم داره از روی یک نقشه ثابت حرکت میکنه یا واقعا داره برای رسیدن به هدف، خودش مسیر رو پیدا میکنه.
🛠 Join @LLMEngineers Community
مسئله اصلی سر کلمهی «خودگردانی» یا
autonomy هست. اینکه یه سیستم چقدر توانایی تصمیمگیری مستقل داره. یه راه خیلی ساده برای تفکیک این سیستمها وجود داره: تفاوت بین Agent و Workflow.یک Workflow مجموعهای از مراحل از پیش تعریف شدهست. شما به سیستم میگین: «اول کار X رو انجام بده، بعد Y و در نهایت Z». مسیر کاملاً مشخص و ثابته. مثل یک
DAG یا Directed Acyclic Graph عمل میکنه. بسیاری از سیستمهایی که امروز بهشون میگن Agent در واقع چیزی بیشتر از یک Workflow پیچیده نیستن که تو بعضی از مراحلش از LLM برای انجام یه تسک خاص استفاده میشه.یک Agent اما داستانش فرق داره. به Agent یک «هدف» داده میشه، نه یک «دستورالعمل». مثلاً بهش میگی: «من رو به مقصد Z برسون». خود Agent باید بفهمه که برای این کار باید مراحل X و Y رو طی کنه. Agentها معمولاً تو یک حلقه یا
loop کار میکنن: محیط رو مشاهده میکنن، برنامهریزی میکنن، یک قدم برمیدارن و دوباره نتیجه رو ارزیابی میکنن تا ببینن به هدف نزدیکتر شدن یا نه. این فرآیند چرخهایه، نه خطی. خودشون تصمیم میگیرن قدم بعدی چی باشه و چه زمانی کار تموم شده. بهترین مدل ذهنی برای یک Agent یک LLM ـه که داخل یک حلقهی while قرار گرفته، به مجموعهای از ابزارها (Tools) دسترسی داره و خودش تصمیم میگیره کی از حلقه خارج بشه.اگه بخوایم فنیتر نگاه کنیم، یک ایجنت واقعی معمولاً چهارتا بخش اصلی داره:
۱. برنامهریزی (Planning): توانایی شکستن یک هدف بزرگ به تسکهای کوچکتر و قابل اجرا.
۲. ابزارها (Tools): قابلیت استفاده از API ها یا فانکشنهای دیگه برای تعامل با دنیای خارج از خودش و انجام کارهای واقعی.
۳. حافظه (Memory): داشتن یک حافظه کوتاه و بلندمدت برای به خاطر سپردن اقدامات گذشته، نتایجشون و یادگیری از اونها.
۴. بازاندیشی (Reflection): توانایی نقد عملکرد خودش، فهمیدن اشتباهات و اصلاح برنامهی آینده بر اساس اون.
به نظر من، این تفاوتها تو دنیای مهندسی خیلی مهمن. ساختن و مدیریت یک Workflow قابل پیشبینیه. میتونی راحت تستش کنی و مطمئن باشی که همیشه یک رفتار مشخص داره. اما یک Agent واقعی به خاطر ماهیت خودگردانش، رفتار غیرقطعی (non-deterministic) داره. دیباگ کردن، تست کردن و تضمین عملکردش تو محیط پروداکشن یک چالش خیلی بزرگه. اینکه هر سیستمی که دو بار یک LLM رو صدا میزنه اسمشو Agent بزاریم، بیشتر هایپ و بازی با کلماته.
خلاصه اینکه دفعه بعدی که کلمه Agent رو شنیدید، ببینید آیا سیستم داره از روی یک نقشه ثابت حرکت میکنه یا واقعا داره برای رسیدن به هدف، خودش مسیر رو پیدا میکنه.
🛠 Join @LLMEngineers Community
Top Non-Reasoning Modes
یه نکته قابل توجه اینه که قویترین مدل توی دسته مدل های none-reasoning (که بنظر من کاربردی ترن) یه مدل اوپن سورس هست.
🛠 Join @LLMEngineers Community
یه نکته قابل توجه اینه که قویترین مدل توی دسته مدل های none-reasoning (که بنظر من کاربردی ترن) یه مدل اوپن سورس هست.
🛠 Join @LLMEngineers Community
یه مدل اپنسورس جدید از چین منتشر شده که رقابت با مدلهای کلوز-سورس رو خیلی جدیتر کرده.
مدل اصلی
عملکردشون توی بنچمارکها قابل توجهه.
📃 لینک مدل:
https://huggingface.co/zai-org/GLM-4.5
🛠 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
LLM Engineers
تیم GLM مدل GLM-4.1V-Thinking رو ریلیز کرده یه VLM که تمرکزش روی multimodal reasoning هست و برای این کار از یه تکنیک جالب استفاده کرده. 🧠 اصل داستان Reinforcement Learning with Curriculum Sampling یا RLCS هست . یعنی چی؟ یعنی مدل رو اول با مسئلههای آسونتر…
اینم کار قبلی این تیم بود, مشخصه تیم قوی ای دارن
LLM Engineers
یه مدل اپنسورس جدید از چین منتشر شده که رقابت با مدلهای کلوز-سورس رو خیلی جدیتر کرده. مدل اصلی GLM-4.5 یه MoE با ۳۵۵ میلیارد پارامتره که ۳۲ میلیارد پارامترش در لحظه فعاله. نسخه سبکتر، GLM-4.5-Air هم یک مدل MoE با ۱۰۶ میلیارد پارامتر کل و ۱۲ میلیارد پارامتر…
مدلای 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
در بحث معماری، این مدلها از 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
LLM Engineers
یه مدل اپنسورس جدید از چین منتشر شده که رقابت با مدلهای کلوز-سورس رو خیلی جدیتر کرده. مدل اصلی GLM-4.5 یه MoE با ۳۵۵ میلیارد پارامتره که ۳۲ میلیارد پارامترش در لحظه فعاله. نسخه سبکتر، GLM-4.5-Air هم یک مدل MoE با ۱۰۶ میلیارد پارامتر کل و ۱۲ میلیارد پارامتر…
بحث مدلهای کدنویسی که به صورت لوکال اجرا میشن دیگه از فاز تئوری خارج شده و کاملاً کاربردی شده. اخیراً یه نفر مدل 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
مدل GLM-4.5 Air در حالت اصلی ۱۰۶ میلیارد پارامتر داره (حدود ۲۰۶ گیگابایت)، اما نسخهی کوانتایز شدهی ۳ بیتی اون برای MLX به ۴۴ گیگابایت رسیده که دقیقاً برای اجرا روی سیستمهای ۶۴ گیگابایتی بهینه شده. موقع اجرا، مدل حدود ۴۸ گیگابایت از رم رو اشغال کرد. مدل قبل از تولید کد، توی بلاک <think> قدم به قدم برنامهش برای ساخت بازی رو توضیح داد و بعد کد رو نوشت. این نشوندهنده یه پروسه استدلال داخلی خوبه.
برای مقایسه، مدل Qwen3-30B رو هم روی همین تسک تست کردم. با اینکه رم کمتری (حدود ۳۰ گیگ) نیاز داشت، کدی که تولید کرد کار نکرد و بازی اجرا نشد. به نظر من، این تفاوت در نتیجهگیری نشون میده که قابلیت "reasoning" در مدلهای هیبریدی مثل GLM-4.5، در مقایسه با مدلهای non-reasoning، تاثیر مستقیم روی کیفیت و صحت کد خروجی داره و باعث میشه کد پیچیدهتر و سالمتری تولید کنن.
این روزها دیگه تقریبا تمام مدلهای جدید با تمرکز ویژه روی کدنویسی منتشر میشن و این تمرکز داره نتیجه میده. اینکه یه لپتاپ میتونه مدلی با این توانایی رو اجرا کنه، پیشرفت بزرگیه.
🛠 Join @LLMEngineers Community
تیم Qwen یه آپدیت برای مدل
این مدل، یک معماری MoE داره. یعنی از ۳۰ میلیارد پارامتر کل، فقط ۳ میلیارد پارامتر موقع هر استنتاج فعال میشه. این ساختار باعث میشه مدل خیلی بهینهتر و سریعتر باشه. نسخه جدید دیگه بلوکهای <think> رو نداره و مستقیم در حالت non-thinking کار میکنه که خروجی تمیزتر و سریعتری میده.
عملکردش توی بنچمارکهای کدنویسی و استدلال خیلی قابل توجهه. مثلا توی LiveCodeBench امتیاز ۶۹ گرفته که از GPT-4o هم بالاتره.
توی استدلال منطقی مثل ZebraLogic هم با امتیاز ۹۰ عالی عمل کرده.
توی BFCL که مختص قابلیت function calling عه همتراز gpt4o عمل کرده
توانایی درک متنهای طولانی تا 256K توکن رو هم داره.
برای تست آنلاین:
Qwen Chat
صفحه هاگینگ فیس:
Hugging Face (FP16)
Hugging Face (FP8)
🛠 Join @LLMEngineers Community
Qwen3-30B-A3B منتشر کرده. الان یه مدل قدرتمند و بهینه برای اجرا روی سختافزارهای شخصی در دسترسه.این مدل، یک معماری MoE داره. یعنی از ۳۰ میلیارد پارامتر کل، فقط ۳ میلیارد پارامتر موقع هر استنتاج فعال میشه. این ساختار باعث میشه مدل خیلی بهینهتر و سریعتر باشه. نسخه جدید دیگه بلوکهای <think> رو نداره و مستقیم در حالت non-thinking کار میکنه که خروجی تمیزتر و سریعتری میده.
عملکردش توی بنچمارکهای کدنویسی و استدلال خیلی قابل توجهه. مثلا توی LiveCodeBench امتیاز ۶۹ گرفته که از GPT-4o هم بالاتره.
توی استدلال منطقی مثل ZebraLogic هم با امتیاز ۹۰ عالی عمل کرده.
توی BFCL که مختص قابلیت function calling عه همتراز gpt4o عمل کرده
توانایی درک متنهای طولانی تا 256K توکن رو هم داره.
برای تست آنلاین:
Qwen Chat
صفحه هاگینگ فیس:
Hugging Face (FP16)
Hugging Face (FP8)
🛠 Join @LLMEngineers Community
LLM Engineers
تیم Qwen یه آپدیت برای مدل Qwen3-30B-A3B منتشر کرده. الان یه مدل قدرتمند و بهینه برای اجرا روی سختافزارهای شخصی در دسترسه. این مدل، یک معماری MoE داره. یعنی از ۳۰ میلیارد پارامتر کل، فقط ۳ میلیارد پارامتر موقع هر استنتاج فعال میشه. این ساختار باعث میشه مدل…
معماری مدل ترکیب هوشمندانهای از دو تکنیک کلیدیه:
یکی 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
یکی 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
LLM Engineers
اجرای لوکال مدل Qwen3-30B-A3B بسته به کوانتایز های مختلف داره، به صورت میانگین حدود ۱۸ گیگ VRAM نیاز داره.
اینجا یه راهنمای عملی برای اجرای این مدل روی سختافزارهای مختلف با استفاده از نسخههای کوانتایز شده جمعآوری شده. (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
هدف اینه که بتونید این مدل رو حتی روی سیستمهای با منابع محدودتر مثل کارتهای گرافیک گیمینگ یا مکبوکها اجرا کنید.
نسخههای مختلف مدل و روشهای اجرا
برای اجرای مدل 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 رو به
مزایای کلیدیش ایناست:
Local-first: تمام لاگها و داشبورد بهصورت پیشفرض روی سیستم خودتون ذخیره و اجرا میشه. دیگه نیازی به اینترنت یا سرویسهای ابری برای دیدن نتایج اولیه نیست.
رایگان و متنباز: تمام قابلیتهاش، حتی هاست کردن داشبورد روی Hugging Face Spaces، رایگانه.
یکپارچگی با اکوسیستم Hugging Face: بهصورت نیتیو با کتابخونههای transformers و accelerate کار میکنه.
اشتراکگذاری ساده: میتونید داشبوردتون رو با یه space_id روی Hugging Face Spaces سینک کنید و به راحتی با بقیه به اشتراک بذارید. حتی میشه با iframe توی بلاگپست یا داکیومنتها embed کرد.
برای استفاده، اول نصبش میکنید:
بعد توی کدتون لاگها رو ثبت میکنید و در نهایت با دستور
به نظر من، Trackio برای پروژههای شخصی، تیمهای کوچیک و کارهای تحقیقاتی که نمیخوان درگیر پیچیدگی و هزینههای ابزارهای بزرگتر بشن، یه گزینهی عالیه. سادگی و local-first بودنش بزرگترین مزیتشه.
اما باید واقعبین بود. این کتابخونه هنوز تو فاز بتا قرار داره و قابلیتهای پیشرفتهای مثل artifact management یا مصورسازیهای خیلی پیچیده که توی wandb یا MLflow پیدا میشه رو نداره. اگه تیم بزرگی دارید و به این فیچرهای enterprise احتیاج دارید، Trackio هنوز به اون سطح از بلوغ نرسیده.
📃 معرفی کتابخانه Trackio در بلاگ Hugging Face
🛠 Join @LLMEngineers Community
کاربرد اصلیش اینه که یه جایگزین خیلی سبک و رایگان برای ابزارهایی مثل 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
مدل 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
Kaggle
Google - The Gemma 3n Impact Challenge
Explore the newest Gemma model and build your best products for a better world
🎯 100 Days of Reading ML / LLM Papers Challenge
Day 4: An overview of gradient descent optimization algorithms
🔗 https://arxiv.org/pdf/1609.04747
🛠 @LLMEngineers
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
This media is not supported in your browser
VIEW IN TELEGRAM
بالاخره Ollama از فاز ترمینال و کامندلاین خالص خارج شد و یه اپ دسکتاپ برای macOS و ویندوز منتشر کرد. تا پیش از این، Ollama ابزار خیلی خوبی برای دانلود و مدیریت مدلهای زبان به صورت لوکال بود، ولی رابط گرافیکی نداشت و همین باعث میشد خیلیا سمتش نرن. این آپدیت جدید این مانع رو برداشته.
🛠 Join @LLMEngineers Community
🛠 Join @LLMEngineers Community
LLM Engineers
بالاخره Ollama از فاز ترمینال و کامندلاین خالص خارج شد و یه اپ دسکتاپ برای macOS و ویندوز منتشر کرد. تا پیش از این، Ollama ابزار خیلی خوبی برای دانلود و مدیریت مدلهای زبان به صورت لوکال بود، ولی رابط گرافیکی نداشت و همین باعث میشد خیلیا سمتش نرن. این آپدیت…
اپدیت جدید Ollama یه سری بهبود فنی مهم هم داشته. این حرکت Ollama رو از یه ابزار صرفا برای گیکها، به چیزی تبدیل میکنه که افراد بیشتری میتونن ازش استفاده کنن. مهم تریناش اینان:
پشتیبانی از Multimodality: قابلیت drag-and-drop کردن فایل، خصوصا عکس، یه قدم مهمه. حالا میتونید با مدلهایی مثل Gemma 3 به صورت بصری تعامل کنید. این قابلیت برای پردازش فایلهای متنی، PDF و حتی کد هم فعاله که برای کارهایی مثل خلاصهسازی یا تولید داکیومنتیشن از روی کد خیلی کاربردیه.
بهبود پرفورمنس: این بخش برای من مهمتره. تو این نسخه، پرفورمنس مدلهای سری gemma3n حدود ۲ تا ۳ برابر سریعتر شده. همچنین، برای سیستمهایی که چندتا GPU دارن، عملکرد موازیسازی ۱۰ تا ۳۰ درصد بهتر شده. این یعنی inference سریعتر و استفاده بهینهتر از سختافزار.
بهبود API: اندپوینت سازگار با OpenAI حالا از فرمت عکس WebP هم پشتیبانی میکنه. علاوه بر این، با دستور ollama ps میتونید ببینید هر مدل با چه context lengthای لود شده که برای دیباگ کردن مصرف مموری مفیده.
📃 بلاگپست معرفی اپ جدید
🔗 صفحه دانلود
🛠 Join @LLMEngineers Community
پشتیبانی از Multimodality: قابلیت drag-and-drop کردن فایل، خصوصا عکس، یه قدم مهمه. حالا میتونید با مدلهایی مثل Gemma 3 به صورت بصری تعامل کنید. این قابلیت برای پردازش فایلهای متنی، PDF و حتی کد هم فعاله که برای کارهایی مثل خلاصهسازی یا تولید داکیومنتیشن از روی کد خیلی کاربردیه.
بهبود پرفورمنس: این بخش برای من مهمتره. تو این نسخه، پرفورمنس مدلهای سری gemma3n حدود ۲ تا ۳ برابر سریعتر شده. همچنین، برای سیستمهایی که چندتا GPU دارن، عملکرد موازیسازی ۱۰ تا ۳۰ درصد بهتر شده. این یعنی inference سریعتر و استفاده بهینهتر از سختافزار.
بهبود API: اندپوینت سازگار با OpenAI حالا از فرمت عکس WebP هم پشتیبانی میکنه. علاوه بر این، با دستور ollama ps میتونید ببینید هر مدل با چه context lengthای لود شده که برای دیباگ کردن مصرف مموری مفیده.
📃 بلاگپست معرفی اپ جدید
🔗 صفحه دانلود
🛠 Join @LLMEngineers Community
Ollama
Download Ollama on macOS
Download Ollama for macOS
خب 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
تحلیل بنچمارکها توی تصویر چند تا نکتهی جالب رو نشون میده:
رقابت با مدلهای پولی: توی تسکهای Agentic که شامل استفاده از ابزار (Tool Use) و مرورگر (Browser Use) میشه، عملکردش به شکل عجیبی نزدیک به OpenAI GPT-4.1 هست.
برتری در مهندسی نرمافزار: توی بنچمارک SWE-bench که توانایی حل مسئلههای واقعی مهندسی نرمافزار رو میسنجه، حتی از GPT-4.1 هم امتیاز بهتری گرفته.
فاصله با بهترینها: البته هنوز با بهترین مدلهای بسته مثل Claude Sonnet-4 و برادر بزرگتر خودش (480B) فاصله داره، اما برای یه مدل با این سایز و سرعت، نتایج خیلی خوبه.
🤗 مدل در Hugging Face
🛠 Join @LLMEngineers Community
LLM Engineers
خب Qwen یه مدل دیگه برای کدنویسی به اسم Qwen3-Coder-Flash منتشر کرد. این مدل ۳۰ میلیارد پارامتری، فقط ۳.۳ میلیارد پارامتر فعال داره که باعث میشه خیلی سریع باشه و بشه روی سختافزارهای معمولی هم اجراش کرد. تحلیل بنچمارکها توی تصویر چند تا نکتهی جالب رو نشون…
چند تا نکتهی کلیدی در موردش:
کانتکست بالا: به صورت نیتیو از ۲۵۶ هزار توکن کانتکست پشتیبانی میکنه که با تکنیک YaRN میشه تا ۱ میلیون توکن هم افزایشش داد. این یعنی میتونید یک ریپازیتوری کامل رو بهش بدید و سوال بپرسید.
عملکرد ایجنتیک: برای کار با ابزارها و Function Calling بهینه شده. میشه راحت بهش ابزارهای مختلفی رو معرفی کرد تا در حین کد زدن ازشون استفاده کنه.
سرعت بالا: طبق تستهای کامیونیتی، روی سختافزارهای مختلف سرعتهای خوبی ثبت شده. مثلاً با کوانتایز GGUF روی سیستمی با ۱۸ گیگابایت رم، سرعت بیشتر از ۶ توکن بر ثانیه بوده. روی مک M4 Pro به ۷۴ توکن بر ثانیه رسیده و روی کارت گرافیک RTX 4090 حتی تا ۱۷۰ توکن بر ثانیه هم گزارش شده.
چطور میشه ازش به عنوان دستیار کدنویسی محلی استفاده کرد؟
فرایند کلی اینه که مدل رو روی سیستم خودتون اجرا کنید و یه 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
کانتکست بالا: به صورت نیتیو از ۲۵۶ هزار توکن کانتکست پشتیبانی میکنه که با تکنیک 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
chat.qwen.ai
Qwen Chat
Qwen Chat offers comprehensive functionality spanning chatbot, image and video understanding, image generation, document processing, web search integration, tool utilization, and artifacts.
یه سری مدل جدید و قوی به اسم Deep Cogito v2 به صورت اپنسورس منتشر شده. این مدلها که در سایزهای مختلف تا ۶۷۱ میلیارد پارامتر (MoE) عرضه شدن،
مدل ۶۷۱ میلیارد پارامتری در بنچمارکها عملکردی نزدیک به مدلهای کلوز-سورس مثل Claude 3 Opus داره.
جزئیات فنی و بلاگپست
لینک دانلود مدلها در Hugging Face
🛠 Join @LLMEngineers Community
مدل ۶۷۱ میلیارد پارامتری در بنچمارکها عملکردی نزدیک به مدلهای کلوز-سورس مثل Claude 3 Opus داره.
جزئیات فنی و بلاگپست
لینک دانلود مدلها در Hugging Face
🛠 Join @LLMEngineers Community
گوگل از قابلیت Deep Think برای Gemini 2.5 رونمایی کرد.
این ویژگی به مدل اجازه میده تا برای حل مسائل پیچیده، چندین مسیر فکری موازی رو همزمان تحلیل کنه و عمیقتر به جواب برسه. کاربرد اصلیش هم برای حل مسائل سنگین کدنویسی، ریاضی و برنامهریزی استراتژیکه.
نکتهی قابل توجه اینه که یه نسخهی پیشرفته از همین مدل تونسته تو المپیاد جهانی ریاضی (IMO) به سطح مدال طلا دست پیدا کنه که نشوندهندهی قدرت استدلال بالای اونه.
در واقع، ایده اینه که با صرف زمان و هزینه محاسباتی بیشتر در لحظه استنتاج (inference time)، کیفیت خروجی برای تسکهای پیچیده به شکل چشمگیری افزایش پیدا کنه. این قابلیت فعلاً برای مشترکین Google AI Ultra در دسترسه.
🛠 Join @LLMEngineers Community
این ویژگی به مدل اجازه میده تا برای حل مسائل پیچیده، چندین مسیر فکری موازی رو همزمان تحلیل کنه و عمیقتر به جواب برسه. کاربرد اصلیش هم برای حل مسائل سنگین کدنویسی، ریاضی و برنامهریزی استراتژیکه.
نکتهی قابل توجه اینه که یه نسخهی پیشرفته از همین مدل تونسته تو المپیاد جهانی ریاضی (IMO) به سطح مدال طلا دست پیدا کنه که نشوندهندهی قدرت استدلال بالای اونه.
در واقع، ایده اینه که با صرف زمان و هزینه محاسباتی بیشتر در لحظه استنتاج (inference time)، کیفیت خروجی برای تسکهای پیچیده به شکل چشمگیری افزایش پیدا کنه. این قابلیت فعلاً برای مشترکین Google AI Ultra در دسترسه.
🛠 Join @LLMEngineers Community