بوابة Cloudflare للذكاء الاصطناعي تمنع تحميل التكلفة على الفاتورة الخطأ

تستطيع Cloudflare الآن إيقاف الطلب الذي يفتقد مفتاح النموذج الخاص بالعميل قبل أن تصل تكلفته إلى فاتورة Cloudflare AI. ففي 14 سبتمبر 2026، أضافت بوابة Cloudflare للذكاء الاصطناعي شرطًا لبيانات اعتماد المزوّد، بحيث يُرفض طلب الطرف الثالث الذي لا يحمل مفتاحًا صالحًا له برمز HTTP 400 بدل احتساب استخدامه عبر Unified Billing.

كيف غيّرت بوابة Cloudflare للذكاء الاصطناعي جهة الدفع

يمكن لـ AI Gateway تمرير طلب نموذج واحد عبر عدة مسارات لبيانات الاعتماد. وبيانات الاعتماد هنا هي المفتاح الذي يحدد لمزوّد النموذج في المنبع الحساب الذي سيتحمل التكلفة.

قبل هذا التغيير، كان التسلسل بسيطًا. تبحث Cloudflare أولًا عن مفتاح المزوّد المرفق بالطلب. وإذا لم تجده، تبحث عن مفتاح Bring Your Own Key، أو BYOK، محفوظ في البوابة تحت الاسم المستعار default. وإذا لم يتوفر أي منهما، كان بإمكانها استخدام بيانات اعتماد تديرها Cloudflare عبر Unified Billing وخصم قيمة الاستخدام من رصيد حساب Cloudflare.

هذا المسار الاحتياطي الأخير مفيد عندما تريد أن تكون Cloudflare هي الجهة الدافعة. لكنه يتحول إلى تسرّب في الميزانية عندما يكون الطلب تابعًا لعميل كان يفترض أن يقدّم مفتاحه الخاص من OpenAI أو Anthropic أو Google أو أي مزوّد آخر.

تتيح لك Cloudflare الآن حذف تلك الخطوة الثالثة من حركة مزوّدي الطرف الثالث. فعّل Require provider credentials على البوابة، وهو الخيار الذي تمثله byok_only: true في API، وسيتوقف أي طلب لا يملك بيانات اعتماد عميل صالحة عند HTTP 400. ويمكن تطبيق القيد نفسه على طلب واحد باستخدام cf-aig-no-wholesale: true. تشرح Cloudflare هنا ترتيب بيانات الاعتماد كاملًا وطريقة استخدام الخيارين.

أسهل طريقة لفهم الآلية هي النظر إليها بوصفها طابورًا من ثلاث جهات محتملة للدفع:

1. بيانات اعتماد الطلب: يرسل العميل مفتاح المزوّد مع الاستدعاء. تمرره AI Gateway كما هو، فيحاسب المزوّد الحساب المرتبط بذلك المفتاح.
2. بيانات الاعتماد المحفوظة في البوابة: لا يصل مفتاح مزوّد مع الاستدعاء، فتستخدم AI Gateway مفتاحًا محفوظًا في Cloudflare Secrets Store. وعلى نقاط نهاية Unified Billing، يجب أن يحمل المفتاح المحفوظ القابل للتطبيق الاسم المستعار default.
3. Cloudflare Unified Billing: لا يتوفر مفتاح عميل أو مفتاح محفوظ قابل للتطبيق، فتستطيع Cloudflare استخدام بيانات الاعتماد التي تديرها وخصم الرصيد من حساب Cloudflare.

القاعدة الجديدة تنهي هذا الطابور بعد الخطوة الثانية. وهذه هي النتيجة التجارية كلها: تتحول بيانات الاعتماد المفقودة إلى توقف ظاهر للخدمة بدل أن تنقل التكلفة بصمت إلى جهة أخرى.

انتقلت حسبة التكلفة من التسوية اللاحقة إلى الرفض الفوري

تضيف Unified Billing رسومًا قدرها 5% عند شراء الرصيد. ومثال Cloudflare واضح: رصيد بقيمة $100 ينتج عنه خصم بقيمة $105، بينما يمر سعر الاستدلال الذي يفرضه المزوّد نفسه من دون هامش إضافي.

ضع هذه الآلية الآن داخل سير عمل لعميل. إذا كان يفترض أن تستخدم مهمة العميل حسابه لدى المزوّد ثم فُقد مفتاحه، فقد تستهلك نماذج بقيمة $100 من رصيد Cloudflare الخاص بالمشغّل بدلًا من ذلك. وتمويل هذا الرصيد يكلف $105. لن يسجل حساب العميل لدى المزوّد شيئًا من هذا الاستخدام الاحتياطي، بينما يتحمل المشغّل كامل الخصم النقدي البالغ $105، ثم يضطر إلى إثبات العميل الذي تسبب فيه.

ليست رسوم 5% هي المشكلة الأساسية. المشكلة أن عبء العمل البالغ $100 انتقل بالكامل إلى الميزانية الخطأ. أما الـ $5 الإضافية فلا تفعل سوى زيادة كلفة الخطأ.

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

من ينبغي له تفعيل هذا الخيار؟

وكالة تدير عمليات أتمتة للعملاء

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

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

فريق SaaS يقبل مفاتيح يقدّمها العملاء

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

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

مهندس منصة يبدأ بمسار واحد

توفّر ترويسة الطلب نطاق تطبيق أصغر. أضف cf-aig-no-wholesale: true إلى مسار واحد لطلبات الطرف الثالث، واختبر سلوك غياب المفتاح، ثم اربط الخطأ بالمراقبة قبل تعميم التغيير على البوابة.

وللأولوية اتجاه واحد عمدًا: يمكن لترويسة الطلب أن تجعل بوابة متساهلة أكثر صرامة. لكن الطلب لا يستطيع ضبط الترويسة على false وإضعاف بوابة فُعّل عليها Require provider credentials بالفعل. تصف Cloudflare هذه القيود بأنها تراكمية.

مسؤول FinOps يفصل التحكم في جهة الدفع عن التحكم في الميزانية

استخدم هذا الإعداد لتحديد الحساب الذي يُسمح له بالدفع. واستخدم حدود الإنفاق في AI Gateway لتحديد المبلغ الذي يمكن إنفاقه. فهما أداتان مختلفتان وينبغي اختبار كل منهما على حدة.

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

اضبط الإعداد من دون التسبب في انقطاع غامض

1. 1

   اربط كل مسار بجهة الدفع المقصودة

   افصل حركة مزوّدي الطرف الثالث عن Workers AI. ولكل مسار تابع لطرف ثالث، دوّن ما إذا كان مفتاح المزوّد يجب أن يصل مع الطلب أم يأتي من مفتاح default المحفوظ في البوابة. لا تفعّل قاعدة مغلقة عند الفشل قبل تحديد هذه الملكية بوضوح.

2. 2

   اختر أصغر نطاق للتطبيق

   لمسار واحد، أرسل cf-aig-no-wholesale: true. وللبوابة كلها، افتح AI > AI Gateway، واختر البوابة، ثم افتح Settings وفعّل Require provider credentials وأكّد الاختيار. أما البوابة التي تُدار عبر API فتستخدم byok_only: true في طلب التحديث.

3. 3

   أثبت صلاحية مساري بيانات الاعتماد

   أرسل طلبًا واحدًا في بيئة الاختبار مع إرفاق مفتاح المزوّد. ثم أرسل طلبًا آخر يعتمد على المفتاح المحفوظ تحت default. تأكد في الحالتين من أن حساب المزوّد المقصود يسجل الاستخدام. وإذا كانت نقطة نهاية Unified Billing لديك تعتمد على مفتاح اسمه production، فصحح الاسم المستعار قبل المتابعة.

4. 4

   احذف المفتاح عمدًا

   أرسل في بيئة الاختبار طلب الطرف الثالث نفسه من دون مفتاح مزوّد ومن دون مفتاح default محفوظ وقابل للتطبيق. النتيجة المتوقعة هي HTTP 400، لا استجابة نموذج ناجحة. وتأكد من أن سياسة إعادة المحاولة لا تكرر خطأ الإعداد هذا باستمرار.

5. 5

   أسند الخطأ إلى شخص وطابور عمل

   حمّل مسؤول التكامل أو المنصة مسؤولية HTTP 400 هذا، لأنه يتحكم في ترويسات الطلب والأسرار المحفوظة وتدوير المفاتيح. يمكن لدعم العملاء شرح العطل وللفريق المالي مراجعته، لكن لا ينبغي لأي منهما أن يمتلك مهمة الإصلاح.

المفاضلات كما هي

يستبدل هذا الإعداد المسار الاحتياطي الصامت بفشل ظاهر. فإذا كانت Unified Billing مسار الإتاحة المقصود لديك، فإن تفعيله يزيل ذلك الإنقاذ من طلبات مزوّدي الطرف الثالث. كذلك يُمرر مفتاح الطلب المنتهي الصلاحية أو غير الصالح إلى المزوّد بدل استبداله بمسار فوترة آخر، ولذلك قد يظل مزوّد المنبع يرفضه.

Workers AI هو الاستثناء المهم. فطلباته لا تستخدم بيانات اعتماد مزوّدي الطرف الثالث، وتظل مسموحة، وتحافظ البوابة على وضع فوترة Workers AI المنفصل. لذا فإن تفعيل byok_only ليس مفتاحًا عامًا يضمن «ألا تتحمل Cloudflare أي تكلفة».

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

ما ينبغي فعله يوم الاثنين

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

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

لمزيد من الشروحات العملية الجاهزة للتنفيذ حول تغييرات مماثلة، اشترك في النشرة البريدية.