Lokalne modele LLM na Linuksie z Ollama — przewodnik i integracja z IDE (2026)

Uruchomienie własnego modelu językowego lokalnie daje trzy rzeczy, których nie zapewnia chmura: prywatność (kod nie opuszcza maszyny), brak kosztów per token i niezależność od limitów dostawcy. Najprostszą drogą na Linuksie jest Ollama — narzędzie, które pobiera, kwantyzuje i serwuje modele jednym poleceniem, wystawiając przy okazji API zgodne z OpenAI. Ten artykuł prowadzi przez cały proces: od instalacji, przez dobór modelu do posiadanej karty, aż po użycie modelu jako agenta do pisania kodu. Osobną, dużą część poświęcam temu, które IDE realnie współpracuje z modelem lokalnym — z konkretnym omówieniem VS Code, PyCharm, Antigravity, Cursora i Zeda.

Dla uziemienia teorii w liczbach w kilku miejscach posługuję się przykładem współczesnego laptopa deweloperskiego: NVIDIA RTX PRO 500 (Blackwell), 6 GB VRAM, 64 GB RAM. To dobra ilustracja typowej sytuacji — niewielki VRAM przy dużej ilości RAM systemowego.

Czym jest Ollama i jak działa

Ollama to lekki runtime do uruchamiania modeli LLM lokalnie. Pobiera gotowe, skwantyzowane modele z własnego rejestru, automatycznie wykrywa GPU (NVIDIA/AMD) i serwuje model przez lokalny serwer HTTP na porcie 11434. Najważniejsze: udostępnia endpoint zgodny z API OpenAI pod http://localhost:11434/v1, dzięki czemu większość narzędzi „mówiących po OpenAI" da się skierować na model lokalny.

Pod maską Ollama korzysta z llama.cpp i formatu GGUF oraz z kwantyzacji — kompresji wag modelu, która drastycznie zmniejsza zapotrzebowanie na pamięć kosztem niewielkiej utraty jakości. To dzięki niej modele rzędu 30B mieszczą się na kartach konsumenckich.

Instalacja na Linuksie

Oficjalny instalator wykrywa dystrybucję i konfiguruje usługę systemd:

curl -fsSL https://ollama.com/install.sh | sh

Po instalacji Ollama działa jako usługa w tle. Sprawdź status i wersję:

systemctl status ollama
ollama --version

Sterowniki GPU

• NVIDIA — potrzebne są zainstalowane sterowniki i CUDA. Ollama wykryje kartę automatycznie. Weryfikacja: nvidia-smi powinno pokazywać kartę.
• AMD — Ollama wspiera ROCm dla obsługiwanych kart Radeon.
• Tylko CPU — Ollama zadziała bez GPU, ale wolno (sensowne wyłącznie dla najmniejszych modeli).

Po uruchomieniu modelu sprawdzisz, czy faktycznie liczy na GPU:

ollama ps   # the PROCESSOR column shows the GPU-vs-CPU split

Pułapka z najnowszymi kartami. Najnowsze generacje GPU NVIDIA (Blackwell i nowsze) wymagają otwartych modułów jądra — na Ubuntu jest to pakiet nvidia-driver-<wersja>-open zamiast klasycznego nvidia-driver-<wersja>. Zainstalowanie zamkniętego wariantu kończy się tym, że karta w ogóle się nie inicjalizuje: w logach jądra pojawia się RmInitAdapter failed oraz komunikat „requires use of the NVIDIA open kernel modules", a nvidia-smi zgłasza brak urządzeń. Rozwiązaniem jest przełączenie na wariant -open i restart. Na laptopie z RTX PRO 500 (Blackwell) był to warunek konieczny, żeby Ollama liczyła na GPU zamiast na CPU.

Podstawowe komendy

ollama pull qwen2.5-coder:7b     # download a model
ollama run qwen2.5-coder:7b      # download (if needed) and run interactively
ollama list                      # list downloaded models
ollama ps                        # models currently loaded into memory
ollama rm qwen2.5-coder:7b       # remove a model
ollama show qwen2.5-coder:7b     # parameters, template, license

W trybie interaktywnym przydają się komendy zaczynające się od /, np. /bye kończy sesję, a /set parameter num_ctx 8192 zmienia długość kontekstu w locie.

Kwantyzacja i VRAM — fundament doboru modelu

Zanim wybierzesz model, zapamiętaj jedną zasadę, która decyduje o wszystkim: model powinien zmieścić się w całości w VRAM. Model w pełni załadowany na GPU działa 5–10× szybciej niż taki, który „przelewa się" do RAM systemowego. Przykład z praktyki: model 32B przy ~60 t/s w VRAM spada do ~1–2 t/s w momencie, gdy zacznie korzystać z RAM.

Kwantyzacja to dźwignia, którą dopasowujesz model do swojej karty:

Praktyczny domyślny wybór to Q4_K_M. Po Q5/Q8 sięgaj tylko wtedy, gdy masz zapas VRAM na wagi i jeszcze na kontekst (KV cache). Reguła nadrzędna: mniejszy model, który mieści się w pamięci, zwykle bije większy, który się przelewa.

Wyjątek: modele MoE i offload do RAM

Regułę „wszystko w VRAM" warto uzupełnić o modele MoE (Mixture of Experts), które mają dużą liczbę parametrów, ale na każdy token aktywują tylko ich ułamek. Przykładowo qwen3-coder:30b to 30 mld parametrów, z których aktywne jest tylko ~3 mld. Takie modele znoszą offload do RAM znacznie lepiej niż modele gęste, bo przez magistralę pamięci na token przechodzi tylko mała, aktywna część wag.

To otwiera furtkę na maszynach z małym VRAM, ale dużym RAM. Na wspomnianym laptopie (6 GB VRAM + 64 GB RAM):

• qwen2.5-coder:7b (~4,7 GB w Q4) mieści się w całości w 6 GB VRAM — działa szybko, w pełni na GPU.
• qwen3-coder:30b (~19 GB) nie zmieści się w 6 GB, ale dzięki 64 GB RAM da się go uruchomić z offloadem, a architektura MoE (3B aktywnych) sprawia, że prędkość pozostaje znośna.

Wniosek: przy zakupie/ocenie sprzętu duży RAM systemowy jest sensownym uzupełnieniem skromnego VRAM — pozwala sięgnąć po modele MoE, których dense'owy odpowiednik byłby nie do ruszenia.

Dobór modelu do klasy sprzętu

Zamiast jednego „najlepszego" modelu, dobierz go do ilości VRAM. Poniższe progi to praktyczne punkty wyjścia dla pracy nad kodem.

Klasa „mała" (≤ 8 GB VRAM, także laptopy)

Cel: sprawdzenie całego przepływu pracy i lekkie, codzienne zadania.

• 6–8 GB VRAM — qwen2.5-coder:7b (~4,7 GB w Q4). Najlepszy mały model do kodu w tym budżecie; bije starsze CodeLlama i DeepSeek-Coder w uzupełnianiu kodu.
• Tylko CPU / mało RAM — qwen2.5-coder:1.5b lub :3b. Będzie wolno, ale pozwoli przetestować integracje.

ollama run qwen2.5-coder:7b

Na tym etapie warto zweryfikować: czy model odpowiada sensownie, czy działa na GPU (ollama ps), jaka jest szybkość generowania i czy uda się podpiąć go pod edytor.

Klasa „średnia" (12–16 GB VRAM)

Wygodny zakres do realnej pracy nad kodem:

• qwen2.5-coder:14b (~10 GB w Q4) — solidny do codziennej pracy.
• devstral:24b — lokalny model agentowy od Mistrala, wymaga ≥16 GB VRAM, dobry do zadań agentowych.
• deepseek-coder-v2:16b (lite) — budżetowy wariant na karty ~12 GB.

ollama run qwen2.5-coder:14b

Klasa „duża" (24 GB+ VRAM)

Poziom, na którym lokalny model zaczyna realnie zastępować chmurę do agentowego pisania kodu. Liderem jest qwen3-coder:30b:

• architektura MoE 30B-A3B (z 30 mld parametrów aktywne jest tylko ~3 mld na token),
• ~16,5–18 GB w Q4_K_M — mieści się na karcie 24 GB z zapasem na kontekst,
• natywny kontekst 256K (rozszerzalny), trening pod zadania agentowe i natywne wywoływanie narzędzi (tool calling) — to kluczowe dla pracy jako agent.

ollama run qwen3-coder:30b

Warianty zależnie od karty:

• 24 GB (RTX 3090/4090) — qwen3-coder:30b w Q4_K_M, ~22–24 t/s, ~6 GB zapasu na KV cache.
• 32 GB (RTX 5090) — ten sam model w Q4 lub wyższej jakości Q5_K_M (~22 GB) z miejscem na długi kontekst.
• 48 GB+ (2× RTX 3090, A6000) — qwen3-coder:30b w Q8 albo cięższe modele; pełne qwen3-coder:480b realnie wymaga sprzętu serwerowego lub wersji hostowanej.

Mapa: VRAM → rekomendowany model do kodu

Uwaga o nazewnictwie. Rodzina qwen3-coder w Ollamie występuje wyłącznie jako MoE 30B i 480B — nie ma wariantu 7B. Do małego, szybkiego modelu należy użyć rodziny qwen2.5-coder (dostępne 0.5B / 1.5B / 3B / 7B / 14B / 32B). To częste źródło błędu pull model manifest: file does not exist.

Przegląd modeli do kodu (2026)

• qwen3-coder (30b / 480b) — aktualny lider lokalnego kodowania. Wersja 30B-A3B to najmocniejszy model agentowy, jaki większość ludzi uruchomi lokalnie. Tool calling, kontekst 256K.
• qwen2.5-coder (0.5b–32b) — najlepsza rodzina małych i średnich modeli do kodu. :32b jest blisko poziomu GPT-4o w benchmarku Aider. Wybór, gdy qwen3-coder:30b jest poza zasięgiem sprzętu.
• devstral:24b — lokalny model agentowy Mistrala, 128K kontekstu.
• deepseek-r1 / deepseek-coder-v2 — dobre do rozumowania nad trudnymi błędami i wariant budżetowy (16b lite) na karty 12 GB.

Strojenie i konfiguracja Ollama

Zachowanie serwera kontrolujesz zmiennymi środowiskowymi (dla usługi systemd ustaw je w pliku override):

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"   # Listen on the network too (be careful!).
Environment="OLLAMA_ORIGINS=*"            # Allow CORS requests (needed by some plugins).
Environment="OLLAMA_KEEP_ALIVE=30m"       # How long a model stays in memory.
Environment="OLLAMA_NUM_PARALLEL=2"       # Number of parallel requests.
Environment="OLLAMA_FLASH_ATTENTION=1"    # Save KV-cache memory.
Environment="OLLAMA_MODELS=/data/ollama"  # Where downloaded models are stored.

Po zmianie: sudo systemctl daemon-reload && sudo systemctl restart ollama.

Najważniejszy parametr przy pracy nad kodem to długość kontekstu (num_ctx). Domyślnie bywa niska, a agent potrzebuje dużego okna — zbyt mały kontekst powoduje ucinanie promptu systemowego i „zapętlanie się" agenta. Ustawisz ją per sesję (/set parameter num_ctx 32768) albo na stałe we własnym Modelfile:

FROM qwen3-coder:30b
PARAMETER num_ctx 32768

ollama create qwen3-coder-32k -f ./Modelfile

Możesz też nadpisać istniejący model tą samą nazwą (FROM qwen3-coder:30b + ollama create qwen3-coder:30b -f ./Modelfile) — Ollama użyje wspólnych warstw wag, więc nic nie pobiera się ponownie.

Ta zmiana jest trwała. Parametr num_ctx zostaje wpalony w definicję modelu w magazynie Ollamy (~/.ollama/models), a nie w plik Modelfile — ten jest potrzebny tylko w momencie ollama create i można go potem usunąć. Ustawienie przetrwa restart usługi i systemu. Podejrzysz je w każdej chwili poleceniem ollama show <model> --modelfile (zobaczysz linię PARAMETER num_ctx ...).

Uwaga: większy num_ctx zjada VRAM na KV cache. Na kartach z małym VRAM (np. 6 GB) rozsądny kompromis to 16384; przy większym oknie model zacznie przelewać się do RAM.

Które IDE współpracuje z modelem lokalnym

Poziom wsparcia różni się drastycznie między edytorami. Najpierw szybki werdykt, potem szczegóły.

VS Code — najlepsze wsparcie

VS Code ma najbogatszy ekosystem wtyczek łączących się z Ollamą bezpośrednio, bez tuneli i bez routowania przez chmurę:

• Continue — model-agnostyczne rozszerzenie do czatu, edycji i autouzupełniania. Natywnie obsługuje providera ollama. Najprostsze wejście.
• Cline i Roo Code — rozszerzenia zorientowane na agentowy przepływ pracy (planowanie, wykonywanie zmian w plikach, użycie narzędzi). Najlepiej wykorzystają model z tool callingiem, jak qwen3-coder:30b. Pamiętaj o num_ctx ≥ 32k, inaczej prompt systemowy agenta zostanie ucięty.

Konfiguracja Continue (plik ~/.continue/config.json; nowsze wersje używają config.yaml — oba działają):

{
  "models": [
    {
      "title": "Qwen2.5 Coder 7B",
      "provider": "ollama",
      "model": "qwen2.5-coder:7b",
      "apiBase": "http://localhost:11434"
    }
  ],
  "tabAutocompleteModel": {
    "title": "Qwen2.5 Coder 1.5B",
    "provider": "ollama",
    "model": "qwen2.5-coder:1.5b",
    "apiBase": "http://localhost:11434"
  }
}

Jawne apiBase jest zalecane zawsze — bez niego zdarzają się ciche błędy połączenia. Po wskazaniu modelu masz czat, inline edit (Ctrl+I) i autouzupełnianie z modelu lokalnego, w pełni offline po pobraniu modelu.

PyCharm / JetBrains — bardzo dobre wsparcie

W ekosystemie JetBrains są trzy sensowne drogi:

• Wbudowany AI Assistant — oficjalny asystent JetBrains obsługuje modele lokalne przez Ollamę. Ponieważ jest częścią IDE, zawsze jest zgodny z bieżącym buildem. Konfiguracja: Settings → Tools → AI Assistant → Providers & API keys → provider Ollama, URL http://localhost:11434 → Test Connection, następnie przypisanie modelu w sekcji Model Assignment. Ograniczenie: z modelami lokalnymi AI Assistant nie wywołuje narzędzi (MCP), więc nie posłuży jako pełny agent edytujący pliki.
• ProxyAI (dawniej CodeGPT) — otwartoźródłowa wtyczka z obsługą lokalnych modeli (Ollama, LM Studio, llama.cpp) oraz trybem agentowym.
• Continue — ma wtyczkę JetBrains, a jej konfigurację ~/.continue/config.json współdzielisz z VS Code.

Niuans zgodności wtyczek z najnowszymi IDE. Marketplace ukrywa wtyczki oznaczone jako niekompatybilne z bieżącym buildem. Na bardzo świeżych wydaniach (przykład: PyCharm 2026.2, linia build 262.*) wtyczka Continue potrafi w ogóle nie pojawiać się w wyszukiwarce Marketplace, dopóki autorzy nie rozszerzą zakresu zgodności. W takiej sytuacji sięgnij po wbudowany AI Assistant albo ProxyAI (które zwykle nadążają szybciej), użyj wersji z kanału EAP, zainstaluj wtyczkę „z dysku" po rozszerzeniu until-build, albo skorzystaj z odpowiednika w VS Code.

Tryb agentowy w terminalu — Aider

Niezależnie od edytora, do zadań „zrób całe zadanie za mnie" najpewniejszym narzędziem z modelami lokalnymi jest Aider — agent działający w terminalu (także w zakładce Terminal wewnątrz IDE). W przeciwieństwie do asystentów w edytorze, Aider sam odnajduje i edytuje pliki w repozytorium git, a każdą zmianę zapisuje jako osobny commit (łatwe cofanie przez /undo).

python -m pip install aider-install && aider-install

cd /path/to/your/git/repo
export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/qwen2.5-coder:7b   # note the ollama_chat/ prefix, not ollama/

Najważniejsze komendy w sesji:

Dla modeli lokalnych warto wcześniej zbudować wariant z większym kontekstem (patrz sekcja o num_ctx), np. qwen2.5-coder:7b-16k, i wskazać go Aiderowi.

Antigravity — brak natywnego wsparcia modeli lokalnych

Antigravity (IDE od Google) korzysta z kuratorowanej, zamkniętej listy modeli serwowanych przez Vertex Model Garden — m.in. Gemini 3.x, Claude (Opus/Sonnet) oraz GPT-OSS-120B. W praktyce:

• brak przycisku „Add Custom Model" i brak BYOK (Bring Your Own Key),
• brak konfiguracji endpointu zgodnego z OpenAI i brak możliwości wskazania localhost:11434,
• modeli z listy nie da się dodać, usunąć ani podmienić na własne.

Innymi słowy: lokalnej Ollamy nie podepniesz natywnie do Antigravity. Krążące w sieci przewodniki opisujące konfigurację Ollamy przez „provider OpenAI-compatible" w Antigravity są w większości nieaktualne lub błędne. Obejścia przez MCP czy proxy są nieoficjalne i zawodne.

Cursor — możliwe, ale kompromisowe

Cursor nie wspiera bezpośrednio modeli na localhost — kieruje żądania przez własne serwery, więc trzeba wystawić Ollamę publicznym tunelem HTTPS (ngrok/Cloudflare Tunnel) i wpisać URL w Settings > Models > Override OpenAI Base URL (z sufiksem /v1, dowolny niepusty klucz API). Dodatkowo Tab zawsze działa w chmurze, a tryb Agent bywa zabugowany. Do czatu i Cmd+K da się to skonfigurować, ale jako pełny lokalny agent Cursor się nie sprawdza.

Zed — warta poznania alternatywa

Zed to szybki, natywny edytor z wbudowaną obsługą Ollamy (provider lokalny w ustawieniach). Lekki i wydajny, dobra opcja do pracy z modelem lokalnym bez instalowania wtyczek.

Rekomendowana ścieżka krok po kroku

1. Instalacja i próba — zainstaluj Ollamę, upewnij się, że GPU jest widoczne (nvidia-smi, ollama ps), uruchom qwen2.5-coder:7b i przetestuj w terminalu, a następnie w VS Code + Continue lub PyCharm (AI Assistant/ProxyAI).
2. Praca nad kodem — na kartach 12–16 GB przejdź na qwen2.5-coder:14b lub devstral:24b; włącz tryb agentowy (Cline/Roo Code w VS Code albo Aider w terminalu).
3. Docelowy agent lokalny — na kartach 24 GB+ ustaw qwen3-coder:30b w Q4_K_M z powiększonym kontekstem; to najmocniejszy lokalny agent do kodu z tool callingiem. Na maszynach z małym VRAM, ale dużym RAM, ten sam model uruchomisz z offloadem (MoE znosi to dobrze).
4. Wybór edytora — do lokalnego agenta postaw na VS Code (najszersze wsparcie) lub PyCharm. Antigravity zostaw do jego modeli chmurowych, a Cursor rozważ tylko, jeśli zaakceptujesz tunel i ograniczenia.

Podsumowanie

Ollama na Linuksie to najprostsza droga do lokalnych modeli: jedna komenda instaluje runtime, kolejna pobiera i uruchamia model, a API zgodne z OpenAI otwiera integracje. Zacznij od qwen2.5-coder:7b na próbę, przejdź przez :14b/devstral na karcie 16 GB, a na karcie 24 GB+ ustaw qwen3-coder:30b jako docelowego lokalnego agenta — to dziś najmocniejszy model do kodu na sprzęcie konsumenckim, z tool callingiem i kontekstem 256K. Zasada sprzętowa: model powinien mieścić się w całości w VRAM (Q4_K_M jako domyślny balans), a wyjątkiem są modele MoE, które na maszynach z dużym RAM znoszą offload zaskakująco dobrze. Co do edytora — VS Code i PyCharm łączą się z Ollamą natywnie (Continue/AI Assistant/ProxyAI, a dla agenta Cline/Roo Code lub Aider). Antigravity nie obsługuje modeli lokalnych (zamknięta lista chmurowa), a Cursor wymaga tuneli i ma ograniczenia.

Referencje

• Ollama — oficjalna strona
• Ollama — biblioteka modeli
• Ollama — repozytorium na GitHubie
• Best Ollama Models: Coding, RAG & Agents — czerwiec 2026 (Morph)
• Ollama Models Cheat Sheet 2026 (ComputingForGeeks)
• Best Ollama Coding Models by NVIDIA RTX GPU: VRAM Tier Guide (haimaker.ai)
• QwenLM/Qwen3-Coder — repozytorium
• Run Qwen3-Coder 30B-A3B Locally — progi VRAM (RunAIatHome)
• NVIDIA — Open GPU Kernel Modules (GitHub)
• Continue — dokumentacja
• Continue — wtyczka JetBrains (Marketplace)
• ProxyAI — wtyczka JetBrains (Marketplace)
• Aider — strona projektu
• Local AI Coding Assistant: VS Code + Ollama + Continue (SitePoint)
• Using Ollama with VS Code, IntelliJ, and Eclipse (Medium)
• Can You Use Local Models (Ollama) with Antigravity? (Agentpedia)
• Cursor Forum — How can I use a local LLM on my desktop/AI computer?
• Zed — dokumentacja (AI / Ollama)