LLM API według klucza rozwiązują problem, którego nie rozwiązują kontrole rozliczeń na poziomie konta: jeden skrypt, agent, klient, środowisko lub dane uwierzytelniające, które wyciekły, nie powinny być w stanie wykorzystać całego budżetu API, zanim ktokolwiek zauważy.
Większość zespołów zaczyna od jednego klucza dostawcy i jednego miesięcznego budżetu. Działa to w przypadku wczesnych eksperymentów, ale przestaje działać, gdy tylko to samo konto obsługuje ruch produkcyjny, rozwój lokalny, narzędzia do kodowania, zadania w tle, dzierżawców klientów, boty Telegram lub obciążenia sprzedawców. Problemem nie jest tylko to, ile konto w sumie wydaje. Praktyczną kwestią jest to, czy każdy klucz ma jasnego właściciela, jasny budżet, przewidywalny tryb awarii i wystarczające śledzenie użycia, aby wyjaśnić, co się stało.
Kontrola dostawców jest różna. Niektóre platformy oferują limity wydatków organizacji lub projektu. Niektóre eksponują ograniczenia obszarów roboczych. Niektóre zapewniają alerty, które nie zatrzymują ruchu. Niektóre limity są raczej limitami stawek niż limitami pieniężnymi. Trwały projekt kontroli kosztów traktuje limity dostawcy jako jedną warstwę, a następnie dodaje budżety AI API dla poszczególnych kluczy na granicy bramy lub aplikacji, gdzie można zidentyfikować indywidualne obciążenia.
Jakie są limity wydatków na klucz
Limit wydatków na klucz to budżet powiązany z konkretnym kluczem API lub kluczem wirtualnym. Klucz może reprezentować osobę, obciążenie pracą, klienta, środowisko, automatyzację, bota lub usługę podrzędną. Gdy użycie przypisane do tego klucza osiągnie skonfigurowany budżet, platforma może ostrzegać, ograniczać, blokować, odrzucać nowe żądania, wyznaczać inne trasy lub wymagać od operatora podniesienia limitu.
Różni się to od limitu konta dostawcy. Limit konta lub organizacji chroni relację rozliczeniową najwyższego poziomu, ale zwykle nie pozwala stwierdzić, czy wydatki pochodzą z usługi produkcyjnej, skryptu testowego, złamanego klucza, czy od pojedynczego klienta. Sterowanie poszczególnych klawiszy zmniejsza promień wybuchu. Sprawiają, że granica budżetu pokrywa się z granicą operacyjną.
Na przykład indywidualny programista może używać oddzielnych kluczy dla osobistego asystenta, agenta programującego, zadania przetwarzania dokumentów i publicznej aplikacji demonstracyjnej. Konto może mieć miesięczny limit, ale każdy klucz powinien mieć swój własny budżet i historię użytkowania. Publiczne demo wymaga małego, twardego limitu. Agent kodujący może potrzebować dziennego limitu i ograniczeń modelowych. Zadanie związane z dokumentem może wymagać większego budżetu tymczasowego, ale ścisłej kontroli współbieżności. Traktowanie ich wszystkich jako jednego wspólnego klucza sprawia, że zarządzanie przydziałami AI API opiera się głównie na domysłach.
Limity wydatków, przydziały i limity stawek nie są takie same
Wiele incydentów związanych z kosztami zaczyna się od problemu ze słownictwem. Przydział, limit szybkości i limit wydatków mogą blokować żądania, ale kontrolują różne ryzyko.
Limity wydatków
Limit wydatków to próg pieniężny. Można go obliczyć na podstawie dokładnego zużycia zgłoszonego przez dostawcę, szacowanego kosztu bramy, ustalonego wykorzystania tokena, kredytów przedpłaconych lub lokalnego katalogu cen. Limity wydatków mogą być miękkie lub twarde. Limity miękkie powiadamiają, ale pozwalają na kontynuację użytkowania. Limity twarde próbują zatrzymać nowe użycie po osiągnięciu progu.
Twarde limity są cenne, ale nie należy ich traktować jako matematycznie natychmiastowych. Równoczesne żądania, odpowiedzi przesyłane strumieniowo, zadania asynchroniczne, opóźnione raportowanie dostawców i rozproszone egzekwowanie mogą pozwolić na niewielkie przekroczenia. Dobre systemy wyraźnie podkreślają takie zachowanie i odpowiednio je projektują.
Przydziały
Przydział to szerszy limit. Może odnosić się do żądań, tokenów, obrazów, modeli, kredytów, współbieżności, poziomu rozliczeniowego lub pojemności obszaru roboczego. Niektórzy dostawcy używają języka kwot do określenia uprawnień na poziomie konta, zamiast kontrolować wydatki. Limit może być przydatny, nie będąc budżetem.
Limity szybkości
Limit szybkości kontroluje ruch w czasie: żądania na minutę, tokeny na minutę, równoczesne żądania i podobne miary. Limity szybkości są niezbędne do zapobiegania pętlom ponownych prób i nadużyciom, ale nie są równoważne limitom budżetu LLM API. Dziesięć tanich żądań i dziesięć drogich żądań wymagających wysokiego kontekstu może mieć bardzo różne koszty.
Najsilniejszy projekt łączy w sobie wszystkie trzy: limity wydatków, limity alokacji oraz limity szybkości lub współbieżności dotyczące prędkości.
Dlaczego limity natywne dostawcy nie są wystarczające
Limity natywne dostawcy są ważne. OpenAI obsługuje kontrolę wydatków na poziomie projektu i organizacji, alerty, klucze o zasięgu projektu, uprawnienia punktu końcowego, konfigurację modelu i operacje limitów szybkości. Anthropic obsługuje klucze o zasięgu obszaru roboczego z limitami wydatków i stawek w obszarze roboczym poniżej limitów na poziomie organizacji. Klucze Google Gemini są powiązane z projektami Google w chmurze w zakresie rozliczeń i przydziału, natomiast limity stawek zależą od poziomu wykorzystania projektu i mogą się różnić w zależności od stanu konta. Cloudflare AI Gateway może definiować limity wydatków według dostawcy, modelu i metadanych, z blokowaniem żądań, gdy skonfigurowane reguły przekraczają budżet.
Te elementy sterujące są pomocne, ale nie wszystkie zapewniają taką samą szczegółowość. Projekt dostawcy może stanowić właściwą granicę dla jednej aplikacji i zbyt szeroką dla innej. Obszar roboczy może oddzielać zespoły, ale nadal łączyć kilka usług. Standardowy klucz dostawcy może nie identyfikować dalszego klienta lub użytkownika wewnętrznego. Alerty mogą powiadamiać, gdy szkody są już w toku. Limity stawek mogą spowolnić złą pętlę bez odzwierciedlania ceny modelu.
Warstwa bramy wypełnia lukę, wydając klucze odpowiadające rzeczywistemu sposobowi działania. Może dołączać budżet, zasady modelu, limity stawek, limity współbieżności i analizy użytkowania do tej samej tożsamości. Może także normalizować kontrolę między dostawcami, dzięki czemu nie jest konieczne, aby każdy dostawca API obsługiwał dokładnie ten sam model zasad.
Wybierz właściwą granicę atrybucji
Budżety na klucz działają tylko wtedy, gdy klucz reprezentuje coś znaczącego. Przed ustawieniem API kluczowych limitów wydatków zdecyduj, co powinien oznaczać każdy klucz.
Przydatne granice obejmują usługi produkcyjne, środowiska programistyczne, zadania CI, lokalne eksperymenty, dzierżawców klientów, publiczne demonstracje, Telegram boty, agenci kodujący, procesy wsadowe, sprzedawcy i narzędzia pomocy. Klucz reprezentujący zbyt wielu niepowiązanych aktorów nie może wymusić przydatnego budżetu. Jeśli dziesięciu klientów ma ten sam klucz, budżet klucza może chronić Twoje konto, ale nie wskaże, który klient spowodował wydatek.
Czasami atrybucja na poziomie klucza nie wystarczy. Produkt SaaS może używać jednego klucza zaplecza, podczas gdy wielu użytkowników końcowych generuje żądania. W takim przypadku żądanie powinno zawierać metadane klienta, użytkownika, obszaru roboczego lub obciążenia, aby brama mogła generować analizy kosztów dla poszczególnych użytkowników lub dzierżawców. Klucz pozostaje poświadczeniem egzekwowania prawa, natomiast metadane dodają drugi wymiar atrybucji.
W przypadku produktów zbudowanych na platformie Model Gate lub podobnych, tutaj również istotna staje się automatyzacja partnera API: tworzenie kluczy, przypisywanie grup, zmiany limitów, zawieszanie się, rotacja i odczyty użycia powinny być częścią udostępniania, a nie ręcznej pracy na konsoli.
Praktyczna hierarchia budżetu
Pojedynczy limit rzadko wystarczy. Ograniczenia użycia dobrej sztucznej inteligencji API są nakładane na siebie, więc wygrywają najsurowsze obowiązujące zasady.
U góry ustaw limit awaryjny obowiązujący dla całego konta. Chroni to całą relację rozliczeniową, jeśli wszystkie inne kontrole zawiodą. Poniżej znajdują się oddzielne środowiska produkcyjne, rozwojowe, postojowe i eksperymentalne. Rozwój nie powinien być w stanie zagłodzić produkcji. Produkcja powinna mieć wyższe limity, ale bardziej rygorystyczne ostrzeżenia i przeglądy.
Następnie zgrupuj powiązane klucze. Grupa może reprezentować klienta, zespół, rodzinę botów, klienta agencji, konto sprzedawcy lub aplikację. Budżety grupowe są przydatne, gdy wiele kluczy musi mieć wspólny limit, ale księga powinna nadal zachowywać indywidualne przypisania kluczy. W przeciwnym razie limit grupy może ukryć, który klucz spowodował wydatek.
Na koniec ustaw budżety na klucz. Małe, ryzykowne, publiczne, autonomiczne lub eksperymentalne klucze powinny mieć niskie twarde limity. Zaufane klucze produkcyjne mogą mieć wyższe budżety, ale nadal wymagają alertów i reguł eskalacji. Nieograniczona liczba kluczy powinna być rzadka i regularnie sprawdzana.
Co śledzić przed i po każdym żądaniu
Egzekwowanie wydatków zależy od przechwytywanych danych. Każde żądanie powinno być powiązane co najmniej z identyfikatorem klucza lub prefiksem klucza, identyfikatorem grupy, klienta lub obciążenia, jeśli jest dostępny, żądanym aliasem modelu, ustalonym dostawcą i modelem, typem żądania, tokenami wejściowymi, tokenami wyjściowymi, użyciem nośnika lub narzędzia, szacunkowym kosztem, rozliczonym kosztem, statusem i sygnaturą czasową.
Te dane mają więcej mocy niż tylko rozliczenia. Pozwala identyfikować błędy routingu w modelach premium, burze ponownych prób, żądania przekroczenia budżetu, klucze bez niedawnej recenzji właściciela i obciążenia, których szybkość wykorzystania nagle się zmieniła. W celu szerszej analizy dedykowany pulpit nawigacyjny analizy użycia AI API powinien pokazywać wydatki według klucza, modelu, dostawcy, grupy, klienta i okna czasowego.
Nie polegaj w tym przypadku wyłącznie na panelach dostawców. Dane dostawcy mogą być opóźnione, mieć inny zakres, być zagregowane w niewłaściwych granicach lub może brakować dalszych metadanych potrzebnych aplikacji. Faktury dostawcy są nadal niezbędne do rozliczenia, ale nie zastępują Twojej własnej księgi użytkowania.
Kontrole przed lotem, rezerwacje i rozliczenia
Sprawny system kontroli wydatków podejmuje decyzję przed wysłaniem żądania do głównego źródła, a następnie koryguje księgowanie, gdy znane jest ostateczne wykorzystanie.
Kontrola wstępna pyta, czy klucz jest aktywny, czy model jest dozwolony, czy żądanie mieści się w limitach szybkości i współbieżności oraz czy szacowany koszt mieści się w pozostałym budżecie. W przypadku tanich synchronicznych połączeń tekstowych oszacowanie to może być proste. W przypadku kosztownych żądań powinien uwzględniać maksymalny wkład, maksymalny wynik, cenę modelu, ponowne próby, trasy awaryjne, koszty mediów, wywołania narzędzi i zakończenie asynchronizacji.
W przypadku prac kosztownych lub długotrwałych użyj wzorca rezerwacji. Zarezerwuj szacunkową kwotę przed wysyłką. Gdy dostawca zwróci ostateczne wykorzystanie, rozlicz rzeczywisty koszt i zwolnij lub dostosuj rezerwację. Zmniejsza to ryzyko, że wiele jednoczesnych żądań przejdzie tę samą kontrolę budżetu i łącznie przekroczy limit.
Rozliczenie wymaga jednoznacznych reguł dotyczących przesyłania strumieniowego, anulowania, błędów dostawcy, przekroczeń limitu czasu, zadań asynchronicznych, żądań wsadowych i nieznanych wyników. Jeśli ostateczne wykorzystanie jest niedostępne, system powinien wiedzieć, czy wstrzymać rezerwację, rozliczyć się z kosztorysem, ponowić próbę pobrania informacji o wykorzystaniu, czy też zakończyć się niepowodzeniem dla przyszłych żądań. Właściwa polityka zależy od wymagań dotyczących kosztów i niezawodności obciążenia.
Paruj budżety z elementami sterującymi modelu
Dostęp do modelu to jedna z najprostszych metod kontroli kosztów. Klucz programistyczny nie powinien umożliwiać odwoływania się do modelu rozumowania premium, modelu o wysokim kontekście, modelu wideo ani hostowanego narzędzia, chyba że dostęp ten jest zamierzony. Publiczna wersja demonstracyjna może wymagać jedynie profilu taniego modelu. Zadanie wyodrębniania wsadowego może wymagać określonego modelu i nie można zastosować droższego.
Modelowe listy dozwolonych, list odrzuconych i profile tras zapobiegają niespodziankom przed wydaniem pieniędzy. Ułatwiają także uzasadnienie budżetu, ponieważ maksymalny możliwy koszt na żądanie jest węższy. Jeśli rezerwowa ścieżka jest dozwolona, ścieżka rezerwowa musi być zgodna z oryginalnym budżetem i uprawnieniami klucza. W przeciwnym razie nieudana tania trasa może stać się nieplanowaną, kosztowną trasą.
Wybór tańszych lub bardziej przewidywalnych modeli stanowi część szerszej ujednoliconej sztucznej inteligencji API rozliczeniowej strategii, ale powinien być egzekwowany w przypadku składania wniosków, a nie tylko sprawdzany po otrzymaniu faktur.
Alerty miękkie i twarde egzekwowanie
Alerty miękkie i twarde służą różnym celom. Alerty najlepiej sprawdzają się w przypadku kluczy zarządzanych przez człowieka, gdy dostępność ma znaczenie i operator może odpowiedzieć. Typowe progi to 50, 80, 90 i 100 procent budżetu. Agenci autonomiczni, aplikacje publiczne i wersje próbne skierowane do klienta zwykle wymagają niższych progów, ponieważ mogą szybko wyczerpać budżet bez ludzkiej intencji.
Twarde limity chronią pieniądze, ale mogą zakłócać przepływ pracy. Klucz produkcyjny osiągający twardy limit może powodować błędy widoczne dla użytkownika. Potok danych może zostać zatrzymany w połowie. Agent kodujący może ponowić próbę, chyba że błąd zostanie usunięty. Twarde egzekwowanie powinno zwrócić przewidywalne błędy, zwykle 429 lub niepowodzenie związane z płatnością, w zależności od projektu API, z kodami przyczyny czytelnymi maszynowo, czasem resetowania, jeśli jest znany, oraz wskazówkami dotyczącymi środków zaradczych.
Zachowanie klienta ma znaczenie. Błędy ogólne mogą powodować agresywne ponawianie prób, pogarszając incydent. Błędy związane z przekroczeniem budżetu powinny informować dobrze zachowujących się klientów, aby nie podejmowali ponownych prób do czasu zmiany budżetu lub zresetowania okna.
Resetuj okna i wydatki przez cały okres
Każdy budżet potrzebuje okna. Budżety miesięczne są dostosowane do cykli rozliczeniowych. Dzienne budżety redukują szkody krótkoterminowe. Okna obrotowe są przydatne do kontroli serii. Ręczne resetowanie może obsługiwać przedpłacone pakiety klientów, wersje próbne lub wewnętrzne eksperymenty.
Bez względu na wybrany model resetowania, rozróżnij wykorzystanie w bieżącym okresie od wydatków przez cały okres użytkowania. Zresetowanie miesięcznego użycia klucza nie powinno wymazać zdarzeń audytu, całkowitych historycznych wydatków, dowodów bezpieczeństwa ani zapisów księgowych. To rozróżnienie ma kluczowe znaczenie w przypadku kompromisu lub sporu z klientem.
Określ także, co dzieje się w czasie resetowania. Czy budżet resetuje się o północy czasu UTC, czasie lokalnym konta, rocznicy subskrypcji lub dacie niestandardowej umowy? Czy aktywne rezerwacje są przenoszone? Czy opłaty za zadania asynchroniczne są naliczane według czasu rozpoczęcia czy zakończenia? Te szczegóły mają znaczenie w pobliżu granicy.
Sprawy dotyczące obsługi pieniędzy dziesiętnych
Koszty wykorzystania LLM są często małe w przeliczeniu na żądanie, ale łącznie duże. Arytmetyka zmiennoprzecinkowa może powodować błędy zaokrągleń w pobliżu progów budżetu, zwłaszcza przy mnożeniu liczby tokenów przez katalogi cen i mnożniki wykorzystania. Przechowuj i porównuj wartości pieniężne za pomocą arytmetyki dziesiętnej.
DokumentacjaModel Gate partnera API odzwierciedla ten wzorzec, przedstawiając pola finansowe i użytkowe jako JSON ciągi znaków i instruując integratorów, aby używali arytmetyki dziesiętnej o dowolnej precyzji zamiast liczb zmiennoprzecinkowych. To właściwa postawa w przypadku egzekwowania wydatków: celowe analizowanie ciągów dziesiętnych, sprawdzanie ich poprawności i unikanie binarnych porównań zmiennoprzecinkowych przy podejmowaniu decyzji, czy klucz ma pozostały budżet.
Jak Model Gate pasuje
Model Gate ma znaczenie w przypadku budżetów LLM na klucz, ponieważ znajduje się pomiędzy aplikacjami a wieloma zewnętrznymi dostawcami AI. Zamiast polegać na każdym dostawcy w zakresie udostępniania identycznej kontroli budżetu, brama może scentralizować zarządzanie kluczami, przypisywanie rozliczeń, analizę użycia i decyzje dotyczące egzekwowania prawa w oparciu o klucze i grupy wydawane przez bramę.
PartnerModel Gate API dokumentuje pola i operacje na poziomie klucza, w tym spend_limit, użycie, pozostały limit wydatków, rpm_limit, concurrency_limit, blokowanie i odblokowywanie, rotacja kluczy i resetowanie użycia. Dokumentuje także limity wydatków na poziomie grupy, wykorzystanie, łączne wydatki, limity szybkości i współbieżności, podstawę i mnożnik ceny użytkowania, członkostwo w grupie, wykorzystanie grupy i statystyki grup.
Te elementy sterujące obsługują praktyczne wzorce: tworzenie oddzielnych kluczy dla każdego klienta lub obciążenia, grupowanie kluczy w ramach sprzedawcy lub aplikacji, zamrażanie podejrzanego klucza, rotacja ujawnionych danych uwierzytelniających, odczytywanie pozostałego budżetu przed zezwoleniem na działanie i resetowanie wykorzystania okresu bez zmiany całkowitych wydatków ani salda konta.
Ważne zastrzeżenie polega na tym, że kontrole bramy to lokalne kontrole egzekwowania i rozliczania. Nie oznaczają one, że dostawca wyższego szczebla ma natywne egzekwowanie budżetu dla każdego klucza dla każdego żądania. Dobre wdrożenia nadal pozwalają na pogodzenie się z rozliczeniami z dostawcami, obsługują opóźnienia w rozliczeniach i dokumentują, co się dzieje, gdy brakuje danych o użytkowaniu lub cenach.
Typowe błędy wdrożeniowe
Najczęstszym błędem jest używanie do wszystkiego jednego wspólnego klucza API. To sprawia, że atrybucja jest słaba, rotacja ryzykowna, a powstrzymywanie jest prawie niemożliwe. Drugi zakłada, że limit organizacji lub projektu jest taki sam, jak budżet na klucz. Tak nie jest. Może chronić całe konto, ale nie izoluje poszczególnych aktorów.
Kolejną częstą porażką jest poleganie na alertach podczas nazywania ich dużymi literami. Alerty są przydatne, ale wydatki będą kontynuowane, chyba że istnieje rygorystyczne egzekwowanie zasad i jest ono włączone. Podobnie limity liczby żądań nie są budżetami w dolarach. Niewielka liczba żądań dotyczących wysokiego kontekstu, modelu premium, obrazu, dźwięku, wideo lub narzędzi hostowanych może przekroczyć oczekiwane wydatki nawet przy niskim wskaźniku żądań.
Zespoły zapominają także o współbieżności. Jeśli dziesięć żądań sprawdzi ten sam pozostały budżet, zanim którykolwiek zostanie rozliczony, wszystkie dziesięć może zostać przyjętych, chyba że system zarezerwuje budżet lub użyje liczników atomowych. Jest to szczególnie ważne w przypadku zadań przesyłania strumieniowego i asynchronicznego, których ostateczny koszt jest znany z opóźnieniem.
Inne błędy obejmują wykorzystywanie zmiennych w zamian za pieniądze, umożliwianie alternatywnych dróg obejścia reguł budżetowych, resetowanie użycia w sposób usuwający historię audytów, brak śledzenia dostawcy i modelu w księdze, tworzenie wielu małych kluczy bez właścicieli oraz zwracanie niejasnych błędów związanych z przekroczeniem budżetu, które klienci agresywnie ponawiają.
Lista kontrolna decyzji dla poszczególnych kluczy AI APIbudżety
Zacznij od zdecydowania, co reprezentuje każdy klucz. Jeśli odpowiedź brzmi „wszystko”, podziel to. Twórz osobne klucze dla produkcji, programowania, CI, lokalnych eksperymentów, publicznych wersji demonstracyjnych, agentów, botów i głównych klientów. Przypisz właścicieli i daty recenzji.
Następnie zdefiniuj hierarchię budżetu: limit konta, limit środowiska, limit grupy, limit kluczy i limity na żądanie. Zdecyduj, które limity są alertami miękkimi, a które twardymi. W przypadku obciążeń autonomicznych lub publicznych preferuj mniejsze, twarde limity i bardziej rygorystyczne limity szybkości.
Następnie zdefiniuj księgę żądań. Przechwytuj metadane klucza, grupy, użytkownika lub klienta, alias modelu, ustalonego dostawcę i model, jednostki użycia, szacowany koszt, rozliczony koszt, status i czas. Korzystaj z rachunkowości dziesiętnej. Uzgodnij faktury dostawcy, ale nie polegaj na nich jako na jedynym źródle prawdy dotyczącej poszczególnych kluczy.
Następnie wykonaj kontrole przed lotem i rozliczenie. W przypadku kosztownych lub równoległych prac zarezerwuj szacunkowe wydatki przed wysyłką. Rozlicz rzeczywisty koszt po zakończeniu. Testuj żądania o dokładnym progu, równoczesne żądania w pobliżu progu, przesyłanie strumieniowe, anulowanie, nieudane wywołania dostawcy, ponowne próby, asynchroniczne zakończenie po wyczerpaniu budżetu i aktualizacje katalogu cen.
Na koniec wyjaśnij operacje. Dokumentuj, kto może podnosić limity, kto może zamrażać klucze, kiedy klucze są zmieniane, jak działa resetowanie użycia i jakie dowody są potrzebne przed zwiększeniem budżetu. System kontroli wydatków jest tak silny, jak nawyki operacyjne wokół niego.
Wniosek
Limity wydatkówLLM API według klucza stanowią praktyczną kontrolę dla każdego, kto przeprowadza więcej niż jeden eksperyment. Zamieniają wspólny budżet konta w możliwe do wyegzekwowania granice dla skryptów, agentów, klientów, zespołów i środowisk. Celem nie są tylko niższe wydatki; jest to przewidywalna awaria, jasne przypisanie, szybsza reakcja na incydent i mniej niespodzianek w przypadku wzrostu wykorzystania.
Trwały wzorzec jest prosty: podziel klucze według rzeczywistych granic własności, konta warstwy, grupy i kluczowych budżetów, połącz limity wydatków z limitami stawek i współbieżności, celowo ograniczaj drogie modele, śledź wykorzystanie w księdze, korzystaj z obsługi pieniędzy z dokładnością dziesiętną i uzgadniaj z rozliczeniami dostawcy. Brama obsługująca wiele modeli, taka jak Model Gate, może scentralizować tę kontrolę między dostawcami, podczas gdy limity natywne dla dostawcy pozostają ważnym zabezpieczeniem na poziomie konta, projektu lub obszaru roboczego.