Zbuduj księgę rozliczeniową interfejsu API AI: wyceń, zarezerwuj, rozlicz i uzgodnij każdą rozmowę modelową

Rozliczenia API AI skierowane do klienta nie mogą stanowić miesięcznego eksportu surowego wykorzystania dostawcy. Jeśli brama udostępnia wiele modeli najemcom, zespołom lub partnerom, zanim faktura powstanie, rozliczenia muszą odpowiedzieć na trudniejsze pytanie: czy należy teraz zezwolić na tę prośbę i jak później wyjaśni się jej koszt?

Praktyczny wzór to księga rozliczeniowa składająca się z czterech etapów: oferta, rezerwacja, rozliczenie i uzgodnienie. Przed złożeniem wniosku podaj prawdopodobny koszt. Zarezerwuj wystarczającą ilość budżetu najemcy, aby pokryć dozwolony najgorszy przypadek. Rozlicz rzeczywisty koszt po poznaniu zużycia. Uzgodnij księgę bramy z zapisami po stronie dostawcy, aby faktury pozostały możliwe do obrony.

W tym artykule opisano tę pętlę sterowania dla bramy API obsługującej wiele modeli. Przydaje się, jeśli bramka wystawia rachunki wewnętrznym zespołom, klientom przedpłaconym, klientom agencyjnym lub partnerom na niższym szczeblu łańcucha dostaw.

Problem z rozliczeniami: korzystanie z usług dostawcy nie jest fakturą klienta

Fakt: główni dostawcy sztucznej inteligencji nie udostępniają jednego uniwersalnego licznika tokenów ani jednej uniwersalnej ceny. OpenAI publikuje ceny poszczególnych modeli z oddzielnymi stawkami wejściowymi, buforowanymi danymi wejściowymi i wyjściowymi tokenami. Buforowanie podpowiedzi OpenAI raportuje użycie tokenu w pamięci podręcznej w polu użycia odpowiedzi API. Dokumenty antropiczne oddzielają liczniki dla normalnych tokenów wejściowych, tokenów wejściowych tworzenia pamięci podręcznej, tokenów wejściowych odczytu pamięci podręcznej i tokenów wyjściowych. Ceny Gemini rozróżniają dane wejściowe, wyjściowe i inne kategorie tokenów, w tym zastosowania specyficzne dla modalności, takie jak tokeny audio.

Oznacza to, że bramka nie może bezpiecznie rozliczać się poprzez pomnożenie wartości total_tokens przez jedną cenę. Potrzebuje adapterów specyficznych dla dostawcy w ramach schematu rozliczeń neutralnego dla dostawcy.

Problem staje się bardziej widoczny w następujących sytuacjach:

• Kredyty przedpłacone: brama musi odrzucać żądania, zanim najemca wyda mniej niż zero.
• Narzuty partnera: partner potrzebuje własnej faktury dla klienta, a nie kopii rachunku dostawcy.
• Przesyłanie strumieniowe: odpowiedź rozpoczyna się, zanim znane będzie ostateczne wykorzystanie tokena.
• Szybkie buforowanie: dane wejściowe zapisane w pamięci podręcznej mogą być tańsze niż dane wejściowe niezapisane w pamięci podręcznej, ale tylko wtedy, gdy są mierzone osobno.
• Rozumowanie i użycie narzędzi: niektóre modele ujawniają dodatkowe wymiary użycia, ukryte klasy wyników lub jednostki multimedialne.
• Zmiany cen dostawcy: faktura z poprzedniego miesiąca musi być nadal odtwarzalna po zmianie arkusza stawek.

Zalecenie: traktuj rozliczenia jako księgę finansową z możliwością dołączenia, a nie jako zapytanie w panelu kontrolnym dotyczące dzienników żądań.

Podstawowa architektura

Niezawodna architektura rozliczeniowa składa się z sześciu elementów:

1. Konto najemcy: klient, obszar roboczy, klient-sprzedawca lub wewnętrzne centrum kosztów.
2. Usługa arkusza stawek: wersjonowane ceny dla dostawcy, modelu, klasy rozliczeniowej, waluty i reguły marży.
3. Estymator: oblicza wycenę przed inspekcją na podstawie parametrów żądania i zasad modelu.
4. Księga rezerwacji: przechowuje budżet przed rozpoczęciem połączenia z dostawcą.
5. Normalizator użytkowania: konwertuje pola użytkowania specyficzne dla dostawcy na wewnętrzne jednostki rozliczeniowe.
6. Zadania rozliczeniowe i uzgadniające: sfinalizuj opłaty i porównaj je z dokumentacją po stronie dostawcy.

Przepływ kontroli wygląda następująco:

żądanie klienta
  -> uwierzytelnij najemcę i klucz
  -> wybierz model i wersję cennika
  -> oszacuj koszt wejściowy i maksymalny koszt wyjściowy
  -> rezerwowe saldo najemcy
  -> zadzwoń do operatora
  -> normalizuj zwrócone użycie
  -> rozlicz rzeczywiste koszty
  -> zwolnij niewykorzystaną rezerwację
  -> wyemituj zdarzenie księgi gotowe do wystawienia faktury

Ważny wybór projektu polega na tym, że żądanie nie jest jedynie przestrzegane. Jest kontrolowany finansowo przed i po realizacji.

Krok 1: wycena przed połączeniem z dostawcą

Wycena przed inspekcją powinna być na tyle pesymistyczna, aby wyegzekwować budżety, ale jednocześnie na tyle łatwa do wyjaśnienia, aby można ją było pokazać klientom lub partnerom.

Wejście zwykle obejmuje:

• identyfikator najemcy i plan rozliczeniowy;
• Identyfikator klucza API lub identyfikator projektu;
• identyfikator dostawcy i modelu po zastosowaniu reguł routingu;
• szacowane niebuforowane tokeny wejściowe;
• znane uprawnienia do wprowadzania danych z pamięci podręcznej, jeśli są dostępne;
• max_tokens, max_output_tokens lub równoważny limit wyjściowy;
• narzędzie, obraz, dźwięk lub inne parametry modalności;
• reguła dotycząca narzutów, rabatów lub cen dla sprzedawców;
• Zasady dotyczące walut i zaokrągleń.

Prosty wzór wyceny do generowania tekstu może wyglądać następująco:

szacowany_koszt =
  szacowana_uncached_input_tokens * stopa_wejściowa
+ szacowana_cached_input_tokens * cached_input_rate
+ max_output_tokens * szybkość_wyjściowa+ opłata za żądanie
+ partner_markup

Zalecenie: gdy ostateczna długość wyjściowa nie jest znana, należy zarezerwować w stosunku do skonfigurowanej maksymalnej wydajności. Jeśli aplikacja pozostawia nieograniczony limit wyjściowy, brama powinna zastosować domyślną dzierżawę lub model. Egzekwowanie budżetu nie może mieć charakteru deterministycznego, jeśli nie istnieje maksymalna odpowiedzialność.

Może to spowodować odrzucenie niektórych żądań, które w praktyce byłyby tanie. Na tym polega kompromis. W przypadku systemów przedpłaconych bezpieczniejszą opcją jest pesymistyczna rezerwacja z niewykorzystanymi środkami uwalnianymi po rozliczeniu. W przypadku fakturowanych klientów korporacyjnych zespoły mogą zezwolić na niewielkie nadwyżki i wykorzystywać wycenę głównie do alertów.

Krok 2: rezerwowy budżet najemcy

Rezerwacja zabezpiecza konto najemcy przed wydatkami przekraczającymi dozwolone saldo. Powinno to mieć charakter atomowy: albo rezerwacja zakończy się powodzeniem i może rozpocząć się połączenie z dostawcą, albo żądanie zostanie odrzucone, zanim poniesione zostaną jakiekolwiek koszty dostawcy.

Rekord rezerwacji może zawierać:

{
  "reservation_id": "res_01J...",
  "ident_dzierżawcy": "dzierżawa_123",
  "api_key_id": "klucz_456",
  "request_id": "req_789",
  "dostawca": "przykładowy dostawca",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  "quoted_amount": "0,032100",
  "waluta": "USD",
  „status”: „zarezerwowany”,
  "expires_at": "2026-08-11T12:05:00Z"

Używaj krótkich terminów ważności rezerwacji w przypadku awarii sieci i rozłączeń klientów. Zadanie czyszczenia powinno zwolnić wygasłe rezerwacje, które nigdy nie osiągnęły rozliczenia. Nie zwalniaj jednak rezerwacji tylko dlatego, że klient się rozłączył; połączenie z dostawcą może nadal zostać zakończone i wiązać się z kosztami. Śledź osobno stan żądania dostawcy.

Zalecenie: ustaw rezerwację jako idempotentną na podstawie identyfikatora żądania lub klucza idempotentnego. Ponowne próby od klientów, bram lub procesów roboczych nie powinny powodować wielokrotnych wstrzymań budżetu dla tego samego żądania logicznego.

Krok 3: normalizacja wykorzystania dostawcy

Odpowiedzi dostawców należy przekształcić w mały schemat wewnętrzny. Zachowaj stabilność, nawet jeśli dostawcy dodają nowe pola użytkowania.

Praktyczny znormalizowany schemat użycia:

{
  „input_uncached_tokens”: 1200,
  „input_cached_tokens”: 800,
  „cache_write_tokens”: 0,
  „tokeny_wyjściowe”: 650,
  "reasoning_or_hidden_output_tokens": 0,
  "tool_or_media_units": [],
  „request_fee_units”: 1,
  "provider_request_id": "prov_abc",
  "usage_source": "odpowiedź_dostawcy",
  „is_estimated”: fałsz

Ten schemat celowo nie jest identyczny z odpowiedzią żadnego dostawcy. Przechwytuje wymiary rozliczeniowe potrzebne na fakturach, zachowując jednocześnie luki ratunkowe dla jednostek specyficznych dla dostawcy.

Tokeny zapisane w pamięci podręcznej wymagają własnej linii

Fakt: buforowanie podpowiedzi może mieć inną cenę niż dane wejściowe niezapisane w pamięci podręcznej. Jeśli tokeny w pamięci podręcznej zostaną połączone w całkowitą liczbę tokenów wejściowych, klient może zostać obciążony zbyt dużą opłatą lub brama może zaniżyć koszt dostawcy. Dane wejściowe zapisane w pamięci podręcznej powinny pojawiać się jako osobna klasa rozliczeniowa zarówno w księdze, jak i na fakturze.

Zapisy i odczyty w pamięci podręcznej nie zawsze są takie same

Niektórzy dostawcy rozróżniają tworzenie wpisów w pamięci podręcznej i odczytywanie z pamięci podręcznej. Normalizator nie powinien zakładać, że dane wejściowe buforowane zawsze oznaczają jedną stawkę rozliczeniową. Jeśli dostawca ma tokeny zapisu w pamięci podręcznej i tokeny odczytu pamięci podręcznej, zmapuj je oddzielnie lub zachowaj jako podjednostki specyficzne dla dostawcy.

Rozumowanie i ukryte wyniki wymagają polityki

Niektóre modele ujawniają użycie związane z rozumowaniem lub ukryte liczniki wyników. Jeśli dostawca wystawia rachunki za te jednostki, brama musi zdecydować, czy pokazać je bezpośrednio, przypisać do kategorii wyjściowej, czy też wyszczególnić jako osobną linię faktury.

Zalecenie: faktury skierowane do klienta powinny być pisane prostym językiem. Na przykład: „rozumowanie tokenów wyjściowych” jest wyraźniejsze niż surowa nazwa pola dostawcy. Udostępniaj surowe pola do kontroli, ale nie zmuszaj każdego klienta do zrozumienia wewnętrznych informacji dostawcy.

Krok 4: rozlicz rzeczywisty koszt

Rozliczenie przekształca znormalizowane wykorzystanie w ostateczne zapisy w księdze. Powinien być przeznaczony tylko do dołączenia i odnosić się do wersji arkusza stawek użytej w żądaniu.

Rozliczone wydarzenie może wyglądać tak:

{
  "ledger_event_id": "led_01J...",
  "event_type": "rozliczenie",
  "ident_dzierżawcy": "dzierżawca_123",
  "request_id": "req_789",
  "reservation_id": "res_01J...",
  "dostawca": "przykładowy dostawca",
  "model": "model-a",
  "rate_card_version": "2026-08-01",
  „linie”: [
    {
      "billing_class": "input_uncached_tokens",
      „ilość”: 1200,
      "jednostka": "token",
      "cena_jednostkowa": "0,00000250",
      "kwota": "0,003000"
    },
    {
      "billing_class": "input_cached_tokens",
      „ilość”: 800,
      "jednostka": "token",
      "cena_jednostkowa": "0,00000125",
      "kwota": "0,001000"
    },
    {
      "billing_class": "output_tokens",
      „ilość”: 650,
      "jednostka": "token","cena_jednostkowa": "0,00001000",
      "kwota": "0,006500"
    }
  ],
  "całkowita_kwota": "0,010500",
  "waluta": "USD",
  „status”: „rozstrzygnięty”

Jeśli żądanie zostało zarezerwowane na kwotę 0,032100 i rozliczone na kwotę 0,010500, księga zwalnia 0,021600 z powrotem do dostępnego salda.

Zalecenie: nigdy nie przeliczaj starych wierszy faktury na podstawie aktualnej tabeli cen. Przechowuj niezmienne wersje arkuszy stawek i dołączaj identyfikator wersji do każdej wyceny, rezerwacji i zdarzenia rozliczeniowego. W przeciwnym razie odtworzenie faktury może okazać się niemożliwe po aktualizacji cen modeli przez dostawcę.

Prośby o transmisję strumieniową: najpierw zarezerwuj, rozstrzygnij później

Streaming komplikuje rozliczenia, ponieważ użytkownik zaczyna odbierać dane wyjściowe, zanim brama dowie się o ostatecznym wykorzystaniu. Odpowiedzią nie jest pominięcie kontroli przed lotem. Brama powinna zarezerwować miejsce przed otwarciem strumienia.

Użyj tego przepływu pracy:

1. Oszacuj tokeny wejściowe i maksymalny koszt wyjściowy.
2. Zarezerwuj budżet najemcy.
3. Otwórz strumień dostawcy.
4. Przekaż fragmenty do klienta.
5. Przechwytuj końcowe wykorzystanie, gdy dostawca je wyśle lub gdy dostępny będzie kolejny zapis użycia.
6. Ureguluj rzeczywisty koszt i zwolnij niewykorzystaną rezerwację.

Jeśli ostateczne wykorzystanie nie jest dostępne, oznacz rozliczenie jako szacunkowe, zamiast udawać, że jest dokładne:

"usage_source": "gateway_estimate",
„is_estimated”: prawda,
„reconciliation_status”: „oczekuje”

Zalecenie: podczas codziennego uzgadniania należy nadać priorytet szacunkowym zdarzeniom związanym z transmisją strumieniową, nieudanym żądaniom, przekroczeniu limitu czasu i ponownym próbom. Są to obszary, które najprawdopodobniej powodują rozbieżności między zapisami bramki a fakturami dostawcy.

Zasady dotyczące wersji arkusza stawek i znaczników

Arkusz stawek powinien być obiektem wersjonowanym, a nie modyfikowalnym arkuszem kalkulacyjnym.

Minimalna liczba pól:

• dostawca;
• identyfikator modelu;
• klasa rozliczeniowa;
• jednostka, taka jak token, żądanie, obraz, sekunda audio lub jednostka narzędziowa;
• cena jednostkowa;
• waluta;
• efektywne znaczniki czasu rozpoczęcia i zakończenia;
• Zasady zaokrąglania;
• plan najemcy lub zasada dotycząca znaczników partnera;
• Odniesienie do źródła i metadane zatwierdzenia.

Zasady znaczników powinny być jasne. Na przykład:

• Koszt plus: koszt dostawcy plus 20%.
• Stała sprzedaż detaliczna: najemca płaci stałą cenę symboliczną niezależnie od ceny dostawcy.
• Warstwowe: pierwsze 10 milionów tokenów przy jednej stawce, a następnie niższej.
• Środki uwzględnione: użycie powoduje wykorzystanie miesięcznego limitu przed rozpoczęciem naliczania opłat za nadwyżkę.

Kompromis: wersjonowanie arkusza stawek zwiększa pracę operacyjną, ale zapobiega przekształceniu sporów dotyczących faktur w archeologię. Pracownik obsługi klienta powinien być w stanie wyjaśnić, dlaczego żądanie z 3 sierpnia zostało obciążone określoną stawką, bez sprawdzania dzisiejszych cen dostawcy.

Oddziel księgę rozliczeniową od analiz

Analityka i rozliczenia mają różne tolerancje. Analitykę można agregować, opóźniać, pobierać próbki lub korygować. Rozliczenia muszą być kompletne, idempotentne, możliwe do sprawdzenia i wyjaśnione.

Korzystaj z analiz w przypadku pytań takich jak:

• Które zespoły wykorzystują najwięcej tokenów?
• Które modele rozwijają się najszybciej?
• Gdzie buforowanie podpowiedzi może obniżyć koszty?
• Które klucze generują niezwykle drogie żądania?

Użyj księgi rozliczeniowej, aby odpowiedzieć na pytania takie jak:

• Czy to żądanie zostało autoryzowane w ramach salda najemcy?
• Która wersja arkusza stawek spowodowała tę opłatę?
• Czy niewykorzystana rezerwacja została zwolniona?
• Czy faktura klienta odpowiada rozliczonemu zużyciu?
• Czy użycie bramy odpowiada użyciu po stronie dostawcy?

Fakt: Konwencje semantyczne OpenTelemetry GenAI obejmują atrybuty użycia tokenów, takie jak tokeny wejściowe i wyjściowe. Jest to przydatne ze względu na obserwowalność i łączenie śladów ze zdarzeniami kosztowymi. Jednak atrybuty telemetryczne nie zastępują arkuszy stawek, rezerwacji, rozliczeń, zaokrągleń ani stanu faktury.

Codzienny przepływ uzgadniania

Uzgadnianie porównuje rozliczoną księgę bramy z wykorzystaniem po stronie dostawcy. Celem nie jest idealne porozumienie na każdym polu pośrednim. Celem jest wykrycie istotnych odchyleń na tyle wcześnie, aby można było skorygować faktury, arkusze stawek lub adaptery.

Praktyczna codzienna praca:

1. Grupuj zdarzenia księgi bramy według dostawcy, modelu, dzierżawcy lub klucza API, klasy rozliczeniowej i dnia UTC.
2. Pobierz wykorzystanie po stronie dostawcy pogrupowane według dostępnych wymiarów, takich jak identyfikator klucza API, model i dzień.
3. O ile to możliwe, normalizuj eksporty dostawców za pomocą tego samego kodu adaptera, który jest używany do odpowiedzi na żądania.
4. Porównaj ilości i koszty według klasy rozliczeniowej.
5. Oznacz odchylenie powyżej progów, np. 0,5% różnicy ilościowej lub dowolną dużą różnicę w kosztach bezwzględnych.
6. Klasyfikuj przyczyny rozbieżności: szacunki przesyłania strumieniowego, ponowne próby, nieudane żądania, rozliczanie pamięci podręcznej, zmiany aliasów modeli, opóźnione rekordy dostawców lub brakujące identyfikatory żądań.
7. Twórz zdarzenia korygujące zamiast edytować stare zdarzenia rozliczeniowe.

Zalecenie: używaj kluczy API dostawcy dla każdego dzierżawcy, jeśli jest to operacyjnie wykonalne, ponieważ upraszcza to uzgadnianie. Jeśli powoduje to zbyt duże obciążenie związane z zarządzaniem kluczami, mapuj wewnętrzne identyfikatory dzierżawy na metadane dostawcy, jeśli jest to obsługiwane, i utrzymuj niezawodny mostek identyfikatora żądań.

Linie faktury zrozumiałe dla klientów

Faktura skierowana do klienta nie powinna odzwierciedlać formatu JSON dostawcy. Powinien wyjaśnić projekt ustawy w stabilnych kategoriach biznesowych.

Przydatne kolumny na fakturze:

• zakres dat;
• etykieta dzierżawcy, projektu lub klucza API;
• model lub profil modelu;
• liczba żądań;
• niebuforowane tokeny wejściowe;
• tokeny wejściowe zapisane w pamięci podręcznej;
• tokeny wyjściowe;
• jednostki multimedialne lub narzędzia, jeśli mają zastosowanie;
• rabaty, kredyty lub narzuty;
• całkowita kwota i waluta.

W przypadku partnerów uwzględnij zarówno koszt hurtowy, jak i opłatę detaliczną, tylko jeśli wymaga tego model biznesowy. Wiele faktur od sprzedawców powinno pokazywać wyłącznie wykorzystanie detaliczne, podczas gdy panele partnerskie mogą pokazywać osobno marżę.

Kompromis: ujednolicony schemat faktur poprawia czytelność, ale szczegółowe informacje rozliczeniowe specyficzne dla dostawcy nadal wymagają luk awaryjnych. Domyślnie zachowaj proste wiersze faktury i zapewnij eksport dla zaawansowanych klientów, którzy potrzebują szczegółowych pól audytu.

Lista kontrolna wdrożenia

Przed uruchomieniem

• Zdefiniuj znormalizowane klasy rozliczeniowe dla wszystkich obsługiwanych dostawców.
• Twórz niezmienne wersje arkuszy stawek z datami obowiązywania.
• Wymagaj ograniczeń wyjściowych lub zastosuj domyślne ustawienia bramy.
• Zaimplementuj rezerwacje atomowe za pomocą kluczy idempotencji.
• Ustaw reguły zaokrąglania dla każdej waluty.
• Zdecyduj, jak fakturować tokeny buforowane, tokeny wnioskowania, jednostki multimedialne i opłaty za żądania.
• Ponowne próby testowania, przekroczenia limitu czasu, rozłączenia klientów i błędy dostawcy.
• Zbuduj mechanizm zdarzeń dostosowawczych zamiast edytować rozliczone zdarzenia.

Podczas obsługi żądania

• Uwierzytelnij najemcę i klucz.
• Rozwiąż ostateczny model po routingu i zasadach awaryjnych.
• Wybierz poprawną wersję arkusza stawek.
• Podać koszt w najgorszym przypadku.
• Zarezerwuj saldo lub odrzuć prośbę.
• Zapisz identyfikator żądania dostawcy, jeśli jest dostępny.
• Normalizuj użycie na podstawie odpowiedzi.
• Rozliczaj, zwalniaj niewykorzystaną rezerwację i emituj zdarzenia gotowe do wystawienia faktury.

Po obsłużeniu żądania

• Przeprowadzaj codzienne uzgadnianie według dostawcy, klucza, modelu, klasy rozliczeniowej i dnia.
• Przejrzyj szacunkowe rozliczenia dotyczące transmisji strumieniowych.
• Oznacz użycie modelu brakującymi wpisami w arkuszu stawek.
• Monitoruj rozbieżności spowodowane rozliczaniem tokenów w pamięci podręcznej.
• Generuj podglądy faktur klientów przed ostatecznym rozliczeniem.

Prognozy do zaplanowania

Przewidywanie: Rozliczenia za pomocą interfejsu API AI staną się bardziej wielowymiarowe, a nie mniej. Klasy tokenów, klasy pamięci podręcznej, jednostki multimedialne, wykonywanie narzędzi i liczniki związane z rozumowaniem będą prawdopodobnie nadal się rozwijać wraz ze zmianą możliwości modelu.

Przewidywanie: klienci będą oczekiwać wyjaśnień dotyczących użytkowania na poziomie żądania, klucza, projektu i faktury. Miesięczna suma bez możliwych do prześledzenia elementów zamówienia będzie niewystarczająca dla zespołów sprzedających dostęp do API lub egzekwujących przedpłacone budżety.

Przewidywanie: bramki, które już oddzielają wycenę, rezerwację, rozliczenie i uzgadnianie, szybciej dostosują się do nowych modeli cenowych, ponieważ mogą dodawać klasy rozliczeniowe bez przepisywania całego systemu fakturowania.

Wniosek, który można zastosować

Jeśli udostępniasz wielu dostawców sztucznej inteligencji za pośrednictwem jednej bramy, utwórz księgę rozliczeniową, zanim spory dotyczące rozliczeń wymuszą problem. Zacznij od czterech gwarancji:

1. Każde płatne żądanie otrzymuje wycenę przed inspekcją.
2. Każdy najemca opłacany z góry lub z limitem ma zarezerwowany budżet przed rozpoczęciem połączenia z dostawcą.
3. Odpowiedź każdego dostawcy jest normalizowana w postaci stabilnych klas rozliczeniowych.
4. Każdą fakturę można uzgodnić z wykorzystaniem po stronie dostawcy i z dokładną wersją arkusza stawek używaną w danym momencie.

Ta pętla kontroli sprawia, że ujednolicone rozliczenia interfejsu API AI są zrozumiałe dla klientów, wykonalne w przypadku środków przedpłaconych, elastyczne w przypadku znaczników partnerów i możliwe do kontrolowania w przypadku zmiany cen dostawcy lub formatów użytkowania.

Powiązane lektury

• łączenie śladów LLM z rejestrami użytkowania i kosztów
• budowanie portali dla sprzedawców z pomiarem wykorzystania najemców
• korzystanie z buforowania podpowiedzi przy jednoczesnym zachowaniu zrozumiałości rozliczeń