O czym jest ten film
- Lokalne AI to model działający na sprzęcie, którym sterujesz — laptopie, telefonie, a nawet przeglądarce — zamiast na cudzych serwerach w chmurze.
- Kluczowe pytanie nie brzmi „czy lokalny model jest mądrzejszy od chmurowego”, tylko „czy wystarczy do zadania — i czy lokalne uruchomienie robi produkt lepszym”.
- Krajobraz lokalnego AI ma cztery klocki: model („mózg”), magazyn modeli (Hugging Face), oprogramowanie do uruchamiania (LM Studio, Ollama) i proces, który wokół tego budujesz.
- Rodzina Gemma 4 od Google: E2B na telefony, E4B jako praktyczny punkt startowy, 12B na laptopy, 26B/31B na mocne stacje robocze — plus wyspecjalizowane odmiany do wyszukiwania, wywoływania narzędzi, obrazów i bezpieczeństwa.
- Poważne produkty będą raczej hybrydowe: lokalny model robi pierwsze przejście po wrażliwych danych, chmura dokłada głębsze rozumowanie na zanonimizowanej wersji, a człowiek zatwierdza to, co ważne.
- Ściągawka sprzętowa: 8 GB RAM — małe testy; 16 GB — E4B i mniejsze modele skwantyzowane; 32 GB — większe procesy; mocny GPU — największe modele. Na telefonie liczy się zadanie, nie rozmiar modelu.
- Pierwszy praktyczny proces: folder z dziesięcioma zgłoszeniami klientów + lokalny model = raport „co mówią klienci” z powtarzającymi się skargami, przyczynami źródłowymi i jednym zadaniem na tydzień.
- Zanim zaczniesz cokolwiek trenować, znajdź powtarzalny proces i zrób prosty test porównawczy: te same dane przez model lokalny i chmurowy, potem zestaw wyników.
- Trzy pomysły na biznes: recenzent dokumentacji dla agencji opieki domowej, mobilny asystent raportów polowych dla firm usuwających szkody, recenzent „przed wysłaniem” dla kancelarii, doradców i księgowych.
- Przestań traktować lokalne AI jako spór o benchmarki — to rozmowa o produkcie: gdzie są dane, gdzie urządzenie, gdzie problem z zaufaniem i gdzie uciążliwa pętla sprawdzania.
Redakcyjne tłumaczenie
Okno na 24 miesiące, którego większość ludzi jeszcze nie widzi
Uważam, że lokalne AI i otwarte modele wygenerują w ciągu najbliższych 24 miesięcy absurdalnie dużo okazji biznesowych — tylko że większość ludzi wciąż nie ma tej mapy. Korzystali z ChatGPT, korzystali z Claude, ale gdy słyszą „lokalne AI”, „Hugging Face”, „Ollama”, „LM Studio” czy „Google AI Edge”, wydaje im się, że to świat dla programistów, do którego zwykły założyciel firmy nie powinien nawet zaglądać. To błąd, bo okazji jest tu praktycznie bez dna.
Po dzisiejszym odcinku zrozumiesz, czym jest lokalne AI i kiedy ma znaczenie, jak uruchamiać otwarte modele w pracy, co w tym wszystkim robi Hugging Face, od której Gemmy zacząć, jak postawić model lokalnie w LM Studio albo Ollamie — i jak to wszystko przekuć w realne pomysły biznesowe. Dam ci trzy pomysły na startupy, które sam poważnie rozważyłbym zbudowanie: kto jest klientem, co robi pierwsza wersja, dlaczego lokalność ma znaczenie i jak bym to sprzedawał. Krótko mówiąc, będzie to mini-kurs z lokalnego AI — jak uruchamiać modele, jak budować na nich aplikacje i jak na tym zarabiać — wytłumaczony tak, żeby nadążył człowiek bez wykształcenia technicznego.
Krótkie podziękowanie dla Google za sponsoring odcinka i za to, że firma angażuje się w lokalne AI i otwarte modele dla przedsiębiorców. W odcinku będę używał Gemmy i Google AI Edge jako głównych przykładów, ale celem jest danie ci pełnej mapy tej przestrzeni — żebyś budował na tym modelu, który tobie pasuje.
Czym właściwie jest lokalne AI
Mówiąc najprościej: lokalne AI to model działający na sprzęcie, nad którym masz kontrolę. Może to być MacBook, laptop z Windowsem, telefon z Androidem albo iPhone, przeglądarka, Raspberry Pi czy stacja robocza w biurze. Ja właśnie kupiłem DGX Spark — to już wyższa półka. (Informacja dodatkowa: DGX Spark to kompaktowa stacja robocza NVIDIA, zaprojektowana specjalnie do lokalnego uruchamiania dużych modeli.) Najważniejsze jest jednak to, że dziś nawet telefon udźwignie lokalny model. AI w chmurze działa natomiast gdzieś daleko, a ty sięgasz do niego przez stronę internetową albo API. I na tym polega cała różnica.
Pytanie biznesowe brzmi: gdzie powinna mieszkać inteligencja? Jeśli zajmuję się pogłębionym researchem, strategią czy trudnym rozumowaniem — słowem czymkolwiek, przy czym chcę mieć najsilniejszy dostępny model — sięgnę po model chmurowy z absolutnej czołówki. Ale jeśli praca dotyczy prywatnych plików: wrażliwych danych klientów, działania offline, pracy w terenie, niskich opóźnień, danych audio — albo wewnętrznego procesu powtarzanego w kółko — lokalne AI zaczyna mieć mnóstwo sensu. Mały model umieszczony we właściwym miejscu potrafi być bardzo wartościowy. I to właśnie ta myśl powinna ci zostać w głowie.
Większość ludzi pyta: „czy ten model jest mądrzejszy od największego w chmurze?”. O wiele pożyteczniejsze pytanie brzmi: „czy ten model wystarczy do tej pracy — i czy to, że działa lokalnie, czyni produkt lepszym?”. Gdy zaczniesz je tak formulować, okazje biznesowe zaczną się same pokazywać.
Cztery elementy układanki
Krajobraz lokalnego AI ma cztery klocki.
Pierwszy: model — czyli plik z „mózgiem”. Gemma to rodzina modeli, Llama to rodzina modeli, Qwen czy Mistral również. Jedne lepiej rozumują, inne lepiej piszą kod. Jedne są mniejsze, szybsze albo lepsze w pracy z obrazami; inne po prostu łatwiej uruchomić na własnej maszynie.
Drugi: magazyn — miejsce, w którym szukasz modeli. Najpewniej trafisz na Hugging Face, największego gracza na tym polu; podobno firma właśnie negocjuje sprzedaż za 13 miliardów dolarów. Najprościej wyobrazić sobie Hugging Face jako gigantyczną hurtownię modeli. Znajdziesz tam karty modeli, licencje, formaty plików, przykłady, wyniki testów, wersje przygotowane przez społeczność, a czasem odmiany już skompresowane, które znacznie wygodniej uruchomić lokalnie. Jedno z najlepszych ćwiczeń dla początkujących to po prostu otworzyć Hugging Face i powoli, uważnie przeczytać jedną kartę modelu — nauczysz się tego więcej niż z niejeden poradnika. Podejrzanie wyglądające szczegóły możesz na początku zignorować i szukać odpowiedzi na kilka podstawowych pytań: do czego model służy, jaki jest duży, na jakiej licencji, na jakim sprzęcie ludzie go uruchamiają, czy obsługuje tekst, obrazy, dźwięk, wywoływanie narzędzi albo embeddingi — i czy dostępne są pliki skwantyzowane. Gdy potrafisz na to odpowiedzieć, cała przestrzeń przestaje przytłaczać. Sam kiedyś, patrząc na te karty po raz pierwszy, czułem się bezradny.
Trzeci: oprogramowanie, które uruchamia model. Większość osób powinna zacząć od LM Studio albo Ollamy. LM Studio zachowuje się jak zwykła aplikacja desktopowa: pobierasz, wyszukujesz model, klikasz i już możesz z nim rozmawiać. Moim zdaniem to jeden z najprzyjaźniejszych pierwszych kontaktów z tematem dla człowieka nietechnicznego. Ollama celuje bardziej w budowniczych: instalujesz, wpisujesz polecenie w rodzaju ollama run gemma… i nagle masz model działający lokalnie, z API, do którego mogą się podłączyć twoje aplikacje. Pod spodem tych narzędzi zacznie ci się obijać o uszy llama.cpp oraz MLX. llama.cpp napędza sporą część lokalnego uruchamiania modeli; MLX ma znaczenie, jeśli pracujesz na układach Apple i myślisz o wydawaniu prawdziwych aplikacji działających na urządzeniu.
Czwarty: przepływ pracy — produkt, który budujesz wokół tego wszystkiego. To w nim dzieje się prawdziwy interes.
Najważniejsze pojęcia w pięć minut
Parametry — powiedzmy 2 czy 4 miliardy — to wewnętrzne wagi modelu. Skrót myślowy dla początkujących: więcej parametrów zwykle oznacza więcej mocy do trudniejszych zadań, ale też większy apetyt na pamięć. Płacisz za to prędkością i sprzętem. Model dwu- lub czteromiliardowy to rozsądny wybór na urządzenia brzegowe, telefony, szybkie procesy i mniejsze zadania. Dwunastomiliardowy to złoty środek, a 26–31 miliardów wchodzi już na terytorium mocniejszych stacji roboczych — zależnie od sprzętu i konstrukcji modelu. Nie wydawaj jeszcze pięciu, dziesięciu czy dwudziestu tysięcy dolarów na stację roboczą. Po tym odcinku zrozumiesz, jak ogarnąć to wszystko na telefonie albo na zapasowym laptopie z 2021 roku.
Tokeny to kawałki tekstu, którymi model operuje. Lokalnie nie płacisz za tokeny, więc interesuje cię prędkość i pamięć, a nie rachunek.
Okno kontekstu mówi, ile informacji model jest w stanie ogarnąć w jednym podejściu.
Kwantyzacja brzmi groźniej, niż jest w rzeczywistości — sam ledwo potrafię to słowo wymówić. To po prostu kompresja modeli: dzięki niej gigant mieści się na zwykłym laptopie. Słyszałeś może o formatach Q4 czy Q8? To właśnie ona. Pełny model to wersja gigantyczna, a wersja skwantyzowana to ta, która realnie wejdzie na przeciętny sprzęt. Trochę jakości można stracić, ale nagle — jak za dotknięciem czarodziejskiej różdżki — to po prostu działa. Reguła na start: Q4 chodzi łatwiej, Q8 zachowuje więcej jakości, ale domaga się więcej pamięci. Zaczynaj od Q4.
GGUF to popularny format plików modeli lokalnych, przyjazny zwykłym maszynom takim jak twoja czy moja. A w świecie Google AI Edge spotkasz LiteRT-LM — format modelu i ścieżkę uruchomieniową, o którą dbasz, budując aplikacje działające na urządzeniu.
(Informacja dodatkowa: LiteRT to obecna nazwa biblioteki TensorFlow Lite, czyli narzędzia Google do uruchamiania modeli na telefonach i innych urządzeniach.)
Prosta mapa, którą warto zapamiętać: Hugging Face pomaga znaleźć modele i je zrozumieć. Gemma to otwarta rodzina Google — a Google to marka, której ufam; prowadzę na niej swój biznes, więc wybór jest dla mnie oczywisty. LM Studio pozwala testować modele lokalnie bez zbędnego trudu. Ollama pozwala je uruchamiać tak, żeby bardziej techniczne osoby podpięły je pod aplikacje. GGUF to wspólny format plików. A Google AI Edge z LiteRT-LM to droga do wydawania produktów AI na urządzeniach. Tyle wystarczy.
Rodzina Gemma i cała mapa Google
Gemma to otwarta rodzina modeli Google, a Gemma 4 powstała z myślą o sprawnym działaniu lokalnie i na urządzeniach. W skład wchodzi Gemma 4 E2B — mniejszy model brzegowy do zastosowań telefonicznych; Gemma 4 E4B — najbardziej praktyczny punkt startowy do większości lokalnych testów; Gemma 4 12B — złoty środek z większymi możliwościami dla laptopów; oraz Gemma 4 26B/31B — mocarny segment stacji roboczych. Taki oto wybieracz.
Mało kto wie, że istnieją też wyspecjalizowane odmiany Gemmy, które naprawdę warto znać. EmbeddingGemma służy do wyszukiwania: zamienia tekst na embeddingi, dzięki czemu można szukać znaczeniem, a nie dosłownym słowem. Jeśli chcesz lokalnie przeszukiwać własną dokumentację, notatki o klientach, zgłoszenia supportu, rozmowy handlowe czy bazę wiedzy — embeddingi są kluczowe. FunctionGemma odpowiada za wywoływanie narzędzi i ustrukturyzowane akcje: model pomaga oprogramowaniu działać w bardziej uporządkowany sposób. To kawałek drogi od „model dał mi odpowiedź” do „model pomógł produktowi zrobić następny krok”. Są i kolejne: PaliGemma — nastawiona na rozpoznawanie obrazów; ShieldGemma — na bezpieczeństwo; Gemma Scope — do zaglądania pod maskę i rozumienia, jak modele działają od środka. W pierwszym dniu możesz śmiało zostawić większość tej rodziny w spokoju. Praktyczna droga: zacznij od Gemmy 4 E4B, zrozum przepływ, a potem ruszaj w górę, w dół albo na boki — zależnie od tego, co budujesz.
Cały ekosystem Google AI wygląda w moim odczytanie tak: Gemma jako otwarta rodzina modeli; Google AI Edge jako środowisko do tworzenia AI działającego na urządzeniach; LiteRT-LM jako warstwa uruchomieniowa dla modeli językowych na różnych urządzeniach; AI Edge Gallery, w której możesz bezpośrednio wypróbować modele na urządzeniu i zobaczyć to doświadczenie na własne oczy. A gdy potrzebujesz ogromnej skali, solidnej zarządzanej infrastruktury albo rozumowania na najwyższym poziomie — masz do dyspozycji Gemini i Google Cloud albo dowolny inny model z czołówki.
Hybryda zamiast „wszystko w chmurze”
W praktyce wiele dużych i poważnych produktów będzie działać w układzie mieszanym: część rzeczy w chmurze, część lokalnie. Wyobraź sobie lokalne narzędzie dla firmy usług profesjonalnych. Model lokalny czyta wrażliwe szkice i wyłapuje problemy; wyciąga lub streszcza prywatne szczegóły i przygotowuje „czystą” wersję zagadnienia. Dopiero gdy klient chce głębszego rozumowania, do gry wchodzi model chmurowy — pracując na zanonimizowanej wersji. Taka architektura wydaje mi się naturalniejsza niż wrzucanie wszystkiego do chmury, na co wiele osób wcale nie ma ochoty. Lokalnie: prywatne pliki w pierwszym przejściu. Chmura: ciężkie myślenie wtedy, kiedy jest potrzebne. Człowiek: zatwierdza wszystko, co ważne, zanim wyjdzie na zewnątrz. Tak właśnie zaczynam myśleć o budowaniu wielu produktów — nie tylko na Gemmie.
Inne rodziny modeli — krótki przegląd
Llama od Meta to wciąż domyślny punkt odniesienia dla sporej rzeszy deweloperów, głównie dzięki potężnemu ekosystemowi. Plusem jest społeczność, narzędzia, przykłady i wsparcie; minusem — to, że licencję i kartę modelu trzeba przeczytać samemu, zwłaszcza gdy budujesz poważny produkt komercyjny.
Qwen od Alibaby zrobiła się bardzo mocna, szczególnie w kodowaniu, pracy wielojęzycznej, długim kontekście i zadaniach agentowych. Kwestia chińska jest realna: mnóstwo osób używa Qwena, bo po prostu dobrze działa. Ale jeśli działasz w korporacji, administracji publicznej, ochronie zdrowia, finansach albo na wrażliwych danych, musisz wyraźnie oddzielić uruchamianie otwartych wag u siebie od wysyłania danych do hostowanego serwisu — i sprawdzić, na co twoja firma, i ty sam, jesteś gotowi.
DeepSeek to podobna historia: pokazała, jak mocne potrafią być chińskie modele otwarte, zwłaszcza w rozumowaniu i kodzie. Za nią przemawiają wydajność i cena — jest tania. Przeciw niej to, że u części kupujących wzbudzi obawy natury zakupowej, bezpieczeństwa czy geopolitycznej. Trzeba tu przemyśleć, gdzie i jak ją wdrażać — i czy w ogóle iść tą ścieżką.
GLM, znana też jako Z.ai, to kolejna nazwa, która będzie ci się co chwilę przewijać — zwłaszcza na Hugging Face, w Ollamie czy w lokalno-modelowym Twitterze; robiłem o niej osobny odcinek. Warto wiedzieć, że niektóre z tych modeli bywają zaskakująco dobre w wąskich zadaniach. Nie lekceważ ich dlatego, że nie są rozpoznawalną marką — testuj, czytaj karty, sprawdzaj licencje. Ale to, czym się bawisz, i to, co wdrożysz w firmie, mogą być dwie różne rzeczy.
Mistral to europejska rodzina, siedziba we Francji. Cenię ich za wydajne modele, częste wydania i mnóstwo praktycznych zastosowań deweloperskich — ich postawa jest po prostu przyjazna budowniczym. Minusem jest nieco myląca oferta: część modeli jest otwarta, część komercyjna, więc zostają znaki zapytania.
Microsoft ma swoją otwartą rodzinę o nazwie Phi. Bywa ciekawa, jeśli zależy ci na małych, szybkich modelach o niskich opóźnieniach — ale w wielu zastosowaniach nie widziałem, żeby jakoś specjalnie błyszczała.
Nowych modeli przybywa bez przerwy, niemal co drugi dzień — i właśnie dlatego Hugging Face ma znaczenie. Nie chodzisz tam tylko po wielkie nazwiska, ale po dziwne, wyspecjalizowane modele, dostrajane wersje społeczności, skwantyzowane odmiany, forki i karty modeli, które mówią, czy coś nadaje się do twojego procesu. Nie musisz tego wszystkiego zapamiętywać. Sedno jest takie: istnieją ekosystemy, a twoim zadaniem jako założyciela — albo po prostu człowieka bawiącego się modelami — jest wybranie rodziny, która pasuje do twojej pracy i z którą jest ci po drodze. Możesz pobawić się wieloma, wiele się nauczyć, a dopiero potem się zdecydować.
Jak uruchomić Gemmę — trzy ścieżki
Dobra, zróbmy z tego coś namacalnego. Gdybym dziś chciał uruchomić Gemmę, zrobiłbym to tak.
Ścieżka pierwsza: LM Studio. Pobierasz — jest darmowe. Otwierasz aplikację i wyszukujesz Gemmę 4. Jeśli masz porządną maszynę, spróbuj E4B; jeśli wolniejszą lub starszą — rozejrzyj się za E2B. Szukaj wersji skwantyzowanej (ścieżka GGUF), żeby model chodził wyraźnie wygodniej. Gdy się pobierze, otwórz czat i zadaj coś naprawdę prostego. Polecam prompt biznesowy, bo chcę, żebyś wartość poczuł natychmiast — to taki moment „aha”. Na przykład: „Przeczytaj te notatki od klientów i zamień je w jednostronicowe memo: z czym klienci się męczą, co się zmieniło i co firma powinna naprawić w tym tygodniu” — i wklej notatki, choćby zmyślone, żeby zobaczyć efekt. Sedno ćwiczenia jest proste: model działa na twojej maszynie i korzystasz z AI, nie wysyłając tego promptu do chmury. Uważam, że każdy powinien tego spróbować i poczuć to na własnej skórze — bo takie działanie będzie coraz powszechniejsze, a przy okazji potrafi uruchomić w głowie zupełnie nowe skojarzenia.
Potem zajrzyj do sekcji deweloperskiej LM Studio i uruchom lokalny serwer. Robi się od tego znacznie ciekawiej: inne aplikacje mogą teraz rozmawiać z modelem na twoim laptopie, a komputer zamienia się w mały serwer AI. Skrypt, prototyp albo narzędzie wewnętrzne może odwoływać się do modelu przez localhost i dostawać odpowiedź. I właśnie wtedy zaczynasz widzieć, jak w nowej erze będą powstawać produkty.
Ścieżka druga: Ollama. Instalujesz, pobierasz Gemmę 4 poleceniem ollama pull, a następnie uruchamiasz wersję E4B. Gotowe — Gemma działa lokalnie z poziomu wiersza poleceń. Ollama stawia też lokalny port API (11434), co się przydaje, bo podłączysz do niego własną aplikację albo skrypt. Jeśli później chcesz spróbować większych modeli — 12B, 26B czy 31B — zakładając, że sprzęt udźwignie. Możesz o to zapytać jakiś LLM, albo po prostu samemu przejść przez powolność i męczarnię.
Ścieżka trzecia: Google AI Edge i LiteRT-LM. Tą drogą szedłbym wyłącznie wtedy, gdybym chciał zbudować prawdziwą aplikację z modelem w środku — np. aplikację mobilną, w której model działa na telefonie; aplikację przeglądarkową z modelem lokalnym; program desktopowy z prywatnym procesem; albo coś na urządzeniu brzegowe. LiteRT-LM zaprojektowano właśnie dla tego świata: Android, iOS, web, desktop i edge. To ścieżka od „lokalnego AI jako demo” do „lokalnego AI jako produktu”.
Ściągawka sprzętowa
8 GB RAM — zaczynaj od małych rzeczy i trzymaj pierwsze testy proste. 16 GB — już da się robić użyteczne eksperymenty, na przykład z E4B i mniejszymi modelami skwantyzowanymi. 30–32 GB — znacznie więcej swobody przy większych, lokalnych procesach. Mocna karta graficzna albo stacja typu DGX Spark — największe modele stają się w pełni realne. A na telefonie myśl dużo mniej o rozmiarze modelu, a dużo więcej o zadaniu: czy model zrozumie zdjęcie? Streści nagranie? Szybko coś sklasyfikuje? Pomoże pracownikowi w terenie? Zadziała bez dobrego zasięgu? Zrobi coś użytecznego w aplikacji, zanim użytkownik zdąży o to poprosić?
Pierwszy proces: dziesięć zgłoszeń, jeden plik na wyjściu
Zbudujmy pierwszy przepływ pracy w głowach. Na pulpicie zakładasz folder „notatki od klientów” i wrzucasz do niego dziesięć zgłoszeń supportu konkretnego biznesu — powiedzmy agencji opieki domowej, med spa albo firmy zajmującej się usuwaniem szkód po zalaniu. Notatki mogą brzmieć: „Próbowałam przełożyć termin, ale nie mogłam znaleźć linku”. „Technik nie wyjaśnił, co będzie dalej”. „Nikt tak naprawdę nie potwierdził mojej wizyty”. „Obciążono mnie dwa razy”. Następnie uruchamiasz lokalny model — Gemmę — i prosisz o utworzenie pliku „co-mówią-klienci.md”. Wynik powinien zawierać: powtarzające się skargi, dokładne słowa klientów, prawdopodobną przyczynę źródłową, obszar firmy, który wygląda na zepsuty, oraz jedną rzecz o wysokim priorytecie, którą operator powinien przetestować w tym tygodniu.
Dlaczego to dobry pierwszy proces? Bo jest użyteczny i prosty. Masz prywatne, chaotyczne dane; model pracuje tuż obok nich; a na wyjściu powstaje memo, z którego ktoś naprawdę skorzysta. A kiedy zrobisz to raz, dopadnie cię to „odblokowanie”, o którym mówiłem — bo wzorzec zaczniesz widzieć wszędzie. Folder rozmów z klientami staje się memem z badania rynku. Folder zgłoszeń — sygnałem do roadmapy produktu. Folder PDF-ów — checklistą ryzyk. Folder szkiców — recenzentem przed wysyłką.
Najpierw proces, dopiero potem trening
Dlatego zawsze zaczynam od przepływów pracy, zanim cokolwiek zacznę dostrajać. Ludzie słyszą „otwarty model” i od razu chcą wytrenować własny. Rozumiem, sam byłem taki — brzmi kusząco. Ale to ruch dla zaawansowanych. Praktyczny, początkujący krok jest inny: najpierw znajdź proces, który powtarza się w kółko. Jeden folder, jeden model, jeden wynik. Uruchamiasz to z dziesięć razy. Patrzysz, gdzie model się gubi; poprawiasz prompt i dokładasz przykłady; dodajesz checklistę. A potem tworzysz mały eval. Czym jest eval? To po prostu test, który mówi ci, czy model wykonał zadanie wystarczająco dobrze. W tym wypadku może być banalny: weź te same dziesięć notatek klientów, przepuść je przez lokalną Gemmę i przez mocny model chmurowy, a potem porównaj wyniki. Czy Gemma wyłapała te same skargi? Wyciągnęła właściwe cytaty? Trzymała format? Coś umknęło? Takie zestawienie uczy cię, gdzie lokalne rozwiązanie już dziś wystarcza, a gdzie wciąż chcesz silniejszego modelu z chmury — czyli jak myśleć o tej hybrydzie.
Kiedy lokalne, a kiedy chmura
Lokalnie: rzeczy prywatne, powtarzalne, szybkie, offline, osadzone na urządzeniu i wysokowolumenowe — procesy, które mają kręcić się bez przerwy. W chmurze: głębokie rozumowanie, gigantyczny kontekst, szeroki research — wszystko tam, gdzie najsilniejszy model realnie zmienia jakość odpowiedzi. Oba naraz: gdy produkt styka się z wrażliwymi danymi i trudnym rozumowaniem. Wiele cennych produktów będzie działać dokładnie tak: lokalne pierwsze przejście, eskalacja do chmury, ludzka zgoda na wszystko, co ważne. Według mnie tak właśnie będzie wyglądać praca.
Trzy biznesy, które bym zaczął
Chcę dać ci trzy pomysły na startupy, w których lokalne AI naprawdę gra pierwsze skrzypce. Szukam biznesów niszowych, użytecznych i od razu generujących gotówkę — takich, do których nie trzeba venture capital — związanych z bolesnym procesem. Mój filtr jest prosty: klient z wrażliwymi danymi, powtarzająca się praca polegająca na sprawdzaniu, złe oprogramowanie, zwykle drogie w skutkach błędy i proces dziejący się blisko urządzenia. Ta kombinacja to dla mnie rewir łowiecki. Kradnijcie śmiało — a w najgorszym razie niech ruszą wam tryby w głowach.
Pomysł 1: lokalny recenzent dokumentacji dla agencji opieki domowej
(Informacja dodatkowa: agencje opieki domowej (home health agencies) to typowy w USA model firmy medycznej — wysyłają pielęgniarki i opiekunów do pacjentów w ich domach, a ich codzienna praca jest mocno obciążona dokumentacją i regulacjami.)
Agencje opieki domowej wysyłają pielęgniarki i opiekunów do pacjentów, a ci piszą notatki z wizyt, aktualizują plany opieki i ogarniają rozliczenia oraz compliance. Papierologia to koszmar — zajmuje mnóstwo czasu, jeśli zobaczysz to na żywo — a ma ogromne znaczenie. Brakujący szczegół oznacza opóźnienie w rozliczeniu, nieprecyzyjna notatka dodatkową robotę administracyjną, a rozjazd między wizytą a planem opieki — kupę ryzyka. Tego nie chcemy.
Pierwsza wersja to lokalna aplikacja desktopowa dla agencji. Wrzucasz notatki z wizyt, plany opieki i transkrypcje dyktowane, a model przegląda je przed wysłaniem i flaguje problemy: „notatka wspomina zawroty głowy, ale nie ma parametrów życiowych”, „opiekun opisał zmianę leków, ale dalsze instrukcje są niejasne”, „notatka może nie uzasadniać poziomu usługi na fakturze”. Kupującego interesuje głównie jedno: mniej problemów z dokumentacją przed rozliczeniem, audytem albo przeglądem przełożonego. Rozwiążesz to — masz jego uwagę.
Jak bym to rozkręcał? Zacząłbym jako serwis. Znalazłbym pięć małych agencji i zaproponował przegląd paczki notatek — z lokalnym AI pomagającym za kulisami, ale na początku wszystko sprawdzane ręcznie przeze mnie. Zapisuję dwadzieścia problemów, które wracają jak bumerang; one stają się checklistą, a checklista w końcu staje się produktem. Punkt zaczepienia jest prosty: łapiesz problemy z dokumentacją, zanim kosztują agencję czas albo pieniądze, i budujesz od tego dalej. Uwielbiam ten biznes i zdecydowanie bym go zaczął.
Pomysł 2: polowy współautor raportów dla firm usuwających szkody
Chodzi o firmy zajmujące się usuwaniem skutków zalania, pożaru czy pleśni. Ekipy w terenie robią zdjęcia, nagrywają notatki, dokumentują szkody i tworzą raporty — dla właścicieli domów oraz likwidatorów ubezpieczeniowych. Miałem to niedawno u siebie, więc coś o tym wiem. Ta praca jest wizualna i fizyczna, odbywa się z dala od biurka, a raport ma kluczowe znaczenie: to on jest pomostem między technikiem, klientem, biurem a procesem ubezpieczeniowym.
Pierwsza wersja to aplikacja mobilna. Technik obchodzi nieruchomość, robi zdjęcia, nagrywa notatki głosowe, a aplikacja szkicuje raport, zanim opuści obiekt — i wyłapuje braki na miejscu: „wspomniałeś o piwnicy, ale nie ma zdjęć piwnicy”, „masz zdjęcie uszkodzonego sufitu, ale nie ma odczytu wilgotności”, „brakuje pokoju objętego szkodą”, „wyjaśnienie dla właściciela jest zbyt techniczne — oto wersja, którą zrozumie”. I ten ostatni element jest niedoceniany: w stresującej sytuacji szkody w domu jasna komunikacja jest częścią produktu. To byłoby kluczowe.
Jak bym to rozkręcał? Najpierw jedna nisza — nie rzucałbym się na wszystko. Na przykład szkody po zalaniu. Rozmawiam z właścicielami-firmowcami, oglądam ich obecne szablony raportów, badam oprogramowanie, którego używają (stary, przedpotopowy stack), i buduję wokół checklisty, którą i tak już mają w głowach. Demo to zdecydowanie najłatwiejsza część: „wyślijcie mi trzy stare zlecenia, a pokażę, jak szybko wasze notatki mogą zamieniać się w raporty”. Jeśli zadziała, produkt może rosnąć: kontrole jakości, szacunki, teczki dla ubezpieczyciela, aktualizacje dla klienta, szkolenie nowych techników. Ale zacząłbym od raportu polowego, bo jest konkretny i ewidentnie wkurzający. A patrząc na ten stary soft — po niedawnym zalaniu u mnie widziałem rzeczy prosto z początku lat 2000. — jest tu okazja na oprogramowanie od podstaw zaprojektowane pod lokalne AI. Stąd moje okno na 24 miesiące.
Pomysł 3: recenzent „przed wysłaniem” dla firm usług profesjonalnych
Każda firma usług profesjonalnych — no dobrze, 99,9 procent z nich — ma wersję tego procesu: ktoś pisze maila do klienta, ofertę, memo, streszczenie umowy, notatkę inwestycyjną albo kadrową, a potem prosi kogoś innego, żeby rzucił okiem przed wysłaniem. Kancelarie, biura rachunkowe, doradcy finansowi, firmy rekrutacyjne, nawet konsultanci — wszędzie znajdziesz taki obieg.
Pierwsza wersja to lokalna aplikacja desktopowa przeglądająca wychodzące szkice, zanim opuszczą firmę. Dla doradcy finansowego: flagowanie sformułowań brzmiących jak gwarantowany zysk — absolutne „nie”. Dla kancelarii: zdań brzmiących zbyt kategorycznie. Dla HR: wrażliwych danych pracowników, które nie powinny zostać w wątku. Dla agencji: obietnic niepokrytych zakresem. Dla księgowego: liczby niezgodnej z załączonym plikiem — zdziwiłbyś się, jak często to się zdarza. Produkt to druga para oczu przy wrażliwej pracy — „polisa od wpadek”. Może nawet tak bym to nazwał: polisaodwpadek.com. Ktoś niech sprawdzi, czy domena wolna.
Jak bym to rozkręcał? Jeden sektor i jeden typ dokumentu. Na przykład przegląd maili dla niezależnych doradców finansowych — nie wszystkich i nie wielkich banków na start. Rozmawiam z dziesięcioma doradcami i pytam, które maile ich stresują. Zbieram zanonimizowane przykłady, zamieniam ich realne obawy w checklistę przeglądu i buduję lokalne narzędzie, które sprawdza szkice wobec tej listy. Sprzedaje się to samo, bo kupujący doskonale zna to zachowanie — już dziś prosi kogoś o sprawdzenie szkicu. Dajesz mu po prostu szybsze pierwsze przejście, które mieszka bliżej danych klienta i wewnętrznych zasad firmy. Ten pomysł uwielbiam i mam nadzieję, że ktoś z was go porwie.
Nie budujesz startupu? Zrób sobie laboratorium
Nawet jeśli jutro nie budujesz żadnego z tych pomysłów, i tak ucz się lokalnego AI, bo zmienia ono pracę z własnymi plikami — z czysto osobistej perspektywy produktywności jest to bardzo pomocne. Jeśli pracujesz w firmie i chcesz po prostu działać sprawniej, żeby zostało więcej czasu na TikToka, filmy albo rodzinę: załóż folder „laboratorium lokalnego AI” i wrzuć do niego dziesięć plików ważnych dla twojej pracy. Cokolwiek: rozmowy handlowe, transkrypcje spotkań, stare tweety, własne pomysły. Potem uruchom Gemmę — albo dowolny inny model — i każ jej wyprodukować jeden użyteczny artefakt: cotygodniowy puls biznesu, zestawienie tego, co się zmieniło w rozmowach z klientami, grupowanie próśb o funkcje według prawdziwego bólu, przegląd szkiców pod kątem tego, na co odbiorcy reagują.
Klucz: wyprodukuj plik — memo, checklistę, krótki raport, przegląd — który da się używać ponownie. Odpowiedź w czacie jest miła dla oka, ale użyteczny artefakt zmienia cały proces. To pierwsze powtórzenie, jakie polecam: model czyta folder, model pisze plik, ty sprawdzasz, poprawiasz proces i uruchamiasz ponownie. Po kilku takich rundach mózg naprawdę zaczyna łączyć kropki. Widzisz, gdzie prywatne dane siedzą uwięzione w folderach. Widzisz, które przeglądy powtarzają się w kółko. Widzisz, które procesy zależą od kogoś, kto sprawdza formularz, czyta notatkę, porównuje dwa pliki, prostuje raport albo pisze to samo memo tydzień po tygodniu.
Puenta: rozmowa o produkcie, nie o benchmarkach
Mam nadzieję, że ten odcinek uruchomił wam kreatywność, bo gdy raz zobaczysz ten wzorzec, zaczniesz dostrzegać biznesy lokalnego AI wszędzie. Możesz poznać mapę na tyle, żeby wiedzieć, gdzie te modele pasują — nie stając się z dnia na dzień inżynierem. Wierzę, że część AI należy do chmury, część do urządzenia, a wiele najlepszych produktów najbliższych lat połączy jedno i drugie. Gdybym zaczynał dziś: uruchomiłbym Gemmę lokalnie, poczytał karty modeli na Hugging Face, poznał różnicę między LM Studio a Ollamą, pobawił się Google AI Edge — a potem szukał jednego nudnego procesu, w którym lokalne AI realnie czyni produkt lepszym. Kategorie łowne to: prywatne dane, praca offline, kontekst z kamery i mikrofonu, niskie opóźnienia, wysokie i powtarzalne koszty API, kupujący, który czuje się lepiej, gdy model działa blisko niego, oraz proces, w którym mały zespół agentów mógłby codziennie czytać, sprawdzać, streszczać i przygotowywać pracę. To jest ten rewir.
Lokalne AI robi się o wiele prostsze do zrozumienia, gdy przestaniesz traktować je jako rozmowę o wynikach benchmarków, a zaczniesz jako rozmowę o produkcie. Zadaj sobie pytania: gdzie odbywa się praca? Gdzie są dane? Gdzie jest urządzenie? Gdzie problem z zaufaniem? Gdzie uciążliwa pętla przeglądu? Odpowiedz na nie — a pomysły zaczną się pokazywać same.
Czytam każdy komentarz na YouTube i odpowiadam na większość, więc do zobaczenia pod filmem. Podziel się tym materiałem z kimś, kto skorzysta z jasnego wytłumaczenia lokalnego AI. Do następnego razu — i budujcie śmiało.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Pytaj „czy wystarczy do zadania”, a nie „czy jest najsilniejszy”
Na czym polega: Wybór modelu to nie ranking mocy, tylko dopasowanie do pracy. Mały model we właściwym miejscu bywa bardzo wartościowy, a pytanie o to, czy lokalne uruchomienie poprawia produkt, otwiera okazje niedostępne w dyskusji o benchmarkach.
Jak stosować: Przy każdym pomyśle wypisz trzy rzeczy: co konkretnie model ma robić (klasyfikacja, streszczenie, przegląd), jaki poziom jakości wystarczy, i co daje lokalność — prywatność, offline, koszty. Dopiero potem wybieraj model.
Na co uważać: Nie testuj modelu na zadaniach „dowodzenia inteligencji”, tylko na własnych danych — inaczej wyciągniesz wnioski niezgodne z realną pracą.
2.Kwalifikuj zadania do lokalnego AI po pięciu sygnałach
Na czym polega: Lokalne AI ma sens, gdy występuje któryś z sygnałów: prywatne pliki, praca offline lub w terenie, niskie opóźnienia, dane z kamery i mikrofonu, proces powtarzany dziesiątki czy setki razy.
Jak stosować: Przejrzyj procesy w swojej firmie pod kątem tej listy — każdy trafiony sygnał podnosi wartość lokalnego wdrożenia i pomaga oszacować zwrot.
Na co uważać: Głębokie rozumowanie, gigantyczny kontekst i szeroki research to wciąż domena chmury — nie forsuj lokalności tam, gdzie jakość odpowiedzi zależy od najsilniejszego modelu.
3.Zapamiętaj cztery klocki: model, magazyn, oprogramowanie, proces
Na czm polega: Cała przestrzeń lokalnego AI da się opisać czterema elementami: plikiem modelu (Gemma, Llama, Qwen), hurtownią modeli (Hugging Face), narzędziem do uruchamiania (LM Studio, Ollama) i przepływem pracy, który budujesz wokół tego wszystkiego.
Jak stosować: Przy każdej decyzji sprawdź, z którym klockiem masz do czynienia — szukasz modelu? licencji? sposobu uruchomienia? czy już projektujesz produkt? To porządkuje naukę i zakupy.
Na co uważać: Trzeci klocek (narzędzie) łatwo pomylić z celem. LM Studio to dopiero środek — wartość powstaje w czwartym klocku, czyli w procesie.
4.Naucz się czytać karty modeli — wystarczy sześć pytań
Na czym polega: Karta modelu na Hugging Face potrafi przytłaczać, ale na start wystarczy odpowiedzieć na sześć pytań: do czego model służy, jaki jest duży, na jakiej licencji, na jakim sprzęcie go uruchamiano, jakie obsługuje dane (tekst, obraz, dźwięk, narzędzia, embeddingi) i czy są wersje skwantyzowane.
Jak stosować: Wybierz jeden model i przeczytaj jego kartę powoli, z notatnikiem. Po trzech kartach przestaniesz się bać tego ekosystemu.
Na co uważać: Licencja bywa ukryta w dopiskach — przy produkcie komercyjnym czytaj ją dokładnie, zwłaszcza u Llamy i Mistrala, gdzie część modeli jest otwarta, a część komercyjna.
5.Zacznij od Gemmy 4 E4B w wersji skwantyzowanej Q4, w LM Studio
Na czym polega: To najniższy próg wejścia: darmowa aplikacja desktopowa, wyszukanie modelu, pobranie wersji Q4 i pierwsza rozmowa — wszystko bez wysyłania czegokolwiek do chmury.
Jak stosować: Pierwszy prompt zrób biznesowy, nie „opowiedz dowcip” — np. „zamień te notatki od klientów w jednostronicowe memo”. Od razu poczujesz praktyczną wartość, a nie tylko ciekawostkę.
Na co uważać: Q4 traci nieco jakości w stosunku do pełnego modelu. Jeśli wynik jest „rozwleczony” albo model gubi szczegóły, spróbuj Q8 — ale pamiętaj, że wymaga więcej pamięci.
6.Od czatu do serwera: włącz lokalny serwer i podepnij własny skrypt
Na czym polega: LM Studio ma sekcję deweloperską z lokalnym serwerem, a Ollama stawia API na porcie 11434. Od tego momentu laptop staje się małym serwerem AI, do którego możesz podłączyć skrypt, prototyp albo narzędzie wewnętrzne.
Jak stosować: Napisz prosty skrypt, który wysyła do lokalnego modelu zawartość folderu i zapisuje odpowiedź do pliku. To pierwszy krok od „bawienia się” do „budowania produktu”.
Na co uważać: Lokalny serwer działa na twojej maszynie i konsumuje jej zasoby — przy większych modelach zamknij zbędne aplikacje i licz się z wolniejszym działaniem.
7.Jeden folder, jeden model, jeden plik wynikowy — powtórz dziesięć razy
Na czym polega: Najlepszy pierwszy proces to najprostszy: folder z dziesięcioma zgłoszeniami klientów, lokalny model i jedno wyjście — plik „co mówią klienci” z powtarzającymi się skargami, przyczynami źródłowymi i jednym zadaniem na tydzień.
Jak stosować: Uruchom proces z dziesięć razy, notuj, gdzie model się myli, poprawiaj prompt, dokładaj przykłady i checklistę. Dopiero potem myśl o skalowaniu albo dostrajaniu modelu.
Na co uważać: Pokusa trenowania własnego modelu na starcie to pułapka — to ruch zaawansowany. Najpierw udowodnij, że sam proces przynosi wartość.
8.Zrób prosty eval: lokalny kontra chmurowy na tych samych danych
Na czym polega: Eval to po prostu test, który mówi, czy model zrobił robotę wystarczająco dobrze. Najprostsza wersja: te same dziesięć dokumentów przepuść przez model lokalny i przez mocny model chmurowy, a potem porównaj wyniki — czy wyłapano te same problemy, czy zachowano format, co umknęło.
Jak stosować: Taki test pokazuje, gdzie lokalne rozwiązanie już wystarcza, a gdzie naprawdę potrzebujesz chmury — i daje konkretne argumenty do decyzji o architekturze hybrydowej.
Na co uważać: Porównuj na realnych danych z twojego procesu, nie na wymyślonych przykładach — łatwo o mylnie optymistyczne wnioski.
9.Projektuj hybrydowo: lokalne pierwsze przejście, chmura do myślenia, człowiek do zatwierdzenia
Na czym polega: Naturalna architektura dla wrażliwych danych: lokalny model czyta prywatne szkice, wyłapuje problemy i przygotowuje zanonimizowaną wersję; chmura wykonuje głębokie rozumowanie na „czystej” kopii; człowiek zatwierdza wszystko, co ważne.
Jak stosować: Przy projektowaniu produktu rozdziel proces na te trzy warstwy od samego początku — to ułatwia rozmowę z klientem o prywatności i obniża koszty chmurowe.
Na co uważać: Anonimizacja musi być rzetelna: jeśli „czysta” wersja wycieka szczegóły, cała zaleta prywatności lokalnej znika. Warto ją testować osobno.
10.Szukaj klientów: wrażliwe dane + powtarzalny przegląd + złe oprogramowanie
Na czym polega: Filtr okazji biznesowych: klient pracujący na wrażliwych danych, z procesem polegającym na ciągłym sprawdzaniu dokumentów, z przestarzałym oprogramowaniem i z błędami, które dużo kosztują — agencje opieki domowej, firmy usuwające szkody, kancelarie, doradcy finansowi, biura rachunkowe.
Jak stosować: Zacznij jako serwis: zrób przegląd dokumentów dla pięciu klientów z AI w tle, zapisz powtarzające się problemy, zamień je w checklistę — a checklistę w produkt. Demo buduj na starych zleceniach klienta.
Na co uważać: Nie rzucaj się od razu na cały rynek — jedna nisza i jeden typ dokumentu na start. I nie sprzedawaj „AI”, tylko mniej problemów przed audytem, rozliczeniem albo wysłaniem maila.