المقياس المفقود بين الرموز وإنفاق السحابة

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

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

لماذا تُظهر مقاييس الرموز وفواتير السحابة قصصًا مختلفة؟

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

ال State of FinOps 2026 يُظهر مدى سرعة انتقال الذكاء الاصطناعي إلى أعمال FinOps العادية: 98٪ من المستجيبين يديرون الآن إنفاق الذكاء الاصطناعي، مقارنةً بـ 63٪ في 2025. لكن وجود بند ميزانية أكبر لا يزال لا يوضح أي سير عمل أنفق المال أو لماذا. 

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

قامت Unite.ai بالفعل بفحص لماذا token counts don’t automatically represent business value. الخطوة التالية هي ربط تلك العدّات بأحمال العمل التي أنتجتها. وإلا، قد تحسن الفرق تكلفة كل رمز بينما تجعل تكلفة كل مهمة مكتملة أسوأ.

كيف يبدو سلسلة تكلفة كاملة؟

تبدأ سلسلة تكلفة مفيدة بالنتيجة التي تهم الأعمال. قد تكون حالة دعم تم حلها، مستندًا تم معالجته، تغيير كود مقبول، أو سير عمل وكيل مكتمل. كل ما يلي يحتاج إلى هوية يمكن تتبعها عبر النظام.

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

ال OpenTelemetry conventions for GenAI agents توفر مفردات ناشئة لهذه الطبقة. تغطي العمليات، المزودين، النماذج المطلوبة، الوكلاء، المحادثات، استخدام الرموز، تنفيذ الأدوات، الأخطاء، وسير العمل. لا تزال هذه الاتفاقيات تحت التطوير، لذا لا ينبغي للفرق اعتبارها معيارًا عالميًا مكتملًا. هي مفيدة لأنها تجعل مشكلة الارتباط ملموسة.

ثم تأتي البنية التحتية. تُتيح AWS’s split cost allocation data for EKS إمكانية تخصيص تكاليف الحوسبة والذاكرة المشتركة إلى حاويات Kubernetes وكشف تفاصيل مثل العنقود، مساحة الاسم، النشر، العقدة، اسم عبء العمل، ونوع عبء العمل. بالنسبة للأنواع المدعومة المتسارعة، تغطي البيانات أيضًا حجز GPU وTrainium وInferentia.

هذا هو النصف الآخر من السلسلة. يمكن للتتبع أن يوضح ما حاول التطبيق القيام به؛ يمكن لتخصيص Kubernetes أن يبين أي الموارد حملت العمل. يقدم دليل Unite.ai لـ deploying and monitoring LLMs on Kubernetes السياق الإنتاجي الأوسع، بما في ذلك تخصيص الموارد، التوسيع، والرصد.

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

بمجرد وجود سياق التطبيق، يمكن للفرق البدء بـ tracking Kubernetes costs by workload وربط مساحة الاسم، وحدة المعالجة المركزية، الذاكرة، واستخدام GPU بالعمل المنفذ. لا يزال ذلك لا يوضح ما إذا كان سير العمل قد خلق قيمة تجارية، لكنه يمنح جانب البنية التحتية من الحساب شيئًا ملموسًا يمكن ربطه به. 

أي مقياس وحدة يجب أن تثق به الأعمال؟

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

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

النجاح يغيّر الحساب.

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

تجعل أنظمة الوكيل الأمر أصعب لأن مساراتها قد تتغير من تشغيل إلى آخر. تحلل Unite.ai the economics of scaling agentic AI workloads وتغطي التوجيه، استدعاءات الأدوات، إعادة المحاولة، ونسب العمل على مستوى سير العمل. تلك السلوكيات تنتمي إلى مقياس الوحدة عندما تستهلك موارد، حتى وإن رأى المستخدم النهائي إجابة واحدة فقط.

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

من يملك الرقم؟

قد يكون الجزء الأصعب تنظيميًا. فرق التعلم الآلي تفهم استدعاءات النماذج والتقييم. فرق المنصة تفهم أحمال العمل وسلوك العنقود. فرق FinOps تفهم بيانات الفوترة وقواعد التخصيص. فرق المنتج تعرف أي نتيجة مهمة.

لا تملك أي فريق السلسلة بالكامل.

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

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

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

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

يجب مشاركة سلسلة التكلفة

ستظل مراقبة تكلفة الذكاء الاصطناعي مجزأة طالما كل فريق يحسن فقط الطبقة التي يراها. الرموز، التتبع، الحاويات، المعجلات، والفواتير ليست قياسات متنافسة. إنها أجزاء من نفس سلسلة التكلفة.

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