مفتاح API واحد لجميع النماذج: الحجة لصالح بوابة LLM

كل مزوّد يمنحك مفتاحًا. بعد المفتاح الثالث، تتوقف المفاتيح عن كونها وسيلة راحة وتبدأ في أن تكون نظامًا عليك بناؤه وصيانته. لديك N من المزوّدين، لكل منهم عنوان URL الأساسي الخاص به، وترويسة المصادقة الخاصة به، ودلالات حدود المعدل الخاصة به، ورموز الأخطاء الخاصة به، وصفحة الفوترة الخاصة به. في اللحظة التي تريد فيها توجيه طلب إلى "أفضل نموذج متاح" بدلًا من "النموذج الذي كتبته بشكل ثابت"، تصبح لديك مشكلة توجيه، وهذا ما تحلّه البوابة.

المشكلة ليست في API، بل في العمليات

استدعاءات API الخام سهلة. كل ما يحيط بها هو ما يتراكم:

•تشتّت بيانات الاعتماد. مفتاح لكل مزوّد، يُدوَّر وفق جداول مختلفة، ويُخزَّن في مديري أسرار مختلفين.

•حدود المعدل. كل مزوّد يحدّ من المعدل بطريقة مختلفة، واستجابات الأخطاء لديهم غير متسقة، لذا يجب أن يتعامل منطق إعادة المحاولة لديك مع كل واحد منها كحالة خاصة.

•وضوح الاستخدام. لكل مزوّد لوحة تحكم خاصة به. لا يوجد مكان واحد يعرض إجمالي الإنفاق عبر جميعهم.

•التجاوز عند الفشل. إذا تعطّل المزوّد A، فإن نقل الحركة إلى المزوّد B يعني إعادة النشر بمفتاح جديد ونقطة نهاية جديدة.

لا شيء من هذا ظاهر في العرض التوضيحي. إنه يظهر في الإنتاج في الثانية صباحًا عندما يكون مزوّد ما معطّلًا وطابور إعادة المحاولة لديك يتراكم.

ما هي البوابة فعليًا

تجلس البوابة بين تطبيقك ومزوّدي النماذج. يتحدث تطبيقك إلى نقطة نهاية واحدة بمفتاح واحد. تتولى البوابة المصادقة والتوجيه وتحديد المعدل ومحاسبة الاستخدام والتجاوز الاحتياطي. من منظور الكود الخاص بك، تبدو تمامًا مثل API واحد لـ LLM.

              +------------------+
              |   تطبيقك         |
              +--------+---------+
                       |  مفتاح واحد، عنوان URL أساسي واحد
                       v
              +--------+---------+
              |   بوابة LLM      |
              |  المصادقة/التوجيه|
              |  تحديد المعدل    |
              |  قياس الاستخدام  |
              +--+-----+----+----+
                 |     |    |
                 v     v    v
            المزوّد A  B   C
            (GPT-4o) (DeepSeek) (Qwen)

قرار التصميم المهم هو أن البوابة تتحدث بروتوكولًا متوافقًا مع OpenAI على جانب الاستقبال. هذا يعني أن كود SDK الحالي لديك لا يحتاج إلى مكتبة عميل جديدة. تغيّر عنوان URL الأساسي والمفتاح، وتستمر في كتابة استدعاءات chat.completions.create العادية.

مفتاح واحد، نقطة نهاية واحدة، نماذج متعددة

إليك التكامل الكامل على جانب العميل:

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)

المفتاح نفسه يصرّح بكل نموذج في الكتالوج. لا تقوم بتجهيز أربعة حسابات أو تتبّع أربعة أرصدة. تدفع فاتورة واحدة محسوبة بالمعدل، والاستخدام مقسّم حسب النموذج حتى ترى أين ذهبت الـ tokens فعليًا.

تجعل البوابة أيضًا التوجيه قرارًا في الإعدادات بدلًا من تغيير في الكود. تريد نموذجًا رخيصًا للمسار عالي الحجم ونموذجًا متقدمًا للمسار الصعب؟ هذا تعيين في مكان واحد:

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

ويصبح التجاوز الاحتياطي تدفق تحكم عاديًا بدلًا من تكامل متعدد المزوّدين:

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

متى تحتاج إلى بوابة، ومتى لا تحتاج إليها

البوابة عبء إضافي لا ينبغي أن تتحمله إذا لم تكن بحاجة إليه. إذا كنت تستخدم مزوّدًا واحدًا ونموذجًا واحدًا وليس لديك متطلب تجاوز عند الفشل، فإن المفتاح المباشر أبسط وهذا هو القرار الصحيح. إضافة قفزة إضافية ومزوّد إضافي إلى المسار الحرج لها تكلفة.

تستحق البوابة مكانها عندما يتحقق واحد على الأقل من هذه الشروط:

•تستخدم نموذجين أو أكثر وتريد التبديل بينها بحرية.

•تحتاج إلى تجاوز احتياطي عندما يكون مزوّد ما معطّلًا أو محدود المعدل.

•تريد فاتورة واحدة ومكانًا واحدًا لرؤية الإنفاق حسب النموذج.

•تريد إجراء اختبار A/B للنماذج على حركة مباشرة دون إعادة النشر.

إذا انطبق أي من هذه، فإن التوفير التشغيلي يفوق القفزة الإضافية. زمن الاستجابة الإضافي الفعلي لبوابة مُدارة جيدًا هو بضعة أجزاء من الثانية، صغير بما يكفي ليختفي بجانب زمن استدلال النموذج.

مُدارة أم مستضافة ذاتيًا؟

أحد القرارات التي تستحق أن تُتخذ عن قصد هو ما إذا كنت ستشغّل بوابتك الخاصة أم تستأجر واحدة. الموجّهات المستضافة ذاتيًا مثل LiteLLM وone-api ممتازة وتمنحك تحكمًا كاملًا في جداول التوجيه والمفاتيح والتسجيل. لكنها أيضًا تمنحك خدمة عليك تشغيلها ومراقبتها وترقيعها والحفاظ على توافرها العالي، وهو بالضبط العبء التشغيلي الذي كنت تحاول التخلص منه.

البوابة المُدارة تعكس المقايضة. تتخلى عن التحكم في الدواخل وتكسب عدم الاضطرار إلى تشغيلها: شخص آخر يحافظ على بقاء نقطة النهاية قيد التشغيل، ويدوّر المفاتيح العلوية، ويستوعب انقطاعات المزوّدين. لفريق صغير، هذه عادةً هي الصفقة الصحيحة. لفريق أكبر لديه مجموعة منصة ضمن الموظفين، قد تكون الاستضافة الذاتية مجدية لأجل قابلية التدقيق وحدها. في كلتا الحالتين، أبقِ عقد الاستقبال متوافقًا مع OpenAI حتى يظل الخيار قابلًا للعكس.

SiCore TokenWorks مبني حول هذه الفكرة: مفتاح API واحد، ونقطة نهاية واحدة متوافقة مع OpenAI على https://api.token8341.com/v1، وكتالوج يمتد عبر GPT-4o وClaude وGemini وDeepSeek وQwen وERNIE وDoubao وSpark وPangu، مع فوترة محسوبة بالمعدل واستخدام مقسّم حسب كل نموذج.