Klient aplikacji wywołuje gateway zamiast bezpośrednio dostawcy modelu, zazwyczaj przez interfejs zgodny z OpenAI. Gateway uwierzytelnia żądanie kluczem wirtualnym przypisanym do zespołu lub aplikacji i sprawdza budżet oraz limity. Następnie wybiera docelowy model i dostawcę zgodnie z konfiguracją routingu (preferowany model, A/B test, koszt, dostępność). Sprawdza cache (deterministyczne klucze lub semantyczne porównanie embeddingów) i przy trafieniu zwraca zapisany wynik. Przy braku trafienia wykonuje wywołanie do dostawcy z mechanizmem retry i timeoutem; w razie błędu lub przekroczenia limitu przełącza się na fallback. Opcjonalnie uruchamia guardrails na wejściu (filtry promptu, redakcja PII) i wyjściu (filtry treści, walidacja schematu). Loguje żądanie i odpowiedź wraz z liczbą tokenów, kosztem, latencją i identyfikatorem śladu, eksportując metryki i ślady do systemów obserwowalności.
Aplikacje korzystające z modeli AI muszą integrować się z wieloma dostawcami o różnych SDK, formatach żądań, mechanizmach uwierzytelniania, polityce limitów i modelach kosztowych. Bez warstwy gateway logika ta — wraz z retry, fallbackiem, cache, rate limitem, redakcją PII i obserwowalnością — duplikowana jest w każdej aplikacji, a kontrola kosztów i bezpieczeństwa jest rozproszona.
Wybiera docelowy model i dostawcę dla żądania na podstawie reguł (preferencja, koszt, dostępność, A/B, load balancing).
Tłumaczy ujednolicone żądanie (zazwyczaj OpenAI-compatible) na natywny format docelowego dostawcy i odwrotnie dla odpowiedzi.
Oficjalna
Uwierzytelnia klienta kluczem wirtualnym i mapuje go na rzeczywiste klucze dostawców, wraz z budżetem i uprawnieniami.
Przechowuje odpowiedzi LLM kluczowane deterministycznie (hash promptu i parametrów) lub semantycznie (porównanie embeddingów).
Oficjalna
Egzekwuje limity per klucz/zespół i przy błędzie lub przekroczeniu kwoty przełącza żądanie na alternatywny model lub dostawcę.
Filtry wejścia i wyjścia: redakcja PII, blokady promptów, walidacja schematu odpowiedzi, filtrowanie treści.
Oficjalna
Zbiera logi, metryki (tokeny, koszt, latencja, błędy) i ślady rozproszone dla każdego żądania.
Automatyczne przełączenie na słabszy model przy błędzie głównego dostawcy może bez ostrzeżenia obniżyć jakość odpowiedzi.
Zbyt niski próg podobieństwa cache semantycznego skutkuje trafieniami dla różnych intencji i wprowadzającymi w błąd odpowiedziami.
Awaria gatewaya przerywa cały ruch AI w organizacji, nawet jeśli dostawcy upstream działają.
Pełne logowanie żądań i odpowiedzi LLM bez redakcji może zapisywać PII, sekrety i własność intelektualną klientów.
Każdy hop dodaje opóźnienie; gateway w innym regionie niż dostawca może wyraźnie pogorszyć czas pierwszego tokena.
Klasyczny API Gateway popularyzowany w architekturze mikroserwisowej jako pojedynczy punkt wejścia z auth, rate limit i routingiem.
Cloudflare uruchamia AI Gateway (wrzesień 2023) jako proxy dla wywołań LLM z analityką, cache i rate limitem; pattern dedykowany AI staje się produktem.
LiteLLM (BerriAI) i Portkey popularyzują OpenAI-compatible proxy do wielu dostawców z fallbackiem, virtual keys i cache.
Kong dodaje natywne pluginy AI (ai-proxy, ai-prompt-guard, ai-rate-limiting), przenosząc logikę LLM do dojrzałych gatewayów L7.
Sposób wyboru modelu/dostawcy: pinned, weighted, cost-based, latency-based, fallback chain.
Brak cache, cache deterministyczny (hash) lub cache semantyczny (embeddingi z progiem podobieństwa).
Limity per klucz wirtualny, zespół, model — w żądaniach/minutę i tokenach/minutę oraz budżety dzienne/miesięczne.
Łańcuch alternatywnych modeli/dostawców uruchamiany przy błędach, timeoutach lub przekroczeniu limitów.
Włączone filtry wejścia/wyjścia: redakcja PII, blokery promptów, filtry treści, walidacja schematu.
Routing per żądanie według polityki (model preferowany, koszt, latencja, dostępność, A/B, fallback).
Bezstanowy proxy — instancje skalują się horyzontalnie; ograniczeniem są limity dostawców upstream i współdzielony cache.
Gateway to lekka warstwa proxy I/O-bound; uruchamia się na zwykłych CPU bez akceleratorów.
