همیشه دوست داشتم یه مدل به درد بخور رو لوکال بالا بیارم ولی محدودیت VRAM واقعاً روی اعصاب بود (کارت گرافیک RTX 3050 با ۶ گیگابایت حافظه VRAM )
قبلاً حتی فکر کردن به لود کردن Qwen3.6-27B روی چنین سخت‌افزاری شبیه شوخی بود، اما نسخه 1-bit مدل جدید Bonsai 27B که کلاً ۳.۹ گیگابایت فضا می‌گیره رو انداختم توی LM Studio و خیلی راحت روی کارت نشست و حتی مقداری فضا برای کانتکست باقی موند...

بررسی ساختار این مدل نشون میده که چطور به این حجم رسیدن... برخلاف اکثر روش‌های کوانتیزیشن رایج که فقط بخشی از وزن‌ها رو فشرده می‌کنن و بخش‌های حساس مثل embeddings یا attention projections رو دست‌نخورده می‌ذارن، تکنولوژی Bonsai به صورت کاملاً end-to-end تمام لایه‌ها رو فشرده می‌کنه... توی مدل‌های معمولی اگه زیر ۴ بیت بریم مدل کلاً متلاشی می‌شه و رفتارهای منطقی خودش رو از دست میده، اما این پروژه وزن‌ها رو بر پایه یک فریم‌ورک ریاضیاتی دقیق به فرمت‌های فوق فشرده تبدیل کرده... نسخه Ternary این مدل با وزن‌های {-1, 0, +1} و یک اسکیل FP16 به ازای هر ۱۲۸ وزن، کلاً ۱.۷۱ بیت به ازای هر وزن مصرف می‌کنه (حدود ۵.۹ گیگابایت)... نسخه ۱ بیتی هم فقط از وزن‌های {-1, +1} استفاده می‌کنه که حجم نهایی رو به ۱.۱۲۵ بیت یعنی حدود ۳.۹ گیگابایت می‌رسونه... این یعنی عملاً امکان اجرای یک مدل کلاس ۲۷ میلیاردی روی گوشی‌های موبایل با رم محدود هم فراهم شده...

مسئله بعدی که معمولاً اجرای لوکال رو غیرممکن می‌کنه، حجم عظیمی هست که KV cache در کانتکست‌های طولانی اشغال می‌کنه... خوشبختانه معماری پایه Qwen3.6 به صورت hybrid-attention طراحی شده؛ یعنی فقط ۱۶ لایه از ۶۴ لایه اون به صورت full-attention کار می‌کنن و بقیه لایه‌ها ساختار linear-attention دارن که حافظه ثابتی می‌خواد... این باعث می‌شه حجم کش مدل از همان ابتدا ۴ برابر کوچک‌تر از مدل‌های متراکم عادی باشه... علاوه بر این، مدل‌های Bonsai مقاومت عجیبی در برابر کوانتیزیشن ۴ بیتی KV cache دارن... آزمایش‌های forward-KL divergence نشون میده که افت کیفیت ناشی از فشرده‌سازی کش در این مدل بسیار کمتر از مدل‌های عادیه... با فعال کردن کش ۴ بیتی، حافظه مورد نیاز برای کانتکست ۱۰۰ هزار توکنی در نسخه ۱ بیتی به حدود ۶.۸ گیگابایت کاهش پیدا می‌کنه که برای اجرا روی لپ‌تاپ‌های معمولی فوق‌العاده‌ست...

پیاده‌سازی این کار به کرنل‌های کاستوم نیاز داره تا سخت‌افزار بتونه وزن‌های کم‌بیت رو مستقیماً بدون نیاز به expand کردن در حافظه پردازش کنه... توسعه‌دهنده‌ها این مسیرها رو روی MLX برای محصولات اپل و CUDA برای کارت‌های انویدیا آماده کردن... همچنین برای افزایش سرعت تولید توکن، یک لایه درفت اختصاصی به اسم DSpark همراه مدل ارایه شده که به روش speculative-decoding سرعت خروجی رو روی کارت‌های انویدیا تا ۳۷ درصد بیشتر می‌کنه... البته طبق گزارش‌ها، سیستم‌های Apple Silicon در پردازش‌های batch size 1 هنوز امکان استفاده بهینه از DSpark رو ندارن و این ویژگی اونجا فعلاً کارایی خاصی نداره...

ارزیابی‌ها نشان میدن که در حالت تفکر یا همان thinking mode، نسخه ۱ بیتی حدود ۹۰ درصد و نسخه ternary نزدیک ۹۵ درصد از کارایی مدل اصلی رو حفظ می‌کنن... برتری بزرگ Bonsai در حفظ رفتارهای عمیق مثل حل مسائل ریاضی، ساختار زنجیره تفکر و نوشتن کدهای برنامه‌نویسی در لایه‌های زیر ۲ بیته... جایی که کوانتیزیشن‌های معمولی مثل IQ2_XXS کاملاً شکست می‌خورن...

دیدن بنچمارک‌های جدید مدل ۱ بیتی Bonsai 27B واقعاً آدم رو به آینده پردازش لوکال امیدوار می‌کنه... نسخه 1-bit این مدل با حجم ناچیز ۳.۹ گیگابایتی توی تست‌های فوق سخت ریاضی مثل AIME 2025 و بنچمارک کدنویسی LiveCodeBench پایاپای با GPT-5 Low رقابت کرده و حتی با اختلاف جزئی جلو زده... این یعنی منطق محاسباتی سنگین بالاخره راهش رو به دستگاه‌های کوچک و جیبی باز کرده...

جالب‌تر اینکه توی رقابت با مدل معروف GPT-4o، این مدل کم‌حجم برتری خودش رو توی بنچمارک‌های کلیدی مثل MATH-500، ارزیابی‌های ایجنتی τ²-Bench و تست‌های دستوری IFBench ثابت کرده... داشتن چنین سطحی از هوش بدون نیاز به سرورهای ابری و به صورت کاملاً آفلاین، دست ما رو برای ساخت پروژه‌های شخصی و ابزارهای کاربردی بازتر می‌کنه... با اینکه هنوز محدودیت‌هایی داره، اما یک شروع فوق‌العاده برای نسل جدید مدل‌های لوکاله...


https://huggingface.co/prism-ml

🛠 Join @LLMEngineers Community

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

معماریش یه هیولای ۹۵۲ میلیارد پارامتریه که حدود ۴۱ میلیاردش تو هر توکن اکتیوه. یعنی عملا ۱۶ تا کارت H200. حتی نسخه کوانتایز شده NVFP4 هم ۶۰۰ گیگ مموری می‌خواد. پس عملا اجرای لوکالش واسه ماها قفله و باید از همون سرویس Tinker خودشون یا پرووایدرهای دیگه استفاده بشه.

بچه‌های تیم سازنده‌ش که اکثرا از OpenAI اومدن بیرون، تصمیم جالبی واسه اسکیل کردن گرفتن. برگشتن سمت muP یا همون Maximal Update Parametrization. چند وقت پیش یه پیپر می‌خوندم که نشون می‌داد واسه مدل‌های بالای یک تریلیون پارامتر، این روش چطور پایداری ترینینگ رو تضمین می‌کنه. ۴۵ تریلیون توکن دیتای آموزشی به خورد مدل داده شده که تو فضای اوپن‌‌ها یه عدد عجیبه.

چیز عجیبی که تو معماری attention دیده میشه، ترکیبش با کانولوشنه. به علاوه اینکه اومدن weight decay رو با learning rate گره زدن. قطعا یه دلیل بهینه‌سازی پشتش بوده ولی به شدت وابسته به ستاپ کاستوم خودشونه. از اون طرف، تو بحث پردازش تصویر، از یه انکودر پچ سلسله‌مراتبی استفاده شده و صدا هم به صورت توکن‌های گسسته درمیاد. این یکپارچگی روی درک کدهای پیچیده و تسک‌های reasoning تاثیر مثبت گذاشته.

🛠 Join @LLMEngineers Community

چیزی که تو معماریش واسم جالب بود بحث Continuous Reasoning Effort هست. جای اینکه مثل بقیه مدل‌ها فقط چند تا مود ثابت واسه ریزونینگ داشته باشه، یه پارامتر بین صفر و یک می‌گیره. من رو ۰.۷ تنظیمش کردم واسه تسک‌های روتین، و فقط وقتی می‌خوام یه کد پیچیده رو دیباگ کنه می‌ذارمش رو ۰.۹۹. اینطوری هم توکن کمتری مصرف می‌شه هم سرعت ریسپانس خیلی بالاتره، چون مدل مجبور نیست رو سوال‌های ساده پردازش الکی انجام بده.

واسه فاین‌تیون کردنش هم داکیومنت‌های پلتفرم Tinker یه سری دیتای خوب داده که به درد پروژه‌های دیگه هم می‌خوره. نوشتن اگه می‌خواید رو این مدل‌های اسپارس MoE لورا بزنید، فقط تارگت کردن لایه‌های اتنشن جواب نمیده. باید وزن‌های LoRA رو روی تمام ماتریکس‌ها، از جمله MLP و خود لایه‌های MoE اعمال کنید. رنک دیفالت رو ۳۲ پیشنهاد دادن و گفتن لرنینگ ریت رو حدود ۱۰ برابر زمانی بذارید که دارید فول‌فاین‌تیون می‌کنید. این ستاپ واسه SFT و حتی RL روی دیتای کاستوم بهترین نتیجه رو داده.

واقعیتش مدلی که من منتظرشم این نسخه ۹۷۵ میلیاردی نیست. تو پیش‌نمایش‌هاشون حرف از Inkling-Small زدن که کلا ۲۷۶ میلیارد پارامتر داره و فقط ۱۲ میلیاردش تو هر توکن اکتیوه. بنچمارک‌هاش تو پردازش صدا و ریکوئست‌های ایجنتیک تقریبا هم‌سطح برادر بزرگترشه ولی هنوز وزن‌هاش رو پابلیک نکردن...

گزارش کامل وضعیت ساپورت نرم‌افزاری و بررسی بنچمارک‌های نسخه کوچیکتر:
https://thinkingmachines.com/inkling-technical-ecosystem

🛠 Join @LLMEngineers Community

مدل Kimi K3 معرفی شد. و توی سایت در دسترسه
kimi.com

کمپانی Moonshot AI تیزر رسمی این مدل رو منتشر کرده و به نظر می‌رسه قراره یکی از جدی‌ترین مدل‌های متن‌باز امسال باشه.
گویا میگن 3T پارامتر داره 1M کانتکس و قدرتش در حد Opus و حتی بالاتره.
هنوز بنچمارک‌ها و جزئیات کامل منتشر نشده، ولی احتمالاً به‌زودی رقابت جذاب‌تری بین مدل‌های متن‌باز و بسته خواهیم دید.

منتظر نتایجش هستم 👀

اگه میتونستم هر career ای دلم میخواد انتخاب کنم، حوزه مورد علاقم post-train و benchmarks design می بود، هم در سطح research هم پروداکشن
لعنتی خیلی جذابه

Boom 💣

مفهوم Agent Harness یا Harness Engineering یکی از اون اصطلاحاتیه که این روزها زیاد شنیده می‌شه، اما چون هم خیلی کلیه و هم خیلی تخصصی، خیلیا هنوز دقیقاً نمی‌دونن چیه. در ساده‌ترین تعریف، خیلیا فکر می‌کنن Harness فقط همون محیط (Environment) اجرای ایجنت هست، اما داستان خیلی عمیق‌تر از این حرف‌هاست.

برای درک بهتر، باید مسیر تکامل تعامل با مدل‌ها رو ببینیم:

۱. سال ۲۰۲۳ و Prompt Engineering:
اوایل که ChatGPT اومد، با Context Window محدود (۴۰۹۶ توکن) درگیر بودیم. تمام تلاشمون این بود که با نوشتن پرامپت‌های بهتر، خروجی دقیق‌تری بگیریم. اما برای کارهای پیچیده اصلاً کافی نبود.

۲. سال ۲۰۲۴ و Context Engineering:
اینجا ابزارهایی مثل RAG، Tool Calling و پروتکل‌هایی مثل MCP وارد شدن. هدف این بود که کانتکست مدل رو بهتر مدیریت کنیم تا ایجنت بتونه به دیتابیس یا فایل‌های خاص دسترسی داشته باشه. اما یک مشکل بزرگ وجود داشت: وقتی تسک‌ها طولانی می‌شد (مثلاً ۱۰-۱۲ ساعت کار مداوم)، کانتکست پر می‌شد و ایجنت مجبور بود اطلاعات رو خلاصه‌سازی (Summarize) کنه. این کار باعث می‌شد جزئیات فنی گم بشه، ایجنت گیج بشه و تسک‌ها رو نصفه رها کنه.

۳. ظهور Harness Engineering:
اینجاست که مفهوم Harness وارد عمل می‌شه. Harness در واقع یک لایه‌ی Orchestration بالای سر کانتکست هست. به جای اینکه ایجنت رو توی کانتکست خودش غرق کنیم، اون رو وارد یک Loop (حلقه) منظم می‌کنیم.

ساختار کار در Harness معمولاً به این شکله:
* ابتدا یک فایل نیازمندی‌های دقیق (PRD) تولید می‌شه.
* این فایل به تسک‌های ریز در قالب JSON شکسته می‌شه.
* ایجنت در هر تکرار (Iteration) از حلقه، فقط روی یک تسک مشخص تمرکز می‌کنه.
* در شروع هر مرحله، ایجنت یک کانتکست کاملاً تازه و تمیز (Fresh Context) دریافت می‌کنه، اما با قوانین (Rules) سخت‌گیرانه‌ای که از قبل براش تعریف شده.

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

نمونه‌های عملی این رویکرد رو می‌شه توی دموی اخیر Anthropic دید. حتی Cursor با معرفی Cloud Agents و قابلیت تعریف Automation برای آپدیت خودکار کدبیس، عملاً داره به سمت Harness Engineering حرکت می‌کنه. در این حالت، شما حتی لازم نیست IDE باز باشه؛ ایجنت توی کلاود طبق تسک‌های تعریف شده کار می‌کنه، کد می‌زنه، تست می‌کنه و در نهایت Pull Request رو براتون می‌فرسته.

در واقع قدرت واقعی ایجنت‌های آینده نه فقط توی مدل قوی‌تر، بلکه توی Harness یا همون زیرساخت مدیریتی هست که ایجنت رو هدایت می‌کنه تا تسک‌های طولانی رو بدون افت کیفیت به پایان برسونه.

🛠 Join @LLMEngineers Community

نشستم ۲۲ تا ابزار کدزنی AI رو با هم مقایسه کردم... بحث سر Harness یا همون بستر اجرای مدله. یعنی اون سیستم مدیریت کانتکست و ابزارهایی که دور مدل کشیده شده.

خلاصه چندتا دسته‌بندی اصلی:
— اگه دنبال سرعت و تجربه تمیز توی ادیتوری: Cursor هنوز بی‌رقیبه.
— اگه گیک ترمینالی: Claude Code جادو می‌کنه.
— اگه کنترل کامل و دنیای متن‌باز رو می‌خوای: Cline و opencode رو حتماً تست کن.
— اگه می‌خوای تسک رو بسپری به ایجنت و بری سراغ کارای دیگه: Devin و Codex و Jules گزینه‌های اصلی‌ان.

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

لینک مقاله:
https://medium.com/@mshojaei77/i-compared-22-ai-coding-harnesses-most-developers-are-comparing-the-wrong-thing-4efb26650fcd

🛠 Join @LLMEngineers Community

بینا ۰.۱ ✨ 👀

پروژه Bina OCR رو کلاً یک هفته‌ست که استارت زدیم و امروز اولین بنچمارک واقعی رو ازش گرفتیم... نتیجه حتی برای خودمون هم غیرمنتظره بود. مدل Bina 0.1 توی تست‌های OCR فارسی جلوتر از مدل‌های بزرگی مثل Gemini 3.5 Flash قرار گرفت. البته این تازه اول مسیره و هنوز کلی باگ و کار زمین‌مونده داریم.

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

این پروژه با همکاری رضا سیار جلو رفته که قبلاً هم سیستم شنوا (ASR فارسی) رو توسعه داده بود. از اون دست به کیبوردهایی که کمتر حرف می‌زنن و بیشتر کد می‌زنن. (اسپویلر: پروژه بعدی هم قراره tts فارسی باشه)

واقعیت فنی اینه که ساختن یه مدل خوب، بیشتر از اینکه درگیر بازی با معماری و مدل‌های عجیب‌وغریب باشه، لنگِ داده‌ست. برای اینکه نسخه‌های بعدی Bina OCR بتونن کارهای سخت‌تر رو انجام بدن به چندتا چیز نیاز مبرم داریم: داده‌های متنوع‌تر، اسناد واقعی‌تر، دستخط‌های نامرتب و البته قدرت پردازش (compute) برای آموزش و تست.

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

نسخه اولیه مدل :
https://huggingface.co/Reza2kn/Bina-0.1
کامیونیتی تلگرام پروژه :
https://t.me/bina_ocr


🛠 Join @LLMEngineers Community

براساس این بنچمارک ما که دارای ۶,۶۶۹ خط متن تایپی و ۶,۶۶۹ صفحه متن دست نویس هست: بینا ۰.۱ در حال حاضر بهترین مدل تشخیص متن فارسی تایپی و دست نویسه! 🔥🔥

پروژه OpenBench v1 برای ارزیابی و بنچمارک دقیق ایجنت‌های کدنویسی منتشر شد... ابزاری متن‌باز که روی مقایسه و سنجش harnessها تمرکز داره.

اکثر تیم‌ها تمام تمرکز رو روی انتخاب مدل گذاشتن - اما یک ایجنت کدنویسی حاصل ترکیب مدل و harness است؛ یعنی همون ابزارهای جانبی، پرامپت‌ها، دسترسی‌ها و سیستم مدیریت اجرای اطراف مدل. وقتی مدل یکسان باشه (مثلاً gpt-5.6)، تغییر دادن harness از cursor به codex، claude یا devin می‌تونه درصد موفقیت و هزینه‌ها رو کلاً تغییر بده.

معیارهای سنجش توی این فریم‌ورک روی سه محور اصلی میچرخه: درصد درستی (correctness)، میزان مصرف token (ورودی، خروجی و cache) و تاخیر زمانی (latency)... ارزیابی‌ها هم داخل کانتینرهای ایزوله Docker اجرا میشن و صحت کد با اسکریپت‌های checker مستقل ارزیابی میشه، نه ادعای خود ایجنت.

https://github.com/minghinmatthewlam/openbench

🛠 Join @LLMEngineers Community

Explain what happens when your input exceeds the context window?