Który lokalny model AI uruchomić? Przewodnik po GPU, kontekście i kodowaniu na październik 2026

Najlepszy lokalny model do kodowania to model, który przechowuje w pamięci wystarczającą część projektu i czyta ją wystarczająco szybko, aby pozostać użytecznym. Rozmiar modelu nadal ma znaczenie. Model, który mieści się dopiero po przeniesieniu części danych do RAM, często działa gorzej niż mniejszy model ze stabilnym oknem kontekstu.

Wybieraj model i budżet pamięci razem. Nie wybieraj modelu z rankingu, a potem nie zmuszaj go do pracy na nieodpowiednim sprzęcie.

Ten przewodnik dotyczy agentów kodujących, a nie krótkich promptów autouzupełniania. Agent czyta pliki, wyniki narzędzi, błędy kompilatora i rezultaty testów, zanim napisze poprawkę. Te dane zużywają kontekst i zmieniają decyzję sprzętową.

Film jest materiałem referencyjnym #

Poniższy film porównuje lokalne modele na kilku poziomach pamięci GPU. Jest przydatny dzięki praktycznym obserwacjom dotyczącym wyboru modelu i przedstawionym wynikom sprzętowym. Ten artykuł porządkuje decyzję inaczej, wokół zachowania pamięci, kontekstu agenta, przetwarzania promptów i całkowitego kosztu posiadania.

Dlaczego rankingi poziomów zawodzą #

Ranking modeli zwykle mapuje liczbę parametrów na ilość pamięci GPU. Ten skrót pomaga przy pierwszym szacunku. Przestaje pomagać, gdy agent kodujący zaczyna czytać prawdziwe repozytorium.

Wagi modelu są pierwszą alokacją. KV cache to alokacja rosnąca. Przechowuje klucze i wartości attention dla aktywnego kontekstu, aby runtime nie musiał przeliczać całego promptu po każdym wygenerowanym tokenie.

To, że plik modelu mieści się na karcie, nie dowodzi, że agent będzie użyteczny. Runtime potrzebuje miejsca na cache, bufory tymczasowe, definicje narzędzi i następną odpowiedź.

Kontekst jest prawdziwym budżetem #

Agenci kodujący zużywają kontekst na więcej niż pliki źródłowe. Budżet obejmuje też instrukcje systemowe, schematy narzędzi, listy katalogów, wyjście powłoki, komunikaty kompilatora, wyniki testów i poprzednie tury rozmowy.

Trzy połączenia MCP z rozbudowanymi definicjami narzędzi często zużywają kilka tysięcy tokenów, zanim agent otworzy plik projektu. Mały domyślny kontekst zostawia wtedy niewiele miejsca na kod. Agent nadal odpowiada, lecz traci zestaw roboczy potrzebny do napraw wieloetapowych.

Ollama runtime FAQ podaje domyślny kontekst 4,096 tokenów. Ustawienie OLLAMA_CONTEXT_LENGTH zmienia domyślną wartość, a OLLAMA_NUM_PARALLEL skaluje wymaganą pamięć wraz z liczbą równoległych żądań. Zapisz obie wartości, zanim porównasz lokalny benchmark z wynikiem dla pojedynczego żądania.

OLLAMA_CONTEXT_LENGTH=32768 OLLAMA_NUM_PARALLEL=1 ollama serve

Ten przykład ustawia domyślne 32K dla jednego aktywnego żądania. Nie rezerwuje 32K tokenów na pliki projektu. Instrukcje, definicje narzędzi, wejście i wyjście nadal dzielą okno.

Prosty zapis kontekstu #

Przed porównaniem GPU zapisz te wartości:

• Rozmiar projektu: liczba plików i przybliżona liczba linii źródłowych w zwykłym zadaniu.
• Narzut narzędzi: prompt systemowy, schematy MCP, narzędzia powłoki i instrukcje edytora.
• Ładunek błędu: typowa długość wyjścia kompilatora i testów.
• Docelowy kontekst: największy prompt, który chcesz zachować bez obcinania.
• Limit odpowiedzi: miejsce zarezerwowane na planowaną poprawkę i wyjaśnienie.

Traktuj wynik jako specyfikację obciążenia. Deweloper edytujący jeden plik naraz potrzebuje innej ilości pamięci niż deweloper proszący agenta o prześledzenie API przez monorepo.

KV cache zmienia ranking #

Dwa modele o podobnej liczbie parametrów często mają różne koszty kontekstu. Gęsty model, w którym każda warstwa uczestniczy w rosnącym cache, może potrzebować więcej pamięci niż model z hybrydowym mechanizmem attention.

Jeden omawiany w materiale referencyjnym model kodujący 27B używa ograniczonego zestawu warstw z pełnym attention, a pozostałe warstwy korzystają ze streszczenia o stałym rozmiarze. Zgłoszony koszt kontekstu 128K pozostaje poniżej 9GB dla cache. Model podobnej wielkości z rosnącym pełnym attention w każdej warstwie według raportu potrzebuje ponad 21GB przy tej samej długości kontekstu.

Te liczby dotyczą konkretnych architektur modeli i ustawień runtime. Traktuj je jako powód do sprawdzenia architektury, a nie jako uniwersalny wzór pamięci.

Przeczytaj architekturę modelu przed zakupem pamięci. Sama liczba parametrów ukrywa koszt długiej sesji kodowania.

Wybieraj według poziomu pamięci GPU #

Cztery do ośmiu GB #

Małe gęste modele pozostają praktycznym wyborem. Mieszczą się na karcie, odpowiadają szybko i dobrze działają przy autouzupełnianiu, krótkich wyjaśnieniach oraz wąskich zmianach plików.

Większy model z CPU offload może generować tekst, lecz czas odpowiedzi często staje się ograniczeniem. Agent kodujący wykonuje powtarzające się odczyty plików i wywołania narzędzi. Konfiguracja z szybkością czterech tokenów na sekundę zamienia każdą naprawę w długie oczekiwanie, nawet gdy model technicznie działa.

Modele mixture-of-experts dają inną drogę. Mała aktywna część zmniejsza presję obliczeniową, a pełny zestaw wag nadal częściowo znajduje się w pamięci systemowej. To podejście korzysta z dużej ilości RAM i szybkich ścieżek transferu.

Na tym poziomie kup najpierw RAM systemowy, zanim zaczniesz szukać dużego modelu. Stabilny mały model wygrywa z dużym modelem, który większość czasu przenosi dane przez magistralę.

Dwanaście do szesnastu GB #

Ten poziom otwiera drogę do modelu kodującego 27B, lecz wybór kwantyzacji staje się kluczowy. Standardowy build 4-bit o rozmiarze około 17GB nie mieści się na karcie 16GB po uwzględnieniu narzutu runtime.

Build 3-bit o rozmiarze około 13GB zostawia więcej miejsca na kontekst. Karta 12GB kieruje wybór ku buildowi 2-bit lub mniejszemu modelowi mixture-of-experts. Jakość zależy od konkretnego kwantyzatora i procesu kalibracji, więc dwa uploady o tej samej głębokości bitowej często dają inne wyniki kodowania.

Przed pobraniem skwantyzowanego modelu sprawdź:

• Autora kwantyzatora i informacje o wydaniu
• Dane kalibracyjne i wyniki oceny
• Zgodność tokenizera
• Testy wywołań narzędzi
• Długość kontekstu przy wybranej kwantyzacji
• Obsługę runtime w Ollama, llama.cpp lub wybranym interfejsie

„2-bit” ani „3-bit” nie jest pełnym opisem jakości. Znaczenie mają metoda pakowania i zapis kalibracji.

Dwadzieścia cztery do trzydziestu dwóch GB #

To najbardziej elastyczny zakres dla modelu kodującego 27B. Karta 24GB często mieści build 4-bit z użytecznym kontekstem, lecz pełne okno 128K może przekroczyć pozostałą pamięć. Karta 32GB daje runtime więcej miejsca na cache i alokacje tymczasowe.

Ten zakres ułatwia też uzasadnienie zakupu. Jedno GPU obsługuje obciążenie bez złożoności podziału na dwie karty. System zużywa mniej energii niż konfiguracja multi-GPU, a obsługę oprogramowania łatwiej przetestować.

Zakres 24GB do 32GB to rozsądna strefa zakupu do częstej prywatnej pracy z kodem. Unika najsłabszego offloadu bez wciskania sprzętu serwerowego do obudowy desktopowej.

Czterdzieści osiem GB i więcej #

Więcej pamięci nie oznacza automatycznie nowego modelu. Ten sam model 27B może działać z precyzją 8-bit na karcie 48GB, z większym cache i mniejszą liczbą kompromisów. Zysk dotyczy spójności, miejsca na kontekst i jakości wyjścia, a nie nowego poziomu rozumowania.

Przy 128GB decyzja się zmienia. Staje się możliwy znacznie większy model mixture-of-experts, lecz przetwarzanie promptu staje się poważnym problemem. Model często generuje szybko, a długo wczytuje duże repozytorium lub świeży wynik narzędzia.

Dla dużych modeli mierz szybkość prefill osobno od szybkości decode. Szybka odpowiedź po wolnym odczycie promptu nadal wydaje się wolna w pracy agenta.

Szybkość decode to tylko połowa testu #

Szybkość decode mierzy liczbę generowanych tokenów na sekundę. Odpowiada na pytanie: „Jak szybko model pisze?”. Szybkość prefill mierzy przetwarzanie promptu. Odpowiada na pytanie: „Jak szybko model czyta?”.

Agent spędza dużą część czasu na czytaniu. Każde wywołanie narzędzia dodaje nowy tekst. Długi plik źródłowy, stack trace lub log testu trafia do promptu, zanim rozpocznie się następna odpowiedź.

Benchmarkuj własne rozmiary promptów. Krótki syntetyczny prompt ukrywa koszt, który ma największe znaczenie podczas pracy z repozytorium.

Najpierw bezpłatne ustawienia runtime #

Modernizacja sprzętu nie jest pierwszym krokiem do poprawy wydajności. Przetestuj ustawienia runtime przed otwarciem strony zakupowej.

Predykcja wielu tokenów #

Niektóre kombinacje modelu i backendu przewidują kilka przyszłych tokenów, a następnie weryfikują je w jednym przebiegu. Funkcja często korzysta z flagi runtime lub zgodnej konfiguracji draft.

Zgłoszone w materiale referencyjnym testy pokazują duże zyski na części kart high-end. Wyniki zależą od pliku modelu, backendu, sterownika i karty. Ścieżki Apple Metal mogą nie zachować wymaganej funkcji podczas konwersji.

Poziom rozumowania #

Model z maksymalnym poziomem rozumowania poświęca więcej czasu na pracę wewnętrzną przed zwróceniem wyniku. Średni poziom często daje lepszy balans przy naprawie kodu, szczególnie gdy zadanie zawiera jasny komunikat błędu i wąski cel w postaci pliku.

Użyj prostej macierzy testowej:

1. Uruchom to samo zadanie naprawy błędu z niskim, średnim i wysokim poziomem rozumowania.
2. Zapisz czas do pierwszego tokena, całkowity czas, sukces poprawki i wynik testu.
3. Powtórz test z krótkim promptem i promptem rozmiaru repozytorium.
4. Zachowaj ustawienie, które daje najlepsze ukończone zadanie, a nie najwyższą szybkość tokenów.

Średni poziom rozumowania ze zgodną ścieżką predykcji wielu tokenów to dobry punkt startowy. Sprawdź jakość na własnym kodzie, zanim ustawisz go jako domyślny.

Sprzęt lokalny czy wynajęte GPU? #

Wynajem obliczeń wygrywa przy okazjonalnej pracy. Płacisz za aktywne sesje zamiast kupować, chłodzić, aktualizować i zasilać kartę przez cały rok.

Posiadany sprzęt wygrywa, gdy obciążenie jest częste, prywatne lub offline. Usuwa też czas oczekiwania w kolejce i daje stabilne środowisko do powtarzalnych testów.

Próg opłacalności obliczaj według aktywnych godzin, nie godzin kalendarzowych. Uwzględnij prąd, pamięć masową, chłodzenie, utrzymanie oraz czas potrzebny do działania runtime.

Wysokiej klasy GPU kupione do sporadycznych eksperymentów to wydatek hobbystyczny. System 24GB do 32GB używany codziennie do prywatnej pracy ma mocniejsze uzasadnienie ekonomiczne.

Lepsza lista zakupowa #

Porównując model i GPU, stosuj tę kolejność:

1. Zdefiniuj zadanie. Autouzupełnianie, naprawa jednego pliku, agent repozytorium lub analiza z długim kontekstem.
2. Zmierz prompt. Policz zwykłe instrukcje systemowe, schematy narzędzi, pliki i wyjście testów.
3. Sprawdź zachowanie cache. Poszukaj informacji o architekturze i pomiarów pamięci kontekstu.
4. Wybierz kwantyzację. Sprawdź wyniki jakości konkretnego uploadu, nie tylko liczbę bitów.
5. Przetestuj prefill i decode. Użyj promptów z własnego repozytorium.
6. Dostrój rozumowanie. Porównaj czas ukończenia zadania przy kilku poziomach rozumowania.
7. Sprawdź prywatność i utrzymanie. Potwierdź, dokąd trafia kod źródłowy i kto utrzymuje backend.
8. Porównaj koszt wynajmu. Użyj przewidywanych aktywnych godzin i dodaj prąd do szacunku systemu własnego.

Ostateczna rekomendacja #

Poniżej 12GB uruchom mniejszy model lub model mixture-of-experts z wystarczającą ilością RAM. Nie zmuszaj gęstego modelu 27B do pracy w konfiguracji, która większość czasu spędza na offloadzie.

Przy 12GB do 16GB skup się na jakości kwantyzacji i kontrolowanym celu kontekstu. Dobrze przetestowany build 2-bit lub 3-bit z obsługą narzędzi jest bardziej użyteczny niż plik 4-bit, który nie mieści się poprawnie.

Przy 24GB do 32GB model kodujący 27B staje się praktycznym domyślnym wyborem do codziennej prywatnej pracy. Zmierz użycie kontekstu i szybkość promptu, zanim uznasz, że całe reklamowane okno jest dostępne.

Przy 48GB i więcej przeznacz dodatkową pamięć na precyzję, miejsce na cache i stabilne sesje, zanim przejdziesz do większego modelu. Gdy model wchodzi na poziom 128GB, szybkość czytania promptu i ekonomia wynajmu zasługują na większą uwagę niż sama pojemność.

Nazwa modelu to dopiero początek. Właściwe pytanie brzmi: ile kontekstu projektu zostaje po tym, jak model, runtime, narzędzia i cache zajmą swoje części?

Powiązane materiały #

• 32GB VRAM dla Qwen 27B: przewodnik po sprzęcie do lokalnego AI , skupia się na ścieżkach sprzętowych dla obciążenia 27B.
• Benchmarki GPU Llama 3.1 8B i Qwen3.8 27B na Vast.ai , zmierzone wyniki wynajętych GPU i ograniczenia długiego kontekstu.
• Lokalne AI w 2026: model 27B pokonuje Sonnet 4.6 , jakość modelu, kwantyzacja i ekonomia lokalnego sprzętu.