علی‌بابا یه مدل تخصصی برای ترجمه به اسم Qwen3-MT معرفی کرده که مستقیماً از طریق API قابل استفاده‌ است. کاربرد اصلیش برای کساییه که نیاز به ترجمه‌ی باکیفیت و قابل کنترل در محصولاتشون دارن. برخلاف سرویس‌های ترجمه‌ی عمومی، این مدل به دولوپر اجازه میده روی خروجی کنترل بیشتری داشته باشه.

نکته‌ی کلیدی این مدل، قابلیت سفارشی‌سازی ترجمه از طریق API هست:
۱- کنترل ترمینولوژی (Terminology Intervention): میتونین یه لیست از کلمات تخصصی و ترجمه‌ی دقیقشون رو به مدل بدین تا توی کل متن، ترجمه‌ی اون کلمات ثابت و مطابق با استاندارد شما باشه. مثلاً برای ترجمه‌ی داکیومنت‌های فنی که یه اصطلاح باید همیشه یکسان ترجمه بشه، این قابلیت خیلی کاربردیه.

۲- حافظه ترجمه (Translation Memory): میشه یه سری جفت جمله-ترجمه‌ی نمونه که از قبل ترجمه شدن رو به مدل داد تا از اون‌ها برای ترجمه‌های جدید الگوبرداری کنه. این کار به حفظ ثبات و سبک ترجمه در متون بلند کمک می‌کنه.

۳- پرامپت‌های دامنه-محور (Domain Prompts): میتونین با یه پرامپت متنی، به مدل بگین که متن مبدأ متعلق به چه حوزه‌ای هست (مثلاً حقوقی، فنی، محاوره‌ای) تا ترجمه با سبک و لحن اون حوزه انجام بشه.

مدل روی ۹۲ زبان، از جمله فارسی (fa)، آموزش دیده. دو نسخه ازش موجوده:
- نسخه‌ی qwen-mt-turbo: بر پایه‌ی معماری MoE ساخته شده، سریع‌تر و خیلی ارزون‌تره (حدود ۰.۵ دلار برای هر یک میلیون توکن خروجی). برای کاربردهای real-time و حجم بالا مناسبه.
- نسخه‌ی qwen-mt-plus: کیفیت بالاتری داره ولی کندتر و گرون‌تره.

نحوه‌ی استفاده ازش هم سرراسته. از طریق یه API که با OpenAI سازگاره، یه درخواست chat.completions.create ارسال میشه. پارامترهای سفارشی‌سازی مثل زبان مبدأ، مقصد و ترمینولوژی‌های خاص، داخل یه دیکشنری به اسم extra_body به درخواست اضافه میشن.

به نظر من، قدرت اصلی Qwen3-MT در همین قابلیت‌های کنترلیه. اینکه مدل صرفاً یه جعبه‌سیاهِ ترجمه نیست و میشه خروجیش رو برای سناریوهای خاص مهندسی کرد، ارزش اصلی رو ایجاد می‌کنه. خیلی از شرکت‌ها با مشکل عدم یکپارچگی در ترجمه‌ی اسامی برند یا اصطلاحات فنی درگیرن که این مدل میتونه حلش کنه.
نقطه‌ی ضعف اصلی اینه که وزن‌های مدل به صورت متن‌باز منتشر نشده. یعنی امکان fine-tune کردن یا اجرای مدل به صورت لوکال وجود نداره و فقط میشه به API علی‌بابا اتکا کرد. ا

📃 وبلاگ معرفی مدل:
https://qwenlm.github.io/blog/qwen-mt/

📃 مستندات API و کد نمونه:
https://alibabacloud.com/help/en/model-studio/translation-abilities

🛠 Join @LLMEngineers Community

علی‌بابا یه مدل جدید از سری Qwen3 داده بیرون که تخصصش reasoning هست: Qwen3-235B-A22B-Thinking-2507. کاربرد اصلی این مدل حل مسائل پیچیده‌ست که نیاز به استدلال مرحله به مرحله داره، مثل مسائل ریاضی، کدنویسی‌های رقابتی و تحلیل‌های علمی.

این مدل یه معماری Mixture-of-Experts داره با ۲۳۵ میلیارد پارامتر که ۲۲ میلیاردش در هر توکن فعال میشه. مهم‌ترین ویژگی‌ این مدل، native بودن حالت "thinking" هست. یعنی دیگه لازم نیست دستی فعالش کنید، خود مدل برای حل مسائل پیچیده از زنجیره‌های استدلال طولانی استفاده می‌کنه تا به جواب دقیق‌تری برسه. در واقع عملکرد مدل توی بنچمارک‌های منطق، ریاضی، کدنویسی و علوم به شکل قابل توجهی بهبود پیدا کرده و با مدل‌های قدرتمند سورس-بسته رقابت می‌کنه.

با اینکه پنجره زمینه یا context window مدل به صورت native تا ۲۵۶ هزار توکن پشتیبانی می‌شه، اما توی API و بعضی پلتفرم‌ها مثل OpenRouter فعلاً تا ۱۳۱ هزار توکن قابل استفاده‌ست. خود تیم Qwen هم توصیه کرده که برای تسک‌های پیچیده که نیاز به reasoning عمیق داره، حتماً context length رو بالای ۱۳۱ هزار توکن تنظیم کنید تا مدل فضای کافی برای "فکر کردن" داشته باشه.

برای اجرا، می‌شه از فریمورک‌هایی مثل vLLM یا sglang استفاده کرد. Unsloth هم GGUF داینامیک براش منتشر کرده که این امکان رو میده تا نسخه ۲-بیتی مدل رو روی سیستمی با ۸۸ گیگابایت رم یکپارچه (unified memory) یا رم معمولی با سرعت بالای ۶ توکن بر ثانیه اجرا کرد. این برای کسایی که دسترسی به کلاسترهای بزرگ ندارن، خوبه.

به نظر من، تیم Qwen داره با سرعت خیلی بالایی مدل‌های SOTA اپن‌سورس رو ریلیز می‌کنه و رقابت رو برای بقیه سخت کرده. اسم مدل‌هاشون (مثلاً همین Qwen3-235B-A22B-Thinking-2507) یکم طولانی و عجیبه، ولی عملکرد، مخصوصاً توی حوزه reasoning، واقعاً قویه و این مدل یه رقیب جدی برای بقیه مدل‌های اپن‌سورس حساب می‌شه. این پیشرفت سریع نشون‌دهنده قدرت آزمایشگاه‌های چینی توی مسابقه هوش مصنوعیه.

📃 مدل اصلی در هاگینگ‌فیس:
https://huggingface.co/Qwen/Qwen3-235B-A22B-Thinking-2507

📃 نسخه FP8 برای مصرف رم کمتر:
https://huggingface.co/Qwen/Qwen3-235B-A22B-Thinking-2507-FP8

📃 گزارش فنی (Technical Report):
https://arxiv.org/abs/2505.09388

🛠 Join @LLMEngineers Community

این چارت، عملکرد مدل جدید علی‌بابا، Qwen3-235B-A22B-Thinking-2507 رو با مدل‌های دیگه مقایسه می‌کنه.

نکته اصلی، جهش عملکرد این نسخه (قرمز) نسبت به نسخه قبلی خودشه (آبی). توی بنچمارک‌های مهمی مثل AIME25 برای ریاضیات، LiveCodeBench v6 برای کدنویسی و Arena-Hard برای همسویی با انسان (alignment)، این مدل جدید تقریباً در تمام موارد در صدر قرار گرفته.

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

به نظر من، این نتایج، Qwen3 رو به عنوان یکی از قوی‌ترین مدل‌های اپن‌سورس در حوزه reasoning تثبیت می‌کنه. مدل حالا دیگه صرفاً یه آلترناتیو نیست، بلکه یه رقیب مستقیم برای مدل‌های بسته مثل Gemini 2.5 Pro و O4-mini محسوب میشه.

🛠 Join @LLMEngineers Community

رویکرد Knowledge Distillation یا به اختصار KD، یه تکنیک برای انتقال دانش از یه مدل بزرگ و قوی (Teacher) به یه مدل کوچیک‌تر و بهینه‌تره (Student). کاربرد اصلیش اینه که مدل‌های غول‌آسا مثل GPT-4 رو که نیازمند منابع محاسباتی سنگین هستن، به نسخه‌های جمع‌وجوری تبدیل کنیم که روی سخت‌افزارهای ضعیف‌تر مثل موبایل یا سرورهای معمولی هم اجرا بشن، بدون اینکه بخش زیادی از عملکردشون رو از دست بدن. این کار هزینه‌های inference رو کم می‌کنه و سرعت رو بالا می‌بره.

اساس کار اینه که مدل Student فقط از روی لیبل‌های واقعی (ground-truth) یاد نمی‌گیره، بلکه تلاش می‌کنه خروجی‌های مدل Teacher رو هم تقلید کنه. این خروجی‌ها فقط جواب نهایی نیستن، بلکه شامل توزیع کامل احتمالاتی روی تمام توکن‌های ممکن (logits) هم میشن. این اطلاعات غنی که بهش "dark knowledge" هم میگن، به Student کمک می‌کنه تا "روش فکر کردن" Teacher رو یاد بگیره، نه فقط جواب درست رو.

چندتا استراتژی اصلی برای این کار وجود داره:

یک. Response-Based Distillation
این روش کلاسیک و ساده‌ترین راهه. اینجا Student سعی می‌کنه توزیع احتمالاتی (logits) خروجی Teacher رو برای هر توکن تقلید کنه. مدل‌هایی مثل DistilBERT از این روش استفاده کردن. این متد از نظر سخت‌افزاری بهینه‌ترینه.

دو. Feature-Based Distillation
اینجا به جای خروجی نهایی، حالت‌های میانی (hidden states) یا attention maps مدل Teacher به Student منتقل میشه. این کار Student رو مجبور می‌کنه که ساختار داخلی و فرآیند استدلال Teacher رو یاد بگیره. این روش برای پر کردن گپ بین یه Teacher خیلی بزرگ و یه Student خیلی کوچیک مفیده.

سه. Instruction & Rationale-Based Distillation
این یکی از موثرترین تکنیک‌ها برای مدل‌های امروزیه. به جای جواب تنها، از Teacher خواسته میشه که مراحل استدلال خودش یا همون Chain-of-Thought (CoT) رو هم تولید کنه. بعد Student روی این دیتاست که شامل دستور -> مراحل استدلال -> جواب نهایی هست، فاین‌تیون میشه. پروژه‌هایی مثل Orca نشون دادن که این روش می‌تونه عملکرد مدل‌های کوچیک در تسک‌های استدلالی رو به شدت بهبود بده. اصل داستان اینه که به جای یاد دادن *جواب نهایی*، به مدل *روش فکر کردن* رو یاد بدی.

گردش کار عملیاتی برای پیاده‌سازی Knowledge Distillation معمولاً اینطوریه:

۱. جمع‌آوری دیتا: یه مجموعه از پرامپت‌ها یا دستورات آماده میشه. این دیتا می‌تونه از دیتاست‌های عمومی مثل Alpaca بیاد یا به صورت مصنوعی با روش‌هایی مثل Self-Instruct تولید بشه.

۲. گرفتن خروجی از Teacher: با استفاده از دیتاست مرحله قبل، از مدل Teacher خروجی گرفته میشه. اینجا تنظیم هایپرپارامترهایی مثل Temperature مهمه. دمای بالاتر (مثلاً T > 1.0) تنوع بیشتری در خروجی ایجاد می‌کنه، در حالی که دمای پایین‌تر (مثلاً T ≈ 0.7) جواب‌های دقیق‌تری میده.

۳. فیلتر کردن و امتیازدهی: خروجی‌های Teacher همیشه بی‌نقص نیستن و ممکنه شامل hallucination یا اطلاعات غلط باشن. به نظر من، مهم‌ترین قسمت داستان همین فیلتر کردنه. با استفاده از روش‌هایی مثل rejection sampling، بررسی `perplexity`، یا فیلترهای مبتنی بر قوانین، خروجی‌های بی‌کیفیت حذف میشن تا Student دیتای تمیزی برای یادگیری داشته باشه.

۴. فاین‌تیون کردن Student: مدل Student روی دیتاست تمیز شده فاین‌تیون میشه. تابع هزینه (loss function) معمولاً ترکیبی از دو بخشه: یکی `Cross-Entropy` روی لیبل‌های واقعی (اگه وجود داشته باشن) و دومی KL Divergence بین خروجی Student و Teacher. تفاوت بین رویکرد black-box (فقط دسترسی به متن خروجی Teacher) و white-box (دسترسی به logits) هم اینجا مشخص میشه.

با وجود تمام مزایا، این روش چالش‌هایی هم داره. بزرگ‌ترین مشکل، انتقال خطاها و hallucination های مدل Teacher به Student هست. اگه Teacher اطلاعات غلط تولید کنه، Student هم همون رو یاد می‌گیره. مسئله‌ی دیگه، "capacity gap" هست؛ یعنی وقتی Student خیلی کوچیک باشه، نمی‌تونه به خوبی از یه Teacher خیلی بزرگ یاد بگیره. همچنین مسائل قانونی مربوط به لایسنس API مدل‌های تجاری مثل GPT-4 هم وجود داره که استفاده از خروجی اون‌ها برای ترین کردن مدل‌های رقیب رو محدود می‌کنه.

📃 مقاله اصلی هینتون در مورد Distillation
Distilling the Knowledge in a Neural Network

📃 مقاله پروژه Orca که از CoT Distillation استفاده کرده
Orca: Progressive Learning from Complex Explanation Traces of GPT-4

🛠 Join @LLMEngineers Community

تیم Qwen از علی‌بابا یه مقاله‌ی جدید داده بیرون به اسم Group Sequence Policy Optimization یا GSPO. این همون الگوریتمیه که برای ترینینگ مدل‌های جدید سری Qwen3 با Reinforcement Learning استفاده شده. هدف اصلیش پایدارتر و بهینه‌تر کردن فرآیند RL برای مدل‌های زبانی بزرگه.

Group Sequence Policy Optimization

تحلیل مقاله رو هم اینجا گذاشتم:
https://news.1rj.ru/str/AI_LLMs/135/3002

🛠 Join @LLMEngineers Community

راهنمای پرامپتینگ مدل جدید GPT-4.1 رو خوندم. این مدل توی کدنویسی و دنبال کردن دستورات، یه سروگردن از GPT-4o بالاتره. برای اینکه بیشترین کارایی رو ازش بکشین، باید یه سری چیزا رو توی پرامپت‌هاتون تغییر بدین. این پست خلاصه‌ی نکات کلیدی و عملی این راهنماست.

نکته‌ی اصلی اینه که GPT-4.1 دستورات رو خیلی دقیق‌تر و کلمه‌به‌کلمه اجرا می‌کنه. برخلاف مدل‌های قبلی که سعی می‌کردن نیت شما رو حدس بزنن، این مدل دقیقاً همون کاری رو می‌کنه که ازش می‌خواین. این یعنی کنترل بیشتری دارین، ولی در عوض باید پرامپت‌های واضح‌تری بنویسین. اگه مدل رفتار عجیبی داشت، معمولاً یه جمله‌ی محکم و شفاف برای اصلاح رفتارش کافیه.

به نظر من، مهم‌ترین نکته همینه: GPT-4.1 کلمه‌به‌کلمه و به شدت تحت‌تأثیر دستورات شماست. پرامپت‌هایی که برای مدل‌های دیگه بهینه کردین، اینجا ممکنه نتیجه‌ی متفاوتی بدن چون مدل دیگه قوانین ضمنی رو استنباط نمی‌کنه.

راهکارهای عملی برای کار با GPT-4.1:

برای ساخت Agentic Workflows
این مدل برای ساخت ایجنت عالیه. برای اینکه ایجنت شما عملکرد بهتری داشته باشه، سه تا یادآوری کلیدی رو توی System Prompt قرار بدین:
۱. پایداری (Persistence): به مدل بگین که یه ایجنته و باید کار رو تا انتها ادامه بده و زود تسلیم نشه. اینجوری وسط کار کنترل رو به کاربر برنمی‌گردونه.
۲. فراخوانی ابزار (Tool-calling): بهش تأکید کنین که اگه اطلاعات کافی نداره، از ابزارهاش برای خوندن فایل‌ها و جمع‌آوری اطلاعات استفاده کنه و به هیچ وجه حدس نزنه.
۳. برنامه‌ریزی (Planning): از مدل بخواین که قبل و بعد از هر بار استفاده از ابزار، به صورت متنی فکر و برنامه‌ریزی کنه. این کار باعث می‌شه فقط یه سری Tool Call پشت سر هم نباشه و عمیق‌تر فکر کنه.
تیم OpenAI با همین سه دستور ساده، امتیاز SWE-bench Verified رو نزدیک به ۲۰٪ بهتر کرده.

فراخوانی ابزار یا Tool Calls
همیشه ابزارهاتون رو از طریق فیلد tools در API به مدل بدین، نه اینکه توضیحات ابزار رو دستی توی پرامپت تزریق کنین. این روش خطاها رو کم می‌کنه و طبق تست‌هاشون، ۲٪ در معیار SWE-bench عملکرد بهتری داشته. اسم و توضیحات ابزار و پارامترهاش رو واضح بنویسین.

استفاده از Chain-of-Thought
مدل GPT-4.1 به صورت پیش‌فرض reasoning model نیست، یعنی قبل از جواب دادن، زنجیره‌ای از افکار درونی تولید نمی‌کنه. اما شما می‌تونین با پرامپت، وادارش کنین که "بلند فکر کنه". یه دستور ساده مثل "First, think carefully step by step..." در انتهای پرامپت معمولاً کافیه. این کار توی بنچمارک SWE-bench تونسته ۴٪ بهبود ایجاد کنه.

کار با Context طولانی
این مدل تا یک میلیون توکن ورودی رو پشتیبانی می‌کنه. برای عملکرد بهتر در context های طولانی، دستورالعمل‌های اصلی رو هم در ابتدا و هم در انتهای متن context قرار بدین. این روش بهتر از اینه که دستورات فقط در بالا یا فقط در پایین باشن.
برای وارد کردن تعداد زیادی داکیومنت، فرمت XML یا فرمت‌های کاستوم مثل ID: 1 | TITLE: ... | CONTENT: ... عملکرد خیلی بهتری نسبت به JSON دارن. از JSON برای این کار استفاده نکنین چون عملکرد ضعیفی نشون داده.

فرمت‌بندی Diff برای کدنویسی
اگه ایجنت کدنویسی می‌سازین، GPT-4.1 توی تولید diff خیلی بهتر شده. OpenAI یه فرمت پیشنهادی معرفی کرده که مدل به خوبی روش آموزش دیده. ویژگی‌های کلیدی این فرمت اینه که از شماره خط استفاده نمی‌کنه و به جاش از متن اطراف کد برای پیدا کردن محل تغییر استفاده می‌کنه. این کار باعث می‌شه دقت مدل خیلی بالاتر بره.

در کل، این مدل قدرت کنترل بالایی به مهندس می‌ده، به شرطی که دستورات کاملاً واضح، دقیق و بدون ابهام باشن. باید شیوه‌ی پرامپت‌نویسی رو با این ذهنیت جدید تطبیق داد.

📃 Prompting Guide for GPT-4.1:
https://cookbook.openai.com/examples/gpt4-1_prompting_guide

🛠 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

یه توصیه برای وقتی که به دیوار ریاضیات تو مقاله‌های دیپ‌لرنینگ می‌خورین.

همه‌مون این تجربه رو داشتیم: مقاله رو باز می‌کنی، abstract و introduction رو می‌خونی، همه چی عالیه. بعد می‌رسی به بخش متدولوژی و فرمول‌ها. یهو حس می‌کنی تو یه دنیای دیگه فرود اومدی. مغزت قفل می‌کنه و مقاله رو می‌بندی. بذار یه چیزی رو رک بهتون بگم: مشکل از شما نیست، مشکل از روشتونه.

فرمول ریاضی رو نباید «خوند». باید باهاش کشتی گرفت. باید تجزیه‌ش کرد. هدف اینه که یه «شهود» بسازی از کاری که اون فرمول انجام میده. لازم نیست تک‌تک نمادهاشو حفظ کنی. باید داستان پشتش رو بفهمی.

این چهارتا قدم رو برو، مشکلت حل میشه:

۱. اول تمام فرمول‌ها رو پیدا کن و یه جا جمع کن. فقط اونایی که تو متن هستن نه، حتی اونایی که فقط بهشون ارجاع داده شده (مثلاً میگه ما از Adam استفاده کردیم). این‌ها پایه‌های کارت هستن.

۲. همه‌شون رو از مانیتور بکش بیرون و روی یه تیکه کاغذ واقعی بنویس. این مهم‌ترین بخشه. وقتی فرمول رو کاغذ میاد، دستت بازه. می‌تونی دورش خط بکشی، فلش بزنی، قطعه‌هاشو از هم جدا کنی و کنارش نوت برداری کنی. محدودیت‌های دیجیتال رو نداری و تمرکزت هزار برابر میشه.

۳. حالا وقت ترجمه‌ست. سمبل‌ها رو به مفهوم تبدیل کن.
اول ببین هر حرف یونانی (مثل α, θ, L) چه معنی‌ای داره. معمولاً اول مقاله تو بخش Preliminaries یا Notation توضیح دادن. مثلاً θ همون وزن‌های مدله. α نرخ یادگیریه. L هم تابع هزینه.
بعد ببین اینا چطوری با عملیات ریاضی (+, -, √) به هم وصل شدن. مثلاً وقتی میگه θ_new = θ_old - α * ∇L یعنی وزن‌های جدید میشه وزن‌های قدیمی منهای یه قدم کوچیک در جهت مخالف گرادیان. این یعنی داریم loss رو کم می‌کنیم.

۴. در آخر، از خودت بپرس «خب که چی؟». اون شهود کلی رو بساز.
بعد از اینکه فهمیدی هر تیکه داره چیکار می‌کنه، یه جمله ساده برای خودت بساز. مثلاً الگوریتم QHM چیه؟ یه میانگین وزن‌دار بین آپدیت momentum و آپدیت SGD ساده‌ست. یا QHAdam چیه؟ همین ایده رو برداشته و روی Adam پیاده کرده تا انعطاف بیشتری داشته باشه. همین. حالا دیگه اون فرمول طولانی و ترسناک برات یه مفهوم ساده و قابل فهم داره.

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

🛠 Join @LLMEngineers Community

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

مسئله اصلی سر کلمه‌ی «خودگردانی» یا 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

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

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

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

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

🛠 Join @LLMEngineers Community

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

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

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

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

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


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

🛠 Join @LLMEngineers Community

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

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

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

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

🛠 Join @LLMEngineers Community

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

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

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

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

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

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

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

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

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

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

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

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

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

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

pip install trackio

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

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

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

🛠 Join @LLMEngineers Community

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🛠 Join @LLMEngineers Community

🎯 100 Days of Reading ML / LLM Papers Challenge

Day 4: An overview of gradient descent optimization algorithms

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

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

🛠 @LLMEngineers

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

🛠 Join @LLMEngineers Community