Infrastruktura

API key rate limiting

AktywnyOpublikowano: 28 lipca 2026Aktualizacja: 28 lipca 2026Opublikowany

Ograniczanie liczby/tempa zadan (i zuzycia tokenow) przypisane do klucza API — np. limity RPM/TPM i kwoty — w celu ochrony backendu, sprawiedliwego dostepu i kontroli kosztow. Powszechne w bramach API LLM.

Kluczowa innowacja

Wiaze limity szybkosci i kwoty z indywidualnym kluczem API, umozliwiajac sprawiedliwy podzial zasobow, ochrone backendu i kontrole kosztow per klient bez zmian w samym modelu/uslugach.

Kategoria

Infrastruktura

Poziom abstrakcji

Wzorzec

Poziom operacji

UdostępnianieAplikacjaSystem

Zastosowania

Ochrona API LLM przed naduzyciami i przeciazeniemSprawiedliwy podzial zasobow miedzy klientow/planyKontrola kosztow (budzety, kwoty per klucz)Egzekwowanie planow taryfowych (tiering)Zapobieganie odsprzedazy/naduzyciom tokenowStabilnosc bram API i backendow modeli

Jak działa

1) Kazde zadanie jest identyfikowane po kluczu API (i ewentualnie uzytkowniku/planie). 2) Brama sprawdza liczniki uzycia dla tego klucza wzgledem skonfigurowanych limitow (np. RPM, TPM, kwota) uzywajac algorytmu (token bucket / sliding window). 3) Jesli limit nie jest przekroczony — zadanie przechodzi, a liczniki sa aktualizowane (we wspoldzielonym magazynie, np. Redis). 4) Jesli limit jest przekroczony — zadanie jest odrzucane (HTTP 429, czesto z naglowkiem Retry-After) albo opoznione/kolejkowane.

Rozwiązany problem

Bez limitow pojedynczy klient moze przeciazyc backend, wyczerpac kwoty dostawcow lub wygenerowac niekontrolowane koszty. Rate limiting per klucz API chroni system, zapewnia sprawiedliwy dostep i utrzymuje koszty pod kontrola.

Komponenty

Licznik uzyciaStan / pomiar

Przechowuje biezace zuzycie per klucz (zadania/tokeny w oknie), zwykle we wspoldzielonym magazynie (np. Redis) dla spojnosci miedzy instancjami.

Oficjalna

Algorytm limitowaniaDecyzja

Decyduje, czy zadanie miesci sie w limicie: token bucket, leaky bucket lub okno przesuwne (sliding window).

Token bucketDopuszcza serie (burst) do pojemnosci kubelka.

Sliding windowDokladniejsze zliczanie w ruchomym oknie czasu.

Oficjalna

Polityka i punkt egzekwowaniaEgzekwowanie

Definicja limitow per klucz/plan (RPM/TPM/kwota) oraz miejsce, w ktorym zadanie jest przepuszczane, odrzucane (429) lub opozniane.

Oficjalna

Implementacja

Implementacje referencyjne

one-api (zarzadzanie tokenami/limitami)

songquanpeng

Kong / NGINX rate limiting

Kong Inc.

Pułapki implementacyjne

Dokladnosc vs wydajnosc (rozproszenie)Średnia

Scisle globalne limity wymagaja spojnego licznika, co dodaje latencje; lokalne liczniki sa szybsze, ale mniej dokladne.

Rozwiązanie:Wspoldzielony magazyn (Redis) z operacjami atomowymi, przybliżenia (approximate), sharding kluczy.

Efekt stada (thundering herd) po resecie oknaŚrednia

Przy oknie stalym (fixed window) wszyscy klienci moga uderzyc jednoczesnie po resecie, powodujac skok obciazenia.

Rozwiązanie:Okno przesuwne (sliding window), jitter, token bucket.

Niejasne komunikaty limituNiska

Brak jasnych naglowkow (limit/pozostalo/Retry-After) utrudnia klientom poprawna obsluge 429.

Rozwiązanie:Standardowe naglowki rate limit i Retry-After, dokumentacja.

Hiperparametry (konfigurowalne osie)

Wymiary limituKrytyczna

Co jest limitowane: zadania (RPM/RPD), tokeny (TPM), rownoczesnosc, budzet.

1000 RPM / 100k TPMZadania i tokeny na minute.

$50/dzienBudzet kosztowy.

AlgorytmWysoka

Token bucket, leaky bucket, fixed/sliding window.

token bucketObsluga serii (burst).

ZakresWysoka

Per klucz API, per uzytkownik, per plan/grupa, globalnie.

Złożoność obliczeniowa

Złożoność czasowa: O(1) na zadanie. Złożoność przestrzenna: O(liczba aktywnych kluczy).

Wąskie gardło obliczeniowe

Spojnosc licznikow w trybie rozproszonym

Utrzymanie dokladnych, spojnych licznikow miedzy wieloma instancjami bramy przy niskiej latencji jest glownym wyzwaniem (kompromis dokladnosc vs wydajnosc).

Zależy od

Wspoldzielony magazyn (np. Redis)