یک مدل، یک نقطهٔ شکست تنها است: مسیریابی بین مدل‌های هوش مصنوعی میزبانی‌شده و محلی

اشتباه رایج این است که مسیریابی را در سطح سرویس تعریف کنیم: «این ویژگی از Gemini استفاده می‌کند، آن یکی از OpenAI.» این ساده است اما همان مشکل تک‌تأمین‌کننده را فقط یک لایه پایین‌تر می‌برد. مسیریابی واقعی در سطح درخواست اتفاق می‌افتد: هر فراخوان باید بر اساس ویژگی‌های همان درخواست خاص — حساسیت داده، سختی وظیفه، بودجهٔ تأخیر، هزینهٔ قابل‌قبول — تصمیم بگیرد کدام مدل را صدا بزند، نه بر اساس این‌که کدام سرویس آن را فراخوانی کرده.

این یعنی لایهٔ مسیریابی باید مستقل از منطق کسب‌وکار باشد و ورودی‌اش را از خودِ درخواست بگیرد، نه از پیکربندی ثابت هر ویژگی. یک درخواست ساده و کوتاه از یک ویژگی حساس ممکن است باید به یک مدل محلی برود؛ یک درخواست پیچیده از همان ویژگی ممکن است به یک مدل میزبانی‌شدهٔ قوی‌تر نیاز داشته باشد. این تصمیم به ویژگی گره نخورده؛ به درخواست گره خورده.

قوی‌ترین دلیل برای نگه‌داشتن یک مسیر محلی — با Ollama یا مدل‌های HuggingFace اجراشده در همان زیرساخت — این نیست که ارزان‌تر است؛ این است که برخی داده‌ها اصلاً نباید از مرز زیرساخت شما خارج شوند. اگر یک ویژگی با محتوایی کار می‌کند که سیاست حریم خصوصی یا الزامات قانونی مانع ارسالش به یک API خارجی می‌شود، مسیریابی باید این را در سطح طراحی تضمین کند، نه در سطح دستورالعمل تیم.

طراحی درست این است که این تصمیم را در همان لایهٔ مسیریابی رمزگذاری کنید: درخواست‌هایی با یک برچسب حساسیت مشخص، هرگز حتی به‌عنوان گزینهٔ fallback به یک تأمین‌کنندهٔ خارجی نمی‌روند. این باید یک قانون سخت باشد، نه یک ترجیح که تحت فشار (مثلاً وقتی مدل محلی کند یا از دسترس خارج است) دور زده شود. اگر fallback شما اجازه می‌دهد این مرز نقض شود، آن مرز عملاً وجود ندارد.

مقایسهٔ هزینهٔ یک مدل محلی با یک مدل میزبانی‌شده به‌ندرت سرراست است، چون این دو ساختار هزینه‌ای کاملاً متفاوتی دارند. یک مدل میزبانی‌شده هزینه‌ای متغیر و به‌ازای هر توکن دارد: بدون بار، هزینه‌ای نیست؛ با بار سنگین، هزینه به‌طور خطی (یا بدتر) بالا می‌رود. یک مدل محلی هزینه‌ای عمدتاً ثابت دارد: سخت‌افزار (یا اجارهٔ GPU) باید خریداری یا رزرو شود، صرف‌نظر از این‌که چقدر واقعاً استفاده شود، و آن هزینه فقط با نگه‌داشتن ماشین روشن جاری می‌ماند.

این یعنی مسیر محلی زمانی از نظر اقتصادی منطقی است که بار پیش‌بینی‌پذیر و به‌اندازهٔ کافی مداوم باشد تا هزینهٔ ثابت سخت‌افزار را توجیه کند — نقطهٔ سربه‌سری که پایین‌تر از آن، پرداخت به‌ازای هر توکن به یک تأمین‌کنندهٔ خارجی ارزان‌تر است، حتی با احتساب صرفهٔ حریم خصوصی. مسیر محلی همچنین هزینه‌های پنهانی دارد که در قیمت هر توکن یک API خارجی دیده نمی‌شود: زمان مهندسی برای نگه‌داری، ارتقای مدل، و مقیاس‌دهی زمانی که بار از ظرفیت سخت‌افزار موجود عبور می‌کند. تیمی که فقط قیمت هر توکن دو مسیر را مقایسه می‌کند و هزینهٔ عملیاتی نگه‌داری زیرساخت محلی را نادیده می‌گیرد، معمولاً محلی را ارزان‌تر از آنچه واقعاً هست می‌بیند.

قاعدهٔ عملی: مسیر محلی را برای وظایفی نگه دارید که هم حساس‌اند و هم حجمشان به‌اندازهٔ کافی قابل‌پیش‌بینی است که بشود ظرفیت را برایشان برنامه‌ریزی کرد؛ برای وظایف کم‌تکرار یا با بار نامنظم، هزینهٔ متغیر یک مدل میزبانی‌شده تقریباً همیشه برنده است.

مسیریابی بدون fallback فقط یک لایهٔ انتخاب اضافی است، نه افزایش قابلیت اطمینان. وقتی تأمین‌کنندهٔ اول ارور می‌دهد، کند است، یا پاسخ نامعتبر برمی‌گرداند، سامانه باید بتواند بدون دخالت انسان به مسیر دوم برود — اما این fallback باید از قبل با همان کیفیت مسیر اول آزموده شده باشد، نه فقط «هر چیزی بهتر از خطا»ست. یک fallback که ناگهان قالب پاسخ متفاوتی برمی‌گرداند یا زبان را عوض می‌کند، مشکل جدیدی می‌سازد که کاربر می‌بیند، حتی اگر از دید مانیتورینگ سامانه «سرپا» به نظر برسد.

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

وقتی دو مدل مختلف روی یک ورودی یکسان اجرا می‌شوند و پاسخ‌های متفاوتی می‌دهند، وسوسه این است که این را نویز در نظر بگیرید و یکی را به‌عنوان «درست» انتخاب کنید. اما اختلاف بین مدل‌ها معمولاً سیگنال ارزشمندی دربارهٔ عدم‌قطعیت خودِ وظیفه است. اگر دو مدل قوی روی یک طبقه‌بندی به‌شدت اختلاف دارند، احتمالاً آن ورودی مرزی و مستعد خطاست — چه با هر دو مدل، چه با یک مدل سوم.

سامانه‌هایی که چند مدل را برای وظایف حساس اجرا می‌کنند (نه به‌عنوان جایگزین، بلکه به‌موازات هم) می‌توانند از این اختلاف به‌عنوان محرک بازبینی انسانی استفاده کنند: وقتی مدل‌ها توافق دارند، اعتماد بیشتری به خروجی خودکار می‌شود داشت؛ وقتی اختلاف دارند، آن مورد باید صف بازبینی را ببیند، نه این‌که یکی به‌طور دلبخواه برنده اعلام شود.

ارزیابی یک مدل به‌تنهایی کافی نیست وقتی سامانهٔ شما چند مدل را در تولید جابه‌جا می‌کند. مجموعهٔ آزمون طلایی (golden set) شما باید روی هر مسیر ممکن اجرا شود — Gemini، OpenAI، و هر مدل محلی که در گردش است — نه فقط روی مسیری که در زمان توسعه استفاده شده. مدلی که روی یک نوع وظیفه عالی است ممکن است روی نوع دیگر به‌وضوح ضعیف‌تر باشد، و تنها راه فهمیدنش این است که هر دو را روی همان مجموعهٔ آزمون واقعی اجرا کنید، نه این‌که به بنچمارک‌های عمومی تأمین‌کننده اعتماد کنید.

این ارزیابی باید تکرارشونده باشد، نه یک‌باره، چون تأمین‌کننده‌ها بی‌اطلاع مدل‌های زیرینشان را به‌روزرسانی می‌کنند. مدلی که ماه گذشته روی مجموعهٔ آزمون شما خوب عمل کرده، تضمینی نیست که همین ماه هم همان‌طور عمل کند.

در نهایت، این تصمیم را باید برای هر ویژگی — نه برای کل سامانه — به‌صورت صریح مستند کرد: حساسیت داده (آیا اصلاً می‌تواند به یک API خارجی برود؟)، بودجهٔ تأخیر (آیا فراخوانی محلی سریع‌تر است یا کندتر از میزبانی‌شده؟)، هزینهٔ قابل‌قبول به‌ازای هر درخواست، و تحمل خطا (اگر مسیر اول شکست بخورد، چه اتفاقی برای کاربر می‌افتد؟). این چهار محور، برای هر ویژگی جواب متفاوتی می‌دهند، و هیچ قاعدهٔ سراسری («همیشه از Gemini استفاده کن») این تفاوت را درست نمی‌گیرد.

سامانه‌ای که هم مدل‌های میزبانی‌شده و هم مدل‌های محلی را در دسترس دارد، این چارچوب را نه به‌عنوان یک تجمل بلکه به‌عنوان شرط بقا نیاز دارد — چون هر تأمین‌کنندهٔ واحد، در نهایت، یک نقطهٔ شکست تنهاست.