Ollama Cloud rozwiązuje realny problem: największe modele wymagają sprzętu, którego mała czy średnia firma nie chce kupować. Ale „wygodny dostęp do mocy” zamienia się w chaos, jeśli każdy serwis woła chmurę po swojemu. Dojrzałe użycie ma jedną bramę.
Dlaczego jeden router, a nie bezpośrednie wywołania#
Bezpośrednie wywołania z wielu miejsc oznaczają rozproszone klucze, brak wspólnej kontroli kosztu i ryzyko, że dane osobowe wyjdą na zewnątrz bez maskowania. Router (OpenClaw) to jedyne wejście do modeli: tu zapada decyzja, który model obsłuży zadanie, tu maskujemy PII, tu liczymy koszt i włącza się fallback, gdy model zwróci pustą odpowiedź. Taki router LLM jest dla całej organizacji jedną warstwą kontroli — niezależnie od tego, ile serwisów z niego korzysta.
Dobór modelu do zadania#
Nie każde zadanie potrzebuje największego modelu. Router kieruje klasyfikację i proste przepływy na mały, tani model, a moc rezerwuje dla zadań, które jej naprawdę wymagają (złożone wnioskowanie, długie konteksty). To jednocześnie najważniejsza dźwignia kosztowa i jakościowa.
W praktyce większość ruchu da się obsłużyć mniejszą klasą modelu, a najdroższą moc zostawić dla wąskiego wycinka zadań. Poniżej orientacyjne dopasowanie — koszt podajemy względnie (rzędy wielkości, nie konkretne stawki), bo cenniki się zmieniają i zależą od długości promptu:
| Typ zadania | Klasa modelu | Względny koszt | Kiedy wybrać |
|---|---|---|---|
| Klasyfikacja, routing, tagowanie, prosty wybór | mały | najniższy | Krótkie wejście, jednoznaczna odpowiedź, duży wolumen |
| Ekstrakcja danych, streszczenie, przepisanie | średni | umiarkowany | Potrzebna struktura i wierność, ale bez wielokrokowego rozumowania |
| Złożone wnioskowanie, długi kontekst, analiza dokumentów | duży | najwyższy | Zadanie wymaga jakości, którą widać dopiero przy większym modelu |
Zasada jest prosta: zaczynaj od najmniejszej klasy, która zdaje test jakości na Twoich danych, i podnoś ją tylko tam, gdzie realnie brakuje trafności. Jak dobierać model do konkretnego zadania, rozkładamy szczegółowo w artykule jak dobrać model AI.
Chmura i RODO w jednym przepływie#
Ollama Cloud to przetwarzanie poza Twoją infrastrukturą — więc traktujemy je jak każde wyjście danych: maskowanie PII przed wysłaniem jest obowiązkowe, a wrażliwe ścieżki kierujemy na model lokalny. Dla danych, które nie mogą wyjść, łączymy chmurę z self-hostingiem w jednym, spójnym routerze. Bezpieczeństwo i RODO są ważniejsze niż pojedynczy feature — jak to ułożyć krok po kroku, rozwijamy w artykule o self-hostingu a RODO.
W praktyce maskowanie przed wywołaniem chmury ma kilka etapów, które router wykonuje za każdym razem:
- Wykryj encje — w prompcie znajdź dane osobowe i wrażliwe: imiona, e-maile, numery telefonu, PESEL, adresy, identyfikatory klientów.
- Zamaskuj lub pseudonimizuj — podmień je na stabilne tokeny zastępcze (np.
KLIENT_1,EMAIL_1), zachowując mapowanie tylko lokalnie. - Wyślij zamaskowany prompt do chmury — model widzi strukturę zadania, ale nie realne dane.
- Przywróć wartości w odpowiedzi po stronie Twojej infrastruktury, na podstawie lokalnej mapy.
Niektórych danych nie maskujemy, tylko w ogóle nie wypuszczamy: ścieżki dotykające dokumentów objętych tajemnicą, danych szczególnej kategorii (np. zdrowotnych) albo treści, których ryzyko ujawnienia jest zbyt duże, router kieruje w całości na model lokalny. To świadoma decyzja w jednym miejscu, a nie nadzieja, że każdy deweloper o tym pamięta.
Telemetria: zobacz, za co płacisz#
Jedna brama daje jedną prawdę o zużyciu: które zadania generują koszt, jak rozkłada się ruch między modele, gdzie warto przesunąć obciążenie na model lokalny. Bez tej obserwowalności optymalizacja kosztu to zgadywanie.
Żeby „zobacz, za co płacisz” było konkretem, router zapisuje przy każdym wywołaniu zestaw pól:
- model i klasa (tier) — który model obsłużył zadanie i z jakiej półki (mały/średni/duży).
- tokeny wejścia i wyjścia — bo to one przekładają się na koszt.
- latencja — czas odpowiedzi, pomocny przy wyborze między modelami o podobnej jakości.
- szacowany koszt — wyliczony z liczby tokenów i stawki danej klasy.
- czy zamaskowano PII — ślad, że ścieżka przeszła przez wymagane maskowanie.
- czy zadziałał fallback lub blokada — sygnał, że model zwrócił pustą odpowiedź albo zadanie zostało zatrzymane.
Z takich pól składa się obraz, który pozwala podejmować decyzje na podstawie liczb, a nie wrażeń: gdzie obniżyć klasę modelu, które zadania przenieść lokalnie, a gdzie koszt rośnie szybciej niż wartość. Pełny rozkład kosztów całego agenta — nie tylko samych wywołań modelu — rozkładamy w artykule ile kosztuje agent AI.
FAQ#
Czym Ollama Cloud różni się od trzymania modelu u siebie?#
Ollama Cloud to moc na żądanie bez własnego sprzętu — niski próg wejścia, koszt zmienny. Self-hosting to wyższy próg wejścia, ale pełna kontrola i przewidywalny koszt przy dużym wolumenie. Często optymalna jest hybryda obu.
Czy mogę używać Ollama Cloud zgodnie z RODO?#
Tak, pod warunkiem że maskujesz dane osobowe przed wysłaniem, ograniczasz zakres do minimum i kierujesz wrażliwe ścieżki na model lokalny. Router egzekwuje te zasady w jednym miejscu, zamiast polegać na dyscyplinie każdego dewelopera.
Po co router, skoro mogę wołać API bezpośrednio?#
Bezpośrednie wywołania rozpraszają kontrolę: koszt, bezpieczeństwo i dobór modelu rozjeżdżają się między serwisami. Router centralizuje decyzję, maskowanie PII, fallback i telemetrię - to różnica między eksperymentem a systemem produkcyjnym.