کاربرای توییتر دارن خیلی تعریف میکنن از grok 4.5
توی بعضی بنچمارک های شخصی حتی در حد fable بوده با ۹ برابر هزینه کمتر

دیتابریکس یه بنچمارک داخلی روی کدبیس چند میلیون خطی خودش زده که نتایجش برای منی که مدام درگیر چیدن پایپ‌لاین‌های Coding Agent هستم، خیلی واقعی‌تر از متریک‌های فیک SWE-bench بود... راستش همیشه فکر می‌کردیم مدل گرون‌تر یعنی نتیجه بهتر، ولی خروجی این تحقیق نشون داد قیمت Token معیار خیلی بدی برای پیش‌بینی هزینه نهایی تسکه. مدل‌های بزرگ‌تر شاید قیمت هر توکن‌شون بالا باشه، ولی چون Reasoning قوی‌تری دارن، با توکن کمتر و تعداد دفعات رفت‌وبرگشت (Turn) کوتاه‌تری تسک رو تموم می‌کنن. مثلاً Opus تو بعضی سناریوها از Sonnet ارزون‌تر تموم شده، صرفاً چون کمتر گیج زده و توکن کمتری مصرف کرده...

بحث Harness یا همون محیطی که Agent توش اجرا می‌شه هم از خود مدل مهم‌تر نباشه، کمتر نیست. دیتابریکس ابزار Pi رو با Claude Code مقایسه کرده؛ Pi چون Context رو هوشمندانه مدیریت می‌کنه و هر بار کل دیتا رو به خورد مدل نمی‌ده، هزینه‌ش گاهی تا ۵۰ درصد کمتر بوده، بدون اینکه دقتش افت کنه. یعنی اگه ابزارت مدیریت Context درستی نداشته باشه، بهترین مدل دنیا رو هم داشته باشی فقط پولت رو دور ریختی...

نکته جالب دیگه، عملکرد مدل‌های Open بود. مدل GLM 5.2 قشنگ اومده تو سطح اول کنار غول‌ها نشسته. برای تسک‌های روزمره که پیچیدگی وحشتناکی ندارن، استفاده از مدل‌هایی مثل Haiku یا GPT-4o Mini به جای مدل‌های سنگین، کارایی تیم رو بدون هزینه اضافی برده بالا. دیتابریکس تسک‌ها رو از توی PRهای واقعی خودشون درآورده بود

لینک جزئیات متدولوژی و پلات‌های مقایسه‌ای رو اینجا ببینید:
databricks.com/blog/benchmarking-coding-agents-multi-million-line-codebase

🛠 Join @LLMEngineers Community

مدل Muse Spark 1.1 از متا منتشر شد با قیمت خیلییی ارزون تر از مدل های رقیب

دیروز توی گروه یه اسکرین‌شات دیدم که مدل وسط چت یهو کدهای عجیبی مثل [control_28] رو چاپ کرد. این یعنی لایه زیرین مدل لو رفته یا همون protocol leakage... مشکل از خودِ هوشِ مدل نیست، احتمالاً موقع تبدیل مدل یا کوانتایز کردن، جای توکن‌های کنترلی با متن معمولی قاطی شده.

مدل وقتی این توکن‌های غلط رو می‌بینه، طبق عادتش شروع می‌کنه به تکرار کردنشون. جالب اینجاست که حتی اگه معذرت‌خواهی کنه و بخواد از اول بنویسه، باز هم چون حافظه‌ش (KV cache) پر از اون توکن‌های خراب شده، نمی‌تونه از اون لوپ بیاد بیرون. یعنی عملاً سیستم قفل می‌کنه روی همون اشتباه و راه فراری نداره.

واقعیت اینه که استکِ اجرای مدل (مثل vLLM یا llama.cpp) به اندازه خودِ وزن‌های مدل مهمه. اگه تنظیمات توکن‌ساز یا متادیتاها توی پروسه تبدیل ذره‌ای جابه‌جا بشه، خروجی نهایی به‌ کل می‌ریزه بهم. اینجور وقت‌ها مدل داره با زبونِ فنی خودش میگه که زیرساختش ایراد داره.

تحلیل کامل‌تر این قضیه و دلیل این تداخل‌ها رو توی پست لینکدینم باز کردم:
https://www.linkedin.com/pulse/debugging-control-token-leakage-m-shojaei-n07me/

🛠 Join @LLMEngineers Community

داشتم با این Colibrì ور می‌رفتم... ایده‌ی اینکه یه مدل ۷۰۰ میلیاردی مثل GLM-5.2 رو روی ۲۵ گیگ رم بالا بیاری، در تئوری جذابه ولی در عمل یعنی با NVMe کشتی می‌گیری. سیستمش دقیقاً مثل یه دیتابیس عمل می‌کنه؛ لایه‌های dense رو تو رم نگه می‌داره، ولی expertهای MoE رو فقط وقتی لازم باشن از SSD می‌خونه. عملاً یه storage hierarchy ساخته که بین VRAM و RAM و دیسک جابه‌جا می‌شه.

کاربرد اصلی‌ش برای وقتیه که سخت‌افزار نداری ولی می‌خوای خروجی یه مدل frontier رو ببینی. معماری MLA رو با یه ترفند جالب به اسم weight absorption بهینه‌سازی کرده که باعث می‌شه حجم KV Cache خیلی کم بشه. اما کوانتیزه‌کردنش خیلی خشنه؛ row-wise int4 بدون هیچ کالیبراسیون خاصی. یعنی احتمالا دقت مدل نسبت به نسخه اصلی افت محسوسی داره.

سرعت خوندن از دیسک گلوگاه اصلیه. اگه SSD خفن نداشته باشی، زیر ۰.۱ توکن در ثانیه می‌گیری. نکته عجیبش هم MTP یا همون speculative decoding هست که اینجا ممکنه برعکس عمل کنه؛ چون حدس زدن توکن‌های بعدی یعنی باید expertهای بیشتری از دیسک خونده بشه و I/O سیستم می‌ترکه. کدهاش به زبان C و بدون وابستگی نوشته شده، خیلی raw و مستقیم... ولی فعلاً برای کار جدی زوده.

https://github.com/JustVugg/colibri

🛠 Join @LLMEngineers Community

سلام دوستان عزیز 👋

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

اگر داده‌های زیر را دارید، خیلی ممنون می‌شیم کمک کنید:

۱. داده‌های دست‌خط (Handwritten):
• جزوه‌ها، یادداشت‌ها و نامه‌های دست‌نویس
• فرم‌های پرشده (اداری، بانکی، پزشکی، ثبت‌نام و ...)
• متن روی کاغذ، تخته، یا عکس گوشی
هرچی از دست خط خودتون باشه به نفعتونه چون این مدل دستخط شمارو بهتر تشخیص خواهد داد :))

→ ارسال به تاپیک: Data: Handwritten

۲. داده‌های تایپ‌شده / چاپی (Typed/Printed):
• اسناد رسمی، قراردادها، فاکتورها، قبوض
• صفحات کتاب، مجله، روزنامه
• گزارش‌ها، نامه‌های رسمی، اسکرین‌شات اپ و وب

→ ارسال به تاپیک: Data: Typed

نکته مهم: حتی چند عکس هم خیلی ارزشمند است! عکس‌های با کیفیت مختلف (تاریک، روشن، زاویه‌دار، نویزدار) عالی هستند چون مدل باید در دنیای واقعی کار کند.

برنامه‌نویس‌ها و متخصصان: برای مشارکت فنی (دیتاست، مدل، کد) به گروه اصلی بپیوندید:
👉 https://telegram.me/bina_ocr

ممنون از لطف و مشارکت ارزشمند شما 🙏
این پروژه کاملاً متن‌باز است و مدل نهایی روی Hugging Face منتشر خواهد شد.

شنوا، یه برنامه‌ی رایگانه که همه‌ی مکالمه‌های فارسی رو به صورت زنده زیرنویس می‌کنه! 🔥👨‍🍳

تا حالا شده بخوای کاش یه ویدیو یا پادکست فارسی، زیرنویس داشت؟👨🏻‍🏫🤓
شنوا، یه برنامه‌ی رایگانه که همه‌ی مکالمه‌های فارسی رو به صورت زنده زیرنویس می‌کنه! 🔥👨‍🍳

این برنامه‌ی نصب روی گوشی های اندروید هست و برای آیفون به سایت شنوا مراجعه کنین 🫡

سایت شنوا (Shenava.app) و من ، رضا سیار در تلگرام و واتسپ صمیمانه پذیرای شما هستیم🤗

تشخیص گفتار (ASR) فارسی به‌صورت استریمینگ و On-device تا قبل از این یه حفره بزرگ توی کامیونیتی بود... رضا سیار با انتشار کالکشن Shenava 1.0 عملاً یه زیرساخت سنگین و باکیفیت رو به‌صورت اوپن‌سورس در اختیار همه گذاشته. تمرکز اصلی پروژه روی Latency پایین و اجرای آفلاین روی سخت‌افزارهای ضعیفه که برای توسعه‌دهنده‌های فارسی‌زبان یه ابزار حیاتی محسوب می‌شه.

مدل‌های این مجموعه از نسخه Koochik (۱۱۴ میلیون پارامتر) که نقش Teacher رو داره، تا نسخه فوق‌بهینه Rizeh-Pizeh (۶.۹ میلیون پارامتر) رو شامل می‌شن... مدل Koochik با وجود ابعاد کوچیکش، توی بنچمارک‌های FLEURS-fa و Golden-6669 عملکردی در سطح مدل‌های بسیار بزرگ‌تر نشون داده. این یعنی می‌شه روی بردهای ارزان‌قیمت مثل ESP32-S3 یا اپلیکیشن‌های موبایل قدیمی، پردازش صوت لایو داشت بدون اینکه نیازی به کارت گرافیک‌های گرون‌قیمت یا اینترنت باشه.

معماری پروژه بر پایه FastConformer هست و تمام خروجی‌های استاندارد اینفرنس توسط رضا آماده شده... فایل‌های ONNX fp16، نسخه‌های CoreML برای iOS، فرمت‌های مخصوص Sherpa-ONNX و حتی نسخه Native Rust با استفاده از Tract توی کالکشن موجوده. عملاً تمام مراحل سختِ تبدیل مدل و بهینه‌سازی برای پلتفرم‌های مختلف انجام شده و مدل‌ها آماده استفاده توی Production هستن.

خط لوله داده (Data Pipeline) این پروژه هم به همون اندازه مدل‌ها فنی و دقیقه... حدود ۴ میلیون سطر دیتای صوتی که با تکنیک‌های Active Learning، اصلاح دستی و فیلتر کردن نویزها تمیز شدن. وجود دیتاست‌های اختصاصی مثل Golha برای کلمات ادبی و Ganjoor برای دکلمه، باعث شده مدل توی درک لحن‌های مختلف فارسی منعطف باشه و نرخ خطای کلمات (WER) رو به‌شدت پایین بیاره.

ابزارهای جانبی مثل ShenavaSanj هم برای امتیازدهی به اهمیت کلمات توی جمله ارائه شده که برای محاسبه Semantic WER کاربرد داره... این کالکشن یه نمونه موفق از Knowledge Distillation و مهندسی دیتاست برای زبان‌های کم‌منبع مثل فارسیه که رضا سیار بدون هیچ منتی برای کامیونیتی جمع‌آوری و منتشر کرده.

https://huggingface.co/collections/Reza2kn/shenava-10-open-streaming-persian-asr-and-captioning

🛠 Join @LLMEngineers Community

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