Najlepsze lokalne modele LLM do kodowania w 2026 (Ollama i inne) 

Ostatnia istotna aktualizacja: 28 października 2026. Co zmieniono: poprawiłem nazwy i tagi modeli, które nie istnieją w bibliotece Ollamy (np. qwen3-coder:8b i devstral:22b), zaktualizowałem rozmiary plików i okna kontekstu według ollama.com, dodałem wyniki SWE-bench z kart modeli, jawny wzór na zużycie pamięci (wagi + KV cache + bufor) oraz dobierak modelu z komendą do skopiowania. Usunąłem twierdzenia, których nie dało się potwierdzić źródłem.

Krótka odpowiedź (stan na 28 października 2026): przy 8 GB VRAM uruchomisz sensownie qwen2.5-coder:7b (plik 4,7 GB), przy 16 GB - gpt-oss:20b (14 GB), a od 24 GB najmocniejszym lokalnym modelem do kodowania jest qwen3.6:27b (19 GB), który według karty modelu osiąga 77,2% w SWE-bench Verified. Przy 64 GB i więcej pamięci w grę wchodzi qwen3-coder-next (52 GB, 80B parametrów, 3B aktywnych). O tym, co się zmieści, decydują jednak nie same wagi, tylko suma: wagi + pamięć kontekstu (KV cache) + bufor - i właśnie tę sumę liczy dobierak poniżej.

Druga rzecz, o której większość poradników milczy: Ollama na kartach z mniej niż 24 GiB VRAM domyślnie ustawia kontekst na zaledwie 4 tys. tokenów (dokumentacja Ollamy), a do agentów i narzędzi kodujących zaleca co najmniej 64 tys. Model, który „mieści się” przy 4k, przy 64k potrafi wypaść z GPU.

Dobierak modelu: wpisz sprzęt i język, dostaniesz model i komendę

Narzędzie liczy pamięć jawnym wzorem (opisanym w następnej sekcji) dla 13 modeli dostępnych w bibliotece Ollamy i wybiera ten z najlepszym wynikiem benchmarku agentowego, który zmieści się w całości w pamięci GPU. Dla Pythona ranking opiera się na SWE-bench Verified, dla innych języków - na SWE-bench Multilingual. Wszystko liczy się w przeglądarce, nic nie jest wysyłane.

Jak czytać wynik: rekomendacja to model z najwyższym wynikiem, który mieści się w całości w VRAM (lub w puli pamięci Maca). Modele, które zmieszczą się tylko częściowo, z przerzuceniem warstw do zwykłego RAM-u, dobierak pokazuje osobno - działają, ale wyraźnie wolniej. Po uruchomieniu zawsze sprawdź ollama ps: kolumna PROCESSOR powinna pokazywać 100% GPU, a zapis typu 48%/52% CPU/GPU oznacza, że model został podzielony między GPU i pamięć systemową (FAQ Ollamy).

Ile pamięci naprawdę potrzebuje model: wzór zamiast zgadywania

Popularna reguła „Q4 to około 0,6-0,75 GB na miliard parametrów” opisuje tylko wagi. Pełne zapotrzebowanie wygląda tak:

M = W + KV + B, gdzie KV = 2 × L_attn × n_kv × d_head × T × b

• W - rozmiar pliku modelu podany przy tagu w bibliotece Ollamy (domyślne tagi to kwantyzacja ok. 4-bitowa, np. Q4_K_M).
• L_attn - liczba warstw z pełną uwagą, n_kv - liczba głowic klucz-wartość, d_head - wymiar głowicy; wszystkie trzy wartości odczytałem z plików config.json modeli na Hugging Face.
• T - długość kontekstu w tokenach, b - bajty na wartość: 2 dla domyślnego f16, ok. 1 dla q8_0 i ok. 0,5 dla q4_0 (Ollama podaje, że q8_0 zużywa około połowy, a q4_0 około ćwierci pamięci f16).
• B - bufor na obliczenia i sterownik; przyjmuję 1 GB. To założenie, nie pomiar - w praktyce bywa od ok. 0,5 do 1,5 GB.

Przykład dla Qwen3.6 27B przy 64k tokenów i f16: model ma 64 warstwy, ale pełną uwagę tylko w 16 z nich (pozostałe 48 to uwaga liniowa ze stałym stanem), 4 głowice KV i wymiar 256. KV = 2 × 16 × 4 × 256 × 65 536 × 2 B ≈ 4,29 GB. Razem: 19 + 4,29 + 1 ≈ 24,3 GB (wyliczone). Karta „24 GB” ma w rzeczywistości 24 GiB, czyli ok. 25,8 GB w jednostkach dziesiętnych, więc model mieści się na styk.

Dwie poprawki, które wzór uwzględnia, a proste reguły pomijają:

• Okno przesuwne (Gemma 4, gpt-oss). Część warstw pamięta tylko ostatnie 1024 (Gemma 4) lub 128 (gpt-oss) tokenów. Ich cache jest stały i doliczam go jako osobną, niezależną od T pozycję.
• MLA (GLM-4.7-Flash). Ten model kompresuje cache do 576 wartości na warstwę i token (kv_lora_rank 512 + 64 wymiary RoPE). Wynik zakłada, że silnik przechowuje cache w tej skompresowanej postaci - to założenie, które warto sprawdzić przez ollama ps.

Ile zajmuje sam kontekst: KV cache przy 64 tys. tokenów

1. Devstral 2 123B23,6 GB
2. Devstral Small 2 24B10,7 GB
3. Qwen3-Coder 30B-A3B6,4 GB
4. Gemma 4 31B6,2 GB
5. Qwen3.6 27B4,3 GB
6. Qwen2.5-Coder 7B3,8 GB
7. GLM-4.7-Flash3,5 GB
8. gpt-oss 120B2,4 GB
9. Qwen3.5 9B2,1 GB
10. gpt-oss 20B1,6 GB
11. Qwen3-Coder-Next 80B-A3B1,6 GB
12. Gemma 4 12B1,4 GB
13. Qwen3.6 35B-A3B1,3 GB

Najważniejszy wniosek z tego zestawienia (wyliczone z config.json): przy 64k tokenów i f16 Devstral Small 2 potrzebuje ok. 10,7 GB na sam kontekst, czyli ponad dwie trzecie rozmiaru swoich wag, a Qwen3.6 35B-A3B tylko ok. 1,3 GB. Modele z uwagą hybrydową (Qwen3.5, Qwen3.6, Qwen3-Coder-Next) mają kilka razy mniejszy cache niż klasyczne modele dense podobnej wielkości, dlatego przy długim kontekście agentowym wygrywają nie tylko benchmarkiem, ale i pamięcią. Z tego samego powodu qwen3-coder:30b (19 GB wag) przy 64k f16 potrzebuje ok. 26,4 GB i na karcie 24 GB zmieści się dopiero z cache q8_0 (ok. 23,2 GB).

Porównanie modeli: rozmiary, kontekst i wyniki benchmarków

Tabela zbiera to, co da się sprawdzić w źródłach pierwotnych: rozmiar domyślnego tagu i okno kontekstu z ollama.com, wyniki z kart modeli lub raportów technicznych. Puste pole oznacza, że karta modelu nie podaje danego wyniku - nie uzupełniam go liczbami z drugiej ręki.

* Qwen2.5-Coder 7B ma maksymalnie 32K kontekstu, więc „razem” liczone jest dla 32K. „Razem” = plik + KV + 1 GB bufora (wyliczone). Benchmarki: deklaracje producentów; Gemma 4 31B w SWE-bench według tabeli Qwen, LiveCodeBench v6 gpt-oss według tabeli w karcie Qwen3.5-9B. Kopiuj tabelę jako CSV

Ważne zastrzeżenie: wyniki SWE-bench to deklaracje producentów, mierzone na ich własnych rusztowaniach agentowych (Qwen używa wewnętrznego zestawu bash + edycja plików, raport Qwen3-Coder-Next podaje osobno 70,6% dla SWE-Agent, 71,1% dla MiniSWE-Agent i 71,3% dla OpenHands). Różnica kilku punktów między modelami różnych producentów nie jest więc twardym dowodem przewagi. SWE-bench Verified to 500 zadań z repozytoriów w Pythonie (podzbiór oryginalnego SWE-bench, który obejmuje wyłącznie projekty pythonowe), a SWE-bench Multilingual to 300 zadań w 9 językach: C, C++, Go, Java, JavaScript, TypeScript, PHP, Ruby i Rust (swebench.com). Jeśli piszesz głównie w TypeScripcie czy Javie, ten drugi wynik mówi więcej.

Rekomendacje według ilości pamięci

Poniższe rekomendacje to tekstowa wersja wyników dobieraka dla kontekstu 64k i cache f16 (wyliczone wzorem z poprzedniej sekcji, kolejność według benchmarków producentów).

8 GB VRAM: autocomplete i proste zadania

Przy 8 GB realnie zostaje qwen2.5-coder:7b: plik 4,7 GB, a przy kontekście 32k (maksimum tego modelu) łącznie ok. 7,6 GB. Nowsze qwen3.5:9b (7,6 GB) i gemma4:12b (8,0 GB) z buforem już nie mieszczą się w całości w 8 GB, więc część warstw trafi do RAM-u. Modele tej wielkości dobrze sprawdzają się w uzupełnianiu kodu, wyjaśnianiu fragmentów i prostym debugowaniu, ale nie zastąpią agenta pracującego samodzielnie nad całym repozytorium.

12-16 GB VRAM: pierwsze sensowne modele z długim kontekstem

Przy 12 GB mieszczą się gemma4:12b (ok. 10,4 GB przy 64k) i qwen3.5:9b (ok. 10,7 GB). Przy 16 GB najmocniejszym wyborem z kontekstem 64k jest gpt-oss:20b od OpenAI: model MoE z 21B parametrów, z których aktywnych jest 3,6B, zaprojektowany tak, by zmieścić się w 16 GB pamięci (karta modelu); łącznie ok. 16,6 GB. Dedykowany agent devstral-small-2:24b (65,8% SWE-bench Verified według Mistrala) zmieści się na 16 GB tylko przy krótkim kontekście - już przy 64k sam jego cache to ok. 10,7 GB.

24 GB VRAM (RTX 3090/4090): złoty środek

Tu wybór jest prosty: qwen3.6:27b. Według karty modelu osiąga 77,2% w SWE-bench Verified, 71,3% w SWE-bench Multilingual i 59,3% w Terminal-Bench 2.0, a przy 64k kontekstu zajmuje ok. 24,3 GB. Alternatywy na tę samą kartę: glm-4.7-flash (59,2% SWE-bench Verified według Z.ai, ok. 23,5 GB przy 64k) oraz qwen3.6:35b (wariant MoE z 3B aktywnych parametrów, 73,4%), który przy 64k zmieści się dopiero z cache q8_0. Modele MoE z 3B aktywnych parametrów zwykle generują tokeny szybciej niż dense 27B, więc jeśli tempo odpowiedzi jest ważniejsze niż kilka punktów benchmarku, wariant 35B-A3B jest rozsądnym wyborem (opinia).

32-48 GB: dłuższy kontekst zamiast większego modelu

Przy 32 GB (np. RTX 5090) i 48 GB nie pojawia się nowy, mocniejszy model - kolejny próg to dopiero ok. 52 GB wag Qwen3-Coder-Next. Ta pamięć najlepiej pracuje jako zapas na kontekst: qwen3.6:27b przy 128k tokenów i f16 potrzebuje ok. 28,6 GB, a qwen3.6:35b przy 128k tylko ok. 27,7 GB. Gemma 4 31B (20 GB) ma świetny wynik w LiveCodeBench v6 (80,0% według Google), ale w zadaniach agentowych SWE-bench tabela Qwen pokazuje dla niej 52,0%, wyraźnie mniej niż Qwen3.6.

64 GB i więcej: stacje robocze i Maki z dużą pamięcią

qwen3-coder-next to 80B parametrów, z których przy każdym tokenie aktywne są tylko 3B; plik Q4_K_M ma 52 GB, a kontekst natywny 256K. Przy 64k kontekstu potrzebuje łącznie ok. 54,6 GB (wyliczone), więc na Macu z 64 GB pamięci zunifikowanej zmieści się na styk albo wcale - komfortowo dopiero od ok. 96 GB. Raport techniczny podaje 70,6-71,3% w SWE-bench Verified, zależnie od rusztowania agenta (arXiv:2603.00729). Na papierze qwen3.6:27b ma wyższy wynik przy trzykrotnie mniejszym rozmiarze, więc Next ma sens głównie wtedy, gdy zależy ci na szybkości generacji MoE przy dużej pamięci. Dalej są gpt-oss:120b (65 GB) i devstral-2:123b (75 GB, 72,2% według Mistrala), ten drugi jednak jako model dense potrzebuje przy 64k aż ok. 23,6 GB na sam cache.

Modele serwerowe w rodzaju DeepSeek V3.1 (671B, 404 GB w Ollamie) czy Qwen3-Coder 480B (290 GB, według Ollamy minimum 250 GB pamięci) to już sprzęt klasy serwerowej. Kimi K2.5, który wcześniej był na tej liście, został wycofany z biblioteki Ollamy 31 lipca 2026.

Dlaczego z listy zniknęły Qwen3-Coder 8B i Devstral 22B

Poprzednia wersja tego artykułu polecała qwen3-coder:8b i devstral:22b. Takich tagów nie ma w bibliotece Ollamy: qwen3-coder występuje w wersjach 30b (19 GB) i 480b (290 GB), a devstral w wersji 24b (14 GB, wydanie z maja 2025), którą zastąpił devstral-small-2:24b. Komenda z nieistniejącym tagiem po prostu zwróci błąd, dlatego w tej wersji każdy tag jest sprawdzony na stronie modelu.

Ollama czy LM Studio: które narzędzie wybrać

Ollama to narzędzie konsolowe z lokalnym serwerem, które po pobraniu modeli działa w pełni offline i udostępnia API zgodne z OpenAI pod adresem http://localhost:11434/v1/ (dokumentacja). Dzięki temu większość edytorów i agentów, które potrafią rozmawiać z API OpenAI, podłączysz do lokalnego modelu, zmieniając tylko adres. To naturalny wybór, gdy chcesz wpiąć model w edytor, własny skrypt albo zautomatyzowany przepływ pracy.

LM Studio idzie w stronę interfejsu graficznego: przeglądarka modeli, pobieranie jednym kliknięciem i czat bez terminala. Ma też lokalny serwer z endpointami zgodnymi z OpenAI (w przykładach dokumentacji na porcie 1234) i narzędzie wiersza poleceń lms (dokumentacja LM Studio). Dla kogoś, kto dopiero zaczyna i chce poeksperymentować bez konfiguracji, to wygodniejszy punkt startowy. Poprzednia wersja tekstu podawała, że Ollama jest o 10-20% szybsza - nie znalazłem źródła, które by to potwierdzało, więc usunąłem tę liczbę.

Jak zacząć: instalacja i pierwsze uruchomienie

Na Linuksie Ollamę instaluje się komendą curl -fsSL https://ollama.com/install.sh | sh, a na Windows i macOS wystarczy instalator ze strony ollama.com. Podstawowe komendy: ollama pull [model] pobiera model, ollama run [model] uruchamia rozmowę, ollama list pokazuje pobrane modele, a ollama ps - które są załadowane i na jakim procesorze.

Przed pracą z agentem ustaw kontekst, bo domyślne 4k na kartach poniżej 24 GiB to za mało. Według dokumentacji robi się to zmienną środowiskową przy starcie serwera, np. OLLAMA_CONTEXT_LENGTH=64000 ollama serve, albo suwakiem w ustawieniach aplikacji. Jeśli brakuje pamięci, włącz Flash Attention (OLLAMA_FLASH_ATTENTION=1) i kwantyzację cache (OLLAMA_KV_CACHE_TYPE=q8_0) - to zmniejsza cache mniej więcej o połowę przy bardzo małej utracie precyzji. Gdy Ollama działa jako usługa systemowa lub aplikacja w tle, zmienne trzeba ustawić dla tej usługi, a nie tylko w bieżącym terminalu.

Przykład dla karty 24 GB:

OLLAMA_CONTEXT_LENGTH=65536 ollama serve
ollama run qwen3.6:27b

Czy polski model Bielik nadaje się do kodowania

Bielik od SpeakLeash to model ogólny, którego mocną stroną jest naturalna polszczyzna, a nie programowanie. Najnowszy Bielik 11B v3.0 jest dostępny w Ollamie w przestrzeni społeczności SpeakLeash (nie w oficjalnej bibliotece): ollama run SpeakLeash/bielik-11b-v3.0-instruct:Q4_K_M, a plik GGUF Q4_K_M ma 6,72 GB (Hugging Face). Mniejszy Bielik 1.5B nadal uruchomisz bezpośrednio z Hugging Face: ollama run hf.co/speakleash/Bielik-1.5B-v3.0-Instruct-GGUF.

Bielik nie publikuje wyników w benchmarkach kodowania takich jak SWE-bench, więc nie umieszczam go w dobieraku. Rozsądny podział ról: model koderski z tabeli do kodu, Bielik do polskich tekstów, opisów zmian czy odpowiedzi dla klientów. Jakość w języku polskim i jakość w kodowaniu to dwie różne kompetencje i rzadko jeden model bez dedykowanego treningu wygrywa w obu. Przy pracy z danymi klientów warto też świadomie dobierać, gdzie trafiają zapytania - pisałem o tym przy okazji pytania RODO a ChatGPT.

Kiedy lokalny model wystarczy, a kiedy warto dopłacić za chmurę

Lokalny model do kodowania ma sens przede wszystkim wtedy, gdy kod i dane firmowe nie mogą trafiać na serwery zewnętrznego dostawcy - temat rozwijałem przy okazji pytania, gdzie trzymać dane, żeby AI było bezpieczne. Drugim argumentem jest koszt: lokalny model nie ma miesięcznej opłaty za użytkownika, co przy kilku narzędziach AI w firmie potrafi się zsumować - o tym, jak to policzyć, pisałem w tekście ile subskrypcji SaaS naprawdę ci się zwraca.

Z drugiej strony liczby z kart modeli dobrze pokazują dystans: według tabeli Qwen najlepszy lokalny model na kartę 24 GB (Qwen3.6 27B, 77,2%) zbliża się w SWE-bench Verified do Claude 4.5 Opus (80,9%), ale w SWE-bench Pro różnica jest wyraźniejsza (53,5% wobec 57,1%), a do tego dochodzi szybkość generacji na domowym sprzęcie. Przy dużych refaktoryzacjach obejmujących dziesiątki plików chmurowe narzędzia wciąż wygrywają - o różnicach między nimi pisałem w porównaniu Claude Code vs Cursor vs Codex. Rozsądnym kompromisem jest hybryda: lokalny model do rutynowych zadań i wrażliwego kodu, płatny agent chmurowy na momenty, w których jakość wyniku jest ważniejsza niż koszt.

Metodologia: skąd są te liczby

• Rozmiary i kontekst (zmierzone przez producenta): z kart modeli i list tagów na ollama.com, sprawdzone 28 października 2026. Rozmiar to plik domyślnego tagu; niektóre modele mają kilka wariantów kwantyzacji o nieco innym rozmiarze.
• KV cache (wyliczone): wzorem z sekcji o pamięci, z parametrami z config.json każdego modelu na Hugging Face. Dla GLM-4.7-Flash przy założeniu cache MLA, dla Gemmy 4 z doliczonym stałym cache warstw z oknem przesuwnym.
• Bufor 1 GB i 75% pamięci Maca dla GPU (założenia): uproszczenia do szacunku; realne wartości zależą od sterownika, wersji systemu i ustawień.
• Benchmarki (deklaracje producentów): z kart modeli i raportów technicznych; różne rusztowania agentowe, więc porównania między producentami są orientacyjne.
• Czego nie ma: własnych pomiarów prędkości (tokeny na sekundę) - nie publikuję liczb, których sam nie zmierzyłem.

Najczęstsze pytania

Źródła

1. Ollama - Context length (domyślny kontekst wg VRAM, zalecenie 64k dla agentów)
2. Ollama - FAQ (kwantyzacja KV cache, Flash Attention, ollama ps)
3. Ollama - OpenAI compatibility
4. Ollama - qwen3.6, qwen3-coder-next, qwen3-coder, qwen3.5, qwen2.5-coder
5. Ollama - gemma4, gpt-oss, glm-4.7-flash, devstral-small-2, devstral-2, devstral, deepseek-v3.1, kimi-k2.5
6. Qwen3.6-27B - karta modelu i config.json (Hugging Face)
7. Qwen3.6-35B-A3B - karta modelu
8. Qwen3-Coder-Next Technical Report, arXiv:2603.00729
9. Devstral Small 2 - karta modelu (Mistral AI)
10. GLM-4.7-Flash - karta modelu (Z.ai)
11. Gemma 4 31B - karta modelu (Google)
12. gpt-oss-20b - karta modelu (OpenAI)
13. Qwen3.5-9B - karta modelu
14. Qwen3-Coder-30B-A3B-Instruct - karta modelu
15. SWE-bench Multilingual i SWE-bench Verified
16. Bielik 11B v3.0 Instruct GGUF (SpeakLeash) i strona w Ollamie
17. LM Studio - dokumentacja dla deweloperów