شرکت Sakana AI در ژوئن ۲۰۲۶ مدل Fugu Ultra را معرفی کرد و این محصول بلافاصله توجه ما را به خود جلب کرد.

«این سیستم بر پایه مجموعه‌ای از مدل‌های پیشرفته و در دسترس عموم ساخته شده است، نه اینکه صرفاً یک مدل واحد باشد.»

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

خلاصه ماجرا

در واقع Fugu Ultra یک مدل نیست؛ بلکه یک هماهنگ‌کننده (Conductor) چندعاملی است که وظایف زیر را انجام می‌دهد:

• درخواست کاربر را از طریق یک API سازگار با OpenAI دریافت می‌کند.
• میزان پیچیدگی درخواست را ارزیابی می‌کند.
• بسته به پیچیدگی، درخواست را به یک تا سه نمونه از مدل‌های پیشرفته (که تأیید شده شامل مدل‌های Google Gemini هستند) ارسال می‌کند.
• خروجی این مدل‌ها را با یکدیگر ترکیب می‌کند.
• در نهایت، پاسخ نهایی را به گونه‌ای بازمی‌گرداند که گویی تنها یک مدل آن را تولید کرده است.

API ساکانا اطلاعات دقیقی درباره توکن‌های مربوط به فرآیند ارکستراسیون ارائه می‌دهد و همین موضوع باعث می‌شود بتوان ساختار واقعی هزینه‌های داخلی سیستم را مشاهده کرد.

برای درخواست‌های ساده، این سیستم تقریباً ۱۲۶۰ توکن سربار ثابت دارد. اما در درخواست‌های پیچیده، تعداد کل توکن‌های مصرف‌شده بین ۵ تا ۱۲ برابر بیشتر از توکن‌هایی است که کاربر در پاسخ نهایی مشاهده می‌کند.

چگونه به این نتیجه رسیدیم؟

ابتدا مدل sakana/fugu-ultra را از طریق روتر درواره فراخوانی کردیم و متوجه نکته‌ای عجیب شدیم:

تعداد completion_tokens بسیار بیشتر از خروجی قابل مشاهده بود.

برای مثال، اگر مدل فقط پاسخ "42" را تولید می‌کرد (که عملاً تنها یک توکن قابل مشاهده است)، API اعلام می‌کرد که ۱۳۶۰ توکن خروجی مصرف شده است.

حتی تولید یک هایکو نیز ۱۴۶۸ توکن مصرف می‌کرد.

واضح بود که در پشت صحنه اتفاقات دیگری در حال رخ دادن است.

سپس مستقیماً API ساکانا را فراخوانی کردیم و پاسخ را یافتیم.

برخلاف درواره که خروجی را به قالب استاندارد OpenAI تبدیل می‌کند، API ساکانا جزئیات کامل مصرف توکن‌ها را نمایش می‌دهد:

{  "prompt_tokens": 212,  "completion_tokens": 522,  "total_tokens": 7250,  "prompt_tokens_details": {    "orchestration_input_tokens": 5463,    "orchestration_input_cached_tokens": 0  },  "completion_tokens_details": {    "reasoning_tokens": 0,    "orchestration_output_tokens": 1053  }}

دو فیلد زیر تمام ماجرا را آشکار می‌کنند:

• orchestration_input_tokens
• orchestration_output_tokens

کاربر تنها ۲۱۲ توکن ورودی و ۵۲۲ توکن خروجی را مشاهده می‌کند.

اما در پشت صحنه، هماهنگ‌کننده سیستم:

• ۵۴۶۳ توکن ورودی اضافی برای فراخوانی مدل‌های داخلی مصرف کرده است.
• ۱۰۵۳ توکن خروجی دیگر نیز در جریان تعامل میان این مدل‌ها تولید شده است.

به همین دلیل، مقدار total_tokens که برابر با ۷۲۵۰ است، تمام توکن‌های مصرف‌شده—چه قابل مشاهده و چه پنهان—را در بر می‌گیرد.

دو حالت عملیاتی

پس از انجام بیش از ۲۰ آزمایش با درخواست‌هایی در سطوح مختلف پیچیدگی، الگوی مشخصی نمایان شد.

Fugu Ultra در دو حالت کاملاً مجزا فعالیت می‌کند.

حالت ساده (Simple Mode)

برای پرسش‌های ساده مانند:

• «۲+۲ چند می‌شود؟»
• «سلام»

رفتار سیستم به این شکل است:

• هماهنگ‌کننده تنها یک مدل را فراخوانی می‌کند.
• حدود ۱۲۶۰ توکن ثابت به‌عنوان ورودی ارکستراسیون مصرف می‌شود (همان پرامپت سیستمی که به مدل تزریق می‌شود).
• هیچ توکنی برای خروجی ارکستراسیون تولید نمی‌شود؛ زیرا نیازی به استدلال داخلی یا ترکیب چند پاسخ وجود ندارد.
• زمان پاسخ‌دهی بین ۸ تا ۱۲ ثانیه است.
• مجموع سربار سیستم تقریباً ۵ برابر تعداد توکن‌های قابل مشاهده است.

حالت پیچیده (Complex Mode)

برای درخواست‌هایی که شامل تحلیل، استدلال چندمرحله‌ای یا تولید محتوای خلاقانه هستند، سیستم رفتار متفاوتی دارد:

• هماهنگ‌کننده چندین مدل را فراخوانی می‌کند.
• فرآیند استدلال داخلی انجام می‌شود.
• نتایج مدل‌ها با یکدیگر ترکیب و یک پاسخ نهایی تولید می‌شود.
• تعداد توکن‌های ورودی ارکستراسیون به ۶۰۰۰ تا بیش از ۱۱۰۰۰ توکن افزایش می‌یابد.
• خروجی ارکستراسیون نیز بین ۱۳۰۰ تا بیش از ۹۲۰۰ توکن خواهد بود.
• زمان پاسخ‌گویی از ۳۰ ثانیه تا بیش از ۱۶۰ ثانیه متغیر است.
• سربار کلی سیستم معمولاً بین ۸ تا ۱۲ برابر تعداد توکن‌های قابل مشاهده خواهد بود.

بخش دوم

جدول زیر نتایج کامل آزمایش‌هایی را نشان می‌دهد که همگی مستقیماً روی API ساکانا اجرا شده‌اند:

این نتایج به‌وضوح نشان می‌دهند که تصمیم سیستم برای مسیریابی درخواست‌ها بر اساس میزان پیچیدگی آن‌ها انجام می‌شود.

پرسش‌های بسیار ساده مستقیماً به یک مدل واحد ارسال می‌شوند.

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

راز عدد ثابت ۱۲۶۰ توکن

نکته جالب این است که تمام درخواست‌ها، چه ساده و چه پیچیده، دقیقاً حدود ۱۲۶۰ توکن ورودی ارکستراسیون دارند.

این عدد تقریباً هیچ‌گاه تغییر نمی‌کند.

دلیل آن این است که این مقدار همان پرامپت سیستمی (System Prompt) هماهنگ‌کننده است؛ یعنی مجموعه دستورالعمل‌هایی که پیش از درخواست کاربر به هر مدل داخلی اضافه می‌شود تا مشخص کند:

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

برای اطمینان از این موضوع، آزمایش دیگری انجام دادیم.

یک درخواست بسیار کوچک شامل تنها یک کلمه («Hi») با مقدار max_tokens=50 ارسال کردیم.

نتیجه چنین بود:

• prompt_tokens: برابر با ۷ (فقط همان کلمه کاربر)
• orchestration_input_tokens: برابر با ۱۲۶۰
• total_tokens: برابر با ۱۳۱۷

این آزمایش نشان می‌دهد که پرامپت سیستمی تقریباً ۱۲۶۰ توکن طول دارد و بدون استثنا به ابتدای تمام درخواست‌ها اضافه می‌شود.

در درخواست‌های پیچیده، تعداد توکن‌های ورودی ارکستراسیون از این مقدار بسیار بیشتر می‌شود، زیرا هماهنگ‌کننده علاوه بر پرامپت سیستمی، اطلاعات دیگری نیز به هر عامل اضافه می‌کند؛ از جمله:

• شرح وظیفه اختصاصی هر عامل (Sub-task Assignment)
• زمینه و نتایج حاصل از سایر مدل‌ها
• اطلاعات لازم برای همکاری میان عامل‌ها

به همین دلیل است که ورودی ارکستراسیون در برخی آزمایش‌ها به بیش از ۱۱ هزار توکن می‌رسد.

عامل‌های داخلی چه چیزی درباره خودشان فاش کردند؟

یکی از جالب‌ترین بخش‌های این تحقیق زمانی بود که مستقیماً از عامل داخلی پرسیدیم:

«تو چه مدلی هستی؟»

پاسخ تقریباً همیشه یکسان بود:

«من fugu-ultra هستم؛ یک عامل (Worker Agent) که در چارچوب سیستم ارکستراسیون Fugu فعالیت می‌کند.»

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

اما وقتی با استفاده از یک پرامپت سیستمی مخصوص اشکال‌زدایی (Debugging System Prompt) از او درباره جزئیات داخلی سؤال کردیم، اطلاعات بسیار بیشتری فاش شد.

عامل چنین پاسخ داد:

«اگرچه من توسط یک مدل زبانی بزرگ ساخته‌شده توسط گوگل (Gemini) قدرت می‌گیرم، اما از داخل محیط اجرا به شناسه دقیق مدل، هش نسخه (Checkpoint Hash) یا آدرس API مورد استفاده دسترسی ندارم.»

این پاسخ عملاً تأیید می‌کند که عامل‌های داخلی حداقل در زمان انجام این آزمایش‌ها بر پایه Google Gemini اجرا می‌شده‌اند.

عامل همچنین بخشی از ساختار پرامپت سیستمی خود را نیز توضیح داد.

۱. دستورالعمل هویت (Identity Instruction)

به عامل گفته می‌شود که همیشه خود را این‌گونه معرفی کند:

«من fugu-ultra هستم؛ یک عامل کاری در سیستم ارکستراسیون Fugu.»

۲. بخش زیرساخت ارکستراسیون (Orchestration Scaffolding)

در ابتدای هر درخواست، یک بلوک ساخت‌یافته به پرامپت اضافه می‌شود که شامل اطلاعاتی مانند:

• داده‌های مربوط به مسیریابی
• متادیتا
• وظایف اختصاص‌یافته به هر عامل

است.

۳. بخش سؤال کاربر

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

۴. قوانین سخت‌گیرانه عدم افشا

عامل‌ها صریحاً دستور دارند که:

• محتوای بلوک ارکستراسیون را فاش نکنند.
• آن را بازنویسی نکنند.
• خلاصه نکنند.
• اجزای آن را فهرست نکنند.
• درباره ساختار، برچسب‌ها یا دسته‌بندی‌های آن توضیحی ارائه ندهند.

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

۵. قالب‌بندی پاسخ

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

سپس هماهنگ‌کننده این پاسخ‌ها را دریافت کرده، آن‌ها را تحلیل و ترکیب می‌کند و در نهایت پاسخ نهایی را به کاربر تحویل می‌دهد.

یک الگوی کلاسیک Orchestrator–Workers

آنچه مشاهده کردیم، دقیقاً با الگوی شناخته‌شده Orchestrator–Workers مطابقت دارد؛ همان الگویی که Anthropic آن را در طبقه‌بندی رسمی خود با عنوان الگوی شماره ۴ معرفی کرده است.

در این معماری:

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

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

استریم پاسخ‌ها به‌صورت بافرشده انجام می‌شود، نه موازی

یکی از آزمایش‌های ما بررسی نحوه Streaming پاسخ‌ها بود.

زمانی که پاسخ Fugu Ultra را به‌صورت استریم دریافت کردیم، تنها سه قطعه (Chunk) به دست آمد:

{"role": "assistant"}

سپس:

{"content": "The capital of Japan is Tokyo."}

که کل پاسخ را تنها در یک قطعه شامل می‌شد.

و در پایان:

{}

که نشان‌دهنده پایان جریان پاسخ بود.

این رفتار یک نکته مهم را ثابت می‌کند:

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

به عبارت دیگر، روند کار به این صورت است:

1. هماهنگ‌کننده عامل‌های داخلی را فراخوانی می‌کند.
2. منتظر می‌ماند تا همه آن‌ها پاسخ خود را تولید کنند.
3. پاسخ‌ها را تحلیل و ترکیب می‌کند.
4. پاسخ نهایی را می‌سازد.
5. تنها پس از پایان همه این مراحل، نتیجه را برای کاربر ارسال می‌کند.

در نتیجه، در طول اجرای عامل‌های داخلی هیچ استریم تدریجی به سمت کاربر وجود ندارد.

پیامد این طراحی

برای پرسش‌های ساده، کاربر باید حدود ۸ تا ۱۲ ثانیه منتظر بماند تا اولین خروجی ظاهر شود.

برای درخواست‌های پیچیده، این انتظار ممکن است بین ۳۰ تا بیش از ۱۶۰ ثانیه طول بکشد.

به همین دلیل، مهم‌ترین نقطه ضعف تجربه کاربری در معماری چندعاملی همین افزایش زمان انتظار است.

Fugu در برابر Fugu Ultra

شرکت Sakana AI از طریق API خود دو محصول ارائه می‌کند:

نسخه fugu هیچ‌گونه لایه ارکستراسیونی ندارد.

در واقع این نسخه تنها یک فراخوانی مستقیم به یک مدل واحد است و بنابراین:

• سربار ارکستراسیون ندارد.
• زمان پاسخ آن حدود ۴ ثانیه است.
• برای کاربردهایی که سرعت اهمیت زیادی دارد، مناسب‌تر است.

در مقابل، Fugu Ultra همان محصول چندعاملی است که با قربانی کردن سرعت، کیفیت پاسخ را در مسائل دشوار افزایش می‌دهد.

هر دو مدل از طریق درواره و با شناسه‌های زیر قابل استفاده هستند:

• sakana/fugu
• sakana/fugu-ultra

این همان «ادغام تکاملی مدل‌ها» نیست

شرکت Sakana AI بیشتر به خاطر پژوهش مشهور خود در سال ۲۰۲۴ درباره ادغام تکاملی مدل‌ها (Evolutionary Model Merging) شناخته می‌شود.

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

مشهورترین دستاورد آن‌ها EvoLLM-JP بود.

در این پروژه، مدلی که در ریاضیات عملکرد بسیار خوبی داشت با یک مدل متخصص زبان ژاپنی ادغام شد و نتیجه، مدلی بود که هم در ریاضیات و هم در زبان ژاپنی عملکرد بسیار قدرتمندی ارائه می‌داد.

اما Fugu Ultra از نظر معماری کاملاً متفاوت است.

تفاوت اصلی چنین است:

ادغام مدل‌ها (Model Merging)

• در زمان آموزش انجام می‌شود.
• وزن‌های چند مدل در هم ادغام می‌شوند.
• در نهایت فقط یک مدل واحد ایجاد می‌شود.

اما Fugu Ultra

• هیچ ادغامی در وزن‌ها انجام نمی‌دهد.
• چند مدل مستقل را هنگام اجرا هماهنگ می‌کند.
• همه مدل‌ها جداگانه باقی می‌مانند و تنها توسط یک هماهنگ‌کننده مدیریت می‌شوند.

خود مدل نیز این تفاوت را هنگام پرسش ما تأیید کرد:

«Fugu Ultra یک مدل پایه عمومی نیست که Sakana AI آن را با استفاده از فناوری ادغام تکاملی توسعه داده باشد. بلکه هویت عملیاتی من در چارچوب این سامانه ارکستراسیون چندعاملی تعریف شده است.»

البته هنوز مشخص نیست که آیا Sakana AI از الگوریتم‌های تکاملی برای بهینه‌سازی موارد زیر استفاده کرده یا خیر:

• پرامپت‌های ارکستراسیون
• آستانه‌های تصمیم‌گیری برای مسیریابی
• منطق انتخاب مدل‌ها

اما آنچه روشن است این است که معماری زمان اجرا بر پایه ارکستراسیون چندعاملی بنا شده، نه ادغام وزن مدل‌ها.

مسئله هزینه

طبق تعرفه‌های رسمی:

• هر یک میلیون توکن ورودی: ۵ دلار
• هر یک میلیون توکن خروجی: ۳۰ دلار

در نگاه اول، هزینه استفاده از Fugu Ultra چندان زیاد به نظر نمی‌رسد.

اما وقتی سربار ارکستراسیون را در نظر بگیریم، تصویر کاملاً تغییر می‌کند.

به عنوان نمونه، درخواست:

«Python را با Rust مقایسه کن.»

دارای مشخصات زیر بود:

• توکن‌های قابل مشاهده:
  • ۱۷۷ توکن ورودی
  • ۲۰۴۶ توکن خروجی
  • مجموع: ۲۲۲۳ توکن

اما در واقع سیستم:

۲۲٬۷۱۰ توکن

مصرف کرده است.

به بیان دیگر، هزینه واقعی تقریباً ۱۰ برابر چیزی است که کاربر از روی خروجی مشاهده می‌کند.

حتی در ساده‌ترین درخواست‌ها نیز وضعیت چندان بهتر نیست.

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

دلیل اصلی این موضوع همان پرامپت سیستمی ثابت ۱۲۶۰ توکنی است.

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

مهم‌ترین بده‌بستان (Trade-off)

این دقیقاً مهم‌ترین ویژگی معماری چندعاملی است:

در ازای:

• کیفیت بالاتر پاسخ‌ها
• استدلال قوی‌تر
• ترکیب خروجی چند مدل پیشرفته

باید هزینه زیر را پرداخت کرد:

• تأخیر بیشتر
• مصرف توکن بسیار بیشتر
• هزینه نهایی بالاتر

اینکه چنین معامله‌ای ارزش داشته باشد یا نه، کاملاً به نوع کاربرد بستگی دارد.

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

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

نحوه استفاده از Fugu Ultra از طریق درواره

می‌توانید Fugu Ultra را با هر کلاینتی که از API سازگار با OpenAI پشتیبانی می‌کند فراخوانی کنید.

نمونه کد پایتون:

from openai import OpenAIclient = OpenAI(    base_url="https://api.darvareh.ir/v1",    api_key="your-darvareh-api-key",)response = client.chat.completions.create(    model="sakana/fugu-ultra",    messages=[        {"role": "user", "content": "Your query here"}    ],)print(response.choices[0].message.content)print(response.usage)

یا با استفاده از curl:

curl https://api.darvareh.ir/v1/chat/completions \  -H "Authorization: Bearer $DARVAREH_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "model": "sakana/fugu-ultra",    "messages": [{"role": "user", "content": "Your query here"}]  }'

درواره برای هر درخواست امکانات کاملی جهت مشاهده و تحلیل عملکرد (Observability) فراهم می‌کند؛ از جمله:

• تعداد توکن‌های مصرف‌شده
• جزئیات زمان پاسخ
• ردیابی هزینه‌ها

اگر تأخیر Fugu Ultra برای کاربرد شما زیاد باشد، می‌توانید سیاستی برای مسیریابی (Routing Policy) تعریف کنید تا هرگاه زمان پاسخ از حد مشخصی بیشتر شد، درخواست به‌طور خودکار به یک مدل سریع‌تر ارسال شود.

این معماری چه معنایی برای آینده هوش مصنوعی چندعاملی دارد؟

Fugu Ultra یکی از نخستین محصولات تجاری است که به‌جای آنکه صرفاً یک مدل باشد، به‌طور شفاف یک سامانه چندعاملی محسوب می‌شود.

اصل این ایده جدید نیست.

شرکت Anthropic در دسامبر ۲۰۲۴ این الگو را با نام Orchestrator–Workers Pattern معرفی کرده بود.

اما نکته جدید این است که چنین سیستمی اکنون:

• در قالب یک API کاملاً سازگار با OpenAI ارائه شده،
• مانند یک مدل عادی قابل استفاده است،
• و در کنار مدل‌های تک‌مدلی در جدول‌های رتبه‌بندی قرار گرفته است.

این موضوع پیامدهای مهمی برای اکوسیستم مدل‌های زبانی بزرگ (LLM) دارد.

۱. نتایج بنچمارک‌ها بدون زمینه کافی گمراه‌کننده‌اند

اگر مدلی برای رسیدن به امتیاز بالاتر:

• ۱۰ برابر توکن بیشتر مصرف کند،
• و ۱۰ برابر دیرتر پاسخ دهد،

این موضوع باید به‌طور شفاف اعلام شود.

در غیر این صورت، مقایسه یک هماهنگ‌کننده چندعاملی با یک مدل واحد، مقایسه‌ای منصفانه نیست.

این دقیقاً مانند مقایسه دو چیز کاملاً متفاوت است.

۲. ارکستراسیون به یک دسته‌بندی جدید از محصولات تبدیل می‌شود

Fugu Ultra نشان می‌دهد که یک هماهنگ‌کننده خوب طراحی‌شده که روی چند مدل پیشرفته عمومی کار می‌کند، می‌تواند از نظر کیفیت با مدل‌های بزرگ رقابت کند.

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

به عبارت دیگر، مزیت رقابتی از «داشتن بهترین مدل» به سمت «هماهنگ کردن هوشمندانه چند مدل» حرکت می‌کند.

۳. قیمت‌گذاری توکن‌ها باید شفاف‌تر شود

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

نویسندگان مقاله معتقدند API ساکانا در این زمینه رویکرد درستی اتخاذ کرده است؛ زیرا تعداد توکن‌های ارکستراسیون را به‌صورت جداگانه نمایش می‌دهد.

۴. مهم‌ترین نقطه ضعف همچنان تأخیر است

زمان پاسخ بین ۸ تا ۱۶۰ ثانیه باعث می‌شود Fugu Ultra برای کاربردهای بلادرنگ (Real-Time) مناسب نباشد.

اما برای مواردی مانند:

• پردازش دسته‌ای (Batch Processing)
• پژوهش
• تحلیل‌های پیچیده
• مسائل استدلالی

که کیفیت پاسخ مهم‌تر از سرعت است، این معماری گزینه مناسبی محسوب می‌شود.

همچنین می‌توان با استفاده از یک سیاست مسیریابی هوشمند، بسته به نوع مسئله تصمیم گرفت که درخواست به Fugu Ultra ارسال شود یا به یک مدل سریع‌تر.

خودتان آن را امتحان کنید

Fugu Ultra هم‌اکنون در درواره با شناسه:

sakana/fugu-ultra

در دسترس است.

کافی است:

• یک حساب کاربری ایجاد کنید،
• کلید API دریافت کنید،
• و کلاینت سازگار با OpenAI خود را به آدرس زیر متصل نمایید:

api.darvareh.ir/v1

در داشبورد درواره می‌توانید سربار ارکستراسیون را مشاهده کرده و آن را با سایر مدل‌های موجود مقایسه کنید.

اگر بخواهید همان آزمایش‌هایی را که نویسندگان مقاله انجام داده‌اند تکرار کنید، روش کار بسیار ساده است:

1. یک درخواست یکسان را از طریق روتر درواره ارسال کنید.
2. همان درخواست را مستقیماً به API ساکانا بفرستید.
3. سپس شیء usage را در هر دو پاسخ مقایسه کنید.

API ساکانا دو فیلد زیر را برمی‌گرداند:

• orchestration_input_tokens
• orchestration_output_tokens

همین دو مقدار تقریباً تمام اتفاقاتی را که در پشت صحنه رخ می‌دهد آشکار می‌کنند.

پرسش‌های متداول

Fugu Ultra چیست؟

Fugu Ultra یک سامانه ارکستراسیون چندعاملی است که توسط Sakana AI توسعه یافته است.

این سیستم به‌جای اجرای یک مدل واحد، مجموعه‌ای از مدل‌های پیشرفته عمومی (که استفاده از Google Gemini در میان آن‌ها تأیید شده است) را هماهنگ می‌کند.

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

Fugu Ultra در داخل چگونه کار می‌کند؟

این سیستم از یک لایه هماهنگ‌کننده (Orchestrator) استفاده می‌کند که هر درخواست را تحلیل کرده و تصمیم می‌گیرد چند مدل باید فراخوانی شوند.

برای درخواست‌های ساده مانند:

«۲+۲ چند می‌شود؟»

تنها یک عامل فراخوانی می‌شود و حدود ۱۲۶۰ توکن سربار به همراه ۸ تا ۱۲ ثانیه تأخیر ایجاد می‌شود.

اما برای درخواست‌های پیچیده مانند:

• اثبات‌های ریاضی
• مقایسه‌ها
• تحلیل‌های چندمرحله‌ای

چندین مدل به کار گرفته می‌شوند و میزان توکن‌های ارکستراسیون به ۶۰۰۰ تا بیش از ۲۰۰۰۰ توکن می‌رسد؛ در حالی که زمان پاسخ نیز بین ۳۰ تا ۱۶۰ ثانیه خواهد بود.

Fugu Ultra از چه مدل‌هایی استفاده می‌کند؟

هنگامی که با استفاده از یک پرامپت مخصوص اشکال‌زدایی از عامل داخلی سؤال شد، او تأیید کرد که بر پایه Google Gemini اجرا می‌شود.

ممکن است هماهنگ‌کننده نیز از Gemini یا یک مدل کوچک‌تر مخصوص مسیریابی استفاده کند.

توضیح رسمی Sakana AI تنها بیان می‌کند که این سامانه بر پایه مجموعه‌ای از مدل‌های پیشرفته عمومی ساخته شده است.

سربار توکن در Fugu Ultra چقدر است؟

برای درخواست‌های ساده، حدود ۱۲۶۰ توکن ثابت به‌عنوان پرامپت سیستمی مصرف می‌شود.

در درخواست‌های پیچیده، تعداد کل توکن‌ها معمولاً بین ۵ تا ۱۲ برابر بیشتر از توکن‌هایی است که کاربر مشاهده می‌کند.

برای نمونه، درخواست:

«Python را با Rust مقایسه کن.»

حدود ۲۲۲۳ توکن قابل مشاهده تولید می‌کند، اما در پشت صحنه ۲۲٬۷۱۰ توکن مصرف می‌شود.

چگونه می‌توان از طریق درواره از Fugu Ultra استفاده کرد؟

کافی است آدرس پایه (Base URL) را روی:

api.darvareh.ir/v1

قرار دهید و شناسه مدل زیر را استفاده کنید:

sakana/fugu-ultra

درواره علاوه بر مدیریت احراز هویت، امکاناتی مانند:

• مشاهده جزئیات اجرای درخواست،
• تحلیل هزینه،
• و مسیریابی جایگزین در صورت کند بودن یا در دسترس نبودن API ساکانا

را نیز فراهم می‌کند.

آیا Fugu Ultra همان فناوری ادغام تکاملی مدل‌های Sakana AI است؟

خیر.

Sakana AI با فناوری Evolutionary Model Merging شناخته می‌شود؛ روشی که در آن وزن چند مدل هنگام آموزش با یکدیگر ادغام می‌شوند و در نهایت یک مدل واحد به دست می‌آید.

اما Fugu Ultra کاملاً متفاوت است.

این سامانه در زمان اجرا، چند مدل مستقل را هماهنگ می‌کند و هیچ ادغامی در وزن مدل‌ها انجام نمی‌شود.

حتی خود سیستم نیز این تفاوت را به‌صراحت تأیید کرده است.

مقالات مرتبط

• راهنمای جامع Prompt Engineering در هوش مصنوعی
• راهنمای جامع Function Calling در مدل‌های هوش مصنوعی
• راهنمای جامع Tool Calling در مدل‌های زبانی بزرگ
• راهنمای جامع Model Context Protocol (MCP)
• راهنمای جامع AI Agent و عامل‌های هوشمند
• راهنمای جامع Context Window در مدل‌های زبانی
• راهنمای جامع Token در هوش مصنوعی
• راهنمای جامع Streaming API
• راهنمای جامع Batch API