مدل جدید Qwen3-Omni از علیبابا منتشر شده و سروصدای زیادی کرده. این مدل یه جهش جدی تو مدلهای چندوجهی (multimodal) به حساب میاد.
کاربرد اصلیش ساختن دستیارهای هوشمنده که میتونن همزمان متن، عکس، صدا و ویدیو رو درک کنن و در لحظه خروجی متنی و صوتی (real-time speech) تولید کنن. دیگه خبری از چسبوندن چندتا مدل مختلف به هم نیست؛ Qwen3-Omni یه مدل واحد و end-to-end هست.
معماری این مدل بر اساس یک ساختار Thinker-Talker مبتنی بر MoE طراحی شده. یه بخش Thinker وظیفهی درک ورودیهای چندوجهی و استدلال رو بر عهده داره و خروجیهای سطح بالاش رو به یه بخش Talker میده. بخش Talker هم با استفاده از یه codebook عصبی، صدا رو با latency خیلی پایین (حدود ۲۱۱ میلیثانیه) تولید میکنه.
سه تا مدل ۳۰ میلیاردی از این خانواده با لایسنس Apache-2.0 اپنسورس شدن:
Qwen3-Omni-30B-A3B-Instruct:
مدل اصلی که هم Thinker و هم Talker رو داره. برای ساخت دستیارهای هوشمند و کاربردهای عمومی طراحی شده و خروجی متن و صدا میده.
Qwen3-Omni-30B-A3B-Thinking:
فقط شامل بخش Thinker میشه. برای کارهای سنگین تحلیلی و استدلال چندوجهی که فقط به خروجی متنی نیاز دارن، بهینه شده.
Qwen3-Omni-30B-A3B-Captioner:
یه مدل تخصصی که روی Instruct فاینتیون شده تا بتونه برای ورودیهای صوتی، کپشنهای دقیق و با کمترین میزان توهم (hallucination) تولید کنه.
برای اجرای این مدلها به سختافزار جدی نیاز هست. مدل Instruct برای پردازش یه ویدیوی ۱۵ ثانیهای حدود ۷۹ گیگابایت VRAM و برای یه ویدیوی ۲ دقیقهای تا ۱۴۵ گیگابایت VRAM مصرف میکنه. به همین خاطر، تیم توسعهدهنده استفاده از vLLM رو برای اجرا توصیه کرده چون برای مدلهای MoE بهینهتره. پشتیبانی از Transformers هم اضافه شده ولی فعلاً باید از سورس نصب بشه.
به نظر من، Qwen3-Omni یه گام فنی خیلی مهمه، چون مفهوم omni-modal رو به شکل یکپارچه و اپنسورس پیادهسازی کرده. مدل Captioner به تنهایی یه ابزار خیلی ارزشمند برای جامعهست چون چنین مدل تخصصی و باکیفیتی برای تحلیل صوت کمتر پیدا میشه. با این حال، نیاز بالای این مدلها به VRAM، استفاده ازشون رو برای دولوپرهای مستقل و تیمهای کوچیک تقریباً غیرممکن میکنه و بیشتر به درد شرکتهای بزرگ و آزمایشگاههای تحقیقاتی میخوره. باید توجه داشت که نسخهی Flash-Realtime که پایینترین latency رو داره، یه سرویس API پولی هست و با مدلهای اپنسورس متفاوته.
🤗 مدلها در هاگینگفیس
🛠 Join @LLMEngineers Community
کاربرد اصلیش ساختن دستیارهای هوشمنده که میتونن همزمان متن، عکس، صدا و ویدیو رو درک کنن و در لحظه خروجی متنی و صوتی (real-time speech) تولید کنن. دیگه خبری از چسبوندن چندتا مدل مختلف به هم نیست؛ Qwen3-Omni یه مدل واحد و end-to-end هست.
معماری این مدل بر اساس یک ساختار Thinker-Talker مبتنی بر MoE طراحی شده. یه بخش Thinker وظیفهی درک ورودیهای چندوجهی و استدلال رو بر عهده داره و خروجیهای سطح بالاش رو به یه بخش Talker میده. بخش Talker هم با استفاده از یه codebook عصبی، صدا رو با latency خیلی پایین (حدود ۲۱۱ میلیثانیه) تولید میکنه.
سه تا مدل ۳۰ میلیاردی از این خانواده با لایسنس Apache-2.0 اپنسورس شدن:
Qwen3-Omni-30B-A3B-Instruct:
مدل اصلی که هم Thinker و هم Talker رو داره. برای ساخت دستیارهای هوشمند و کاربردهای عمومی طراحی شده و خروجی متن و صدا میده.
Qwen3-Omni-30B-A3B-Thinking:
فقط شامل بخش Thinker میشه. برای کارهای سنگین تحلیلی و استدلال چندوجهی که فقط به خروجی متنی نیاز دارن، بهینه شده.
Qwen3-Omni-30B-A3B-Captioner:
یه مدل تخصصی که روی Instruct فاینتیون شده تا بتونه برای ورودیهای صوتی، کپشنهای دقیق و با کمترین میزان توهم (hallucination) تولید کنه.
برای اجرای این مدلها به سختافزار جدی نیاز هست. مدل Instruct برای پردازش یه ویدیوی ۱۵ ثانیهای حدود ۷۹ گیگابایت VRAM و برای یه ویدیوی ۲ دقیقهای تا ۱۴۵ گیگابایت VRAM مصرف میکنه. به همین خاطر، تیم توسعهدهنده استفاده از vLLM رو برای اجرا توصیه کرده چون برای مدلهای MoE بهینهتره. پشتیبانی از Transformers هم اضافه شده ولی فعلاً باید از سورس نصب بشه.
به نظر من، Qwen3-Omni یه گام فنی خیلی مهمه، چون مفهوم omni-modal رو به شکل یکپارچه و اپنسورس پیادهسازی کرده. مدل Captioner به تنهایی یه ابزار خیلی ارزشمند برای جامعهست چون چنین مدل تخصصی و باکیفیتی برای تحلیل صوت کمتر پیدا میشه. با این حال، نیاز بالای این مدلها به VRAM، استفاده ازشون رو برای دولوپرهای مستقل و تیمهای کوچیک تقریباً غیرممکن میکنه و بیشتر به درد شرکتهای بزرگ و آزمایشگاههای تحقیقاتی میخوره. باید توجه داشت که نسخهی Flash-Realtime که پایینترین latency رو داره، یه سرویس API پولی هست و با مدلهای اپنسورس متفاوته.
🤗 مدلها در هاگینگفیس
🛠 Join @LLMEngineers Community
یه مقایسهی بیتعارف و بهروز از ابزارهای اصلی برای ران کردن LLMها، چه لوکال چه روی پروداکشن. ابزارها بر اساس کاری که واقعاً انجام میدن دستهبندی شدن تا انتخاب راحتتر باشه.
اول از همه، راهنمای سریع انتخاب بر اساس موقعیت:
اگه فقط یه اپ دسکتاپ ساده میخوای (دانلود، کلیک، چت/API):
برو سراغ LM Studio که هم UI داره هم سرور محلی سازگار با OpenAI. گزینههای دیگه Ollama (برای کارای سریع با CLI) و Jan (اپ دسکتاپ اوپنسورس) هستن. هر سه عمدتاً از اکوسیستم GGUF و llama.cpp استفاده میکنن.
اگه دنبال throughput بالا برای پروداکشن با کلی کاربر هستی: vLLM با تکنیک PagedAttention و continuous batching یه استاندارد صنعتیه. SGLang هم با RadixAttention و بهینهسازیهای خفنش رقیب جدیایه. Text-Generation-Inference (TGI) از Hugging Face هم یه گزینهی قوی برای پروداکشنه.
اگه فقط روی سختافزار NVIDIA کار میکنی و دنبال نهایت سرعت و کمترین latency هستی: TensorRT-LLM انتخاب اوله. با بهینهسازیهای سطح پایین مثل Inflight batching و کوانتیزیشن FP8/INT4، بهترین پرفورمنس رو از GPUهای انویدیا بیرون میکشه.
اگه روی Apple Silicon (مک) کد میزنی: MLX و MLX-LM که خود اپل توسعه داده بهترین گزینه هستن. از Metal و معماری unified memory استفاده میکنن و تجربهی روانی رو روی مک فراهم میکنن.
اگه میخوای مدل رو کامل روی موبایل یا توی مرورگر ران کنی: MLC LLM و WebLLM این کار رو با کامپایل کردن مدل برای اندروید، iOS و WebGPU انجام میدن. حتی یه API سازگار با OpenAI سمت کلاینت توی مرورگر ارائه میدن.
اگه دنبال یه موتور سبک برای CPU یا اکوسیستم GGUF هستی: llama.cpp خود جنسه. یه موتور سبک C/C++ با پشتیبانی از CUDA, Metal و حتی Vulkan که یه سرور داخلی سازگار با OpenAI هم داره.
اگه یه GPU انویدیای تکی داری و میخوای مدلهای بزرگ رو با کوانتیزیشن 4-bit ران کنی: ExLlamaV2/V3 با کرنلهای کاستوم CUDA برای فرمتهای GPTQ/EXL2/EXL3 ساخته شده. سرعتش تو این سناریو فوقالعادهست.
حالا چندتا نکتهی کلیدی که از تجربه میاد:
اول اینکه، هرجا دیدی نوشته "OpenAI-compatible" لزوماً به معنی جایگزینی صددرصدی نیست. سرورهای vLLM و TGI خیلی قوی و قابل اعتمادن. سرور داخلی llama.cpp هم کار راهاندازه. ولی مثلاً سازگاری Ollama هنوز experimental محسوب میشه و برای کارهای پیشرفته بهتره از API اصلیش استفاده بشه.
دوم اینکه، اکوسیستمهای کوانتیزیشن با هم فرق دارن. فرمت GGUF مال خانوادهی llama.cpp (مثل LM Studio و Ollama) هست. در حالی که سرورهای پروداکشن مثل vLLM و TGI بیشتر با فرمتهای GPTQ, AWQ یا FP8 که توی safetensors ذخیره شدن کار میکنن. نمیشه اینا رو جای هم استفاده کرد.
سوم، Speculative decoding که برای افزایش سرعت استفاده میشه، همهجا به یه شکل پیادهسازی نشده و گاهی نیاز به تنظیمات دقیق برای هر مدل داره. توی TensorRT-LLM و SGLang خیلی خوب پیادهسازی شده ولی انتظار معجزه نداشته باش.
🛠 Join @LLMEngineers Community
اول از همه، راهنمای سریع انتخاب بر اساس موقعیت:
اگه فقط یه اپ دسکتاپ ساده میخوای (دانلود، کلیک، چت/API):
برو سراغ LM Studio که هم UI داره هم سرور محلی سازگار با OpenAI. گزینههای دیگه Ollama (برای کارای سریع با CLI) و Jan (اپ دسکتاپ اوپنسورس) هستن. هر سه عمدتاً از اکوسیستم GGUF و llama.cpp استفاده میکنن.
اگه دنبال throughput بالا برای پروداکشن با کلی کاربر هستی: vLLM با تکنیک PagedAttention و continuous batching یه استاندارد صنعتیه. SGLang هم با RadixAttention و بهینهسازیهای خفنش رقیب جدیایه. Text-Generation-Inference (TGI) از Hugging Face هم یه گزینهی قوی برای پروداکشنه.
اگه فقط روی سختافزار NVIDIA کار میکنی و دنبال نهایت سرعت و کمترین latency هستی: TensorRT-LLM انتخاب اوله. با بهینهسازیهای سطح پایین مثل Inflight batching و کوانتیزیشن FP8/INT4، بهترین پرفورمنس رو از GPUهای انویدیا بیرون میکشه.
اگه روی Apple Silicon (مک) کد میزنی: MLX و MLX-LM که خود اپل توسعه داده بهترین گزینه هستن. از Metal و معماری unified memory استفاده میکنن و تجربهی روانی رو روی مک فراهم میکنن.
اگه میخوای مدل رو کامل روی موبایل یا توی مرورگر ران کنی: MLC LLM و WebLLM این کار رو با کامپایل کردن مدل برای اندروید، iOS و WebGPU انجام میدن. حتی یه API سازگار با OpenAI سمت کلاینت توی مرورگر ارائه میدن.
اگه دنبال یه موتور سبک برای CPU یا اکوسیستم GGUF هستی: llama.cpp خود جنسه. یه موتور سبک C/C++ با پشتیبانی از CUDA, Metal و حتی Vulkan که یه سرور داخلی سازگار با OpenAI هم داره.
اگه یه GPU انویدیای تکی داری و میخوای مدلهای بزرگ رو با کوانتیزیشن 4-bit ران کنی: ExLlamaV2/V3 با کرنلهای کاستوم CUDA برای فرمتهای GPTQ/EXL2/EXL3 ساخته شده. سرعتش تو این سناریو فوقالعادهست.
حالا چندتا نکتهی کلیدی که از تجربه میاد:
اول اینکه، هرجا دیدی نوشته "OpenAI-compatible" لزوماً به معنی جایگزینی صددرصدی نیست. سرورهای vLLM و TGI خیلی قوی و قابل اعتمادن. سرور داخلی llama.cpp هم کار راهاندازه. ولی مثلاً سازگاری Ollama هنوز experimental محسوب میشه و برای کارهای پیشرفته بهتره از API اصلیش استفاده بشه.
دوم اینکه، اکوسیستمهای کوانتیزیشن با هم فرق دارن. فرمت GGUF مال خانوادهی llama.cpp (مثل LM Studio و Ollama) هست. در حالی که سرورهای پروداکشن مثل vLLM و TGI بیشتر با فرمتهای GPTQ, AWQ یا FP8 که توی safetensors ذخیره شدن کار میکنن. نمیشه اینا رو جای هم استفاده کرد.
سوم، Speculative decoding که برای افزایش سرعت استفاده میشه، همهجا به یه شکل پیادهسازی نشده و گاهی نیاز به تنظیمات دقیق برای هر مدل داره. توی TensorRT-LLM و SGLang خیلی خوب پیادهسازی شده ولی انتظار معجزه نداشته باش.
🛠 Join @LLMEngineers Community
یه گزارش مفصل از خود OpenAI منتشر شده که دادههای واقعی استفادهی کاربران از ChatGPT رو تحلیل کرده. این گزارش بر اساس میلیونها پیام (البته ناشناسسازی شده) نوشته شده و نشون میده مردم واقعاً دارن با این ابزار چیکار میکنن.
کاربرد اصلی ChatGPT برخلاف تصور عمومی، اصلاً برای کار نیست. حدود ۷۰ درصد استفادهها کاملاً شخصیه و این سهم روزبهروز در حال افزایشه. در حالی که بیشتر تحلیلهای اقتصادی روی افزایش بهرهوری تو محیط کار تمرکز دارن، دادهها نشون میده ارزش واقعی این تکنولوژی فعلاً تو زندگی روزمرهی مردمه.
دستهبندی کلی کاربردها به این شکله:
۱. راهنمایی عملی (Practical Guidance): حدود ۲۹٪ کل پیامها. شامل مشاوره، آموزش، ایدهپردازی و دستورالعملهای مختلف.
۲. جستجوی اطلاعات (Seeking Information): حدود ۲۴٪. این بخش یه جایگزین مستقیم برای موتورهای جستجوی سنتیه.
۳. نوشتن (Writing): حدود ۲۴٪. شامل تولید ایمیل، اسناد، خلاصهسازی و ترجمه.
دو تا نکتهی خیلی جالب هم وجود داره. اول اینکه برنامهنویسی فقط ۴.۲٪ از کل استفادهها رو تشکیل میده که با تصور خیلیها که ChatGPT رو ابزار اصلی کدنویسی میدونن، در تضاده. دوم اینکه کاربردهای مربوط به روابط عاطفی و همراهی (Companionship) فقط ۱.۹٪ هست که نشون میده هایپ رسانهها در این مورد با واقعیت فاصله داره.
مهمترین کاربرد ChatGPT در محیط کار، نوشتن (Writing) هست که ۴۰٪ پیامهای کاری رو شامل میشه. اینجا یه نکتهی خیلی ظریف وجود داره: حدود دو سوم از این درخواستهای نوشتن، مربوط به ویرایش، نقد، خلاصهسازی یا ترجمهی متنی هست که خود کاربر به مدل داده؛ نه تولید محتوای کاملاً جدید از صفر. یعنی بیشتر به عنوان یه دستیار ویراستار فوق هوشمند استفاده میشه تا یه تولیدکنندهی محتوا.
این گزارش یه دستهبندی جدید هم معرفی کرده: Asking در مقابل Doing.
Asking:
وقتی کاربر دنبال اطلاعات یا مشاوره برای تصمیمگیری بهتره (حدود ۴۹٪).
Doing:
وقتی کاربر از مدل میخواد یه خروجی مشخص مثل کد، ایمیل یا جدول تولید کنه (حدود ۴۰٪).
دادهها نشون میده که استفادههای نوع Asking سریعتر از Doing در حال رشده و رضایت کاربر هم از این نوع تعاملات بیشتره. این یعنی ارزش اصلی مدلها برای کاربر، نه فقط اتوماسیون وظایف، بلکه پشتیبانی از فرآیند تصمیمگیریه.
به نظر من، این گزارش تأیید میکنه که قدرت اصلی LLMها در حال حاضر، نه جایگزینی انسان (co-worker)، بلکه تقویت تواناییهای اون (co-pilot) هست. بیشترین ارزش اقتصادی از طریق پشتیبانی در تصمیمگیری (decision support) ایجاد میشه، مخصوصاً برای نیروهای متخصصی که کیفیت تصمیمهاشون مستقیماً روی خروجی کار تأثیر داره.
📃 مقاله
🛠 Join @LLMEngineers Community
کاربرد اصلی ChatGPT برخلاف تصور عمومی، اصلاً برای کار نیست. حدود ۷۰ درصد استفادهها کاملاً شخصیه و این سهم روزبهروز در حال افزایشه. در حالی که بیشتر تحلیلهای اقتصادی روی افزایش بهرهوری تو محیط کار تمرکز دارن، دادهها نشون میده ارزش واقعی این تکنولوژی فعلاً تو زندگی روزمرهی مردمه.
دستهبندی کلی کاربردها به این شکله:
۱. راهنمایی عملی (Practical Guidance): حدود ۲۹٪ کل پیامها. شامل مشاوره، آموزش، ایدهپردازی و دستورالعملهای مختلف.
۲. جستجوی اطلاعات (Seeking Information): حدود ۲۴٪. این بخش یه جایگزین مستقیم برای موتورهای جستجوی سنتیه.
۳. نوشتن (Writing): حدود ۲۴٪. شامل تولید ایمیل، اسناد، خلاصهسازی و ترجمه.
دو تا نکتهی خیلی جالب هم وجود داره. اول اینکه برنامهنویسی فقط ۴.۲٪ از کل استفادهها رو تشکیل میده که با تصور خیلیها که ChatGPT رو ابزار اصلی کدنویسی میدونن، در تضاده. دوم اینکه کاربردهای مربوط به روابط عاطفی و همراهی (Companionship) فقط ۱.۹٪ هست که نشون میده هایپ رسانهها در این مورد با واقعیت فاصله داره.
مهمترین کاربرد ChatGPT در محیط کار، نوشتن (Writing) هست که ۴۰٪ پیامهای کاری رو شامل میشه. اینجا یه نکتهی خیلی ظریف وجود داره: حدود دو سوم از این درخواستهای نوشتن، مربوط به ویرایش، نقد، خلاصهسازی یا ترجمهی متنی هست که خود کاربر به مدل داده؛ نه تولید محتوای کاملاً جدید از صفر. یعنی بیشتر به عنوان یه دستیار ویراستار فوق هوشمند استفاده میشه تا یه تولیدکنندهی محتوا.
این گزارش یه دستهبندی جدید هم معرفی کرده: Asking در مقابل Doing.
Asking:
وقتی کاربر دنبال اطلاعات یا مشاوره برای تصمیمگیری بهتره (حدود ۴۹٪).
Doing:
وقتی کاربر از مدل میخواد یه خروجی مشخص مثل کد، ایمیل یا جدول تولید کنه (حدود ۴۰٪).
دادهها نشون میده که استفادههای نوع Asking سریعتر از Doing در حال رشده و رضایت کاربر هم از این نوع تعاملات بیشتره. این یعنی ارزش اصلی مدلها برای کاربر، نه فقط اتوماسیون وظایف، بلکه پشتیبانی از فرآیند تصمیمگیریه.
به نظر من، این گزارش تأیید میکنه که قدرت اصلی LLMها در حال حاضر، نه جایگزینی انسان (co-worker)، بلکه تقویت تواناییهای اون (co-pilot) هست. بیشترین ارزش اقتصادی از طریق پشتیبانی در تصمیمگیری (decision support) ایجاد میشه، مخصوصاً برای نیروهای متخصصی که کیفیت تصمیمهاشون مستقیماً روی خروجی کار تأثیر داره.
📃 مقاله
🛠 Join @LLMEngineers Community
یه مقایسهی جالب از روند ساخت LLMها بین سال ۲۰۲۳ و ۲۰۲۵
۱. مرحله Pretraining: تمرکز از دیتا میکسهای عمومی رفته روی دیتاهای باکیفیتتر. اولویت با کد بوده و الان دیگه synthetic data هم بهش اضافه شده.
۲. مرحله Midtraining: این مرحلهی جدید، یه جور fine-tuning تخصصی بین pretraining و post-training هست. اینجا قابلیتهای خاص مثل افزایش طول متن (Context-expansion) یا تمرکز روی تسکهای استدلالی سنگین (Reasoning heavy) به مدل تزریق میشه. به نظر من، این مرحله مهمترین تغییره چون اجازه میده مدلها برای کاربردهای خاص بهینه بشن بدون اینکه نیاز به pretrain از اول باشه.
۳. مرحله Post-training: این فاز هم دقیقتر شده. قبلاً کلیگویی بود، اما الان به دو بخش مشخص SFT برای یادگیری دنبال کردن دستورات و RL برای همراستاسازی نهایی با ترجیحات انسانی تقسیم شده.
۴. مرحله Model Merging: این تکنیک به عنوان یه مرحلهی نهایی و مستقل اضافه شده. به جای ساخت یک مدل غولپیکر، چند مدل متخصص رو با هم ادغام میکنن تا بهترین قابلیتهای هر کدوم رو داشته باشن. این روش از نظر محاسباتی خیلی بهینهتره.
🛠 Join @LLMEngineers Community
۱. مرحله Pretraining: تمرکز از دیتا میکسهای عمومی رفته روی دیتاهای باکیفیتتر. اولویت با کد بوده و الان دیگه synthetic data هم بهش اضافه شده.
۲. مرحله Midtraining: این مرحلهی جدید، یه جور fine-tuning تخصصی بین pretraining و post-training هست. اینجا قابلیتهای خاص مثل افزایش طول متن (Context-expansion) یا تمرکز روی تسکهای استدلالی سنگین (Reasoning heavy) به مدل تزریق میشه. به نظر من، این مرحله مهمترین تغییره چون اجازه میده مدلها برای کاربردهای خاص بهینه بشن بدون اینکه نیاز به pretrain از اول باشه.
۳. مرحله Post-training: این فاز هم دقیقتر شده. قبلاً کلیگویی بود، اما الان به دو بخش مشخص SFT برای یادگیری دنبال کردن دستورات و RL برای همراستاسازی نهایی با ترجیحات انسانی تقسیم شده.
۴. مرحله Model Merging: این تکنیک به عنوان یه مرحلهی نهایی و مستقل اضافه شده. به جای ساخت یک مدل غولپیکر، چند مدل متخصص رو با هم ادغام میکنن تا بهترین قابلیتهای هر کدوم رو داشته باشن. این روش از نظر محاسباتی خیلی بهینهتره.
🛠 Join @LLMEngineers Community
مجموعه AgentKit از OpenAI معرفی شد. یه ابزار کامل برای ساخت، دیپلوی و بهینهسازی Agentic Workflows. هدف اینه که کل چرخه ساخت یه Agent رو از صفر تا صد پوشش بده و دولوپر رو توی اکوسیستم خودش نگه داره.
این کیت از چند بخش اصلی تشکیل شده:
Agent Builder:
یه محیط ویژوال و node-based برای ساختن ورکفلوهای چندمرحلهای. به صورت drag-and-drop میشه نودها (مدل، ابزار، منطق شرطی) رو به هم وصل کرد و یه Agent ساخت.
ChatKit:
یه UI قابل embed و شخصیسازی برای استفاده از Agent ساخته شده. بعد از ساخت ورکفلو، یه ID بهت میده که میتونی توی ChatKit ازش استفاده کنی و UI رو توی محصول خودت بذاری.
Guardrails:
برای کنترل و ایمنسازی ورودی و خروجیهای Agent.
Evals:
ابزارهایی برای ارزیابی عملکرد Agent، شامل trace grading، ساخت دیتاست و بهینهسازی خودکار پرامپت.
روند کار به این صورته که اول با Agent Builder ورکفلو رو طراحی میکنی، بعد منتشرش میکنی و در نهایت با ChatKit یا Agents SDK (برای پایتون و تایپاسکریپت) توی محصول خودت دیپلوی میکنی. این چرخه کامل، از طراحی تا ارزیابی، باعث میشه فرآیند توسعه سریعتر بشه.
به نظر من، این یه حرکت کاملاً استراتژیک برای lock-in کردن دولوپرهاست. OpenAI داره کل استک رو به صورت عمودی یکپارچه میکنه تا نیاز به ابزارهای جانبی مثل LangChain یا LlamaIndex رو برای پروژههای جدید کمتر کنه. با داشتن Evals و Guardrails داخلی، نیازمندیهای سطح enterprise رو هم هدف گرفته.
البته هنوز جایگزین ابزارهای اتومیشن مثل Zapier یا n8n نیست، چون اونها اکوسیستم بزرگتری از integration ها دارن. یکی از نقدهای جدی که بهش وارده، نبود قابلیت import/export برای ورکفلوهاست که باعث میشه شبیه یه سیستم بسته مثل Custom GPT ها عمل کنه و قابلیت انتقالپذیری نداشته باشه.
📃 معرفی AgentKit در بلاگ OpenAI
📃 مستندات Agent Builder
💻 نمونه استارتر ChatKit در گیتهاب
🛠 Join @LLMEngineers Community
این کیت از چند بخش اصلی تشکیل شده:
Agent Builder:
یه محیط ویژوال و node-based برای ساختن ورکفلوهای چندمرحلهای. به صورت drag-and-drop میشه نودها (مدل، ابزار، منطق شرطی) رو به هم وصل کرد و یه Agent ساخت.
ChatKit:
یه UI قابل embed و شخصیسازی برای استفاده از Agent ساخته شده. بعد از ساخت ورکفلو، یه ID بهت میده که میتونی توی ChatKit ازش استفاده کنی و UI رو توی محصول خودت بذاری.
Guardrails:
برای کنترل و ایمنسازی ورودی و خروجیهای Agent.
Evals:
ابزارهایی برای ارزیابی عملکرد Agent، شامل trace grading، ساخت دیتاست و بهینهسازی خودکار پرامپت.
روند کار به این صورته که اول با Agent Builder ورکفلو رو طراحی میکنی، بعد منتشرش میکنی و در نهایت با ChatKit یا Agents SDK (برای پایتون و تایپاسکریپت) توی محصول خودت دیپلوی میکنی. این چرخه کامل، از طراحی تا ارزیابی، باعث میشه فرآیند توسعه سریعتر بشه.
به نظر من، این یه حرکت کاملاً استراتژیک برای lock-in کردن دولوپرهاست. OpenAI داره کل استک رو به صورت عمودی یکپارچه میکنه تا نیاز به ابزارهای جانبی مثل LangChain یا LlamaIndex رو برای پروژههای جدید کمتر کنه. با داشتن Evals و Guardrails داخلی، نیازمندیهای سطح enterprise رو هم هدف گرفته.
البته هنوز جایگزین ابزارهای اتومیشن مثل Zapier یا n8n نیست، چون اونها اکوسیستم بزرگتری از integration ها دارن. یکی از نقدهای جدی که بهش وارده، نبود قابلیت import/export برای ورکفلوهاست که باعث میشه شبیه یه سیستم بسته مثل Custom GPT ها عمل کنه و قابلیت انتقالپذیری نداشته باشه.
📃 معرفی AgentKit در بلاگ OpenAI
📃 مستندات Agent Builder
💻 نمونه استارتر ChatKit در گیتهاب
🛠 Join @LLMEngineers Community
Openai
Introducing AgentKit
New tools for building, deploying, and optimizing agents.
مدلهای جدید Granite 4.0 از IBM منتشر شدن و هدفشون رقابت روی لیدربوردها نیست. این خانواده از مدلها برای کارهای واقعی و بیزینسی طراحی شدن، جایی که هزینه و پرفورمنس روی GPU های معمولی مهمه، نه فقط اعداد و ارقام تئوری. کاربرد اصلیشون توی ساخت ایجنتهای نرمافزاری، اتوماسیون پشتیبانی و تسکهای مبتنی بر function-calling هست که نیاز به سرعت و مصرف رم پایین دارن.
معماری این مدلها یه ترکیب هیبریدی از Mamba-2 و Transformer هست. بیشتر لایهها از نوع Mamba-2 هستن که یه State Space Model (SSM) محسوب میشه و باعث میشه مقیاسپذیری با افزایش طول متن، خطی باشه. چند تا بلاک Transformer هم به صورت دورهای در معماری قرار داده شده. نتیجهی این طراحی، کاهش ۷۰ درصدی مصرف RAM در پردازش متنهای طولانی و افزایش توان پردازشی (throughput) در بچسایزهای بالاست. مدلهای بزرگتر از معماری Mixture of Experts (MoE) هم استفاده میکنن تا پارامترهای فعال رو پایین نگه دارن.
مدلهای اصلی که فعلاً به صورت Base و Instruct عرضه شدن اینها هستن:
Granite-4.0-H-Small:
مدل اصلی با ۳۲ میلیارد پارامتر (۹ میلیارد فعال). برای ساخت ایجنتهای پیچیده که با چند ابزار کار میکنن مناسبه. روی ۸-بیت حدود ۳۳ گیگ رم لازم داره.
Granite-4.0-H-Tiny:
یه مدل جمعوجور با ۷ میلیارد پارامتر (۱ میلیارد فعال). برای کارهای سبک روی سختافزارهای ضعیفتر (Edge) یا سیستمهای لوکال با رم ۸ تا ۱۲ گیگ عالیه. روی ۸-بیت حدود ۸ گیگ رم میگیره.
Granite-4.0-H-Micro:
یه مدل ۳ میلیاردی بدون MoE. برای دستگاههای خیلی محدود با ۴ گیگ رم GPU طراحی شده.
Granite-4.0-Micro:
یه نسخهی ۳ میلیاردی دیگه که کاملاً مبتنی بر Transformer هست. این مدل برای سازگاری حداکثری با فریمورکهایی که هنوز معماری هیبریدی رو کامل ساپورت نمیکنن، ارائه شده.
به نظر من، حرکت IBM به سمت مدلهای کوچیک، بهینه و اپنسورس (Apache-2.0) خیلی هوشمندانهست. بازار داره از مدلهای غولپیکر و پرهزینه اشباع میشه و نیاز به مدلهایی که بشه به راحتی روی یه A100 یا حتی RTX 3060 اجراشون کرد، کاملاً حس میشه. تمرکز روی function-calling و instruction-following هم نشون میده که هدف، کاربردهای عملی و agentic بوده. این مدلها برای cosplay کردن SOTA ساخته نشدن، برای کار واقعی طراحی شدن.
برای اجرا و تست، مدلها روی Hugging Face، Ollama و LM Studio در دسترس هستن. پشتیبانی کامل از vLLM و Transformers هم وجود داره. نسخههای بهینهشده برای استدلال (Thinking) هم اواخر ۲۰۲۵ منتشر میشن.
📃 بیانیهی رسمی IBM
📃 کالکشن مدلها در Hugging Face
🛠 Join @LLMEngineers Community
معماری این مدلها یه ترکیب هیبریدی از Mamba-2 و Transformer هست. بیشتر لایهها از نوع Mamba-2 هستن که یه State Space Model (SSM) محسوب میشه و باعث میشه مقیاسپذیری با افزایش طول متن، خطی باشه. چند تا بلاک Transformer هم به صورت دورهای در معماری قرار داده شده. نتیجهی این طراحی، کاهش ۷۰ درصدی مصرف RAM در پردازش متنهای طولانی و افزایش توان پردازشی (throughput) در بچسایزهای بالاست. مدلهای بزرگتر از معماری Mixture of Experts (MoE) هم استفاده میکنن تا پارامترهای فعال رو پایین نگه دارن.
مدلهای اصلی که فعلاً به صورت Base و Instruct عرضه شدن اینها هستن:
Granite-4.0-H-Small:
مدل اصلی با ۳۲ میلیارد پارامتر (۹ میلیارد فعال). برای ساخت ایجنتهای پیچیده که با چند ابزار کار میکنن مناسبه. روی ۸-بیت حدود ۳۳ گیگ رم لازم داره.
Granite-4.0-H-Tiny:
یه مدل جمعوجور با ۷ میلیارد پارامتر (۱ میلیارد فعال). برای کارهای سبک روی سختافزارهای ضعیفتر (Edge) یا سیستمهای لوکال با رم ۸ تا ۱۲ گیگ عالیه. روی ۸-بیت حدود ۸ گیگ رم میگیره.
Granite-4.0-H-Micro:
یه مدل ۳ میلیاردی بدون MoE. برای دستگاههای خیلی محدود با ۴ گیگ رم GPU طراحی شده.
Granite-4.0-Micro:
یه نسخهی ۳ میلیاردی دیگه که کاملاً مبتنی بر Transformer هست. این مدل برای سازگاری حداکثری با فریمورکهایی که هنوز معماری هیبریدی رو کامل ساپورت نمیکنن، ارائه شده.
به نظر من، حرکت IBM به سمت مدلهای کوچیک، بهینه و اپنسورس (Apache-2.0) خیلی هوشمندانهست. بازار داره از مدلهای غولپیکر و پرهزینه اشباع میشه و نیاز به مدلهایی که بشه به راحتی روی یه A100 یا حتی RTX 3060 اجراشون کرد، کاملاً حس میشه. تمرکز روی function-calling و instruction-following هم نشون میده که هدف، کاربردهای عملی و agentic بوده. این مدلها برای cosplay کردن SOTA ساخته نشدن، برای کار واقعی طراحی شدن.
برای اجرا و تست، مدلها روی Hugging Face، Ollama و LM Studio در دسترس هستن. پشتیبانی کامل از vLLM و Transformers هم وجود داره. نسخههای بهینهشده برای استدلال (Thinking) هم اواخر ۲۰۲۵ منتشر میشن.
📃 بیانیهی رسمی IBM
📃 کالکشن مدلها در Hugging Face
🛠 Join @LLMEngineers Community
یه مدل جدید از Zhipu AI به اسم GLM-4.6 منتشر شده که تمرکز اصلیش روی ایجنتها و کدنویسیه. این مدل یه سری آپدیتهای کلیدی نسبت به نسخهی قبلیش داره.
کاربرد اصلیش برای تسکهاییه که به context طولانی و قابلیتهای ایجنتیک نیاز دارن. مثلاً تحلیل کل یک codebase، انجام RAG روی چندین داکیومنت حجیم، یا ساخت ایجنتهایی که از ابزارهای مختلف استفاده میکنن.
مهمترین تغییراتش ایناست:
پنجرهی زمینهش یا همون context window به ۲۰۰ هزار توکن افزایش پیدا کرده و میتونه تا ۱۲۸ هزار توکن خروجی تولید کنه. این برای تسکهای برنامهریزی پیچیده و کار با دادههای طولانی خیلی به درد میخوره.
تواناییش توی استفاده از ابزارها (tool use) و ساخت ایجنت بهتر شده و با فریمورکهای ایجنتیک رایج راحتتر ادغام میشه.
توی کدنویسی هم روی بنچمارکها و هم ابزارهای واقعی مثل Cline و Roo Code پیشرفت داشته.
از نظر بهینگی هم گفته شده که به طور متوسط بین ۱۵ تا ۳۰ درصد توکن کمتری نسبت به نسخهی ۴.۵ مصرف میکنه.
از نظر فنی، این مدل یه معماری Mixture of Experts یا MoE با حدود ۳۵۷ میلیارد پارامتر داره. نکتهی مهم اینه که برای پردازش هر توکن، فقط حدود ۳۲ میلیارد پارامتر فعال میشه. این یعنی با وجود سایز بزرگ، برای inference گرفتن بهینهتر عمل میکنه. وزنهای مدل هم به صورت open-weights با لایسنس MIT روی Hugging Face منتشر شده.
در مورد عملکرد، طبق بنچمارکهای خود Z.ai، این مدل تقریباً با Claude Sonnet 4 برابری میکنه. البته خودشون هم اشاره کردن که توی کدنویسی هنوز از Sonnet 4.5 عقبتره. این شفافیت خوبیه و نشون میده که هنوز جای پیشرفت وجود داره.
برای استفاده ازش چندتا راه هست:
از طریق API خود Z.ai یا OpenRouter با اسم مدل glm-4.6 در دسترسه. قیمتگذاری روی OpenRouter برای هر میلیون توکن، ۰.۵ دلار ورودی و ۱.۷۵ دلار خروجی هست.
یه قابلیت جالب به اسم thinking mode داره که برای تسکهای پیچیده و استدلالهای چند مرحلهای ایجنتها فعال میشه.
برای اجرای لوکال هم میشه از فریمورکهایی مثل vLLM یا SGLang استفاده کرد.
📃 بلاگپست معرفی GLM-4.6
📃 صفحهی مدل در Hugging Face
📃 مستندات فنی و راهنمای API
📃 قیمتگذاری در OpenRouter
🛠 Join @LLMEngineers Community
کاربرد اصلیش برای تسکهاییه که به context طولانی و قابلیتهای ایجنتیک نیاز دارن. مثلاً تحلیل کل یک codebase، انجام RAG روی چندین داکیومنت حجیم، یا ساخت ایجنتهایی که از ابزارهای مختلف استفاده میکنن.
مهمترین تغییراتش ایناست:
پنجرهی زمینهش یا همون context window به ۲۰۰ هزار توکن افزایش پیدا کرده و میتونه تا ۱۲۸ هزار توکن خروجی تولید کنه. این برای تسکهای برنامهریزی پیچیده و کار با دادههای طولانی خیلی به درد میخوره.
تواناییش توی استفاده از ابزارها (tool use) و ساخت ایجنت بهتر شده و با فریمورکهای ایجنتیک رایج راحتتر ادغام میشه.
توی کدنویسی هم روی بنچمارکها و هم ابزارهای واقعی مثل Cline و Roo Code پیشرفت داشته.
از نظر بهینگی هم گفته شده که به طور متوسط بین ۱۵ تا ۳۰ درصد توکن کمتری نسبت به نسخهی ۴.۵ مصرف میکنه.
از نظر فنی، این مدل یه معماری Mixture of Experts یا MoE با حدود ۳۵۷ میلیارد پارامتر داره. نکتهی مهم اینه که برای پردازش هر توکن، فقط حدود ۳۲ میلیارد پارامتر فعال میشه. این یعنی با وجود سایز بزرگ، برای inference گرفتن بهینهتر عمل میکنه. وزنهای مدل هم به صورت open-weights با لایسنس MIT روی Hugging Face منتشر شده.
در مورد عملکرد، طبق بنچمارکهای خود Z.ai، این مدل تقریباً با Claude Sonnet 4 برابری میکنه. البته خودشون هم اشاره کردن که توی کدنویسی هنوز از Sonnet 4.5 عقبتره. این شفافیت خوبیه و نشون میده که هنوز جای پیشرفت وجود داره.
برای استفاده ازش چندتا راه هست:
از طریق API خود Z.ai یا OpenRouter با اسم مدل glm-4.6 در دسترسه. قیمتگذاری روی OpenRouter برای هر میلیون توکن، ۰.۵ دلار ورودی و ۱.۷۵ دلار خروجی هست.
یه قابلیت جالب به اسم thinking mode داره که برای تسکهای پیچیده و استدلالهای چند مرحلهای ایجنتها فعال میشه.
برای اجرای لوکال هم میشه از فریمورکهایی مثل vLLM یا SGLang استفاده کرد.
📃 بلاگپست معرفی GLM-4.6
📃 صفحهی مدل در Hugging Face
📃 مستندات فنی و راهنمای API
📃 قیمتگذاری در OpenRouter
🛠 Join @LLMEngineers Community
LLM Engineers
مجموعه AgentKit از OpenAI معرفی شد. یه ابزار کامل برای ساخت، دیپلوی و بهینهسازی Agentic Workflows. هدف اینه که کل چرخه ساخت یه Agent رو از صفر تا صد پوشش بده و دولوپر رو توی اکوسیستم خودش نگه داره. این کیت از چند بخش اصلی تشکیل شده: Agent Builder: یه محیط…
خیلی موافقم
خیلی جاها دیدم اشتباها به یه workflow میگن agent
ولی متفاوتن، تفاوتشون اینه که یه Workflow فقط یه سری مراحل از پیش تعیینشده رو اجرا میکنه؛ مثل یه فلوچارت ثابت. اما یه Agent واقعی، یه سیستم خودگردان (autonomous) هست که خودش برای رسیدن به هدف برنامهریزی، استدلال و مسیرش رو اصلاح میکنه.
🛠 Join @LLMEngineers Community
خیلی جاها دیدم اشتباها به یه workflow میگن agent
ولی متفاوتن، تفاوتشون اینه که یه Workflow فقط یه سری مراحل از پیش تعیینشده رو اجرا میکنه؛ مثل یه فلوچارت ثابت. اما یه Agent واقعی، یه سیستم خودگردان (autonomous) هست که خودش برای رسیدن به هدف برنامهریزی، استدلال و مسیرش رو اصلاح میکنه.
🛠 Join @LLMEngineers Community
یه تکنیک جدید و خیلی کاربردی معرفی شده به اسم Prompt Baking که فاصلهی بین prompt engineering و fine-tuning رو پر میکنه.
کاربرد اصلی اینه که به جای اینکه هر بار یه پرامپت سیستمی یا چندتا مثال few-shot رو به مدل بدیم، میایم و اثر اون پرامپت رو مستقیماً توی وزنهای مدل "bake" میکنیم یا "میپزیم". نتیجهش یه مدل جدیده که ذاتاً اون رفتار یا دانش رو داره، بدون اینکه نیازی به خود پرامپت باشه. این کار هم context window رو آزاد میکنه و هم مشکل "prompt decay" یا فراموشی پرامپت در طول مکالمات طولانی رو حل میکنه.
روش کار بر اساس به حداقل رسوندن KL divergence بین توزیع خروجی مدل اصلیِ پرامپتشده و مدل جدیدِ بدون پرامپت بنا شده. در واقع، مدل جدید طوری آموزش داده میشه که logitهای خروجیش رو با logitهای مدل پرامپتشده تطبیق بده. این پروسه یه جور self-distillation به حساب میاد و معمولاً با استفاده از LoRA انجام میشه تا هم سریع باشه (گاهی در حد ۵ دقیقه) و هم بهینه.
نتایج عملی این تکنیک خیلی قابل توجهه:
- بهبود استدلال: با bake کردن پرامپتهای Chain-of-Thought، عملکرد zero-shot مدل روی بنچمارکهای استدلال ریاضی و کدنویسی مثل GSM8K، ASDiv و MBPP به سطح عملکرد few-shot نزدیک شده.
- تزریق دانش: میشه دانش جدید، مثلاً اخبار روز، رو به صورت دائمی به مدل اضافه کرد. مدل بعد از bake شدن، میتونه به سوالات مستقیم و حتی غیرمستقیم در مورد اون اطلاعات جدید جواب بده.
- پایداری شخصیت: مشکل persona drift که در اون مدل در مکالمات طولانی، شخصیت یا دستورالعمل اولیهاش رو فراموش میکنه، با این روش به طور کامل برطرف میشه.
- کنترل پیوسته: میشه فرآیند bake رو زودتر متوقف کرد ("half-baking") تا میزان تأثیر پرامپت روی رفتار نهایی مدل رو به صورت پیوسته کنترل کرد.
یه یافتهی جالب و غیرمنتظره اینه که اگه مدلی که یه پرامپت توش bake شده رو دوباره با همون پرامپت اجرا کنیم، عملکردش حتی از مدل اصلی که فقط پرامپت گرفته بهتر میشه. با همین تکنیک، روی بنچمارک GSM8K تونستن رکوردی که متا برای Llama 3 منتشر کرده بود رو هم رد کنن. این ایده به یه روش تکرارشونده به اسم Prompt Pursuit هم توسعه داده شده که مدل به صورت مداوم خودش رو در جهت پرامپت بهبود میده.
به نظر من، Prompt Baking یه ابزار خیلی قدرتمند برای کنترل مدلهاست. به جای جمعآوری دیتاست و fine-tuningهای سنگین برای یه رفتار خاص، میشه با یه پرامپت خوشساخت، اون رفتار رو به صورت دائمی و پایدار در مدل نهادینه کرد. این روش همچنین مقاومت خوبی در برابر catastrophic forgetting نشون داده، یعنی bake کردن یک مهارت، باعث تخریب بقیه تواناییهای مدل نمیشه.
📃 عنوان مقاله: Prompt Baking
https://arxiv.org/abs/2408.14332
🛠 Join @LLMEngineers Community
کاربرد اصلی اینه که به جای اینکه هر بار یه پرامپت سیستمی یا چندتا مثال few-shot رو به مدل بدیم، میایم و اثر اون پرامپت رو مستقیماً توی وزنهای مدل "bake" میکنیم یا "میپزیم". نتیجهش یه مدل جدیده که ذاتاً اون رفتار یا دانش رو داره، بدون اینکه نیازی به خود پرامپت باشه. این کار هم context window رو آزاد میکنه و هم مشکل "prompt decay" یا فراموشی پرامپت در طول مکالمات طولانی رو حل میکنه.
روش کار بر اساس به حداقل رسوندن KL divergence بین توزیع خروجی مدل اصلیِ پرامپتشده و مدل جدیدِ بدون پرامپت بنا شده. در واقع، مدل جدید طوری آموزش داده میشه که logitهای خروجیش رو با logitهای مدل پرامپتشده تطبیق بده. این پروسه یه جور self-distillation به حساب میاد و معمولاً با استفاده از LoRA انجام میشه تا هم سریع باشه (گاهی در حد ۵ دقیقه) و هم بهینه.
نتایج عملی این تکنیک خیلی قابل توجهه:
- بهبود استدلال: با bake کردن پرامپتهای Chain-of-Thought، عملکرد zero-shot مدل روی بنچمارکهای استدلال ریاضی و کدنویسی مثل GSM8K، ASDiv و MBPP به سطح عملکرد few-shot نزدیک شده.
- تزریق دانش: میشه دانش جدید، مثلاً اخبار روز، رو به صورت دائمی به مدل اضافه کرد. مدل بعد از bake شدن، میتونه به سوالات مستقیم و حتی غیرمستقیم در مورد اون اطلاعات جدید جواب بده.
- پایداری شخصیت: مشکل persona drift که در اون مدل در مکالمات طولانی، شخصیت یا دستورالعمل اولیهاش رو فراموش میکنه، با این روش به طور کامل برطرف میشه.
- کنترل پیوسته: میشه فرآیند bake رو زودتر متوقف کرد ("half-baking") تا میزان تأثیر پرامپت روی رفتار نهایی مدل رو به صورت پیوسته کنترل کرد.
یه یافتهی جالب و غیرمنتظره اینه که اگه مدلی که یه پرامپت توش bake شده رو دوباره با همون پرامپت اجرا کنیم، عملکردش حتی از مدل اصلی که فقط پرامپت گرفته بهتر میشه. با همین تکنیک، روی بنچمارک GSM8K تونستن رکوردی که متا برای Llama 3 منتشر کرده بود رو هم رد کنن. این ایده به یه روش تکرارشونده به اسم Prompt Pursuit هم توسعه داده شده که مدل به صورت مداوم خودش رو در جهت پرامپت بهبود میده.
به نظر من، Prompt Baking یه ابزار خیلی قدرتمند برای کنترل مدلهاست. به جای جمعآوری دیتاست و fine-tuningهای سنگین برای یه رفتار خاص، میشه با یه پرامپت خوشساخت، اون رفتار رو به صورت دائمی و پایدار در مدل نهادینه کرد. این روش همچنین مقاومت خوبی در برابر catastrophic forgetting نشون داده، یعنی bake کردن یک مهارت، باعث تخریب بقیه تواناییهای مدل نمیشه.
📃 عنوان مقاله: Prompt Baking
https://arxiv.org/abs/2408.14332
🛠 Join @LLMEngineers Community
arXiv.org
One-layer transformers fail to solve the induction heads task
A simple communication complexity argument proves that no one-layer transformer can solve the induction heads task unless its size is exponentially larger than the size sufficient for a two-layer...
LLM Engineers
the_smol_training_playbook_the_secrets_to_building_world_class_llms.pdf
دنبال یه راهنمای عملی برای ترین کردن مدلهای زبانی (LLMs) هستین؟ چیزی که از صفر تا صد، تمام چالشهای واقعی رو پوشش بده، نه فقط تئوریهای دانشگاهی. Hugging Face یه playbook منتشر کرده به اسم Smol Training Playbook که دقیقاً همینه. این راهنما بر اساس تجربیات تیمشون در ساخت مدل SmolLM-3B (یک مدل ۳ میلیارد پارامتری که روی ۱۱ تریلیون توکن ترین شده) نوشته شده.
اگه توی تیم کوچیکی کار میکنید یا منابع محدودی دارید و میخواید یه مدل زبانی سفارشی بسازید، این playbook به دردتون میخوره. هدفش اینه که جلوی اشتباهات پرهزینه رو بگیره و یه مسیر مستقیم از ایده تا محصول نهایی (from-zero-to-ship) ارائه بده.
محتوای اصلی playbook به چند بخش کلیدی تقسیم میشه:
* قبل از شروع: قطبنمای ترینینگ
اول از همه به این سوال جواب میده که آیا اصلاً به ترین کردن یه مدل جدید نیاز دارید یا نه. خیلی وقتها fine-tuning مدلهای اپنسورس موجود کافیه. این بخش کمک میکنه اهداف رو مشخص کنید و ببینید ترین کردن از پایه توجیه استراتژیک داره یا نه.
* فاز Pretraining: کارهای سنگین
اینجا وارد جزئیات فنی میشه. مباحثی مثل انتخاب معماری و سایز مدل، ترکیب داده (data mixture) برای کد، ریاضیات و چندزبانگی، طراحی Tokenizer و استفاده از Scaling Laws برای تخمین Performance مدل نهایی پوشش داده میشه. همینطور به زیرساختهای لازم مثل DeepSpeed و Megatron و بهینهسازی Throughput هم پرداخته شده.
* داستانهای جنگی: تجربههای واقعی
به نظر من، این بخش ارزشمندترین قسمت راهنماست. اینجا از مشکلات واقعی که تیم Hugging Face باهاش روبرو شده صحبت میشه. افت ناگهانی throughput، کرش کردنهای بیدلیل، باگهای مربوط به parallelism و روشهای دیباگ کردن و ریکاوری از این فاجعهها. اینا تجربیاتیه که معمولاً با کلی هزینه و زمان به دست میاد.
* بعد از ترینینگ: Alignment و استقرار
کار با pretraining تموم نمیشه. این بخش روی مراحل بعد از اون تمرکز داره:
* Supervised Fine-Tuning (SFT):
برای یاد دادن تسکهای مشخص به مدل.
* Preference Optimization:
استفاده از تکنیکهایی مثل DPO یا APO برای همسو کردن رفتار مدل با اولویتهای انسانی.
* Evaluation:
ارزیابی مدل و آمادهسازی برای استقرار نهایی.
این playbook یه منبع متمرکز و عملیه که مثل یه چکلیست میتونید ازش استفاده کنید. به جای خوندن دهها مقاله پراکنده، یه نقشه راه مشخص جلوتون میذاره.
🛠 Join @LLMEngineers Community
اگه توی تیم کوچیکی کار میکنید یا منابع محدودی دارید و میخواید یه مدل زبانی سفارشی بسازید، این playbook به دردتون میخوره. هدفش اینه که جلوی اشتباهات پرهزینه رو بگیره و یه مسیر مستقیم از ایده تا محصول نهایی (from-zero-to-ship) ارائه بده.
محتوای اصلی playbook به چند بخش کلیدی تقسیم میشه:
* قبل از شروع: قطبنمای ترینینگ
اول از همه به این سوال جواب میده که آیا اصلاً به ترین کردن یه مدل جدید نیاز دارید یا نه. خیلی وقتها fine-tuning مدلهای اپنسورس موجود کافیه. این بخش کمک میکنه اهداف رو مشخص کنید و ببینید ترین کردن از پایه توجیه استراتژیک داره یا نه.
* فاز Pretraining: کارهای سنگین
اینجا وارد جزئیات فنی میشه. مباحثی مثل انتخاب معماری و سایز مدل، ترکیب داده (data mixture) برای کد، ریاضیات و چندزبانگی، طراحی Tokenizer و استفاده از Scaling Laws برای تخمین Performance مدل نهایی پوشش داده میشه. همینطور به زیرساختهای لازم مثل DeepSpeed و Megatron و بهینهسازی Throughput هم پرداخته شده.
* داستانهای جنگی: تجربههای واقعی
به نظر من، این بخش ارزشمندترین قسمت راهنماست. اینجا از مشکلات واقعی که تیم Hugging Face باهاش روبرو شده صحبت میشه. افت ناگهانی throughput، کرش کردنهای بیدلیل، باگهای مربوط به parallelism و روشهای دیباگ کردن و ریکاوری از این فاجعهها. اینا تجربیاتیه که معمولاً با کلی هزینه و زمان به دست میاد.
* بعد از ترینینگ: Alignment و استقرار
کار با pretraining تموم نمیشه. این بخش روی مراحل بعد از اون تمرکز داره:
* Supervised Fine-Tuning (SFT):
برای یاد دادن تسکهای مشخص به مدل.
* Preference Optimization:
استفاده از تکنیکهایی مثل DPO یا APO برای همسو کردن رفتار مدل با اولویتهای انسانی.
* Evaluation:
ارزیابی مدل و آمادهسازی برای استقرار نهایی.
این playbook یه منبع متمرکز و عملیه که مثل یه چکلیست میتونید ازش استفاده کنید. به جای خوندن دهها مقاله پراکنده، یه نقشه راه مشخص جلوتون میذاره.
🛠 Join @LLMEngineers Community
مدل جدید Kimi K2 Thinking از شرکت چینی Moonshot AI منتشر شده که تمرکزش روی کارهای Agentic و استفاده عمیق از ابزاره. کاربرد اصلیش برای ساختن Agent-هاییه که باید تسکهای پیچیده و چند مرحلهای رو انجام بدن، مثل تحقیق خودکار یا کدنویسیهای طولانی.
این مدل صرفاً یه LLM معمولی نیست؛ به عنوان یه "thinking agent" طراحی شده. یعنی زنجیرهای از استدلال (Chain-of-Thought) و فراخوانی ابزار (Function Calling) رو به صورت End-to-End با هم یاد گرفته. نکته کلیدیش اینه که میتونه پایداری خودش رو توی صدها مرحله فراخوانی ابزار حفظ کنه، در حالی که مدلهای دیگه معمولاً بعد از ۳۰-۵۰ مرحله دچار افت عملکرد یا انحراف از هدف میشن.
معماریش Mixture-of-Experts یا MoE هست با ۱ تریلیون پارامتر که موقع inference فقط ۳۲ میلیاردش فعاله. این ساختار باعث بهینگی در اجرا میشه. از یه context window به طول 256K هم پشتیبانی میکنه و به صورت نیتیو از کوانتیزیشن INT4 استفاده میکنه که سرعت inference رو حدوداً ۲ برابر میکنه بدون اینکه عملکرد مدل افت کنه. این یعنی برای دیپلوی کردن روی موتورهایی مثل vLLM یا SGLang بهینهست.
عملکردش توی بنچمارکهای Agentic مثل HLE (با ابزار) و BrowseComp در حد SOTA ـه و گاهی از GPT-5 و Grok-4 هم بهتره. مخصوصاً در حالت "heavy mode" که چندین trajectory رو به صورت موازی بررسی میکنه، نتایجش خیلی قویه. البته توی بنچمارکهای Reasoning بدون ابزار، هنوز کمی از بهترینها مثل GPT-5 عقبتره، که نشون میده قدرت اصلیش در ترکیب استدلال و ابزاره.
به نظر من، تمرکز روی پایداری توی فراخوانیهای طولانی ابزار (200-300 step) مهمترین ویژگی این مدله. خیلی از Agent-های الان بعد از چند ده مرحله، هدف رو گم میکنن و این مدل ظاهراً این مشکل رو تا حد زیادی حل کرده. عرضه شدن یه مدل open-source با این قابلیتها که میتونه با مدلهای بسته مثل GPT-5 و Claude 4.5 Sonnet توی تسکهای پیچیده رقابت کنه، اونم با هزینه کمتر، یه اتفاق مهمه.
مدل روی Hugging Face در دسترسه و میشه ازش استفاده کرد.
📃 مدل در Hugging Face:
https://huggingface.co/moonshot-ai/kimi-k2-thinking
🛠 Join @LLMEngineers Community
این مدل صرفاً یه LLM معمولی نیست؛ به عنوان یه "thinking agent" طراحی شده. یعنی زنجیرهای از استدلال (Chain-of-Thought) و فراخوانی ابزار (Function Calling) رو به صورت End-to-End با هم یاد گرفته. نکته کلیدیش اینه که میتونه پایداری خودش رو توی صدها مرحله فراخوانی ابزار حفظ کنه، در حالی که مدلهای دیگه معمولاً بعد از ۳۰-۵۰ مرحله دچار افت عملکرد یا انحراف از هدف میشن.
معماریش Mixture-of-Experts یا MoE هست با ۱ تریلیون پارامتر که موقع inference فقط ۳۲ میلیاردش فعاله. این ساختار باعث بهینگی در اجرا میشه. از یه context window به طول 256K هم پشتیبانی میکنه و به صورت نیتیو از کوانتیزیشن INT4 استفاده میکنه که سرعت inference رو حدوداً ۲ برابر میکنه بدون اینکه عملکرد مدل افت کنه. این یعنی برای دیپلوی کردن روی موتورهایی مثل vLLM یا SGLang بهینهست.
عملکردش توی بنچمارکهای Agentic مثل HLE (با ابزار) و BrowseComp در حد SOTA ـه و گاهی از GPT-5 و Grok-4 هم بهتره. مخصوصاً در حالت "heavy mode" که چندین trajectory رو به صورت موازی بررسی میکنه، نتایجش خیلی قویه. البته توی بنچمارکهای Reasoning بدون ابزار، هنوز کمی از بهترینها مثل GPT-5 عقبتره، که نشون میده قدرت اصلیش در ترکیب استدلال و ابزاره.
به نظر من، تمرکز روی پایداری توی فراخوانیهای طولانی ابزار (200-300 step) مهمترین ویژگی این مدله. خیلی از Agent-های الان بعد از چند ده مرحله، هدف رو گم میکنن و این مدل ظاهراً این مشکل رو تا حد زیادی حل کرده. عرضه شدن یه مدل open-source با این قابلیتها که میتونه با مدلهای بسته مثل GPT-5 و Claude 4.5 Sonnet توی تسکهای پیچیده رقابت کنه، اونم با هزینه کمتر، یه اتفاق مهمه.
مدل روی Hugging Face در دسترسه و میشه ازش استفاده کرد.
📃 مدل در Hugging Face:
https://huggingface.co/moonshot-ai/kimi-k2-thinking
🛠 Join @LLMEngineers Community
بحث
ایدهی اصلی اینه که به جای آپدیت همهی پارامترها، فقط اون بخش از شبکه که اطلاعات غلط رو ذخیره کرده پیدا و اصلاح بشه. دو تا از معروفترین الگوریتمها توی این حوزه
متد
روند کارش اینطوریه:
۱. پیدا کردن محل دانش: با تکنیکی به اسم
۲. اصلاح دانش: بعد از پیدا کردن اون لایه، یک آپدیت ماتریسی از نوع
مشکل اصلی
متد
روند کارش به این شکله:
۱. آپدیت چندلایهای: به جای اینکه فقط یک لایه رو ادیت کنه، آپدیتها رو بین چندین لایه پخش میکنه تا فشار روی یک بخش از مدل نباشه.
۲. پردازش دستهای: برای یک بچ از ادیتها، یک معادله رو حل میکنه تا آپدیتهای بهینه برای وزنها پیدا بشه. اینطوری تداخل بین ادیتها کمتر میشه.
به طور خلاصه:
- از
- از
به نظر من،
برای پیادهسازی عملی، فریمورک
📃 مقاله ROME: Locating and Editing Factual Associations in GPT
https://arxiv.org/abs/2202.05262
📃 مقاله MEMIT: Mass-Editing Memory in a Transformer
https://arxiv.org/abs/2210.07229
💻 فریمورک EasyEdit برای پیادهسازی
https://github.com/zjunlp/EasyEdit
🛠 Join @LLMEngineers Community
Model Editing یعنی اینکه بتونیم دانش یک LLM رو به صورت جراحی و مستقیم توی وزنهاش آپدیت کنیم، بدون اینکه نیاز به fine-tuning کامل داشته باشیم. کاربرد اصلیش وقتیه که مدل یه فکت رو اشتباه میگه (hallucination) یا اطلاعاتش قدیمی شده و میخوایم فقط همون یک تیکه دانش رو اصلاح کنیم. این کار خیلی بهینهتر از retraining هست که هم هزینهبره و هم ریسک catastrophic forgetting داره (یعنی مدل چیزای دیگهای که بلد بوده رو یادش بره).ایدهی اصلی اینه که به جای آپدیت همهی پارامترها، فقط اون بخش از شبکه که اطلاعات غلط رو ذخیره کرده پیدا و اصلاح بشه. دو تا از معروفترین الگوریتمها توی این حوزه
ROME و MEMIT هستن.متد
ROME برای ادیت کردن یک فکت تنها طراحی شده. فرضش اینه که دانش در لایههای MLP مدل Transformer ذخیره شده.روند کارش اینطوریه:
۱. پیدا کردن محل دانش: با تکنیکی به اسم
causal tracing میاد لایهای که بیشترین تاثیر رو روی تولید اون فکت خاص داره پیدا میکنه.۲. اصلاح دانش: بعد از پیدا کردن اون لایه، یک آپدیت ماتریسی از نوع
rank-one روی وزنهای MLP اون لایه اعمال میکنه تا فکت جدید جایگزین قبلی بشه. این آپدیت خیلی کوچیک و دقیقه.مشکل اصلی
ROME اینه که برای ادیتهای پشت سر هم ضعیفه. معمولاً بعد از ۱۰-۲۰ تا ادیت، مدل دچار model collapse میشه و کاراییش رو از دست میده، چون آپدیتها روی هم جمع میشن و ساختار وزنها رو خراب میکنن.متد
MEMIT در واقع نسخهی توسعهیافته ROME برای ادیت کردن دستهای و انبوه (mass editing) هست. یعنی میتونه هزاران فکت رو همزمان توی مدل آپدیت کنه.روند کارش به این شکله:
۱. آپدیت چندلایهای: به جای اینکه فقط یک لایه رو ادیت کنه، آپدیتها رو بین چندین لایه پخش میکنه تا فشار روی یک بخش از مدل نباشه.
۲. پردازش دستهای: برای یک بچ از ادیتها، یک معادله رو حل میکنه تا آپدیتهای بهینه برای وزنها پیدا بشه. اینطوری تداخل بین ادیتها کمتر میشه.
MEMIT مقیاسپذیری خیلی بهتری داره و میتونه دانش مدل رو به صورت پیوسته آپدیت کنه، ولی ممکنه با ادیتهای متناقض روی یک موضوع به مشکل بخوره.به طور خلاصه:
- از
ROME برای اصلاح یک فکت خاص و سریع استفاده میشه.- از
MEMIT برای آپدیتهای گسترده و دستهای دانش، مثل اضافه کردن اطلاعات جدید به مدل، استفاده میشه.به نظر من،
Model Editing هنوز جایگزین کاملی برای fine-tuning نیست، مخصوصاً برای تغییر رفتار مدل. این تکنیکها بیشتر برای اصلاح دانش (factual knowledge) کاربرد دارن تا منطق یا تواناییهای استدلالی. بزرگترین ریسکشون هم پتانسیل سوءاستفاده برای تزریق اطلاعات غلط به مدلهای موجوده، مثل پروژهی PoisonGPT که با همین روشها مدل رو مسموم میکرد. ابزار قدرتمندیه ولی باید با احتیاط استفاده بشه.برای پیادهسازی عملی، فریمورک
EasyEdit کار رو خیلی راحت کرده و هر دو الگوریتم رو پشتیبانی میکنه. برای اجرا حداقل به یک GPU با ۱۶ گیگ VRAM نیاز هست و بهتره با مدلهای سایز متوسط مثل 7B یا شروع کنید.📃 مقاله ROME: Locating and Editing Factual Associations in GPT
https://arxiv.org/abs/2202.05262
📃 مقاله MEMIT: Mass-Editing Memory in a Transformer
https://arxiv.org/abs/2210.07229
💻 فریمورک EasyEdit برای پیادهسازی
https://github.com/zjunlp/EasyEdit
🛠 Join @LLMEngineers Community
LLM Engineers
یه تکنیک جدید و خیلی کاربردی معرفی شده به اسم Prompt Baking که فاصلهی بین prompt engineering و fine-tuning رو پر میکنه. کاربرد اصلی اینه که به جای اینکه هر بار یه پرامپت سیستمی یا چندتا مثال few-shot رو به مدل بدیم، میایم و اثر اون پرامپت رو مستقیماً توی…
خب بچهها، امروز میخوایم یه تکنیک خیلی کاربردی رو کالبدشکافی کنیم. فرض کنین یه system prompt خیلی خفن و طولانی دارین که مدل رو وادار به یه رفتار خاص میکنه، مثلاً استدلال قدمبهقدم. مشکل اینجاست که هر بار باید این پرامپت طولانی رو به مدل بدین که هم هزینه توکن داره و هم ممکنه مدل تو متنهای طولانی یادش بره. راه حل، پختن این پرامپت توی وزنهای خود مدله.
ایده اصلی اینه که رفتار یه مدل بزرگ و هوشمند (معلم) که با system prompt بهینه شده رو به یه مدل کوچیکتر و بهینهتر (دانشآموز) منتقل کنیم. این کار ترکیبی از دو تا تکنیک معروفه: Prompt Baking و Knowledge Distillation. نتیجه اینه که مدل کوچیکتر بدون نیاز به اون پرامپت طولانی، همون رفتار رو از خودش نشون میده.
این تکنیک چیز جدیدی نیست، فقط اسمش عوض شده. قبلاً بهش میگفتن Context Distillation و شرکتهایی مثل Anthropic از سال ۲۰۲۱ برای تزریق اصول اخلاقی (HHH) به مدلهاشون ازش استفاده میکردن. پس این یه روش تستشده و قابل اعتماده، نه یه هایپ جدید.
پروسه کار به این شکله:
۱. تولید داده با مدل معلم:
اول یه مدل بزرگ و قوی مثل DeepSeek-V2 رو برمیداریم و system prompt مورد نظرمون رو بهش میدیم. بعد یه مجموعه داده متنوع از سوالات (مثلاً از دیتاست SQuAD) بهش میدیم تا جواب تولید کنه. این جوابها که بهشون trajectories میگن، باید با temperature بالا تولید بشن تا تنوع داشته باشن و مدل دانشآموز overfit نشه. نکته کلیدی اینجاست که برای هر توکنی که مدل معلم تولید میکنه، ما logits (خروجی خام قبل از softmax) رو هم ذخیره میکنیم. این logits در واقع توزیع احتمال کامل روی تمام توکنهای ممکنه و کل دانش مدل معلم توش نهفتهست.
۲. آموزش مدل دانشآموز:
حالا یه مدل کوچیکتر، مثلاً یه مدل ۲۰ میلیاردی، رو انتخاب میکنیم. یه آداپتور LoRA روی لایههای attention این مدل سوار میکنیم تا فقط بخش کوچیکی از وزنها آپدیت بشن و دانش پایهی مدل از بین نره. بعد مدل دانشآموز رو با دادههایی که تولید کردیم آموزش میدیم. مدل دانشآموز اینجا دیگه system prompt رو نمیبینه. وظیفهش اینه که یاد بگیره logits خروجی خودش رو به logits مدل معلم شبیه کنه. تابع زیان یا loss function برای این کار Kullback-Leibler (KL) divergence هست که تفاوت بین دو توزیع احتمال رو اندازه میگیره.
۳. استفاده از مدل پختهشده:
بعد از اینکه آموزش تموم شد، وزنهای LoRA رو با وزنهای اصلی مدل دانشآموز ادغام (merge) میکنیم. حالا ما یه مدل کوچیک داریم که رفتار دیکتهشده توسط اون system prompt پیچیده رو به صورت دائمی در خودش داره، بدون اینکه نیاز به ارسال مجدد پرامپت باشه. این یعنی صرفهجویی در هزینه توکن و پایداری رفتار در مکالمات طولانی.
به نظر من، این روش یه نمونهی عالی از مهندسی هوش مصنوعیه. به جای تئوریپردازی، یه مشکل واقعی یعنی هزینه و ناپایداری پرامپتهای طولانی رو به شکل بهینه حل میکنه. با استفاده از logits به جای متن خالی (hard labels)، دانش خیلی عمیقتری از مدل معلم به دانشآموز منتقل میشه. البته ریسکهایی هم داره؛ اگه پرامپت شما بایاس یا مشکلی داشته باشه، اون بایاس برای همیشه توی مدل جدید پخته میشه.
این روش در عمل توسط تیمهای بزرگی مثل گوگل برای آموزش مدلهای Gemma با استفاده از مدلهای Gemini به عنوان معلم هم استفاده شده و نتایج خوبی روی بنچمارکها گرفته. پس اگه دنبال یه راه بهینه برای سفارشی کردن رفتار مدلهاتون هستین، این مسیر رو حتماً بررسی کنین.
🛠 Join @LLMEngineers Community
ایده اصلی اینه که رفتار یه مدل بزرگ و هوشمند (معلم) که با system prompt بهینه شده رو به یه مدل کوچیکتر و بهینهتر (دانشآموز) منتقل کنیم. این کار ترکیبی از دو تا تکنیک معروفه: Prompt Baking و Knowledge Distillation. نتیجه اینه که مدل کوچیکتر بدون نیاز به اون پرامپت طولانی، همون رفتار رو از خودش نشون میده.
این تکنیک چیز جدیدی نیست، فقط اسمش عوض شده. قبلاً بهش میگفتن Context Distillation و شرکتهایی مثل Anthropic از سال ۲۰۲۱ برای تزریق اصول اخلاقی (HHH) به مدلهاشون ازش استفاده میکردن. پس این یه روش تستشده و قابل اعتماده، نه یه هایپ جدید.
پروسه کار به این شکله:
۱. تولید داده با مدل معلم:
اول یه مدل بزرگ و قوی مثل DeepSeek-V2 رو برمیداریم و system prompt مورد نظرمون رو بهش میدیم. بعد یه مجموعه داده متنوع از سوالات (مثلاً از دیتاست SQuAD) بهش میدیم تا جواب تولید کنه. این جوابها که بهشون trajectories میگن، باید با temperature بالا تولید بشن تا تنوع داشته باشن و مدل دانشآموز overfit نشه. نکته کلیدی اینجاست که برای هر توکنی که مدل معلم تولید میکنه، ما logits (خروجی خام قبل از softmax) رو هم ذخیره میکنیم. این logits در واقع توزیع احتمال کامل روی تمام توکنهای ممکنه و کل دانش مدل معلم توش نهفتهست.
۲. آموزش مدل دانشآموز:
حالا یه مدل کوچیکتر، مثلاً یه مدل ۲۰ میلیاردی، رو انتخاب میکنیم. یه آداپتور LoRA روی لایههای attention این مدل سوار میکنیم تا فقط بخش کوچیکی از وزنها آپدیت بشن و دانش پایهی مدل از بین نره. بعد مدل دانشآموز رو با دادههایی که تولید کردیم آموزش میدیم. مدل دانشآموز اینجا دیگه system prompt رو نمیبینه. وظیفهش اینه که یاد بگیره logits خروجی خودش رو به logits مدل معلم شبیه کنه. تابع زیان یا loss function برای این کار Kullback-Leibler (KL) divergence هست که تفاوت بین دو توزیع احتمال رو اندازه میگیره.
۳. استفاده از مدل پختهشده:
بعد از اینکه آموزش تموم شد، وزنهای LoRA رو با وزنهای اصلی مدل دانشآموز ادغام (merge) میکنیم. حالا ما یه مدل کوچیک داریم که رفتار دیکتهشده توسط اون system prompt پیچیده رو به صورت دائمی در خودش داره، بدون اینکه نیاز به ارسال مجدد پرامپت باشه. این یعنی صرفهجویی در هزینه توکن و پایداری رفتار در مکالمات طولانی.
به نظر من، این روش یه نمونهی عالی از مهندسی هوش مصنوعیه. به جای تئوریپردازی، یه مشکل واقعی یعنی هزینه و ناپایداری پرامپتهای طولانی رو به شکل بهینه حل میکنه. با استفاده از logits به جای متن خالی (hard labels)، دانش خیلی عمیقتری از مدل معلم به دانشآموز منتقل میشه. البته ریسکهایی هم داره؛ اگه پرامپت شما بایاس یا مشکلی داشته باشه، اون بایاس برای همیشه توی مدل جدید پخته میشه.
این روش در عمل توسط تیمهای بزرگی مثل گوگل برای آموزش مدلهای Gemma با استفاده از مدلهای Gemini به عنوان معلم هم استفاده شده و نتایج خوبی روی بنچمارکها گرفته. پس اگه دنبال یه راه بهینه برای سفارشی کردن رفتار مدلهاتون هستین، این مسیر رو حتماً بررسی کنین.
🛠 Join @LLMEngineers Community
فاینتیون کردن مدلهای زبانی با LoRA استاندارد صنعتی شده، ولی همیشه یه گپی با Full Fine-tuning وجود داره که پر نمیشه. تکنیک DoRA یا Weight-Decomposed Low-Rank Adaptation دقیقاً برای پر کردن همین فاصله طراحی شده؛ یه متد PEFT که یادگیری Magnitude و Direction وزنها رو از هم جدا میکنه تا رفتار Full FT رو دقیقتر شبیهسازی کنه.
تحلیلهای ریاضی روی پروسه Full Fine-tuning نشون میده که مدلها بیشتر تمایل دارن "جهت" (Direction) بردار وزنها رو تغییر بدن و "اندازه" (Magnitude) رو نسبتا ثابت نگه میدارن. مشکل LoRA اینه که با تزریق ماتریسهای Low-Rank، تغییرات مگنیتود و دایرکشن رو با هم کوپل میکنه و دست مدل رو برای تنظیم دقیق جهتها میبنده.
راهکار DoRA اینه که ماتریس وزن Pretrained رو اول تجزیه میکنه:
۱. یک بردار Magnitude قابل آموزش (𝑚).
۲. یک ماتریس Direction نرمالایز شده (𝑉).
بعدش پروسه استاندارد LoRA رو فقط روی بخش Direction اعمال میکنه و بردار 𝑚 رو جداگانه آموزش میده. نتیجه اینه که همگرایی مدل سریعتر و پایدارتر میشه و بدون اضافه کردن سربار محاسباتی خاصی (حدود ۰.۰۱ درصد پارامتر بیشتر نسبت به LoRA)، ظرفیت یادگیری مدل رو بالا میبره.
پیادهسازی این متد الان توی اکوسیستم Hugging Face کاملاً ساده شده. اگر از کتابخونه peft استفاده میکنید، کافیه توی LoraConfig پارامتر use_dora=True رو ست کنید. نکته حیاتی برای پروداکشن اینه که مثل LoRA، وزنهای DoRA هم کاملاً قابلیت Merge شدن دارن و موقع Inference هیچ Latency اضافهای تحمیل نمیکنن.
به نظر من اگر روی تسکهای پیچیده مثل Reasoning یا Vision-Language کار میکنید، سوییچ کردن به DoRA منطقیه. بنچمارکها نشون میدن DoRA حتی با Rank نصف نسبت به LoRA، خروجی بهتری میده. این یعنی میتونید پارامترهای کمتری آموزش بدید ولی کیفیت نزدیک به Full Fine-tuning بگیرید. تنها نکته منفی شاید مصرف جزئی حافظه بیشتر موقع Training باشه که ناشی از عملیات Decomposition هست، ولی ارزش پرفورمنس نهایی رو داره.
📃 پیپر اصلی DoRA:
https://arxiv.org/abs/2402.09353
🛠 Join @LLMEngineers Community
تحلیلهای ریاضی روی پروسه Full Fine-tuning نشون میده که مدلها بیشتر تمایل دارن "جهت" (Direction) بردار وزنها رو تغییر بدن و "اندازه" (Magnitude) رو نسبتا ثابت نگه میدارن. مشکل LoRA اینه که با تزریق ماتریسهای Low-Rank، تغییرات مگنیتود و دایرکشن رو با هم کوپل میکنه و دست مدل رو برای تنظیم دقیق جهتها میبنده.
راهکار DoRA اینه که ماتریس وزن Pretrained رو اول تجزیه میکنه:
۱. یک بردار Magnitude قابل آموزش (𝑚).
۲. یک ماتریس Direction نرمالایز شده (𝑉).
بعدش پروسه استاندارد LoRA رو فقط روی بخش Direction اعمال میکنه و بردار 𝑚 رو جداگانه آموزش میده. نتیجه اینه که همگرایی مدل سریعتر و پایدارتر میشه و بدون اضافه کردن سربار محاسباتی خاصی (حدود ۰.۰۱ درصد پارامتر بیشتر نسبت به LoRA)، ظرفیت یادگیری مدل رو بالا میبره.
پیادهسازی این متد الان توی اکوسیستم Hugging Face کاملاً ساده شده. اگر از کتابخونه peft استفاده میکنید، کافیه توی LoraConfig پارامتر use_dora=True رو ست کنید. نکته حیاتی برای پروداکشن اینه که مثل LoRA، وزنهای DoRA هم کاملاً قابلیت Merge شدن دارن و موقع Inference هیچ Latency اضافهای تحمیل نمیکنن.
به نظر من اگر روی تسکهای پیچیده مثل Reasoning یا Vision-Language کار میکنید، سوییچ کردن به DoRA منطقیه. بنچمارکها نشون میدن DoRA حتی با Rank نصف نسبت به LoRA، خروجی بهتری میده. این یعنی میتونید پارامترهای کمتری آموزش بدید ولی کیفیت نزدیک به Full Fine-tuning بگیرید. تنها نکته منفی شاید مصرف جزئی حافظه بیشتر موقع Training باشه که ناشی از عملیات Decomposition هست، ولی ارزش پرفورمنس نهایی رو داره.
📃 پیپر اصلی DoRA:
https://arxiv.org/abs/2402.09353
🛠 Join @LLMEngineers Community
این پیپر از اون دست مقالههاییه که با اینکه سال ۲۰۲۰ اومده (دوران اوج RoBERTa)، ولی منطقش دقیقاً همون چیزیه که امروز توی بحث Continued Pretraining برای LLMهای بزرگ مثل Llama 3 یا Mistral هم به درد میخوره. تیم AllenAI اینجا یه سوال اساسی رو حل کرده: وقتی یه مدل زبانی روی دیتای عمومی (Common Crawl و غیره) آموزش دیده، چقدر میتونه توی دامینهای تخصصی مثل پزشکی، حقوقی یا حتی نقدهای آمازون خوب عمل کنه؟
جواب کوتاهش اینه: مدلهای جنرال اونقدر که فکر میکنید «همه فن حریف» نیستن و Fine-tuning خالی اغلب راهحل بهینهای نیست.
📃 Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks
https://arxiv.org/abs/2004.10964
نکات کلیدی و فنی که باید بدونید:
۱. استراتژی DAPT (Domain-Adaptive Pretraining)
بیشتر ما عادت داریم مدل Pretrained رو برداریم و مستقیم روی دیتای لیبلدار Fine-tune کنیم. این پیپر نشون میده اگر قبل از Fine-tuning، مدل رو روی دیتای بدون لیبل (Unlabeled) همون "دامین" ادامه آموزش بدید (Continued Pretraining)، پرفورمنس به شدت میره بالا.
نکته مهم اینجاست که هرچقدر دامین شما از دیتای اصلی مدل دورتر باشه (مثلاً BioMed نسبت به News)، تاثیر DAPT بیشتره.
۲. استراتژی TAPT (Task-Adaptive Pretraining) - این بخش طلاست
شاید فکر کنید برای ادامه Pretraining نیاز به ترابایتها دیتا دارید. این تحقیق نشون میده که انجام Pretraining روی همون دیتای ترینینگ تسک (بدون استفاده از لیبلها) تاثیر عجیب و غریبی داره.
حتی اگر دیتای شما کمه، TAPT باعث میشه مدل با توزیع آماری خاص اون دیتاست (Task Distribution) آداپته بشه. هزینه محاسباتی TAPT خیلی پایینه ولی تاثیرش بعضاً با DAPT رقابت میکنه.
۳. ترکیب برنده: DAPT + TAPT
بهترین خروجی زمانی به دست میاد که اول مدل رو روی دامین کلی (مثلاً کل مقالات CS) آموزش بدید و بعد روی دیتای خاص تسک (مثلاً فقط چکیدههای مربوط به AI). این "Curriculum Learning" ساده، SOTA رو جابجا میکنه.
۴. انتقال دانش (Cross-Task Transfer) همیشه مثبت نیست
یه نکتهی جالب و غیرشهودی توی پیپر اینه: اگر مدل رو روی تسک A آداپته کنید (TAPT)، ممکنه روی تسک B توی همون دامین پرفورمنسش افت کنه. این یعنی TAPT مدل رو به شدت روی توزیع خاص اون دیتاست Overfit میکنه (به معنای مثبتش برای همون تسک، و منفی برای جنرالیزیشن).
۵. انتخاب هوشمند دیتا (Augmented TAPT)
اگر دیتای ترینینگ شما کمه، میتونید از روشهای ساده مثل kNN یا VAMPIRE استفاده کنید تا از دیتای بزرگ دامین، نمونههای شبیه به دیتای تسک رو پیدا کنید و با اونها TAPT رو انجام بدید. این کار تقریباً جای خالی دیتای زیاد رو پر میکنه.
به نظر من:
امروز خیلیها درگیر RAG یا Prompt Engineering هستن، ولی اگر دارید روی یه محصول جدی توی یه دامین خاص (مثل حقوقی فارسی یا نسخه پیچی پزشکی) کار میکنید، Continued Pretraining روی متون تخصصی اون حوزه (DAPT) و بعدش روی دیتای خودتون (TAPT) یه الزام مهندسیه، نه یه فیچر لوکس.
خیلی وقتا مدلهای کوچیکتر که درست روی دامین آداپته شدن، مدلهای غولپیکر جنرال رو توی تسکهای تخصصی شکست میدن. فقط به بنچمارکهای عمومی GLUE و غیره اعتماد نکنید؛ توزیع دیتای واقعی شما با اونها فرق داره.
خلاصه دستورالعمل اجرایی:
۱- دیتای خام دامینتون رو جمع کنید -> DAPT
۲- دیتای خام تسکتون رو جدا کنید -> TAPT
۳- حالا برید سراغ Supervised Fine-tuning.
🛠 Join @LLMEngineers Community
جواب کوتاهش اینه: مدلهای جنرال اونقدر که فکر میکنید «همه فن حریف» نیستن و Fine-tuning خالی اغلب راهحل بهینهای نیست.
📃 Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks
https://arxiv.org/abs/2004.10964
نکات کلیدی و فنی که باید بدونید:
۱. استراتژی DAPT (Domain-Adaptive Pretraining)
بیشتر ما عادت داریم مدل Pretrained رو برداریم و مستقیم روی دیتای لیبلدار Fine-tune کنیم. این پیپر نشون میده اگر قبل از Fine-tuning، مدل رو روی دیتای بدون لیبل (Unlabeled) همون "دامین" ادامه آموزش بدید (Continued Pretraining)، پرفورمنس به شدت میره بالا.
نکته مهم اینجاست که هرچقدر دامین شما از دیتای اصلی مدل دورتر باشه (مثلاً BioMed نسبت به News)، تاثیر DAPT بیشتره.
۲. استراتژی TAPT (Task-Adaptive Pretraining) - این بخش طلاست
شاید فکر کنید برای ادامه Pretraining نیاز به ترابایتها دیتا دارید. این تحقیق نشون میده که انجام Pretraining روی همون دیتای ترینینگ تسک (بدون استفاده از لیبلها) تاثیر عجیب و غریبی داره.
حتی اگر دیتای شما کمه، TAPT باعث میشه مدل با توزیع آماری خاص اون دیتاست (Task Distribution) آداپته بشه. هزینه محاسباتی TAPT خیلی پایینه ولی تاثیرش بعضاً با DAPT رقابت میکنه.
۳. ترکیب برنده: DAPT + TAPT
بهترین خروجی زمانی به دست میاد که اول مدل رو روی دامین کلی (مثلاً کل مقالات CS) آموزش بدید و بعد روی دیتای خاص تسک (مثلاً فقط چکیدههای مربوط به AI). این "Curriculum Learning" ساده، SOTA رو جابجا میکنه.
۴. انتقال دانش (Cross-Task Transfer) همیشه مثبت نیست
یه نکتهی جالب و غیرشهودی توی پیپر اینه: اگر مدل رو روی تسک A آداپته کنید (TAPT)، ممکنه روی تسک B توی همون دامین پرفورمنسش افت کنه. این یعنی TAPT مدل رو به شدت روی توزیع خاص اون دیتاست Overfit میکنه (به معنای مثبتش برای همون تسک، و منفی برای جنرالیزیشن).
۵. انتخاب هوشمند دیتا (Augmented TAPT)
اگر دیتای ترینینگ شما کمه، میتونید از روشهای ساده مثل kNN یا VAMPIRE استفاده کنید تا از دیتای بزرگ دامین، نمونههای شبیه به دیتای تسک رو پیدا کنید و با اونها TAPT رو انجام بدید. این کار تقریباً جای خالی دیتای زیاد رو پر میکنه.
به نظر من:
امروز خیلیها درگیر RAG یا Prompt Engineering هستن، ولی اگر دارید روی یه محصول جدی توی یه دامین خاص (مثل حقوقی فارسی یا نسخه پیچی پزشکی) کار میکنید، Continued Pretraining روی متون تخصصی اون حوزه (DAPT) و بعدش روی دیتای خودتون (TAPT) یه الزام مهندسیه، نه یه فیچر لوکس.
خیلی وقتا مدلهای کوچیکتر که درست روی دامین آداپته شدن، مدلهای غولپیکر جنرال رو توی تسکهای تخصصی شکست میدن. فقط به بنچمارکهای عمومی GLUE و غیره اعتماد نکنید؛ توزیع دیتای واقعی شما با اونها فرق داره.
خلاصه دستورالعمل اجرایی:
۱- دیتای خام دامینتون رو جمع کنید -> DAPT
۲- دیتای خام تسکتون رو جدا کنید -> TAPT
۳- حالا برید سراغ Supervised Fine-tuning.
🛠 Join @LLMEngineers Community
arXiv.org
Don't Stop Pretraining: Adapt Language Models to Domains and Tasks
Language models pretrained on text from a wide variety of sources form the foundation of today's NLP. In light of the success of these broad-coverage models, we investigate whether it is still...
معماری Fine-tuning مدلهای زبانی روی دیتای تخصصی (Domain-Specific) معمولاً با یه چالش بزرگ روبروئه: دیتای باکیفیت کمه و گرون. اکثر ما عادت کردیم دیتاست رو به صورت Random Shuffle بدیم به مدل و امیدوار باشیم Loss بیاد پایین. اما مقاله EDCO نشون میده که ترتیب یادگیری (Curriculum Learning) اگه داینامیک باشه، بازی رو عوض میکنه.
روشهای سنتی Curriculum Learning معمولاً استاتیک هستن و از "آسون به سخت" میرن جلو (مثلاً بر اساس طول متن). اما EDCO میگه برای یک مدل Pre-trained، دادههای آسون عملاً Noise هستن چون مدل قبلاً اون مفاهیم رو بلده.
متد EDCO (Entropy-based Dynamic Curriculum Orchestration) میاد وسط پروسه Training، دائماً چک میکنه که مدل روی کدوم نمونهها "عدم قطعیت" یا همون Inference Entropy بالایی داره.
نکته جالب ماجرا اینجاست که این روش یه جورایی Reverse Curriculum حساب میشه. یعنی به جای اینکه اول آسونها رو یاد بگیره، تمرکز رو میذاره روی نمونههایی که مدل رو به چالش میکشن (High Entropy Samples). این کار باعث میشه مدل دچار "Entropy Collapse" نشه (حالتی که مدل الکی اعتماد به نفسش میره بالا و دیگه یاد نمیگیره).
چالش فنی این ایده اینه که محاسبه Entropy برای کل دیتاست در هر مرحله، هزینه پردازشی وحشتناکی داره. تیم نویسنده برای حل این مشکل دوتا تریک جالب زدن:
۱. استفاده از Quick-Answer Prompting: مدل رو مجبور میکنن جواب کوتاه بده تا سریعتر پردازش بشه.
۲. تکنیک Prefix Entropy Approximation: به جای کل خروجی، فقط ۵۰ تا ۱۲۸ توکن اول رو برای محاسبه آنتروپی چک میکنن که طبق بنچمارکهاشون ۸۳.۵ درصد سریعتره و دقتش هم حفظ میشه.
نتیجه نهایی روی دیتای مخابراتی (که پر از اصطلاحات خاصه) نشون داده که هم در SFT و هم در RLFT، این روش بهتر از Random Sampling و روشهای سنتی عمل کرده.
📃 عنوان مقاله: EDCO: DYNAMIC CURRICULUM ORCHESTRATION FOR DOMAIN-SPECIFIC LARGE LANGUAGE MODEL FINE-TUNING
https://openreview.net/pdf?id=sF0p40wM8X
به نظر من، این مقاله یه حقیقت تلخ رو یادآوری میکنه: اکثر ما در پروسه Fine-tuning تنبلی میکنیم و فقط دنبال جمع کردن دیتای بیشتر هستیم، در حالی که "نحوه ارائه دیتا" به مدل، به اندازه خود دیتا مهمه. برای پروژه بعدیتون اگر دیتای کمی دارید، به جای Data Augmentation الکی، روی مکانیزمهایی مثل Active Learning یا همین Dynamic Curriculum وقت بذارید تا مدل روی نقاط ضعفش تمرکز کنه نه روی چیزایی که از قبل بلده.
🛠 Join @LLMEngineers Community
روشهای سنتی Curriculum Learning معمولاً استاتیک هستن و از "آسون به سخت" میرن جلو (مثلاً بر اساس طول متن). اما EDCO میگه برای یک مدل Pre-trained، دادههای آسون عملاً Noise هستن چون مدل قبلاً اون مفاهیم رو بلده.
متد EDCO (Entropy-based Dynamic Curriculum Orchestration) میاد وسط پروسه Training، دائماً چک میکنه که مدل روی کدوم نمونهها "عدم قطعیت" یا همون Inference Entropy بالایی داره.
نکته جالب ماجرا اینجاست که این روش یه جورایی Reverse Curriculum حساب میشه. یعنی به جای اینکه اول آسونها رو یاد بگیره، تمرکز رو میذاره روی نمونههایی که مدل رو به چالش میکشن (High Entropy Samples). این کار باعث میشه مدل دچار "Entropy Collapse" نشه (حالتی که مدل الکی اعتماد به نفسش میره بالا و دیگه یاد نمیگیره).
چالش فنی این ایده اینه که محاسبه Entropy برای کل دیتاست در هر مرحله، هزینه پردازشی وحشتناکی داره. تیم نویسنده برای حل این مشکل دوتا تریک جالب زدن:
۱. استفاده از Quick-Answer Prompting: مدل رو مجبور میکنن جواب کوتاه بده تا سریعتر پردازش بشه.
۲. تکنیک Prefix Entropy Approximation: به جای کل خروجی، فقط ۵۰ تا ۱۲۸ توکن اول رو برای محاسبه آنتروپی چک میکنن که طبق بنچمارکهاشون ۸۳.۵ درصد سریعتره و دقتش هم حفظ میشه.
نتیجه نهایی روی دیتای مخابراتی (که پر از اصطلاحات خاصه) نشون داده که هم در SFT و هم در RLFT، این روش بهتر از Random Sampling و روشهای سنتی عمل کرده.
📃 عنوان مقاله: EDCO: DYNAMIC CURRICULUM ORCHESTRATION FOR DOMAIN-SPECIFIC LARGE LANGUAGE MODEL FINE-TUNING
https://openreview.net/pdf?id=sF0p40wM8X
به نظر من، این مقاله یه حقیقت تلخ رو یادآوری میکنه: اکثر ما در پروسه Fine-tuning تنبلی میکنیم و فقط دنبال جمع کردن دیتای بیشتر هستیم، در حالی که "نحوه ارائه دیتا" به مدل، به اندازه خود دیتا مهمه. برای پروژه بعدیتون اگر دیتای کمی دارید، به جای Data Augmentation الکی، روی مکانیزمهایی مثل Active Learning یا همین Dynamic Curriculum وقت بذارید تا مدل روی نقاط ضعفش تمرکز کنه نه روی چیزایی که از قبل بلده.
🛠 Join @LLMEngineers Community