یک API Key برای همه مدل‌ها: استدلالی برای یک LLM Gateway

هر provider به شما یک کلید می‌دهد. بعد از سومی، کلیدها دیگر یک راحتی نیستند و به سیستمی تبدیل می‌شوند که باید بسازید و نگهداری کنید. شما N provider دارید، هر کدام با base URL خودش، هدر auth خودش، معناشناسی rate limit خودش، کدهای خطای خودش، صفحه صورتحساب خودش. لحظه‌ای که بخواهید یک درخواست را به «بهترین مدل موجود» مسیردهی کنید نه «مدلی که hardcode کرده‌ام»، یک مسئله routing دارید و این همان چیزی است که یک gateway حل می‌کند.

مشکل API نیست، عملیات است

فراخوانی‌های خام API آسان هستند. این همه چیز اطراف آن‌هاست که انباشته می‌شود:

•پراکندگی اعتبارنامه‌ها. یک کلید به ازای هر provider، با برنامه‌های چرخش متفاوت، ذخیره‌شده در secret managerهای مختلف.

•محدودیت‌های نرخ. هر provider به شکل متفاوتی throttle می‌کند و پاسخ‌های خطایشان یکسان نیست، بنابراین منطق retry شما باید هر کدام را به صورت خاص مدیریت کند.

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

•Failover. اگر provider A از کار بیفتد، انتقال ترافیک به provider B یعنی استقرار مجدد با کلید جدید و endpoint جدید.

هیچ‌کدام از این‌ها در یک demo قابل مشاهده نیست. در production ساعت ۲ بامداد ظاهر می‌شود، وقتی یک provider از کار افتاده و صف retry شما در حال انباشته شدن است.

یک gateway در واقع چیست

یک gateway بین اپلیکیشن شما و providerهای مدل قرار می‌گیرد. اپلیکیشن شما با یک endpoint و یک کلید صحبت می‌کند. gateway احراز هویت، routing، rate limiting، محاسبه مصرف و fallback را مدیریت می‌کند. برای کد شما دقیقاً مثل یک LLM API واحد به نظر می‌رسد.

              +------------------+
              |   Your app       |
              +--------+---------+
                       |  one key, one base URL
                       v
              +--------+---------+
              |   LLM gateway    |
              |  auth / routing  |
              |  rate limiting   |
              |  usage metering  |
              +--+-----+----+----+
                 |     |    |
                 v     v    v
            Provider A  B   C
            (GPT-4o) (DeepSeek) (Qwen)

تصمیم طراحی مهم این است که gateway در سمت inbound با پروتکل سازگار با OpenAI صحبت می‌کند. این یعنی کد SDK موجود شما به کتابخانه کلاینت جدیدی نیاز ندارد. base URL و کلید را تغییر می‌دهید و به نوشتن فراخوانی‌های عادی chat.completions.create ادامه می‌دهید.

یک کلید، یک endpoint، مدل‌های بسیار

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

from openai import OpenAI

client = OpenAI(
    base_url="https://api.token8341.com/v1",
    api_key="sk-one-key-for-everything",
)

for model in ["gpt-4o", "claude-3-5-sonnet", "deepseek-chat", "qwen-max"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Reply with the word 'ok'"}],
    )
    print(model, "->", resp.choices[0].message.content)

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

gateway همچنین routing را به یک تصمیم پیکربندی تبدیل می‌کند نه یک تغییر کد. مدل ارزان برای lane پرحجم و مدل frontier برای lane سخت می‌خواهید؟ این یک mapping در یک جا است:

ROUTES = {
    "summarize": "deepseek-chat",
    "reason": "qwen-max",
    "frontier": "gpt-4o",
}

و fallback به یک control flow معمولی تبدیل می‌شود نه یک یکپارچه‌سازی چندفروشنده‌ای:

def call_with_fallback(prompt, primary, backup):
    try:
        return ask(primary, prompt)
    except Exception:
        return ask(backup, prompt)

چه زمانی به gateway نیاز دارید و چه زمانی نه

یک gateway سرباری است که اگر به آن نیاز ندارید نباید بپذیرید. اگر از یک provider و یک مدل استفاده می‌کنید و هیچ الزام failover ندارید، یک کلید مستقیم ساده‌تر است و همان تصمیم درست است. افزودن یک hop اضافی و یک فروشنده اضافی به مسیر بحرانی هزینه دارد.

یک gateway جای خود را پیدا می‌کند وقتی حداقل یکی از این‌ها درست باشد:

•شما از دو یا چند مدل استفاده می‌کنید و می‌خواهید آزادانه بین آن‌ها جابه‌جا شوید.

•وقتی یک provider از کار می‌افتد یا rate limit می‌شود به fallback نیاز دارید.

•یک صورتحساب واحد و یک جای واحد برای دیدن هزینه به تفکیک مدل می‌خواهید.

•می‌خواهید مدل‌ها را روی ترافیک زنده A/B تست کنید بدون استقرار مجدد.

اگر هر یک از این‌ها صدق کند، صرفه‌جویی عملیاتی از hop اضافی بیشتر است. تأخیر اضافه واقعی یک gateway که خوب اجرا شود چند میلی‌ثانیه است، به اندازه‌ای کوچک که در کنار زمان inference مدل ناپدید می‌شود.

مدیریت‌شده یا self-hosted؟

یک تصمیم که ارزش دارد عامدانه گرفته شود این است که آیا gateway خودتان را اجرا کنید یا یکی اجاره کنید. روترهای self-hosted مثل LiteLLM و one-api عالی هستند و کنترل کامل روی جداول routing، کلیدها و logging می‌دهند. همچنین یک سرویس به شما می‌دهند که باید اجرا، پایش، patch و به‌صورت highly available نگه‌داری کنید، که دقیقاً همان بار عملیاتی است که می‌خواستید از آن خلاص شوید.

یک gateway مدیریت‌شده این معاوضه را معکوس می‌کند. کنترل روی درون‌ها را از دست می‌دهید و این را به دست می‌آورید که لازم نیست آن‌ها را عملیاتی کنید: کس دیگری endpoint را بالا نگه می‌دارد، کلیدهای upstream را می‌چرخاند و قطعی‌های provider را جذب می‌کند. برای یک تیم کوچک این معمولاً معامله درستی است. برای یک تیم بزرگ‌تر با یک گروه پلتفرم در تیم، self-hosting ممکن است فقط به خاطر قابلیت حسابرسی ارزشش را داشته باشد. در هر صورت، قرارداد inbound را سازگار با OpenAI نگه دارید تا انتخاب قابل برگشت بماند.

SiCore TokenWorks حول این ایده ساخته شده است: یک API key، یک endpoint سازگار با OpenAI در https://api.token8341.com/v1، و یک کاتالوگ که شامل GPT-4o، Claude، Gemini، DeepSeek، Qwen، ERNIE، Doubao، Spark و Pangu است، با صورتحساب متری و مصرف تفکیک‌شده به تفکیک مدل.