یه مدل جدید ۴ میلیاردی به اسم Jan-v1 معرفی شده که کار اصلیش سرچ وب و ریسرچ عمیقه. تیم سازندهش اون رو به عنوان یه جایگزین open-source برای Perplexity Pro معرفی کرده که به صورت کاملاً local هم اجرا میشه.
این مدل روی نسخهی جدید Qwen یعنی Qwen3-4B-Thinking ساخته شده که تا ۲۵۶ هزار توکن context length داره. به طور مشخص برای reasoning و استفاده از ابزارها (tool use) فاینتیون شده که این یعنی برای کارهای agentic و حل مسائل پیچیده بهینه شده.
توی ارزیابی SimpleQA، به دقت ۹۱.۱٪ رسیده که طبق بنچمارکهای منتشر شده، عملکردش یه مقدار از Perplexity Pro بهتره. این نشون میده که مدلهای با این سایز هم میتونن توی تسکهای واقعی مثل پرسش و پاسخ مبتنی بر فکت، عملکرد خیلی خوبی داشته باشن.
برای استفاده، میشه اون رو توی Jan App، یا با فریمورکهای llama.cpp و vLLM اجرا کرد. اگه از Jan App استفاده میکنید، برای فعال کردن قابلیت سرچ باید از تنظیمات، Experimental Features رو روشن کنید و بعدش یه سرور MCP مثل Serper رو فعال کنید تا به اینترنت دسترسی داشته باشه.
به نظر من، حرکت به سمت مدلهای کوچیکتر و تخصصی که به صورت local هم اجرا میشن، خیلی مهمه. این مدلها کنترل بیشتری به دولوپر میدن و وابستگی به API های پولی رو کم میکنن. اینکه یه مدل 4B داره با سرویسی مثل Perplexity رقابت میکنه، نشون میده که آینده فقط دست مدلهای غولپیکر نیست و مدلهای بهینه شده برای تسکهای خاص، جایگاه خودشون رو دارن.
فایلهای مدل رو میتونید از لینکهای زیر بگیرید:
📃 مدل اصلی Jan-v1-4B
📃 نسخه GGUF برای llama.cpp
🛠 Join @LLMEngineers Community
این مدل روی نسخهی جدید Qwen یعنی Qwen3-4B-Thinking ساخته شده که تا ۲۵۶ هزار توکن context length داره. به طور مشخص برای reasoning و استفاده از ابزارها (tool use) فاینتیون شده که این یعنی برای کارهای agentic و حل مسائل پیچیده بهینه شده.
توی ارزیابی SimpleQA، به دقت ۹۱.۱٪ رسیده که طبق بنچمارکهای منتشر شده، عملکردش یه مقدار از Perplexity Pro بهتره. این نشون میده که مدلهای با این سایز هم میتونن توی تسکهای واقعی مثل پرسش و پاسخ مبتنی بر فکت، عملکرد خیلی خوبی داشته باشن.
برای استفاده، میشه اون رو توی Jan App، یا با فریمورکهای llama.cpp و vLLM اجرا کرد. اگه از Jan App استفاده میکنید، برای فعال کردن قابلیت سرچ باید از تنظیمات، Experimental Features رو روشن کنید و بعدش یه سرور MCP مثل Serper رو فعال کنید تا به اینترنت دسترسی داشته باشه.
به نظر من، حرکت به سمت مدلهای کوچیکتر و تخصصی که به صورت local هم اجرا میشن، خیلی مهمه. این مدلها کنترل بیشتری به دولوپر میدن و وابستگی به API های پولی رو کم میکنن. اینکه یه مدل 4B داره با سرویسی مثل Perplexity رقابت میکنه، نشون میده که آینده فقط دست مدلهای غولپیکر نیست و مدلهای بهینه شده برای تسکهای خاص، جایگاه خودشون رو دارن.
فایلهای مدل رو میتونید از لینکهای زیر بگیرید:
📃 مدل اصلی Jan-v1-4B
📃 نسخه GGUF برای llama.cpp
🛠 Join @LLMEngineers Community
LLM Engineers
یه مدل جدید ۴ میلیاردی به اسم Jan-v1 معرفی شده که کار اصلیش سرچ وب و ریسرچ عمیقه. تیم سازندهش اون رو به عنوان یه جایگزین open-source برای Perplexity Pro معرفی کرده که به صورت کاملاً local هم اجرا میشه. این مدل روی نسخهی جدید Qwen یعنی Qwen3-4B-Thinking…
🛠 Join @LLMEngineers Community
یه تست سریع و عملی روی چندتا LLM برای یه تسک سادهی NLP تشخیص زبان انجام دادم.
شرایط تست مشخص بود: همه مدلها به وب دسترسی داشتن، پس پیدا کردن بهترین و سریعترین راهحل هم بخشی از آزمون بود. مهمتر اینکه، تست کاملاً Zero-Shot بود؛ یعنی کد تولید شده باید در اولین تلاش، بدون هیچ دخالت یا اصلاح دستی، اجرا میشد.
نتایج خیلی جالب بود. Claude Sonnet 4 با اختلاف بهترین عملکرد رو داشت. نه فقط کد رو Zero-Shot و بدون خطا تحویل داد، بلکه بهینهترین الگوریتم رو با latency فقط 0.63 میلیثانیه انتخاب کرد. نکته جالبتر این بود که توی کدش ۴ تا روش مختلف رو هم مقایسه کرده بود که این نشوندهنده فهم عمیق مسئله است.
در مقابل، مدلهایی مثل Qwen Coder یا DeepSeek R1 که ادعای زیادی روی کد دارن، روی این تسک و با این شرایط fail شدن.
🛠 Join @LLMEngineers Community
شرایط تست مشخص بود: همه مدلها به وب دسترسی داشتن، پس پیدا کردن بهترین و سریعترین راهحل هم بخشی از آزمون بود. مهمتر اینکه، تست کاملاً Zero-Shot بود؛ یعنی کد تولید شده باید در اولین تلاش، بدون هیچ دخالت یا اصلاح دستی، اجرا میشد.
نتایج خیلی جالب بود. Claude Sonnet 4 با اختلاف بهترین عملکرد رو داشت. نه فقط کد رو Zero-Shot و بدون خطا تحویل داد، بلکه بهینهترین الگوریتم رو با latency فقط 0.63 میلیثانیه انتخاب کرد. نکته جالبتر این بود که توی کدش ۴ تا روش مختلف رو هم مقایسه کرده بود که این نشوندهنده فهم عمیق مسئله است.
در مقابل، مدلهایی مثل Qwen Coder یا DeepSeek R1 که ادعای زیادی روی کد دارن، روی این تسک و با این شرایط fail شدن.
🛠 Join @LLMEngineers Community
گوگل از یه ورژن خیلی کوچیک Gemma 3 رونمایی کرده که ۲۷۰ میلیون پارامتریه.
کاربرد اصلی این مدل برای fine-tune کردن سریع و اجرای تسکهای هوش مصنوعی روی دستگاههای کاربر (on-device) هست. نقطه قوت کلیدی این مدل، توانایی بالای اون در دنبال کردن دستورات یا instruction following هست که توی بنچمارک IFEval سنجیده شده.
توی نمودار مقایسهای، نسخه 270M با اینکه سایز کوچیکی داره، مدلهای بزرگتری مثل Qwen 2.5 0.5B و SmolLM2-360M رو با اختلاف کنار زده. این موضوع نشوندهنده بهینگی بالا در معماری و کیفیت دیتاست pre-train هست.
🛠 Join @LLMEngineers Community
کاربرد اصلی این مدل برای fine-tune کردن سریع و اجرای تسکهای هوش مصنوعی روی دستگاههای کاربر (on-device) هست. نقطه قوت کلیدی این مدل، توانایی بالای اون در دنبال کردن دستورات یا instruction following هست که توی بنچمارک IFEval سنجیده شده.
توی نمودار مقایسهای، نسخه 270M با اینکه سایز کوچیکی داره، مدلهای بزرگتری مثل Qwen 2.5 0.5B و SmolLM2-360M رو با اختلاف کنار زده. این موضوع نشوندهنده بهینگی بالا در معماری و کیفیت دیتاست pre-train هست.
🛠 Join @LLMEngineers Community
LLM Engineers
گوگل از یه ورژن خیلی کوچیک Gemma 3 رونمایی کرده که ۲۷۰ میلیون پارامتریه. کاربرد اصلی این مدل برای fine-tune کردن سریع و اجرای تسکهای هوش مصنوعی روی دستگاههای کاربر (on-device) هست. نقطه قوت کلیدی این مدل، توانایی بالای اون در دنبال کردن دستورات یا instruction…
جزئیات فنی معماری و آموزش
معماری این مدل ۲۷۰ میلیون پارامتری خیلی جالبه. از این عدد، ۱۷۰ میلیون پارامتر فقط برای embeddingهاست و ۱۰۰ میلیون پارامتر به بلوکهای transformer اختصاص داده شده. این یعنی بخش بزرگی از ظرفیت مدل صرف درک توکنها شده. دلیلش هم داشتن یک vocabulary بسیار بزرگ با ۲۵۶ هزار توکنه. این ویژگی باعث میشه مدل پایه (base model) خیلی قوی باشه و برای fine-tune شدن روی دامنههای تخصصی یا زبانهای مختلف که توکنهای نادری دارن، عملکرد فوقالعادهای از خودش نشون بده.
نکته کلیدی دیگه، حجم دیتای آموزشیه. این مدل ۲۷۰ میلیون پارامتری روی ۶ تریلیون توکن آموزش دیده. در حالی که نسخههای بزرگتر مثل Gemma 3 1B روی ۲ تریلیون و 4B روی ۴ تریلیون توکن آموزش دیدن. این نسبت بالای دیتا به پارامتر (data-to-parameter ratio) یکی از دلایل اصلی عملکرد قوی این مدل در زمینه instruction following هست. امتیاز ۵۱.۲ در بنچمارک IFEval برای مدلی در این سایز، نشوندهنده همین بهینگی در آموزشه.
برای بهینگی بیشتر، گوگل نسخههای Quantization-Aware Trained یا QAT رو هم منتشر کرده. این یعنی مدل از همون ابتدا با در نظر گرفتن کوانتایز شدن آموزش دیده و میشه اون رو با دقت INT4 و با کمترین افت عملکرد اجرا کرد. تستهای داخلی روی چیپست Pixel 9 Pro نشون داده که نسخه INT4 این مدل برای ۲۵ مکالمه فقط ۰.۷۵٪ از باتری رو مصرف کرده که اون رو به بهینهترین مدل Gemma از نظر مصرف انرژی تبدیل میکنه.
چطور ازش استفاده کنیم؟
این مدل برای تسکهای پیچیده و مکالمههای طولانی طراحی نشده. قدرت اصلیش وقتی مشخص میشه که روی یک تسک مشخص fine-tune بشه. به خاطر سایز کوچیکش، فرایند fine-tuning خیلی سریعه و میشه در چند ساعت به نتیجه رسید، نه چند روز.
ابزارهایی مثل Unsloth و فریمورکهای استاندارد مثل JAX و Hugging Face به طور کامل ازش پشتیبانی میکنن. برای اجرا هم میتونید از پلتفرمهایی مثل Ollama، LM Studio یا llama.cpp استفاده کنید.
🤗 صفحه مدل در Hugging Face
🛠 Join @LLMEngineers Community
معماری این مدل ۲۷۰ میلیون پارامتری خیلی جالبه. از این عدد، ۱۷۰ میلیون پارامتر فقط برای embeddingهاست و ۱۰۰ میلیون پارامتر به بلوکهای transformer اختصاص داده شده. این یعنی بخش بزرگی از ظرفیت مدل صرف درک توکنها شده. دلیلش هم داشتن یک vocabulary بسیار بزرگ با ۲۵۶ هزار توکنه. این ویژگی باعث میشه مدل پایه (base model) خیلی قوی باشه و برای fine-tune شدن روی دامنههای تخصصی یا زبانهای مختلف که توکنهای نادری دارن، عملکرد فوقالعادهای از خودش نشون بده.
نکته کلیدی دیگه، حجم دیتای آموزشیه. این مدل ۲۷۰ میلیون پارامتری روی ۶ تریلیون توکن آموزش دیده. در حالی که نسخههای بزرگتر مثل Gemma 3 1B روی ۲ تریلیون و 4B روی ۴ تریلیون توکن آموزش دیدن. این نسبت بالای دیتا به پارامتر (data-to-parameter ratio) یکی از دلایل اصلی عملکرد قوی این مدل در زمینه instruction following هست. امتیاز ۵۱.۲ در بنچمارک IFEval برای مدلی در این سایز، نشوندهنده همین بهینگی در آموزشه.
برای بهینگی بیشتر، گوگل نسخههای Quantization-Aware Trained یا QAT رو هم منتشر کرده. این یعنی مدل از همون ابتدا با در نظر گرفتن کوانتایز شدن آموزش دیده و میشه اون رو با دقت INT4 و با کمترین افت عملکرد اجرا کرد. تستهای داخلی روی چیپست Pixel 9 Pro نشون داده که نسخه INT4 این مدل برای ۲۵ مکالمه فقط ۰.۷۵٪ از باتری رو مصرف کرده که اون رو به بهینهترین مدل Gemma از نظر مصرف انرژی تبدیل میکنه.
چطور ازش استفاده کنیم؟
این مدل برای تسکهای پیچیده و مکالمههای طولانی طراحی نشده. قدرت اصلیش وقتی مشخص میشه که روی یک تسک مشخص fine-tune بشه. به خاطر سایز کوچیکش، فرایند fine-tuning خیلی سریعه و میشه در چند ساعت به نتیجه رسید، نه چند روز.
ابزارهایی مثل Unsloth و فریمورکهای استاندارد مثل JAX و Hugging Face به طور کامل ازش پشتیبانی میکنن. برای اجرا هم میتونید از پلتفرمهایی مثل Ollama، LM Studio یا llama.cpp استفاده کنید.
🤗 صفحه مدل در Hugging Face
🛠 Join @LLMEngineers Community
یکی از ابزارهای خفن برای فاینتونینگ مدلهای زبانی Axolotl عه،
خیلی ساده، Axolotl یه فریمورک اوپنسورس برای فاینتون کردن LLMهاست. تمرکزش روی اینه که بهترین و جدیدترین تکنیکها رو خیلی سریع در اختیارت بذاره. از مدلهای Llama و Qwen گرفته تا Gemma و حالا gpt-oss.
این فریمورک با بهینهسازیهای پیشرفتهای مثل FlashAttention برای محاسبات سریعتر attention، و gradient checkpointing برای صرفهجویی تو مصرف مموری، خودش رو مجهز کرده. قابلیتهایی مثل multipacking (استفاده بهینه از مموری با پک کردن چند سکانس کوتاه کنار هم) و RoPE scaling (برای کار با context lengthهای متغیر) هم جزو ویژگیهای استانداردشه.
نقطه قوت اصلی Axolotl، تواناییهاش توی distributed training هست. یعنی اگه بخوای روی چندتا GPU یا حتی چندتا سرور (multi-node) یه مدل غولپیکر رو ترین کنی، Axolotl با پشتیبانی از DeepSpeed (ZeRO stages 1-3) و FSDP (Fully Sharded Data Parallel) کارت رو راه میندازه.
Axolotl یا Unsloth؟ مسئله این است
هر دو ابزار عالین، ولی انتخاب بینشون بستگی به نیازت داره.
چرا باید Axolotl رو انتخاب کنی؟
مقیاسپذیری و Multi-GPU: اگه میخوای مدلهای واقعاً بزرگ رو روی چندین GPU ردهبالا فاینتون کنی، Axolotl بهترین گزینهست. استراتژیهای distributed training توش به بلوغ رسیدن، چیزی که Unsloth هنوز توش خیلی کار داره.
انعطافپذیری و کنترل کامل: Axolotl گزینههای کانفیگ خیلی زیادی برای کنترل دقیق پروسه ترینینگ بهت میده. از sequence parallelism برای contextهای خیلی طولانی گرفته تا یکپارچهسازی با ابزارهایی مثل Weights & Biases برای مانیتورینگ.
چه زمانی Unsloth برنده میشه؟
سرعت و بهینهسازی VRAM روی تک GPU: اگه سختافزار محدودی داری (مثلاً یه کارت گرافیک گیمینگ یا سرورهای قدیمیتر Colab)، Unsloth معجزه میکنه. با کرنلهای سفارشی که برای GPU نوشته، میتونه تا ۲-۵ برابر سریعتر باشه و تا ۸۰٪ VRAM کمتری مصرف کنه.
به نظر من، اگه اولویتت سرعت حداکثری و بازدهی روی یک یا دوتا GPU هست و با مدلهای محبوب کار میکنی، Unsloth کارت رو خیلی سریع و تمیز راه میندازه. اما برای کارهای تحقیقاتی، فاینتونینگ مدلهای عظیم و نیاز به کنترل کامل روی محیطهای distributed، قطعاً Axolotl برتری داره.
فاینتونینگ مدلهای GPT-OSS با Axolotl
اخیراً OpenAI دو مدل Mixture-of-Experts (MoE) به اسم gpt-oss-20B و gpt-oss-120B رو به صورت اوپنویت منتشر کرده. خبر خوب اینه که Axolotl خیلی سریع پشتیبانی از فاینتونینگ این مدلها رو اضافه کرده.
یکی از نکات مهمی که جامعه بهش رسیده اینه که تکنیکهای Parameter-Efficient Fine-Tuning (PEFT) مثل QLoRA، بهخصوص روی تسکهای پیچیده، عملکرد ضعیفتری نسبت به full-parameter fine-tuning دارن. برای همین Axolotl روی قابلیتهای distributed training خودش سرمایهگذاری کرده تا بتونی مدلهای 70B+ رو بدون افت کیفیت، به صورت کامل فاینتون کنی.
پروسه فاینتونینگ با Axolotl حول یک فایل کانفیگ YAML میچرخه که توش همهچیز رو تعریف میکنی.
نیازمندیهای سختافزاری:
QLoRA: برای این تکنیک روی مدل gpt-oss-20B، یه GPU با حدود ۱۶ تا ۲۴ گیگ VRAM کافیه.
Full Fine-Tuning (FFT): برای فاینتونینگ کامل، به سختافزار سنگین مثل H100 با ۸۰ گیگ VRAM نیاز داری. البته با استراتژیهایی مثل FSDP و offloading میشه مدل gpt-oss-20B رو روی دوتا GPU با ۲۴ گیگ VRAM هم ترین کرد.
مدل 120B: طبق داکیومنتهای Axolotl، میشه مدل gpt-oss-120B رو با FFT و offloading روی یک نود با ۸ تا H100 (هر کدوم ۸۰ گیگ) فاینتون کرد.
کانفیگ YAML:
توی فایل کانفیگ، base_model رو openai/gpt-oss-20b میذاری و دیتاست خودت رو مشخص میکنی. برای تکنیکهای مختلف، کانفیگهای متفاوتی وجود داره:
برای QLoRA، گزینهی load_in_4bit: true و adapter: qlora رو فعال میکنی.
برای FFT، این گزینهها رو حذف میکنی.
چون این مدلها MoE هستن، باید lora_target_modules رو روی لایههای درستی مثل gate_proj تنظیم کنی.
ویژگیهای جدید:
با آپدیتهای اخیر، Axolotl از FP8 هم پشتیبانی میکنه که مصرف مموری رو از این هم کمتر میکنه. همچنین با همکاری Hugging Face، امکان ترکیب Context Parallelism، Tensor Parallelism و FSDP برای ترین کردن مدلهای عظیم در مقیاس multi-node فراهم شده.
در کل، Axolotl خودش رو به عنوان یه ابزار جدی و قدرتمند برای کارهای بزرگ و تحقیقاتی ثابت کرده و اگه قصد داری مدلهای سنگین رو به صورت حرفهای فاینتون کنی، یکی از بهترین گزینههاست.
📃 بلاگ رسمی Hugging Face درباره ND Parallelism
📃 مثالهای کانفیگ برای فاینتونینگ GPT-OSS
🛠 Join @LLMEngineers Community
خیلی ساده، Axolotl یه فریمورک اوپنسورس برای فاینتون کردن LLMهاست. تمرکزش روی اینه که بهترین و جدیدترین تکنیکها رو خیلی سریع در اختیارت بذاره. از مدلهای Llama و Qwen گرفته تا Gemma و حالا gpt-oss.
این فریمورک با بهینهسازیهای پیشرفتهای مثل FlashAttention برای محاسبات سریعتر attention، و gradient checkpointing برای صرفهجویی تو مصرف مموری، خودش رو مجهز کرده. قابلیتهایی مثل multipacking (استفاده بهینه از مموری با پک کردن چند سکانس کوتاه کنار هم) و RoPE scaling (برای کار با context lengthهای متغیر) هم جزو ویژگیهای استانداردشه.
نقطه قوت اصلی Axolotl، تواناییهاش توی distributed training هست. یعنی اگه بخوای روی چندتا GPU یا حتی چندتا سرور (multi-node) یه مدل غولپیکر رو ترین کنی، Axolotl با پشتیبانی از DeepSpeed (ZeRO stages 1-3) و FSDP (Fully Sharded Data Parallel) کارت رو راه میندازه.
Axolotl یا Unsloth؟ مسئله این است
هر دو ابزار عالین، ولی انتخاب بینشون بستگی به نیازت داره.
چرا باید Axolotl رو انتخاب کنی؟
مقیاسپذیری و Multi-GPU: اگه میخوای مدلهای واقعاً بزرگ رو روی چندین GPU ردهبالا فاینتون کنی، Axolotl بهترین گزینهست. استراتژیهای distributed training توش به بلوغ رسیدن، چیزی که Unsloth هنوز توش خیلی کار داره.
انعطافپذیری و کنترل کامل: Axolotl گزینههای کانفیگ خیلی زیادی برای کنترل دقیق پروسه ترینینگ بهت میده. از sequence parallelism برای contextهای خیلی طولانی گرفته تا یکپارچهسازی با ابزارهایی مثل Weights & Biases برای مانیتورینگ.
چه زمانی Unsloth برنده میشه؟
سرعت و بهینهسازی VRAM روی تک GPU: اگه سختافزار محدودی داری (مثلاً یه کارت گرافیک گیمینگ یا سرورهای قدیمیتر Colab)، Unsloth معجزه میکنه. با کرنلهای سفارشی که برای GPU نوشته، میتونه تا ۲-۵ برابر سریعتر باشه و تا ۸۰٪ VRAM کمتری مصرف کنه.
به نظر من، اگه اولویتت سرعت حداکثری و بازدهی روی یک یا دوتا GPU هست و با مدلهای محبوب کار میکنی، Unsloth کارت رو خیلی سریع و تمیز راه میندازه. اما برای کارهای تحقیقاتی، فاینتونینگ مدلهای عظیم و نیاز به کنترل کامل روی محیطهای distributed، قطعاً Axolotl برتری داره.
فاینتونینگ مدلهای GPT-OSS با Axolotl
اخیراً OpenAI دو مدل Mixture-of-Experts (MoE) به اسم gpt-oss-20B و gpt-oss-120B رو به صورت اوپنویت منتشر کرده. خبر خوب اینه که Axolotl خیلی سریع پشتیبانی از فاینتونینگ این مدلها رو اضافه کرده.
یکی از نکات مهمی که جامعه بهش رسیده اینه که تکنیکهای Parameter-Efficient Fine-Tuning (PEFT) مثل QLoRA، بهخصوص روی تسکهای پیچیده، عملکرد ضعیفتری نسبت به full-parameter fine-tuning دارن. برای همین Axolotl روی قابلیتهای distributed training خودش سرمایهگذاری کرده تا بتونی مدلهای 70B+ رو بدون افت کیفیت، به صورت کامل فاینتون کنی.
پروسه فاینتونینگ با Axolotl حول یک فایل کانفیگ YAML میچرخه که توش همهچیز رو تعریف میکنی.
نیازمندیهای سختافزاری:
QLoRA: برای این تکنیک روی مدل gpt-oss-20B، یه GPU با حدود ۱۶ تا ۲۴ گیگ VRAM کافیه.
Full Fine-Tuning (FFT): برای فاینتونینگ کامل، به سختافزار سنگین مثل H100 با ۸۰ گیگ VRAM نیاز داری. البته با استراتژیهایی مثل FSDP و offloading میشه مدل gpt-oss-20B رو روی دوتا GPU با ۲۴ گیگ VRAM هم ترین کرد.
مدل 120B: طبق داکیومنتهای Axolotl، میشه مدل gpt-oss-120B رو با FFT و offloading روی یک نود با ۸ تا H100 (هر کدوم ۸۰ گیگ) فاینتون کرد.
کانفیگ YAML:
توی فایل کانفیگ، base_model رو openai/gpt-oss-20b میذاری و دیتاست خودت رو مشخص میکنی. برای تکنیکهای مختلف، کانفیگهای متفاوتی وجود داره:
برای QLoRA، گزینهی load_in_4bit: true و adapter: qlora رو فعال میکنی.
برای FFT، این گزینهها رو حذف میکنی.
چون این مدلها MoE هستن، باید lora_target_modules رو روی لایههای درستی مثل gate_proj تنظیم کنی.
ویژگیهای جدید:
با آپدیتهای اخیر، Axolotl از FP8 هم پشتیبانی میکنه که مصرف مموری رو از این هم کمتر میکنه. همچنین با همکاری Hugging Face، امکان ترکیب Context Parallelism، Tensor Parallelism و FSDP برای ترین کردن مدلهای عظیم در مقیاس multi-node فراهم شده.
در کل، Axolotl خودش رو به عنوان یه ابزار جدی و قدرتمند برای کارهای بزرگ و تحقیقاتی ثابت کرده و اگه قصد داری مدلهای سنگین رو به صورت حرفهای فاینتون کنی، یکی از بهترین گزینههاست.
📃 بلاگ رسمی Hugging Face درباره ND Parallelism
📃 مثالهای کانفیگ برای فاینتونینگ GPT-OSS
🛠 Join @LLMEngineers Community
یه مقایسه عملی و سریع بین Ollama و LM Studio موقع اجرای یه مدل GGUF یکسان. نتایج جالبه و شاید برای انتخاب ابزار کمکتون کنه.
توی این تست، مدل gemma-2-2b-fa یک بار با LM Studio و یک بار با Ollama روی یه مجموعه سوال یکسان ارزیابی شده.
نتایج خلاصه:
LM Studio:
دقت 31.04% و میانگین latency برابر 0.15s.
Ollama:
دقت 29.40% و میانگین latency برابر 0.43s.
همونطور که مشخصه، LM Studio هم دقت بالاتری داشته و هم تقریباً ۳ برابر سریعتر بوده. علاوه بر این، مصرف VRAM در Ollama هم بیشتر بود.
🛠 Join @LLMEngineers Community
توی این تست، مدل gemma-2-2b-fa یک بار با LM Studio و یک بار با Ollama روی یه مجموعه سوال یکسان ارزیابی شده.
نتایج خلاصه:
LM Studio:
دقت 31.04% و میانگین latency برابر 0.15s.
Ollama:
دقت 29.40% و میانگین latency برابر 0.43s.
همونطور که مشخصه، LM Studio هم دقت بالاتری داشته و هم تقریباً ۳ برابر سریعتر بوده. علاوه بر این، مصرف VRAM در Ollama هم بیشتر بود.
🛠 Join @LLMEngineers Community
داشتم قابلیت function calling یا tool use رو با مدلهای لوکال تست میکردم که یه نتیجه جالب گرفتم.
مدل کوچیک jan-v1-4b که قبلتر راجبش گفته بودنم رو توی LM Studio ران کردم و بهش MCP جستجوی وب با DuckDuckGo وصل کردم. وقتی ازش خواستم آخرین اخبار هوش مصنوعی رو بهم بگه، به جای اینکه از دانش داخلی و تاریخ گذشتهش استفاده کنه، خودش تشخیص داد که باید از ابزار search استفاده کنه.
همونطور که توی اسکرینشات مشخصه، مدل به صورت خودکار یه کوئری جستجو ساخت، اجراش کرد و بعد نتایج رو برام خلاصه کرد. این دقیقاً همون فرآیند ReAct هست که داریم روی مدلهای بزرگ میبینیم، ولی این بار روی یه مدل ۴ میلیاردی لوکال.
به نظر من، این قابلیت که مدلهای کوچیک و open-source هم بتونن از ابزارهای خارجی استفاده کنن، بازی رو عوض میکنه. این یعنی دیگه محدود به دانش داخلی مدل نیستیم و میتونیم مدلها رو برای کاربردهای واقعی و ساختن agent های ساده آماده کنیم.
🛠 Join @LLMEngineers Community
مدل کوچیک jan-v1-4b که قبلتر راجبش گفته بودنم رو توی LM Studio ران کردم و بهش MCP جستجوی وب با DuckDuckGo وصل کردم. وقتی ازش خواستم آخرین اخبار هوش مصنوعی رو بهم بگه، به جای اینکه از دانش داخلی و تاریخ گذشتهش استفاده کنه، خودش تشخیص داد که باید از ابزار search استفاده کنه.
همونطور که توی اسکرینشات مشخصه، مدل به صورت خودکار یه کوئری جستجو ساخت، اجراش کرد و بعد نتایج رو برام خلاصه کرد. این دقیقاً همون فرآیند ReAct هست که داریم روی مدلهای بزرگ میبینیم، ولی این بار روی یه مدل ۴ میلیاردی لوکال.
به نظر من، این قابلیت که مدلهای کوچیک و open-source هم بتونن از ابزارهای خارجی استفاده کنن، بازی رو عوض میکنه. این یعنی دیگه محدود به دانش داخلی مدل نیستیم و میتونیم مدلها رو برای کاربردهای واقعی و ساختن agent های ساده آماده کنیم.
🛠 Join @LLMEngineers Community
مجموع دانلود مدلهای فارسی gemma-3-4b که چند ماه پیش منتشر کردم، از مرز ۴ هزار دانلود عبور کرد.
این آمار شامل تمام نسخههای کوانتایز شده GGUF، نسخهی Ollama و ...
این استقبال نشون میده که چقدر به مدلهای زبانی فارسی باکیفیت و اپنسورس نیاز داریم. این عدد فقط یه آمار نیست، بلکه سوخت و انگیزهی اصلی برای ادامهی این مسیره.
با همین انرژی، کار روی پروژهی بعدی شروع شده.
منتظر نسخهی فاینتیون شدهی فارسی Qwen3-4B یا gemma-3n-e4b باشید. بهزودی ...
🤗 صفحه من توی هاگینگ فیس
🛠 Join @LLMEngineers Community
این آمار شامل تمام نسخههای کوانتایز شده GGUF، نسخهی Ollama و ...
این استقبال نشون میده که چقدر به مدلهای زبانی فارسی باکیفیت و اپنسورس نیاز داریم. این عدد فقط یه آمار نیست، بلکه سوخت و انگیزهی اصلی برای ادامهی این مسیره.
با همین انرژی، کار روی پروژهی بعدی شروع شده.
منتظر نسخهی فاینتیون شدهی فارسی Qwen3-4B یا gemma-3n-e4b باشید. بهزودی ...
🤗 صفحه من توی هاگینگ فیس
🛠 Join @LLMEngineers Community
نتیجه تست مدل های زبانی کوچک SLM روی بنچمارک ParsiEval برای سنجش دانش زبان فارسی
پ.ن: لازم به ذکره qwen thinking هم خیلی کند تر بود هم gpu داغ کن تر
▫️ لیست کامل
🛠 Join @LLMEngineers Community
پ.ن: لازم به ذکره qwen thinking هم خیلی کند تر بود هم gpu داغ کن تر
▫️ لیست کامل
🛠 Join @LLMEngineers Community
This media is not supported in your browser
VIEW IN TELEGRAM
توضیح غیرفنی معماری MoE
🛠 Join @LLMEngineers Community
🛠 Join @LLMEngineers Community
خب، بیاید بیتعارف بریم سراغ معایب واقعی فریمورکهای RAG و Agent. این روزا همه دنبال راه حل سریعن، ولی این ابزارها عصای موسی نیستن و هرکدوم کلی دردسر و مشکلات فنی با خودشون میارن. اینجا یه کالبدشکافی از مشکلاتشون رو میبینید که از تجربه و بازخورد دولوپرها درومده.
اصل داستان توی ساخت سیستمهای مبتنی بر LLM، ارکستریشن (orchestration) هست. یعنی مدیریت جریان کار، فراخوانی ابزارها، و نگهداری وضعیت (state). هر فریمورکی یه راهی برای این ارکستریشن پیشنهاد میده و انتخاب اشتباه میتونه منجر به مشکلات معماری جدی بشه.
استفاده مستقیم از OpenAI SDK یعنی شما مسئولیت کامل لایه ارکستریشن رو به عهده میگیرید. این به معنی کنترل صددرصدی روی پرامپتها، مدیریت state و منطق فراخوانی ابزارهاست. از نظر فنی، این روش کمترین overhead و dependency رو داره ولی تمام پیچیدگیهای state management و control flow رو به کدبیس اپلیکیشن شما منتقل میکنه. برای سیستمهای پیچیده، این یعنی باید یک مینی-فریمورک داخلی برای خودتون بنویسید.
فریمورک LangChain مشکل اصلیش سطح بالای انتزاع (high level of abstraction) هست. این فریمورک منطق اصلی رو پشت کلاسها و متدهای خودش مخفی میکنه و این باعث میشه introspection یا همون بازبینی عملکرد داخلی سیستم، به شدت سخت بشه. مثلا فهمیدن اینکه پرامپت نهایی که به مدل ارسال شده دقیقاً چی بوده، کار سادهای نیست. این "جادو" هزینه داره: سربار محاسباتی و حافظه بیشتر، و سختی در دیباگ کردن. LangGraph تلاشی برای حل این مشکله؛ با تبدیل کردن جریان کار به یک گراف صریح (explicit graph)، کنترل بیشتری روی control flow به دولوپر میده. در واقع شما یک state machine تعریف میکنید. چالش فنی LangGraph اینه که هنوز جدیده، ابزارهای جانبی و مستندات کاملی نداره و پیچیدگی مدیریت گراف به عهده خود شماست.
ابزار LlamaIndex معماریش کاملاً داده-محور (data-centric) هست و برای پایپلاینهای ingestion و retrieval در RAG بهینهسازی شده. انتزاعهای اصلیش مثل Index و QueryEngine برای این کار طراحی شدن. نقطه ضعف فنیش اینه که قابلیتهای agentic اون به اندازه بخش retrieval توسعه پیدا نکرده. اگه بخواید یک ایجنت با منطق پیچیده و ابزارهای متنوع بسازید، ممکنه معماری LlamaIndex محدودتون کنه.
در مورد Haystack باید گفت که یک فریمورک پایپلاین-محور (pipeline-centric) هست. شما یک Pipeline از Node های مختلف میسازید که هرکدوم یک وظیفه مشخص دارن. این معماری ماژولار و شفاف، دیباگ کردن رو ساده میکنه. اما برای ساخت ایجنتهای پیچیده که نیاز به حلقههای منطقی (reasoning loops) و مدیریت حافظه مکالمه دارن، Haystack ابزارهای آماده کمتری ارائه میده و باید منطق رو به صورت سفارشی در Node های خودتون پیادهسازی کنید.
فریمورکهایی مثل CrewAI و AutoGen یک پارادایم سطح بالاتر برای سیستمهای چند-ایجتی (multi-agent systems) ارائه میدن. مشکل فنی این رویکرد، نبود observability و کنترل دقیق روی تعاملات بین ایجنتهاست. وقتی چندین ایجنت با هم شروع به کار میکنن، فضای حالت (state space) سیستم به شدت پیچیده میشه و دیباگ کردن اینکه چرا یک ایجنت تصمیم اشتباهی گرفته، تقریباً غیرممکنه. اینها بیشتر برای کارهای تحقیقاتی و اتوماسیونهای خاص مناسبن تا اپلیکیشنهای پروداکشن که نیاز به پایداری و رفتار قابل پیشبینی دارن.
پلتفرمهای low-code مثل Langflow و Dify.ai برای پروتوتایپینگ سریع عالین، ولی از نظر مهندسی نرمافزار مشکلات جدی دارن. بزرگترین مشکل، عدم سازگاری با فرآیندهای استاندارد CI/CD و version control هست. مدیریت تغییرات، تستنویسی و همکاری تیمی روی یک فلو-چارت گرافیکی بسیار سختتر از کد هست. این ابزارها برای رسیدن به پیچیدگیهای دنیای واقعی، مقیاسپذیر نیستن.
در نهایت، ابزارهای تخصصی و مینیمال هم جایگاه خودشون رو دارن. Vanna فقط برای Text-to-SQL طراحی شده و معماریش برای همین کار بهینه شده. txtai و smol-agents هم فلسفه مینیمالیسم دارن. چالش فنی smol-agents عدم پشتیبانی نیتیو از async هست که برای ساخت اپلیکیشنهای I/O-bound مقیاسپذیر یک محدودیت جدیه.
به نظر من تنها راه معقول برای ساختن یه اپلیکیشن جدی و قابل نگهداری، استفاده مستقیم از OpenAI SDK و ساختن منطق کار روی پایههای مهندسی نرمافزار واقعیه. بقیهی این فریمورکها یا اسباببازی هستن، یا تلههای بهرهوری که فقط technical debt تولید میکنن. گول "سادگی پیاده سازی" رو نخورید. هیچ میانبری وجود نداره. یا کار رو درست و اصولی انجام میدی، یا چند ماه دیگه در حال بازنویسی کامل پروژهای هستی که تو باتلاق یه فریمورک پر از هایپ گیر کرده.
🛠 Join @LLMEngers Community
اصل داستان توی ساخت سیستمهای مبتنی بر LLM، ارکستریشن (orchestration) هست. یعنی مدیریت جریان کار، فراخوانی ابزارها، و نگهداری وضعیت (state). هر فریمورکی یه راهی برای این ارکستریشن پیشنهاد میده و انتخاب اشتباه میتونه منجر به مشکلات معماری جدی بشه.
استفاده مستقیم از OpenAI SDK یعنی شما مسئولیت کامل لایه ارکستریشن رو به عهده میگیرید. این به معنی کنترل صددرصدی روی پرامپتها، مدیریت state و منطق فراخوانی ابزارهاست. از نظر فنی، این روش کمترین overhead و dependency رو داره ولی تمام پیچیدگیهای state management و control flow رو به کدبیس اپلیکیشن شما منتقل میکنه. برای سیستمهای پیچیده، این یعنی باید یک مینی-فریمورک داخلی برای خودتون بنویسید.
فریمورک LangChain مشکل اصلیش سطح بالای انتزاع (high level of abstraction) هست. این فریمورک منطق اصلی رو پشت کلاسها و متدهای خودش مخفی میکنه و این باعث میشه introspection یا همون بازبینی عملکرد داخلی سیستم، به شدت سخت بشه. مثلا فهمیدن اینکه پرامپت نهایی که به مدل ارسال شده دقیقاً چی بوده، کار سادهای نیست. این "جادو" هزینه داره: سربار محاسباتی و حافظه بیشتر، و سختی در دیباگ کردن. LangGraph تلاشی برای حل این مشکله؛ با تبدیل کردن جریان کار به یک گراف صریح (explicit graph)، کنترل بیشتری روی control flow به دولوپر میده. در واقع شما یک state machine تعریف میکنید. چالش فنی LangGraph اینه که هنوز جدیده، ابزارهای جانبی و مستندات کاملی نداره و پیچیدگی مدیریت گراف به عهده خود شماست.
ابزار LlamaIndex معماریش کاملاً داده-محور (data-centric) هست و برای پایپلاینهای ingestion و retrieval در RAG بهینهسازی شده. انتزاعهای اصلیش مثل Index و QueryEngine برای این کار طراحی شدن. نقطه ضعف فنیش اینه که قابلیتهای agentic اون به اندازه بخش retrieval توسعه پیدا نکرده. اگه بخواید یک ایجنت با منطق پیچیده و ابزارهای متنوع بسازید، ممکنه معماری LlamaIndex محدودتون کنه.
در مورد Haystack باید گفت که یک فریمورک پایپلاین-محور (pipeline-centric) هست. شما یک Pipeline از Node های مختلف میسازید که هرکدوم یک وظیفه مشخص دارن. این معماری ماژولار و شفاف، دیباگ کردن رو ساده میکنه. اما برای ساخت ایجنتهای پیچیده که نیاز به حلقههای منطقی (reasoning loops) و مدیریت حافظه مکالمه دارن، Haystack ابزارهای آماده کمتری ارائه میده و باید منطق رو به صورت سفارشی در Node های خودتون پیادهسازی کنید.
فریمورکهایی مثل CrewAI و AutoGen یک پارادایم سطح بالاتر برای سیستمهای چند-ایجتی (multi-agent systems) ارائه میدن. مشکل فنی این رویکرد، نبود observability و کنترل دقیق روی تعاملات بین ایجنتهاست. وقتی چندین ایجنت با هم شروع به کار میکنن، فضای حالت (state space) سیستم به شدت پیچیده میشه و دیباگ کردن اینکه چرا یک ایجنت تصمیم اشتباهی گرفته، تقریباً غیرممکنه. اینها بیشتر برای کارهای تحقیقاتی و اتوماسیونهای خاص مناسبن تا اپلیکیشنهای پروداکشن که نیاز به پایداری و رفتار قابل پیشبینی دارن.
پلتفرمهای low-code مثل Langflow و Dify.ai برای پروتوتایپینگ سریع عالین، ولی از نظر مهندسی نرمافزار مشکلات جدی دارن. بزرگترین مشکل، عدم سازگاری با فرآیندهای استاندارد CI/CD و version control هست. مدیریت تغییرات، تستنویسی و همکاری تیمی روی یک فلو-چارت گرافیکی بسیار سختتر از کد هست. این ابزارها برای رسیدن به پیچیدگیهای دنیای واقعی، مقیاسپذیر نیستن.
در نهایت، ابزارهای تخصصی و مینیمال هم جایگاه خودشون رو دارن. Vanna فقط برای Text-to-SQL طراحی شده و معماریش برای همین کار بهینه شده. txtai و smol-agents هم فلسفه مینیمالیسم دارن. چالش فنی smol-agents عدم پشتیبانی نیتیو از async هست که برای ساخت اپلیکیشنهای I/O-bound مقیاسپذیر یک محدودیت جدیه.
به نظر من تنها راه معقول برای ساختن یه اپلیکیشن جدی و قابل نگهداری، استفاده مستقیم از OpenAI SDK و ساختن منطق کار روی پایههای مهندسی نرمافزار واقعیه. بقیهی این فریمورکها یا اسباببازی هستن، یا تلههای بهرهوری که فقط technical debt تولید میکنن. گول "سادگی پیاده سازی" رو نخورید. هیچ میانبری وجود نداره. یا کار رو درست و اصولی انجام میدی، یا چند ماه دیگه در حال بازنویسی کامل پروژهای هستی که تو باتلاق یه فریمورک پر از هایپ گیر کرده.
🛠 Join @LLMEngers Community
LLM Engineers
خب، بیاید بیتعارف بریم سراغ معایب واقعی فریمورکهای RAG و Agent. این روزا همه دنبال راه حل سریعن، ولی این ابزارها عصای موسی نیستن و هرکدوم کلی دردسر و مشکلات فنی با خودشون میارن. اینجا یه کالبدشکافی از مشکلاتشون رو میبینید که از تجربه و بازخورد دولوپرها…
Screenshot 2025-08-18 192400.png
272.6 KB
Media is too big
VIEW IN TELEGRAM
یه ویدیو خلاصه درباره فاینتیون مدل gpt-oss-120b
ساخته شده با notebooklm
🛠 Join @LLMEngineers Community
ساخته شده با notebooklm
🛠 Join @LLMEngineers Community
یه بنچمارک برای long context به اسم Fiction.LiveBench هست که نشون میده کدوم مدلها واقعاً میتونن محتوای طولانی رو بفهمن.
عملکرد اکثر مدلها، به خصوص مدلهای open-source، با افزایش طول متن به شدت افت میکنه. این یعنی پشتیبانی از یک context window بزرگ، به هیچ وجه تضمینی برای فهم عمیق محتوا نیست.
مدل gpt-oss-120b یه مثال بارزه. با اینکه مدل بزرگیه، عملکردش با افزایش کانتکست به سرعت سقوط میکنه و توی 8k توکن به زیر ۵۰٪ دقت میرسه. این نشون میده برای کارهایی که نیاز به استدلال و درک عمیق در متنهای طولانی دارن، هنوز راه زیادی در پیش داره.
در مقابل، مدلهای proprietary مثل gpt-5 و gemini-2.5-pro پایداری فوقالعادهای دارن و حتی در کانتکستهای بالای 120k توکن، دقت بالایی رو حفظ میکنن.
به نظر من، این نوع ارزیابیها واقعیت مدلها رو بهتر نشون میده. توانایی reasoning و comprehension در یک long context چالش اصلیه، نه فقط داشتن یک پنجره کانتکست بزرگ.
🛠 Join @LLMEngineers Community
عملکرد اکثر مدلها، به خصوص مدلهای open-source، با افزایش طول متن به شدت افت میکنه. این یعنی پشتیبانی از یک context window بزرگ، به هیچ وجه تضمینی برای فهم عمیق محتوا نیست.
مدل gpt-oss-120b یه مثال بارزه. با اینکه مدل بزرگیه، عملکردش با افزایش کانتکست به سرعت سقوط میکنه و توی 8k توکن به زیر ۵۰٪ دقت میرسه. این نشون میده برای کارهایی که نیاز به استدلال و درک عمیق در متنهای طولانی دارن، هنوز راه زیادی در پیش داره.
در مقابل، مدلهای proprietary مثل gpt-5 و gemini-2.5-pro پایداری فوقالعادهای دارن و حتی در کانتکستهای بالای 120k توکن، دقت بالایی رو حفظ میکنن.
به نظر من، این نوع ارزیابیها واقعیت مدلها رو بهتر نشون میده. توانایی reasoning و comprehension در یک long context چالش اصلیه، نه فقط داشتن یک پنجره کانتکست بزرگ.
🛠 Join @LLMEngineers Community
یه مدل جدید برای ادیت عکس اومده به اسم Qwen-Image-Edit که مستقیم روی تسکهای ویرایش تصویر تمرکز کرده. کاربرد اصلیش اینه که میتونی با دستورات متنی، تغییرات دقیق و کنترلشدهای روی عکسها اعمال کنی، مخصوصاً وقتی پای ویرایش متن داخل عکس وسط باشه.
مدل Qwen-Image-Edit بر پایهی مدل بزرگتر Qwen-Image با ۲۰ میلیارد پارامتر ساخته شده. معماری این مدل برای کنترل دقیق روی ویرایش، یه رویکرد هوشمندانه داره. تصویر ورودی به دو بخش داده میشه:
۱. یک بخش میره به Qwen2.5-VL که یک مدل ویژن-زبان هست. این قسمت مسئول درک معنایی و مفهومی تصویره. یعنی مدل میفهمه توی عکس چه خبره و دستور شما برای تغییر، چه مفهومی داره. این برای کنترل Semantic Editing استفاده میشه.
۲. بخش دوم میره به یک VAE Encoder. این قسمت روی ظاهر بصری و جزئیات سطح پایین تصویر تمرکز میکنه. هدفش اینه که مناطقی از عکس که قرار نیست تغییر کنن، دستنخورده باقی بمونن. اینم برای کنترل Appearance Editing هست.
خروجی این دو انکودر با هم به مدل اصلی که یک Multimodal Diffusion Transformer یا MMDiT هست، داده میشه. اینطوری مدل میتونه بین حفظ جزئیات اصلی تصویر و اعمال تغییرات معنایی، تعادل برقرار کنه.
قابلیتهای اصلی که ارائه میده به این شکله:
ویرایش معنایی (Semantic Editing): برای تغییرات سطح بالا مثل عوض کردن استایل هنری عکس (مثلاً به سبک استودیو جیبلی)، چرخوندن اشیاء توی صحنه (Novel View Synthesis) یا حتی خلق کاراکترهای جدید بر اساس یک IP اولیه. اینجا کل پیکسلهای عکس میتونه تغییر کنه ولی مفهوم اصلی حفظ میشه.
ویرایش ظاهری (Appearance Editing): برای تغییرات دقیق و محلی. مثلاً اضافه کردن یا حذف یک شیء، تغییر پسزمینه، یا عوض کردن رنگ لباس. نکته کلیدی اینه که بقیهی قسمتهای عکس کاملاً ثابت باقی میمونن.
ویرایش دقیق متن: این یکی از نقاط قوت اصلی این مدله. میتونه متنهای انگلیسی و چینی رو داخل عکسها ویرایش، حذف یا اضافه کنه و سعی میکنه استایل، فونت و اندازهی متن اصلی رو هم حفظ کنه. این قابلیت توی مدلهای غربی معمولاً ضعیفه. میشه به صورت زنجیرهای (Chained Editing) هم برای اصلاح خطاهای تایپی یا نوشتاری در تصاویر استفاده کرد.
مدل فقط یک سری پیکسل رو عوض نمیکنه، بلکه واقعاً میفهمه چه چیزی رو باید تغییر بده و چه چیزی رو باید ثابت نگه داره. عملکردش توی بنچمارکهای GEdit و ImgEdit هم قوی بوده و در سطح مدلهای SOTA مثل GPT-4o و FLUX.1 قرار گرفته.
📃 صفحه مدل در Hugging Face
🛠 Join @LLMEngineers Community
مدل Qwen-Image-Edit بر پایهی مدل بزرگتر Qwen-Image با ۲۰ میلیارد پارامتر ساخته شده. معماری این مدل برای کنترل دقیق روی ویرایش، یه رویکرد هوشمندانه داره. تصویر ورودی به دو بخش داده میشه:
۱. یک بخش میره به Qwen2.5-VL که یک مدل ویژن-زبان هست. این قسمت مسئول درک معنایی و مفهومی تصویره. یعنی مدل میفهمه توی عکس چه خبره و دستور شما برای تغییر، چه مفهومی داره. این برای کنترل Semantic Editing استفاده میشه.
۲. بخش دوم میره به یک VAE Encoder. این قسمت روی ظاهر بصری و جزئیات سطح پایین تصویر تمرکز میکنه. هدفش اینه که مناطقی از عکس که قرار نیست تغییر کنن، دستنخورده باقی بمونن. اینم برای کنترل Appearance Editing هست.
خروجی این دو انکودر با هم به مدل اصلی که یک Multimodal Diffusion Transformer یا MMDiT هست، داده میشه. اینطوری مدل میتونه بین حفظ جزئیات اصلی تصویر و اعمال تغییرات معنایی، تعادل برقرار کنه.
قابلیتهای اصلی که ارائه میده به این شکله:
ویرایش معنایی (Semantic Editing): برای تغییرات سطح بالا مثل عوض کردن استایل هنری عکس (مثلاً به سبک استودیو جیبلی)، چرخوندن اشیاء توی صحنه (Novel View Synthesis) یا حتی خلق کاراکترهای جدید بر اساس یک IP اولیه. اینجا کل پیکسلهای عکس میتونه تغییر کنه ولی مفهوم اصلی حفظ میشه.
ویرایش ظاهری (Appearance Editing): برای تغییرات دقیق و محلی. مثلاً اضافه کردن یا حذف یک شیء، تغییر پسزمینه، یا عوض کردن رنگ لباس. نکته کلیدی اینه که بقیهی قسمتهای عکس کاملاً ثابت باقی میمونن.
ویرایش دقیق متن: این یکی از نقاط قوت اصلی این مدله. میتونه متنهای انگلیسی و چینی رو داخل عکسها ویرایش، حذف یا اضافه کنه و سعی میکنه استایل، فونت و اندازهی متن اصلی رو هم حفظ کنه. این قابلیت توی مدلهای غربی معمولاً ضعیفه. میشه به صورت زنجیرهای (Chained Editing) هم برای اصلاح خطاهای تایپی یا نوشتاری در تصاویر استفاده کرد.
مدل فقط یک سری پیکسل رو عوض نمیکنه، بلکه واقعاً میفهمه چه چیزی رو باید تغییر بده و چه چیزی رو باید ثابت نگه داره. عملکردش توی بنچمارکهای GEdit و ImgEdit هم قوی بوده و در سطح مدلهای SOTA مثل GPT-4o و FLUX.1 قرار گرفته.
📃 صفحه مدل در Hugging Face
🛠 Join @LLMEngineers Community