نقاط قوت مشخص: شکی نیست که Hunyuan-7B در حوزه استدلال ریاضی و منطق خیلی قویه. امتیازهای بالا در بنچمارک‌های MATH، GSM-8K و به‌خصوص AIME این رو ثابت می‌کنه. در این حوزه‌ها، با بهترین‌های کلاس خودش کل‌کل می‌کنه.

نقاط ضعف یا نکات انحرافی:

بنچمارک MMLU: این یه بنچمارک استاندارد و مهمه که دانش عمومی مدل رو می‌سنجه. تو نمودارهای رنگی تنسنت اثری ازش نیست، ولی طبق داده‌های دیگه، Hunyuan-7B با امتیاز حدود ۷۹.۸، به شکل محسوسی از رقیب اصلیش یعنی Qwen3-8B (با امتیاز ۸۷.۵ در MMLU-Redux) ضعیف‌تره. این اختلاف مهمه و نشون میده در دانش عمومی، Qwen3 برتری داره.

بنچمارک IFEval: این بنچمارک توانایی مدل در دنبال کردن دستورالعمل‌ها رو می‌سجه. اینجا هم Hunyuan از مدل OpenAI o1-mini عقب‌تره. این یعنی ممکنه برای تسک‌هایی که نیاز به پیروی دقیق و پیچیده از دستورالعمل دارن، بهترین گزینه نباشه.

دستچین کردن رقبا: در بنچمارک AIME 2024، نمودار تنسنت نشون میده که Hunyuan با امتیاز ۸۱.۱ از بقیه بهتره. اما این "بقیه" شامل مدل تخصصی DeepSeek-R1-0528-Qwen3-8B نمیشه که امتیاز ۸۶.۰ رو در همین بنچمارک کسب کرده. پس Hunyuan بهترین نیست، فقط از رقبایی که تنسنت انتخاب کرده بهتره.

ارزش واقعی Hunyuan-7B کجاست؟

به نظر من، اصل قضیه این نیست که Hunyuan توی همه بنچمارک‌ها اول باشه، چون نیست. ارزش اصلی این مدل توی پکیج کامل و منحصر به فردشه:

۱. عملکرد استدلالی خیلی خوب (Good Enough): شاید بهترین نباشه، ولی به اندازه‌ی کافی قوی هست که کارهای پیچیده رو انجام بده.
۲. پنجره context نیتیو و عظیم 256K: این برگ برنده‌ی اصلیه. هیچکدوم از رقبای مستقیمش چنین پنجره‌ی بزرگی رو به صورت نیتیو و بدون افت کیفیت ارائه نمیدن.
۳. کوانتیزاسیون فوق‌العاده: مدل‌های کوانتایزشده‌ی FP8 و INT4 افت عملکرد بسیار کمی دارن. این یعنی می‌تونید یک مدل با توانایی پردازش ۲۵۶ هزار توکن رو روی یک کارت گرافیک خانگی مثل RTX 4090 اجرا کنید.

🛠 Join @LLMEngineers Community

اپلیکیشن Jan یه رابط کاربری دسکتاپه برای اجرای llm ها که هم آفلاین کار می‌کنه و هم به سرویس‌های ابری وصل می‌شه. کاربرد اصلیش اینه که بهت اجازه می‌ده بدون نگرانی بابت حریم خصوصی، مدل‌های زبانی بزرگ رو روی سیستم شخصی خودت اجرا کنی. اخیراً هم یه قابلیت مهم بهش اضافه شده که می‌شه با اکانت Hugging Face PRO مدل‌ها رو مستقیم داخلش اجرا کرد. کل کدبیسش هم کاملاً اوپن‌سورسه و می‌شه اون رو تغییر داد یا خودتون هاست کنین.

برگ برنده‌اش قابلیت سوییچ یکپارچه بین مدل‌های محلی و ابریه. Jan به شما اجازه می‌ده توی یک محیط چت، هم مدل‌های GGUF رو با llama.cpp به صورت آفلاین اجرا کنین و هم به APIهای کلاد مثل OpenAI، Groq و Mistral وصل بشین. مهم‌تر اینکه، API سرور محلیش (روی localhost:1337) می‌تونه ترافیک رو به صورت شفاف بین یه مدل لوکال Llama 3 و یه مدل ابری مثل GPT-4o جابجا کنه. این یعنی کدی که برای توسعه می‌زنین، بدون هیچ تغییری می‌تونه از هر دو مدل استفاده کنه.

دانلود

🛠 Join @LLMEngineers Community

مقایسه لانچرهای لوکال مدل‌های زبانی بر اساس تجربه شخصی و بحث‌های کامیونیتی

🟣 LM Studio
نقطه‌ی قوت اصلیش، رابط کاربری (GUI) و تجربه‌ی کاربری (UX) خیلی خوبشه. برای کسی که می‌خواد بدون دردسر و سریع یه مدل GGUF رو تست کنه، عالیه.

مزایا: همه‌چیز توی یه پکیجه. دانلودر داخلی از Hugging Face داره، تنظیمات مدل مثل context size و GPU offload به‌راحتی قابل کنترله و یه حالت سرور OpenAI-compatible داره که مدل‌ها رو بر اساس درخواست، به صورت on-demand لود و آنلود می‌کنه. این قابلیت آخر خیلی مهمه.

معایب: رابط کاربریش closed-source هست. یعنی نمی‌تونی کدش رو ببینی یا تغییر بدی. برای بعضی‌ها این یه خط قرمزه. گاهی هم باگ‌هایی داره که البته معمولاً تو نسخه‌های بتا رفع میشن.

کاربرد: بهترین گزینه برای شروع، تست سریع مدل‌های جدید و کسایی که نمی‌خوان درگیر CLI و Docker بشن.

⚪️ Ollama
Ollama بیشتر یه backend یا ابزار CLI هست تا یه اپلیکیشن کامل. هدفش اینه که اجرای مدل‌ها و سرویس‌دهی از طریق API رو تا حد ممکن ساده کنه.

مزایا: خیلی سبکه، نصبش ساده‌ست و به قول معروف set it and forget it هست. مدل‌ها رو از لایبرری خودش می‌کشه و آپدیت می‌کنه.

معایب: یه GUI حداقلی اخیراً اضافه شده ولی برای یه تجربه کامل، معمولاً باید با یه فرانت‌اند مثل OpenWebUI ترکیب بشه. بعضی کاربران حرفه‌ای معتقدن وقتی کار پیچیده میشه، Ollama گزینه‌های کنترلی کمتری نسبت به llama.cpp خام بهت میده.

کاربرد: عالیه برای وقتی که فقط یه API endpoint پایدار برای مدل‌هات می‌خوای و قراره از یه UI دیگه بهش وصل بشی. ترکیب Ollama + OpenWebUI یه ترکیب خیلی محبوبه.

🟡 Jan
Jan سعی کرده یه تعادل بین LM Studio و Ollama برقرار کنه. رابط کاربری داره ولی کاملاً open-source هست.

مزایا: کل اپلیکیشن (فرانت و بک) تحت لایسنس Apache-2.0 هست. بزرگترین ویژگی منحصربه‌فردش اینه که می‌تونه به صورت transparent ترافیک رو بین مدل‌های لوکال و مدل‌های کلاد (مثل GPT-4o یا Claude) جابجا کنه، بدون اینکه نیاز باشه کد سمت کلاینت رو تغییر بدی.

معایب: بعضی‌ها حس می‌کنن هنوز به پختگی LM Studio نرسیده و یه مقدار featureless به نظر میاد.

کاربرد: برای کسایی که به open-source بودن اهمیت میدن و نیاز دارن به‌راحتی بین مدل‌های لوکال و APIهای خارجی سوییچ کنن، بهترین گزینه‌ست.

🟠 Llama.cpp
این خودِ موتوره. ابزارهای دیگه مثل LM Studio و Jan در هسته‌ی خودشون از llama.cpp استفاده می‌کنن.

مزایا: حداکثر پرفورمنس و کنترل. هیچ لایه‌ی اضافه‌ای وجود نداره. برای کارهای جدی، اجرا روی سرورهای headless و برای دولوپرهایی که می‌خوان روی خود انجین کار کنن، انتخاب اوله.

معایب: کار باهاش دانش فنی می‌خواد. همه چیز از طریق CLI و پارامترها کنترل میشه و خبری از GUI نیست.

کاربرد: برای حرفه‌ای‌ها و کارهای جدی.

تیم Qwen یه مدل جدید به اسم Qwen-Image رو اوپن سورس کرده که تمرکزش روی تولید تصویر با رندر متن خیلی قویه، مخصوصا برای زبان چینی و انگلیسی. این مدل ۲۰ میلیارد پارامتری، متن رو به صورت in-pixel یعنی به عنوان بخشی از خود تصویر تولید می‌کنه، نه یه لایه جدا.

اما نکته فنی کلیدی، استفاده از GRPO هست. این رویکرد، تولید تصویر رو به عنوان یک مسئله رتبه‌بندی فرموله می‌کنه. یعنی مدل به جای اینکه فقط یک خروجی «خوب» تولید کنه، یاد می‌گیره از بین چندتا تصویر تولید شده، اونی که به سلیقه انسان نزدیک‌تره رو انتخاب کنه. این فرآیند دقیقاً شبیه به مکانیزم RLHF در مدل‌های زبانی برای همسو شدن با اولویت‌های انسانیه. نتیجه‌اش هم خروجی‌هاییه که نه تنها دقیقن، بلکه از نظر زیبایی‌شناسی هم قوی‌ترن.

🤗 هاگینگ فیس

🛠 Join @LLMEngineers Community

یه مدل جدید به اسم Hierarchical Reasoning Model یا HRM اومده که نتایج جالبی روی تسک‌های استدلال منطقی گرفته. بعضی‌ها دارن بهش میگن "LLM-killer" ولی این مقایسه از پایه اشتباهه. کاربرد عملی HRM حل پازل‌های منطقی پیچیده و بهینه‌سازی مسیر تو فضاهای بسته‌ است، یعنی کارهایی که نیاز به جستجو و backtracking عمیق دارن.

این مدل مستقیماً به محدودیت‌های معماری Transformers حمله می‌کنه. مدل‌های ترنسفورمر، هرچقدر هم بزرگ باشن، از نظر محاسباتی "کم‌عمق" هستن و نمی‌تونن الگوریتم‌های پیچیده رو به صورت end-to-end اجرا کنن. برای همین به سراغ Chain-of-Thought یا CoT میرن که در واقع نوعی برون‌سپاری استدلال به فضاست. CoT شکننده است و به داده زیاد برای فاین‌تیون شدن نیاز داره.

معماری HRM از ساختار سلسله‌مراتبی و چندمقیاسی مغز الهام گرفته شده. دو ماژول recurrent داره که با هم کار می‌کنن:
۱. یه ماژول سطح بالا (High-level H): این ماژول آهسته آپدیت میشه و مسئولیت برنامه‌ریزی انتزاعی و کلی رو به عهده داره.
۲. یه ماژول سطح پایین (Low-level L): این یکی سریع آپدیت میشه و محاسبات جزئی و دقیق رو انجام میده.

نتایجش روی بنچمارک‌های خاص خیلی خوبه. این مدل ۲۷ میلیون پارامتری، فقط با ۱۰۰۰ نمونه داده آموزشی و بدون هیچ pre-training، تونسته پازل‌های سودوکوی خیلی سخت (Sudoku-Extreme) و مازهای پیچیده (Maze-Hard) رو با دقت نزدیک به ۱۰۰٪ حل کنه؛ تسک‌هایی که مدل‌های زبانی بزرگ با CoT عملاً روی اون‌ها شکست خوردن (دقت صفر). توی بنچمارک ARC هم که برای سنجش هوش عمومی مصنوعی طراحی شده، عملکرد بهتری از مدل‌های بسیار بزرگتر از خودش داشته.

به نظر من، HRM یه LLM-killer" نیست. LLM مثل یک سیستم‌عامل همه-کاره‌ست که میتونه کد بنویسه، ایمیل بزنه و کارهای عمومی انجام بده. HRM مثل یک ماشین حساب فوق‌العاده تخصصی و قدرتمنده که برای حل یک کلاس خاص از مسائل منطقی طراحی شده. قدرت اصلی این مقاله در اینه که نشون میده میشه با معماری‌های جایگزین، به خصوص ساختارهای سلسله‌مراتبی و recurrent، الگوریتم‌های پیچیده رو به صورت بهینه و با داده کم یاد گرفت. این مدل شاید مستقیم تو محصولات روزمره استفاده نشه، ولی اصول معماریش می‌تونه روی نسل بعدی مدل‌ها تاثیرگذار باشه.


📃 Hierarchical Reasoning Model

🛠 Join @LLMEngineers Community

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

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

این نقشه راه، ۵ مرحله کلیدی داره که Agent رو از جهنم توسعه به یک سیستم قابل اتکا و مقیاس‌پذیر منتقل می‌کنه.

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

فریم‌ورک FastAPI: این روش صحبت کردن Agent با دنیای بیرونه. باهاش می‌شه Endpointهای سبک، امن و مقیاس‌پذیر ساخت.

برنامه‌نویسی Async: ایجنت‌ها معمولاً منتظر جواب APIها یا دیتابیس‌ها می‌مونن. برنامه‌نویسی Async کمک می‌کنه که سیستم بدون بلاک شدن، کارهای بیشتری رو با سرعت بالاتر انجام بده.

کتابخانه‌ی Pydantic: داده‌هایی که به Agent وارد و از اون خارج می‌شن باید قابل پیش‌بینی و اعتبارسنجی شده باشن. Pydantic با تعریف Schema جلوی نصف باگ‌های آینده رو می‌گیره.

مرحله ۲: پایدار و قابل اتکا کردن Agent
توی این مرحله، Agent از نظر فنی کار می‌کنه، ولی پروداکشن به این اهمیت نمی‌ده. پروداکشن نگران لحظاتیه که سیستم کار نمی‌کنه. دو چیز اینجا حیاتیه:

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

تست‌نویسی (Testing): تست‌های Unit جلوی اشتباهات ساده رو قبل از رسیدن به پروداکشن می‌گیرن. تست‌های Integration هم تضمین می‌کنن که ابزارها، پرامپت‌ها و APIها با هم درست کار می‌کنن.

مرحله ۳: عمیق شدن در RAG
یک Agent بدون دسترسی به دانش قابل اتکا، چیز زیادی برای ارائه نداره. معماری RAG (Retrieval-Augmented Generation) به Agent حافظه، فکت و دسترسی به اطلاعات دنیای واقعی رو می‌ده.

مبانی RAG: اول باید درک کرد که RAG چیه، چرا مهمه و چطور در طراحی سیستم جا می‌گیره.

ابزارهای اصلی: مفاهیم Text Embeddings و Vector Stores، بلوک‌های اصلی بازیابی اطلاعات هستن.

جایگزین‌ها: برای خیلی از کاربردها، نیازی به Vector DBهای عجیب و غریب نیست. یک PostgreSQL که خوب ایندکس شده باشه هم می‌تونه کار رو راه بندازه.

بهینه‌سازی: استراتژی‌های Chunking هوشمندانه، روی کیفیت بازیابی تأثیر مستقیم داره. استفاده از فریم‌ورک‌هایی مثل LangChain برای کنار هم گذاشتن قطعات و ابزارهای ارزیابی (Evaluation) هم برای سنجش کیفیت جواب‌ها ضروریه.
به نظر من، اکثر Agentهای ضعیف همین‌جا زمین می‌خورن.

مرحله ۴: تعریف معماری مستحکم برای Agent
یک Agent قدرتمند فقط یک پرامپت نیست، بلکه یک سیستم کامله. برای ساختن چیزی که در پروداکشن کار کنه، به ساختار، حافظه و کنترل نیاز داری:

فریم‌ورک‌های Agent (مثل LangGraph): این‌ها مغز متفکر Agent هستن. وضعیت (state)، مراحل، تلاش‌های مجدد و منطق کلی سیستم رو مدیریت می‌کنن.

مهندسی پرامپت: دستورالعمل‌های واضح تفاوت بین حدس زدن و رفتار قابل اتکا رو رقم می‌زنن.

مدیریت دیتابیس: به یک دیتابیس واقعی با ابزارهایی مثل SQLAlchemy و Alembic برای مدیریت لاگ‌ها، حافظه و وضعیت Agent نیاز هست.

مرحله ۵: مانیتورینگ، یادگیری و بهبود در پروداکشن
آخرین مرحله، تفاوت بین پروژه‌های سرگرمی و سیستم‌های واقعی رو مشخص می‌کنه: بهبود مستمر.
وقتی Agent لانچ می‌شه، کار تموم نشده، تازه شروع شده. باید با ابزارهایی مثل Langfuse یا لاگ‌های کاستوم، رفتار Agent و کاربر رو زیر نظر گرفت. هر تعامل کاربر با سیستم، یک فیدبک حساب می‌شه که باید ازش برای بهبود پرامپت‌ها و ابزارها استفاده کرد. تله‌ی "راه‌اندازی کن و فراموشش کن" چیزیه که خیلی‌ها توش می‌افتن.

در نهایت، ساختن Agent برای پروداکشن، انتخاب بین ساختن یه اسباب‌بازی و یه سیستم واقعیه. سیستم‌هایی که حافظه دارن، استدلال می‌کنن و در طول زمان بهتر می‌شن، با شانس ساخته نمی‌شن؛ با اصول مهندسی ساخته می‌شن.

🛠 Join @LLMEngineers Community

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

اینجا چند تا استراتژی رایج و پیشرفته برای Chunking رو بررسی می‌کنیم تا بدونید کی و کجا از هرکدوم استفاده کنید.

استراتژی‌های پایه و ساده

این روش‌ها نقطه شروع خوبی هستن و پیاده‌سازی ساده‌ای دارن.

Fixed-size chunking:
ساده‌ترین راه. متن به تکه‌هایی با اندازه ثابت (مثلا ۱۰۰۰ کاراکتر) تقسیم میشه. این روش برای داده‌های کثیف و بدون ساختار مثل متن‌های استخراج شده از اسکن OCR یا فایل‌های لاگ خام مناسبه، ولی ریسک شکستن جملات و از بین رفتن کانتکست رو داره.

Sliding window chunking:
نسخه‌ی بهبود یافته‌ی روش قبلی. چانک‌ها با هم همپوشانی (overlap) دارن تا کانتکست بینشون حفظ بشه. برای متونی که مفاهیم در جملات طولانی کشیده میشن، مثل مقالات و گزارش‌های روایی، کاربرد داره.

Sentence-based chunking:
متن بر اساس پایان جملات (نقطه، علامت سوال و...) شکسته میشه. برای متون تمیز و خوش‌ساختار مثل بلاگ‌پست‌ها و مستندات که هر جمله یک ایده کامل داره، خوبه.

Paragraph-based chunking:
متن بر اساس پاراگراف‌ها تقسیم میشه. وقتی هر پاراگراف یک بلوک معنایی کامل رو تشکیل میده، مثل مقالات یا گزارش‌ها، این روش کانتکست بهتری نسبت به شکستن جمله به جمله فراهم می‌کنه.

استراتژی‌های مبتنی بر ساختار

این روش‌ها از ساختار خود داکیومنت برای تقسیم‌بندی هوشمندتر استفاده می‌کنن.

Document-based chunking:
تقسیم‌بندی بر اساس ساختار طبیعی سند مثل سرفصل‌ها (Headings) و بخش‌ها (Sections) انجام میشه. برای کتاب‌های درسی، مقالات تحقیقاتی و راهنماها که ساختار سلسله‌مراتبی دارن، ایده‌آله.

Page-based chunking:
هر صفحه از سند به عنوان یک چانک در نظر گرفته میشه. مشخصاً برای کار با PDF، اسلاید یا کتاب که شماره صفحه اهمیت داره استفاده میشه.

Structured chunking:
برای داده‌های ساختاریافته یا نیمه‌ساختاریافته مثل HTML، JSON یا CSV کاربرد داره. در این روش، چانک‌ها بر اساس تگ‌ها (مثلا <div> در HTML) یا فیلدهای مشخص تعریف میشن.

Table-aware chunking:
جدول‌ها شناسایی و به صورت جداگانه و با فرمت مناسب (مثلا Markdown یا JSON) چانک میشن تا ساختارشون حفظ بشه.

استراتژی‌های پیشرفته و محتوامحور

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

Semantic chunking:
در این روش، جملات یا پاراگراف‌ها بر اساس شباهت معنایی (embedding similarity) گروه‌بندی میشن. چانک‌ها زمانی شکسته میشن که موضوع بحث تغییر کنه. برای اسناد طولانی با موضوعات مختلف که روش‌های ساده جواب نمیدن، خیلی موثره.

Entity-based chunking:
با استفاده از مدل‌های Named Entity Recognition (NER)، موجودیت‌هایی مثل اسامی افراد، مکان‌ها یا محصولات شناسایی شده و متن‌های مرتبط با هر موجودیت در یک چانک قرار می‌گیره. برای تحلیل قراردادهای حقوقی، مقالات خبری یا اسناد مالی خوبه.

Agentic / LLM-based chunking:
اینجا از خود یک LLM خواسته میشه که تصمیم بگیره متن رو چطور تقسیم کنه. این روش قدرت انعطاف بالایی داره ولی کند و پرهزینه‌ست. این روش معمولا overkill حساب میشه، مگر اینکه با داده‌های خیلی پیچیده و بدون هیچ ساختاری سر و کار داشته باشید.

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


🛠 Join @LLMEngineers Community

خب، OpenAI بالاخره دو تا مدل open-weight واقعی منتشر کرد. اسم این خانواده gpt-oss هست و فعلاً دو تا عضو داره:

gpt-oss-120b:
مدل بزرگ با ۱۱۷ میلیارد پارامتر (۵.۱ میلیارد پارامتر فعال) برای پروداکشن و تسک‌های سنگین استدلالی.

gpt-oss-20b:
مدل کوچیک با ۲۱ میلیارد پارامتر (۳.۶ میلیارد پارامتر فعال) برای سخت‌افزارهای ضعیف‌تر و کاربردهای on-device.

کاربرد اصلیشون برای تسک‌های agentic و استدلاله. مدل‌ها text-only هستن و با لایسنس Apache 2.0 منتشر شدن که برای استفاده تجاری عالیه.

برای اجرا، می‌تونید از فریمورک‌های استاندارد مثل transformers، vLLM و Ollama استفاده کنید.

این مدل‌ها قابلیت‌های agentic خوبی دارن مثل function calling، وب‌گردی و اجرای کد پایتون. همچنین می‌شه سطح استدلال مدل رو از طریق system prompt روی سه حالت low، medium و high تنظیم کرد.

💻 دمو (gpt-oss.com)

نکات کلیدی فنی و معماری:

معماری اصلی این مدل‌ها Mixture-of-Experts یا MoE هست.
مدل 120B دارای ۱۲۸ اکسپرت محلی و مدل 20B دارای ۳۲ اکسپرته.
برای هر توکن، ۴ اکسپرت فعال میشه (experts_per_token: 4).

یک نوآوری مهم، استفاده از کوانتایزیشن MXFP4 به صورت native هست. این کوانتایزیشن ۴ بیتی فقط روی وزن‌های MoE اعمال شده. نتیجه اینه که مدل 120B روی یک کارت H100 با ۸۰ گیگ VRAM و مدل 20B روی سخت‌افزار معمولی با ۱۶ گیگ VRAM جا میشه. این برای چنین مدل‌های بزرگی، یک دستاورد عالیه.

مکانیزم attention هم ترکیبی طراحی شده. لایه‌ها به صورت یکی در میون از full attention و sliding window attention (با پنجره ۱۲۸ توکنی) استفاده می‌کنن. از GQA استفاده شده
برای positional encoding هم از Yarn RoPE scaling استفاده شده که به مدل اجازه میده کانتکست طولانی تا 128K توکن رو پشتیبانی کنه.

🤗 مدل gpt-oss-120b در هاگینگ فیس
🤗 مدل gpt-oss-20b در هاگینگ فیس


🛠 Join @LLMEngineers Community

همچنین OpenAI یه مجموعه Cookbook برای مدل‌های gpt-oss منتشر کرده:

- چطور مدل‌های gpt-oss رو با Hugging Face Transformers فاین‌تیون کنیم.

- چطور مدل‌ها رو با فریمورک‌های بهینه‌ای مثل vLLM یا به صورت محلی با Ollama اجرا کنیم.

- چطور chain-of-thought خام مدل رو مدیریت و ازش استفاده کنیم.

- و مهم‌تر از همه، توضیح فرمت پاسخ‌دهی OpenAI Harmony.

این دو مورد آخر خیلی مهمن. چون این مدل‌ها با فرمت Harmony آموزش دیدن و برای استفاده درست و گرفتن Chain-of-Thought، باید با این فرمت آشنا بود.

gpt-oss cookbook

🛠 Join @LLMEngineers Community

این نمودار عملکرد مدل‌های gpt-oss رو در بنچمارک Humanity's Last Exam نشون میده که شامل سوالات بسیار تخصصی در حوزه‌های مختلفه. این بنچمارک، توانایی استدلال عمیق و دانش تخصصی مدل رو به چالش می‌کشه.

مدل gpt-oss-120b با استفاده از ابزار (with tools) به دقت ۱۹٪ میرسه. این بهترین عملکرد در بین مدل‌های open-weight موجود در این نموداره.

با این حال، هنوز فاصله قابل توجهی با مدل‌های بسته و قدرتمندتر مثل o3 وجود داره که به دقت ۲۴.۹٪ رسیده.

مهم‌ترین نکته، تأثیر ابزارهاست. دقت gpt-oss-120b بدون ابزار از ۱۹٪ به ۱۴.۹٪ سقوط می‌کنه. این الگو برای مدل gpt-oss-20b هم تکرار می‌شه (۱۷.۳٪ در مقابل ۱۰.۹٪).

نکته جالب اینه که gpt-oss-120b با ابزار (۱۹٪) عملکرد بهتری از o4-mini با ابزار (۱۷.۷٪) داره که این یک امتیاز مثبت برای این مدل اپن سورس محسوب میشه.

🛠 Join @LLMEngineers Community

این نمودار عملکرد کدنویسی مدل‌های gpt-oss رو در مسائل مسابقات برنامه‌نویسی Codeforces، نشون می‌ده.

مدل gpt-oss-120b با استفاده از tools (ابزارهایی مثل مفسر پایتون) به ریتینگ قابل احترام ۲۶۲۲ رسیده. این امتیاز خیلی بالاست و نشون‌دهنده توانایی بالای استدلال الگوریتمیه.

با این حال، هنوز از مدل‌های بسته مثل o4-mini که ریتینگ ۲۷۱۹ داره، کمی ضعیف‌تره.

عملکرد مدل gpt-oss-20b هست. این مدل کوچیک وقتی از ابزار استفاده می‌کنه، به ریتینگ ۲۵۱۶ میرسه که حتی از مدل ۱۲۰ میلیاردی بدون ابزار هم بهتره. این نشون میده معماری و آموزش برای استفاده از ابزار چقدر بهینه‌ست.

🛠 Join @LLMEngineers Community

بنچمارک های دیگه


🛠 Join @LLMEngineers Community

با انتشار مدل های gpt-oss-20b و gpt-oss-120b به صورت اوپن سورس OpenAI کاملاً داره رقیباشو له میکنه
مقایسه با مدل های Qwen با اینکه اینا حدود ۵ برابر پارامترهای فعال کمتر دارن

🛠 Join @LLMEngineers Community

gpt-oss-120b & gpt-oss-20b Model Card