Το Χαμένο Μέτρο μεταξύ Tokens και Δαπανών Cloud

Το πρόβλημα δεν είναι ότι οι ομάδες AI στερούνται δεδομένων κόστους. Είναι ότι ο πίνακας ελέγχου token και το τιμολόγιο cloud περιγράφουν διαφορετικά συστήματα, που ανήκουν σε διαφορετικές ομάδες, χωρίς αξιόπιστο τρόπο σύνδεσής τους.

Ένας υπάλληλος υποστήριξης μπορεί να επιλύσει ένα ticket μετά από πέντε κλήσεις μοντέλου, ένα βήμα ανάκτησης, δύο κλήσεις εργαλείου και μια επανάληψη. Η επιχείρηση καταγράφει μία ολοκληρωμένη περίπτωση. Η υποδομή καταγράφει μια σειρά από αιτήματα, pods, μνήμη, χρόνο επιταχυντών και κοινές υπηρεσίες. Μέχρι να εναρμονιστούν αυτές οι καταγραφές, η βελτιστοποίηση κόστους είναι εν μέρει εικασία.

Γιατί οι Μετρήσεις Token και τα Τιμολόγια Cloud Διηγούν Διαφορετικές Ιστορίες;

Οι μετρήσεις token είναι χρήσιμες. Δείχνουν πόσο κείμενο έλαβε και επέστρεψε ένα μοντέλο, και βοηθούν τις ομάδες να συγκρίνουν prompts, μοντέλα ή επιλογές δρομολόγησης. Αλλά δεν σας λένε τι συνέβη γύρω από την κλήση του μοντέλου, πόση υπολογιστική ισχύ χρησιμοποιήθηκε για την ανάκτηση και τη χρήση εργαλείων, πόσες αποτυχημένες προσπάθειες υπήρξαν πρώτα, ή αν το τελικό αποτέλεσμα ήταν χρήσιμο.

Η State of FinOps 2026 δείχνει πόσο γρήγορα η AI εντάχθηκε στην καθημερινή εργασία FinOps: το 98 % των ερωτηθέντων διαχειρίζεται πλέον δαπάνες AI, έναντι 63 % το 2025. Αλλά μια μεγαλύτερη γραμμή προϋπολογισμού εξακολουθεί να μην δείχνει ποια ροή εργασίας κατανάλωσε τα χρήματα ή γιατί. 

Δύο εργασίες επεξεργασίας εγγράφων μπορούν να χρησιμοποιήσουν περίπου τον ίδιο αριθμό token. Η μία μπορεί να ολοκληρωθεί με μια μόνο κλήση μοντέλου. Η άλλη μπορεί να ανακτήσει περιεχόμενο από πολλαπλές αποθήκες, να καλέσει εξωτερική υπηρεσία, να επιστρέψει σε άλλο μοντέλο και να εκτελέσει ξανά το έγγραφο μετά από αποτυχημένο έλεγχο επικύρωσης που ο χρήστης δεν βλέπει. Τα σύνολα token φαίνονται παρόμοια ενώ οι διαδρομές εκτέλεσης διαφέρουν.

Η Unite.ai έχει ήδη εξετάσει γιατί οι μετρήσεις token δεν αντιπροσωπεύουν αυτόματα την επιχειρηματική αξία. Το επόμενο βήμα είναι να συνδέσουμε αυτές τις μετρήσεις με τις εργασίες που τις παρήγαγαν. Διαφορετικά, μια ομάδα μπορεί να βελτιώσει το κόστος ανά token ενώ κάνει το κόστος ανά ολοκληρωμένη εργασία χειρότερο.

Πώς Δείχνει μια Πλήρης Αλυσίδα Κόστους;

Μια χρήσιμη αλυσίδα κόστους ξεκινά με το αποτέλεσμα που ενδιαφέρει την επιχείρηση. Αυτό μπορεί να είναι μια επιλυμένη περίπτωση υποστήριξης, ένα επεξεργασμένο έγγραφο, μια αποδεκτή αλλαγή κώδικα ή μια ολοκληρωμένη ροή εργασίας πράκτορα. Ό,τι βρίσκεται κάτω από αυτό χρειάζεται μια ταυτότητα που μπορεί να ακολουθηθεί μέσα στο σύστημα.

Το επίπεδο εφαρμογής παρέχει την πρώτη σύνδεση. Ένα request ID, trace ID, όνομα ροής εργασίας ή conversation ID μπορεί να συνδέσει πολλές λειτουργίες μοντέλου και εργαλείου με ένα κομμάτι εργασίας. Χωρίς αυτό το νήμα, δέκα σχετιζόμενα γεγονότα μοιάζουν με δέκα ανεξάρτητες χρεώσεις.

Οι OpenTelemetry conventions for GenAI agents προσφέρουν ένα αναδυόμενο λεξιλόγιο για αυτό το επίπεδο. Καλύπτουν λειτουργίες, παρόχους, ζητούμενα μοντέλα, πράκτορες, συνομιλίες, χρήση token, εκτέλεση εργαλείων, σφάλματα και ροές εργασίας. Οι συμβάσεις είναι ακόμη υπό ανάπτυξη, οπότε οι ομάδες δεν πρέπει να τις θεωρούν ως τελικό καθολικό πρότυπο. Είναι χρήσιμες επειδή κάνουν το πρόβλημα συσχέτισης συγκεκριμένο.

Στη συνέχεια έρχεται η υποδομή. Τα split cost allocation data for EKS της AWS μπορούν να εκχωρήσουν κοινά κόστη υπολογισμού και μνήμης σε pods του Kubernetes και να αποκαλύψουν λεπτομέρειες όπως σύμπλεγμα, namespace, deployment, node, όνομα εργασίας και τύπο εργασίας. Για υποστηριζόμενες επιταχυνόμενες περιπτώσεις, τα δεδομένα καλύπτουν επίσης κρατήσεις GPU, Trainium και Inferentia.

Αυτό είναι το άλλο μισό της αλυσίδας. Ένα trace μπορεί να εξηγήσει τι προσπάθησε να κάνει η εφαρμογή· η κατανομή του Kubernetes μπορεί να δείξει ποιοι πόροι ανέλαβαν την εργασία. Ο οδηγός της Unite.ai για την ανάπτυξη και παρακολούθηση LLMs στο Kubernetes παρέχει το ευρύτερο παραγωγικό πλαίσιο, συμπεριλαμβανομένης της κατανομής πόρων, κλιμάκωσης και παρατηρησιμότητας.

Η σύνδεση δεν θα συμβεί τυχαία. Οι ομάδες χρειάζονται ένα σταθερό αναγνωριστικό που να παραμένει αρκετά χρόνο για να συνδέσει την τηλεμετρία της εφαρμογής με τις ετικέτες εργασιών, τις εγγραφές κατανομής ή άλλο επίπεδο χαρτογράφησης. Τα δεδομένα πελατών δεν πρέπει να βρίσκονται σε ετικέτες του Kubernetes. Οι ομάδες πρέπει να αποφασίσουν ποια αναγνωριστικά χαμηλής καρδινάλιας μπορούν με ασφάλεια να συνδέσουν μια κατηγορία ροής εργασίας, υπηρεσία ή χαρακτηριστικό με τους πόρους που κατανάλωσαν.

Μόλις το πλαίσιο της εφαρμογής είναι στη θέση του, οι ομάδες μπορούν να αρχίσουν να παρακολουθούν τα κόστη Kubernetes ανά εργασία και να συνδέσουν το namespace, CPU, μνήμη και χρήση GPU με την εργασία που εκτελείται. Αυτό ακόμα δεν δείχνει αν η ροή εργασίας δημιούργησε επιχειρηματική αξία, αλλά δίνει στην πλευρά της υποδομής του υπολογισμού κάτι συγκεκριμένο στο οποίο να τοποθετηθεί. 

Ποιο Μονάδα Μέτρησης Πρέπει να Εμπιστευτεί η Επιχείρηση;

Δεν υπάρχει μία ενιαία μέτρηση κόστους AI που να πρέπει να χρησιμοποιεί κάθε ομάδα. Το κόστος ανά token απαντά σε ερώτηση κατανάλωσης μοντέλου. Το κόστος ανά pod απαντά σε ερώτηση κατανομής υποδομής. Κανένα από τα δύο δεν λέει σε έναν product owner αν η λειτουργία αποδίδει.

Ο καλύτερος παρονομαστής είναι συνήθως το μικρότερο αποτέλεσμα που η επιχείρηση μπορεί να ορίσει σαφώς και που η ομάδα προϊόντος μπορεί να επηρεάσει. Μια λειτουργία υποστήριξης μπορεί να παρακολουθεί το κόστος ανά επιλυμένη περίπτωση. Ένα σύστημα εγγράφων μπορεί να χρησιμοποιεί το κόστος ανά επιτυχώς επεξεργασμένο αρχείο, ενώ ένας βοηθός κώδικα θα μπορούσε να εξετάσει το κόστος ανά αποδεκτή αλλαγή αντί για το κόστος ανά πρόταση.

Η επιτυχία αλλάζει τα μαθηματικά.

Μια ροή εργασίας με χαμηλό κόστος ανά προσπάθεια μπορεί να είναι ακριβή αν αποτυγχάνει συχνά, προκαλεί επαναλαμβανόμενες επικυρώσεις ή στέλνει πάρα πολλές περιπτώσεις για ανθρώπινη αξιολόγηση. Γι’ αυτό οι ομάδες πρέπει να διαχωρίζουν το κόστος ανά προσπάθεια από το κόστος ολοκλήρωσης και, όπου είναι δυνατόν, το κόστος ανά αποδεκτό αποτέλεσμα. Ο τελευταίος αριθμός είναι συχνά ο πιο χρήσιμος, επειδή περιλαμβάνει τη δουλειά που παρήγαγε το σύστημα αλλά η επιχείρηση δεν μπόρεσε να χρησιμοποιήσει.

Τα συστήματα πράκτορα το καθιστούν πιο δύσκολο, επειδή οι διαδρομές τους μπορούν να αλλάζουν από εκτέλεση σε εκτέλεση. Η ανάλυση της Unite.ai για την οικονομία κλιμάκωσης εργασιών AI με πράκτορες καλύπτει δρομολόγηση, κλήσεις εργαλείων, επαναπροσπάθειες και απόδοση σε επίπεδο ροής εργασίας. Αυτές οι συμπεριφορές ανήκουν στη μονάδα μέτρησης όταν καταναλώνουν πόρους, ακόμη και όταν ο τελικός χρήστης βλέπει μόνο μία απάντηση.

Η μέτρηση δεν θα είναι τέλεια. Οι κοινές υπηρεσίες, τα αποθηκευμένα αποτελέσματα, οι παρτίδες εργασιών και η καθυστέρηση επεξεργασίας μπορούν να θολώσουν την απόδοση. Μια εκτίμηση χρήσιμη για λήψη αποφάσεων είναι καλύτερη από ψεύτικη ακρίβεια, ειδικά όταν δείχνει στους μηχανικούς ποιο επίπεδο αξίζει να διερευνηθεί.

Ποιος Κατέχει τον Αριθμό;

Το πιο δύσκολο μέρος μπορεί να είναι οργανωτικό. Οι ομάδες ML κατανοούν τις κλήσεις μοντέλου και την αξιολόγηση. Οι ομάδες πλατφόρμας κατανοούν τις εργασίες και τη συμπεριφορά του συμπλέγματος. Οι FinOps κατανοούν τα δεδομένα τιμολόγησης και τους κανόνες κατανομής. Οι ομάδες προϊόντος ξέρουν ποιο αποτέλεσμα μετρά.

Καμία ομάδα δεν κατέχει ολόκληρη την αλυσίδα.

Αυτό δημιουργεί ένα προβλέψιμο επιχείρημα για το ποιος πίνακας ελέγχου είναι σωστός. Η ομάδα ML μπορεί να δείξει χαμηλότερη χρήση token, ενώ η ομάδα πλατφόρμας βλέπει αύξηση ωρών GPU και η ομάδα προϊόντος βλέπει λιγότερες ολοκληρωμένες εργασίες από πριν. Και οι τρεις παρατηρήσεις μπορούν να είναι αληθινές ταυτόχρονα. Η κοινή μέτρηση πρέπει να εξηγεί τη σχέση μεταξύ τους.

Ένα εφικτό σημείο εκκίνησης είναι μια παραγωγική ροή εργασίας με σαφή γεγονός ολοκλήρωσης. Δώστε της ένα σταθερό αναγνωριστικό. Μεταφέρετε αυτό το πλαίσιο μέσω των ιχνηλασιών μοντέλου και εργαλείου, χαρτογραφήστε το στην υπηρεσία ή την εργασία που τρέχει στο Kubernetes και επιλέξτε έναν επιχειρηματικό παρονομαστή. Στη συνέχεια φέρτε τις ομάδες μαζί όταν ο αριθμός αλλάζει απροσδόκητα.

Αυτή η ανασκόπηση μετρά περισσότερο από έναν καλοσχεδιασμένο πίνακα ελέγχου. Μια ξαφνική αύξηση μπορεί να προέρχεται από μεγαλύτερα prompts, νέα εναλλακτική διαδρομή, υποχρησιμοποιημένη χωρητικότητα GPU, αλλαγή πολιτικής αυτόματης κλιμάκωσης ή απόφαση προϊόντος που στέλνει περισσότερη δουλειά μέσω της λειτουργίας AI. Κάθε αιτία ανήκει σε διαφορετικό ιδιοκτήτη.

Η αυτοματοποίηση πρέπει να έρθει αργότερα. Μια μηχανή συστάσεων μπορεί να ενεργήσει μόνο πάνω στις ετικέτες και τα όρια που λαμβάνει, και ένας κακός παρονομαστής μπορεί να κάνει ένα αποδοτικό σύστημα να φαίνεται σπατάλη ή να ανταμείβει μια φθηνή ροή εργασίας που οι χρήστες απορρίπτουν. Οι ομάδες χρειάζονται αρκετή κοινή ορατότητα για να διακρίνουν τη συμπεριφορά του μοντέλου από το σχεδιασμό της εφαρμογής και την κατανομή υποδομής πριν αφήσουν ένα σύστημα να ενεργήσει βάσει του αποτελέσματος. Διαφορετικά, μια αυτοματοποιημένη διόρθωση κόστους μπορεί να μειώσει τη χωρητικότητα, να αυξήσει τη καθυστέρηση και να μετακινήσει το κόστος κάπου λιγότερο ορατό.

Η Αλυσίδα Κόστους Πρέπει να Μοιράζεται

Ο έλεγχος κόστους AI θα παραμείνει κατακερματισμένος όσο κάθε ομάδα βελτιστοποιεί μόνο το επίπεδο που μπορεί να δει. Τα tokens, τα traces, τα pods, οι επιταχυντές και τα τιμολόγια δεν είναι ανταγωνιστικές μετρήσεις. Είναι κομμάτια της ίδιας αλυσίδας κόστους.

Οι εταιρείες που τα συνδέουν δεν θα έχουν έναν τέλειο αριθμό από την πρώτη μέρα. Το σημαντικό είναι αν η ομάδα μπορεί να εντοπίσει ένα υψηλό τιμολόγιο πίσω στη ροή εργασίας που το προκάλεσε, να καταλάβει τι άλλαξε και να αποφασίσει αν το αποτέλεσμα δικαιούται το κόστος.