جداسازی قابلیت‌های هوش مصنوعی از ارائه‌دهندگان برای حذف وابستگی فنی

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

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

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدیریت هزینه‌های استنتاج اشاره کردیم، پایداری عملیاتی نیازمند تغییر دیدگاه است. این چرخش معماری، تصمیم را از «استفاده از ارائه‌دهنده A» به «عدم استفاده از ارائه‌دهندگانی خارج از محدوده جغرافیایی ما، و رد کردن غنی‌سازی‌های غیرضروری پیش از آنکه هزینه از سقف تعیین‌شده عبور کند» تغییر می‌دهد. در واقع، این رویکرد یک انتخاب موقت در پیاده‌سازی را به یک محدودیت عملیاتی قابل تست، بازبینی و بادوام تبدیل می‌کند؛ حتی اگر ارائه‌دهنده A به‌طور کامل از لیست حذف شود.

هزینه وابستگی به ارائه‌دهنده

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

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

پیاده‌سازی مسیریابی مبتنی بر قابلیت

Infrai مدلی را پیشنهاد می‌دهد که در آن هر قابلیت، یک مجموعه از ترجیحات مسیریابی دارد. در این سیستم، یک Worker آپلود و یک Job پردازش شبانه، هر دو به یک «قرارداد قابلیت» وابسته هستند. هیچ‌کدام از آن‌ها نمی‌دانند ارائه‌دهنده کیست یا آن را انتخاب نمی‌کنند. بنابراین، تغییر آنچه در پشت این قرارداد قرار دارد، هیچ تغییری در کد آن‌ها ایجاد نمی‌کند.

• اولویت حذف بر انتخاب: سیستم به‌جای «همیشه از X استفاده کن»، ترجیح می‌دهد بگوید «ارائه‌دهندگانی که این شرط را ندارند حذف شوند». این روش منعطف‌تر است چون اجازه می‌دهد ارائه‌دهندگان جدیدی که واجد شرایط هستند، به‌طور خودکار وارد چرخه شوند. در مقابل، یک «پین» یا تثبیت، مسیر بهبود را مسدود می‌کند تا زمانی که کسی به‌صورت دستی آن را پیدا کرده و تغییر دهد.
• استثنای پین کردن: تثبیت یک ارائه‌دهنده (Pinning) در واقع خریدِ اطمینان در لحظه در ازای دست کشیدن از بهبودهای آینده است. این کار تنها زمانی توجیه دارد که یک گواهینامه قراردادی، نیاز به بازتولید دقیق نتایج (Reproducibility) یا یک فرمت خروجی بسیار خاص و تایید شده مورد نیاز باشد.
• وضعیت متمرکز: وضعیت مسیریابی از طریق یک مسیر API واحد خوانده می‌شود. با قرار دادن منشأ در پیکربندی محیط (Environment Configuration)، کلیدهای API و تنظیمات استقرار از کد منبع خارج می‌شوند. این ساختار به سیستم اجازه می‌دهد محدودیت‌های نرخ (Rate Limits) را بدون ایجاد حلقه‌های تکرار فشرده مدیریت کند و در صورت بروز خطا، بدنه پاسخ را نمایش دهد.

آزمایش نردبان رد درخواست

برای حجم‌های کاری رسانه‌ای که با موجودی پیش‌پرداخت اجرا می‌شوند، حیاتی‌ترین سیاست، ترکیب یک سقف هزینه با یک مسیر رد (Refusal Path) صریح است. در اینجا محور تصمیم‌گیری ملموس است: سقف بالاتر ترافیک بیشتری را عبور می‌دهد و سقف پایین‌تر ریسک هزینه را کم می‌کند اما زودتر درخواست‌ها را رد می‌کند.

Infrai برای تست این موضوع، یک سیستم دوکلاسه پیشنهاد می‌کند: کارهای «ضروری» و «اختیاری». فرض کنید یک بودجه ۱۰۰ دلاری دارید. شرح‌نویسی ضروری می‌تواند از هر مسیر واجد شرایط تا رسیدن به سقف سخت استفاده کند. اما غنی‌سازی اختیاری در یک گاردریل زودتر — مثلاً وقتی فقط ۲۰ دلار باقی مانده — متوقف می‌شود. در اینجا اعداد دقیق اهمیت کمتری دارند نسبت به داشتن دو تصمیم به‌طور عمدی متفاوت برای تست مسیر مؤثر و نتیجه رد درخواست پیش از استقرار نهایی.

این منطق رد درخواست باید در کنار پذیرش بودجه باشد، نه داخل یک Wrapper در SDK. با تبدیل «نردبان رد» به یک تصمیم محصولی و «بک‌اند نهایی» به یک سیاست زیرساختی، تیم‌ها از تغییرات ناگهانی در رفتار هزینه‌ها جلوگیری می‌کنند. این تفکیک همچنین از یک خطای دسته‌بندی رایج جلوگیری می‌کند: گارد بودجه تصمیم می‌گیرد که آیا کار پیش برود یا خیر، در حالی که ترجیحات مسیریابی تصمیم می‌گیرند کدام بک‌اند واجد شرایط می‌تواند آن را ارائه دهد. ادغام هر دو در یک «پین ارائه‌دهنده»، حسابرسی و تست رفتار هزینه‌ها را دشوار می‌کند.

مقایسه صفحات کنترل

محصولات مختلف، صفحات کنترل متفاوتی ارائه می‌دهند. قانون طراحی مستقل ساده است: صفحه‌ای را انتخاب کنید که دامنه آن با محدودیت شما همخوانی داشته باشد.

• AWS Bedrock inference profiles: بهترین گزینه برای تیم‌هایی است که در اکوسیستم AWS هستند و به یک سطح مسیریابی مدیریت‌شده نیاز دارند. محدودیت این است که سیاست‌ها به صفحه کنترل Bedrock و مدل‌ها و مناطق مورد حمایت آن گره خورده است.
• Google Vertex AI Model Garden: ایده‌آل برای تیم‌هایی که دسترسی به مدل‌ها و حاکمیت داده را در گوگل کلاود استاندارد می‌کنند. نقطه ضعف این است که معماری اپلیکیشن به منابع و مفاهیم استقرار Vertex AI وابسته می‌ماند.
• OpenRouter provider routing: برای اپلیکیشن‌هایی مفید است که می‌خواهند ترتیب ارائه‌دهندگان، اجازه دسترسی یا حذف آن‌ها را در نزدیکی هر درخواست مدل تعیین کنند. با این حال، آزادی در سطح درخواست می‌تواند باعث انحراف سیاست‌ها شود مگر اینکه اپلیکیشن این ترجیحات را متمرکز کند.
• Kong Gateway, Apigee, or Tyk: مناسب برای تیم‌هایی که به یک Gateway عمومی نیاز دارند و می‌خواهند منطق مسیریابی را خودشان بسازند. در اینجا تیم باید مالک مدل صلاحیت ارائه‌دهنده و نگهداری آن باشد.
• Stripe Billing: مدیریت شارژ حساب و استحقاق‌ها را بر عهده دارد. این ابزار می‌تواند هزینه را کنترل کند، اما یک صفحه کنترل برای مسیریابی ارائه‌دهنده نیست و باید در کنار مسیریاب استفاده شود، نه به‌جای آن.

Infrai زمانی کاربرد دارد که مرز مورد نظر، یک «قابلیت» مشترک بین چندین نقطه فراخوانی باشد. رابط کاربری آن ۲۹۵ مسیر را در ۲۰ ماژول پوشش می‌دهد تا قرارداد فراخوانی ثابت بماند، حتی اگر ارائه‌دهنده تغییر کند. این ابزار متادیتای ارائه‌دهنده، تأخیر، هزینه، کش و متادیتای درخواست را برای هر فراخوانی جهت انتساب‌های بعدی پشتیبانی می‌کند. این ابزار برای مواردی که سیاست‌ها باید کاملاً داخل یک صفحه کنترل ابری بمانند یا مهندسان بخواهند منطق Gateway سفارشی بنویسند، مناسب نیست.

حسابرسی و اندازه‌گیری

هر تغییر در مسیریابی به دو رکورد مجزا نیاز دارد: قصد اعلام‌شده و نتیجه مؤثر. قصد باید پاسخ دهد که چرا یک ارائه‌دهنده حذف یا تثبیت شده، چه قابلیتی تحت تأثیر است، چه کسی آن را تأیید کرده و چه زمانی باید بازبینی شود. نتیجه باید نشان دهد کدام ارائه‌دهنده واقعاً پاسخ داده و متادیتای هزینه و تأخیر را به همراه یک شناسه درخواست ثبت کند.

پیکربندی نشان می‌دهد اپراتورها چه خواسته‌اند و تله‌متری نشان می‌دهد چه اتفاقی افتاده است. هیچ‌کدام جایگزین دیگری نیستند. برای یک حجم کاری رسانه‌ای، اپراتورها باید تعداد ردهای هر کلاس کاری، موجودی باقی‌مانده، هزینه بر اساس قابلیت، ارائه‌دهنده نهایی و سن هر «پین» را مانیتور کنند. تیم‌ها باید برای افزایش ناگهانی ردهای «شرح‌نویسی ضروری» هشدار فعال کنند، در حالی که ردهای «غنی‌سازی اختیاری» را به عنوان یک کنترل برنامه‌ریزی‌شده در نظر بگیرند.

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

قبل از اعمال این محدودیت‌ها، تیم‌ها باید «تصمیمات سایه» (Shadow Decisions) را اجرا کنند. این یعنی محاسبه کنیم که آیا یک Job اجازه اجرا می‌یافت یا رد می‌شد، بدون اینکه واقعاً کاری را در محیط تولید متوقف کنیم. سپس این نتیجه را با سطح خدمات (SLA) مورد نیاز مقایسه کنیم. توزیع داده‌ها را ثبت کنید، نه فقط میانگین را؛ زیرا یک مجموع روزانه می‌تواند جهش‌های شدید آپلود را که موجودی را پیش از بررسی بعدی تخلیه می‌کند، پنهان کند.

چهار معیار کلیدی را قبل از اجرا اندازه بگیرید:
۱. تعداد کارهای ضروری که رد می‌شدند.
۲. میزان کارهای اختیاری که متوقف می‌شدند.
۳. دفعات تغییر مسیر مؤثر تحت سیاست حذف.
۴. سرعت توضیح یک مسیر انتخاب‌شده از طریق رکورد حسابرسی.

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

گام بعدی شما

• بررسی کنید آیا در کد شما نام ارائه‌دهندگان مدل‌ها (مانند OpenAI یا Anthropic) به‌صورت سخت‌افزاری تکرار شده است یا خیر.
• یک لیست از «قابلیت‌های» اپلیکیشن خود (مثلاً: خلاصه‌سازی، استخراج موجودیت) تهیه کنید و آن‌ها را از نام مدل‌ها جدا کنید.
• برای کارهای غیرضروری، یک سقف بودجه پایین‌تر از کارهای حیاتی تعریف کنید تا در زمان بحران، فقط خدمات لوکس متوقف شوند.

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