Google يضع ضوابط لفاتورة وكلاء Gemini قبل أن تتضخم

أعلنت Google في 26 أغسطس 2026 توسيع خيارات فوترة أحمال الوكلاء في Gemini Enterprise وإضافة حدود شهرية توقف استدعاءات الوكيل مؤقتاً عند نفاد الميزانية. ويشمل الإعلان خيار الدفع حسب الاستخدام إلى جانب الاشتراك لكل مستخدم، وفق تغطية Axios للإطلاق.

بدأت Google طرح إصدار الدفع حسب الاستخدام لعملاء مختارين، على أن يتوسع لاحقاً، بينما أصبحت Flexible Savings Plans متاحة عبر الشراء الذاتي واتفاقيات المؤسسات. وتوضح تفاصيل Google Cloud الرسمية أن الالتزام السنوي يخفض كلفة الرموز 10%، والالتزام لثلاث سنوات يخفضها 20%، وأن تنبيهات السقف تصل عند 50% و80% و100%؛ أما التنفيذ المؤجل الذي قد يخفض كلفة الاستدلال إلى النصف فما زال قادماً لأحمال مختارة.

نموذج الدفع يتبع شكل الحمل

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

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

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

وتقع Flexible Savings Plans بين النموذجين: يختار العميل التزام إنفاق شهرياً لمدة محددة، ويستفيد من خصم على الاستخدام المؤهل. لكنها ليست حصة مجانية ولا سقفاً أعلى للفاتورة؛ فالالتزام مستحق حتى عندما يقل الاستخدام عنه، ولا تنتقل سعته غير المستهلكة إلى الشهر التالي، بينما تحاسب الزيادة خارج الالتزام بالسعر الجاري.

السقف الشهري يوقف الوكيل لا المشروع كله

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

بعد تشغيل السقف يستطيع المسؤول استئناف العمل من وحدة التحكم، أو تفعيل التجاوزات إذا كانت استمرارية الخدمة أهم من التوقف. عندئذ ينتقل الاستهلاك الزائد إلى أسعار الدفع حسب الاستخدام، ويمكن أن يُحتسب الاستهلاك المؤهل ضمن Flexible Savings Plan.

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

الحصص المجمعة تقلل السعة غير المستخدمة

تجمع Google الحصص اليومية المتضمنة في اشتراك Gemini Enterprise على مستوى مشروع Google Cloud. ويمكن لتطبيقات الأعمال وGoogle Antigravity وأدوات Android Studio والوكلاء المخصصين السحب من المجموعة المشتركة، بدلاً من بقاء السعة محجوزة داخل تراخيص منفصلة.

تُستهلك الحصة المجمعة أولاً، ثم يقرر المسؤول ما إذا كان يسمح بالتجاوز المدفوع. هذا يفيد الفرق التي يتفاوت استخدامها يومياً، لكنه لا يلغي الحاجة إلى توزيع الكلفة داخلياً: مشاركة الحصة تحسن استغلال السعة، إلا أنها قد تخفي الفريق أو الوكيل الذي يقود الزيادة إذا اكتفت المؤسسة بالنظر إلى إجمالي المشروع.

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

مصفوفة قرار بين التجربة والاستقرار والتقلب

الاختيار العملي يبدأ بسلوك الحمل، لا بعدد موظفي المؤسسة وحده:

• تجربة محدودة أو طلب متقطع: الدفع حسب الاستخدام يقلل الالتزام المبكر، بشرط وضع سقف منخفض يمنع المهمة الطويلة من استهلاك ميزانية غير متوقعة.
• استخدام يومي مستقر: الاشتراك لكل مستخدم يوفر خطاً شهرياً أوضح، وتساعد الحصة المجمعة على امتصاص تفاوت الاستخدام داخل المشروع.
• استهلاك ثابت أو قابل للتوقع: Flexible Savings Plan يخفض كلفة الاستخدام المؤهل، لكنه يتطلب ثقة بأن المؤسسة ستستهلك التزامها الشهري طوال مدة العقد.
• وكيل متقلب وغير حرج: السقف الصلب أنسب عندما يكون التوقف المؤقت مقبولاً.
• وكيل متقلب وحرج: التجاوز المدفوع يحافظ على الاستمرارية، على أن تقترن به مراقبة الانحراف وتحديد مسؤولية التدخل.
• مهام كثيفة وغير عاجلة: التنفيذ المؤجل مرشح مناسب عندما يصبح متاحاً للحمل المؤهل، لكنه ليس خياراً عاماً عند الإطلاق.

في مثال حسابي شرطي، إذا بلغت كلفة المقاعد لفريق ما 10,000 وحدة نقدية شهرياً، بينما تراوح استهلاكه المتوقع بين 3,000 و14,000، فقد يقلل الدفع حسب الاستخدام كلفة أشهر التجربة لكنه يبقي الحد الأعلى متقلباً. وإذا استقر الاستخدام المؤهل عند 12,000 شهرياً، فإن خصماً سنوياً قدره 10% يخفض هذا الجزء إلى 10,800؛ ولا تمثل النتيجة فاتورة نهائية لأنها لا تشمل الموارد غير المؤهلة أو الدعم أو فروق المنطقة والعملات.

ما يجب تثبيته قبل توسيع صلاحيات الوكيل

كلما طالت سلسلة عمل الوكيل أو اتسعت الأدوات التي يستطيع استدعاءها، أصبح قياس الطلب الأول وحده مضللاً. قبل توسيع التشغيل، تحتاج فرق السحابة وFinOps إلى تثبيت الحدود التالية:

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

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

اقرأ أيضًا:

• خادم MCP قد يسرّب أسرارك: 10 ضوابط قبل توصيل أي وكيل
• اختراق Hugging Face: وكلاء OpenAI تجاوزوا العزل قبل اكتشافهم