في العام الماضي، عملنا على دمج قدرات الذكاء الاصطناعي لفريق يعمل في مجال SaaS لسلاسل التوريد العابرة للحدود. كان الطلب من جانب الأعمال بسيطًا للغاية: استخدام GPT-4o للمحادثات مع خدمة العملاء، وClaude لتلخيص بنود العقود، وDeepSeek للأسئلة والأجوبة في قاعدة المعرفة الداخلية، لأن نسبة السعر إلى الأداء لدى DeepSeek كانت مغرية في ذلك الوقت. يبدو الأمر وكأنه مجرد استدعاء ثلاث واجهات برمجية، لكننا في النهاية قضينا ستة أسابيع في المعاناة، ولم يتجاوز الوقت الفعلي لكتابة منطق الأعمال الثلث، بينما ذهب الباقي كله في صيانة SDK.
ببساطة، منصة تجميع واجهات برمجة تطبيقات الذكاء الاصطناعي هي التي توحد واجهات برمجة تطبيقات النماذج الكبيرة المتناثرة من مختلف الشركات عبر طبقة بوابة نماذج، وتقدم واجهة برمجية موحدة للخارج. قيمتها لا تكمن في "الكمية"، بل في معالجة المهام القذرة مثل المصادقة والبث والفوترة بشكل مركزي. لاحقًا انتقلنا إلى التوجيه متعدد النماذج من SiCore TokenWorks للتجربة التدريجية، حيث يمكن لمفتاح واحد استدعاء النماذج الرئيسية مثل GPT-4o وClaude وGemini وDeepSeek وQwen وERNIE وDoubao، وهكذا انخفضت تكلفة الصيانة. فيما يلي سأفصل ثلاث فجوات من أكثر ما يتم التقليل من تقديره.
الفجوة الأولى: المصادقة وإدارة المفاتيح، كل طرف له لغته الخاصة في المعاملات
إذا نظرت إلى كود التهيئة الخاص بثلاثة SDKs معًا، قد تشك في أنهم اتفقوا على إزعاج بعضهم البعض. عائلة OpenAI تستخدم api_key، وAnthropic تتطلب رأس طلب منفصل anthropic-version، وبعض الشركات المحلية تتطلب حقلين مزدوجين app_id وsecret_key. في مشروعنا، قمنا بإعداد 11 متغير بيئة فقط، وفي CI كان علينا حقنها لكل بيئة على حدة.
الأمر الأكثر إزعاجًا هو تدوير المفاتيح. أحد المزودين كانت صلاحية مفتاحه 90 يومًا، وآخر غير محدد بالوقت لكنه يحدد التزامن. كتبنا في ذلك الوقت نصًا برمجيًا للتدوير، ولكن بسبب عدم توحيد تسمية المعاملات، احتوى النص على سبع طبقات من فروع if. أظهرت القياسات الفعلية أن مشروعًا صغيرًا بثلاثة نماذج، شكل كود المصادقة 42% من إجمالي كود الدمج.
الحل هو التوحيد إلى طبقة إدارة مفاتيح موحدة. لاحظنا عند اختبار token8341 أنه متوافق مع OpenAI SDK، وتغيير سطر واحد من base_url يكفي لتبديل النموذج، وجميع حقول المصادقة متوافقة مع مواصفات OpenAI. هذا خفض النسبة من 42% إلى رقم واحد. كما تحول تدوير المفاتيح من تغيير سبعة أماكن إلى تغيير مكان واحد.
الفجوة الثانية: تقسيم SSE في البث المباشر، عرض الواجهة الأمامية يتذبذب
هذه الفجوة هي الأكثر خفاءً. على الرغم من أن الجميع يستخدم SSE، إلا أن استراتيجيات دفع الرموز للخارج تختلف. OpenAI تدفع على مستوى الرمز الواحد، وClaude أحيانًا تقسم حسب مجموعة الكلمات، وDeepSeek في سيناريوهات النصوص الطويلة تجمع دفعة ثم ترسلها. استخدمنا في الواجهة الأمامية العرض حرفًا بحرف، وكان سلسًا مع GPT-4o، ولكن عند التبديل إلى مزود آخر بدأ القفز المتقطع.
بعد تحليل الحزم، لنفس الإجابة المكونة من ثلاثمائة حرف، دفع المزود A 187 قطعة، بينما دفع المزود B 23 قطعة فقط. إذا اتبعت الواجهة الأمامية إيقاعًا ثابتًا لتأثير الآلة الكاتبة، فستواجه مع المزود B توقفًا ثم انفجارًا. كان حلنا المؤقت في ذلك الوقت إضافة قائمة انتظار تخزين مؤقت في الواجهة الأمامية، لكن زمن الاستجابة زاد بدلاً من أن ينخفض، وارتفع زمن استجابة الحرف الأول من 400ms إلى 1.1s.
الحل الصحيح هو التوحيد في طبقة البوابة، وتوحيد استراتيجيات التقسيم المختلفة إلى تدفق بحبيبات ثابتة. معنى طبقة بوابة النماذج يكمن هنا، فلا يحتاج جانب الأعمال إلى الاهتمام بكيفية الدفع من المنبع، بل يستهلك التدفق القياسي فقط. قارنا بين المسارين المباشر والمجمع، وبعد التوحيد اختفى تقريبًا تذبذب العرض في الواجهة الأمامية، واستقر زمن استجابة الحرف الأول ضمن 500ms.
الفجوة الثالثة: معيار فوترة الرموز، الفاتورة لا تتطابق أبدًا
هذه الفجوة اكتشفها القسم المالي أولاً. أعددنا جدولًا ملخصًا بناءً على استخدام كل منصة تحكم، وقارناه بإحصاءات تتبع الأعمال الفعلية للمكالمات، فوجدنا فرقًا يقارب الخمس. بالتحقيق، تبين أن هناك ثلاثة أمور: بعض المنصات تحسب system prompt ضمن رموز الإدخال والبعض لا يحسبه؛ بعضها يحسب علامة نهاية البث كرمز واحد أيضًا؛ وعند خلط الصينية والإنجليزية تختلف قواعد تقسيم الكلمات.
مثال محدد: نفس العقد الصيني المكون من ألفي حرف، إحصاء الإدخال لدى المزود A هو 1840 token، ولدى المزود B هو 2130 token، بفرق 15%. إذا تم تشغيل مئات الآلاف من المكالمات شهريًا، سيظهر هذا الانحراف مباشرة في حساب التكاليف، ولا يمكن إعداد الميزانية على الإطلاق.
طريقة توحيد المعيار هي جعل طبقة البوابة تسجل الحسابات بنفسها، بإحصاء الإدخال والإخراج وفق قاعدة واحدة، ثم التسوية مع فواتير كل مزود. طريقتنا الحالية هي تسجيل نسخة على جانب البوابة ونسخة على جانب المنبع، وإذا تجاوز الانحراف 3% نطلق تنبيهًا. بهذه الطريقة تصبح فوترة الرموز قابلة للتحكم، ويكون لدينا معيار موحد عند مقارنة أسعار واجهات برمجة التطبيقات.
نقاط سأنظر إليها عند الاختيار
إذا كنت تقيم أيضًا حلول تجميع واجهات برمجة تطبيقات النماذج الكبيرة، سأذكر بعض النقاط التي أتحقق منها فعليًا: هل حقول المصادقة متوافقة مع مواصفات OpenAI، وهل يمكن تغيير سطر واحد من base_url للتبديل؛ هل تم توحيد تقسيم البث المباشر، وهل يمكن خفض زمن استجابة الحرف الأول إلى أقل من 600ms؛ هل معيار الفوترة شفاف، وهل يدعم الدفع حسب الاستخدام والتسوية؛ هل تغطية النماذج المحلية كاملة، وهل يمكن استدعاء Pangu وQwen وERNIE وDoubao مباشرة؛ وهل توجد سجلات استدعاء قابلة للمراقبة عند حدوث مشاكل.
باختصار، اختيار منصة تجميع واجهات برمجة تطبيقات الذكاء الاصطناعي لا يعتمد على عدد النماذج التي تتصل بها، بل على عدد المهام القذرة التي تنجزها نيابة عنك. وبشكل موسع، إذا كنت تتصل بنموذج أو نموذجين فقط، فإن الاتصال المباشر يكفي؛ وبمجرد أن يتجاوز العدد ثلاثة، تبرز قيمة طبقة البوابة.
المؤلف: ليو تشييوان
تاريخ النشر: 6 أكتوبر 2026