Mercury 3 مدل زبانی شرکت Inception است که از رویکرد Diffusion برای تولید متن استفاده می‌کند. دلیل توجه به این خانواده، تلاش برای کوتاه‌کردن زمان تولید پاسخ در محصولاتی مثل دستیار پشتیبانی، جستجوی تعاملی و ایجنت است. اما برای انتخاب مدل، یک عدد بزرگ کنار «توکن بر ثانیه» کافی نیست؛ کاربر زمان رسیدن به پاسخ درست و قابل استفاده را تجربه می‌کند، نه سرعت یک بخش جدا از سیستم را.
این راهنما بر منابع رسمی بررسی‌شده در ۲۰ اکتبر ۲۰۲۶ تکیه دارد. هدف، توضیح معماری در حد لازم، طراحی آزمایش واقعی و نشان‌دادن مسیر اتصال API است. در این مقاله بنچمارک استنتاج روی Mercury 3 انجام نشده و دسترسی تأییدنشده از مسیر پاستا قطعی معرفی نمیشود. می‌توانید همین چارچوب را برای مقایسه مدل فعلی محصول با هر مدل سریع دیگری نیز استفاده کنید.
مدل زبانی Diffusion چیست؟
در توضیح ساده، مدل‌های خودرگرسیو متن را با وابستگی به توکن‌های قبلی تولید می‌کنند. مدل‌های انتشار یا Diffusion می‌توانند نمایش متن را طی مرحله‌های اصلاح و با پردازش موازی بخش‌هایی از خروجی بسازند. این توضیح یک تصویر مفهومی است؛ جزئیات پیاده‌سازی، شیوه آموزش و سرو کردن هر مدل ممکن است متفاوت باشد. نام معماری به‌تنهایی کیفیت فارسی، دقت ابزار یا هزینه واقعی را تعیین نمی‌کند.
Diffusion فقط برای تصویر نیست. شنیدن این واژه نباید باعث شود Mercury 3 را با مدل نقاشی یا تولید ویدئو اشتباه بگیرید. اینجا موضوع مدل زبانی و خروجی متنی است. همچنین نحوه تولید داخلی و شکل دریافت پاسخ توسط برنامه متفاوت‌اند: یک مدل با معماری متفاوت هم می‌تواند از قراردادی شبیه Chat Completions استفاده کند تا برنامه به بازنویسی کامل نیاز نداشته باشد.
برای برنامه‌نویس، پرسش اصلی این است: آیا می‌توانم پاسخ را به شکل موردنیاز دریافت کنم، هزینه را اندازه بگیرم و هنگام خطا کنترل سیستم را حفظ کنم؟ اگر جواب مثبت باشد، معماری داخلی به یک ویژگی ارزیابی تبدیل میشود، نه الزام به بازطراحی همه محصول. اگر قابلیت ضروری مثل ابزار یا ساختار خروجی در مسیر انتخاب‌شده پشتیبانی نشود، سازگاری ظاهری endpoint کافی نخواهد بود.
چه چیزی درباره Mercury 3 رسماً اعلام شده است؟
در معرفی رسمی Mercury 3 در ۱۹ اکتبر ۲۰۲۶، Inception بر سرعت تولید، زمینه بلند و کاربردهای حساس به تأخیر تأکید کرده است. اعداد سرعت و مقایسه‌های آن صفحه، گزارش سازنده‌اند؛ نه تضمین کیفیت روی زبان فارسی یا زمان پاسخ از شبکه ایران. شرایط آزمایش، طول ورودی و خروجی و ظرفیت سرویس می‌توانند نتیجه را تغییر دهند.
همان معرفی، Mercury Voice و Mercury Decide را به‌عنوان محصولات جدا مطرح می‌کند. اولی روی تجربه صوتی و دومی روی تصمیم و طبقهبندی متمرکز است. از این موضوع نباید نتیجه گرفت که endpoint متنی Mercury 3 همه قابلیت‌های آن دو را دارد. هنگام خرید، نام دقیق مدل، نوع صورتحساب و مسیر درخواست را از مستندات رسمی Inception بررسی کنید.
برای تصمیم تجاری، قیمت رسمی دلاری را با قیمت نهایی ارائه‌دهنده ایرانی برابر نگیرید. تخفیف زمان عرضه ممکن است تمام شود، قیمت کش قواعد جدا داشته باشد و خروجی استدلالی روی مصرف اثر بگذارد. مقایسه را با نرخ فعلی همان مسیری انجام دهید که قرار است در محصول استفاده شود. نرخ قدیمی یک اسکرین‌شات مبنای بودجه ماه بعد نیست.
سرعت توکن، اولین پاسخ و زمان پایان چه فرقی دارند؟
سه ساعت متفاوت دارید. ساعت اول از ارسال درخواست تا دریافت اولین محتوای قابل نمایش می‌گذرد. ساعت دوم تا کامل‌شدن پاسخ ادامه دارد. ساعت سوم از اقدام کاربر در رابط تا نمایش نتیجه قابل استفاده اندازهگیری میشود و زمان شبکه، بازیابی داده، فراخوانی ابزار و رندر مرورگر را هم شامل میشود. بهبود ساعت دوم الزاماً ساعت سوم را به همان نسبت بهتر نمی‌کند.
مثلاً در یک دستیار سفارش، ابتدا باید هویت کاربر بررسی شود و سفارش از سیستم فروش خوانده شود. اگر این دو مرحله کند باشند، جایگزینی مدل فقط بخشی از انتظار را کم می‌کند. در یک پاسخ خیلی کوتاه نیز هزینه ثابت ارتباط و صف ممکن است از زمان تولید متن مهم‌تر باشد. برای همین، سنجش فقط با یک پرامپت طولانی نتیجه مناسبی برای همه کاربردها نمی‌دهد.
| شاخص | معنای عملی | اشتباه رایج |
|---|---|---|
| اولین محتوای قابل نمایش | زمان شروع مشاهده پاسخ توسط کاربر | شمردن یک رویداد خالی به‌عنوان اولین پاسخ |
| زمان تکمیل | مدت دریافت پاسخ کامل و وضعیت پایان | مقایسه خروجی‌های با طول بسیار متفاوت |
| تأخیر انتهابهانتها | زمان از تعامل کاربر تا نتیجه قابل استفاده | حذف زمان دیتابیس، ابزار یا شبکه |
| کیفیت پذیرفته‌شده | درستی پاسخ طبق معیار مشخص | سریع شمردن یک پاسخ اشتباه یا ناقص |
پیش از اتصال، دسترسی مدل را روشن کنید
وجود Mercury در یک ارائه‌دهنده خارجی ثابت نمی‌کند که Mercury 3 با همان نام در پاستا فعال است. ابتدا فهرست مدل‌های API پاستا را بررسی کنید و شناسه دقیق، قابلیت Streaming و شرایط قیمت همان ردیف را ببینید. اگر نام دقیق موجود نبود، شناسه حدسی نسازید و مدل قدیمی خانواده را بی‌توضیح جای نسخه جدید قرار ندهید.
در بررسی کاتالوگ تولید پاستا در ۲۰ اکتبر ۲۰۲۶، شناسه inception/mercury-3 با دسترسی API فعال و قیمت تأییدشده ثبت شده بود. این بررسیِ کاتالوگ با آزمایش استنتاج فرق دارد: اجرای موفق و سنجش سرعت این نسخه از مسیر پاستا برای مقاله تأیید نشده است. پیش از استفاده، وضعیت فعلی و قابلیت موردنیاز را دوباره بررسی کنید. برای اتصال مستقیم سازنده، آدرس و کلید جدا لازم است؛ credential هر مسیر در سرور و محیط آزمایش از production جدا می‌ماند.
پاستا برای مدیریت هزینه تومانی، تنظیم کلید و اتصال مدل‌های موجود به برنامه کاربرد دارد. سازگاری API کمک می‌کند منطق محصول از انتخاب مدل جدا بماند؛ اما نباید آن را تضمین دسترسی به هر مدل تازه یا پشتیبانی کامل همه پارامترها دانست. آموزش اتصال OpenAI SDK به پاستا مسیر تنظیم اولیه را توضیح می‌دهد.