Jeden AI Gateway stoi przed pulą serwerów AI pracujących. Aplikacje łączą się z gatewayem za pomocą jednego URL i jednego klucza, dokładnie tak, jakby to był pojedynczy AI Server; za nim gateway równoważy każde żądanie pomiędzy serwery, kontroluje ich stan i przekierowuje ruch z umierającego serwera do zdrowego, zanim wywołujący to zauważy [1]. Nie jest to osobny produkt. AI Gateway to AI Server działający w trybie front-end farmy, więc zgodne z OpenAI /v1/* oraz zgodne z Ollama /api/* punkty końcowe pojedynczego serwera są dokładnie tym, co udostępnia farma [1].

Jeden URL i jeden klucz, farma za nimi

Gateway równoważy każdy typ żądania obsługiwany przez platformę: czat, osadzenia, generowanie obrazów, wizję i audio, w tym WebSocket do mowy na żywo [1]. Żądania są kierowane według wybranej strategii — round-robin, najmniejsze opóźnienie, najmniejsza liczba połączeń, ważone lub przyklejone do klienta. Trasowanie świadome modeli wysyła żądanie do serwera, który ma już rozgrzany żądany model, co unika kary za zimne ładowanie, gdyby wywołanie mogło trafić do zimniejszej maszyny [1].

Dodaj kartę GPU, a pojemność rośnie; klienci nic nie zmieniają. Wyłącz serwer na konserwację, a jego ruch jest stopniowo odprowadzany, więc żadne żądanie w trakcie nie zostanie utracone. W naszym własnym zestawie testów zabijamy serwery w trakcie ruchu, aby zachować tę gwarancję: serwer, który padnie, jest ponownie wywoływany na zdrowym, a failover odbywa się wewnątrz gatewaya, zanim klient zobaczy błąd [1][3].

Granica zaufania wprowadzona przez farmę

Farma zmienia, kto posiada które poświadczenia, a konstrukcja utrzymuje tę granicę ścisłą. Klucz gatewaya klienta nigdy nie trafia do serwera. Gateway przedstawia każdemu serwerowi jego własny klucz, więc wyciekły klucz gatewaya nie może być bezpośrednio użyty przeciwko serwerowi, a poświadczenia per serwer pozostają wewnątrz farmy [2]. Tożsamość wywołującego, czyli która aplikacja i która instalacja wysłała żądanie, jest przekazywana do serwera. Każdy serwer prowadzi więc beztreściowy dziennik audytu, który rejestruje prawdziwego inicjatora, a nie przypisuje wszystkiego gatewayowi [2].

Backpressure zamiast timeoutów

Gdy każdy serwer jest przeciążony, gateway zwraca wyraźny sygnał „spróbuj ponownie wkrótce” zamiast utrzymywać połączenie otwarte aż do timeoutu [1]. Wywołujący otrzymują sygnał, na który mogą zareagować. Dwa mechanizmy wdrożeniowe działają na tej samej warstwie trasowania. Canary release kieruje stały fragment ruchu do nowych maszyn, zanim przejmą pełne obciążenie. Aktualizacja bez przestojów opróżnia serwer, aktualizuje go i zwraca do puli, a punkt końcowy pozostaje dostępny przez cały czas [1].

Kubernetes bez ręcznych edycji puli

Na Kubernetesie pracownicy są wykrywani automatycznie w miarę skalowania, więc farma z autoskalowaniem nie wymaga ręcznych edycji listy pracowników bramy [2]. Przepis dostarcza trzy warianty z jednego produktu: Docker Compose dla demonstracji na pojedynczym urządzeniu, manifesty Kubernetes oraz wykres Helm dla klastra. Produkt, API i licencja są identyczne od laptopa po farmę GPU [2].

Koszty eksploatacji farmy

Każdy serwer, w tym brama, posiada własny panel na żywo i udostępnia natywne metryki Prometheus dotyczące stanu floty, opóźnień, wykorzystania i pojemności [3]. Widoczność floty to jeden panel, a nie stos monitoringu złożony przed pierwszym żądaniem. Obsługa sieci pozostaje kontrolowana na każdym węźle: nieudane powiązanie z adresem innym niż loopback powoduje natychmiastowe zamknięcie, chyba że węzeł posiada uprawnienia Pro i co najmniej jeden klucz API, co zapobiega cichemu udostępnianiu się nieautoryzowanego lub nieposiadającego klucza urządzenia w sieci LAN [1][4].

Farma bram to topologia stojąca za pozycją dostępności platformy: punkt końcowy AI pozostaje aktywny, gdy urządzenie przestaje działać, i odbywa się to bez udziału chmury dostawcy w ścieżce żądania. Jest licencjonowana jako część Pro Commercial, a nie sprzedawana jako osobny produkt [4].