Summary

  • تعتزم Google فرض رسوم مستقلة على رموز TabFM من 30 أكتوبر 2026 مع استمرار رسوم الوحدات أو البايتات للجزء غير النموذجي من الاستعلام.
  • تضرب الصيغة المعلنة رموز الإدخال والإخراج في n_ensembles؛ مضاعفة هذا المعامل تضاعف بند النموذج عند ثبات بقية البيانات.

البساطة في الواجهة لا تصل إلى الفاتورة

تتيح دالة AI.PREDICT في BigQuery استخدام بيانات موسومة وأخرى تنتظر التنبؤ للحصول على تصنيف أو قيمة تقديرية ضمن عبارة SQL واحدة. لا يحتاج الفريق إلى نشر نموذج منفصل كي يبدأ. هذه سهولة حقيقية، وهي أيضاً مدخل تجاري ذكي. توضح وثيقة الدالة الرسمية أن Google ستفرض، اعتباراً من 30 أكتوبر 2026، رسوماً على رموز نموذج TabFM، مع استمرار احتساب وحدات المعالجة أو البايتات للجزء غير المتعلق باستدلال النموذج من الاستعلام. التاريخ عند الكتابة هو 28 أكتوبر؛ ما بين أيدينا جدول رسوم معلن لا فاتورة عميل بعد بدء التطبيق.

في مرحلة المعاينة، تحسب نسختا Enterprise وEnterprise Plus الاستخدام بوحدات المعالجة، ويحسب الاستخدام عند الطلب بالبايتات المعالجة. أما القاعدة الجديدة فتفصل عمل النموذج عن بقية عمل المستودع. سيظل المطور يرى استعلاماً واحداً. على المحاسب أن يرى وحدتي استهلاك، وأن يعرف من يقرر حجم كل منهما.

المعامل الصغير الذي يضاعف الرسوم

تعرض صفحة التسعير سعراً قدره 0.05 دولار لكل مليون رمز إدخال و0.20 دولار لكل مليون رمز إخراج. تحسب رموز الإدخال وفق (صفوف التدريب × الأعمدة + صفوف التنبؤ × (الأعمدة − 1)) × n_ensembles، ورموز الإخراج وفق صفوف التنبؤ × n_ensembles. تشمل الأعمدة السمات وعمود النتيجة المستهدفة المشار إليها في الحساب. ويحدد n_ensembles عدد النسخ المعاد ترتيبها من البيانات التي يصدر النموذج تنبؤاً لكل منها ثم يأخذ متوسط النتائج. لهذا يظهر المعامل في الحسابين. مضاعفته مع ثبات بقية المدخلات تضاعف بند النموذج. تحدد وثيقة TabFM سقفاً يبلغ 50 عموداً للسمات.

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

سلطة الإنفاق انتقلت إلى كتابة الاستعلام

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

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

تنقصنا فاتورة صدرت بعد 30 أكتوبر ومربوطة باستعلام معروف حتى نعرف العبء الفعلي على عميل محدد. لكن علاقة القوة صارت ظاهرة: Google جعلت التنبؤ سهل الاستدعاء، ومنحت النموذج عداداً مستقلاً داخل الاستدعاء نفسه.

المصادر