Jak egzekwować limity wydatków LLM na bramce API

Ograniczenia wydatków dostawców są przydatnymi zabezpieczeniami, ale rzadko odpowiadają faktycznemu poziomowi wydatków firmy na LLM. Finanse wymagają ograniczeń według zespołu, aplikacji, środowiska, klienta, partnera lub przepływu pracy. Zespoły ds. platform muszą egzekwować te limity, zanim żądanie zostanie przesłane do OpenAI, Anthropic, Gemini, Azure OpenAI lub innego dostawcy modelu. Właściwym punktem kontrolnym jest zazwyczaj brama API, w której można przypisać, oszacować, przyjąć, obniżyć poziom, zablokować i uzgodnić każde żądanie.

W tym przewodniku opisano implementację warstwy bramy dla AI API kontroli kosztów. Koncentruje się na egzekwowaniu budżetu w czasie rzeczywistym, a nie na retrospektywnych raportach dotyczących obciążeń zwrotnych czy szeroko zakrojonych programach optymalizacji kosztów.

Co może, a czego nie może zrobić kontrola wydatków dostawcy

Fakt: Główni dostawcy udostępniają przydatne mechanizmy kontrolne, ale działają w granicach określonych przez dostawcę. OpenAI dokumentuje miesięczne API limity wydatków na poziomie organizacji i projektu, wraz z wyraźnymi błędami dotyczącymi limitów organizacji, limitów projektu, przypisanych limitów użytkowania i wyczerpanych przedpłaconych kredytów. Anthropic dokumentuje limity wydatków i stawek w obszarze roboczym, a także udostępnia interfejsy API umożliwiające pobieranie skonfigurowanych limitów organizacji i obszaru roboczego na potrzeby wewnętrznych alertów. Google Same alerty dotyczące budżetu w chmurze nie ograniczają automatycznie wydatków, podczas gdy Google dokumentują także budżety z ograniczonymi wydatkami na kwalifikujące się usługi, takie jak Gemini API i platforma agentów. Przydział platformy Azure OpenAI jest przypisywany do subskrypcji, regionu, modelu i typu wdrożenia w jednostkach tokenów na minutę, a obliczenia limitów stawek mogą uwzględniać szybkie szacunki i maksymalną liczbę tokenów, a nie tylko tokeny z ostateczną opłatą.

Zalecenie: Pozostaw włączone limity wydatków natywne dla dostawcy jako zabezpieczenie ostateczne. Nie traktuj ich jako głównego mechanizmu egzekwowania budżetów wewnętrznych. Są zbyt uproszczone dla większości modeli własności i zwykle uruchamiają się, gdy ścieżka żądania wymknęła się już spod Twojej kontroli.

Prognoza: Kontrola dostawców będzie się stale poprawiać, ale przedsiębiorstwa nadal będą potrzebować zasad na poziomie bramy, ponieważ koszty wewnętrzne zmieniają się szybciej niż struktury kont dostawców.

Najpierw zdefiniuj model polityki budżetowej

Zacznij od zasad, a nie kodu. Brama nie może egzekwować budżetu, który nie został dokładnie opisany.

Praktyczny zapis zasad powinien obejmować:

• Właściciel budżetu: właściciel zespołu, działu, klienta, partnera, aplikacji lub przepływu pracy.
• Zakres: wymiary pasujące do żądań, takie jak team_id, app_id, environment, customer_id i workflow_id.
• Interwał resetowania: codziennie, co tydzień, co miesiąc, okres umowy lub okno niestandardowe.
• Miękki próg: punkt, w którym brama ostrzega, obniża wersję, zmniejsza długość danych wyjściowych lub przekierowuje do tańszych modeli.
• Twardy próg: punkt, w którym blokowany jest ruch niekrytyczny.
• Dozwolone modele: modele, których może używać ten zakres.
• Modele awaryjne: modele tańsze lub o mniejszej wydajności dozwolone po miękkim progu.
• Krytyczność: czy obciążenie jest krytyczne dla produkcji, skierowane do użytkownika, wewnętrzne, wsadowe czy eksperymentalne.
• Pominięcie awaryjne: kto może przedłużyć limit, na jak długo i z jaką ścieżką audytu.
• Cele powiadomień: kanał Slack, grupa e-mailowa, usługa incydentów, webhook lub kolejka finansowa.

Przykładowa zasada:

{
  "budget_id": "budget_support_prod_monthly",
  "owner_type": "team",
  "owner_id": "customer_support",
  "scope": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production"
  },
  "currency": "USD",
  "limit": 5000.00,
  "reset_interval": "monthly",
  "soft_threshold_percent": 80,
  "hard_threshold_percent": 100,
  "allowed_models": ["premium-chat", "standard-chat", "economy-chat"],
  "fallback_models": ["standard-chat", "economy-chat"],
  "criticality": "user_facing_production",
  "on_soft_limit": ["notify", "downgrade_model", "reduce_max_output_tokens"],
  "on_hard_limit": ["block_noncritical", "allow_emergency_override"],
  "notification_targets": ["slack:#support-platform", "email:[email protected]"]
}

Wymagaj metadanych własności przy każdym żądaniu

Egzekwowanie budżetu zależy od atrybucji. Jeśli żądania nie można przypisać do zakresu budżetu, brama nie może podjąć wiarygodnej decyzji o przyjęciu.

Wymagaj od klientów wewnętrznych wysyłania metadanych dotyczących stabilnej własności:

{
  "model": "premium-chat",
  "messages": [...],
  "max_tokens": 1200,
  "metadata": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production",
    "customer_id": "cust_48291",
    "workflow_id": "ticket_reply_draft"
  }
}

Zalecenie: Wdrażaj to etapami. Najpierw zarejestruj nieprzypisany ruch. Następnie ostrzeż o tym. Następnie odrzuć nieprzypisany ruch produkcyjny, gdy właściciele będą mieli czas na zaktualizowanie klientów. W przypadku ruchu rozwojowego należy go poddać kwarantannie i umieścić w budżecie domyślnym z niskim limitem, zamiast mieszać go z wydatkami na produkcję.

Sprawdź także metadane w swoim systemie tożsamości. Klient nie powinien mieć możliwości ubiegania się o budżet innego zespołu poprzez zmianę team_id. Powiąż klucze API, konta usług lub dane uwierzytelniające partnerów z dozwolonymi zakresami budżetu.

Oszacuj koszt przed wysyłką

Oszacowanie wstępne to podstawa egzekwowania zasad w czasie rzeczywistym. Brama szacuje maksymalny prawdopodobny koszt przed wysłaniem żądania do dostawcy.

Estymator potrzebuje:

• Modelowe tabele cen dotyczące danych wejściowych, wyjściowych, danych wejściowych przechowywanych w pamięci podręcznej, partii, użycia narzędzi, obrazów, osadzania i innych płatnych wymiarów.
• Tokenizator lub logika szacowania tokenów na rodzinę modeli.
• Monit o liczbę lub szacunkową liczbę tokenów.
• Żądany max_tokens lub maksymalna długość wyjściowa.
• Założenia dotyczące pamięci podręcznej, jeśli buforowanie podpowiedzi wpływa na rozliczenia.
• Specyficzne dla dostawcy reguły rozliczeniowe dotyczące ponownych prób, wywołań narzędzi, tokenów wnioskowania, generowania obrazów lub wprowadzania danych multimodalnych.

Przykładowy wynik estymatora:

{
  "request_id": "req_7f1b",
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "model": "premium-chat",
  "input_tokens_estimated": 1850,
  "max_output_tokens": 1200,
  "estimated_cost": 0.0845,
  "estimate_basis": "prompt_tokens_plus_max_output_tokens",
  "confidence": "conservative"
}

Zalecenie: Koszt wstępnego lotu należy traktować jako ostrożną szacunkową kwotę wstępu, a nie prawdę księgową. Jeśli użytkownik poprosi o max_tokens: 4000, zarezerwuj w stosunku do tej górnej granicy, nawet jeśli odpowiedź zwykle kończy się na 700 tokenach. Zmniejsza to ryzyko przekroczenia budżetu, ale może odrzucić wnioski, które zostałyby zrealizowane w ramach budżetu. Taki kompromis jest lepszy w przypadku ścisłej kontroli finansów i mniej atrakcyjny w przypadku wewnętrznych narzędzi eksploracyjnych.

Zarezerwuj budżet przed wysłaniem żądania

Częstym trybem awarii jest sprawdzanie budżetu, znajdowanie dostępnego salda, a następnie przepuszczanie wielu jednoczesnych żądań przed zarejestrowaniem wydatków. Rozwiązaniem jest rezerwacja.

Kolejność wstępu powinna być następująca:

1. Uwierzytelnij osobę dzwoniącą.
2. Sprawdź metadane własności.
3. Rozwiąż obowiązującą politykę budżetową.
4. Oszacuj koszt żądania.
5. Zarezerwuj atomowo szacunkowy koszt ze sklepu budżetowego.
6. Wyślij żądanie do dostawcy tylko wtedy, gdy rezerwacja się powiedzie.
7. Zwolnij niewykorzystaną rezerwację po jej zakończeniu.
8. Zarejestruj ostateczne szacunkowe lub zgłoszone przez dostawcę wykorzystanie.

Magazyn rezerwacji musi obsługiwać aktualizacje atomowe. Redis ze skryptami Lua, transakcjami PostgreSQL lub dedykowaną usługą księgową może działać. Ważną właściwością jest to, że dwa żądania nie mogą wydać tego samego pozostałego budżetu.

Przykładowy zapis rezerwacji:

{
  "reservation_id": "res_9d42",
  "request_id": "req_7f1b",
  "budget_id": "budget_support_prod_monthly",
  "estimated_cost": 0.0845,
  "state": "reserved",
  "expires_at": "2026-09-28T12:45:00Z"
}

Używaj krótkich terminów wygaśnięcia rezerwacji, aby porzucone prośby nie blokowały budżetu na zawsze. Czyszczenie w tle powinno zwolnić wygasłe rezerwacje, które nigdy nie osiągnęły stanu końcowego.

Oddziel limity miękkie od limitów twardych

Miękkie i twarde limity powinny zachowywać się inaczej. Miękki limit jest sygnałem polityki. Twardy limit to decyzja o przyjęciu.

Zachowanie miękkiego limitu

Kiedy zakres przekroczy miękki próg, brama może nadal obsługiwać ruch, zmniejszając jednocześnie wydatki. Przydatne odpowiedzi obejmują:

• Wysyłaj alerty do właściciela budżetu oraz kanału finansowego lub platformy.
• Dodaj nagłówki odpowiedzi pokazujące stan limitu i pozostały budżet.
• Kieruj niekrytyczne żądania do tańszych modeli.
• Zmniejsz max_tokens, aby uzyskać szczegółowe przepływy pracy.
• Wyłącz drogie funkcje opcjonalne, takie jak generowanie wielu próbek.
• Wymagaj zatwierdzenia nowych eksperymentów w ramach tego zakresu budżetu.

Przykładowe metadane odpowiedzi na miękkie limity:

{
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "limit_state": "soft_limit_exceeded",
  "estimated_cost": 0.0310,
  "remaining_budget": 912.44,
  "applied_policy": ["downgrade_model", "reduce_max_output_tokens"],
  "selected_model": "standard-chat"
}

Zachowanie twardego limitu

Przy twardym progu brama powinna blokować ruch niekrytyczny za pomocą przewidywalnego kontraktu błędu.

{
  "error": {
    "type": "budget_limit_exceeded",
    "code": "llm_budget_hard_limit",
    "message": "The budget for this scope has been exhausted.",
    "budget_scope": "team:customer_support/app:support_assistant/env:production",
    "retry_after": "2026-10-01T00:00:00Z",
    "override_required": true
  }
}

Nie zwracaj błędów w kształcie dostawcy w przypadku niepowodzeń budżetu bramy. Klienci wewnętrzni muszą rozróżnić limity stawek dostawcy, limity wydatków dostawcy, limity wydatków bramy, błędy uwierzytelnienia i odmowy zasad.

Jawna obsługa żądań transmisji strumieniowej

Transmisja strumieniowa stwarza inny problem z egzekwowaniem prawa. Żądanie zostaje przyjęte, zanim brama pozna ostateczne tokeny wyjściowe, a wygenerowane tokeny mogą w dalszym ciągu akumulować koszty, gdy strumień jest otwarty.

Praktyczny wzór to:

1. Zarezerwuj konserwatywną kwotę w oparciu o tokeny podpowiedzi i tokeny maksymalnej wydajności.
2. Jeśli to możliwe, śledź wygenerowane tokeny podczas transmisji.
3. Zatrzymaj generowanie, jeśli zarezerwowana kwota zostanie wyczerpana.
4. Zwróć powód zakończenia, który może obsłużyć klient.
5. Uzgodnij rzeczywiste wykorzystanie po przesłaniu przez dostawcę ostatecznych metadanych dotyczących użycia lub po zakończeniu szacowania bramy.

Przykładowe zdarzenie zakończenia strumienia:

{
  "type": "response.completed",
  "finish_reason": "budget_exhausted",
  "budget_scope": "customer:cust_48291/workflow:ticket_reply_draft",
  "estimated_cost": 0.0845,
  "remaining_budget": 0.00
}

Kompromis: Odcięcie strumienia chroni budżet, ale może generować niekompletne wyniki. W przypadku przepływów pracy wymagających kompletnych odpowiedzi strukturalnych preferuj blokowanie wstępne lub obniżenie wersji modelu przed rozpoczęciem przesyłania strumieniowego. W przypadku czatu akceptowalny może być powód zakończenia uwzględniający budżet, jeśli klient może poprosić użytkownika o ponowną próbę później lub kontynuowanie korzystania z tańszego modelu.

Udostępnij klientom stan budżetu

Egzekwowanie budżetu jest łatwiejsze, gdy dzwoniący mogą zobaczyć, co się stało. Dodaj nagłówki odpowiedzi lub metadane dla klientów wewnętrznych i interfejsów API partnerów.

Przydatne pola obejmują:

• budget_scope
• limit_state: normalny, soft_limit_near, soft_limit_exceeded, hard_limit_exceeded
• estimated_cost
• reserved_cost
• final_cost_when_available
• remaining_budget
• applied_policy
• selected_model

W przypadku interfejsów API partnerów publicznych należy unikać ujawniania nazw wewnętrznych zespołów lub podstaw kosztów, jeśli jest to wrażliwe z handlowego punktu widzenia. Zamiast tego ujawnij stan przydziału bezpiecznego dla dzierżawy, taki jak remaining_quota, limit_state i retry_after.

Uzgodnij szacunki z wykorzystaniem dostawcy

Egzekwowanie zasad w momencie żądania i raportowanie kosztów na poziomie księgowym są ze sobą powiązane, ale to nie to samo. Oszacowanie bramki podejmuje decyzję o przyjęciu w warunkach niepewności. Eksporty rozliczeń dostawców, interfejsy API użytkowania i faktury zapewniają dane, którymi zajmą się finanse.

Zalecenie: Przynajmniej codziennie uzgadniaj wydatki szacowane przez bramę z wykorzystaniem raportowanym przez dostawcę. Różnice mogą wynikać z niedopasowania tokenizera, buforowania podpowiedzi, rabatów zbiorczych, ponownych prób, nieudanych połączeń, zaokrągleń specyficznych dla dostawcy, rozliczeń za użycie obrazu lub narzędzia oraz opóźnionego eksportu rozliczeń.

Zadanie pojednania powinno:

1. Importuj dane dotyczące wykorzystania i kosztów dostawcy.
2. Normalizuj to zgodnie ze schematem użycia bramy.
3. Dopasuj rekordy dostawcy do identyfikatorów żądań bramy, jeśli są dostępne.
4. Przydziel niedopasowane wydatki dostawcy do najbardziej konkretnego znanego zakresu.
5. Dostosuj księgi budżetu pod kątem nadmiernej lub niedostatecznej rezerwacji.
6. Emituj raporty o rozbieżnościach według dostawcy, modelu, zespołu, aplikacji i środowiska.

Użyj znormalizowanych pól telemetrycznych dla tokenów wejściowych, tokenów wyjściowych, modelu, dostawcy, identyfikatora żądania i stanu. Konwencje semantyczne OpenTelemetry GenAI definiują atrybuty użycia tokenów, które mogą pomóc w standaryzacji danych telemetrycznych użycia u różnych dostawców.

Wybierz świadomie zachowanie w przypadku awarii lub zamknięcia

Sklep budżetowy staje się częścią ścieżki żądania. Jest to główny koszt architektoniczny egzekwowania przepisów w czasie rzeczywistym.

Jeśli sklep budżetowy jest niedostępny, brama wymaga określonego zachowania:

• Niepowodzenie otwarcia: zezwalaj na żądania i zaznacz je do późniejszego uzgodnienia. Chroni to dostępność, ale może spowodować nadmierne wydatki.
• Awaria zamknięta: blokuje żądania do czasu udostępnienia stanu budżetu. Chroni to wydatki, ale może zakłócić przepływ pracy w produkcji.
• Ograniczenie awarii: zezwalaj tylko na krytyczny ruch produkcyjny, używaj tańszych modeli, stosuj niskie limity na żądanie i blokuj eksperymenty lub obciążenia wsadowe.

Zalecenie: użyj ograniczenia w przypadku większości systemów biznesowych. Krytyczne przepływy pracy w produkcji są kontynuowane przy zmniejszonym narażeniu na koszty, natomiast obciążenia uznaniowe są wstrzymywane do czasu przywrócenia płaszczyzny kontrolnej.

Lista kontrolna wdrożenia

• Określ zakresy budżetu i metadane własności.
• Powiąż API kluczy lub kont usług z dozwolonymi zakresami.
• Twórz rekordy zasad z limitami miękkimi i twardymi, dozwolonymi modelami, rezerwami awaryjnymi, zastąpieniami i celami powiadomień.
• Stwórz narzędzie do szacowania kosztów uwzględniające dostawców.
• Wykorzystaj rezerwacje budżetu atomowego przed wysyłką dostawcy.
• Zwolnij niewykorzystane rezerwacje po zakończeniu.
• Zaimplementuj błędy związane z twardym limitem dzięki stabilnej umowie.
• Dodaj śledzenie tokenów przesyłania strumieniowego i powody zakończenia uwzględniające budżet.
• Wyświetl stan budżetu za pomocą wewnętrznych nagłówków lub metadanych odpowiedzi.
• Włącz limity wydatków dostawców jako zabezpieczenia.
• Codziennie uzgadniaj szacunki dotyczące bramy z raportami dotyczącymi wykorzystania i kosztów dostawcy.
• Powiadomienie o rozbieżnościach, nieprzypisanym ruchu, wyczerpanych budżetach i zastąpieniu użycia.

Wnioski, które można zastosować

Aby niezawodnie egzekwować limity wydatków LLM, umieść decyzję tam, gdzie żądania wpływają do Twojego systemu. Ograniczenia dostawców mogą powstrzymać szkody na poziomie konta, ale zasady bramy mogą egzekwować limity biznesowe, o które faktycznie proszą liderzy: budżet zespołu, aplikacji, środowiska, klienta, partnera i przepływu pracy.

Projekt minimalnego wykonalnego projektu jest prosty: wymaga metadanych własności, szacuje koszt przed wysyłką, rezerwuje budżet atomowo, stosuje miękkie i twarde progi, oddzielnie obsługuje przesyłanie strumieniowe i uzgadnia z danymi o użytkowaniu dostawcy. Najtrudniejszą częścią nie jest decyzja dotycząca pierwszego bloku. Najtrudniejszą częścią jest uczynienie systemu na tyle przewidywalnym, aby finanse mu ufały, a zespoły produkcyjne mogły kontynuować działanie, gdy budżet jest pod presją.

Powiązana lektura

• Księga kosztów LLM dla każdego zespołu