Jak to działa

Ta strona wyjaśnia pojęcia, na których opiera się Model Router — przeczytaj ją raz, a wszystkie pozostałe strony staną się bardziej zrozumiałe.

Przedpłacone saldo

Twój obiekt ma przedpłacone saldo w USD. Zmienia się ono tylko w dwóch kierunkach:

• Rośnie, gdy je doładowujesz (ręcznie, przez automatyczne doładowanie lub w wyniku korekty zaksięgowanej na Twoim koncie). Doładowania pojawiają się natychmiast.
• Maleje w miarę narastania wykorzystania. Wykorzystanie jest raportowane na bieżąco przez usługę wnioskowania i uzgadniane z przedpłaconym saldem co 15 minut, więc pojawienie się bardzo niedawnej aktywności w sekcji Monthly usage może potrwać kilka minut. Historia transakcji zawiera wyłącznie doładowania i korekty salda.

Saldo jest barierą finansową: gdy osiągnie zero, żądania wnioskowania są blokowane z błędem insufficient credits, dopóki nie doładujesz salda. Pobieranie listy modeli działa nawet przy zerowym saldzie, dzięki czemu integracje mogą poznać katalog, zanim zasilisz konto.

Katalog modeli

Katalog zawiera modele wielu dostawców, każdy wyceniany za milion tokenów (tokeny wejściowe i wyjściowe wyceniane osobno, co widać w ustawieniach Models). Wszystkie modele są domyślnie włączone dla Twojego obiektu; możesz:

• Wyłączać modele dla całego konta w Settings → Models (co najmniej jeden model musi pozostać włączony).
• Ograniczać modele dla poszczególnych kluczy API lub połączonych usług — węższa lista w ramach zestawu włączonego dla obiektu.

Specjalna pozycja katalogu, auto (Auto Router), nie ma własnej ceny. Dla każdego żądania automatycznie wybiera najlepszy model na podstawie złożoności promptu, a opłata naliczana jest według stawki wybranego modelu. Zobacz Models.

Dwa sposoby korzystania z modeli

1. Połączone usługi

Urządzenia z agentem AI sparowane z Twoim obiektem łączą się z Model Router automatycznie — na urządzeniu nigdy nie wprowadza się klucza API — a Workflows również mogą się połączyć. Każda połączona usługa pojawia się w Settings → Service Access & API Keys w sekcji Connected Services z własnymi danymi o wydatkach, a każdej z nich możesz przypisać własne limity wydatków, ograniczenia modeli i zastąpienia zabezpieczeń. Zobacz Connected Services.

2. Własne klucze API

Możesz generować klucze API (zaczynają się od phk_), aby oprogramowanie i systemy firm zewnętrznych obsługujące BYOK (Bring Your Own Key) mogły łączyć się z modelami publikowanymi przez Performance Hub. Punkt końcowy jest zgodny z OpenAI — skieruj dowolny SDK lub narzędzie OpenAI na bazowy adres URL i uwierzytelnij się swoim kluczem. Zobacz Klucze API i Łączenie aplikacji.

Obie ścieżki korzystają z tego samego salda, podlegają tym samym limitom wydatków dla całego konta, pojawiają się w tej samej analityce Activity i na tej samej karcie Logs i można je indywidualnie ograniczać.

Saldo a limity wydatków

To dwa różne mechanizmy i oba obowiązują:

Limity wydatków konta obejmują trzy okresy — dzienny (resetuje się codziennie o północy czasu lokalnego obiektu), miesięczny (resetuje się 1. dnia każdego miesiąca, czasu lokalnego obiektu) oraz całkowity limit twardy (liczy wydatki od ostatniego ręcznego resetu; nigdy nie resetuje się samoczynnie). Jednocześnie może być aktywna dowolna ich kombinacja, a limity obejmują łącznie wszystkie klucze API i połączone usługi. Przedpłacone saldo nadal obowiązuje dodatkowo.

Limity dla poszczególnych kluczy i usług działają tak samo (dzienny, miesięczny, całkowity), ale uwzględniają tylko wydatki danego klucza lub usługi. Po osiągnięciu limitu blokowany jest tylko ten klucz lub ta usługa — reszta obiektu działa dalej.

Jak przetwarzane jest żądanie

Gdy żądanie dociera do punktu końcowego, kontrole są wykonywane w następującej kolejności:

1. Uwierzytelnianie — prawidłowy klucz API lub tożsamość połączonej usługi. W przypadku klucza API obiekt, w którym Model Router nie jest włączony, zostaje odrzucony na tym etapie z HTTP 403 ("Model Router is not enabled for this facility"). Pobieranie listy modeli (GET /v1/models) jest obsługiwane zaraz po uwierzytelnieniu, więc działa nawet przy zerowym saldzie.
2. Sprawdzenie przedpłaconych środków — dostępne saldo musi być wyższe niż $0 (w przypadku połączonych usług Model Router musi być także włączony); w przeciwnym razie żądanie jest odrzucane z błędem insufficient credits (HTTP 402).
3. Limity wydatków konta — jeśli przekroczony zostanie limit dzienny, miesięczny lub całkowity, żądanie jest odrzucane z błędem budget exceeded (HTTP 402), który podaje, kiedy okres się zresetuje, w strefie czasowej Twojego obiektu.
4. Limity wydatków dla kluczy / usług — ta sama kontrola, ograniczona do wywołującego klucza lub usługi.
5. Kontrole promptu — ochrona przed wstrzykiwaniem promptów i Twoje niestandardowe filtry treści są stosowane do promptu. Filtr typu block lub wykrycie wstrzyknięcia odrzuca żądanie (HTTP 403, content policy violation); filtry typu redact zamieniają dopasowania na [REDACTED] i pozwalają kontynuować żądanie.
6. Routing modelu — auto jest zamieniany przez Auto Router na konkretny model (żądanie zawierające obraz jest wysyłane do dozwolonego przez Ciebie modelu obsługującego obraz). Modele zapasowe są filtrowane do tych, z których klucz może korzystać, Twoje ustawienie rozumowania jest stosowane, gdy żądanie nie ustawia własnego, a żądane limity danych wyjściowych są przycinane do możliwości modelu.
7. Wnioskowanie — maskowanie danych osobowych i usuwanie sekretów (jeśli są włączone) są stosowane przez usługę wnioskowania, zanim prompt dotrze do modelu; następnie żądanie trafia do dostawcy modelu, a odpowiedź jest przesyłana strumieniowo z powrotem.

Limity liczby żądań (żądań/min i tokenów/min, jeśli ustawiono je dla klucza lub usługi) są egzekwowane przez cały czas; ich przekroczenie zwraca HTTP 429.

Co jest rejestrowane

Każde żądanie jest rejestrowane wraz z metadanymi: czasem, modelem (zarówno żądanym, jak i wybranym przez router), dostawcą, tokenami (promptu, uzupełnienia, buforowanymi, rozumowania), kosztem, opóźnieniem, czasem do pierwszego tokenu, szybkością, stanem oraz wywołującym kluczem lub usługą. Treść promptów i odpowiedzi nigdy nie jest przechowywana.

Dane o wykorzystaniu i wydatkach wyświetlane w module są tymi samymi danymi, które służą do egzekwowania limitów, więc to, co widzisz jako „limit reached”, jest dokładnie tym, co zostaje zablokowane.

Słowniczek