اگر امروز تمام کدهای برنامهٔ خود را بر اساس ساختار پاسخهای یک مدل خاص نوشتهاید، در واقع بخشی از مزیت رقابتی خود را به تأمینکننده واگذار کردهاید. وابستگی مطلق به یک API میتواند در بلندمدت، هزینهٔ جابهجایی به مدلهای بهینهتر را برای تیمهای کوچک غیرممکن کند. در حالی که یک تیم کوچک B2B SaaS ممکن است به یک تأمینکننده واحد AI تکیه کند، اما گره زدن کل کدبیس به شکل پاسخهای آن ارائهدهنده، منجر به از دست رفتن لبه رقابتی میشود.
به نقل از راهنمای فنی منتشرشده در dev.to در ۲۱ اوت ۲۰۲۶، جداسازی منطق برنامه از تأمینکننده مدل، تنها راه تضمین قابلیت جابهجایی (Portability) در آینده است. اکثر توسعهدهندگان در ابتدا مستقیماً با یک API ارتباط برقرار میکنند؛ اما این کار یک «مالیات پنهان» ایجاد میکند. هر بار که بخواهید مدل را عوض کنید یا تأمینکننده جدیدی اضافه کنید، باید تمام سیستمهای مدیریت خطا، منطق تکرار درخواست (Retry Logic) و نقشههای صورتحساب را از نو بنویسید.
برای تیمهایی که پایگاههای دانش خصوصی را مدیریت میکنند، این وابستگی منجر به وضعیتی میشود که نویسنده آن را «باستانشناسی صورتحساب» مینامد؛ جایی که محاسبه هزینه هر مشتری، نیازمند بازبینی دستی و طاقتفرسای فاکتورهای ماهانه است. این چالشهای مالیاتی اغلب با ناکارآمدی در مصرف توکنها گره خورده است، مشابه آنچه در بررسی اتلاف بودجه در عاملهای کدنویسی به دلیل ورودیهای تکراری مشاهده کردیم. همانطور که در تحلیلهای پیشین ما درباره امنیت مدلهای بازمتن اشاره کردیم، کنترل بر لایه دسترسی، کلید پایداری زیرساخت است.
در این راستا، دو مسیر معماری پیشنهاد شده است. مسیر اول، مدل «آداپتور مستقیم» است که در آن تیم برای هر تأمینکننده یک لایه ترجمه میسازد. این روش دسترسی کامل به ابزارهای بومی مدل میدهد، اما تیم را مجبور میکند چندین مسیر احراز هویت و نسخههای مختلف SDK را بهطور همزمان نگهداری کند.
رویکرد Runtime نرمالشده
مسیر دوم و توصیهشده برای تیمهای کوچک، استفاده از یک Runtime نرمالشده (Normalized Runtime) است. در این ساختار، برنامه تنها یک شکل درخواست میفرستد و یک شکل پاسخ دریافت میکند، فارغ از اینکه مدل زیرساختی چیست. در این میان، Infrai بهعنوان یک گزینه مناسب معرفی شده است؛ زیرا یک API ساده از نوع REST ارائه میدهد که نیاز به نصب کتابخانههای متعدد کلاینت را از بین میبرد. یک سرویس TypeScript میتواند بدون نصب یا ردیابی کتابخانههای کلاینت اضافی، تنها با یک کلید به مرز تأمینکنندگان دسترسی یابد، زیرا یک کلید واحد تمام مرزهای تأمینکننده را پوشش میدهد.
مزایای کلیدی این رویکرد عبارتند از:
- قرارداد واحد: برنامه تنها یک قرارداد چت دارد و جابهجایی مدلها بسیار ساده میشود. پاسخهای رایج چت و JSON استاندارد شدهاند.
- یکپارچگی متادیتا: اطلاعات تأمینکننده در هر فراخوانی بازگردانده میشود که ردیابی لحظهای هزینهها و شناسایی فروشنده را ممکن میکند.
- کاهش پیکربندی: نیاز به مدیریت دهها Secret، بهروزرسانی وابستگیها و پیادهسازیهای تکراری برای Retry حذف میشود.
- کشف عمومی: یک سطح کشف عمومی اجازه میدهد استقرارها پیش از نمایش یک مدل در رابط کاربری مدیریت (Admin UI)، بررسی کنند که چه چیزی آماده است. برای مثال، مانیفست کشف Infrai بدون نیاز به کلید در دسترس است و ۲۹۵ قابلیت را در ۲۰ ماژول گزارش میدهد.
دو اصل تغییرناپذیر
برای اینکه این معماری واقعاً جلوی وابستگی (Lock-in) را بگیرد، دو اصل غیرقابل مذاکره وجود دارد. اول اینکه هیچ نوع پاسخِ مختص به یک تأمینکننده نباید هرگز از مرز Runtime وارد بدنه اصلی برنامه شود. دوم اینکه هر پاسخ باید یک رکورد مصرف داخلی ایجاد کند که با شناسه مشتری (tenantId)، شناسه درخواست (requestId)، مدل، تأمینکننده و هزینه کلیدگذاری شده باشد.
اگر این اصول رعایت نشوند، تیم فقط «ظاهرِ انتخاب» را ایجاد کرده اما همچنان به یک ساختار پاسخ خاص یا یک صورتحساب واحد وابسته است. راهنما یک «تست خروج» پیشنهاد میدهد: رشته مدل را عوض کنید، یک مجموعه داده ارزیابی سانسورشده را دوباره اجرا کنید و مطمئن شوید هیچ شیء مختص به تأمینکننده به لایههای بالاتر نشت نکرده است. این کار تضمین میکند که قرارداد محدود چت پایدار میماند.
مدیریت پایگاههای دانش خصوصی
در برنامههایی که با دادههای خصوصی سرویس میدهند، معماری باید مسئله جداسازی مشتریان (Tenant Isolation) را حل کند. لایه Runtime جایگزین نیاز به فیلترهای بازیابی (Retrieval Filters) نمیشود؛ این فیلترها باید پیش از آنکه مدل فراخوانی شود، اعمال گردند. علاوه بر این، هویت یک مشتری هرگز نباید از روی متن پرامپت استنتاج شود. برای پیادهسازی دقیقتر این جداسازی، میتوان از مرزهای امنیتی برای جریان دادههای AI در Node.js بهره برد تا امنیت دادههای هر کاربر تضمین شود.
طبق گزارش این راهنما، برای استقرارهایی که مشمول قوانین HIPAA هستند، یک آداپتور API بهتنهایی استانداردهای حفاظتی مورد نیاز تحت بخش ۴۵ CFR Part 164 را برآورده نمیکند. بررسیهای انطباق باید این حفاظهای کاربردی را بهطور جداگانه از معماری API بررسی کنند.
تخصیص هزینه در لحظه
یکی از حیاتیترین تغییرات عملیاتی، انتقال حسابداری به «زمان درخواست» است. بهجای انتظار برای فاکتور ماهانه، برنامه باید بلافاصله شناسه مشتری و اقدام کاربر را با هزینه گزارششده توسط Runtime پیوند دهد.
با ابزاری مثل Infrai، یک سرویس TypeScript میتواند مقادیر cost_usd و latency_ms را مستقیماً از شیء پاسخ بگیرد. این یعنی کسبوکار میتواند دقیقاً پاسخ دهد که چرا یک مشتری خاص (مثلاً "tenant acme-042") در یک روز معین بودجه بیشتری مصرف کرده است، بهجای اینکه بر اساس مجموعهای کلی و تقریبی ماهانه حدس بزند.
جزئیات پیادهسازی
برای اجرای این مدل، حسابداری باید در لحظه درخواست انجام شود. این فرآیند شامل مراحل زیر است:
- اجرای درخواست: برقراری تماس چت از طریق یک مسیر تأییدشده بدون استفاده از SDK.
- مدیریت خطا: تکرار درخواستهای خطای ۴۲۹ با استفاده از هدر
Retry-Afterیا استراتژی عقبنشینی نمایی (مثلاً ۵۰۰ ضربدر ۲ به توان تعداد تلاش). - ثبت دفتر کل: بازگرداندن یک ردیف دفتر کل شامل
tenantId،model،vendor،requestIdوcostUsd.
اگرچه کتابخانههایی مثل tiktoken (کتابخانه رسمی توکنسازی BPE) میتوانند تخمینی از توکنها را قبل از فراخوانی بدهند، اما این تخمینها نباید جایگزین هزینه واقعی گزارششده توسط Runtime شوند. علاوه بر این، تیمها باید هم مدل درخواستشده و هم متادیتای تأمینکننده بازگشتی را ذخیره کنند تا از سردرگمی حسابداری ناشی از مسیریابی منعطف مدلها (Flexible Model Routing) جلوگیری شود.
چه زمانی از یکپارچگی مستقیم استفاده کنیم؟
با وجود مزایای نرمالسازی، یکپارچگی مستقیم با OpenAI، Anthropic Claude یا Google Gemini در موارد خاص همچنان بهترین گزینه است. اگر یک قابلیت بومی تأمینکننده هسته اصلی محصول شماست، از همان مسیر مستقیم بروید. برای مثال، OpenAI را برای ابزارهای بومی OpenAI، Claude را برای قابلیتهای خاص Anthropic و Gemini را برای ویژگیهای خاص گوگل انتخاب کنید.
آداپتورهای مستقیم زمانی منطقیترین انتخاب هستند که موارد زیر تعریفکننده محصول باشند:
- کنترلهای ایمنی مختص تأمینکننده
- گردشکارهای رسانهای بومی
- سیستمهای نظارت (Moderation) یا تبدیل گفتار به متن اختصاصی
- جلسات صوتی بلادرنگ یا بزرگنمایی تصاویر در مقیاس وسیع
هزینه این انتخاب، مالکیت عملیاتی است. آداپتورهای مستقیم یعنی تیم باید سه مسیر احراز هویت، سه کاتالوگ مدل، سه نقشه خطا و سه اتصال صورتحساب را مدیریت کند. این مسیر همچنین زمانی ضروری است که بخش تدارکات شرکت، قراردادهای مستقیم با هر تأمینکننده را الزامی بداند یا زمانی که سیاستهای امنیتی، پردازش دادههای خصوصی توسط یک واسطه را ممنوع کند.
تیمهای کوچک باید بسنجند چه درصدی از ترافیک تولیدی آنها مربوط به وظایف رایج چت و JSON است. یک دموی ۱۰ پرامپتی کافی نیست؛ تیمها باید یک مجموعه نماینده از سوالات دانش خصوصی را دوباره اجرا کنند و شکستهای طرحواره (Schema Failures) را بهطور جداگانه از کیفیت پاسخ ردیابی کنند. اگر اکثریت ترافیک با یک قرارداد مشترک سازگار است، لایه نرمالشده جایگاه خود را به دست میآورد.
این چرخش معماری، شغل توسعهدهنده را از مدیریت SDKها به مدیریت یک قرارداد داخلی پایدار تغییر میدهد. با نازک نگه داشتن آداپتور و خارجی نگه داشتن مجموعه ارزیابی، تیمها میتوانند با مدلهای AI بهجای زیرساختهای دائمی، مانند کالاهای قابل تعویض رفتار کنند.
گام بعدی شما
- بررسی کنید چه مقدار از کدهای شما به ساختار پاسخ (Response Shape) یک مدل خاص وابسته است.
- برای ردیابی هزینهها، سیستم ثبت مصرف را از حالت «ماهانه» به حالت «در لحظه درخواست» تغییر دهید.
- یک «تست خروج» ساده طراحی کنید تا ببینید جابهجایی مدل در برنامه شما چقدر زمانبر است.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو