یه مقایسه عملی و سریع بین Ollama و LM Studio موقع اجرای یه مدل GGUF یکسان. نتایج جالبه و شاید برای انتخاب ابزار کمکتون کنه.

توی این تست، مدل gemma-2-2b-fa یک بار با LM Studio و یک بار با Ollama روی یه مجموعه سوال یکسان ارزیابی شده.

نتایج خلاصه:

LM Studio:
دقت 31.04% و میانگین latency برابر 0.15s.

Ollama:
دقت 29.40% و میانگین latency برابر 0.43s.

همونطور که مشخصه، LM Studio هم دقت بالاتری داشته و هم تقریباً ۳ برابر سریع‌تر بوده. علاوه بر این، مصرف VRAM در Ollama هم بیشتر بود.

🛠 Join @LLMEngineers Community

داشتم قابلیت function calling یا tool use رو با مدل‌های لوکال تست می‌کردم که یه نتیجه جالب گرفتم.

مدل کوچیک jan-v1-4b که قبلتر راجبش گفته بودنم رو توی LM Studio ران کردم و بهش MCP جستجوی وب با DuckDuckGo وصل کردم. وقتی ازش خواستم آخرین اخبار هوش مصنوعی رو بهم بگه، به جای اینکه از دانش داخلی و تاریخ گذشته‌ش استفاده کنه، خودش تشخیص داد که باید از ابزار search استفاده کنه.

همونطور که توی اسکرین‌شات مشخصه، مدل به صورت خودکار یه کوئری جستجو ساخت، اجراش کرد و بعد نتایج رو برام خلاصه کرد. این دقیقاً همون فرآیند ReAct هست که داریم روی مدل‌های بزرگ می‌بینیم، ولی این بار روی یه مدل ۴ میلیاردی لوکال.

به نظر من، این قابلیت که مدل‌های کوچیک و open-source هم بتونن از ابزارهای خارجی استفاده کنن، بازی رو عوض می‌کنه. این یعنی دیگه محدود به دانش داخلی مدل نیستیم و می‌تونیم مدل‌ها رو برای کاربردهای واقعی و ساختن agent های ساده آماده کنیم.

🛠 Join @LLMEngineers Community

مجموع دانلود مدل‌های فارسی gemma-3-4b که چند ماه پیش منتشر کردم، از مرز ۴ هزار دانلود عبور کرد.
این آمار شامل تمام نسخه‌های کوانتایز شده GGUF، نسخه‌ی Ollama و ...

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

با همین انرژی، کار روی پروژه‌ی بعدی شروع شده.
منتظر نسخه‌ی فاین‌تیون شده‌ی فارسی Qwen3-4B یا gemma-3n-e4b باشید. به‌زودی ...

🤗 صفحه من توی هاگینگ فیس

🛠 Join @LLMEngineers Community

نتیجه تست مدل های زبانی کوچک SLM روی بنچمارک ParsiEval برای سنجش دانش زبان فارسی

پ.ن: لازم به ذکره qwen thinking هم خیلی کند تر بود هم gpu داغ کن تر

▫️ لیست کامل

🛠 Join @LLMEngineers Community

توضیح غیرفنی معماری MoE
🛠 Join @LLMEngineers Community

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