O czym jest ten film
- Dlaczego warto mieć lokalne AI jako „polisę ubezpieczeniową” — ryzyko dostawcy, rosnące rachunki, prywatność i agenci działający w tle.
- Autor odrzuca wojnę „open source kontra closed source” i pokazuje, jak łączyć oba światy.
- Kluczowy schemat ekosystemu w pięciu warstwach: sprzęt → modele → silnik inferencji → gateway → interfejs (plus harness).
- Jak użyć Claude Code / Codex, żeby przeanalizowały twój sprzęt i dobrały modele, które faktycznie na nim ruszą.
- Rola Open Router (testowanie modeli) i Hugging Face (pobieranie modeli).
- Prywatna sieć mesh przez Tailscale — dostęp do lokalnego AI z telefonu i innych urządzeń.
- Przegląd najlepszych modeli open weight (Qwen, GLM, Kimi, MiniMax, Gemma, DeepSeek) i jak dzielić zadania między modele.
- Podpięcie modeli open source pod harness Claude Code przez Open Router (tryb „DSP-OS”).
- Objaśnienie pojęć: parametry, kwantyzacja/„bity”, GGUF vs MLX, KV cache, sparse attention, tokeny na sekundę.
- Budowa własnego centrum dowodzenia na bazie repozytorium ODS (Osmantic) — praktycznie „na przycisk”.
Redakcyjne tłumaczenie
Wstęp: dlaczego w ogóle lokalne AI
W ostatnich miesiącach przeżyliśmy kilka „strachów” związanych z AI. Tydzień temu Anthropic odciął dostęp do świeżo wypuszczonych modeli — Fable 5 i Mythos 5. Z dnia na dzień straciliśmy dostęp nie do jednego, lecz do dwóch modeli z górnej półki. Uznano je za zbyt niebezpieczne i zbyt potężne, by udostępniać je publicznie. Później je odzyskaliśmy, ale te kilka tygodni stworzyło precedens. To było przypomnienie, że cokolwiek robisz na co dzień i jakkolwiek korzystasz z AI, wszystko może się zmienić w mgnieniu oka.
(Informacja dodatkowa: Fable i Mythos to nazwy modeli używane w narracji filmu; przykład ma ilustrować ryzyko nagłej utraty dostępu do modeli zamkniętych.)
Modele open source i open weight z natury nie dorównują absolutnej czołówce. Ale dla wielu codziennych zastosowań stają się aż nadto dobre — do pracy, na którą wydajesz mnóstwo pieniędzy w modelach zamkniętych. I co najlepsze, będą się dalej poprawiać. Dlatego bardziej niż kiedykolwiek warto mieć mentalną polisę ubezpieczeniową: wiedzieć, jak z tych modeli korzystać, jak wyciągnąć z nich pełnię możliwości i czy opłaca się zainwestować w sprzęt.
Celem tego minikursu jest rozłożenie na czynniki pierwsze wielu zawiłych pojęć, które być może wcześniej cię odstraszały. A dodatkowo pokażę pewien twist: jak używać modeli zamkniętych, takich jak Claude i Codex, żeby pomogły ci zbudować, skonfigurować, a nawet utrzymać i naprawiać twój lokalny setup. Zamiast kazać ci wybierać strony, pokażę, jak wziąć to, co najlepsze z obu światów.
Film dzieli się na trzy części: kluczowe koncepcje, dobór właściwego modelu do właściwego zadania w odpowiednim momencie (z narzędziami takimi jak Tailscale czy Ollama), a na końcu — droga najmniejszego oporu do zbudowania własnego centrum dowodzenia.
Centrum dowodzenia — podgląd celu
To jest moje osobiste centrum dowodzenia AI, działające wyłącznie na modelach lokalnych hostowanych na tym Mac Mini. W zależności od tego, jakie modele chcesz uruchamiać i jaki masz sprzęt, może nie będziesz takiego urządzenia potrzebować. Ale jeśli chcesz oddzielone środowisko, żeby izolować i prowadzić eksperymenty, dopóki nie złapiesz wprawy, coś w rodzaju Mac Mini bywa pomocne.
Najważniejsze jest to, że masz dashboard z szeregiem gotowych funkcji, które jeszcze 24 miesiące temu trzeba było mozolnie składać ręcznie. Możesz mieć czat AT, uruchomić agenta Hermes prosto z pudełka, mieć Q&A po dokumentach (czyli RAG, który kiedyś był ogromnym bólem głowy), a nawet tworzyć automatyzacje w lokalnej wersji n8n.
(Informacja dodatkowa: RAG — retrieval-augmented generation — to technika, w której model odpowiada, korzystając z twoich własnych dokumentów podanych mu jako kontekst.)
Kliknięcie „AI chat” otwiera zakładkę z Open WebUI — środowiskiem przypominającym ChatGPT czy Claude, gdzie przeciągasz i upuszczasz pliki, korzystasz z zamiany mowy na tekst i wysyłasz zapytanie. Kluczowe: to zapytanie uruchamia się na Mac Mini, a nie na tym laptopie. Kiedy wysyłam pytanie „Jaki rodzaj konsultingu AI najlepiej założyć w 2026 roku?”, na dashboardzie widać skok CPU Mac Mini, zużytą pamięć, okno kontekstu i użyty model. Odpowiedź przychodzi wolniej niż w zwykłym czacie online, ale przychodzi — razem ze śladami rozumowania modelu.
Jeśli masz skonfigurowany Tailscale, możesz korzystać z tego dashboardu w drodze — nawet z telefonu. Możesz też generować obrazy po ustawieniu ComfyUI: nie w jakości GPT Image czy Gemini 3.1, ale wystarczająco dobrej dla większości zastosowań. Jest też zakładka rozszerzeń — coś jak mały sklep z aplikacjami, gdzie dokładasz kolejne narzędzia open source: orkiestrację, bazy wektorowe, integracje pokazujące pełną mapę systemu. U mnie działają model wizualny Qwen, model Qwen 14B oraz Mistral do triażu maili.
Cztery powody, by uruchamiać AI lokalnie
Pokazuję to nie po to, żeby machać przed tobą czymś efektownym, ale żeby pokazać, dokąd zmierzamy. Zanim jednak wejdziemy głębiej, oczyśćmy atmosferę wokół tej „wojny” w internecie. Jedna drużyna — zamknięta — uważa, że open source jest bezużyteczny i beznadziejnie w tyle. Druga drużyna — otwarta — śmieje się z użytkowników modeli zamkniętych. Ja jestem pośrodku i uważam, że obie strony się mylą. Open source jest niezbędny jako redundancja na wypadek eksplozji kosztów. Jednocześnie ja i mój zespół intensywnie używamy modeli zamkniętych. Trzeba umieć poruszać się w obu światach — to dziś umiejętność życiowa.
Cztery powody, dla których warto rozważyć lokalne AI:
1. Ryzyko dostawcy (vendor risk). To właśnie stało się z Fable i GPT 5.6 i prawdopodobnie powtórzy się z kolejnymi modelami — niektóre mogą nigdy nie trafić w ręce publiczności. Gdy odzyskaliśmy Fable, nie dostaliśmy pełnej wersji: jakość, długość bezbłędnego działania i pomysłowość były zauważalnie słabsze.
2. Rachunek. Subsydia dla tych planów kiedyś się skończą — to czysta ekonomia. Kapitał wysokiego ryzyka dotuje firmy jak Anthropic i OpenAI, by mogły oferować plany za 100–200 dolarów, które okazują się warte 6–8 tys. dolarów użycia na Claude i 13–15 tys. na OpenAI miesięcznie. Nie trzeba być matematykiem, żeby zrozumieć, że w pewnym momencie te firmy będą musiały szybko zacząć zarabiać. Uber i Airbnb latami działały pod kreską, żeby uzależnić ludzi od swojego ekosystemu — z modelami zamkniętymi może być tak samo. Jeśli cała firma jest uzależniona od jednej platformy, a rachunek wzrośnie pięciokrotnie, przez jakiś czas i tak będzie musiała płacić, bo jest w niej zamknięta (locked in).
3. Prywatność. Oczywisty przypadek to niewysyłanie swoich danych do trenowania modeli. Przykład: zbudowałem cały „system operacyjny zdrowia” i przetworzyłem swoje DNA — analizę wykonały modele lokalne, które nie wysyłały tych informacji nigdzie dalej. Dopiero po syntezie użyłem modeli zamkniętych, żeby dopracować system.
4. Agenci działający w tle (ambient agents). Mogą nieustannie skanować twój system, szukać luk bezpieczeństwa, sprawdzać kondycję aplikacji, robić ciągły RAG po plikach — zespół agentów działający 24/7, wykonujący czarną robotę, na którą nie warto wydawać pieniędzy na API. Zamiast wydawać tysiące dolarów miesięcznie na najtańsze nawet modele zamknięte, płacisz dziesiątki (może wczesne setki) dolarów za prąd.
Dlaczego dziś jest inaczej niż rok temu
Niektórzy próbowali już Ollamy, pobrali Llama 3.1, Llama 2 czy Mistral i byli rozczarowani. Słusznie — dwa lata, a nawet 12 miesięcy temu wiele z tych modeli było zabawkami. Ale dziś, przy modelach takich jak Kimi K3, masz nie tylko lepsze modele i systemy, ale też tzw. harnessy, do których podpinasz modele lokalne, żeby działały znacznie lepiej. I — jak mówiłem — możesz użyć planu od 20 do 200 dolarów na Codex lub Claude Code, żeby zbudować całą infrastrukturę. Pokazane na początku centrum dowodzenia powstało tak: wziąłem cudze repozytorium z GitHuba (ODS), podałem je Claude Code, kazałem je przeanalizować, rozproszyć pracę na wielu agentów, a potem dobrać najlepszy model do moich specyfikacji i zająć się całą „hydrauliką”.
Kluczowy schemat: pięć warstw ekosystemu
To najważniejszy fragment całego filmu. Gdy zrozumiesz ten diagram, reszta ułoży się sama. Idąc od tyłu do przodu:
1. Warstwa sprzętu. Twój laptop z Windowsem, Mac, Mac Mini, Mac Studio — cokolwiek masz. To decyduje, jakie modele uruchomisz, w jakiej wydajności i z jaką latencją (tzw. tokeny na sekundę).
2. Warstwa modeli. Mówimy o modelach lokalnych — albo „open source”, „local source”, albo „open weight”. Open weight oznacza, że mamy cały plik wag opisujących, jak model działa. Przy Claude od Anthropic i modelach GPT od OpenAI nie widzisz wag i nie wiesz dokładnie, jak dochodzą do odpowiedzi. Przy modelach chińskich czy Gemma od Google możesz te wagi fizycznie zobaczyć.
3. Warstwa silnika inferencji. Zwykle chodzi o llama.cpp lub vLLM. Llama.cpp to most, przez który model bierze twój prompt, przepuszcza go przez silnik i tworzy odpowiedź. vLLM to alternatywa używana raczej w skali zespołowej.
4. Warstwa gateway. Zwykle jest to LiteLLM. Pozwala tworzyć API łączące dowolną usługę z modelami lokalnymi na twoim komputerze — działa jak przejściówka do gniazdka, dzięki której wszystkie aplikacje rozmawiają z dowolnym modelem.
5. Warstwa interfejsu. Na wierzchu masz coś jak Open WebUI, gdzie prowadzisz rozmowę tak jak w ChatGPT czy Claude.
Do tego dochodzą harnessy. Harness to sposób, by model open source — „mózg w słoiku” — dostał kończyny. Pozwala pisać, czytać i modyfikować pliki, używać basha do przemieszczania plików itd. To właśnie harness sprawia, że ludzie kochają Claude Code i Codex — myślą, że cała orkiestracja to sam model, a to symbioza modelu z jego kończynami. Jeśli chcesz używać modelu open source w Claude Code, możesz podpiąć Open Router przez API i „pożyczyć” harness Claude Code.
Warstwa 1 i 2 razem: dobór modelu do sprzętu
Możemy połączyć pierwsze dwie warstwy. Używamy Claude Code, Codex albo nawet Kimi 3, żeby spojrzały na twój sprzęt: ile masz RAM-u, ile pamięci, co to znaczy po ludzku, ile masz VRAM — i na tej podstawie ustaliły, jakie modele faktycznie na tym ruszą, żebyś nie czekał pięciu dni roboczych na odpowiedź na „cześć”.
W terminalu (używam Opus 4.8) wysyłamy prosty prompt: „Czy możemy użyć API Open Router, żeby pobrać najnowsze modele open source z ostatnich 6 miesięcy według dzisiejszej daty?” i „skategoryzuj je na modele tekstowe kontra multimodalne”.
Open Router to platforma, która pozwala rozmawiać z dowolnym modelem — otwartym czy zamkniętym. Masz portfel kredytów i przez API z niego czerpiesz, sięgając po różne modele z jednego mostu. Najważniejsza jest tu funkcja eksploracji modeli: rankingi, cały leaderboard i publiczne API. Zamiast robić web fetch i ryzykować niekompletne wyniki, pobieramy pełną listę z tego źródła jako JSON — z podziałem na modele tylko tekstowe i multimodalne (te, które rozumieją i tworzą obraz, wideo, audio). W rankingach widać zresztą, że Anthropic zajmuje sporą część leaderboardu, ale można odfiltrować same modele open source.
Mając listę, mówimy: „Przejdź przez specyfikację mojego systemu i powiedz, jakie modele mogę uruchomić, jeśli chcę model dobry w generowaniu jakościowego tekstu, ale też rozumiejący obraz i potencjalnie wideo oraz tworzący audio. Jeśli potrzeba do tego kilku modeli, daj znać. Ale ma nie działać bardzo wolno.” Model sięgnie po specyfikację systemu, porówna ją z wymaganiami modeli i poda krótką listę.
Ja pracuję na Apple M5 Max z ponad 128 GB pamięci, 18 rdzeniami i GPU — to bestia, ale bardzo droga. Tobie do codziennej pracy taki sprzęt nie będzie potrzebny. Kupiłem cały ten sprzęt, zanim kilka miesięcy temu ceny nieuchronnie poszły w górę.
(Informacja dodatkowa: nazwy modeli w filmie — Qwen 3.5, Gemma, Nvidia Nemotron — bywają wypowiadane niewyraźnie w automatycznym transkrypcie; traktuj konkretne numery jako przybliżone.)
Model rozbija chip, pamięć zunifikowaną i — co ważne — ile z niej faktycznie można przeznaczyć na modele. Ludzie patrzą na pudełko laptopa i myślą, że skoro jest 128 GB, to tyle mogą użyć. Nie da się: masz inne aplikacje działające w tle. Dostajesz też informację, które modele są zdecydowanie za duże — nawet moja bestia nie uruchomi Kimi K2 bez wersji skwantyzowanej (skompresowanej).
Możesz kazać modelowi rozproszyć pracę na podagentów, żeby znalazły najlepsze modele do syntezy mowy. Dostajesz też instrukcję, jak to uruchomić: najprościej na Apple Silicon przez LM Studio lub Ollamę (backend llama.cpp), a jest też MLX zoptymalizowany pod Apple. Możesz nawet powiedzieć: „Pobierz ten rekomendowany model Qwen.” Wtedy sprawdzi Hugging Face.
Hugging Face to odpowiednik sklepu z aplikacjami dla modeli: nowe modele, wersje skwantyzowane, modele dostrojone (fine-tuned) i tzw. destylowane — gdzie ktoś wziął np. wersję Kimi, skompresował ją i zrobił świetną w rozumieniu obrazów. Open Router serwuje modele, ale ich nie pobierzesz; Hugging Face to repozytorium, z którego się pobiera.
W moim przypadku wybrany model waży 70 GB, obsługuje obraz i wideo, i rozsądnie szybko działa — więc pobieram. Mam już Ollamę i Brew, ale jeśli tobie ich brakuje, model powinien to wykryć i zainstalować jako wymagania wstępne. Najlepsze w używaniu terminala z tak mądrym modelem zamkniętym jak Claude jest to, że sam zauważy, że trzeba zaktualizować Pythona: pobranie 65 GB było idealne, ale biblioteka serwująca wymagała dwóch poprawek. Zamiast żebym sam się w tym grzebał, sam zaktualizuje środowisko wirtualne i architekturę modelu.
Na końcu dostaję komunikat, że wszystko działa: model chodzi z prędkością 60 tokenów na sekundę i zajmuje określoną część moich 128 GB. Zwykle nie chcesz przekraczać 50% — zaczną się problemy, zwłaszcza gdy uruchamiasz coś równolegle. Ponieważ Ollama i LM Studio to nakładki na llama.cpp, Claude Code potrafił połączyć się z modelem i można z nim od razu porozmawiać. Robię to zresztą, nagrywając ten film w 4K — i radzi sobie nieźle. Potem wyrzucam model (eject), żeby zwolnić maksimum pamięci.
Ten sam proces można wykonać zdalnie na Mac Mini — łączę się przez współdzielenie ekranu i SSH (bezpieczna powłoka), uruchamiam ten sam prompt, model znajduje najlepsze dopasowania, instaluje w moim imieniu i aktualizuje dashboard.
Llama.cpp vs vLLM
Zanim przejdziemy do gateway, domknijmy różnicę między llama.cpp a vLLM. Kiedy pracujesz z modelem lokalnym na własnym sprzęcie, gotujesz dla przyjęcia jednoosobowego — nie musisz martwić się skalowaniem inferencji. Ale gdy obsługujesz coś w rodzaju kuchni przemysłowej, gdzie wiele osób jednocześnie uderza do tych samych modeli, potrzebujesz vLLM. Inna analogia: możesz być zadowolony z gruchota, który dowiezie cię z punktu A do B, nawet wolniej i z dziwnymi dźwiękami. Ale gdy zmuszą cię, byś tym samym autem jechał autostradą z limitem 300 mil na godzinę, pojawią się problemy. vLLM pozwala uruchamiać silniki z dużo wyższą przepustowością, żeby wielu ludzi mogło korzystać jednocześnie.
Warstwa gateway: LiteLLM
Przedostatnia warstwa to gateway, np. LiteLLM. Wyobraź sobie centralkę telefoniczną. Jeśli chcesz obsługiwać modele lokalne przez czat, Open WebUI, agentów kodujących równolegle, agentów działających w tle albo automatyzacje w lokalnie hostowanym n8n — wszystko może przechodzić przez tego pośrednika. Jego zaleta to tzw. API zgodne z OpenAI, dzięki czemu jeden backend rozmawia z setkami modeli. Zamiast za każdym razem od nowa pobierać i przełączać model, masz warstwę pośrednią zajmującą się orkiestracją. Chcesz przejść z Qwena na Gemmę? Wystarczy przepiąć jeden „kabel” na drugi. Chodzi o to, by być maksymalnie zwinnym.
Prywatna sieć mesh: Tailscale
Zanim dojdziemy do ostatniej warstwy, kilka pojęć. Pierwsze to prywatny mesh — dzięki niemu mam dostęp do dashboardu działającego na moim Mac Mini. Robi to Tailscale: prywatna, szyfrowana sieć, w której mam jeden centralny hub i wchodzę na każde urządzenie tak, jakby stało w tym samym pokoju. Zamiast przekierowywać porty czy hostować serwer, który ktoś mógłby skompromitować, wszystkie urządzenia rozmawiają ze sobą potajemnie, niewidocznie dla innych.
Lubię Tailscale też z powodu ceny (bez żadnej afiliacji): plan osobisty jest całkowicie darmowy i daje nieograniczoną liczbę urządzeń oraz do sześciu użytkowników — dla małych firm to aż nadto. Instalacja jest banalna. W aplikacji, w zakładce urządzeń, widzę iPhone, stary laptop, Mac Mini i ten laptop — wszystkie połączone. Gdy z telefonu uruchomię czat na Qwen 14B i wyślę „Jak się masz?”, żądanie leci zaszyfrowane wprost do Mac Mini, który uruchamia inferencję i bezpiecznie odsyła odpowiedź na telefon. Całą sieć bierzesz ze sobą w drogę i możesz nawet udostępnić ją komuś.
Najlepsze modele open source i podział zadań
Od lewej do prawej: Gemma od Google — przyzwoity model, ale bywa dziwnie restrykcyjny, potrafi zablokować całkowicie normalne, legalne rzeczy. Przy modelach chińskich powiem głośno to, co inni przemilczają: naprawdę wyprzedzają sporą część rynku. Qwen, GLM, Kimi — wypuszczają nowe wersje bez przerwy, ich okna kontekstu sięgają miliona tokenów, a koszt hostowania wersji skwantyzowanych coraz niższy. DeepSeek dał nam swego czasu „moment DeepSeeka”, w którym open source na dobre wszedł do rozmowy. MiniMax ciekawie oferuje alternatywę dla ElevenLabs — przy klonowaniu głosu ma unikalne cechy.
Moi faworyci: modele Qwen i MiniMax dają świetne opcje kodowania agentowego, a GLM sprawdza się jako koń roboczy. Możesz łączyć: model zamknięty zajmuje się szczegółowym planowaniem, przeglądem błędów i testowaniem, a drobne zadania (zmień nazwy tych plików, znajdź ten plik) oddajesz koniowi roboczemu. Dzięki temu oszczędzasz koszty i tokeny.
(Informacja dodatkowa: „grep” to standardowe narzędzie do wyszukiwania wzorców w plikach — autor mówi o nim, wspominając szukanie plików.)
Możesz testować przed zakupem. Przez Open Router podłączasz pięć modeli i sprawdzasz je na dziesięciu zadaniach, żeby zobaczyć, które radzą sobie najlepiej na twoich workflow. Dopiero wtedy decydujesz, co zasługuje na stałe miejsce na lokalnym sprzęcie.
Podpięcie open source pod harness Claude Code
Prosimy: „Claude Code integration, Open Router docs.” Pierwszy link to integracja z Claude Code. W nowej sesji Claude Code mówię: „Chcę używać API Open Routera natywnie przez Claude Code, przeczytaj dokumentację, w razie potrzeby rozprosz podagentów i stwórz pełny plan komunikacji przez API — może przez przełączanie modelu na alias o nazwie »open source«.” Podaję link, Claude używa web fetch, po kilku minutach wraca z planem.
Jednym z rozwiązań jest utworzenie trybu „claude OS”: wybierasz go, gdy chcesz działać na modelach open source, a zwykłego „claude”, gdy chcesz standardowych modeli. Wybieram Kimi K3 i decyduję, jak obsłużyć klucz API Open Routera — można przez keychain albo plik z sekretami; dla prostoty użyję pliku i izolacji. Po kilkunastu minutach wszystko jest gotowe. Powstaje skrót o nazwie DSP-OS — DSP oznacza „dangerously skip permissions”, czyli tryb YOLO harnessa Claude Code. W nowym terminalu wpisuję DSP-OS, otwiera się Claude korzystający z Moonshot Kimi K3.
(Informacja dodatkowa: „dangerously skip permissions” wyłącza pytania o zgodę na akcje — wygodne, ale ryzykowne; agent może wykonać operacje bez potwierdzenia.)
Żeby zmienić model, wpisuję ten sam skrót z nazwą modelu — powstał też skrót DSP-OSG dla GLM 4.6. Gdy proszę „zbuduj mi aplikację kółko i krzyżyk”, żądanie leci do API Open Routera, model wchodzi w tryb planowania i pożycza harness Claude Code — masz to, co najlepsze z obu światów. Możesz przetestować model przy niższej stawce inferencji, zanim zdecydujesz się pobrać go na sprzęt. Na dole widać uruchamiane agenty i podagenty — mimo że to nie model Claude, dzięki harnessowi ma dostęp do wszystkich narzędzi, które kojarzymy z modelami zamkniętymi.
Kluczowe pojęcia w pigułce
Parametry. Zwykle liczone w miliardach. W przybliżeniu to miernik tego, jak zdolny jest model. Kimi K3 ma prawie 2,8 biliona parametrów w pełnej skali — uruchamianie tego w domu mogłoby kosztować ponad 10 tys. dolarów miesięcznie za sam prąd, nie licząc sprzętu. Kompresja czyni modele mniej zdolnymi, ale dziś model 14B, 27B czy 50B często wystarcza do codziennej pracy. Reguła kciuka: weź liczbę parametrów, podziel z grubsza przez dwa — to przybliżona ilość pamięci potrzebnej do swobodnego uruchomienia. Model 70B potrzebuje 35–40 GB RAM, 120B — prawie 60, a 14B — 5–7 GB, co bywa wykonalne na skromnym sprzęcie.
„4-bit” / kwantyzacja / kompresja. „4-bit” to w przybliżeniu miernik kwantyzacji, a kwantyzacja to miernik kompresji. Wyobraź sobie bardzo mądry mózg, którego wiedzę i wierność stopniowo kompresujesz — to jak rozdzielczość obrazu czy filmu: 4K, 1080p, 720p, a przy 480p robi się już nieciekawie. Masz 16-bit, 8-bit, 4-bit i niżej. Poniżej 1 bit „przekompresowujesz” mózg tak, że wiele inteligencji i zdolności (np. używania narzędzi, nawet ze świetnym harnessem) zostaje mocno okrojone. Nie ma sensu wchodzić w konkretne algorytmy kompresji — wiedz tylko, że to różne warianty. Cel przy pracy lokalnej: znaleźć najmniejszą kwantyzację najmniejszego modelu, który wciąż przechodzi twoje testy.
GGUF i MLX. GGUF to uniwersalny paszport — działa niemal wszędzie, w dziewięciu przypadkach na dziesięć z llama.cpp, czyli z Ollamą i LM Studio. MLX to paszport natywny dla Apple — ten sam model będzie działał znacznie lepiej, bo jest zoptymalizowany pod Apple Silicon. Reguła: jeśli nie pracujesz na Apple, nie masz po co szukać MLX. Dla większości modeli na Hugging Face znajdziesz odpowiednik MLX obok GGUF, choć niektóre mają tylko wersję ogólną. (Uwaga redakcyjna: w tym fragmencie automatyczny transkrypt miejscami myli GGUF z MLX — obowiązuje reguła: GGUF działa wszędzie, MLX tylko na Apple.)
KV cache. Gdy zaczynasz rozmowę, masz czyste biurko. Z każdą kolejną wymianą, zwłaszcza gdy rozmowa wielotorowa wywołuje narzędzia lub używa harnessa z rozbudowanym promptem systemowym (jak agent Hermes), biurko zapełnia się kontekstem. Trzy sposoby optymalizacji: (1) krótszy prompt systemowy agenta — po przycięciu ogromnego promptu Hermesa odpowiedź na „cześć” spadła u mnie z 2 minut do 30 sekund; (2) mniejszy kontekst — nie pisz eseju tam, gdzie nie trzeba; (3) kwantyzacja/kompresja samego cache — np. po 20 wiadomościach podsumowujesz je do jednej, którą niesiesz dalej.
Sparse attention. Spopularyzowany przez model MiniMax. Standardowy model czyta każde słowo każdej części rozmowy przez cały czas. Sparse attention wybiera, które tokeny z przeszłości są najistotniejsze — jest znacznie oszczędniejszy tokenowo i łagodzi problemy wydajnościowe większych modeli.
Tokeny na sekundę. Przepustowość pamięci to jak rura: jej szerokość decyduje, jak duże bloki i jak szybko przez nią przejdą. Mniejsze bloki (mniejsze „bity”) biegną szybciej. Duże bloki w wąskiej rurze dają 5–10 tokenów na sekundę — bardzo wolno, jakbyś dostawał pięć słów na minutę. Przy 60–70 tokenach na sekundę akapit pojawia się w 10–15 sekund. Bardziej skwantyzowany model daje więc większą zwinność i lepsze doświadczenie na twoim sprzęcie.
Harnessy — więcej opcji
Poza połączeniem Claude Code z Open Routerem możesz podpiąć Ollamę i używać tego harnessu lokalnie bez Open Routera. Możesz użyć harnessu Codex, Gemini, a także harnessów open source jak pi.dev — bardzo minimalistycznego, elastycznego frameworka, w którym budujesz kończyny podpinane do wybranego mózgu. Ustawiasz go, wklejając komendę curl do terminala, albo — jak ja — dajesz Claude Code lub Codex link, każesz przeczytać dokumentację, rozproszyć podagentów i skonfigurować pod twój system.
Klucz: początkowo taki harness nie będzie tak dopracowany jak Claude Code czy Codex, ale to będzie twój harness. Monitorujesz wydajność i wciąż dajesz modelowi feedback, by go poprawiał — po 5–15 iteracjach może osiągnąć optimum. Główny kompromis: przy modelach zamkniętych inżynieria harnessu jest zrobiona za ciebie i stale aktualizowana. Przy pi.dev, gdy wychodzą nowe modele, będziesz musiał go stopniowo dostrajać, bo każdy model ma nieco inne zachowania i wzorce wywoływania narzędzi.
Ostatni krok: budowa centrum dowodzenia (ODS)
Frameworków jest wiele; pokażę jeden, który u mnie zadziałał świetnie. Szukając „ODS GitHub”, trafisz na Osmantic ODS — nowsze repo autorstwa Ahmeda Ozmana. Jest naprawdę utalentowany w tematyce open source i udostępnił całe centrum dowodzenia, na którym zbudowałem swoje (Osmantic).
Tą samą techniką co wcześniej — podając repo, strony i dokumenty swojemu modelowi — bierzesz link do GitHuba i prosisz model, żeby (1) sprawdził i zaudytował repo, a potem (2) rozproszył podagentów, którzy zaplanują wdrożenie na twoim komputerze. Ja powiedziałem: „Rozprosz podagentów, żeby przeczytali to repozytorium i wróciły z kompleksowym planem, jak postawić to lokalnie na naszym systemie z pobranymi modelami Qwen.” Model robi web search, przechodzi przez całe repo, wraca z wnioskami: mamy model MLX, więc trzeba upewnić się, że współpracuje z serwerami llama i rozwiązać ewentualne problemy. Nawet jeśli jesteś nietechniczny, zwykle wystarczy rozmawiać z modelem prostym językiem i dojść do drogi najmniejszego oporu — resztę wykona za ciebie.
Uruchamiałem to potajemnie przez cały czas nagrywania filmu — zajęło około 45 minut z kilkoma pytaniami o preferencje. Po konfiguracji wchodzę pod lokalny adres, nazywam platformę (MarkX ODS), podaję użytkownika, klikam „zrób wszystko” i „zakończ” — i mam dashboard. Różnice względem tego z początku: nie ma logo w lewym górnym rogu; wszystkie funkcje włączyłem, rozmawiając z Claude Code; zamiast domyślnego modelu używa tego pobranego wcześniej. Mam pełny wgląd w to, co dzieje się w systemie, mogę instalować rozszerzenia i dodawać integracje — i stopniowo rozbudować to do poziomu tamtego zaawansowanego setupu. Możesz to potem połączyć („zfrankensteinować”) z innymi frameworkami we własną, jedyną w swoim rodzaju wersję.
Zakończenie
Mam nadzieję, że ten przegląd dał ci pełne „TL;DR” tego, jak przejść od nieumiejętności korzystania z modeli lokalnych do aktywnego i skutecznego ich używania drogą najmniejszego oporu. Przygotowałem też obszerny przewodnik po lokalnej inżynierii AI, dokumentujący wszystko, co przeczytałem i przetestowałem, składając własny sprzęt przez ostatnie półtora miesiąca — dostępny za darmo pod drugim linkiem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Lokalne AI jako polisa ubezpieczeniowa, nie zamiennik
Na czym polega: Modele open source nie dorównują czołówce, ale dla wielu codziennych zadań są „wystarczająco dobre”. Warto je znać jako redundancję na wypadek utraty dostępu, wzrostu cen lub wymogów prywatności.
Jak stosować: Zidentyfikuj zadania powtarzalne i mniej wymagające (triaż maili, RAG po dokumentach, drobne przekształcenia plików) i przenieś je lokalnie, a modele zamknięte zostaw do najtrudniejszej pracy.
Na co uważać: Nie oczekuj jakości absolutnej czołówki. Traktuj to jako uzupełnienie, nie pełne zastąpienie — inaczej rozczarujesz się przy złożonych zadaniach.
2.Cztery realne powody: dostawca, koszt, prywatność, agenci w tle
Na czym polega: Ryzyko nagłej utraty modelu (vendor risk), koniec subsydiów i groźba wielokrotnego wzrostu rachunków, brak wysyłania wrażliwych danych oraz tania praca agentów działających 24/7.
Jak stosować: Policz swój realny miesięczny koszt modeli zamkniętych i oszacuj, ile z tego to zadania w tle, które mógłbyś przenieść na prąd zamiast API. Dane wrażliwe (zdrowie, DNA, dokumenty firmowe) przetwarzaj lokalnie.
Na co uważać: „Lock-in” jest realny — jeśli cała firma stoi na jednej platformie, migracja przy wzroście cen zajmie miesiące. Buduj zwinność, zanim będzie za późno.
3.Pięciowarstwowy schemat ekosystemu to mapa całości
Na czym polega: Sprzęt → modele (open weight) → silnik inferencji (llama.cpp/vLLM) → gateway (LiteLLM) → interfejs (Open WebUI), a na wierzchu harness dający modelowi „kończyny”.
Jak stosować: Zanim cokolwiek zainstalujesz, umieść każdy element w tej mapie — wtedy wiesz, co za co odpowiada i co wymienić, gdy coś nie działa.
Na co uważać: To sam model bez harnessu jest tylko „mózgiem w słoiku”. Magia Claude Code i Codex to symbioza modelu z narzędziami, nie sam model.
4.Użyj modelu zamkniętego jako wykonawcy konfiguracji
Na czym polega: Claude Code / Codex potrafią przeanalizować twój sprzęt, dobrać modele, pobrać je, naprawić zależności (np. Python) i połączyć z interfejsem.
Jak stosować: W terminalu podawaj proste polecenia po ludzku („sprawdź moją specyfikację i powiedz, co uruchomię”). Podawaj linki do repozytoriów i dokumentacji i każ rozpraszać podagentów do analizy.
Na co uważać: Tryb „dangerously skip permissions” (DSP) uruchamia agenta bez pytania o zgodę — wygodny, ale ryzykowny; używaj świadomie i w izolowanym środowisku.
5.Open Router do testów, Hugging Face do pobierania
Na czym polega: Open Router to jeden most do setek modeli (z rankingami i publicznym API) — świetny do testowania. Hugging Face to repozytorium, z którego modele faktycznie pobierasz.
Jak stosować: Najpierw przetestuj kilka modeli na swoich realnych workflow przez Open Router („try before you buy”), a dopiero zwycięzców pobierz z Hugging Face na stałe.
Na co uważać: Open Router serwuje, ale nie pobiera. Nie myl ról tych platform i pamiętaj, że rankingi to punkt wyjścia, nie wyrok — liczy się wynik na twoich zadaniach.
6.Dobierz model do sprzętu według reguły „parametry ÷ 2”
Na czym polega: Liczba parametrów w przybliżeniu oddaje zdolność modelu, a jej połowa (w GB) to zgrubne zapotrzebowanie na pamięć. 70B ≈ 35–40 GB, 14B ≈ 5–7 GB.
Jak stosować: Oszacuj, ile pamięci realnie masz do dyspozycji (nie z pudełka!), i wybierz największy model mieszczący się poniżej ~50% pamięci.
Na co uważać: Nie licz całej deklarowanej pamięci — inne aplikacje ją zajmują. Przekroczenie ~50% powoduje problemy, zwłaszcza przy równoległych zadaniach.
7.Znajdź najmniejszą kwantyzację, która nadal przechodzi testy
Na czym polega: Kwantyzacja („bity”) to kompresja modelu — jak rozdzielczość obrazu. Poniżej 1 bita model traci zdolność rozumowania i używania narzędzi.
Jak stosować: Szukaj najmniejszej kwantyzacji najmniejszego modelu, który wciąż zdaje twoje testy zadaniowe — to daje najlepszą prędkość (tokeny/s) przy akceptowalnej jakości.
Na co uważać: Zbyt agresywna kompresja („przekompresowany mózg”) psuje działanie nawet z dobrym harnessem. Nie goń za rozmiarem kosztem użyteczności.
8.Na Apple wybieraj MLX, wszędzie indziej GGUF
Na czym polega: GGUF to uniwersalny format działający niemal wszędzie (llama.cpp, Ollama, LM Studio). MLX jest zoptymalizowany pod Apple Silicon i działa tam wyraźnie szybciej.
Jak stosować: Na Macu szukaj wersji MLX modelu; na innych platformach trzymaj się GGUF. Dla większości modeli na Hugging Face znajdziesz obie wersje.
Na co uważać: Nie każdy model ma wariant MLX — czasem jest tylko wersja ogólna. Nie zakładaj z góry, że MLX istnieje dla twojego modelu.
9.Optymalizuj KV cache, by przyspieszyć lokalne modele
Na czym polega: Kontekst kumuluje się z każdą turą rozmowy. Trzy dźwignie: krótszy prompt systemowy, mniejszy kontekst wejściowy, kompresja/kwantyzacja cache (np. podsumowanie ostatnich wiadomości).
Jak stosować: Zdiagnozuj prompt systemowy agenta i przytnij, czego nie potrzebujesz — autor zszedł z 2 minut do 30 sekund na odpowiedź „cześć”. Po dłuższej rozmowie streszczaj historię.
Na co uważać: Nadmierne przycinanie promptu może odebrać agentowi ważne instrukcje. Tnij to, co zbędne, nie to, co definiuje zachowanie agenta.
10.Zbuduj centrum dowodzenia z gotowego repo (ODS) i iteruj
Na czym polega: Zamiast składać wszystko ręcznie, podajesz modelowi gotowe repozytorium (np. Osmantic ODS), każesz zaudytować i wdrożyć — konfiguracja zajmuje ok. 45 minut.
Jak stosować: Podaj link do repo, poproś o audyt i plan wdrożenia dopasowany do twoich pobranych modeli, a potem rozwijaj dashboard, dogadując z modelem kolejne funkcje i integracje.
Na co uważać: Własny harness/setup początkowo będzie mniej dopracowany niż gotowe Claude Code — wymaga kilku-kilkunastu iteracji feedbacku. Traktuj to jako proces, nie jednorazowe kliknięcie.