خب، بیاید بی‌تعارف بریم سراغ معایب واقعی فریمورک‌های 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

یه ویدیو خلاصه درباره فاین‌تیون مدل gpt-oss-120b
ساخته شده با 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

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

بر اساس تجربه تیم سازنده cline، که یک ایجنت کدنویسی پیشرفته برای VSCode هست، سه تا ویروس فکری رایج تو ساختن AI Agents وجود داره. این ایده‌ها روی کاغذ هوشمندانه به نظر میان، ولی در عمل کار نمی‌کنن.

۱. ارکستراسیون چند ایجنتی (Multi-Agent Orchestration)
این دیدگاه علمی-تخیلی که یک ایجنت اصلی، دسته‌ای از زیر-ایحنت‌ها (مثلاً ایجنت تحلیلگر، ایجنت تحقیق و...) رو مدیریت کنه و نتایج رو با هم ترکیب کنه، در عمل جواب نمیده. بیشتر کارهای مفید و واقعی ایجنت‌ها به صورت single-threaded انجام میشه.
پیاده‌سازی ارکستراسیون‌های پیچیده، فقط به سردرگمی و پیچیدگی کد اضافه می‌کنه و تفسیر رفتار مدل رو هم سخت‌تر می‌کنه، بدون اینکه ارزش واقعی تولید کنه. به اندازه کافی سخت هست که مدل رو تو یک مسیر واحد به درستی هدایت کنیم، چه برسه به مدیریت چندین ایجنت موازی. در عمل، چیزی که به عنوان «رهبر ایجنت» و «زیر-ایحنت» تو مقالات می‌بینیم، بیشتر شبیه یک ترد اصلی با چند tool call متوالی هست.

۲. بازیابی اطلاعات (RAG) برای ایجنت‌های کدنویسی
این ایده که RAG می‌تونه به ایجنت‌ها درک عمیقی از کدبیس بده، یک ویروس فکریه. در عمل، ابزارهای ساده‌تری مثل grep اغلب بهتر کار می‌کنن، مخصوصاً برای ایجنت‌های کدنویسی.
مشکل اصلی اینه که RAG (مشخصاً وقتی از Vector DB ها استفاده میشه) کدهای پراکنده و بی‌ربط رو به مدل میده که به یک "فهم" یکپارچه از کد منجر نمیشه. رویکرد بهتر اینه که مدل مثل یک برنامه‌نویس واقعی عمل کنه: فایل‌ها رو لیست کنه، با grep جستجو کنه و بعد کل فایل‌های مرتبط رو بخونه. اینطوری کانتکست کامل رو در اختیار داره، نه فقط چند تکه کد که از نظر وکتوری شبیه بودن.

۳. دستورالعمل‌های بیشتر = نتایج بهتر
این تصور که با اضافه کردن دستورالعمل‌های زیاد به system prompt، مدل هوشمندتر و قابل کنترل‌تر میشه، کاملاً اشتباهه. پر کردن پرامپت با دستورالعمل‌های زیاد، مدل رو با اطلاعات متناقض و اضافی گیج می‌کنه و باعث میشه خروجی غیرقابل پیش‌بینی بشه.
برای مدل‌های پیشرفته امروزی، بهتره زیاد در مسیرشون قرار نگیریم و اجازه بدیم کارشون رو بکنن. به جای "داد زدن" سر مدل با پرامپت‌های طولانی، باید توکن‌ها رو با دقت و به صورت بهینه مصرف کرد. این پرامپت‌های سنگین شاید برای مدل‌های قدیمی‌تر مفید بودن، ولی برای مدل‌های جدید کارایی ندارن.

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

منبع

🛠 Join @LLMEngineers Community

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

اصل داستان، ساخت یک پایپ‌لاین Speech-to-Speech با کمترین Latency ممکن روی سخت‌افزار معمولیه. معماری کلی سیستم به این شکله که صدا به صورت استریم پردازش می‌شه و از یک چرخه چندمرحله‌ای عبور می‌کنه:
۱. تشخیص فعالیت صوتی (VAD) با pyannote/segmentation-3.0
۲. تبدیل گفتار به متن (STT) با whisper-tiny.en
۳. پردازش توسط مدل زبان (LLM) از طریق Ollama با مدلی مثل qwen2.5:0.5b
۴. تبدیل متن به گفتار (TTS) با Kokoro-82M

اما بخش مهم ماجرا، تکنیک‌هایی هست که برای کاهش Latency استفاده شده، خصوصاً Perceived Latency یا تأخیری که کاربر حس می‌کنه.

اولین تکنیک، Priority-based Text Chunking هست. به جای اینکه منتظر بمونیم تا کل جواب LLM آماده بشه، خروجی مدل به صورت استریم گرفته می‌شه و به محض رسیدن اولین کلمات، پردازش شروع می‌شه. یک TextChunker سفارشی، این متن رو بر اساس اولویت‌بندی هوشمندانه‌ای به قطعات کوچیک‌تر تقسیم می‌کنه. اولویت با علائم نگارشی مثل نقطه و علامت سواله، بعدش نوبت کلمات ربطی مثل "however" یا "and" و در نهایت کاما و خط تیره می‌رسه. اینطوری TTS می‌تونه اولین تیکه از جواب رو خیلی سریع‌تر به صوت تبدیل کنه، در حالی که بقیه جواب هنوز داره تولید می‌شه.

دومین تکنیک، یه حقه جالب توی پرامپت‌نویسیه. از LLM خواسته می‌شه که جوابش رو با کلمات پُرکننده (Filler Words) مثل "umm" یا "so" شروع کنه. این کلمات تک‌هجایی هستن و TTS در چند میلی‌ثانیه اون‌ها رو به صوت تبدیل می‌کنه. این باعث می‌شه کاربر تقریباً بلافاصله یه صدایی از سیستم بشنوه و حس کنه که سیستم داره فکر می‌کنه تا جواب بده. این مکث کوتاه و طبیعی، زمان لازم برای تولید بقیه جواب رو می‌خره و تأخیر واقعی سیستم رو از دید کاربر پنهان می‌کنه.

نتیجه‌ی این رویکرد روی یک سیستم بدون GPU با پردازنده AMD Ryzen 5600G، رسیدن به Latency حدود ۲ ثانیه بوده. اما با این تکنیک‌ها، زمان شنیدن اولین صوت از سیستم به ۰.۵ تا ۰.۷ ثانیه کاهش پیدا کرده که تجربه مکالمه رو خیلی طبیعی‌تر می‌کنه.

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

📃 مشاهده پروژه در گیت‌هاب:
https://github.com/asiff00/On-Device-Speech-to-Speech-Conversational-AI

🛠 Join @LLMEngineers Community

پشت این ویدیو از مبارزه زاکربرگ و آلتمن، مدل Wan 2.1 از شرکت علی‌بابا قرار داره.

چالش اصلی اینجا character consistency یا ثابت نگه داشتن چهره‌ها در شات‌های مختلفه که با ابزارهای جانبی مثل IP-Adapter حل شده تا هویت بصری کاراکترها در تمام کلیپ حفظ بشه.

این صرفاً خروجی خام یه مدل text-to-video نیست؛ نتیجه‌ی یک pipeline کامله. اول کلیپ‌ها تولید شدن، بعد چهره‌ها ثابت شدن و در نهایت پست-پروداکشن سنگین با افکت‌های ویژه ماتریکس، اصلاح رنگ و صداگذاری انجام شده.

🛠 Join @LLMEngineers Community

پارت 2
درباره فاین‌تیون مدل gpt-oss
ساخته شده با notebooklm

🛠 Join @LLMEngineers Community

چندتا مدل جدید تو هفته‌های اخیر ریلیز شده که هرکدوم یه گوشه از بازار رو هدف گرفتن. تمرکز اصلی روی بهینه‌سازی، قابلیت‌های ایجنتی (agentic) و مدیریت context طولانی هست.

مدل DeepSeek-V3.1

این مدل یه معماری هیبریدی داره که دو حالت thinking و non-thinking رو توی یه مدل واحد جمع کرده. یعنی برای تسک‌های سنگین و نیازمند استدلال، از حالت thinking استفاده می‌کنه که توکن بیشتری مصرف می‌کنه ولی دقت بالاتری داره و برای جواب‌های سریع، میره سراغ حالت non-thinking. این مدل ۶۷۱ میلیارد پارامتر داره که البته در هر لحظه فقط ۳۷ میلیاردش فعاله (MoE).

نکته‌ی مهمش اینه که تو بنچمارک‌های کدنویسی و ایجنت مثل LiveCodeBench و SWE-Bench به ترتیب به امتیازهای ۷۴.۸٪ و ۶۶٪ رسیده که جهش قابل توجهی نسبت به نسخه‌های قبلیه. با این حال، جامعه کاربری معتقده که توی نوشتن خلاقانه ضعیف‌تر شده و هنوز مشکل هذیان‌گویی (hallucination) توی contextهای طولانی رو داره. در کل، برای تسک‌های برنامه‌نویسی و ایجنت خیلی خوبه، ولی برای کاربردهای عمومی‌تر شاید بهترین گزینه نباشه.

مدل Command-A-Reasoning-08-2025

این مدل ۱۱۱ میلیارد پارامتری از طرف Cohere برای کاربردهای enterprise و چندزبانه (۲۳ زبان) ساخته شده. مثل DeepSeek، این مدل هم یه سوییچ برای خاموش/روشن کردن حالت استدلال (reasoning) داره تا بشه بین سرعت و دقت یه تعادل برقرار کرد.

قدرت اصلیش توی استفاده از ابزار (tool use) هست و تونسته تو بنچمارک ToolBench به امتیاز ۷۸.۴٪ برسه که برای ساخت ایجنت‌های سازمانی خیلی کاربردیه. نقطه ضعف اصلیش اما لایسنس محدودکننده‌ی اونه. برای استفاده خصوصی اوکیه، ولی برای کارهای تجاری باید پول پرداخت بشه.

مدل Seed-OSS-36B-Instruct

این مدل ۳۶ میلیارد پارامتری از ByteDance با context نیتیو ۵۱۲ هزارتایی ریلیز شده که برای یه مدل اپن‌سورس در این اندازه، فوق‌العاده‌ست. یه قابلیت جالب به اسم thinking budget داره (مشابه مدل های Gemini گوگل) که به کاربر اجازه می‌ده میزان thinking رو محدود کنه .

توی بنچمارک‌های مربوط به context طولانی مثل RULER امتیاز ۹۲.۱٪ رو گرفته و تو بنچمارک SWE-Bench هم به امتیاز ۴۸.۷٪ رسیده که نشون می‌ده برای تحلیل و کدنویسی روی پایگاه‌کدهای بزرگ گزینه‌ی خیلی خوبیه. به نظر من، این مدل برای تیم‌هایی که با داده‌های حجیم سروکار دارن یه ابزار مناسبه

مدل Grok-2

این مدل از xAI دیشب ریلیز شد، با هدف ارائه‌ی هوش خالص و جواب‌های بدون فیلتر و سانسور عرضه شده. حدود 500GB حجمشه و برای اجرا به سخت‌افزار سنگینی (حدود ۸ کارت گرافیک 40GB) نیاز داره.

توی بنچمارک‌های استاندارد مثل MMLU و HumanEval به ترتیب امتیازهای ۸۷.۵٪ و ۸۸.۴٪ رو کسب کرده و به خاطر جواب‌های مستقیم و بی‌حاشیه‌اش معروف شده. جامعه کاربری هنوز در حال مقایسه‌ش با مدل‌های آینده مثل Grok-3 هست و بحث اصلی سر اینه که آیا این مدل فقط یه نسخه‌ی post-trained هست یا یه معماری جدید.

صفحات مدل‌ها در Hugging Face:

🤗 مدلDeepSeek-V3.1

🤗 مدل Command-A-Reasoning

🤗 مدل Seed-OSS-36B-Instruct

🤗 مدل Grok-2

🛠 Join @LLMEngineers Community

مقایسه برترین LLM های اوپن سورس
🛠 Join @LLMEngineers Community

ااینم مقایسه چنتا از SLM های اوپن سورس (زیر 10b)
🛠 Join @LLMEngineers Community

آقا این مقاله یه Position Paperئه، یعنی اومده یه دیدگاه رو مطرح کنه و بگه آینده این شکلیه. خلاصه حرفش اینه که آینده‌ی ایجنت‌ها دست مدل‌های کوچیک (SLMs) هست، نه این LLMهای غول‌پیکر. استدلالش هم اینه که اکثر کارهایی که یه ایجنت می‌کنه، تکراری و تخصصیه. پس چرا برای یه کار ساده، یه مدل ۱۷۵ میلیاردی رو صدا بزنیم؟ به جاش بیایم برای هر تسک یه SLM متخصص و fine-tune شده بذاریم که هم سریع‌تره، هم ارزون‌تر. برای اون بخش‌هایی هم که نیاز به فکر کردن و استدلال عمیق داره، یه LLM رو به عنوان مغز متفکر یا orchestrator می‌ذاریم که کارها رو به SLMهای کارگر پاس بده. یه معماری heterogeneous.

دمشون گرم برای این نکته‌ها:

اقتصاد Inference رو درست فهمیدن: اینکه هزینه سرو کردن یه مدل ۷ میلیاردی ۱۰ تا ۳۰ برابر ارزون‌تر از یه مدل ۷۰ میلیاردیه، یه فکت کاملاً تجربه‌شده‌ست. وقتی نیاز به parallel کردن مدل روی کلی GPU نداری، هزینه‌های نگهداری و عملیات (operational cost) به شدت میاد پایین. اینو هرکی یه مدل رو production برده باشه با گوشت و پوستش حس کرده.

زدن تو خال با Behavioral Alignment: این یکی از بهترین نکته‌های فنی مقاله‌ست. توی سیستم‌های ایجنتیک، مدل باید یه خروجی با فرمت دقیق (مثلاً JSON) بده تا tool بعدی کار کنه. هرکی ایجنت واقعی نوشته باشه می‌دونه LLMهای بزرگ گاهی زیادی خلاق می‌شن و فرمت رو یه جوری می‌دن که کل پایپ‌لاین می‌خوابه. یه SLM که فقط برای تولید یه فرمت خاص fine-tune شده، خروجی به شدت قابل اعتمادتر و deterministicتری می‌ده. این یه درد واقعی تو مهندسی ایجنته.

ایده‌ی Data Flywheel درسته: اینکه تعاملات ایجنت بهترین منبع برای جمع‌آوری دیتا و بهبود مدل‌های آینده‌ست، یه استراتژی MLOps کلاسیک و درسته. لاگ‌هایی که از ایجنت جمع می‌شه، بهترین و تمیزترین دیتاست دنیاست برای fine-tune کردن یه SLM متخصص و این یه نکته‌ی کاملاً فنی و قابل دفاعه.

ولی خب، بریم سراغ جاهایی که مقاله زیادی خوش‌بین بوده:

الگوریتم مهاجرتشون یه شوخیه: الگوریتمی که تو بخش ۶ داده، روی کاغذ قشنگه ولی تو دنیای واقعی کابوسه. مرحله Data Curation که میگه داده‌های حساس (PII) رو با "ابزارهای اتوماتیک" پاک کنیم؟ تو محیط enterprise، این کار به شدت پرریسک و گرونه. یه اشتباه کوچیک تو این مرحله کل مدل fine-tune شده رو سمی می‌کنه و می‌تونه یه فاجعه امنیتی به بار بیاره.

پیدا کردن تسک با کلاسترینگ؟ جدی؟ اینکه بشینی با الگوریتم‌های unsupervised کلاسترینگ روی promptها، تسک‌های بیزینس رو پیدا کنی بیشتر شبیه یه پروژه‌ی دانشگاهیه تا کار واقعی. تو دنیای واقعی، تسک رو بیزینس و مدیر محصول تعریف می‌کنه، نه k-means. این بخش از مقاله خیلی از واقعیت دوره.

هزینه کل مالکیت (TCO) رو ندیدن: مقاله فقط روی هزینه‌ی inference زوم کرده، ولی هزینه‌ی کل مالکیت یه معماری با صدها SLM رو کلاً فراموش کرده. مدیریت، مانیتورینگ، آپدیت و ارزیابی این "باغ‌وحش مدل" (model zoo) یه جهنم عملیاتیه. واسه همین خیلی از شرکت‌ها ترجیح می‌دن پول API یه مدل خفن مثل GPT-4o رو بدن ولی سردرد نگهداری صدتا مدل ریز و درشت رو نداشته باشن.

ریسک Edge Caseها رو دست‌کم گرفتن: مهم‌ترین ریسک فنی که مقاله بهش وزن نداده، همین edge caseهاست. اون قدرت استدلال عمومی (general reasoning) توی یه LLM بزرگ، مثل یه safety net عمل می‌کنه. وقتی یه سناریوی پیش‌بینی‌نشده پیش میاد، LLM یه شانس برای هندل کردنش داره. ولی یه SLM که فقط روی تسک خودش ترین شده، وقتی با یه ورودی عجیب و خارج از توزیع (out-of-distribution) روبه‌رو بشه، یه شکست فاجعه‌بار می‌خوره که توی یه سیستم بیزینسی یعنی فاجعه.

به نظر من، جهت‌گیری کلی مقاله درسته؛ آینده‌ی سیستم‌های AI به سمت معماری‌های ترکیبی (heterogeneous) میره. اما این مسیر رو خیلی صاف و ساده و بدون چالش نشون داده. واقعیت اینه که پیاده‌سازی این چشم‌انداز تو مقیاس enterprise پر از چالش‌های مهندسی، MLOps و مدیریتیه که مقاله خیلی راحت از کنارشون گذشته.

🛠 Join @LLMEngineers Community

یه مدل جدید از انویدیا اومده که می‌تونه محاسبات سنگین reasoning رو با context طولانی ۱۲۸ هزار توکنی، روی یه کارت گرافیک با ۲۲ گیگ VRAM اجرا کنه. این یعنی دسترسی‌پذیری بالاتر برای تسک‌هایی که نیاز به "فکر کردن" طولانی دارن، بدون نیاز به سخت‌افزارهای فضایی.

مدل Nemotron-Nano-9B-v2 یه مدل هیبرید Mamba-Transformer هست. معماریش به این صورته که اکثر لایه‌های self-attention با لایه‌های Mamba-2 جایگزین شدن. این کار باعث شده سرعت inference و throughput مدل، مخصوصاً در سناریوهایی با ورودی و خروجی طولانی (مثلاً ورودی ۸ هزار و خروجی ۱۶ هزار توکن)، تا ۶ برابر بیشتر از مدل‌هایی مثل Qwen3-8B بشه، در حالی که دقتش رو هم حفظ کرده.

ساخت این مدل چندتا مرحله‌ی کلیدی داشته که برای ماها هم قابل استفاده‌ست:
اول یه مدل پایه ۱۲ میلیارد پارامتری (12B) روی ۲۰ تریلیون توکن با استفاده از FP8 training recipe آموزش داده شده. دیتاست عظیم و باکیفیتی هم براش ساختن، از جمله یه دیتاست ریاضی جدید به اسم Nemotron-CC-Math که میگن از پایپ‌لاین‌های قبلی خیلی بهتره.

بعد از آموزش اولیه و alignment با تکنیک‌هایی مثل SFT، DPO، GRPO و RLHF، مدل اصلی رو با یه استراتژی هوشمندانه فشرده کردن. از فریمورک Minitron برای pruning استفاده شده. توی این فرآیند، هم لایه‌های کامل (depth) و هم ابعاد FFN و embedding (width) رو هرس کردن تا مدل از ۱۲ میلیارد به ۹ میلیارد پارامتر برسه و توی حافظه‌ی 12 گیگی A10G جا بشه.

برای اینکه افت دقت ناشی از pruning جبران بشه، از knowledge distillation استفاده شده. یعنی مدل ۱۲ میلیاردی به عنوان "معلم"، دانشش رو به مدل ۹ میلیاردیِ "شاگرد" منتقل کرده تا دقتش بازیابی بشه.

یه نکته‌ی جالب دیگه در فاز alignment، استفاده از model merging بوده. دوتا checkpoint مختلف که یکی در reasoning و دیگری در chat قوی‌تر بوده رو با هم ترکیب کردن (interpolation) تا به یه تعادل مناسب بین این دو قابلیت برسن. همچنین یه قابلیت budget control برای "فکر کردن" مدل پیاده‌سازی کردن که به کاربر اجازه می‌ده مشخص کنه مدل قبل از دادن جواب نهایی، چند توکن برای خودش تحلیل بنویسه.

رسما اومدن بهترین تکنیک‌ها رو یاهم ترکیب کردن!

انویدیا هم مدل‌های 9B و 12B-Base و هم بخش بزرگی از دیتاست‌های pre-training و post-training رو به صورت متن‌باز منتشر کرده.

📃 مقاله فنی Nemotron Nano 2

🛠 Join @LLMEngineers Community

مایکروسافت یه مدل Text-to-Speech جدید و open-source به اسم VibeVoice داده که تمرکزش روی حل مشکلات مدل‌های فعلیه. این مدل برای ساختن محتوای صوتی طولانی مثل پادکست و کتاب صوتی که چند نفر توش صحبت می‌کنن، عالیه.

برتری‌ها و ویژگی‌های کلیدیش نسبت به بقیه اینه:

۱. تولید صدای خیلی طولانی: بزرگترین مزیتش اینه که می‌تونه تا ۹۰ دقیقه صدای پیوسته تولید کنه. مدل‌های دیگه معمولاً برای متن‌های کوتاه خوبن و توی محتوای طولانی به مشکل می‌خورن، اما VibeVoice برای یه اپیزود کامل پادکست طراحی شده.

۲. پشتیبانی از چند گوینده: می‌تونه مکالمه بین حداکثر ۴ نفر رو با صدای متفاوت و طبیعی شبیه‌سازی کنه. دیگه لازم نیست صدای هر کس رو جدا بسازی و به هم بچسبونی؛ مدل خودش جریان و نوبت‌دهی صحبت رو مدیریت می‌کنه تا حس یه گفتگوی واقعی رو بده.

۳. کیفیت صدای بالاتر از رقبا: توی مقایسه‌هایی که انجام شده، کیفیت صدای VibeVoice توی معیارهایی مثل "طبیعی بودن" و "غنی بودن حس صدا" از مدل‌های خیلی قوی و تجاری مثل Gemini 2.5 گوگل و ElevenLabs هم بهتر بوده.

۴. کارایی بالا: یه تکنیک هوشمندانه برای فشرده‌سازی صدا داره. این باعث می‌شه بتونه حجم عظیمی از صدا رو با سرعت بالا پردازش کنه بدون اینکه کیفیت خراب بشه. این همون راز تواناییش در تولید محتوای ۹۰ دقیقه‌ایه.

به نظر من، VibeVoice یه ابزار خیلی قدرتمند برای تولیدکننده‌های محتواست. تا امروز ساختن یه پادکست چند نفره‌ی باکیفیت از روی متن، تقریباً غیرممکن یا خیلی پرهزینه بود. این مدل این کار رو به شکل open-source در دسترس قرار داده و می‌تونه استاندارد جدیدی برای محتوای صوتی تولید شده با هوش مصنوعی تعریف کنه.

البته این مدل فعلاً فقط برای کارهای تحقیقاتی منتشر شده و مایکروسافت برای جلوگیری از سوءاستفاده و ساخت deepfake، یه پیام صوتی کوتاه که میگه "این صدا با هوش مصنوعی ساخته شده" و یه واترمارک نامرئی به تمام خروجی‌ها اضافه کرده.

📃 گزارش فنی VibeVoice

💻 صفحه پروژه و کد

🛠 Join @LLMEngineers Community