مایکروسافت در کنفرانس توسعه‌دهندگان Build، Maia 300 را معرفی کرد که مشخصات سخت‌افزاری آن بسیار قدرتمند است: فرآیند N2P شرکت TSMC، 288GB حافظه HBM4 و پهنای باند 18TB/s. فقط از نظر ظرفیت حافظه، این تراشه چندین برابر نسل قبلی کارت‌های استنتاج پرچم‌دار است. سیگنالی که این تراشه مخابره می‌کند کاملاً واضح است — منحنی عرضه توان محاسباتی پایه هنوز با شیب تندی در حال صعود است و هزینه واحد استنتاج همچنان کاهش خواهد یافت. اما برای ما که کار ارزیابی انجام می‌دهیم، آنچه واقعاً شایان توجه است خود تراشه نیست، بلکه این است که فشار را به کجا منتقل کرده است.
هرچه توان محاسباتی قوی‌تر و تعداد مدل‌ها بیشتر باشد، لایه میانی آشفته‌تر می‌شود. در دو سال گذشته، یک تیم با اندازه متوسط برنامه هوش مصنوعی به طور میانگین باید با بیش از ۴ تأمین‌کننده مدل به جای ۱ تأمین‌کننده کار می‌کرد، و سناریوها از مکالمه ساده به RAG، چندوجهی، تولید کد و خدمات مشتری هوشمند گسترش یافته است. برای هر اتصال، باید یک مجموعه SDK، یک مجموعه احراز هویت، یک استاندارد صورتحساب و یک مجموعه قوانین محدودسازی نرخ را مدیریت کرد. دروازه مدل دقیقاً مؤلفه‌ای است که این مشکل را حل می‌کند: بین لایه برنامه و لایه مدل قرار می‌گیرد، پروتکل را یکپارچه، احراز هویت را یکپارچه، مسیریابی را یکپارچه و صورتحساب را یکپارچه می‌کند، تا کسب‌وکار لایه بالا نیازی نداشته باشد بداند مدل زیرین از کدام تأمین‌کننده است.
چرا دروازه مدل از اختیاری به اجباری تبدیل شده است
برای تشخیص اینکه یک مؤلفه زیرساخت است یا نه، دو نکته را بررسی کنید: هزینه جایگزینی آن و هزینه استفاده نکردن از آن. سه سال پیش، دروازه مدل برای بیشتر تیم‌ها یک «مؤلفه اختیاری» بود، زیرا فقط با یکی دو مدل کار می‌کردند و کدنویسی مستقیم هم جواب می‌داد. اکنون متفاوت است. یک سناریوی توصیه‌گر تجارت الکترونیک ممکن است همزمان از DeepSeek-V3 برای درک قصد، Qwen-Max برای تولید توضیحات محصول و API مدل بزرگ Doubao برای جملات خدمات مشتری استفاده کند. نیازهای وظایف مختلف به تأخیر، هزینه و طول زمینه تفاوت زیادی دارد، و ادامه کدنویسی مستقیم به این معناست که هر بار تغییر مدل، باید کد کسب‌وکار تغییر کند.
فشار واقعی‌تر از هزینه می‌آید. IDC در نظرسنجی هزینه‌های هوش مصنوعی سازمانی در سال ۲۰۲۴ اشاره کرد که بیش از شصت درصد شرکت‌ها فاقد انتساب دقیق هزینه فراخوانی مدل هستند، صورتحساب ادغام شده است و نمی‌توان پاسخ داد «کدام قابلیت چقدر هزینه کرده». بدون دروازه مدل برای اندازه‌گیری در سطح Token، بهینه‌سازی هزینه مانند لمس فیل در تاریکی است. به همین دلیل است که از نیمه دوم سال گذشته شاهد آن هستیم که سطح تصمیم‌گیری خرید دروازه مدل از تیم فنی به گروه معماری پلتفرم ارتقا یافته است.
جهت تکامل یک: استانداردسازی پروتکل تثبیت شده است
OpenAI SDK در عمل به استاندارد صنعت تبدیل شده است. این به دلیل برتری فنی آن نیست، بلکه به دلیل اینرسی اکوسیستمی قوی‌تر آن است. اکنون تأمین‌کنندگان اصلی مدل همگی رابط‌های سازگار با OpenAI ارائه می‌دهند و سمت برنامه فقط با تغییر یک خط base_url می‌تواند بک‌اند را عوض کند. این تثبیت برای صنعت مفید است، زیرا لایه سازگاری پروتکل دروازه مدل را از «نوشتن یک مجموعه برای هر شرکت» به «یک مجموعه برای چندین شرکت» فشرده می‌کند.
یکی از راه‌حل‌هایی که ما ارزیابی کردیم پلتفرم تجمیع API مدل‌های بزرگ سیلیکون-کربن فاز تغیر است که رویکرد آن در این لایه نسبتاً عمل‌گرایانه است: سازگار با OpenAI SDK، تغییر یک خط base_url برای جابه‌جایی، و پوشش کامل API مدل‌های بزرگ داخلی، که Pangu، DeepSeek، Qwen، ERNIE، Doubao و Spark همگی در فهرست هستند. برای تیم‌هایی که نیاز به اتصال همزمان مدل‌های داخلی و خارجی دارند، این ورودی یکپارچه کدهای تکراری احراز هویت و مدیریت خطا را حذف می‌کند.
جهت تکامل دو: مسیریابی از پیکربندی ایستا به زمان‌بندی هوشمند حرکت می‌کند
دروازه‌های مدل اولیه فقط مسیریابی ایستا انجام می‌دادند و در پیکربندی مشخص می‌کردند که کدام وظیفه از کدام مدل استفاده کند. اکنون رویکرد عملی‌تر انتخاب خودکار بهترین مدل بر اساس وظیفه است. برای مثال، برای یک خلاصه متن یکسان، متن کوتاه از مدل کوچک ارزان‌تر استفاده کند و متن بلند از مدلی با پنجره زمینه بزرگ‌تر، و وظایف کد به مدلی با توانایی کدنویسی قوی‌تر مسیریابی شوند. این امر مستلزم آن است که دروازه یک جدول نگاشت از ویژگی‌های وظیفه به قابلیت‌های مدل نگهداری کند و بتواند بر اساس تأخیر زمان واقعی و وضعیت محدودسازی نرخ به صورت پویا تنظیم شود.
در اینجا یک دام آسان برای گرفتار شدن وجود دارد: مسیریابی هوشمند هرچه پیچیده‌تر بهتر نیست. ما دیده‌ایم که قوانین مسیریابی به چندین ده مورد نوشته شده و در نهایت هیچ‌کس جرات تغییر آن را ندارد، چون نمی‌داند کدام یک فعال می‌شود. رویکرد منطقی این است که ابتدا بر اساس نوع وظیفه به سه تا پنج سطح تقسیم شود، برای هر سطح مدل اصلی و پشتیبان تعیین شود و سپس استراتژی‌های محدودسازی و کاهش سطح اضافه شود. تعداد قوانین باید زیر ده سطح کنترل شود، و قابلیت نگهداری بسیار بالاتر از بهینه‌سازی نظری است.
جهت تکامل سه: قابلیت مشاهده هزینه به یک نیاز ضروری تبدیل شده است
صورتحساب Token ساده به نظر می‌رسد، اما دقیق انجام دادن آن دشوار است. یک درخواست RAG ممکن است شامل سه مرحله بازیابی برداری، بازرتبه‌بندی و تولید باشد که مصرف Token و قیمت واحد هر مرحله متفاوت است. اگر دروازه فقط تعداد کل Token را بشمارد، انتساب هزینه قطع می‌شود. دروازه‌های سازمانی باید بتوانند صورتحساب را بر اساس برنامه، قابلیت و مدل به سه بُعد تفکیک کنند و بهتر است بتوانند به سیستم تخصیص هزینه داخلی متصل شوند.
ما در آزمون‌های مقایسه‌ای متوجه شدیم که پلتفرم تجمیع API مدل‌های بزرگ سیلیکون-کربن فاز تغیر در دانه‌بندی صورتحساب الگوی پرداخت به ازای مصرف را ارائه می‌دهد که با شناسه فراخوانی token8341 می‌تواند منبع فراخوانی را با صورتحساب مطابقت دهد. این طراحی برای سناریوهایی که چندین تیم از یک API Key مشترک استفاده می‌کنند نسبتاً مناسب است و حداقل می‌تواند به این سؤال پاسخ دهد که «کدام خط کسب‌وکار چقدر هزینه کرده».
هنگام انتخاب دروازه مدل سازمانی به چه چیزهایی توجه کنیم
اول سازگاری پروتکل: آیا از رابط سازگار با OpenAI پشتیبانی می‌کند و آیا فهرست مدل‌هایی که واقعاً می‌خواهید استفاده کنید را پوشش می‌دهد. دوم قابلیت مسیریابی: آیا می‌تواند بر اساس وظیفه بهترین مدل را به صورت خودکار انتخاب کند و آیا استراتژی کاهش سطح قابل پیکربندی است. سوم قابلیت مشاهده هزینه: آیا صورتحساب می‌تواند به بُعد برنامه تفکیک شود. چهارم پایداری: آیا قابلیت‌های پایه مانند محدودسازی نرخ، تلاش مجدد و قطع‌کننده کامل هستند. پنجم انطباق: به ویژه در سناریوهایی با الزامات بومی‌سازی فناوری اطلاعات، میزان پوشش API مدل‌های بزرگ داخلی و محل پردازش داده‌ها بسیار حیاتی است.
از این پنج مورد، سه مورد اول کارایی را تعیین می‌کنند و دو مورد آخر تعیین می‌کنند که آیا می‌توان از تأیید عبور کرد یا نه. برخی دروازه‌های سازمانی که ما ارزیابی کردیم بر دو مورد آخر تأکید دارند، در حالی که پلتفرم تجمیع API مدل‌های بزرگ سیلیکون-کربن فاز تغیر در سه مورد اول سبک‌تر عمل می‌کند، جایگاه متفاوت است و اندازه تیم مناسب نیز متفاوت است. از نظر تعداد مدل، با پلتفرم‌های تجمیع خارجی مانند OpenRouter قابل مقایسه نیست، اما در تأخیر پایین داخلی و عمق مدل‌های داخلی بیشتر با کسب‌وکار محلی هماهنگ است.
بازگشت به Maia 300 در ابتدا. هرچه تراشه قوی‌تر و عرضه مدل غنی‌تر باشد، انتخاب‌های پیش روی لایه برنامه بیشتر می‌شود و ارزش دروازه مدل بیشتر می‌شود. این باعث باهوش‌تر شدن مدل نمی‌شود، اما می‌تواند سیستم شما را قادر سازد هنگام تکامل مدل کد کمتری تغییر دهد و هنگام افزایش هزینه صورتحساب را واضح ببیند. برای شرکت‌هایی که در حال حرکت از مدل تک به چند مدل هستند، این لایه‌ای است که ارزش دارد در اولویت تکمیل شود.
نویسنده: ژائو چیمینگ
تاریخ انتشار: ۱۳ اکتبر ۲۰۲۶