AI Gateway چیست؟ معماری دروازۀ هوش مصنوعی و تفاوت آن با API Gateway

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

اتصال مستقیم یک نرم‌افزار به یک مدل در مرحلۀ آزمایش ساده به نظر می‌رسد. توسعه‌دهنده یک API Key دریافت می‌کند، درخواست را به Endpoint ارائه‌دهنده می‌فرستد و پاسخ مدل را در برنامه نمایش می‌دهد.

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

• اگر ارائه‌دهنده از دسترس خارج شود چه اتفاقی می‌افتد؟
• اگر مدل انتخاب‌شده بیش از حد گران باشد چه باید کرد؟
• چگونه می‌توان درخواست‌ها را میان چند مدل مسیریابی کرد؟
• مصرف توکن هر کاربر یا سازمان چگونه محاسبه می‌شود؟
• چگونه API Key ارائه‌دهندگان را از کلاینت مخفی کنیم؟
• اگر قالب API ارائه‌دهندگان متفاوت باشد، برنامه چگونه باید با آن‌ها کار کند؟
• چگونه Promptها، پاسخ‌ها، هزینه و زمان پردازش را مانیتور کنیم؟
• چگونه از ارسال اطلاعات حساس به مدل‌ها جلوگیری کنیم؟
• اگر مدل جدیدی بهتر یا ارزان‌تر شد، چگونه بدون تغییر گستردۀ کد از آن استفاده کنیم؟

AI Gateway برای پاسخ دادن به همین مسائل طراحی شده است.

AI Gateway یا دروازه هوش مصنوعی، لایه‌ای زیرساختی میان نرم‌افزارها و مدل‌های هوش مصنوعی است. این لایه دسترسی به مدل‌ها را یکپارچه می‌کند و مسئولیت‌هایی مانند احراز هویت، مسیریابی مدل، کنترل مصرف، مدیریت هزینه، Fallback، ثبت لاگ و اعمال سیاست‌های امنیتی را بر عهده می‌گیرد.

در این مقاله به‌صورت جامع و فنی بررسی می‌کنیم AI Gateway چیست، چه تفاوتی با API Gateway و LLM Gateway دارد، از چه اجزایی تشکیل شده است و چگونه می‌توان از آن در معماری یک محصول واقعی استفاده کرد.

AI Gateway چیست؟

AI Gateway یک لایۀ واسط میان نرم‌افزار مصرف‌کننده و سرویس‌های هوش مصنوعی است. برنامه به‌جای اتصال مستقیم به هر ارائه‌دهنده، درخواست‌های خود را به AI Gateway ارسال می‌کند.

Gateway سپس بر اساس تنظیمات و سیاست‌های تعریف‌شده:

1. هویت ارسال‌کننده را بررسی می‌کند.
2. اعتبار و بودجۀ حساب را کنترل می‌کند.
3. مدل منطقی را به مدل واقعی نگاشت می‌کند.
4. ارائه‌دهندۀ مناسب را انتخاب می‌کند.
5. درخواست را به قالب موردنیاز ارائه‌دهنده تبدیل می‌کند.
6. درخواست را به مدل ارسال می‌کند.
7. خطا، Timeout و Rate Limit را مدیریت می‌کند.
8. میزان مصرف توکن و هزینه را محاسبه می‌کند.
9. متریک‌ها و اطلاعات عملیاتی را ثبت می‌کند.
10. پاسخ را در قالبی استاندارد به برنامه بازمی‌گرداند.

در ساده‌ترین حالت، معماری به این شکل است:

Application
    ↓
AI Gateway
    ↓
AI Models and Providers

اما در یک محیط واقعی، AI Gateway چندین مسئولیت هم‌زمان دارد:

Web, Mobile, Backend, Agent
               ↓
           AI Gateway
               ↓
 Authentication • Routing • Budget • Logging • Guardrails
               ↓
 OpenAI • Anthropic • Google • Open-source Models • Local Models

بنابراین AI Gateway صرفاً یک Proxy برای ارسال درخواست نیست؛ بلکه لایۀ کنترل، سیاست‌گذاری و مشاهده‌پذیری زیرساخت هوش مصنوعی است.

چرا نام «درواره» انتخاب شده است؟

«درواره» برابر فارسی پیشنهادی برای واژۀ Gateway است. Gateway در معماری نرم‌افزار به نقطه‌ای گفته می‌شود که درخواست‌ها از طریق آن وارد یک سامانه یا شبکۀ خدمات می‌شوند.

نام «درواره» نیز بر همین مفهوم استوار است: یک درگاه یا لایۀ اتصال که نرم‌افزارها را به اکوسیستم گستردۀ هوش مصنوعی متصل می‌کند.

در این معماری، توسعه‌دهنده به‌جای ایجاد و نگهداری اتصال جداگانه به هر مدل یا ارائه‌دهنده، از یک API واحد استفاده می‌کند. درواره درخواست را دریافت می‌کند و آن را به مدل انتخاب‌شده در اکوسیستم هوش مصنوعی هدایت می‌کند.

این مفهوم را می‌توان با یک عبارت خلاصه کرد:

یک اتصال برای دسترسی به تمام اکوسیستم هوش مصنوعی

AI Gateway چه مشکلی را حل می‌کند؟

پراکندگی ارائه‌دهندگان

مدل‌های هوش مصنوعی توسط شرکت‌ها و زیرساخت‌های مختلف ارائه می‌شوند. هر ارائه‌دهنده ممکن است موارد زیر را به شکل متفاوتی پیاده‌سازی کند:

• Endpointها
• روش احراز هویت
• ساختار درخواست
• قالب پاسخ
• نام مدل‌ها
• Streaming
• Tool Calling
• Structured Output
• محدودیت توکن
• مدیریت خطا
• قیمت‌گذاری

اتصال مستقیم به چند ارائه‌دهنده باعث می‌شود منطق اختصاصی هرکدام وارد کد اصلی محصول شود.

AI Gateway این تفاوت‌ها را پشت یک رابط واحد پنهان می‌کند.

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

اگر تمام بخش‌های برنامه مستقیماً به API یک شرکت متصل باشند، تغییر ارائه‌دهنده یا مدل دشوار خواهد بود. این وضعیت Vendor Lock-in نامیده می‌شود.

وابستگی می‌تواند در چند سطح ایجاد شود:

• قالب API
• نام مدل
• ساختار پیام
• نحوۀ Streaming
• فرمت Tool Calling
• مدیریت فایل و تصویر
• قالب خطاها
• روش محاسبۀ توکن

AI Gateway یک لایۀ انتزاع ایجاد می‌کند تا کد برنامه کمتر به جزئیات یک ارائه‌دهندۀ خاص وابسته باشد.

ناپایداری مدل‌ها

حتی سرویس‌های بزرگ نیز ممکن است با مشکلات زیر مواجه شوند:

• افزایش زمان پاسخ
• خطای موقت
• Rate Limit
• توقف یک مدل
• کاهش ظرفیت منطقه‌ای
• تغییر نسخه
• محدودیت حساب
• اختلال ارائه‌دهنده

اگر برنامه فقط به یک مدل و یک ارائه‌دهنده متصل باشد، این مشکلات مستقیماً به کاربر منتقل می‌شوند.

AI Gateway می‌تواند در صورت بروز خطا، درخواست را به مدل یا ارائه‌دهندۀ جایگزین منتقل کند.

کنترل هزینه

هزینۀ استفاده از مدل‌ها یکسان نیست. قیمت ممکن است بر اساس این موارد محاسبه شود:

• توکن ورودی
• توکن خروجی
• توکن Cache‌شده
• تعداد تصویر
• وضوح تصویر
• مدت صوت یا ویدئو
• زمان پردازش
• تعداد فراخوانی ابزار
• مدل یا ارائه‌دهنده

بدون یک لایۀ مرکزی، محاسبۀ دقیق هزینه در محصولی که از چند مدل استفاده می‌کند پیچیده خواهد شد.

AI Gateway می‌تواند مصرف را در سطح‌های مختلف ثبت و کنترل کند:

• کاربر
• تیم
• سازمان
• API Key
• پروژه
• محیط
• مدل
• Endpoint
• ارائه‌دهنده

امنیت کلیدها و داده‌ها

اگر API Key ارائه‌دهنده در اپلیکیشن وب، موبایل یا نرم‌افزار دسکتاپ قرار گیرد، امکان استخراج و سوءاستفاده از آن وجود دارد.

با استفاده از AI Gateway، کلاینت فقط کلید داخلی یا Token مربوط به پلتفرم را دریافت می‌کند و کلید اصلی ارائه‌دهنده در زیرساخت امن نگهداری می‌شود.

Gateway همچنین می‌تواند داده‌های حساس را پیش از ارسال به مدل شناسایی یا حذف کند.

معماری AI Gateway

یک AI Gateway حرفه‌ای معمولاً از چند لایۀ اصلی تشکیل می‌شود.

لایۀ ورودی درخواست

این لایه درخواست‌های نرم‌افزارها را از طریق پروتکل‌ها و Endpointهای مختلف دریافت می‌کند:

• REST API
• API سازگار با OpenAI
• WebSocket
• Server-Sent Events
• gRPC
• Webhook
• Batch API

در بسیاری از محصولات، سازگاری با API شرکت OpenAI به یک استاندارد عملی تبدیل شده است. در این حالت، توسعه‌دهنده معمولاً با تغییر Base URL و API Key می‌تواند برنامه را به Gateway متصل کند.

لایۀ احراز هویت

در این بخش هویت مصرف‌کننده بررسی می‌شود. روش‌های رایج عبارت‌اند از:

• API Key
• JWT
• OAuth 2.0
• امضای درخواست
• Service Account
• Mutual TLS

هر کلید می‌تواند سیاست‌های خاص خود را داشته باشد:

• مدل‌های مجاز
• محدودیت درخواست در دقیقه
• سقف مصرف روزانه یا ماهانه
• محدودیت بودجه
• IPهای مجاز
• تاریخ انقضا
• محیط مجاز
• Tenant مرتبط

لایۀ سیاست‌گذاری

Policy Engine مشخص می‌کند هر درخواست تحت چه شرایطی پذیرفته یا رد شود.

برای مثال:

اگر بودجه پروژه تمام شده است → رد درخواست
اگر مدل برای این API Key مجاز نیست → رد درخواست
اگر ورودی حاوی اطلاعات حساس است → حذف یا رد درخواست
اگر تعداد درخواست بیش از حد است → پاسخ 429
اگر مدل اصلی در دسترس نیست → استفاده از مدل جایگزین

سیاست‌ها می‌توانند در سطح پلتفرم، سازمان، پروژه، API Key یا مدل تعریف شوند.

لایۀ مسیریابی مدل

Model Router یکی از مهم‌ترین اجزای AI Gateway است. این بخش تعیین می‌کند درخواست به کدام مدل و ارائه‌دهنده ارسال شود.

تصمیم مسیریابی می‌تواند بر اساس موارد زیر باشد:

• نام مدل درخواست‌شده
• نوع وظیفه
• پیچیدگی Prompt
• اندازۀ Context
• زبان ورودی
• قابلیت Tool Calling
• پشتیبانی از تصویر یا صوت
• قیمت مدل
• زمان پاسخ
• وضعیت سلامت ارائه‌دهنده
• Rate Limit باقی‌مانده
• محل نگهداری داده
• سیاست سازمان
• کیفیت تاریخی مدل

لایۀ سازگارکننده ارائه‌دهندگان

Provider Adapter درخواست استاندارد Gateway را به قالب موردنیاز هر ارائه‌دهنده تبدیل می‌کند.

این لایه معمولاً مسئول تبدیل موارد زیر است:

• ساختار Message
• پارامترهای مدل
• قالب Tool
• تنظیمات Structured Output
• Image Input
• Audio Input
• Streaming Event
• Usage Metadata
• Error Response

پاسخ ارائه‌دهنده نیز باید دوباره به قالب استاندارد Gateway تبدیل شود.

لایۀ کنترل هزینه و مصرف

این بخش تعداد توکن‌ها، قیمت مدل، نرخ تبدیل ارز و سیاست قیمت‌گذاری را بررسی می‌کند.

اطلاعات قابل ثبت می‌توانند شامل موارد زیر باشند:

• توکن ورودی
• توکن خروجی
• Cached Token
• Reasoning Token
• هزینه ارائه‌دهنده
• هزینه نهایی کاربر
• زمان پردازش
• تعداد Retry
• مدل درخواست‌شده
• مدل واقعی استفاده‌شده
• ارائه‌دهندۀ نهایی

لایۀ مشاهده‌پذیری

Observability در AI Gateway فقط به بررسی کد وضعیت HTTP محدود نمی‌شود. یک درخواست ممکن است از نظر فنی موفق باشد، اما پاسخ مدل کیفیت لازم را نداشته باشد.

بنابراین مشاهده‌پذیری شامل چند سطح است:

• وضعیت فنی درخواست
• Latency
• مصرف توکن
• هزینه
• خطاهای ارائه‌دهنده
• نرخ Fallback
• کیفیت پاسخ
• ساختار خروجی
• موفقیت Tool Calling
• رضایت کاربر
• ایمنی محتوا

تفاوت AI Gateway و API Gateway

API Gateway برای مدیریت عمومی APIها طراحی شده است، اما AI Gateway نیازهای اختصاصی مدل‌های هوش مصنوعی را نیز پوشش می‌دهد.

یک API Gateway عمومی می‌تواند جلوی AI Gateway قرار گیرد، اما معمولاً به‌تنهایی جایگزین آن نیست.

برای مثال، API Gateway می‌تواند TLS، WAF و احراز هویت عمومی را انجام دهد؛ سپس AI Gateway مسیریابی مدل، کنترل توکن، Fallback و ثبت هزینه را مدیریت کند.

تفاوت AI Gateway و LLM Gateway

اصطلاح‌های AI Gateway و LLM Gateway گاهی به‌جای یکدیگر استفاده می‌شوند، اما دامنۀ آن‌ها می‌تواند متفاوت باشد.

LLM Gateway عمدتاً بر مدل‌های زبانی بزرگ و قابلیت‌هایی مانند موارد زیر تمرکز دارد:

• Chat Completion
• Text Generation
• Embedding
• Tool Calling
• Structured Output
• Prompt Management

AI Gateway می‌تواند دامنه‌ای گسترده‌تر داشته باشد و مدل‌های مختلف را پوشش دهد:

• متن
• تصویر
• صوت
• ویدئو
• Embedding
• Reranking
• Speech-to-Text
• Text-to-Speech
• مدل‌های چندوجهی
• مدل‌های تولید کد

بنابراین هر LLM Gateway را می‌توان نوعی AI Gateway دانست، اما یک AI Gateway لزوماً به مدل‌های زبانی محدود نیست.

تفاوت AI Gateway و AI Router

AI Router یا Model Router معمولاً یکی از اجزای AI Gateway است.

Router تصمیم می‌گیرد درخواست به کدام مدل ارسال شود؛ اما Gateway مسئولیت‌های بیشتری دارد:

• احراز هویت
• مدیریت کلید
• ثبت مصرف
• کنترل موجودی
• Rate Limiting
• استانداردسازی API
• مدیریت خطا
• لاگ و مانیتورینگ
• امنیت داده
• اجرای سیاست‌ها

ممکن است یک محصول فقط Router باشد و وظیفۀ انتخاب مدل را انجام دهد. AI Gateway یک لایۀ کامل‌تر برای مدیریت چرخه درخواست هوش مصنوعی است.

مسیریابی مدل چگونه انجام می‌شود؟

مسیریابی صریح

در این روش، برنامه نام مدل را مستقیماً مشخص می‌کند:

{
  "model": "selected-model",
  "messages": [
    {
      "role": "user",
      "content": "این متن را خلاصه کن."
    }
  ]
}

Gateway مدل مشخص‌شده را به ارائه‌دهندۀ مناسب هدایت می‌کند.

این روش ساده و قابل‌پیش‌بینی است، اما تصمیم انتخاب مدل همچنان بر عهدۀ برنامه قرار دارد.

مسیریابی مبتنی بر Alias

برنامه به‌جای نام واقعی مدل، از یک نام منطقی استفاده می‌کند:

fast-model
balanced-model
reasoning-model
vision-model

Gateway این Alias را به یک مدل واقعی نگاشت می‌کند:

fast-model      → مدل سریع و اقتصادی
balanced-model  → مدل عمومی
reasoning-model → مدل استدلالی
vision-model    → مدل چندوجهی

مزیت این روش آن است که مدل واقعی بدون تغییر کد برنامه قابل‌تعویض است.

مسیریابی بر اساس هزینه

Gateway می‌تواند ارزان‌ترین مدلی را انتخاب کند که شرایط درخواست را برآورده می‌کند.

برای مثال:

اگر درخواست ساده و کوتاه است → مدل اقتصادی
اگر نیازمند استدلال پیچیده است → مدل قدرتمند
اگر تصویر دارد → مدل چندوجهی

انتخاب صرفاً بر اساس ارزان‌ترین قیمت مناسب نیست؛ زیرا کاهش کیفیت می‌تواند باعث Retry، نارضایتی کاربر یا هزینه‌های غیرمستقیم شود.

مسیریابی بر اساس Latency

برای قابلیت‌هایی مانند پیشنهاد خودکار، تکمیل متن یا چت زنده، زمان پاسخ اهمیت زیادی دارد. Gateway می‌تواند با استفاده از متریک‌های اخیر، ارائه‌دهنده‌ای با Latency کمتر را انتخاب کند.

مسیریابی بر اساس قابلیت

همۀ مدل‌ها از قابلیت‌های یکسانی پشتیبانی نمی‌کنند. Router باید نیاز درخواست را با قابلیت مدل تطبیق دهد:

• Tool Calling
• JSON Schema
• ورودی تصویر
• Context طولانی
• Streaming
• تولید کد
• Embedding
• زبان فارسی
• پردازش فایل

مسیریابی بر اساس کیفیت

Gateway می‌تواند نتایج ارزیابی‌های قبلی را در تصمیم‌گیری دخالت دهد. برای مثال، مدلی که در استخراج اطلاعات از فاکتورهای فارسی عملکرد بهتری دارد، برای همان وظیفه انتخاب شود.

مسیریابی ترکیبی

در محیط Production معمولاً چند معیار به‌صورت هم‌زمان بررسی می‌شوند:

قابلیت لازم
    ↓
مدل‌های مجاز سازمان
    ↓
محدودیت Context
    ↓
سلامت ارائه‌دهنده
    ↓
قیمت و Latency
    ↓
انتخاب مقصد نهایی

Fallback در AI Gateway

Fallback یعنی اگر مدل یا ارائه‌دهندۀ اصلی نتوانست درخواست را پاسخ دهد، Gateway از مسیر جایگزین استفاده کند.

یک زنجیرۀ Fallback ممکن است به شکل زیر باشد:

مدل اصلی در ارائه‌دهنده اول
    ↓ در صورت خطای موقت
همان مدل در ارائه‌دهنده دوم
    ↓ در صورت عدم دسترسی
مدل جایگزین هم‌سطح
    ↓ در صورت شکست
پاسخ خطای استاندارد

Fallback می‌تواند در چند سطح انجام شود:

• تغییر Endpoint همان ارائه‌دهنده
• تغییر Region
• تغییر ارائه‌دهنده
• تغییر مدل
• استفاده از پاسخ Cache‌شده
• کاهش قابلیت‌های درخواست
• انتقال به صف پردازش

چه خطاهایی برای Fallback مناسب‌اند؟

Fallback معمولاً برای خطاهای موقت مفید است:

• 429 Too Many Requests
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout
• خطای اتصال
• Timeout
• کاهش ظرفیت ارائه‌دهنده

خطاهای زیر معمولاً با تغییر ارائه‌دهنده حل نمی‌شوند:

• API Key نامعتبر
• مدل غیرمجاز
• ساختار اشتباه درخواست
• عبور از بودجۀ کاربر
• ورودی نامعتبر
• نقض سیاست محتوا

چالش سازگاری مدل جایگزین

دو مدل ممکن است خروجی یکسانی تولید نکنند. تفاوت‌ها می‌توانند شامل موارد زیر باشند:

• کیفیت پاسخ
• لحن
• قالب JSON
• نحوۀ Tool Calling
• طول پاسخ
• سیاست محتوایی
• اندازۀ Context
• نام پارامترها

بنابراین مدل جایگزین باید پیش از ورود به زنجیرۀ Fallback آزمایش شود.

Load Balancing میان ارائه‌دهندگان

گاهی یک مدل از طریق چند ارائه‌دهنده یا زیرساخت قابل‌دسترسی است. Gateway می‌تواند ترافیک را میان آن‌ها توزیع کند.

روش‌های رایج عبارت‌اند از:

Round Robin

درخواست‌ها به‌ترتیب میان مقصدها توزیع می‌شوند. این روش ساده است، اما تفاوت قیمت، Latency و ظرفیت را در نظر نمی‌گیرد.

Weighted Routing

برای هر مقصد وزن مشخصی تعریف می‌شود:

Provider A: 70%
Provider B: 20%
Provider C: 10%

Least Latency

درخواست به مقصدی ارسال می‌شود که در بازۀ اخیر سریع‌تر بوده است.

Cost-Based Routing

Gateway ارزان‌ترین مسیر سالم را انتخاب می‌کند.

Availability-Based Routing

مسیر بر اساس نرخ خطا، Rate Limit و ظرفیت باقی‌مانده انتخاب می‌شود.

ترکیب معیارها

در یک سیستم واقعی می‌توان برای هر مسیر امتیاز محاسبه کرد:

Score =
Quality Weight
- Cost Weight
- Latency Weight
- Error Rate Weight

ضرایب باید بر اساس نیاز محصول تعیین شوند.

کنترل Rate Limit

مدل‌ها و ارائه‌دهندگان معمولاً محدودیت‌هایی مانند موارد زیر دارند:

• Request Per Minute
• Token Per Minute
• Request Per Day
• Concurrent Request
• محدودیت تولید تصویر
• محدودیت مدت ویدئو
• محدودیت حساب یا پروژه

AI Gateway باید دو نوع محدودیت را مدیریت کند:

محدودیت مصرف‌کننده

برای جلوگیری از مصرف بی‌رویه، هر API Key یا سازمان محدود می‌شود.

محدودیت ارائه‌دهنده

Gateway باید مراقب باشد مجموع درخواست‌های کاربران از ظرفیت حساب ارائه‌دهنده عبور نکند.

برای کنترل این وضعیت می‌توان از روش‌های زیر استفاده کرد:

• صف درخواست
• Token Bucket
• کنترل هم‌زمانی
• توزیع میان چند ارائه‌دهنده
• انتقال به مدل جایگزین
• Backpressure
• رزرو ظرفیت برای مشتریان مهم

مدیریت هزینه و بودجه

کنترل هزینه یکی از تفاوت‌های اصلی AI Gateway با API Gateway عمومی است.

Gateway باید قیمت هر مدل را در واحدهای مربوط به آن نگهداری کند. برای مدل‌های زبانی معمولاً هزینه بر اساس توکن محاسبه می‌شود:

Input Cost =
Input Tokens × Input Token Price

Output Cost =
Output Tokens × Output Token Price

Total Cost =
Input Cost + Output Cost

اما مدل‌های دیگر ممکن است واحدهای متفاوتی داشته باشند:

• هر تصویر
• وضوح تصویر
• تعداد پیکسل
• ثانیۀ صوت
• دقیقۀ ویدئو
• مدت پردازش
• تعداد عملیات
• حجم داده

بودجه می‌تواند در چند سطح تعریف شود:

• بودجۀ هر درخواست
• بودجۀ روزانه کاربر
• بودجۀ ماهانۀ پروژه
• سقف مصرف API Key
• سقف مصرف یک مدل
• بودجۀ کل سازمان

رفتار Gateway پس از رسیدن به سقف می‌تواند یکی از این موارد باشد:

• رد درخواست
• ارسال هشدار
• انتقال به مدل اقتصادی‌تر
• کاهش سقف خروجی
• غیرفعال کردن مدل‌های گران
• نیاز به تأیید مدیر

Prompt Caching

در بسیاری از کاربردها، بخش بزرگی از Prompt در درخواست‌های مختلف تکرار می‌شود:

• System Prompt
• دستورالعمل سازمان
• توضیح ابزارها
• قوانین قالب خروجی
• بخش ثابت سند
• نمونه‌های Few-shot

Prompt Caching می‌تواند پردازش این بخش‌های تکراری را کاهش دهد. بسته به مدل و ارائه‌دهنده، این قابلیت ممکن است موجب کاهش هزینه یا Latency شود.

AI Gateway می‌تواند اطلاعات Cache را ثبت کند و درخواست‌ها را به ارائه‌دهنده‌ای هدایت کند که Cache مرتبط را در اختیار دارد.

Semantic Caching

در کش معمولی، تنها درخواست‌های دقیقاً یکسان از Cache پاسخ می‌گیرند. Semantic Cache شباهت معنایی درخواست‌ها را بررسی می‌کند.

برای مثال، دو پرسش زیر از نظر نوشتاری متفاوت اما از نظر معنایی مشابه‌اند:

API Gateway چیست؟
دروازۀ API چه کاربردی دارد؟

Semantic Cache معمولاً با Embedding و Vector Search پیاده‌سازی می‌شود.

پیش از استفاده از آن باید موارد زیر بررسی شوند:

• تازگی پاسخ
• وابستگی پاسخ به کاربر
• سطح شباهت
• وجود داده حساس
• تغییرپذیری موضوع
• مجوز اشتراک پاسخ
• احتمال پاسخ نادرست

برای پرسش‌های مالی، پزشکی، حقوقی یا داده‌های لحظه‌ای، Cache معنایی باید با احتیاط بیشتری استفاده شود.

امنیت در AI Gateway

مدیریت API Key

کلیدهای ارائه‌دهندگان باید در Secret Manager نگهداری شوند و فقط سرویس Gateway امکان دسترسی به آن‌ها را داشته باشد.

API Key نباید در موارد زیر قرار گیرد:

• کد Frontend
• اپلیکیشن موبایل
• Repository
• فایل عمومی
• لاگ
• پیام خطا
• Analytics
• Prompt

جداسازی Tenantها

در سامانه‌های چندسازمانی، داده‌ها و مصرف هر Tenant باید کاملاً از دیگری جدا باشد.

این جداسازی شامل موارد زیر است:

• API Key
• لاگ
• بودجه
• Cache
• Prompt
• فایل
• مدل‌های مجاز
• گزارش مصرف

حذف اطلاعات حساس

Gateway می‌تواند پیش از ارسال درخواست به مدل، الگوهای حساس را شناسایی کند:

• شماره کارت
• رمز عبور
• Token
• API Key
• کد ملی
• شمارۀ تماس
• ایمیل
• اطلاعات پزشکی
• داده‌های محرمانۀ سازمان

واکنش سیستم می‌تواند شامل Masking، Redaction، Tokenization یا رد کامل درخواست باشد.

جلوگیری از Prompt Injection

Prompt Injection زمانی رخ می‌دهد که محتوای ورودی تلاش کند دستورالعمل‌های اصلی سیستم را تغییر دهد یا اطلاعات محرمانه را استخراج کند.

AI Gateway می‌تواند برخی کنترل‌های عمومی را اعمال کند، اما جلوگیری کامل از Prompt Injection فقط با یک فیلتر ساده ممکن نیست. طراحی امن باید شامل این موارد باشد:

• جداسازی دستور و داده
• محدود کردن ابزارهای قابل‌فراخوانی
• اعتبارسنجی ورودی ابزار
• کنترل مجوز در Backend
• عدم اعتماد به خروجی مدل
• تأیید عملیات حساس
• محدود کردن دسترسی Agent
• ثبت و بررسی رفتارهای مشکوک

کنترل خروجی مدل

خروجی مدل نباید مستقیماً در عملیات حساس استفاده شود.

برای نمونه، اگر مدل این دستور را تولید کند:

{
  "action": "transfer_money",
  "amount": 50000000
}

وجود JSON معتبر به معنی مجاز بودن عملیات نیست. Backend باید هویت، مجوز، محدودیت مبلغ و وضعیت تراکنش را جداگانه بررسی کند.

Guardrail چیست؟

Guardrail مجموعه‌ای از سیاست‌ها و کنترل‌هایی است که ورودی و خروجی مدل را بررسی می‌کند.

Guardrail ورودی می‌تواند موارد زیر را تشخیص دهد:

• محتوای غیرمجاز
• اطلاعات حساس
• Prompt Injection
• درخواست خارج از دامنۀ محصول
• فایل نامعتبر
• زبان یا قالب غیرمجاز

Guardrail خروجی می‌تواند موارد زیر را بررسی کند:

• محتوای ناامن
• افشای اطلاعات
• JSON نامعتبر
• نبود فیلدهای ضروری
• پاسخ خارج از موضوع
• وجود کد یا URL مشکوک
• ادعای بدون منبع

Guardrail نباید تنها به یک مدل زبانی دیگر متکی باشد. بهتر است ترکیبی از روش‌های قطعی و احتمالی استفاده شود:

• Regex
• Schema Validation
• Rule Engine
• Classifier
• Moderation Model
• Allowlist
• Blocklist
• بررسی انسانی

Logging و حریم خصوصی

ثبت Prompt و پاسخ برای عیب‌یابی و ارزیابی کیفیت مفید است، اما خطر حریم خصوصی ایجاد می‌کند.

پیش از ثبت محتوای درخواست باید مشخص شود:

• آیا ثبت Prompt ضروری است؟
• چه افرادی به آن دسترسی دارند؟
• اطلاعات چه مدت نگهداری می‌شوند؟
• آیا داده‌ها رمزنگاری می‌شوند؟
• آیا کاربر امکان Opt-out دارد؟
• آیا اطلاعات حساس حذف می‌شوند؟
• داده در کدام موقعیت جغرافیایی ذخیره می‌شود؟
• آیا برای آموزش مدل استفاده خواهد شد؟

یک راهکار امن می‌تواند به‌صورت پیش‌فرض فقط Metadata را ثبت کند:

{
  "request_id": "req_92a7c1",
  "model_requested": "balanced-model",
  "model_used": "provider/model-name",
  "input_tokens": 840,
  "output_tokens": 270,
  "latency_ms": 1240,
  "cost": 0.0041,
  "status": "success"
}

ثبت متن کامل باید فقط در صورت نیاز و با سیاست نگهداری مشخص فعال شود.

مشاهده‌پذیری در AI Gateway

متریک‌های فنی

• تعداد درخواست
• نرخ موفقیت
• نرخ خطا
• P50، P95 و P99 زمان پاسخ
• Time to First Token
• مدت کامل تولید
• تعداد اتصال‌های Streaming
• نرخ Timeout
• تعداد Retry
• نرخ Fallback

متریک‌های مصرف

• توکن ورودی
• توکن خروجی
• توکن Cache‌شده
• هزینه هر درخواست
• هزینه هر کاربر
• هزینه هر پروژه
• مصرف هر مدل
• مصرف هر ارائه‌دهنده

متریک‌های کیفیت

• نرخ پذیرش پاسخ
• نرخ تولید مجدد
• موفقیت Tool Call
• اعتبار Structured Output
• امتیاز ارزیابی
• رضایت کاربر
• نرخ پاسخ بی‌ارتباط
• نرخ Hallucination در مجموعۀ ارزیابی

ردیابی توزیع‌شده

هر درخواست باید یک Request ID یا Trace ID داشته باشد:

X-Request-ID: req_92a7c1

این شناسه باید در مسیر زیر حفظ شود:

Application
→ AI Gateway
→ Provider Adapter
→ Model Provider
→ Tool
→ Internal Service

بدون این شناسه، بررسی خطا در Agentهایی که چند ابزار و مدل را فراخوانی می‌کنند دشوار خواهد بود.

AI Gateway و Streaming

در پاسخ‌های Streaming، مدل به‌جای انتظار برای تکمیل کل خروجی، بخش‌های پاسخ را به‌تدریج ارسال می‌کند.

Gateway باید بتواند:

• ارتباط را باز نگه دارد.
• Chunkها را بدون تأخیر غیرضروری عبور دهد.
• قطع اتصال کلاینت را تشخیص دهد.
• درخواست ارائه‌دهنده را لغو کند.
• مصرف نهایی را ثبت کند.
• خطا در میان Stream را مدیریت کند.
• Time to First Token را اندازه بگیرد.
• قالب رویداد ارائه‌دهندگان را استاندارد کند.

Buffering نادرست در Proxy ممکن است باعث شود Streaming عملاً کار نکند و پاسخ پس از تکمیل کامل به کاربر نمایش داده شود.

AI Gateway و Tool Calling

Agentها و دستیارهای پیشرفته می‌توانند از طریق مدل، ابزارهایی مانند جست‌وجو، پایگاه داده یا API داخلی را فراخوانی کنند.

Gateway می‌تواند Tool Call را ثبت و ساختار آن را اعتبارسنجی کند، اما اجرای مجاز ابزار باید در لایۀ Agent یا Backend کنترل شود.

نکات امنیتی مهم عبارت‌اند از:

• تعریف فهرست ابزارهای مجاز
• اعتبارسنجی ورودی با JSON Schema
• تعیین Timeout
• محدود کردن تعداد فراخوانی
• کنترل مجوز کاربر
• جلوگیری از دسترسی مستقیم مدل به Secret
• تأیید انسانی برای عملیات حساس
• ثبت نتیجۀ هر Tool Call
• محدود کردن Loopهای Agent

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

AI Gateway و Structured Output

در بسیاری از نرم‌افزارها، پاسخ مدل باید به‌جای متن آزاد، ساختاری قابل‌پردازش داشته باشد.

برای مثال:

{
  "category": "technical_support",
  "priority": "high",
  "sentiment": "negative",
  "requires_human": true
}

AI Gateway می‌تواند:

• Schema موردنیاز را به ارائه‌دهنده منتقل کند.
• تفاوت قالب Structured Output را استاندارد کند.
• پاسخ را اعتبارسنجی کند.
• خروجی نامعتبر را ثبت کند.
• Retry اصلاحی انجام دهد.
• مدل جایگزین را امتحان کند.

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

AI Gateway در معماری Agentها

Agent ممکن است طی یک درخواست چندین بار مدل و ابزارها را فراخوانی کند. به همین دلیل، کنترل مصرف در Agentها اهمیت بیشتری دارد.

Gateway می‌تواند برای هر اجرای Agent اطلاعات زیر را ثبت کند:

• تعداد فراخوانی مدل
• تعداد Tool Call
• مجموع توکن
• مجموع هزینه
• مدل‌های استفاده‌شده
• مدت کل اجرا
• خطاهای هر مرحله
• تعداد Loop
• نتیجۀ نهایی

همچنین می‌توان محدودیت‌هایی تعریف کرد:

حداکثر 10 فراخوانی مدل
حداکثر 20 Tool Call
حداکثر هزینه 0.50 دلار
حداکثر زمان اجرا 120 ثانیه
حداکثر 5 تکرار

این محدودیت‌ها از اجرای بی‌نهایت، Loop و هزینه کنترل‌نشده جلوگیری می‌کنند.

نمونه اتصال به AI Gateway درواره

API درواره با الگوی سازگار با OpenAI در دسترس توسعه‌دهندگان قرار می‌گیرد. Base URL آن به شکل زیر است:

https://api.darvareh.ir/v1

برای اتصال معمولاً به دو مقدار نیاز دارید:

DARVAREH_API_KEY=your_api_key
DARVAREH_BASE_URL=https://api.darvareh.ir/v1

نمونه درخواست با cURL

curl https://api.darvareh.ir/v1/chat/completions \
  -H "Authorization: Bearer $DARVAREH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_ID",
    "messages": [
      {
        "role": "system",
        "content": "شما یک دستیار فنی دقیق هستید."
      },
      {
        "role": "user",
        "content": "AI Gateway را در سه بند توضیح بده."
      }
    ]
  }'

مقدار MODEL_ID باید با شناسه مدل موردنظر در فهرست مدل‌های درواره جایگزین شود.

نمونه با Python

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1",
)

response = client.chat.completions.create(
    model="MODEL_ID",
    messages=[
        {
            "role": "system",
            "content": "شما یک دستیار فنی دقیق هستید."
        },
        {
            "role": "user",
            "content": "مزایای AI Gateway را توضیح بده."
        }
    ],
)

print(response.choices[0].message.content)

نمونه با Node.js

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DARVAREH_API_KEY,
  baseURL: "https://api.darvareh.ir/v1",
});

const response = await client.chat.completions.create({
  model: "MODEL_ID",
  messages: [
    {
      role: "system",
      content: "شما یک دستیار فنی دقیق هستید.",
    },
    {
      role: "user",
      content: "معماری AI Gateway را توضیح بده.",
    },
  ],
});

console.log(response.choices[0].message.content);

نمونه Streaming با Node.js

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DARVAREH_API_KEY,
  baseURL: "https://api.darvareh.ir/v1",
});

const stream = await client.chat.completions.create({
  model: "MODEL_ID",
  stream: true,
  messages: [
    {
      role: "user",
      content: "یک راهنمای کوتاه برای طراحی AI Gateway بنویس.",
    },
  ],
});

for await (const chunk of stream) {
  const content = chunk.choices[0]?.delta?.content;

  if (content) {
    process.stdout.write(content);
  }
}

API Key باید فقط در محیط امن سرور نگهداری شود و نباید در کد Frontend یا Repository قرار گیرد.

الگوی پیشنهادی برای استفاده در Frontend

مرورگر نباید مستقیماً کلید اصلی درواره را دریافت کند. مسیر مناسب به شکل زیر است:

Browser
   ↓
Application Backend
   ↓
Darvareh AI Gateway
   ↓
Selected AI Model

Backend برنامه باید:

1. هویت کاربر را بررسی کند.
2. محدودیت مصرف کاربر را اعمال کند.
3. ورودی را اعتبارسنجی کند.
4. درخواست را با API Key سرور به درواره ارسال کند.
5. پاسخ را به کلاینت بازگرداند.

نمونۀ ساده Endpoint سرور با Node.js:

import express from "express";
import OpenAI from "openai";

const app = express();
app.use(express.json());

const client = new OpenAI({
  apiKey: process.env.DARVAREH_API_KEY,
  baseURL: "https://api.darvareh.ir/v1",
});

app.post("/api/assistant", async (req, res) => {
  const prompt = req.body?.prompt;

  if (typeof prompt !== "string" || prompt.length === 0) {
    return res.status(400).json({
      error: "Prompt is required",
    });
  }

  if (prompt.length > 5000) {
    return res.status(413).json({
      error: "Prompt is too long",
    });
  }

  try {
    const response = await client.chat.completions.create({
      model: "MODEL_ID",
      messages: [
        {
          role: "user",
          content: prompt,
        },
      ],
    });

    return res.json({
      content: response.choices[0].message.content,
    });
  } catch (error) {
    console.error("AI request failed", {
      status: error.status,
      requestId: error.request_id,
    });

    return res.status(502).json({
      error: "AI service is temporarily unavailable",
    });
  }
});

app.listen(3000);

در محیط Production باید Authentication، Rate Limiting، Timeout، Logging امن و کنترل بودجه نیز به این Endpoint اضافه شوند.

معماری پیشنهادی برای محیط Production

یک معماری متداول می‌تواند به شکل زیر باشد:

Users and Applications
          ↓
CDN / WAF / Load Balancer
          ↓
Application Backend
          ↓
AI Gateway
          ↓
Policy and Routing Layer
          ↓
Models and AI Providers

در کنار AI Gateway نیز اجزای زیر قرار می‌گیرند:

• Secret Manager
• Identity Provider
• Billing System
• Distributed Rate Limiter
• Metrics Platform
• Log Storage
• Trace Collector
• Cache
• Evaluation Service
• Guardrail Service
• Model Catalog

اصول مهم استقرار

• چند نمونه Gateway اجرا شود.
• Gateway تا حد ممکن Stateless باشد.
• شمارنده‌ها در فضای ذخیره‌سازی مشترک نگهداری شوند.
• Secretها خارج از کد باشند.
• برای هر مسیر Timeout مشخص شود.
• Fallbackها از قبل آزمایش شوند.
• مدل‌های جایگزین از نظر قابلیت سازگار باشند.
• تمام درخواست‌ها Request ID داشته باشند.
• تنظیمات نسخه‌بندی شوند.
• تغییرات ابتدا روی ترافیک محدود آزمایش شوند.
• مانیتورینگ هزینه و کیفیت هم‌زمان انجام شود.

چه زمانی به AI Gateway نیاز داریم؟

استفاده از AI Gateway زمانی بیشترین ارزش را دارد که:

• از بیش از یک مدل استفاده می‌کنید.
• احتمال تغییر مدل یا ارائه‌دهنده وجود دارد.
• محصول شما چند کاربر یا سازمان دارد.
• هزینه و مصرف توکن باید محاسبه شود.
• به Fallback نیاز دارید.
• مدل‌ها محدودیت نرخ متفاوتی دارند.
• امنیت API Key اهمیت دارد.
• چند تیم به زیرساخت هوش مصنوعی متصل‌اند.
• باید مدل‌های مجاز هر پروژه کنترل شوند.
• نیاز به Logging و مانیتورینگ متمرکز دارید.
• Agent یا جریان چندمرحله‌ای اجرا می‌کنید.
• می‌خواهید از وابستگی شدید به یک ارائه‌دهنده جلوگیری کنید.

چه زمانی AI Gateway ضروری نیست؟

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

AI Gateway مستقل می‌تواند در این شرایط پیچیدگی غیرضروری ایجاد کند:

• فقط یک اسکریپت آزمایشی دارید.
• محصول هنوز کاربر واقعی ندارد.
• مصرف و هزینه بسیار محدود است.
• هیچ نیاز امنیتی یا سازمانی خاصی وجود ندارد.
• تغییر ارائه‌دهنده در برنامه نیست.

با رشد محصول، بهتر است اتصال مدل در یک ماژول مشخص محصور شود تا مهاجرت آینده به Gateway ساده‌تر باشد.

ساخت AI Gateway یا استفاده از سرویس آماده؟

ساخت Gateway اختصاصی

مزایا:

• کنترل کامل معماری
• امکان اعمال سیاست‌های اختصاصی
• نگهداری داده در زیرساخت دلخواه
• یکپارچگی عمیق با سیستم داخلی

چالش‌ها:

• نگهداری Adapter ارائه‌دهندگان
• تغییر مداوم API مدل‌ها
• مدیریت قیمت و Token
• پیاده‌سازی Streaming
• مدیریت Rate Limit توزیع‌شده
• امنیت Secretها
• مانیتورینگ و Billing
• نگهداری شبانه‌روزی زیرساخت
• مدیریت خطاهای متفاوت
• نیاز به تیم فنی متخصص

استفاده از AI Gateway آماده

مزایا:

• راه‌اندازی سریع‌تر
• API یکپارچه
• دسترسی ساده‌تر به مدل‌های مختلف
• کاهش کد اختصاصی
• مدیریت متمرکز کلید و مصرف
• امکان تغییر مدل با تغییرات محدود

چالش‌ها:

• وابستگی به کیفیت سرویس Gateway
• نیاز به بررسی حریم خصوصی
• هزینه لایۀ واسط
• لزوم ارزیابی قابلیت‌ها و SLA
• بررسی سیاست نگهداری داده

برای بسیاری از تیم‌ها، استفاده از یک Gateway آماده در مرحلۀ شروع و رشد از نظر زمان و هزینه منطقی‌تر است.

اشتباهات رایج در طراحی AI Gateway

تبدیل Gateway به محل منطق کسب‌وکار

AI Gateway نباید تصمیم‌های دامنه‌ای محصول را بر عهده بگیرد. برای مثال، تشخیص اینکه یک مشتری مجاز به لغو قرارداد است باید در سرویس کسب‌وکار انجام شود.

انتخاب مدل فقط بر اساس قیمت

ارزان‌ترین مدل همیشه کم‌هزینه‌ترین نتیجۀ نهایی را ایجاد نمی‌کند. مدل ضعیف ممکن است باعث Retry، اصلاح دستی یا کاهش نرخ تبدیل شود.

Fallback بدون آزمایش

مدل جایگزین ممکن است از Tool Calling، JSON Schema، تصویر یا Context موردنیاز پشتیبانی نکند.

ثبت همۀ Promptها

ثبت بدون محدودیت ورودی و خروجی می‌تواند خطر امنیتی و حقوقی ایجاد کند.

Retry کورکورانه

Retry برای درخواست‌های نامعتبر فایده‌ای ندارد و فقط هزینه را افزایش می‌دهد. همچنین در Streaming یا Tool Calling می‌تواند رفتار تکراری ایجاد کند.

نداشتن سقف هزینه

یک Loop در Agent یا Prompt بسیار بزرگ می‌تواند مصرف بالایی ایجاد کند. بودجه باید پیش از درخواست و پس از پاسخ کنترل شود.

اعتماد به خروجی مدل

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

استفاده از نام واقعی مدل در سراسر کد

پخش کردن شناسه مدل در ده‌ها فایل، مهاجرت را دشوار می‌کند. بهتر است مدل‌ها در یک Config مرکزی یا از طریق Alias مدیریت شوند.

نادیده گرفتن قطع ارتباط کاربر

اگر کاربر Stream را متوقف کند، Gateway باید در صورت امکان درخواست بالادستی را نیز لغو کند؛ در غیر این صورت هزینه تولید ادامه پیدا می‌کند.

چک‌لیست انتخاب AI Gateway

پیش از انتخاب یک سرویس یا ابزار، این موارد را بررسی کنید:

• آیا API آن با SDKهای موجود سازگار است؟
• چه مدل‌ها و ارائه‌دهندگانی را پوشش می‌دهد؟
• آیا متن، تصویر، صوت و ویدئو را پشتیبانی می‌کند؟
• Streaming چگونه پیاده‌سازی شده است؟
• آیا Tool Calling و Structured Output پشتیبانی می‌شوند؟
• مدل جایگزین چگونه انتخاب می‌شود؟
• مصرف توکن چگونه محاسبه می‌شود؟
• قیمت مدل‌ها چگونه به‌روزرسانی می‌شود؟
• آیا بودجه و Quota قابل‌تعریف است؟
• Rate Limit در چه سطحی اعمال می‌شود؟
• Promptها ذخیره می‌شوند یا خیر؟
• داده‌ها چه مدت نگهداری می‌شوند؟
• آیا امکان غیرفعال کردن ثبت محتوا وجود دارد؟
• گزارش مصرف تا چه سطحی جزئیات دارد؟
• خطاها در چه قالبی بازگردانده می‌شوند؟
• آیا Request ID ارائه می‌شود؟
• وضعیت سلامت ارائه‌دهندگان چگونه مانیتور می‌شود؟
• چه SLA یا سازوکار پشتیبانی وجود دارد؟
• آیا API Keyها قابل لغو و محدودسازی هستند؟
• مهاجرت از سرویس چقدر دشوار است؟

پرسش‌های متداول

AI Gateway چیست؟

AI Gateway لایه‌ای میان نرم‌افزار و مدل‌های هوش مصنوعی است که اتصال، احراز هویت، مسیریابی مدل، کنترل هزینه، Rate Limiting، Fallback، امنیت و مانیتورینگ درخواست‌ها را مدیریت می‌کند.

آیا AI Gateway همان API Gateway است؟

خیر. API Gateway برای مدیریت عمومی APIها طراحی شده است. AI Gateway علاوه بر قابلیت‌های عمومی، از مفاهیمی مانند توکن، مدل، Prompt، هزینه استنتاج، Tool Calling، Guardrail و Fallback میان مدل‌های هوش مصنوعی آگاه است.

LLM Gateway چیست؟

LLM Gateway نوعی AI Gateway با تمرکز بر مدل‌های زبانی بزرگ است. AI Gateway می‌تواند علاوه بر زبان، مدل‌های تصویر، صوت، ویدئو و سایر سرویس‌های هوش مصنوعی را نیز مدیریت کند.

آیا AI Gateway کیفیت پاسخ مدل را افزایش می‌دهد؟

Gateway مستقیماً توانایی مدل را تغییر نمی‌دهد، اما می‌تواند با انتخاب مدل مناسب، اعمال Guardrail، Fallback و ارزیابی خروجی، کیفیت و پایداری تجربۀ نهایی را بهبود دهد.

آیا AI Gateway هزینه را کاهش می‌دهد؟

در صورت طراحی صحیح، بله. مسیریابی درخواست‌های ساده به مدل‌های اقتصادی، استفاده از Cache، کنترل طول خروجی و جلوگیری از Retryهای غیرضروری می‌تواند هزینه را کاهش دهد.

آیا استفاده از Gateway باعث افزایش Latency می‌شود؟

هر لایۀ واسط مقداری تأخیر اضافه می‌کند. این تأخیر در یک Gateway بهینه معمولاً در برابر زمان استنتاج مدل کوچک است. بااین‌حال، Guardrailهای سنگین، Logging هم‌زمان و چند Retry می‌توانند Latency را افزایش دهند.

آیا می‌توان مدل را بدون تغییر کد عوض کرد؟

اگر برنامه از Alias یا یک رابط استاندارد استفاده کند، مدل واقعی می‌تواند در سطح Gateway تغییر کند. بااین‌حال، سازگاری قابلیت‌ها و کیفیت مدل جدید باید آزمایش شود.

آیا قراردادن API Key در Frontend امن است؟

خیر. کلید باید در Backend یا زیرساخت امن نگهداری شود. Frontend باید درخواست را به سرور برنامه ارسال کند و سرور با Gateway ارتباط برقرار کند.

آیا AI Gateway برای Agentها مناسب است؟

بله. Gateway می‌تواند تعداد فراخوانی‌ها، هزینه، مدل‌ها، Tool Callها و مدت اجرای Agent را ثبت و محدود کند. بااین‌حال، مدیریت حافظه و منطق اجرای Agent معمولاً وظیفۀ خود Gateway نیست.

درواره چه نقشی دارد؟

درواره یک لایۀ اتصال برای دسترسی توسعه‌دهندگان و کسب‌وکارها به مدل‌های مختلف هوش مصنوعی از طریق یک API یکپارچه فراهم می‌کند. برنامه با استفاده از Base URL درواره و یک API Key می‌تواند مدل موردنظر را فراخوانی کند.

جمع‌بندی

AI Gateway یکی از اجزای مهم زیرساخت محصولات هوش مصنوعی است. این لایه میان نرم‌افزار و مدل‌ها قرار می‌گیرد و پیچیدگی اتصال به ارائه‌دهندگان مختلف را مدیریت می‌کند.

مهم‌ترین قابلیت‌های یک AI Gateway عبارت‌اند از:

• API یکپارچه
• مدیریت API Key
• مسیریابی مدل
• Fallback
• کنترل Rate Limit
• محاسبۀ توکن و هزینه
• مدیریت بودجه
• ثبت لاگ و متریک
• Guardrail
• استانداردسازی پاسخ‌ها
• کاهش وابستگی به ارائه‌دهنده

API Gatewayهای عمومی برای مدیریت ترافیک HTTP بسیار مفیدند، اما از مفاهیم اختصاصی هوش مصنوعی مانند Prompt، Token، Context، مدل، هزینه استنتاج و کیفیت پاسخ آگاهی ندارند. AI Gateway این فاصله را پر می‌کند.

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

برای شروع کافی است API Key خود را از درواره دریافت کنید، Base URL را روی آدرس زیر قرار دهید و مدل موردنظر را انتخاب کنید:

https://api.darvareh.ir/v1

مقالات مرتبط پیشنهادی

• API Gateway چیست؟ راهنمای جامع معماری، امنیت و پیاده‌سازی
• بهترین API هوش مصنوعی برای سایت و اپلیکیشن؛ راهنمای انتخاب توسعه‌دهندگان
• چگونه هزینه API هوش مصنوعی را کاهش دهیم؟
• Fallback در API هوش مصنوعی چیست و چگونه پیاده‌سازی می‌شود؟
• Auto Router چیست؟ آموزش مسیریابی هوشمند بین مدل‌های هوش مصنوعی
• توکن در API هوش مصنوعی چیست و چگونه محاسبه می‌شود؟
• Structured Output چیست؟ دریافت خروجی JSON معتبر از مدل‌های هوش مصنوعی
• Function Calling و Tool Calling چیست و چه کاربردی در Agentها دارد؟