اتصال مستقیم برنامه‌ها به ارائه‌دهندگان مختلف مدل‌های زبانی مانند OpenAI یا مدل‌های میزبانی‌شده روی سرورهای شخصی، چالش‌های متعددی ایجاد می‌کند؛ هر ارائه‌دهنده ساختار SDK، سازوکار احراز هویت، و سقف ترافیک مختص به خود را دارد. اگر کدهای سرویس شما مستقیماً با این رابط‌ها درگیر شوند، اعمال قابلیت‌هایی مانند تغییر مسیر خودکار هنگام خطا، محدودیت نرخ درخواست و ردیابی هزینه‌ها به بار فنی سنگینی تبدیل خواهد شد.
استفاده از یک درگاه هوش مصنوعی (AI Gateway) معماری شما را یکپارچه می‌کند. با قراردادن یک درگاه متن‌باز مانند LiteLLM یا Portkey روی سرورهای اختصاصی خود، برنامه‌ها تنها با یک رابط استاندارد کار می‌کنند و کلیدهای دسترسی، سهمیه‌بندی هر مشتری و مسیرهای جایگزین همگی در یک لایه مرکزی مدیریت می‌شوند.
در این درس، درگاههای مطرح را از نظر سقف مقیاسپذیری، تاخیر زمانی (Latency Overhead) و ابزارهای امنیتی مقایسه می‌کنیم تا بر اساس ابعاد ترافیک و الزامات نگهداری داده‌ها، مناسب‌ترین گزینه را انتخاب کنید.
درگاه (Gateway) بین برنامههای شما و ارائه‌دهندگان مدل قرار می‌گیرد. قابلیتهای اصلی آن عبارتند از: مسیریابی ارائه‌دهنده، طرح پشتیبان (Fallback)، تلاش مجدد (Retries)، محدودیت نرخ درخواست (Rate limit)، ارجاع به اطلاعات محرمانه (Secret references)، مشاهده‌پذیری و گاردریلها (سازوکارهای ایمنی یا Guardrails). وضعیت بازار در سال 2026: LiteLLM با مجوز MIT متن‌باز است، از بیش از 100 ارائه‌دهنده پشتیبانی می‌کند و با OpenAI سازگار است؛ اما حول‌وحوش 2000 RPS از کار می‌افتد (مصرف حافظه‌ی 8 گیگابایت و خطاهای آبشاری در بنچمارک‌های منتشرشده)؛ گزینه‌ای عالی برای برنامههای Python، بار ترافیکی کمتر از 500 RPS و محیط‌های توسعه یا نمونه‌سازی اولیه. Portkey با تمرکز بر سطح کنترل (Control Plane) جایگاه‌یابی شده است (گاردریلها، پاک‌سازی دادههای حساس، شناسایی جیل‌بریک و ردگیری ممیزی)؛ از مارس 2026 با مجوز Apache 2.0 متن‌باز شد، 20 تا 40 میلی‌ثانیه سرریز تاخیر دارد و اشتراک محیط عملیاتی آن 49 دلار در ماه است. Kong AI Gateway بر پایه‌ی Kong Gateway ساخته شده است — طبق بنچمارک خود Kong روی 12 پردازنده‌ی یکسان: 228% سریع‌تر از Portkey و 859% سریع‌تر از LiteLLM عمل می‌کند؛ با قیمت 100 دلار به‌ازای هر مدل در ماه (حداکثر 5 مدل در پلن Plus)؛ انتخابی سازمانی در صورتی که هم‌اکنون از Kong استفاده می‌کنید. Bifrost (متعلق به Maxim AI) — تلاش مجدد خودکار با عقب‌گردِ قابل‌تنظیم و سوییچ به Anthropic هنگام خطای 429 از سمت OpenAI. درگاههای Cloudflare / Vercel AI Gateways — کاملاً مدیریت‌شده، بدون نیاز به عملیات زیرساختی و با قابلیتهای پایه‌ای تلاش مجدد. محل نگهداری داده‌ها (Data residency) عامل اصلی در تصمیم‌گیری برای میزبانی شخصی (Self-host) است؛ Portkey و Kong با ارائه‌ی نسخه‌ی متن‌باز در کنار سرویس مدیریت‌شده‌ی اختیاری، در میانه‌ی این طیف قرار می‌گیرند.
اهداف یادگیری
- نام بردن هفت قابلیت اصلی درگاه (مسیریابی، طرح پشتیبان، تلاش مجدد، محدودیت نرخ درخواست، اطلاعات محرمانه، مشاهده‌پذیری و گاردریلها).
- تطبیق دادن چهار درگاه مطرح سال 2026 (LiteLLM، Portkey، Kong AI و Bifrost) با سقف مقیاسپذیری و سناریوهای کاربردی هر یک.
- ارجاع به بنچمارک Kong (سریع‌تر بودن به میزان 228% نسبت به Portkey و 859% نسبت به LiteLLM) و تشریح اهمیت آن در ترافیکهای بالای 500 RPS.
- انتخاب میان گزینه‌ی میزبانی شخصی در برابر سرویس مدیریت‌شده بر اساس الزامات محل نگهداری داده‌ها و بودجه‌ی تیم عملیات.
صورت‌مسئله
محصول شما از OpenAI، Anthropic و یک مدل Llama که خودتان میزبانی می‌کنید استفاده می‌کند. هر ارائه‌دهنده SDK، مدل خطا، محدودیت نرخ درخواست و شیوه‌ی احراز هویت متفاوتی دارد. شما به تغییر مسیر خودکار هنگام خرابی (Failover) نیاز دارید (اگر OpenAI خطای 429 داد، Anthropic امتحان شود)، در کنار یک مخزن متمرکز برای نگهداری اطلاعات احراز هویت، سیستم مشاهده‌پذیری یکپارچه و محدودیت نرخ درخواست به‌ازای هر مشتری (Tenant).
پیاده‌سازی دوباره‌ی این موارد در لایه‌ی اپلیکیشن، تک‌تک سرویس‌ها را به تمام ارائه‌دهنده‌ها وابسته می‌کند. یک لایه‌ی درگاه همه‌ی این منطق‌ها را در قالب یک فرایند واحد با یک API مشترک (معمولاً سازگار با OpenAI) تجمیع می‌کند و درخواست‌ها را بین ارائه‌دهندگان توزیع می‌نماید.
مبانی نظری
هفت قابلیت محوری
- مسیریابی ارائه‌دهنده (Provider routing) — قرار گرفتن OpenAI، Anthropic، Gemini، مدل‌های شخصی و غیره پشت یک API واحد.
- طرح پشتیبان (Fallback) — تلاش مجدد روی ارائه‌دهنده‌ای دیگر هنگام وقوع خطاهای 429، 5xx یا افت کیفیت پاسخ.
- تلاش مجدد (Retries) — استفاده از عقب‌گرد نمایی (Exponential Backoff) با سقف تعداد تلاش محدود.
- محدودیت نرخ درخواست (Rate limits) — اعمال محدودیت به‌ازای هر مشتری، هر کلید و هر مدل.
- ارجاع به اطلاعات محرمانه (Secret references) — خواندن کلیدهای دسترسی از والت در محیط اجرا (هرگز در کد برنامه قرار نمی‌گیرند).
- مشاهده‌پذیری (Observability) — ترکیب OpenTelemetry با ویژگی‌های GenAI (بخش 17 · 13) به‌همراه تفکیک هزینه‌ها.
- گاردریلها (Guardrails) — پاک‌سازی دادههای حساس (PII redaction)، شناسایی جیل‌بریک (شکستن قفل ایمنی) و فیلتر کردن موضوعات مجاز.
LiteLLM — متن‌باز با مجوز MIT، مبتنی بر Python
- پشتیبانی از بیش از 100 ارائه‌دهنده، سازگار با OpenAI، پیکربندی مسیریاب (Router)، طرح پشتیبان و مشاهده‌پذیری پایه‌ای.
- در بنچمارک Kong حول‌وحوش 2000 RPS از کار می‌افتد؛ مصرف حافظه به 8 گیگابایت می‌رسد و زیر بار ترافیکی مداوم دچار خطاهای آبشاری میشود.
- بهترین کاربرد: برنامههای Python، ترافیک کمتر از 500 RPS، درگاههای محیط تست و توسعه و سناریوهای آزمایشی مسیریابی.
- هزینه: برای نسخه‌ی متن‌باز 0 دلار؛ پلن رایگان ابری نیز دارد.
Portkey — جایگاه‌یابی در سطح کنترل (Control Plane)
- از مارس 2026 با مجوز Apache 2.0 متن‌باز شده است. ارائه‌دهنده‌ی گاردریلها، پاک‌سازی دادههای حساس، شناسایی جیل‌بریک و لاگهای ممیزی.
- سرریز تاخیر 20 تا 40 میلی‌ثانیه‌ای به‌ازای هر درخواست.
- 49 دلار در ماه برای پلن محیط عملیاتی به‌همراه نگهداری داده‌ها و تضمین سطح کیفیت خدمات (SLA).
- بهترین کاربرد: صنایع تحت نظارت قانونی که به گاردریل و مشاهده‌پذیری به‌صورت یکپارچه نیاز دارند.
Kong AI Gateway — گزینه‌ای برای مقیاس‌های بزرگ
- ساخته‌شده بر پایه‌ی Kong Gateway (یک محصول درگاه API باسابقه، مبتنی بر Lua و OpenResty).
- طبق بنچمارک خود Kong روی سخت‌افزار معادل 12 پردازنده: 228% سریع‌تر از Portkey و 859% سریع‌تر از LiteLLM.
- قیمت‌گذاری: 100 دلار به‌ازای هر مدل در ماه، حداکثر 5 مدل در پلن Plus.
- بهترین کاربرد: مجموعه‌هایی که از قبل از Kong استفاده می‌کنند؛ ترافیک بالای 1000 RPS دارند؛ و مایل به پرداخت هزینه‌ی لایسنس هستند.
Bifrost (از Maxim AI)
- تلاش‌های مجدد خودکار با قابلیت تنظیم عقب‌گرد.
- جابه‌جایی خودکار به Anthropic هنگام دریافت خطای 429 از OpenAI، یکی از الگوهای استاندارد و رایج آن است.
- محصولی جدیدتر و تجاری.
Cloudflare AI Gateway / Vercel AI Gateway
- مدیریت‌شده و بدون نیاز به مدیریت زیرساخت. دارای قابلیتهای پایه‌ای تلاش مجدد و مشاهده‌پذیری.
- بهترین کاربرد: برنامههای JavaScript مستقر روی Edge در Cloudflare یا Vercel.
- در مقایسه با Kong و Portkey از نظر گاردریلها و اعمال محدودیت نرخ درخواست امکانات محدودتری دارد.
میزبانی شخصی در برابر سرویس مدیریت‌شده
الزامات محل نگهداری داده‌ها عامل تعیین‌کننده است. حوزه‌های درمان و مالی معمولاً سراغ میزبانی شخصی می‌روند (LiteLLM، نسخه‌ی متن‌باز Portkey یا Kong). محصولات حوزه‌ی کاربر نهایی معمولاً سرویس‌های مدیریت‌شده (مثل Cloudflare AI Gateway) یا گزینه‌های میانی (سرویس ابری Portkey) را انتخاب می‌کنند. در معماری ترکیبی: برای مشتریان مشمول مقررات از سرویس شخصی و برای سایرین از درگاههای ابری استفاده میشود.
سقف تاخیر (Latency budget)
- LiteLLM: سرریز تاخیر معمولاً بین 5 تا 15 میلی‌ثانیه.
- Portkey: سرریز تاخیر بین 20 تا 40 میلی‌ثانیه.
- Kong: سرریز تاخیر بین 3 تا 8 میلی‌ثانیه.
- Cloudflare/Vercel: سرریز تاخیر بین 1 تا 3 میلی‌ثانیه (به دلیل مزیت پردازش روی سرورهای Edge).
تاخیر درگاه مستقیماً به زمان رسیدن اولین توکن (TTFT) اضافه میشود. اگر در تعهدات کاری، سقف تاخیر صدک 99 (P99) کمتر از 100 میلی‌ثانیه باشد، باید سراغ Kong یا Cloudflare بروید. برای P99 کمتر از 500 میلی‌ثانیه، هر گزینه‌ای پاسخگو است.
سازوکار محدودیت نرخ درخواست اهمیت دارد
الگوریتم ساده‌ی سطل توکن (Token-bucket) فقط تا مقیاس‌های متوسط جواب میدهد. سناریوهای چندمشتری نیازمند پنجره‌ی لغزان (Sliding-window)، امکان ارسال بار لحظهای (Burst) و سطوح مختلف بر اساس نوع مشتری هستند. LiteLLM از الگوریتم سطل توکن استفاده می‌کند؛ Kong از پنجره‌ی لغزان بهره می‌برد؛ و Portkey سیستم چندسطحی را ارائه میدهد.
ترکیب درگاه، مشاهده‌پذیری و مسیریابی
مباحث فاز 17 · 13 (مشاهده‌پذیری)، فاز 16 (مسیریابی مدل) و فاز 19 (درگاه‌ها) در محیط عملیاتی همگی در قالب یک لایه قرار می‌گیرند. یا ابزاری انتخاب کنید که هر سه را پوشش دهد یا آن‌ها را با دقت به هم متصل کنید: بیشتر پیاده‌سازی‌ها در سال 2026 ابزار Helicone (مشاهده‌پذیری) یا Portkey (گاردریلها) را با Kong (برای مقیاسپذیری) ترکیب می‌کنند تا وظایف تفکیک شوند.
اعدادی که باید به‌خاطر بسپارید
- LiteLLM: افت کارایی در حدود 2000 RPS با 8 گیگابایت مصرف حافظه.
- Portkey: سرریز تاخیر 20 تا 40 میلی‌ثانیه؛ متن‌باز با لایسنس Apache 2.0 از مارس 2026.
- Kong: سریع‌تر به میزان 228% نسبت به Portkey و 859% نسبت به LiteLLM.
- قیمت‌گذاری Kong: معادل 100 دلار به‌ازای هر مدل در ماه، حداکثر 5 مدل روی پلن Plus.
- Cloudflare/Vercel: سرریز تاخیر 1 تا 3 میلی‌ثانیه روی Edge.
پیاده‌سازی عملی
فایل code/main.py مسیریابی درگاه را همراه با طرح پشتیبان بین 3 ارائه‌دهنده در شرایط تزریق خطاهای 429 و 5xx شبیه‌سازی می‌کند. در خروجی، معیارهای تاخیر، نرخ تلاش مجدد و نرخ فعال‌سازی طرح پشتیبان گزارش میشود.
تحویل نهایی
این درس فایل outputs/skill-gateway-picker.md را تولید می‌کند. این ابزار بر اساس مقیاس، وضعیت تیم عملیات، الزامات انطباق و سقف تاخیر مجاز، مناسب‌ترین درگاه را برای شما انتخاب می‌کند.
تمرین‌ها
- اسکریپت
code/main.pyرا اجرا کنید. مسیر پشتیبان را به‌صورت OpenAI→Anthropic→self-hosted تنظیم کنید. با فرض نرخ خطای 5 درصدی برای هر ارائه‌دهنده، نرخ موفقیت مورد انتظار چقدر است؟ - تعهد سطح کیفیت خدمات شما برای TTFT صدک 99 کمتر از 320 میلی‌ثانیه است و خود مدل به‌تنهایی در P99 تاخیری معادل 300 میلی‌ثانیه دارد. کدام درگاه‌ها در این سقف تاخیر باقی می‌مانند؟
- مشتری فعالی در حوزه‌ی درمان نیازمند میزبانی شخصی، پاک‌سازی دادههای حساس و ردگیری ممیزی است. بین نسخه‌ی متن‌باز Portkey یا Kong یکی را انتخاب کنید.
- مقایسه‌ی LiteLLM در برابر Kong: یک تیم در چه سقفی از RPS باید سیستم خود را مهاجرت دهد؟
- یک سیاست محدودیت نرخ درخواست برای یک سرویس SaaS چندمشتری طراحی کنید که شامل سطوح رایگان، آزمایشی و سازمانی باشد. سطل توکن را ترجیح می‌دهید یا پنجره‌ی لغزان؟
اصطلاحات کلیدی
| اصطلاح | در گفت‌وگوها | معنای واقعی در عمل |
|---|---|---|
| Gateway | «واسط API» | فرایندی که میان برنامه‌ها و ارائه‌دهندگان قرار می‌گیرد |
| LiteLLM | «همان گزینه‌ی MIT» | ابزار پایتونی متن‌باز، بیش از 100 ارائه‌دهنده، افت کارایی در 2K RPS |
| Portkey | «درگاه مجهز به گاردریل» | سطح کنترل به‌همراه مشاهده‌پذیری، با لایسنس Apache 2.0 |
| Kong AI Gateway | «گزینه‌ی مقیاس‌پذیر» | ساخته‌شده بر پایه‌ی Kong Gateway، پیشتاز در بنچمارکها |
| Bifrost | «درگاه Maxim» | الگوی آماده برای تلاش مجدد و سوییچ به Anthropic |
| Cloudflare AI Gateway | «سرویس مدیریت‌شده روی Edge» | درگاه مدیریت‌شده و مستقر روی لبه‌ی شبکه، بدون دردسر عملیاتی |
| PII redaction | «پاک‌سازی داده‌ها» | ماسک کردن عبارات با Regex و NER قبل از ارسال پرامپت به مدل |
| Jailbreak detection | «محافظت در برابر تزریق پرامپت» | کلاسیفایر بررسی‌کننده‌ی ورودی کاربر برای جلوگیری از دور زدن قوانین |
| Audit trail | «لاگهای قانونی» | ثبت تغییرناپذیر تمام فراخوانی‌های مدل زبانی |
| Token-bucket | «محدودیت ساده‌ی نرخ درخواست» | محدودکننده مبتنی بر پر شدن مجدد توکن‌ها در سطل |
| Sliding-window | «محدودیت دقیق نرخ درخواست» | محدودکننده بر اساس پنجره‌ی زمانی با رعایت بهتر عدالت در تخصیص سهمیه |