Zbudowałem w pełni lokalnego asystenta kodowania AI w Windows za pomocą Ollama i VS Code

Asystenci do kodowania w chmurze są zdecydowanie pomocni, ale wiążą się z powtarzającymi się subskrypcjami lub opłatami według zużycia, a ty umieszczasz potencjalnie poufne informacje w internecie.

Dobrą wiadomością jest to, że możesz przenieść całą operację na własny sprzęt. Uruchamiając Ollama i łącząc go z VS Code poprzez specjalne rozszerzenie, możesz bardzo łatwo uruchomić prywatną, offline'ową alternatywę bez subskrypcji w stosunku do dużych modeli w chmurze.

Lokalni agenci kodowania są świetni pod względem kosztów i prywatności

Prywatność, brak opłat subskrypcyjnych i możliwość korzystania offline

Agenci kodujący są bardziej popularni niż kiedykolwiek, a dzięki niedawnym ulepszeniom lokalni agenci kodujący stają się coraz bardziej realną alternatywą dla dużych modeli w chmurze, zwłaszcza jeśli potrafisz podzielić swoją pracę na mniejsze części.

Uruchamianie rzeczy lokalnie ma kilka zalet, z których najbardziej bezpośrednią jest prywatność. Gdy Twój kod nigdy nie opuszcza Twojego komputera, zmniejszasz ryzyko wycieku zastrzeżonego kodu, ujawnienia danych lub naruszenia wymogów regulacyjnych. Jeśli pracujesz nad czymś wrażliwym lub po prostu dbasz o prywatność, modele lokalne są świetną opcją.

Poza tym możesz zapomnieć o pomiarze API czy miesięcznych subskrypcjach. Możesz korzystać ze swojego asystenta kodowania tak długo, jak chcesz, a jedynym realnym miesięcznym kosztem jest prąd, plus rozłożony koszt sprzętu. Na początku brzmi to ciężko, ale gdy weźmiesz pod uwagę, że Claude faktycznie zaczyna się od 100 USD miesięcznie (plan za 20 USD będzie zbyt ograniczony dla większości intensywnych użytkowników), szybko zbiera się to do ceny katalogowej RTX 5080.

Jeśli podoba Ci się pomysł kontrolowania swoich danych, rezygnacji z subskrypcji i masz odpowiedni sprzęt, lokalna sztuczna inteligencja jest świetną opcją.

Czego tak naprawdę potrzebuje lokalna konfiguracja AI

Istnieją trzy składniki lokalnego agenta do kodowania AI

Gdy uruchamiasz duży model językowy jako asystenta kodowania, potrzebujesz trzech rzeczy:

• Ollama — Hostuje duży model językowy
• VScode z Continue lub Cline — Zapewnia interfejs użytkownika w VS code
• LLM — Jakiś LLM, który faktycznie pomoże w kodowaniu

Możesz użyć dowolnego LLM, jaki chcesz, ale pamiętaj, że LLM są bardzo wymagające pod względem pamięci RAM. Dobrą zasadą jest, że każdy miliard parametrów będzie wymagał 1 gigabajta VRAM dla standardowego modelu 8-bitowego. Tak więc Gemma 4 12B potrzebowałaby 12 GB VRAM, nie wliczając miejsca na okno kontekstu.

Musisz również uwzględnić swoje okno kontekstowe, które określa, ile „materiału” podajesz swojej sztucznej inteligencji w połączeniu z tym, ile ona generuje. Twoje okno kontekstowe może zużywać od kilkuset megabajtów do wielu gigabajtów. Jeśli działasz blisko limitu pamięci VRAM, uważnie to obserwuj — może to łatwo spowodować przeniesienie obliczeń na CPU, co znacznie spowolni wydajność.

Kwantyzacja jest twoim najlepszym przyjacielem—z haczykiem

To właśnie tutaj pomocna może być kwantyzacja — którą można uważać za formę kompresji modelu. Aby ogólnie sprawdzić, czy Twój kwantyzowany model się zmieści, podziel swoją kwantyzację przez 8, a następnie pomnóż tę wartość przez rozmiar parametrów modelu. Na przykład, jeśli uruchomiłeś 5-bitową kwantyzowaną wersję Gemma 4 12B, możesz rozsądnie oczekiwać, że zmieści się ona w 7,5 GB VRAM, ponieważ 5/8 razy 12 to 7,5.

To właśnie dlatego modele kwantyzowane do 3 bitów Qwen 3.6 27B mogą być uruchamiane na GPU z 16 GB VRAM — zużywają one tylko 10-13,5 GB VRAM w porównaniu do pełnego modelu 8-bitowego.

Nie ma jednoznacznej odpowiedzi na pytanie „którego modelu powinieneś użyć.” Generalnie, modele kwantyzowane nie są tak inteligentne jak ich niekwantyzowane odpowiedniki, a im bardziej model jest kwantyzowany, tym mniej będzie inteligentny.

Natychmiast wykluczyłbym 2-bitowe kwantyzacje — prawie nigdy się nie opłacają. Modele 3-bitowe są czasami w porządku, jednak. Dodatkowo unikałbym uruchamiania mocno skwantyzowanych wersji małych modeli. Są już dość szczupłe, a utrata inteligencji zazwyczaj jest zbyt znacząca, by była użyteczna.

Konfigurowanie lokalnego agenta kodującego

Uruchamianie Ollama i twojego modelu

Aby rozpocząć, pobierz i zainstaluj Ollama, korzystając z instalatora ze strony internetowej Ollama. Jeśli używasz Windows lub macOS, dostępny jest faktyczny instalator. Jeśli używasz Linuxa, będziesz musiał użyć curl.

Po zainstalowaniu i uruchomieniu musisz pobrać modele, które pasują do Twojego sprzętu. Na przykład, jeśli chciałbyś pobrać kwantowaną wersję Qwen 3.6-27B od Unsloth, należy uruchomić:

ollama run hf.co/unsloth/Qwen3.6-27B-MTP-GGUF:Q3_K_S

Używałem batiai/qwen3.6-27b:q3 jako mojego bardziej zaawansowanego lokalnego modelu kodowania.

Gdy to zostanie zrobione, możesz uruchomić ollama ls, aby potwierdzić, że jest dostępny.

Możesz również używać mniejszych, lżejszych modeli (szukaj czegoś w zakresie 7B) do bardziej inteligentnego autouzupełniania w Continue w połączeniu z cięższymi modelami. Jeśli nie możesz uruchomić 27B asystenta kodowania, wypróbuj zamiast tego sparametryzowany model 14B lub model 7B. Nadal są całkiem dobre, zwłaszcza do autouzupełniania.

Skonfiguruj swojego agenta kodowania AI w VS Code

Następnie zainstaluj rozszerzenie Cline lub Continue w VS Code. Gdy zostanie zainstalowane, wystarczy, że wskażesz swoje rozszerzenie na serwer Ollama działający na twoim komputerze, a będzie ono w stanie wykryć wszystkie modele dostępne dla Ollama.

Cline błyszczy, jeśli chcesz czegoś, co generuje w pełni działające bloki kodu na podstawie twoich instrukcji, nie potrafi jednak autouzupełniać w linii. Jeśli chcesz tylko autouzupełniania w linii, użyj Continue.

Po skonfigurowaniu wyślij kilka zapytań czatu lub automatycznie uzupełnij kilka linii. Jeśli zauważysz, że odpowiedzi są bardzo opóźnione lub system działa powoli, powinieneś dostosować rozmiar modelu do mniejszego, aby lepiej pasował do twojej VRAM. Możesz również uruchomić ollama ps, aby zobaczyć, jak twój system dzieli zasoby między GPU a CPU. W idealnym świecie chcesz mieć 100% GPU — jest to znacznie szybsze.

Lokalne LLM-y do kodowania mają pewne ograniczenia

Zrzucanie zadań na CPU jest problemem wydajnościowym

Lokalne modele LLM mogą obecnie zastąpić niektóre funkcje większych modeli opartych na chmurze, co jest świetne, jeśli potrzebujesz prywatności lub po prostu nie chcesz płacić za obliczenia.

Ma jednak pewne wady.

Używam RTX 5070Ti, który ma 16 gigabajtów pamięci VRAM. W praktyce oznacza to, że nie mogę używać modeli z więcej niż około 12 miliardami parametrów (jak Gemma 4 12B od Google'a) w normalnych warunkach. Między kontekstem a samym modelem szybko zużywam te 16 GB.

Gdy 16 GB zostanie zużyte, zaczyna się ono „przeładowywać” na Twój procesor i pamięć RAM systemu. Niestety, w porównaniu jest to strasznie wolne. LLM, który na GPU może działać z prędkością 70-90 tokenów/s, często spowalnia do 5 tokenów/s przy przeładowaniu na CPU. Jeśli używasz go jako procesu w tle, jest to w porządku. Jeśli siedzisz i czekasz, aż skończy, jest to dość nieprzyjemne.

Prywatne kodowanie AI jest teraz praktycznym narzędziem codziennego użytku, a nie eksperymentem

Połączenie Ollama, Cline i dedykowanego modelu kodu tworzy lokalną wersję Claude'a lub Copilota, która jest naprawdę przydatna do codziennej pracy, o ile ostrożnie z niej korzystasz. Chociaż chmura ma swoje zalety w zakresie surowej mocy, podejście lokalne przynosi korzyści w momencie, gdy prywatność lub koszty stają się głównym priorytetem.