Revolut تنقل 2000 مهندس إلى GLM باستضافة ذاتية وتخفض نفقات البرمجة بالذكاء الاصطناعي بنسبة 90%

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

ما الذي فعلته الشركة تحديداً؟

تخلّى البنك عن Claude Code وCodex، وانتقل إلى نموذج GLM المفتوح من مختبر Z.ai الصيني. ويعمل النموذج على وحدات GPU الخاصة بـRevolut، ما يعني أن شيفرات المهندسين وطلباتهم لا تُرسل إلى مزوّد خارجي. واستناداً إلى عنوان المادة المصدر، تدور التكلفة حول 0.30 $ لكل مليون توكن، وقد انتقل نحو 2000 مهندس إلى المنظومة الجديدة.

عرض هذه الأرقام ديفيد أبيتبول، رئيس التشغيل والبنية التحتية في Revolut، خلال مؤتمر AI Engineer في نيويورك. لكن ثمة تحفظ أساسي: هذه تقديرات الشركة نفسها، ولم يتحقق منها أي طرف مستقل. لذلك ينبغي التعامل مع نسبة 90% باعتبارها نتيجة تعلن الشركة تحقيقها، لا حقيقة مثبتة.

من أين يأتي الوفر؟

لا تتضمن المادة المتاحة لنا تفاصيل الحساب، لذا فإن ما يلي هو تفسيرنا، وليس نقلاً لما ورد في العرض.

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

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

لكن هذه الميزة لا تتحقق إلا عند ارتفاع معدل استخدام وحدات GPU. فعنقود حوسبة قليل الاستخدام قد يلتهم كل الوفر سريعاً.

ما الذي لا يزال غير واضح؟

هناك عدة جوانب مجهولة ينبغي وضعها في الحسبان قبل تبنّي هذا النهج:

• الجودة. لا نعرف مدى تكافؤ GLM مع Claude وCodex في مهام Revolut الفعلية، ولا عدد المرات التي يضطر فيها المهندسون إلى إعادة العمل على النتائج.
• التكلفة الكاملة. ليس واضحاً ما إذا كانت تكلفة 0.30 $ لكل مليون توكن تشمل شراء وحدات GPU والكهرباء وعمل الفريق المسؤول عن تشغيل منظومة الاستدلال وصيانتها.
• أسباب الاختيار. بالنسبة إلى بنك، يُرجّح أن ترتبط الاستضافة الذاتية بأمن البيانات والامتثال أيضاً، وليس بالسعر وحده. وهذا افتراض من جانبنا.
• قابلية تكرار التجربة. لدى Revolut فريق قوي للبنية التحتية. وقد لا تتوافر الموارد نفسها لشركة ناشئة تضم 30 شخصاً.

الدرس العملي

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

ما الذي يمكن للفرق فعله؟

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

إذا أصبحت فاتورة المساعدات مؤثرة بالفعل في ميزانيتكم، فإن تجربة Revolut تستحق على الأقل إدراجها في جدول السيناريوهات. اختبروها باستخدام بياناتكم، ولا تقبلوا نسبة 90% المعلنة دون تحقق.