Δημιουργήστε μια λογιστική λογιστικής χρέωσης AI API: Προσφορά, κράτηση, διευθέτηση και συμβιβασμός κάθε κλήσης μοντέλου

Η τιμολόγηση API AI που αντιμετωπίζει ο πελάτης δεν μπορεί να αποτελεί μηνιαία εξαγωγή ακατέργαστης χρήσης παρόχου. Εάν μια πύλη εκθέτει πολλά μοντέλα σε ενοικιαστές, ομάδες ή συνεργάτες, η χρέωση πρέπει να απαντήσει σε μια πιο δύσκολη ερώτηση προτού υπάρξει το τιμολόγιο: θα πρέπει αυτό το αίτημα να επιτρέπεται αυτήν τη στιγμή και πώς θα εξηγηθεί αργότερα το κόστος του;

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

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

Το πρόβλημα χρέωσης: η χρήση του παρόχου δεν είναι τιμολόγιο πελάτη

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

Αυτό σημαίνει ότι μια πύλη δεν μπορεί να χρεώσει με ασφάλεια πολλαπλασιάζοντας το total_tokens επί μία τιμή. Χρειάζεται προσαρμογείς για συγκεκριμένους παρόχους πίσω από ένα σχήμα χρέωσης ουδέτερου παρόχου.

Το πρόβλημα γίνεται πιο ορατό σε αυτές τις περιπτώσεις:

• Προπληρωμένες πιστώσεις: η πύλη πρέπει να απορρίψει αιτήματα προτού ο ενοικιαστής ξοδέψει κάτω από το μηδέν.
• Σήμανση συνεργάτη: ο συνεργάτης χρειάζεται το δικό του τιμολόγιο για τον πελάτη και όχι αντίγραφο του λογαριασμού του παρόχου.
• Ροή: η απόκριση ξεκινά πριν γίνει γνωστή η τελική χρήση διακριτικού.
• Αποθήκευση στην κρυφή μνήμη: η είσοδος στην κρυφή μνήμη μπορεί να είναι φθηνότερη από την μη αποθηκευμένη στην κρυφή μνήμη, αλλά μόνο εάν μετρηθεί ξεχωριστά.
• Συλλογισμός και χρήση εργαλείου: ορισμένα μοντέλα εκθέτουν πρόσθετες ιδιότητες χρήσης, κρυφές κλάσεις εξόδου ή μονάδες πολυμέσων.
• Αλλαγές τιμών παρόχου: ένα τιμολόγιο από τον προηγούμενο μήνα πρέπει να είναι ακόμα αναπαραγώγιμο μετά τις αλλαγές μιας κάρτας τιμών.

Σύσταση: αντιμετωπίζετε τη τιμολόγηση ως χρηματοοικονομικό καθολικό μόνο με προσάρτημα και όχι ως ερώτημα πίνακα ελέγχου πάνω από αρχεία καταγραφής αιτημάτων.

Η βασική αρχιτεκτονική

Μια αξιόπιστη αρχιτεκτονική χρέωσης έχει έξι στοιχεία:

1. Λογαριασμός μισθωτή: πελάτης, χώρος εργασίας, πελάτης μεταπωλητή ή κέντρο εσωτερικού κόστους.
2. Υπηρεσία κάρτας τιμών: εκδόσεις τιμών για πάροχο, μοντέλο, κατηγορία χρέωσης, νόμισμα και κανόνα σήμανσης.
3. Εκτιμητής: υπολογίζει μια προσφορά πριν από την πτήση από τις παραμέτρους αιτήματος και την πολιτική μοντέλου.
4. Καθολικό κρατήσεων: κρατά τον προϋπολογισμό πριν από την έναρξη της κλήσης του παρόχου.
5. Ομαλοποιητής χρήσης: μετατρέπει πεδία χρήσης για συγκεκριμένους παρόχους σε εσωτερικές μονάδες χρέωσης.
6. Εργασίες διακανονισμού και συμφωνίας: οριστικοποιήστε τις χρεώσεις και συγκρίνετε τις με τις εγγραφές του παρόχου.

Η ροή ελέγχου μοιάζει με αυτό:

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

Η σημαντική επιλογή σχεδιασμού είναι ότι το αίτημα δεν τηρείται απλώς. Ελέγχεται οικονομικά πριν και μετά την εκτέλεση.

Βήμα 1: προσφορά πριν από την κλήση του παρόχου

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

Οι είσοδοι συνήθως περιλαμβάνουν:

• Αναγνωριστικό μισθωτή και σχέδιο χρέωσης,
• Αναγνωριστικό κλειδιού API ή αναγνωριστικό έργου;
• αναγνωριστικό παρόχου και μοντέλου μετά την εφαρμογή κανόνων δρομολόγησης.
• εκτιμώμενα μη αποθηκευμένα διακριτικά εισόδου;
• γνωστή καταλληλότητα προσωρινής αποθήκευσης εισόδου, εάν είναι διαθέσιμη;
• max_tokens, max_output_tokens ή ισοδύναμο όριο εξόδου;
• εργαλείο, εικόνα, ήχος ή άλλες παράμετροι τρόπου λειτουργίας;
• κανόνας σήμανσης συνεργάτη, έκπτωσης ή τιμολόγησης μεταπωλητή.
• πολιτική νομίσματος και στρογγυλοποίησης.

Ένας απλός τύπος εισαγωγικού για τη δημιουργία κειμένου μπορεί να είναι:

εκτιμώμενο_κόστος =
  εκτιμώμενα_αποθηκευμένα_tokens_input * input_rate
+ εκτιμώμενα_cached_input_tokens * cached_input_rate
+ max_output_tokens * output_rate+ request_fee
+ partner_markup

Σύσταση: όταν το τελικό μήκος εξόδου είναι άγνωστο, δεσμεύστε τη ρυθμισμένη μέγιστη έξοδο. Εάν η εφαρμογή αφήνει το όριο εξόδου απεριόριστο, η πύλη θα πρέπει να εφαρμόσει μια προεπιλογή μισθωτή ή μοντέλου. Η επιβολή του προϋπολογισμού δεν μπορεί να είναι προσδιοριστική εάν δεν υπάρχει μέγιστη ευθύνη.

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

Βήμα 2: δέσμευση προϋπολογισμού μισθωτή

Η κράτηση προστατεύει τον λογαριασμό μισθωτή από το να ξοδέψει περισσότερα από το επιτρεπόμενο υπόλοιπο. Θα πρέπει να είναι ατομική: είτε η κράτηση είναι επιτυχής και η κλήση του παρόχου μπορεί να ξεκινήσει ή το αίτημα απορρίπτεται πριν προκύψει οποιοδήποτε κόστος παρόχου.

Μια εγγραφή κράτησης μπορεί να περιλαμβάνει:

{
  "reservation_id": "res_01J...",
  "tenant_id": "tenant_123",
  "api_key_id": "key_456",
  "request_id": "req_789",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "quoted_amount": "0.032100",
  "νόμισμα": "USD",
  "status": "κράτηση",
  "expires_at": "2026-08-11T12:05:00Z"
}

Χρησιμοποιήστε σύντομες λήξεις κρατήσεων για αποτυχίες δικτύου και αποσυνδέσεις πελατών. Μια εργασία εκκαθάρισης θα πρέπει να αποδεσμεύει ληγμένες κρατήσεις που δεν ολοκληρώθηκαν ποτέ. Ωστόσο, μην αποδεσμεύσετε μια κράτηση απλώς και μόνο επειδή ο πελάτης αποσυνδέθηκε. η κλήση του παρόχου μπορεί να είναι ακόμα ολοκληρωμένη και να έχει κόστος. Παρακολουθήστε την κατάσταση αιτήματος παρόχου ξεχωριστά.

Σύσταση: κάντε την κράτηση αδύναμη με το αναγνωριστικό αιτήματος ή το κλειδί αδυναμίας. Οι επαναλήψεις από πελάτες, πύλες ή εργαζόμενους δεν πρέπει να δημιουργούν πολλαπλές δεσμεύσεις προϋπολογισμού για το ίδιο λογικό αίτημα.

Βήμα 3: κανονικοποίηση της χρήσης παρόχου

Οι απαντήσεις του παρόχου θα πρέπει να μετατραπούν σε ένα μικρό εσωτερικό σχήμα. Διατηρήστε το σταθερό ακόμα και όταν οι πάροχοι προσθέτουν νέα πεδία χρήσης.

Ένα πρακτικό κανονικοποιημένο σχήμα χρήσης:

{
  "input_uncached_tokens": 1200,
  "input_cached_tokens": 800,
  "cache_write_tokens": 0,
  "output_tokens": 650,
  "reasoning_or_hidden_output_tokens": 0,
  "tool_or_media_units": [],
  "request_fee_units": 1,
  "provider_request_id": "prov_abc",
  "usage_source": "provider_response",
  "is_estimated": ψευδής
}

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

Τα αποθηκευμένα διακριτικά χρειάζονται τη δική τους γραμμή

Γεγονός: η τιμή της προσωρινής προσωρινής αποθήκευσης μπορεί να είναι διαφορετική από την μη αποθηκευμένη κρυφή είσοδο. Εάν τα αποθηκευμένα διακριτικά συγχωνεύονται σε συνολικά διακριτικά εισόδου, ο πελάτης μπορεί να υπερχρεωθεί ή η πύλη μπορεί να υποτιμήσει το κόστος του παρόχου. Τα αποθηκευμένα δεδομένα θα πρέπει να εμφανίζονται ως η δική τους κατηγορία χρέωσης τόσο στο καθολικό όσο και στο τιμολόγιο.

Οι εγγραφές στην κρυφή μνήμη και οι αναγνώσεις στην κρυφή μνήμη δεν είναι πάντα ίδιες

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

Η συλλογιστική και η κρυφή έξοδος χρειάζονται πολιτική

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

Σύσταση: τα τιμολόγια που απευθύνονται σε πελάτες θα πρέπει να χρησιμοποιούν απλή γλώσσα. Για παράδειγμα: το "Reasoning output tokens" είναι πιο σαφές από το όνομα ενός πεδίου ακατέργαστου παρόχου. Διατηρήστε τα ακατέργαστα πεδία διαθέσιμα για έλεγχο, αλλά μην αναγκάζετε κάθε πελάτη να κατανοήσει τα εσωτερικά στοιχεία του παρόχου.

Βήμα 4: τακτοποιήστε το πραγματικό κόστος

Ο Διακανονισμός μετατρέπει την κανονικοποιημένη χρήση σε τελικές εγγραφές στο καθολικό. Θα πρέπει να είναι μόνο προσάρτημα και να αναφέρεται στην έκδοση της κάρτας τιμών που χρησιμοποιείται για το αίτημα.

Ένα διευθετημένο συμβάν μπορεί να μοιάζει με αυτό:

{
  "ledger_event_id": "led_01J...",
  "event_type": "διακανονισμός",
  "tenant_id": "tenant_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "provider": "example_provider",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "γραμμές": [
    {
      "billing_class": "input_uncached_tokens",
      "ποσότητα": 1200,
      "μονάδα": "κουπόνι",
      "unit_price": "0.00000250",
      "ποσό": "0,003000"
    },
    {
      "billing_class": "input_cached_tokens",
      "ποσότητα": 800,
      "μονάδα": "κουπόνι",
      "unit_price": "0.00000125",
      "ποσό": "0,001000"
    },
    {
      "billing_class": "output_tokens",
      "ποσότητα": 650,
      "μονάδα": "κουπόνι","unit_price": "0.00001000",
      "ποσό": "0,006500"
    }
  ],
  "total_amount": "0.010500",
  "νόμισμα": "USD",
  "status": "τακτοποιημένος"
}

Εάν το αίτημα είχε δεσμευτεί για 0.032100 και διευθετήθηκε στο 0.010500, το καθολικό αποδεσμεύει το 0.021600 στο διαθέσιμο υπόλοιπο.

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

Αιτήματα ροής: κράτηση πρώτα, διευθέτηση αργότερα

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

Χρησιμοποιήστε αυτήν τη ροή εργασίας:

1. Εκτιμήστε τα διακριτικά εισόδου και το μέγιστο κόστος εξόδου.
2. Κράτηση προϋπολογισμού ενοικιαστών.
3. Ανοίξτε τη ροή του παρόχου.
4. Προωθήστε τα κομμάτια στον πελάτη.
5. Καταγράψτε την τελική χρήση όταν την αποστέλλει ο πάροχος ή όταν είναι διαθέσιμη μια επακόλουθη εγγραφή χρήσης.
6. Διακανονίστε το πραγματικό κόστος και αποδεσμεύστε την αχρησιμοποίητη κράτηση.

Εάν η τελική χρήση δεν είναι διαθέσιμη, επισημάνετε τη διευθέτηση ως εκτιμώμενη αντί να προσποιηθείτε ότι είναι ακριβής:

"usage_source": "gateway_estimate",
"is_estimated": true,
"reconciliation_status": "εκκρεμεί"

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

Κανόνες έκδοσης και σήμανσης κάρτας τιμών

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

Ελάχιστα πεδία:

• πάροχος;
• αναγνωριστικό μοντέλου;
• κατηγορία χρέωσης;
• μονάδα, όπως διακριτικό, αίτημα, εικόνα, δευτερόλεπτο ήχου ή μονάδα εργαλείων.
• τιμή μονάδας;
• νόμισμα;
• ενεργές χρονικές σημάνσεις έναρξης και λήξης,
• πολιτική στρογγυλοποίησης,
• κανόνας σήμανσης προγράμματος μισθωτή ή συνεργάτη,
• αναφορά πηγής και μεταδεδομένα έγκρισης.

Οι κανόνες σήμανσης πρέπει να είναι σαφείς. Για παράδειγμα:

• Κόστος συν: κόστος παρόχου συν 20%.
• Σταθερή λιανική: ο ενοικιαστής πληρώνει μια σταθερή τιμή συμβολικού ανεξάρτητα από την τιμή του παρόχου.
• Σε επίπεδο: πρώτα 10 εκατομμύρια μάρκες με μία τιμή και μετά χαμηλότερη.
• Περιλαμβανόμενες πιστώσεις: η χρήση μειώνει ένα μηνιαίο επίδομα πριν από την έναρξη της υπέρβασης χρέωσης.

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

Διαχωρίστε το βιβλίο χρεώσεων από τα αναλυτικά στοιχεία

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

Χρησιμοποιήστε αναλυτικά στοιχεία για ερωτήσεις όπως:

• Ποιες ομάδες χρησιμοποιούν τα περισσότερα διακριτικά;
• Ποια μοντέλα αναπτύσσονται πιο γρήγορα;
• Πού μπορεί να μειώσει το κόστος η προσωρινή αποθήκευση προτροπής;
• Ποια κλειδιά δημιουργούν ασυνήθιστα ακριβά αιτήματα;

Χρησιμοποιήστε το βιβλίο τιμολόγησης για ερωτήσεις όπως:

• Εγκρίθηκε αυτό το αίτημα έναντι του υπολοίπου του ενοικιαστή;
• Ποια έκδοση της κάρτας τιμών προκάλεσε αυτήν τη χρέωση;
• Έχει αποδεσμευτεί η αχρησιμοποίητη κράτηση;
• Το τιμολόγιο πελάτη ταιριάζει με τη διακανονισμένη χρήση;
• Η χρήση πύλης ταιριάζει με τη χρήση από την πλευρά του παρόχου;

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

Καθημερινή ροή εργασιών συμφωνίας

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

Μια πρακτική καθημερινή δουλειά:

1. Ομαδοποιήστε συμβάντα λογιστικής πύλης ανά πάροχο, μοντέλο, μισθωτή ή κλειδί API, κατηγορία χρέωσης και ημέρα UTC.
2. Λήψη χρήσης από την πλευρά του παρόχου ομαδοποιημένη κατά διαθέσιμες ιδιότητες, όπως αναγνωριστικό κλειδιού API, μοντέλο και ημέρα.
3. Ομαλοποιήστε τις εξαγωγές παρόχου μέσω του ίδιου κωδικού προσαρμογέα που χρησιμοποιείται για απαντήσεις αιτημάτων όπου είναι δυνατόν.
4. Συγκρίνετε τις ποσότητες και το κόστος ανά κατηγορία χρέωσης.
5. Επισήμανση διακύμανσης πάνω από τα όρια, όπως 0,5% διαφορά ποσότητας ή οποιαδήποτε μεγάλη διαφορά απόλυτου κόστους.
6. Ταξινόμηση αιτιών διακύμανσης: εκτιμήσεις ροής, επαναλήψεις, αποτυχημένα αιτήματα, λογιστική κρυφής μνήμης, αλλαγές ψευδωνύμων μοντέλου, καθυστερημένες εγγραφές παρόχου ή λείπουν αναγνωριστικά αιτημάτων.
7. Δημιουργήστε συμβάντα προσαρμογής αντί να επεξεργαστείτε παλιά συμβάντα τακτοποίησης.

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

Οι γραμμές τιμολογίων μπορούν να κατανοήσουν οι πελάτες

Ένα τιμολόγιο που απευθύνεται σε πελάτες δεν πρέπει να αντικατοπτρίζει τον πάροχο JSON. Θα πρέπει να εξηγεί το νομοσχέδιο με σταθερούς επιχειρηματικούς όρους.

Χρήσιμες στήλες τιμολογίων:

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

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

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

Λίστα ελέγχου εφαρμογής

Πριν από την κυκλοφορία

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

Κατά τη διαχείριση αιτημάτων

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

Μετά από χειρισμό αιτημάτων

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

Προβλέψεις για προγραμματισμό

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

Πρόβλεψη: οι πελάτες θα αναμένουν επεξηγήσεις χρήσης σε επίπεδο αιτήματος, κλειδιού, έργου και τιμολογίου. Ένα μηνιαίο σύνολο χωρίς ανιχνεύσιμα στοιχεία γραμμής θα είναι ανεπαρκές για ομάδες που μεταπωλούν πρόσβαση στο API ή επιβάλλουν προπληρωμένους προϋπολογισμούς.

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

Εκκίνητο συμπέρασμα

Εάν εκθέσετε πολλούς παρόχους τεχνητής νοημοσύνης μέσω μιας πύλης, δημιουργήστε το βιβλίο τιμολόγησης προτού οι διαφωνίες χρέωσης επιβάλουν το ζήτημα. Ξεκινήστε με τέσσερις εγγυήσεις:

1. Κάθε χρεώσιμο αίτημα λαμβάνει μια προσφορά πριν από την πτήση.
2. Κάθε προπληρωμένο ή με ανώτατο όριο μισθωτή έχει δεσμευτεί προϋπολογισμό πριν από την έναρξη της κλήσης του παρόχου.
3. Κάθε απόκριση παρόχου κανονικοποιείται σε σταθερές κατηγορίες χρέωσης.
4. Κάθε τιμολόγιο μπορεί να συμφωνηθεί με τη χρήση από τον πάροχο και την ακριβή έκδοση της κάρτας τιμών που χρησιμοποιήθηκε εκείνη τη στιγμή.

Αυτός ο βρόχος ελέγχου καθιστά την ενοποιημένη χρέωση API AI κατανοητή για τους πελάτες, εκτελεστή για προπληρωμένες πιστώσεις, ευέλικτη για σημάνσεις συνεργατών και ελεγκτή όταν αλλάζουν οι τιμές παρόχου ή οι μορφές χρήσης.

Σχετική ανάγνωση

• σύνδεση ιχνών LLM με αρχεία χρήσης και κόστους
• δημιουργία πυλών μεταπωλητών με μέτρηση χρήσης ενοικιαστών
• χρησιμοποιώντας προσωρινή αποθήκευση προτροπής διατηρώντας παράλληλα κατανοητή τη χρέωση