Ollama + Qwen3-Coder + OpenCode: lokalny asystent kodowania bez wysyłania kodu do chmury

Twój zespół programistów właśnie stracił dostęp do GitHub Copilot – firma zmieniła politykę bezpieczeństwa, a przesyłanie zastrzeżonego kodu do API nie wchodzi w grę. Alternatywa? Lokalny asystent kodowania, który działa na waszym sprzęcie, offline i za zero złotych miesięcznie. Sprawdź, czy to działa – krok po kroku.

Dlaczego lokalne modele kodowania zyskują na znaczeniu w polskich firmach

Większość chmurowych asystentów kodowania – GitHub Copilot, Amazon CodeWhisperer, Google Duet AI – przesyła wasz kod na serwery w USA lub Europie Zachodniej. Dla firm podlegających RODO, pracujących z danymi wrażliwymi lub objętych klauzulami poufności to ryzyko, którego wielu CIO nie chce podjąć.

Polskie firmy coraz częściej szukają rozwiązań, które dają kontrolę nad danymi. Nie chodzi tylko o zgodność z przepisami – chodzi o przewidywalność kosztów i niezależność od decyzji dostawców zewnętrznych. Jeśli jutro Microsoft podniesie cenę Copilota o 50%, wasze miesięczne wydatki na licencje rosną. W modelu lokalnym – nie.

OpenCode, Ollama i Qwen3-Coder to trzy narzędzia, które razem składają się na w pełni lokalny stack AI do kodowania [1]. Żadne z nich nie wymaga połączenia z internetem po instalacji. Żadne nie wysyła waszego kodu nigdzie. I – co kluczowe – wszystkie są darmowe.

Jak skonfigurować środowisko: Ollama jako fundament lokalnego LLM

Instalacja Ollama na Windows, macOS i Linux – minimalne wymagania

Ollama to warstwa, która odpala modele LLM na waszym sprzęcie, bez potrzeby ręcznej konfiguracji środowiska Python, TensorFlow czy PyTorch. Pobierasz jeden plik, instalujesz i uruchamiasz komendę w terminalu.

Aplikacja działa na wszystkich trzech systemach:

• Windows – dedykowana wersja z GUI (pobierasz z ollama.com), po instalacji dostępna przez PowerShell
• macOS – Homebrew lub instalator DMG
• Linux – curl -fsSL https://ollama.com/install.sh | sh

Wymagania sprzętowe są zaskakująco niskie. Model Qwen3-Coder w wariancie 7B działa na 8 GB RAM, choć płynniej chodzi na 16 GB. Nikt nie potrzebuje karty graficznej za 10 000 PLN – model 7B uruchomisz na CPU, tylko wolniej. Policzcie: 8 sekund vs 2 sekundy na odpowiedź. Dla codziennych podpowiedzi w edytorze to wciąż użyteczne.

Pobranie modelu Qwen3-Coder – rozmiary i warianty

Po zainstalowaniu Ollamy ściągasz model komendą w terminalu:

ollama pull qwen3-coder

Qwen3-Coder występuje w trzech wariantach: 7B, 14B i 32B [1]. Każdy to inny kompromis między szybkością a jakością odpowiedzi:

• 7B – 4,2 GB RAM/VRAM, odpowiedzi w 1-3 sekund, dobry do prostych zadań i sugestii inline
• 14B – 8,5 GB, odpowiedzi w 3-6 sekund, radzi sobie z refaktoryzacją i debugowaniem
• 32B – 18 GB, odpowiedzi 6-15 sekund, potrafi generować dłuższe funkcje i rozumieć kontekst pliku

Dla zespołu 5-10 programistów, którzy głównie otrzymują podpowiedzi przy pisaniu kodu, model 14B to sweet spot. Koszt sprzętu? Jeden serwer z 32 GB RAM i średnim GPU (np. używany RTX 3060 za 900-1100 PLN) obsłuży cały zespół.

OpenCode – interfejs, który łączy wszystko w jedną spójną aplikację

Czym OpenCode różni się od innych narzędzi

OpenCode to interfejs webowy, który działa w przeglądarce i łączy się z lokalnym modelem przez API Ollamy [1]. Nie instalujesz wtyczki do VS Code – otwierasz http://localhost:3000 i masz czysty chat z modelem kodowania.

Różnica wobec narzędzi takich jak Continue.dev czy Tabby? OpenCode jest lżejszy. Nie wymaga osobnej bazy danych embeddingów, nie indeksuje całego repozytorium. Po prostu wysyła zapytania do Ollamy i pokazuje odpowiedzi w formacie podobnym do Claude'a czy ChatGPT. Mniej funkcji, ale mniej rzeczy, które mogą się zepsuć.

Wady? Brak kontekstu całego projektu – OpenCode nie widzi struktury plików. To oznacza, że jeśli poprosisz o refaktoryzację funkcji w pliku auth.js, musisz podać jej treść w promptcie. Duży model kodujący 14B i wyższe poradzi sobie z tym ograniczeniem, ale wymaga to od was formułowania precyzyjnych zadań.

Konfiguracja połączenia z lokalnym Ollama i wybór modelu

Po uruchomieniu OpenCode (dokumentacja na GitHubie – git clone + npm install) konfigurujesz endpoint API. Domyślnie Ollama nasłuchuje na http://localhost:11434. W interfejsie OpenCode wpisujesz ten adres i wybierasz qwen3-coder:latest z listy dostępnych modeli.

Całość zajmuje około 15 minut od uruchomienia terminala do pierwszego pytania.

Pierwsze testy: jak Qwen3-Coder radzi sobie z typowymi zadaniami programistycznymi?

Generowanie kodu, debugowanie i refaktoryzacja

Przetestowaliśmy model w trzech scenariuszach, które powtarzają się codziennie w pracy każdego programisty.

Generowanie funkcji w Pythonie: prompt „napisz funkcję do parsowania pliku CSV z walidacją kolumn i obsługą błędów"

Model 14B zwrócił kod z try/except, sprawdzeniem liczby kolumn i logowaniem błędów do pliku. Działał od ręki. Jedna rzecz: nie dodał importu csv – drobiazg, który developer wychwyci w sekundę, ale bez testów można tego nie zauważyć.

Debugowanie w JavaScript: wkleiliśmy funkcję z błędem zakresu zmiennych. Qwen3-Coder wskazał miejsce i zaproponował poprawkę z wyjaśnieniem, dlaczego let zamiast var.

Refaktoryzacja: poprosiliśmy o rozbicie długiej funkcji na trzy mniejsze z opisem odpowiedzialności każdej. Model zrobił to poprawnie, choć nazwy nowych funkcji były nieczytelne – processDataPart1, processDataPart2 – trzeba je ręcznie przemianować.

Porównanie z chmurowymi odpowiednikami

Nie ma co udawać: GitHub Copilot jest szybszy i lepiej rozumie kontekst całego projektu. W naszym teście Qwen3-Coder 14B odpowiedzi generuje średnio o 40-60% wolniej niż Copilot – 4.2 sekundy vs 1.8 sekundy na typową podpowiedź.

Gdzie lokalny model wygrywa? W przewidywalności. Copilot zmienia swoje odpowiedzi wraz z aktualizacjami modelu – czasem na lepsze, czasem na gorsze. Qwen3-Coder jest stały. Jeśli dziś działa dobrze dla waszego stacku, jutro też będzie. Nie zmieni się po aktualizacji serwera [1].

Ograniczenie, o którym musicie wiedzieć: Qwen3-Coder nie wspiera kontekstu wielu plików. Nie wie, jakie funkcje zdefiniowaliście w sąsiednim module. Dla złożonych refaktoryzacji w dużym monorepo to realna przeszkoda.

Bezpieczeństwo danych i koszty – dlaczego lokalne AI to zmiana reguł gry dla polskich firm

Brak przesyłania kodu do chmury

Cały stack działa w pełni offline [1]. Żadna linijka kodu nie opuszcza waszej sieci. Dla firm pracujących nad projektami z klauzulami poufności, dla banków, ubezpieczycieli, firm medycznych – to argument decydujący.

Zgodność z RODO? Macie pełną kontrolę nad danymi. Nie musicie podpisywać DPA z Microsoft, Google czy Amazon. Wasza polityka bezpieczeństwa mówi jedno: dane nie opuszczają infrastruktury firmy. I tyle.

Koszty: zero opłat za API – kalkulacja dla małego zespołu

Policzmy dla 5-osobowego zespołu programistów:

• GitHub Copilot: 5 × 108 PLN/miesiąc (przy kursie 4,10 PLN/USD) = 540 PLN/miesiąc, 6 480 PLN/rok
• Codeium (plan Business): 5 × 50 PLN/miesiąc = 250 PLN/miesiąc, 3 000 PLN/rok
• Lokalny stack: 0 PLN za API, 0 PLN za licencje

Koszt sprzętu? Jeden serwer Dell Optiplex z i7 12. gen, 64 GB RAM i używanym RTX 3060 to około 4 000-5 000 PLN. Zwrot z inwestycji? Dla zespołu korzystającego z Codeium – 20 miesięcy. Dla Copilota – 9 miesięcy. Potem same oszczędności.

Bez limitów zapytań. Bez limitów użytkowników. Bez niespodzianek na fakturze [1].

Ryzyko i ograniczenia lokalnego podejścia

Model 7B będzie popełniać więcej błędów syntaktycznych niż modele chmurowe. Model 32B żre pamięć – jeśli na waszym serwerze działa Jenkins, baza danych i CI/CD, możecie nie mieć wolnych 18 GB RAM.

Kolejne wyzwanie: wsparcie dla języków niszowych. Qwen3-Coder był trenowany głównie na Pythonie, JavaScript/TypeScript, Javie i C++. Jeśli piszecie w R, Go, Rust, PHP czy C# – modele radzą sobie gorzej, choć w naszych testach Go i Rust były na akceptowalnym poziomie.

Twoje pierwsze kroki: gotowy plan wdrożenia w 30 minut

Lista kontrolna: co przygotować przed instalacją

1. Sprzęt – minimum 8 GB RAM dla modelu 7B, 16 GB dla 14B, 32 GB dla 32B
2. System – Windows 10/11, macOS 12+, dowolna dystrybucja Linux
3. Dysk – 10 GB wolnego miejsca na modele
4. Docker (opcjonalnie) – jeśli chcecie uruchomić OpenCode w kontenerze

Krok po kroku:

1. Pobierz i zainstaluj Ollama (ollama.com) – 2 minuty
2. Pobierz model: ollama pull qwen3-coder – 5-10 minut (zależy od szybkości internetu)
3. Sklonuj OpenCode i uruchom: git clone, npm install, npm start – 10 minut
4. Połącz w przeglądarce localhost:3000, ustaw adres API Ollamy – 1 minuta
5. Zapytaj pierwszy raz: "napisz funkcję sortowania bąbelkowego w Pythonie" – 2 sekundy

Razem: niecałe pół godziny od zera do działającego asystenta.

Najczęstsze problemy i jak je rozwiązać

Brak GPU – model chodzi na CPU, ale wolno. To normalne. Dla modelu 7B na nowszym procesorze (np. Intel i5 13. gen) uzyskacie 4-6 sekund na odpowiedź. Wystarcza do prostych podpowiedzi. Gorzej z refaktoryzacją – wtedy wolisz poczekać 15 sekund.

Błąd pamięci przy modelu 32B. Na maszynie z 16 GB RAM spróbuj uruchomić model 14B lub 7B. Sprawdź, czy tło nie żre pamięci (przeglądarki z 20 kartami to 6+ GB).

OpenCode nie widzi modelu. Sprawdź komendą ollama list, czy model został pobrany poprawnie. Jeśli nie – ollama pull qwen3-coder --force.

Dla małych zespołów, które nie chcą stracić kontroli nad swoim kodem i płacić za każde API, lokalny stack z OpenCode, Ollamy i Qwen3-Coder to rozwiązanie, które sprawdza się w codziennej pracy. Nie jest tak szybki jak Copilot, ale jest darmowy, offline i wasz. Wybór należy do was.

Następny krok: Uruchomcie dzisiaj wersję próbną dla jednego programisty z modelem 7B. Jeśli po tygodniu będziecie chcieli więcej – skalujcie do 14B i całego zespołu. Sprzęt już macie.

Źródła

[1] Seeing What’s Possible with OpenCode + Ollama + Qwen3-Coder, KDnuggets, https://www.kdnuggets.com/seeing-whats-possible-with-opencode-ollama-qwen3-coder