Kategoria: Lokalne AI
„Czy brama API przed lokalnym modelem jest w ogóle potrzebna, jeśli silnik ma już własne API?” Wątpliwość jest zasadna: pierwszy uruchomiony model odpowiada pod własnym adresem i nic nie podpowiada, że trzeba przed nim stawiać cokolwiek jeszcze.
Odpowiadam na nie odczytem jednej konfiguracji, a nie zaleceniem. Wartości poniżej odczytałem 2 listopada 2026 z pliku konfiguracyjnego klienta, który u mnie korzysta z bramy, oraz z odpowiedzi samego silnika. Rolę bramy pełni u mnie LiteLLM i opisałem ją wcześniej jako trzecią warstwę całej konfiguracji, rozkładając na części uruchomienie lokalnego modelu na llama.cpp i LiteLLM. Tamtych trzech warstw tu nie powtarzam, wchodzę w jedną z nich.
Gdzie stoi brama, a gdzie silnik
Trzy warstwy, dwie maszyny
Opisując te trzy warstwy, pokazałem je na jednej maszynie, bo tak najłatwiej zacząć. U mnie od pewnego momentu stoją na dwóch. Modele liczy osobny komputer, na którym jest Ubuntu Server i nic poza tym, a brama razem z interfejsami czatu pracuje na drugiej maszynie, żeby nie zajmowały pamięci pierwszej. Podałem to już, licząc, ile prądu zużywa domowy serwer AI, bo pobór tej drugiej maszyny dolicza się osobno.
Ten podział ma jeden skutek, który widać dopiero w pliku klienta: klient nie zna adresu maszyny z modelami. Zna adres bramy. W odczytanym pliku jest to adres lokalny, port 4000, podstawiany pod pole „adres serwera OpenAI”. Zmiana maszyny, na której liczy się model, nie jest więc zmianą w kliencie.
Kto wpisuje adres bramy
Dwa programy do rozmowy z modelem i jeden węzeł w automatyzacjach
Adres bramy wpisują u mnie Open WebUI i AnythingLLM. Oba dostają ten sam adres i ten sam sposób uwierzytelnienia, a o maszynie z modelami nie wiedzą nic.
Trzecim klientem są moje automatyzacje, w mniejszym stopniu, niż sam się spodziewałem. Sprawdziłem konfigurację 3 listopada 2026: spośród węzłów wywołujących model dokładnie jeden ma podpięty adres bramy i jest to model zapasowy, a pozostałe kierują wprost do chmury. Nie podważa to liczby, którą podałem, pytając o modele AI w n8n, chmura czy lokalnie, tylko ją uściśla: jedno z tych wywołań kończy na modelu lokalnym, bo w konfiguracji adres bramy wygląda tak samo jak adres dostawcy.
Dwadzieścia cztery nazwy w jednym pliku
Osiemnaście modeli z własnej tabeli, cztery nazwy z chmury
Plik klienta wymienia dwadzieścia cztery nazwy modeli (odczyt, 2 listopada 2026). Rozkładają się tak:
| Grupa nazw | Ile | Przykłady z odczytu |
|---|---|---|
| wiersze z mojej serii pomiarów z września 2026 | 18 | qwen3-coder-30b, tiel-coder-35b-a3b, gpt-oss-20b, qwen3.8-9b-distill |
| modele dostawców w chmurze | 4 | gpt-4o-mini, gpt-4.1-mini, gemini-flash, openrouter-auto |
| nazwy, których w tej tabeli pomiarów nie ma | 2 | agents-a1, qwopus-27b-coder |
Liczbę osiemnaście sprawdziłem nazwa po nazwie wobec tej tabeli. Dwie pozycje odpowiadają jej wariantem zapisu, a nie dokładnym napisem (qwen3.8-9b-distill i qwen3.6-27b-fable-fusion), i liczę je jako dopasowane.
Pełną tabelę prędkości dla tych lokalnych wierszy, model po modelu, podałem przy pytaniu, jaki model AI uruchomisz lokalnie na mini PC.
Druga i trzecia grupa są tu ważniejsze niż pierwsza. Model lokalny i model z chmury leżą w tym pliku obok siebie, w jednej liście, pod jednym adresem i z tym samym sposobem uwierzytelnienia. Dla aplikacji, która z tego korzysta, różnica między nimi jest różnicą jednego napisu w ustawieniach. To jest cała treść słowa „brama”: nie przyspiesza ona niczego i nie liczy niczego, tylko sprowadza kilkanaście osobnych adresów do jednego.
Dlaczego „LiteLLM czy OpenRouter” jest źle postawionym pytaniem
OpenRouter jest u mnie jedną z tych nazw, nie alternatywą
To pytanie wraca w wyszukiwaniu regularnie i w moim układzie nie ma sensu, bo obie rzeczy pracują u mnie jednocześnie. W odczytanym pliku openrouter-auto jest jedną z dwudziestu czterech nazw, czyli jednym z wejść po drugiej stronie bramy, a nie zamiennikiem dla niej.
Ta sama uwaga dotyczy porównań bramy z silnikami. Silnik wczytuje plik modelu i liczy tokeny. Brama nie robi ani jednego, ani drugiego: nie ma w pamięci żadnych wag i nie wie, jak policzyć token. U mnie silnikiem jest llama.cpp, a brama stoi przed nim. Wybór „jedno albo drugie” dotyczyłby więc dwóch różnych warstw, które na tej samej maszynie i tak się nie zastępują.
Co stoi między klientem a modelem
Klucz główny w zmiennej środowiskowej, nie w pliku klienta
Brama nie jest otwarta. Odczytany plik klienta nie zawiera klucza, zawiera nazwę zmiennej środowiskowej, pod którą klucz jest podstawiany w chwili uruchomienia. Różnica jest praktyczna: plik konfiguracyjny można skopiować, pokazać komuś i trzymać w repozytorium, bo klucza w nim nie ma.
Druga zamknięta rzecz to sam silnik. Jego adres kontroli stanu odpowiada poprawnie, a zapytanie o listę modeli zwraca w tej chwili odmowę uwierzytelnienia (odczyt, 2 listopada 2026). Nawet spis nazw nie jest więc po drodze dostępny bez klucza. Dwie zamknięte warstwy zamiast jednej to nie przesada, bo adres bramy wpisuje się do każdego nowego klienta, a adres silnika do żadnego.
Dwadzieścia cztery nazwy, a w pamięci jeden model
Zmiana nazwy w kliencie kosztuje od 30 do 60 sekund
Tu jest rzecz, którą lista z drugiej sekcji przesłania, i to najważniejsze zdanie tego tekstu. Lista nazw na bramie nie jest listą modeli gotowych do odpowiedzi. Silnik pod bramą ma w danej chwili wczytany jeden model: zapytanie skierowane na inną nazwę zwalnia ten wczytany i ładuje kolejny, a zimny start zajmuje od 30 do 60 sekund. Jest to ograniczenie trybu routera, które rozpisałem już przy samym uruchamianiu modelu, i brama go nie zdejmuje.
Wniosek dotyczy sposobu pracy, nie konfiguracji. Dwadzieścia cztery nazwy w kliencie wyglądają jak dwadzieścia cztery modele pod ręką, a są jednym modelem pod ręką i dwudziestoma trzema do wczytania. Dlatego dobór nazwy w aplikacji przestaje być drobnym ustawieniem, a staje się decyzją na kilka godzin pracy.
Jeszcze jeden odczyt z tego samego pliku, bo bywa źródłem nieporozumień: każda z dwudziestu czterech pozycji ma ustawiony ten sam parametr czasu ważności, 3600 sekund. To ustawienie klienta, nie bramy, i nie mówi nic o tym, który model jest wczytany.
Pięć rzeczy poza tym plikiem
Pięć rzeczy, których ten tekst nie rozstrzyga, zebranych w jednym miejscu.
- Nie podaję konfiguracji samej bramy. Rozdzielania ruchu, tras zapasowych, ponowień, pamięci podręcznej odpowiedzi ani budżetów. W odczytanym pliku klienta żadnego z tych ustawień nie ma, a pliku bramy w tym tekście nie cytuję. Nic tutaj nie świadczy więc o tym, że mój układ ponawia zapytania albo przełącza trasy.
- Nie podaję ceny ani warunków licencyjnych. Nie mam na nie źródła z datą, które czytelnik mógłby sprawdzić.
- Brama nie zmienia tokenów na sekundę. Wszystkie prędkości, jakie podaję, są prędkościami silnika na jego własnej maszynie. Warstwa przed nim ani ich nie poprawia, ani nie psuje.
- Nie wszystko da się za nią schować. Osobne narzędzie do modeli dyfuzyjnych nie wystawia tego samego API co zwykły serwer modeli, więc do bramy nie trafia. Opisałem to przy modelach działających inaczej niż LLM.
- To nie jest instrukcja instalacji ani miara oszczędności czasu. Opisuję stan z jednego dnia, a nie przepis na własną instalację.
- Nie wymieniam wszystkich programów, które z bramy korzystają. Podaję te, które sprawdziłem w konfiguracji.
