AI Engineers

یه تکنیک جدید و خیلی کاربردی معرفی شده به اسم 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

🛠 Join @LLMEngineers Community

خیلی موافقم

خیلی جاها دیدم اشتباها به یه workflow میگن agent
ولی متفاوتن، تفاوتشون اینه که یه Workflow فقط یه سری مراحل از پیش تعیین‌شده رو اجرا می‌کنه؛ مثل یه فلوچارت ثابت. اما یه Agent واقعی، یه سیستم خودگردان (autonomous) هست که خودش برای رسیدن به هدف برنامه‌ریزی، استدلال و مسیرش رو اصلاح می‌کنه.

🛠 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

مدل‌های جدید 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

مجموعه 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

یه مقایسه‌ی جالب از روند ساخت LLMها بین سال ۲۰۲۳ و ۲۰۲۵

۱. مرحله Pretraining: تمرکز از دیتا میکس‌های عمومی رفته روی دیتاهای باکیفیت‌تر. اولویت با کد بوده و الان دیگه synthetic data هم بهش اضافه شده.

۲. مرحله Midtraining: این مرحله‌ی جدید، یه جور fine-tuning تخصصی بین pretraining و post-training هست. اینجا قابلیت‌های خاص مثل افزایش طول متن (Context-expansion) یا تمرکز روی تسک‌های استدلالی سنگین (Reasoning heavy) به مدل تزریق می‌شه. به نظر من، این مرحله مهم‌ترین تغییره چون اجازه می‌ده مدل‌ها برای کاربردهای خاص بهینه بشن بدون اینکه نیاز به pretrain از اول باشه.

۳. مرحله Post-training: این فاز هم دقیق‌تر شده. قبلاً کلی‌گویی بود، اما الان به دو بخش مشخص SFT برای یادگیری دنبال کردن دستورات و RL برای هم‌راستاسازی نهایی با ترجیحات انسانی تقسیم شده.

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

🛠 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

یه مقایسه‌ی بی‌تعارف و به‌روز از ابزارهای اصلی برای ران کردن 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

مدل جدید 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

یه مدل جدید و قدرتمند مولتی‌مودال از سری Qwen به اسم Qwen3-VL ریلیز شده که همزمان تصویر، ویدیو و متن رو به عنوان ورودی می‌گیره و خروجی متنی تولید می‌کنه. کاربرد اصلیش فراتر از VQA ساده رفته و روی تحلیل ویدیوهای خیلی طولانی و کاربردهای ایجنت‌محور برای کنترل رابط کاربری (GUI) تمرکز داره.

این مدل توی دو نسخه ارائه شده:

Instruct:
برای کاربردهای عمومی مثل تشخیص متن از تصویر (OCR)، تحلیل نمودار و داکیومنت و درک رابط کاربری.

Thinking:
برای استدلال‌های پیچیده‌تر، حل مسائل ریاضی و علمی که نیاز به chain-of-thought داره.

معماری این مدل از نوع Mixture-of-Experts یا MoE هست. مدل ۲۳۵ میلیارد پارامتری در مجموع حدود ۲۳۵ میلیارد پارامتر داره، اما در هر forward pass فقط حدود ۲۲ میلیارد پارامتر فعال میشه (A22B). این ساختار که از ۱۲۸ اکسپرت با ۸ اکسپرت فعال تشکیل شده، باعث میشه مدل خیلی بزرگ باشه ولی هزینه محاسباتی برای inference کنترل‌شده باقی بمونه.

از نظر فنی چندتا ویژگی کلیدی داره:

طول زمینه بالا: به صورت نیتیو 256K توکن context داره که با تکنیک‌های scaling مثل RoPE میشه اون رو تا حدود ۱ میلیون توکن افزایش داد. این قابلیت، تحلیل کتاب‌ها یا ویدیوهای چند ساعته رو ممکن می‌کنه.

درک ویدیو: با استفاده از معماری‌هایی مثل Interleaved-MRoPE و Text–Timestamp Alignment، میتونه رویدادها رو با دقت زمانی بالا توی ویدیوهای طولانی تشخیص بده.

درک فضایی: توانایی درک موقعیت اشیاء به صورت دو‌بعدی و سه‌بعدی (3D grounding) رو داره که برای رباتیک و embodied AI مهمه.

OCR پیشرفته: از ۳۲ زبان پشتیبانی می‌کنه و توی شرایط نوری ضعیف، زاویه‌های نامناسب یا روی متون تار عملکرد خوبی از خودش نشون میده.

برای اجرا کردنش به سخت‌افزار سنگین نیاز هست. توی داکیومنت‌هاش به کارت‌های H100 انویدیا با CUDA 12 به بالا اشاره شده و مثال‌های inference با موازی‌سازی روی ۸ تا GPU ارائه شدن. پس برای استفاده عملی باید به فکر زیرساخت بود.

به نظر من، Qwen3-VL یه قدم مهم در دنیای مدل‌های مولتی‌مودال اپن‌سورس (با لایسنس Apache-2.0) محسوب میشه. ترکیب MoE با context طولانی برای ویدیو و قابلیت‌های ایجنت، اون رو به یه ابزار قدرتمند برای ساخت محصولات پیچیده تبدیل کرده، به شرطی که منابع سخت‌افزاری لازم براش فراهم باشه.

🤗 مدل در هاگینگ فیس

🛠 Join @LLMEngineers Community

یه مشکل اساسی تو پایپ‌لاین‌های RAG، پردازش داکیومنت‌های پیچیده‌ مثل PDF هست. ابزارهای عادی متن رو به صورت خطی و بدون ساختار استخراج می‌کنن که باعث می‌شه کلی از کانتکست مثل جداول، لیست‌ها و ترتیب خوندن متن از بین بره. اینجاست که مدل جدید و اوپن‌سورس IBM یعنی Granite-Docling وارد می‌شه تا این مشکل رو حل کنه.

این مدل یه Vision-Language Model یا VLM خیلی کوچیک با حجم 258M پارامتره که برای فهم کامل ساختار داکیومنت‌ها طراحی شده. کارش اینه که به جای استخراج متن خام، ساختار سند رو با تمام جزئیاتش مثل جداول، فرمول‌های ریاضی، بلوک‌های کد و لی‌اوت صفحه حفظ می‌کنه. این مدل بر اساس معماری Granite 3 و انکودر بصری SigLIP2 ساخته شده و تحت لایسنس Apache 2.0 در دسترسه.

نقطه‌ی قوت اصلی Granite-Docling در فرمت خروجی منحصربه‌فردش به اسم DocTags هست. این یه زبان نشانه‌گذاریه که خود IBM توسعه داده تا تمام المان‌های صفحه رو به صورت ساختاریافته توصیف کنه. DocTags محتوای متنی رو از ساختار سند جدا می‌کنه و روابط بین المان‌ها، مثلاً اینکه یک کپشن مربوط به کدوم شکله، رو هم مشخص می‌کنه. این فرمت برای پردازش توسط LLM ها بهینه شده و می‌شه به‌راحتی اون رو به Markdown، JSON یا HTML تبدیل کرد.

باید بین Granite-Docling و کتابخونه‌ی Docling تفاوت قائل شد. Docling یه کتابخونه پایتون و یه پایپ‌لاین کامله که کل فرآیند تبدیل سند رو مدیریت می‌کنه. می‌تونه مدل‌های مختلفی رو ارکستر کنه. در مقابل، Granite-Docling یه مدل خاص و تخصصی برای همین کاره که می‌تونه به عنوان موتور اصلی توی این پایپ‌لاین استفاده بشه. این ترکیب، یه راهکار end-to-end برای آماده‌سازی داکیومنت‌ها برای RAG فراهم می‌کنه.

برای کاربردهای RAG، این رویکرد یه تغییر بازیه. وقتی شما داکیومنت رو با حفظ ساختارش به Markdown تبدیل می‌کنید، فرآیند chunking خیلی هوشمندانه‌تر انجام می‌شه. کتابخونه‌ی Docling یه ابزار به اسم HybridChunker داره که chunk هایی با کانتکست بهتر تولید می‌کنه. این یعنی امبدینگ‌های باکیفیت‌تر، بازیابی دقیق‌تر و در نهایت، کاهش چشم‌گیر هذیان‌گویی یا hallucination در پاسخ‌های مدل.

به نظر من، ارزش اصلی Granite-Docling در اندازه‌ی کوچیک و تخصص بالای اونه. دیگه لازم نیست برای فهم ساختار سند به سراغ مدل‌های غول‌پیکر چند ده میلیاردی بریم. این مدل نشون می‌ده که با یه معماری درست و دیتاست تمیز، می‌شه یه مدل کم‌حجم و کارآمد ساخت که یه مشکل مشخص رو به خوبی حل کنه. فرمت DocTags هم یه ایده‌ی خیلی خوبه چون یه لایه‌ی میانی استاندارد برای نمایش ساختار داکیومنت ایجاد می‌کنه که می‌تونه اساس خیلی از تسک‌های downstream باشه. این مدل همچنین قابلیت‌های آزمایشی برای زبان‌های غیرلاتین مثل چینی، ژاپنی و عربی هم داره که نشون‌دهنده‌ی مسیر توسعه‌ی آینده‌شه.

💻 دمو

🛠 Join @LLMEngineers Community

ٖ🐧 ویدیو ارائه (اثر نرم‌افزار آزاد در رشد هوش مصنوعی) منتشر شد.

👤 ارائه دهنده: محمد شجاعی

متخصص مدل‌های زبانی، طرفدار فرهنگ نرم‌افزار آزد و دسترس‌پذیری در هوش مصنوعی

🗃 درباره این ارائه:
در این ارائه به نقش نرم‌افزار آزاد در تحول هوش مصنوعی می‌پردازیم. توضیح می‌دهیم چگونه کامیونیتی اوپن‌سورس با ابزارهایی مثل PyTorch و Hugging Face و مدل‌های متن‌باز، نوآوری را سرعت داده و شرکت‌های بزرگ را به شفافیت بیشتر وادار کرده است. همچنین به تفاوت مدل‌های open-source و open-weight و اهمیت این روند برای زبان‌های کمتر پشتیبانی‌شده اشاره می‌کنیم.

📌 لینک ویدیوی کامل: https://tubedu.org/w/mMUTdti8QGQSUvDupFoSuK


#نرم‌_افزار_آزاد #روز_آزادی_نرم_افزار

مسیر ساخت اولین AI Agent؛ بدون هایپ و تئوری‌های اضافه.

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

اولین قدم، انتخاب یه مسئله‌ی خیلی کوچیک و مشخصه. فکر ساختن یه "ایجنت همه‌کاره" رو از سرت بیرون کن. یه وظیفه‌ی خاص رو مشخص کن. مثلاً: رزرو وقت دکتر از یه سایت بیمارستان، یا پیدا کردن شغل‌های مرتبط با تو و فرستادن ایمیل. هرچی مسئله کوچیک‌تر و شفاف‌تر باشه، دیزاین و دیباگ کردنش راحت‌تره.

دومین قدم، انتخاب یه LLM پایه است. لازم نیست از اول مدل خودت رو ترین کنی. از مدل‌های آماده مثل GPT، Claude یا Gemini استفاده کن. اگه می‌خوای self-host کنی، Kimi-K2 یا Qwen گزینه‌های خوبی‌ان. فقط مطمئن شو مدل قابلیت reasoning و تولید خروجی‌های ساختاریافته (structured outputs) رو داشته باشه، چون ایجنت‌ها به اینا وابسته‌ان.

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

- وب اسکرپینگ با Playwright یا Puppeteer
- کار با ایمیل از طریق Gmail API یا Outlook API
- دسترسی به تقویم با Google Calendar API
- عملیات روی فایل مثل خوندن و نوشتن یا پارس کردن PDF

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

برای حافظه از اول سراغ سیستم‌های پیچیده نرو. حافظه‌ی کوتاه‌مدت (short-term context) که همون چندتا پیام آخره، برای شروع کافیه. اگه نیاز به حافظه‌ی بلندمدت داشتی، یه فایل JSON ساده یا یه دیتابیس Sqlite کار رو راه میندازه. Vector databaseها رو بذار برای وقتی که واقعاً بهشون نیاز پیدا کردی (سیستم RAG).

در نهایت، برای ایجنتت یه رابط کاربری ساده بساز. یه اسکریپت CLI برای اولش خوبه، ولی بعداً با Streamlit می‌تونی یه وب اپ ساده براش بیاری بالا تا توی یه محیط واقعی تستش کنی.

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

🛠 Join @LLMEngineers Community

دیتاست جدید FinePDFs برای pre-training منتشر شده. این دیتاست ۳ تریلیون توکنی از محتوای فایل‌های PDF استخراج شده و برای حل مشکل کمبود داده باکیفیت یا همون "data wall" عرضه شده. کاربرد اصلیش اینه که اگه با دیتاست‌های مبتنی بر وب ترکیب بشه، پرفورمنس مدل رو به شکل قابل توجهی بالا می‌بره. به علاوه، چون میانگین طول داکیومنت‌ها در PDFها خیلی بیشتر از صفحات وب هست، برای آموزش مدل‌های long-context یه منبع فوق‌العاده‌ست.

مدتیه که دیتاست‌های مبتنی بر وب دارن به سقف ظرفیتشون می‌رسن. PDFها همیشه یه منبع غنی از محتوای باکیفیت بودن، مثل مقالات علمی، اسناد حقوقی و گزارش‌های فنی، ولی استخراج متن ازشون به خاطر ساختار پیچیده و هزینه بالای پردازش، یه چالش بزرگ بوده. تیم Hugging Face با استفاده از کتابخونه datatrove این دیتاست رو آماده کرده.

برای استخراج متن، یه پایپ‌لاین دو مرحله‌ای طراحی شده تا هزینه رو مدیریت کنن.
۱. برای PDFهایی که متن قابل استخراج (native) دارن، از ابزار Docling روی CPU استفاده شده که روش ارزون‌تریه.
۲. برای PDFهای اسکن‌شده یا اونایی که متن‌شون به صورت عکس هست، از یه VLM به اسم rolmOCR روی GPU استفاده شده که هزینه بالاتری داره ولی کیفیتش عالیه.

نتیجه‌ی این فرایند، دیتاستی با ۳ تریلیون توکن از ۴۷۵ میلیون داکیومنت در ۱۷۳۳ زبان مختلفه. تست‌ها نشون داده که ترکیب این دیتاست با دیتاست‌های SOTA مبتنی بر وب (مثل SmolLM3-Web)، نتایج بهتری نسبت به هر کدوم به تنهایی می‌ده. بهترین عملکرد وقتی به دست اومده که حدود ۲۵٪ از دیتای pre-training از FinePDFs و بقیه‌ش از منابع وب باشه. پس توصیه نمیشه که یه مدل رو فقط با این دیتاست از صفر آموزش بدید.


🤗 دیتاست FinePDFs در Hugging Face

🛠 Join @LLMEngineers Community

علی‌بابا یه مدل جدید به اسم Qwen3 Next 80B داده که تونستن به سطح هوش DeepSeek V3.1 برسن، در حالی که فقط ۳ میلیارد پارامتر فعال دارن. این یعنی کارایی و بهینگی خیلی بالا با حفظ قدرت.

معماری این مدل از چندتا تکنیک جدید استفاده می‌کنه. به جای attention استاندارد، از یه مکانیزم هیبریدی به اسم Gated DeltaNet و Gated Attention استفاده شده. مهم‌ترین بخشش اما، معماری Mixture-of-Experts با پراکندگی (sparsity) خیلی بالاست. از ۸۰ میلیارد پارامتر کل، فقط ۳.۸٪ در هر لحظه فعال میشن. این یعنی کاهش شدید فلاپس و در نتیجه سرعت بالاتر inference، مخصوصاً برای context های طولانی. یه تکنیک دیگه هم به اسم Multi-Token Prediction یا MTP برای افزایش سرعت inference به کار رفته.

عملکردش در بنچمارک‌ها خیلی خوب بوده و کنار مدل‌های سنگین‌تر قرار می‌گیره. نکته‌ی مهم اینه که روی یک کارت H200 جا میشه و این برای دولوپرهای عادی و شرکت‌هایی که نمی‌خوان هزینه سرورهای غول‌پیکر بدن، خبر خیلی خوبیه. پنجره‌ی context نیتیو مدل 256k توکنه که با تکنیک YaRN تا حدود ۱ میلیون توکن هم قابل افزایشه. این برای پردازش اسناد خیلی طولانی کاربرد داره.

برای دیپلوی کردنش، بهترین راه استفاده از فریمورک‌های بهینه‌شده مثل sglang یا vllm هست. این ابزارها بهتون یه اندپوینت OpenAI-compatible می‌دن و اجازه می‌دن از تمام ظرفیت سرعت مدل، مخصوصاً MTP، استفاده کنین. استفاده از transformers خام، تمام پتانسیل مدل رو آزاد نمی‌کنه.

به نظر من، این مدل یه سیگنال واضحه که آینده‌ی مدل‌ها فقط در بزرگ‌تر شدن خلاصه نمیشه، بلکه در هوشمندتر شدن معماریه. جنگ پارامتر داره جاش رو به جنگ بهینگی می‌ده. معماری‌های sparse که دانش رو در پارامترهای زیاد ذخیره می‌کنن ولی موقع inference فقط بخش کوچیکی رو فعال می‌کنن، آینده‌ی مدل‌های production-ready هستن. ترکیب ظرفیت بالا با هزینه محاسباتی پایین، همون چیزیه که برای کاربردهای واقعی لازم داریم و Qwen3 Next یه قدم محکم در این مسیره.

🤗 جزئیات فنی و بنچمارک‌ها


🛠 Join @LLMEngineers Community