درگاه‌های مدل در برابر API مستقیم؛ کدام معماری برای صورت‌حساب مشتریان برنده است؟

تصور کنید یک تیم مهندسی تازه‌کار در حال ساخت چت‌بات استخدامی برای یک فروشگاه آنلاین است؛ آیا باید مستقیماً با OpenAI، Anthropic و Gemini یکپارچه شوند یا همه چیز را از طریق یک درگاه مدل (Model Gateway) هدایت کنند؟ این تصمیم معماری تعیین می‌کند که تیم در سه ماه آینده وقت خود را صرف نوشتن آداپتورهای اختصاصی برای هر ارائه‌دهنده کند یا مدیریت یک کلید API واحد.

این چالش زمانی رخ می‌دهد که توسعه‌دهندگان می‌خواهند از نمونه‌های اولیه ساده به محیط‌های تولیدی چندمستاجری (Multi-tenant) بروند. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چرا محدودیت‌های نرخ درخواست (Request-based rate limits) اغلب برای SaaSهای هوش مصنوعی شکست می‌خورند اشاره کردیم، چالش اصلی اکنون از دریافت پاسخ ساده به تخصیص دقیق هر سنت از هزینه آن پاسخ به یک مشتری خاص تغییر کرده است. اگر چت‌بات قرار است کاندیداهای شغلی را بر اساس یک دستورالعمل (Rubric) استخدامی ارزیابی کند، تیم باید تصمیم بگیرد کدام محیط اجرایی اجازه می‌دهد هر مکالمه ارزیابی شده را به یک مستاجر نسبت دهد، خطاها را به‌صورت ایمن بازتلاش کند و صورت‌حساب را به‌طور شفاف توضیح دهد.

به نقل از راهنمای کاربردی منتشر شده در ۲۶ سپتامبر ۲۰۲۶، نویسنده استدلال می‌کند که برای اکثر تیم‌های کوچک، هزینه‌های عملیاتی یکپارچگی مستقیم بسیار بیشتر از مزایای کنترل بومی است. مدیریت سه SDK مختلف، سه مجموعه هدر برای محدودیت نرخ و سه صورت‌حساب مجزا که هیچ‌کدام از ارائه‌دهندگان آن‌ها را به‌گونه‌ای طراحی نکرده‌اند که شناسه‌های داخلی مستاجران شما را بفهمند، کابوسی برای بخش مالی است. در نهایت، حسابدار مجبور است سه صورت‌حساب مختلف را به‌صورت دستی با شناسه‌های داخلی مشتریان تطبیق دهد تا متوجه شود هر مشتری چقدر هزینه کرده است.

مزیت تجمیع‌کننده‌ها

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

• صورت‌حساب یکپارچه: بخش مالی به‌جای تطبیق چندین صورت‌حساب از فروشندگان مختلف، تنها یک فاکتور دریافت می‌کند. این امر بار اداری مربوط به تطبیق صورت‌حساب‌ها را به‌شدت کاهش می‌دهد.
• API استاندارد: یک رابط واحد و سازگار با OpenAI، مقدار کدهای آداپتور (Adapter) — شبیه به تبدیل‌های برق که اجازه می‌دهد دوشاخه‌ها به سه شاخه وصل شوند — را که تیم باید نگهداری کند، کاهش می‌دهد. برای مثال، OpenRouter بر دسترسی به مدل‌ها از طریق این API سازگار تمرکز دارد. در این راستا، انتخاب بین مدل‌های مختلف اغلب به قابلیت‌های خروجی آن‌ها بستگی دارد، مشابه آنچه در مقایسه ساختار خروجی Claude و OpenAI برای اتوماسیون بررسی کردیم.
• آزمایش سریع: تغییر از یک مدل به مدل دیگر به‌جای استقرار مجدد کد (Code Deployment)، تنها با یک تغییر در تنظیمات (Configuration) انجام می‌شود. این قابلیت اجازه می‌دهد تا بدون نیاز به آداپتورهای جداگانه برای هر ارائه‌دهنده، آزمایش‌های گسترده‌ای روی مدل‌های مختلف انجام شود.

Infrai به‌طور خاص این مدل را گسترش داده و محیط اجرایی بک‌اند وسیع‌تری را ارائه می‌دهد که در آن یک کلید می‌تواند چندین سرویس هوش مصنوعی و سرویس‌های بک‌اند را پوشش دهد. طبق مستندات عمومی این سرویس، ۲۹۵ قابلیت در ۲۰ ماژول مختلف در دسترس است. این ابزار متادیتای حیاتی پاسخ را ارائه می‌دهد، از جمله هزینه هر فراخوانی (Per-call cost)، ارائه‌دهنده، تأخیر (Latency)، نرخ برخورد با حافظه پنهان (Cache hits) و شناسه‌های درخواست (Request IDs) که برای ردیابی مالی دقیق ضروری هستند.

مسیر ارائه‌دهندگان مستقیم

با وجود سادگی درگاه‌ها، حساب‌های مستقیم تنها راهکار زمانی هستند که قابلیت‌های بومی خاص غیرقابل مذاکره باشند. اگر محصول شما به یک فیلد خاص در درخواست ارائه‌دهنده، یک قرارداد انطباق منطقه‌ای (Regional Compliance) یا ویژگی‌های پیشرویی وابسته است که هنوز توسط درگاه پشتیبانی نمی‌شود، تجمیع‌کننده تبدیل به یک گلوگاه می‌شود. این یک مرز سخت است، نه یک نکته جزئی یا حاشیه‌ای.

یکپارچگی مستقیم نیازمند ساخت یک حلقه کنترل داخلی مستحکم برای هر ارائه‌دهنده است. بک‌اند چت‌بات به سه آداپتور مجزا نیاز دارد که هر کدام باید مسئولیت‌های زیر را بر عهده بگیرد:

۱. احراز هویت: مدیریت اعتبارنامه‌های منحصربه‌فرد و مرزهای حساب برای هر فروشنده.
۲. تجزیه خطا: مدیریت بدنه‌های وضعیت مختلف و پاسخ‌های ۴۲۹ (Too Many Requests) که در هر ارائه‌دهنده متفاوت است.
۳. قوانین بازتلاش: اجرای استراتژی‌های بازگشت نمایی (Exponential Backoff) اختصاصی برای هر ارائه‌دهنده و رعایت هدرهای Retry-After.
۴. نرمال‌سازی مصرف: تبدیل روش‌های مختلف شمارش توکن (Token) — تکه‌های کوچکی از متن که مدل می‌خورد — و مدل‌های سهمیه (Quota) به یک فرمت داخلی پایدار.

پیاده‌سازی دفتر کل مستاجران

نویسنده تأکید می‌کند که فارغ از معماری انتخابی، دفتر کل مستاجران (Tenant Ledger) باید در خودِ برنامه باشد، نه در محیط اجرایی. یک صورت‌حساب یکپارچه، بخش تأمین را ساده می‌کند اما مدل مستاجاری شما را تعریف نمی‌کند. جریان درست باید به این صورت باشد: درخواست مستاجر $ \rightarrow $ بررسی سیاست $ \rightarrow $ مدل مجاز $ \rightarrow $ محیط اجرایی $ \rightarrow $ رویداد مصرف $ \rightarrow $ دفتر کل مستاجر.

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

جزئیات فنی پیاده‌سازی

برای کسانی که از گزینه‌های تجمیعی استفاده می‌کنند، پیاده‌سازی را می‌توان با استفاده از بسته openai در TypeScript عملی کرد. با تنظیم INFRAI_API_KEY و AI_RUNTIME_BASE_URL در سرور، تیم می‌تواند از یک سطح چت مشترک استفاده کند.

• پیکربندی درخواست: کلاینت باید با مهلت زمانی (Timeout) ۳۰ ثانیه و حد maxRetries (مثلاً ۴) تنظیم شود تا بازتلاش‌های خودکار برای خطاهای اتصال، پاسخ‌های ۴۰۸، ۴۰۹، ۴۲۹ و پاسخ‌های سری ۵xx محدود و کنترل شده باشند.
• استخراج متادیتا: سیستم باید مقادیر cost_usd ،latency_ms ،vendor و request_id را از متادیتای پاسخ محیط اجرایی استخراج کند. اگر پاسخ فاقد متادیتای هزینه قطعی و محدود باشد، سیستم باید به‌جای پذیرفتن پاسخ به‌عنوان موفق، یک خطا صادر کند.
• اجرای سیاست‌ها: تیم باید برای ساخت لیست سفید (Allowlist) از شناسه‌های مدل، در دسترس بودن و قیمت‌ها، نقطه انتهایی /v1/ai/models را در سمت سرور فراخوانی کند. این لیست سفید باید طبق یک برنامه زمانی کنترل شده به‌روزرسانی شود.
• سیاست مستاجر: برای هر مستاجر، سیستم باید شناسه‌های مدل‌های مجاز، بودجه حداکثری مکالمه و مجموعه ارائه‌دهندگان یا مناطق تأیید شده را ذخیره کند. درخواست‌هایی که خارج از این سیاست باشند باید قبل از اجرا رد شوند تا از جهش‌های هزینه‌ای مبهم در صورت‌حساب مشترک جلوگیری شود.

مدیریت بازتلاش‌ها و محدودیت نرخ

هوش مصنوعی در محیط تولید نیازمند بازتلاش روی «درخواست» است، نه «اکشن تجاری». برای یک چت‌بات داخلی، رویکرد توصیه شده چهار تلاش با بازگشت نمایی محدود و افزودن Jitter (تغییرات تصادفی کوچک در زمان انتظار) است تا درخواست‌های هم‌زمان مستاجران به‌طور هم‌زمان بیدار نشوند و فشار لحظه‌ای ایجاد نکنند.

وقتی بودجه بازتلاش تمام شد، سیستم باید یک «وضعیت مشغول» (Busy State) مفید را به کاربر نشان دهد. برای جلوگیری از پاسخ‌های تکراری در یک مکالمه، برنامه باید قبل از فراخوانی یک شناسه درخواست (Request ID) اختصاص دهد، آن را همراه با پیام در انتظار ذخیره کند و تنها یک پیام دستیار را برای آن شناسه ثبت (Commit) کند. این موضوع حیاتی است زیرا ابهام در شبکه می‌تواند کلاینت را در مورد اینکه آیا پاسخی تولید شده است یا خیر، نامطمئن کند.

معیارها (Metrics) باید به چهار دسته‌بندی متمایز تقسیم شوند تا دید شفافی ایجاد شود:

• موفق (Success): درخواست به‌طور عادی تکمیل شد.
• محدود شده و سپس بازیابی شده (Throttled then Recovered): سیستم به محدودیت نرخ برخورد کرد اما پس از بازتلاش موفق شد. این نشان‌دهنده ظرفیت سیستم است، نه لزوماً یک حادثه برای مشتری.
• محدود شده و تمام شده (Throttled and Exhausted): بودجه بازتلاش بدون موفقیت مصرف شد. هشدارها (Alerts) باید روی این نرخ تنظیم شوند، نه روی حجم خام خطاهای ۴۲۹.
• شکست غیرقابل بازتلاش (Non-retryable Failure): خطای سطح ۴۰۰ که با انتظار یا بازتلاش برطرف نمی‌شود.

این معیارها باید به تفکیک مستاجر و مدل تحلیل شوند. با این حال، اگر تعداد مستاجران زیاد است، شناسه‌های مستاجر باید در لاگ‌ها یا Traces نگه داشته شوند، نه به‌عنوان برچسب‌های متریک با تعداد مقادیر بالا (Low-cardinality labels).

تحلیل موازنه

انتخاب یک تجمیع‌کننده در واقع معاوضه کنترل مستقیم با کاهش هزینه‌های نگهداری است. ریسک اصلی «تأخیر در وابستگی» (Dependency Lag) است؛ جایی که درگاه ممکن است در پیاده‌سازی یک ویژگی بومی جدید کندتر عمل کند یا یک فیلد خاص در درخواست ارائه‌دهنده را محدود کند.

اگر داده‌های کاندیداها باید طبق یک توافق منطقه‌ای در نزد ارائه‌دهنده خاصی بماند، تیم باید مدل و منطقه را قبل از ارسال ترافیک تأیید کند. آن‌ها نمی‌توانند فرض کنند که یک نام مستعار (Alias) کلی برای مدل، قوانین منطقه‌ای را برآورده می‌کند. تجمیع‌کننده برای مواردی که بخش تدارکات نیازمند قرارداد مستقیم با ارائه‌دهنده است یا محصول به ویژگی‌های بومی مانند صدای بلادرنگ (Real-time Voice)، تعدیل اختصاصی (Dedicated Moderation) یا ارتقای کیفیت تصاویر (Image-upscaling) وابسته است، نامناسب است.

برای یک تیم تازه‌کار، توانایی نگهداری یک بک‌اند کوچک و قابل مدیریت با سیاست‌های متمرکز معمولاً اولویت دارد. اما به محض اینکه یک قانون سخت‌گیرانه ارائه‌دهنده-بر-اساس-منطقه یا یک قابلیت بومی به نیاز محصول تبدیل شود، معماری باید به ارائه‌دهندگان مستقیم بازگردد. این انتقال راحت‌تر است اگر تیم نقطه انتهایی (Endpoint) API را در تنظیمات استقرار (Deployment Configuration) نگه دارد و آن را سخت‌کد نکند، تا آزمایش بین تجمیع‌کننده و ارائه‌دهنده مستقیم بازگشت‌پذیر باشد.

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

گام بعدی شما

• اگر از چندین مدل استفاده می‌کنید، ابتدا یک لایه انتزاع (Abstraction Layer) ساده در کد خود بسازید تا تغییر از درگاه به API مستقیم بدون بازنویسی کل پروژه ممکن باشد.
• سیستم مانیتورینگ خود را به‌گونه‌ای تنظیم کنید که نرخ خطاهای ۴۲۹ را تفکیک کرده و فقط روی «تلاش‌های تمام شده» هشدار دهد.
• برای هر مشتری یک بودجه سخت (Hard Limit) در دیتابیس داخلی تعریف کنید تا از شوک‌های مالی در صورت‌حساب ماهانه جلوگیری کنید.

اما مدیریت این هزینه‌ها تنها بخشی از ماجراست؛ برای بهینه‌سازی واقعی هزینه استنتاج، تحلیل ما درباره استراتژی‌های Distillation را بخوانید.