Przez ostatnie lata rozwój generatywnej AI wydawał się prowadzić w jednym kierunku. Coraz większe modele trafiały do coraz większych centrów danych, a użytkownik korzystał z nich przez stronę internetową lub API. Lokalnie można było co najwyżej eksperymentować z czymś mniejszym, ciekawym, ale zwykle wyraźnie słabszym.

W ostatnim tygodniu ten podział zaczął wyglądać mniej oczywiście.

 

Microsoft pokazał model programistyczny działający bezpośrednio na komputerze, GitHub Copilot nauczył się wykrywać modele uruchomione w Ollamie, a jednocześnie pojawiły się nowe zabezpieczenia ograniczające dostęp agentów do plików, sieci i poświadczeń.

 

Nie oznacza to końca chmury. Raczej początek bardziej praktycznego podziału pracy.

 

Agent może pracować lokalnie i nadal korzystać z chmury

 

GitHub Copilot CLI pozwala teraz znaleźć modele dostępne w działającej lokalnie instancji Ollama. Użytkownik może wybrać je obok modeli oferowanych przez GitHuba, bez przebudowy całego środowiska pracy.

 

Microsoft idzie jeszcze dalej. Copilot może automatycznie zdecydować, czy zadanie powinno zostać wykonane na komputerze, czy w chmurze. Liczy się charakter problemu, dostępny kontekst i stan pamięci podręcznej.

 

To dość ważna zmiana. Wcześniej decyzję trzeba było podejmować na poziomie całego projektu: aplikacja była lokalna albo chmurowa. Teraz wybór może odbywać się dla każdego etapu procesu.

 

Prosta klasyfikacja, analiza poufnego fragmentu kodu albo szybka podpowiedź mogą zostać obsłużone lokalnie. Trudniejsze rozumowanie lub praca wymagająca dużego kontekstu może trafić do mocniejszego modelu w centrum danych.

 

Chyba właśnie tak będzie wyglądać najbliższa przyszłość AI - nie jako pojedynek „lokalnie kontra chmura”, lecz jako ciągłe dobieranie właściwego miejsca wykonania.

 

Lokalny model nie zawsze oznacza tryb offline

 

Tu pojawia się istotne zastrzeżenie.

 

Jeżeli model działa na komputerze, nie oznacza to jeszcze, że cały proces został odłączony od sieci. Narzędzie może przesyłać telemetrię. Agent może korzystać ze zdalnego serwera MCP. Część kontekstu może trafiać do innej usługi. Nawet przy włączonym trybie offline niewłaściwie skonfigurowany provider może komunikować się z zewnętrznym endpointem.

 

Dlatego samo pytanie „gdzie działa model?” przestaje wystarczać.

 

Trzeba wiedzieć również, gdzie trafia prompt, jakie narzędzia może uruchomić agent, które katalogi są dla niego dostępne oraz jakie połączenia sieciowe wolno mu nawiązać. To różnica między lokalnym wnioskowaniem a rzeczywiście lokalnym procesem.

 

Agent potrzebuje granic, nie tylko dobrego modelu

 

GitHub udostępnił lokalne sandboxy dla Copilot CLI, aplikacji Copilot i sesji VS Code korzystających z Agent Host. Microsoft rozwija podobny mechanizm na poziomie Windowsa poprzez Microsoft Execution Containers.

 

Sandbox nie odpowiada na pytanie, co agent powinien zrobić. Określa natomiast, czego zrobić mu nie wolno.

 

Może ograniczyć dostęp do plików, sieci, poświadczeń i procesów. Dzięki temu agent wykonujący polecenia w terminalu nie musi automatycznie otrzymywać takich samych uprawnień jak zalogowany użytkownik.

 

To szczególnie ważne przy pracy z kodem. W typowym repozytorium łatwo znaleźć pliki .env, tokeny, konfiguracje połączeń z bazą, dane testowe albo skrypty przeznaczone wyłącznie dla administratora.

 

Agent nie musi działać złośliwie, żeby spowodować problem. Wystarczy źle zrozumiane polecenie, nieaktualna dokumentacja albo wygenerowany skrypt, którego skutki wykraczają poza katalog projektu.

 

Małe modele mają wykonywać dużo pracy, nie wygrywać każdy benchmark

 

Równolegle Anthropic udostępniło Claude Haiku 5.5. Firma pozycjonuje go nie jako model rozwiązujący każdy możliwy problem, lecz jako tanią i szybką warstwę dla dużej liczby krótkich zadań.

 

To rozsądny kierunek. Agent potrafi wykonać dziesiątki operacji podczas jednego procesu. Pobiera dokument, wyszukuje fragment, klasyfikuje dane, tworzy podsumowanie, sprawdza format i dopiero później przekazuje trudniejszą decyzję mocniejszemu modelowi.

 

Uruchamianie najdroższego modelu na każdym etapie przypomina korzystanie z klastra obliczeniowego do zmiany nazwy pliku.

 

Coraz ważniejsze będzie więc projektowanie architektury wielomodelowej. Mały model może obsługiwać powtarzalne operacje, większy analizować problemy wymagające dłuższego rozumowania, a lokalny model przejmować dane, których organizacja nie chce wysyłać na zewnątrz.

 

W takim systemie nie istnieje jeden „najlepszy model”. Istnieje model najlepiej dopasowany do konkretnego zadania.

 

Infrastruktura nadal wyznacza granice

Lokalne AI nie rozwiązuje jednak problemu zasobów. Nowy komputer Microsoftu przeznaczony do pracy z modelami może dysponować 128 GB współdzielonej pamięci i układem Nvidia RTX Spark. To imponujące parametry, ale również sprzęt z zupełnie innej półki niż przeciętny laptop.

 

Tymczasem TSMC notuje rekordowe przychody napędzane popytem na układy AI i zaawansowane pakowanie chipów. Rosną też ceny gotowych systemów przeznaczonych do lokalnej pracy z modelami.

 

Dlatego wybór między lokalnym AI a chmurą nie sprowadza się do prywatności. Trzeba uwzględnić koszt sprzętu, energię, pamięć, czas konfiguracji, wykorzystanie urządzenia i częstotliwość wykonywania zadań.

 

Jeśli model ma pracować kilkanaście minut tygodniowo, chmura może pozostać bardziej opłacalna. Jeżeli jednak codziennie przetwarza tysiące dokumentów albo poufny kod, własna infrastruktura zaczyna wyglądać inaczej.

 

Polska dyskusja też staje się bardziej konkretna

 

Podczas AI Summit Poland wiele rozmów dotyczyło już nie samych możliwości modeli, ale powodów, dla których wdrożenia nie dają oczekiwanych oszczędności.

 

Pojawiały się dane, procesy, bezpieczeństwo, regulacje, koszty oraz przygotowanie pracowników. W programie konferencji zwracano również uwagę na rosnące zainteresowanie prywatną chmurą do produkcyjnego wnioskowania.

 

To zbiega się z globalnym zwrotem w stronę hybrydowej AI.

 

Polska firma nie musi budować własnego ogromnego centrum danych. Może jednak wydzielić część procesów do lokalnych modeli, wykorzystać prywatną infrastrukturę dla bardziej wrażliwych danych i pozostawić chmurę dla najbardziej wymagających zadań.

 

Warunkiem jest świadoma architektura. Bez niej łatwo otrzymać wszystkie koszty lokalnego środowiska i wszystkie ryzyka zewnętrznej usługi jednocześnie.

 

Lokalna AI wymaga szerszych kompetencji

 

Uruchomienie modelu w Ollamie lub LM Studio jest dziś stosunkowo proste. Trudniejsze pytania pojawiają się chwilę później.

 

Jak dobrać kwantyzację? Ile pamięci potrzebuje model? Jak kontrolować dostęp do plików? Co zapisuje narzędzie? Jak odseparować proces? Kiedy przekazać zadanie do chmury? Jak zmierzyć jakość i koszt całego workflow?

 

W praktyce lokalne AI łączy kilka dziedzin: programowanie, Linux lub Windows, sprzęt, sieci, bezpieczeństwo, API, kontenery i architekturę aplikacji.

 

To chyba najciekawszy wniosek z ostatnich premier. Modele stają się łatwiejsze do uruchomienia, ale rozsądne środowisko pracy z nimi nadal trzeba zaprojektować.

 

Chmura więc nie znika. Lokalna AI również nie pozostanie niszowym eksperymentem. Obie warstwy zaczynają działać obok siebie, a najważniejszą kompetencją może okazać się umiejętność postawienia między nimi właściwej granicy.

 

Źródła:

 

Hybrydowe AI wymaga dziś znajomości nie tylko samych modeli, lecz także sprzętu, systemów operacyjnych, bezpieczeństwa, programowania i architektury chmurowej. To te kompetencje pozwalają zdecydować, które elementy procesu warto zachować lokalnie, a które przekazać do chmury.