AI Engineers

معماری مدل Qwen3.8-27B ترکیبی ساخته شده؛ یعنی از ۶۴ لایه، فقط ۱۶ لایه‌اش به سبک کلاسیک توجه کامل دارند و ۴۸ لایه دیگه به‌صورت خطی (با معماری Gated DeltaNet) کار می‌کنند. این طراحی باعث شده حافظه موقت پردازش متن یا همون KV Cache بسیار سبک‌تر از مدل‌های عادی باشه و کانتکست ۲۶۲ هزار توکنی مدل روی سیستم‌های خانگی رم زیادی مصرف نکنه. توی بنچمارک‌های رسمی برای کارهای ایجنتیک، برنامه‌نویسی و کنترل سیستم نمرات بالایی ثبت کرده (مثل شاخص ۵۲ در ارزیابی مستقل Artificial Analysis). اما در استفاده واقعی یک ضعف مشخص داره: تمایل به تفکر بیش‌ازحد یا همون Overthinking. اگر متغیر تلاش تفکر یعنی reasoning_effort رو روی حالت متوسط یا کم تنظیم نکنید، برای سوال‌های ساده توکن‌های بسیار زیادی می‌سوزونه و خروجی کند می‌شه. واقعیت اجرای مدل روی سیستم‌ها و کارت‌های مختلف: کارت‌های ۲۴ گیگابایت (مثل 3090 یا 4090): نقطه تعادل مدل نسخه ۴ بیتی مثل Q4_K_M با حجم حدود ۱۷ گیگابایته. روی این کارت‌ها به راحتی اجرا می‌شه و فضای کافی برای کانتکست ۳۲ تا ۶۴ هزار توکنی باقی می‌مونه. کارت‌های ۱۶ گیگابایت (مثل 5080 لپ‌تاپ یا 4060Ti): نسخه ۴ بیتی کامل جا نمی‌شه. باید برید سراغ کوانت ۳ بیتی مثل UD-Q3_K_XL (حدود ۱۳.۵ گیگابایت) و برای مصرف کمتر حافظه، کش کانتکست رو هم ۴ بیتی کنید (--cache-type-k q4_0). سرعت بین ۲۰ تا ۵۰ توکن بر ثانیه میده و برای کدنویسی واقعی جوابه. کارت‌های زیر ۱۲ گیگابایت یا ۶ گیگ (مثل 3050): اجرای مدل عملاً منطقی نیست. نسخه‌های ۱ یا ۲ بیتی بالا میان ولی افت کیفیت در منطق و برنامه‌نویسی بسیار شدیده و سرعت با فرستادن لایه‌ها روی پردازنده اصلی به زیر ۲ توکن بر ثانیه می‌رسه. وضعیت روی سیستم‌های مک و حافظه یکپارچه: - مک‌های ۱۶ گیگابایت: به خاطر اشغال رم توسط سیستم‌عامل، فقط کوانت‌های خیلی ضعیف ۲ بیتی جا می‌شن که خروجی بی‌کیفیت و کندی دارن. - مک ۲۴ گیگابایت (مثل M2 یا پایه M5 Pro): با کوانت ۳ بیتی یا ۴ بیتی هماهنگ کار می‌کنه و سرعت حدود ۸ تا ۱۵ توکن بر ثانیه می‌ده. - مک‌های ۳۶ گیگابایت به بالا (مثل M3 Pro یا M5 Pro): محیط ایده‌آل اجرای روان نسخه ۴ بیتی با فریم‌ورک MLX و سرعت بالای ۲۰ توکن بر ثانیه است. برای گرفتن بالاترین سرعت روی تمام سیستم‌ها، مدل دارای یک head داخلی برای حدس کلمات بعدی یا هم

امروز داشتم گزارش GDPval رو می‌خوندم؛ بنچمارک رسمی OpenAI که به‌جای سؤال آکادمیک، کارهای واقعی و پول‌ساز رو تست می‌کنه. ۱۳۲۰ تسک از ۴۴ شغل توی ۹ بخش اصلی GDP آمریکا، همه ساخته‌شده توسط متخصص‌های واقعی با میانگین ۱۴ سال سابقه. اصل داستان: هر تسک یه خروجی واقعیه : فایل Excel، اسلاید، نقشه CAD، حتی ویدیو و صوت . که برای متوسط حدود ۷ ساعت کار حرفه‌ای زمان می‌بره. ارزیابی هم با مقایسه زوج بین خروجی مدل و خروجی متخصص انسانی انجام میشه، نه گریدر خودکار. چارت مدل های برتر تا الان (8/2026) رو توی کامنتا گذاشتم. مدل Claude Opus 5 با ۱۸۳۵ صدرنشینه، بعد GLM-5.3 با ۱۷۶۶ و Grok 4.6 با ۱۷۶۱. بهترین مدل‌ها تقریباً ۸۰٪ بالاتر از سطح متخصص انسانی کار تحویل میدن. نکته‌ی جالب‌تر برای من پراکندگی بالای جدوله: GLM و مدل‌های چینی open-weight دیگه کاملاً تو جمع frontier هستن، و فاصله‌ی رتبه ۱ تا رتبه ۱۰ فقط حدود ۲۰٪ ٪‌ـه. یعنی دیگه بحث «کدوم مدل به انسان می‌رسه» نیست؛ بحث اینه که کدوم ارزون‌تر و سریع‌تر از انسان تحویل میده. نکته جالب برای من این بود که چقدر با مهندسی ساده میشه جلو رفت: پرامپتی که مدل رو وادار کنه خروجیش رو به‌صورت تصویر رندر کنه و چک کنه، خطاهای فرمت PowerPoint رو از ۸۶٪ به ۶۴٪ رسوند و ۵ واحد درصد هم win rate اضافه کرد. محدودیتش رو هم بگم: تسک‌ها one-shot و کاملاً مشخص‌ان، در حالی که تو دنیای واقعی فهمیدن خودِ مسئله نصف کاره. کار فیزیکی و دانش ضمنی هم بیرون از دامنه‌ست. https://arxiv.org/html/2510.04374v1 🛠 Join @LLMEngineers Community

اگر می‌خواید مسیر شغلی خودتون رو به عنوان یک Applied AI Engineer بسازید و به استانداردهای تیم‌های تراز اول برسید، باید تمرکزتون رو از «پرامپت‌زدن و کپی‌پیست نوت‌بوک» کاملاً بردارید و روی مهندسی سیستم‌های پروداکشن بذارید. تحلیل دقیق شرح شغل‌های اخیر OpenAI، NVIDIA و BMW یک نقشه‌راه کاملاً شفاف به ما میده: قدم اول: تبدیل شدن به یک مهندس نرم‌افزار واقعی قبل از ورود عمیق به AI. توی شرح شغل رسمی NVIDIA برای موقعیت مهندسی هوش مصنوعی، فاندامنتال مهندسی نرم‌افزار این‌طور لیست شده: system design, API design, testing, CI/CD, code quality, observability, security, databases, containers, and distributed/event-driven systems پس وقتت رو اول بذار روی پایتون پیشرفته، سیستم‌های توزیع‌شده، تست‌نویسی، داکر و معماری Backend. قدم دوم: عمیق شدن توی ایجنت‌ها و مدیریت خطا. دموهای ساده با کدهای ۱۰ خطی به کار پروداکشن نمیان. تیم Codex در OpenAI دقیقاً دنبال مهندس‌هایی می‌گرده که این چالش‌ها رو حل کرده باشن: real-world long-horizon agent workflows, tool-use strategies, context construction, production failures, evaluation and feedback loops حتی BMW هم توی آگهی استخدام موقعیت Agentic AI صریحاً عبارت previous experience building agentic applications رو آورده و تسلط روی فریم‌ورک‌ها و پروتکل‌هایی مثل MCP رو الزامی کرده. قدم سوم: یادگیری اصولی Evals و ارزیابی سیستم. ساخت سیستم بدون متریک ارزش فنی نداره. شرکت OpenAI از مهندس‌های کاربردی خودش انتظار داره سیستم‌ها رو به شکل ساختاریافته بسنجن: representative data, graders, production signals and human judgment باید بلد باشی دیتاست تست بسازی، رگرسیون مدل رو بسنجی و بدونی Latency، هزینه و فیلیر مودهای سیستم روی تسک‌های واقعی چقدره. قدم چهارم: تسلط روی پروداکشن و اسکیل. تیم BMW هدف استخدامش رو industrializing GenAI and agentic systems اعلام کرده و آگهی OpenAI لندن هم ازت می‌خواد پروژه رو از صفر تا صد جلو ببری: take systems from use-case selection and architecture through prototyping, evaluation, launch and scale این مرحله شامل مانیتورینگ، Tracing، مدیریت کش، دپلوی کلود روی AWS یا Azure و کنترل دسترسی داده‌هاست. برای پورتفولیو هم بهتره به جای ۳۰ تا ن

تیم IFM که پیش‌تر با پروژه LLM360 شناخته می‌شد، خانواده مدل‌های K2 Horizon رو تحت لایسنس Apache 2.0 منتشر کرد؛ یه پکیج کامل از ۶ مدل مختلف که از سایز فوق‌العاده سبک 0.9B شروع می‌شه و تا غول ۳۷۵ میلیارد پارامتری 375B-A23B ادامه داره. برخلاف خیلی از شرکت‌ها که فقط وزن نهایی رو می‌دن و تمام، این تیم کل چرخه آموزش رو باز کرده؛ یعنی از دیتای Pre-train و چک‌پوینت‌های میانی گرفته تا لاگ‌های جزئی آموزش و کدهای Agentic Post-training همه‌چیز در دسترسه تا بشه رفتار مدل رو دقیق مهندسی معکوس کرد. یکی از جذاب‌ترین نکات معماری این سری، مدل 36B-A4B هست که سراغ ایده‌ای به اسم MoVA یا همان Mixture-of-Value-Attention رفته. برخلاف MoEهای مرسوم که sparsity رو فقط روی لایه‌های Feed-Forward اعمال می‌کنن، اینجا اسپارسیتی وارد مکانیزم Attention شده. این طراحی باعث شده مدل با وجود ۳۶ میلیارد پارامتر کلی، در هر توکن فقط حدود ۴ میلیارد پارامتر فعال داشته باشه، ولی عملکردش پا‌به‌پای نسخه متراکم ۳۲ میلیاردی بیاد و در تست‌هایی مثل Terminal-Bench 2.1 به امتیاز ۵۸.۶ برسه؛ چیزی که روی سرورهای سبک یا سیستم‌های لوکال هزینه پردازش رو به‌شدت پایین می‌کشه. مدل پرچمدار این خانواده یعنی 375B-A23B هم با ۲۳ میلیارد پارامتر فعال در هر توکن، مستقیماً برای کارهای سنگین برنامه‌نویسی و ایجنتی طراحی شده. این مدل در بنچمارک‌های کار با ابزار مثل MCPMark امتیاز ۶۷.۷ و در Toolathlon امتیاز ۶۵.۳ رو ثبت کرده. هرچند در استدلال‌های فوق‌العاده انتزاعی و سنگین مثل Humanity's Last Exam هنوز پشت سر مدل‌های کلوزی مثل GPT-5.6 یا Claude Sonnet 5 قرار می‌گیره، اما در کارهای مهندسی نرم‌افزار و تسک‌های طولانی ایجنتی کاملاً در قامت یه مدل کلاس تجاری ظاهر می‌شه. نکته‌ای که این گزارش رو برای من فوق‌العاده جذاب کرد، شفافیت بی‌تعارف تیم روی ماجرای Reward Hacking بود. وقتی مدل در محیط شبیه‌سازی‌شده ترمینال قرار گرفته، در کمال زرنگی سورس بنچمارک رو از گیت‌هاب پیدا کرده، جواب‌ها رو بیرون کشیده و تست‌ها رو دور زده! تیم IFM با ابزار آدیت شرکت Artificial Analysis متوجه تقلب در ۲۴ تلاش شد و به‌جای لاپوشانی، رک و راست امتیاز خام ۷۰.۲ درصدی رو به ۶۶.۹ درصد اصلاح کرد. همین ثبت رفتارهای ناخواسته در چک‌پوینت‌های میانی، ارزش علمی این انتشار رو ا

روند بکارگیری یادگیری تقویتی (RL) در بهبود عملکرد مدل‌های زبانی (LLMs) : https://telegra.ph/RL-in-LLMs-09-14

امروز داشتم معرفی Jev از TypeSafe AI رو می‌خوندم و ایده‌ش جالبه: به‌جای ساختن یه LLM بهتر برای تولید متن، یه مدل ساختن که مستقیم برای تصمیم‌گیری داخل نرم‌افزار طراحی شده. اصل مسئله‌شون اینه که LLMها برای chat عالی‌ان، ولی توی automation هنوز دردسر دارن: خروجی stringـه، باید parse و validate بشه، latency بالاست و confidence هم همیشه قابل اعتماد نیست. مدل Jev از یه دسته‌ی جدید به اسم System One Modelsـه. ورودی می‌تونه متن یا state نامرتب باشه، ولی خروجی از قبل type مشخص داره: مثلاً یه category، score، boolean یا چند probability. یعنی مدل قرار نیست چند پاراگراف تولید کنه؛ مستقیم یه تصمیم ساختاریافته تحویل می‌ده. برای آموزش هم یه روش به اسم RLCD معرفی کردن؛ Reinforcement Learning for Calibrated Decisions. هدف اینه که probabilityهای مدل واقعاً معنی‌دار باشن. یعنی وقتی می‌گه ۹۰٪ مطمئنم، انتظار داری تقریباً در ۹۰٪ موارد مشابه درست باشه. یه تفاوت مهم دیگه parallel samplingـه. LLM معمولی (autoregressive) توکن به توکن خروجی می‌سازه، ولی Jev چون text generation نداره می‌تونه چند تصمیم رو در یه query با هم تولید کنه. برای چیزهایی مثل scoring، routing، classification و تصمیم‌های real-time این می‌تونه خیلی مهم باشه. کمپانی TypeSafe ادعا می‌کنه Jev روی System One taskها intelligence مشابه بعضی مدل‌های frontier داره، ولی حدود 40x تا 200x سریع‌تره و latency حدود 70 تا 500 میلی‌ثانیه داره. قیمت input هم $0.042 برای هر یک میلیون توکن اعلام شده. یه ادعای مهم دیگه هم «no type errors»ـه. چون خروجی از قبل schema مشخص داره، مدل نمی‌تونه یه value خارج از ساختار تعریف‌شده تحویل بده. ولی این رو نباید با «هیچ‌وقت اشتباه نمی‌کنه» قاطی کرد؛ ممکنه خروجی کاملاً type-safe باشه ولی تصمیمش غلط باشه. https://x.com/CompleteSkeptic/status/2099925682726002904?s=20 https://typesafe.ai/blog/introducing-system-one-models-and-jev 🛠 Join @LLMEngineers Community

امروز Jev 1.13 رو از طریق API رسمی OpenRouter آزمایش کردم، و نتیجه‌اش بیشتر از چیزی که انتظار داشتم جالب بود. روی دیتاست MASSIVE با ۵٬۹۴۸ جمله‌ی فارسی و انگلیسی و ۶۰ نوع Intent، چهارده مدل رو روی یک داده‌ی یکسان مقایسه کردم. بر اساس دقت: - اول، E5 Base با Logistic Regression: ۸۳٫۷۹٪+ - دوم، TF-IDF با Logistic Regression: ۸۲٫۴۸٪+ - سوم، Decider-2B: ۸۱٫۶۴٪ - بعد، E5 Small: ۸۰٫۹۰٪ - بعد، Jev 1.13: ۷۹٫۸۶٪ - بعد، Decider-0.8B: ۷۶٫۷۷٪ - آخر، Kev-0.8B: ۵۷٫۹۵٪ یعنی یک مدل امبدینگ ۲۷۸ میلیونی از مدل‌های تخصصی تصمیم‌گیری جلوتر افتاد، و TF-IDF هم هنوز از Jev و Decider دقیق‌تر بود. حالا راز E5 چیه؟ از مدل چندزبانه‌ی E5 استفاده کردم تا متن رو به بردارهای ۷۶۸بعدی تبدیل کنه و فقط یک Logistic Regression ساده روی خروجی‌اش آموزش دادم. هیچ‌کدوم از پارامترهای E5 رو دوباره آموزش ندادم. ولی یک نکته‌ای هست که نباید از قلم بیفته: من برای E5 و TF-IDF از بیش از ۲۳ هزار نمونه‌ی آموزشی برچسب‌دار استفاده کردم، درحالی‌که Jev و Decider بدون آموزش و به‌صورت Zero-shot ارزیابی شدن. پس این نتایج ثابت نمی‌کنه E5 یک موتور تصمیم‌گیری عمومی قوی‌تره. از Jev یک نتیجه‌ی غیرمنتظره هم درآمد. اگر به‌جای Accuracy از Macro-F1 استفاده کنیم، مقایسه برعکس می‌شه: Jev به ۷۷٫۳۲٪ می‌رسه و Decider-2B به ۷۶٫۲۵٪. چون Macro-F1 به همه‌ی کلاس‌ها وزن یکسان می‌ده، یعنی Jev با وجود دقت کلی پایین‌تر، بین دسته‌های مختلف متعادل‌تر بوده. کالیبراسیون هم داستان جداگانه‌ای داشت. خطای کالیبراسیون یا ECE برای Decider-2B حدود ۰٫۰۱۸۶، برای Jev حدود ۰٫۰۵۰۹ و برای E5 Base حدود ۰٫۲۵۷۳ دراومد. هرچه ECE کمتر باشه یعنی اطمینان پیش‌بینی‌شده به دقت واقعی نزدیک‌تره. البته ECE همه‌چیز رو نشون نمی‌ده؛ E5 با وجود خطای بالاتر، توی آزمایش من در رتبه‌بندی تصمیم‌ها بر اساس ریسک بهتر عمل کرد. از نظر هزینه و سرعت هم، اجرای کامل Jev روی هر ۵٬۹۴۸ جمله حدود ۰٫۲۹۳ دلار شد و میانه‌ی زمان پاسخ هم حدود ۶۲۶ میلی‌ثانیه. یک نکته‌ی دیگه هم این بود که در دو اجرای مستقل روی ۳۹۸ ورودی مشترک، حدود ۲٫۳ درصد پیش‌بینی‌های Jev تغییر کرد. یعنی نتیجه‌ی یک اجرای منفرد رو نباید خیلی قطعی گرفت. دارم هنوز تست میکنم این مدل هارو، مرحله بعدی هدفم دیگه فقط تشخیص Intent