Najlepsze modele LLM do OpenCode – przetestowane lokalnie

Przetestowałem działanie narzędzia OpenCode z kilkoma lokalnie hostowanymi modelami LLM na Ollama, a dla porównania dodałem również darmowe modele z OpenCode Zen.

OpenCode jest obecnie jednym z najbardziej obiecujących narzędzi w ekosystemie narzędzi dla programistów AI.

TL;DR - Najlepsze LLM do OpenCode

Jasny zwycięzca w wersji lokalnej: Qwen 3.5 27b Q3_XXS na llama.cpp

Model o 27 bilionach parametrów w kwantyzacji IQ3_XXS dostarczył kompletny, działający projekt w języku Go z 8 przechodzącymi testami jednostkowymi, pełnym plikiem README oraz prędkością 34 tokenów na sekundę na moim setupie z 16 GB VRAM (hybrydowy CPU+GPU). Pięć gwiazdek, bez zastrzeżeń. To mój wybór do lokalnych sesji OpenCode.

Qwen 3.5 35b na llama.cpp — szybki do kodowania, ale wszystko wymaga weryfikacji

Model 35b jest doskonały do szybkich, autonomicznych zadań kodowania — jednak moje testy mapy migracyjnej ujawniły poważny problem z niezawodnością. W dwóch uruchomieniach z kwantyzacją IQ3_S wywołał 63–73% niezgodności slugów, a w kwantyzacji IQ4_XS zapomniał całkowicie o uwzględnieniu slugów stron, generując ścieżki kategorii, które mapowałyby 8 różnych stron na ten sam URL. Jakość kodowania w zadaniu IndexNow była rzeczywiście dobra, więc ten model jest wart użycia — po prostu nigdy nie ufaj jego wynikom w zadaniach strukturalnych wymagających przestrzegania reguł bez ich sprawdzenia. Weryfikacja nie jest opcjonalna.

Zaskakująco dobry: Bigpicle (z OpenCode Zen)

Najszybszy w ukończeniu zadania — 1 minuta 17 sekund. Co ważniejsze, był to jedyny model, który zatrzymał się przed napisaniem kodu, aby faktycznie wyszukać specyfikację protokołu IndexNow za pomocą Exa Code Search. Znalazł wszystkie poprawne punkty końcowe za pierwszym razem. Jeśli masz dostęp do OpenCode Zen, ten model bije swoje możliwości.

Dobry, ale tylko przy wysokim poziomie myślenia: GPT-OSS 20b

W trybie domyślnym GPT-OSS 20b zawodzi — napotyka martwe końce w wywołaniach WebFetch i się zatrzymuje. Przełącz go na tryb wysokiego myślenia i staje się naprawdę zdolnym asystentem kodowania: pełna analiza flag, poprawna logika grupowania, przechodzące testy jednostkowe, wszystko wykonane szybko. Pamiętaj o tym, zanim o nim zapomnisz. GPT-OSS 20b zawiodł w zadaniach strukturalnych nawet w trybie wysokim.

Ominąć w autonomicznym kodowaniu: GPT-OSS 20b (domyślny), Qwen 3 14b, devstral-small-2:24b

Były to moje ulubione modele pod kątem szybkości w czatach i zadaniach generacyjnych. Jednak w trybie autonomicznym wszystkie mają realne problemy. Qwen 3 14b halucynuje dokumentację zamiast przyznać się, że nie może znaleźć czegoś. GPT-OSS 20b (domyślny) zacięty, gdy WebFetch zawodzi. Devstral myli się przy podstawowych operacjach na plikach. W przypadku OpenCode, jakość przestrzegania instrukcji i wywoływania narzędzi ma o wiele większe znaczenie niż surowa prędkość.

O tym teście

Każdemu modelowi uruchomionemu w opencode zadałem dwa zadania/prompty:

1. Stwórz dla mnie narzędzie CLI w języku Go, które będzie wywoływać punkty końcowe indexnow dla Binga i innych silników wyszukiwania, aby powiadamiać o zmianach na mojej stronie.
2. Przygotuj mapę migracji strony.

Wiesz, czym jest protokół Indexnow, prawda?

Drugie zadanie: mam plan migracji niektórych starych postów na tej stronie ze starego formatu URL blogowego (np. https://www.glukhov.org/post/2024/10/digital-detox/) do klastrów tematycznych (tak jak URL tego artykułu: https://www.glukhov.org/ai-devtools/opencode/llms-comparison/). Poprosiłem więc każde LLM w OpenCode o przygotowanie dla mnie mapy migracji zgodnie z moją strategią.

Większość modeli LLM uruchamiałem na lokalnie hostowanym Ollama, a niektóre inne na lokalnie hostowanym llama.cpp. Model Bigpicle i inne bardzo duże modele językowe pochodziły z OpenCode Zen.

Wyniki każdego modelu

qwen3.5:9b

Całkowita porażka w pierwszym zadaniu. Model przeszedł przez swój proces myślowy — poprawnie identyfikując odpowiednie usługi (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex) — ale nigdy faktycznie nie wywołał żadnych narzędzi. Wygenerował podsumowanie „Build" bez dotknięcia pojedynczego pliku. Żadne wywołanie narzędzia.

qwen3.5:9b-q8_0

Krok do przodu względem domyślnej kwantyzacji: przynajmniej utworzył plik go.mod i main.go. Następnie jednak natychmiast utknął, przyznał, że musi dodać brakujące importy, próbował przepisać cały plik używając heredoc w powłoce — i nie powiódł się. Czas budowania wyniósł 1 minuta 27 sekund za coś, co nie działało.

Qwen 3 14b

Klasyczna halucynacja pod presją. Próbowano pobrać dokumentację IndexNow trzy razy z rzędu, za każdym razem napotykając błąd 404 z błędnego URL (github.com/Bing/search-indexnow). Zamiast przyznać, że nic nie może znaleźć, zmyślił pewne siebie brzmienie odpowiedź — błędny punkt końcowy API, błędna metoda uwierzytelniania. Kiedy poprosiłem go o ponowne wyszukiwanie, wyprodukował drugą zmyśloną odpowiedź wskazującą na jeszcze inny URL, który również zwraca 404. Informacja, którą zgłosił, była niepoprawna. To jest tryb awarii, którego najbardziej chcę uniknąć.

GPT-OSS 20b

Przynajmniej zachowanie było szczere i metodyczne. Wykonał długą sekwencję wywołań WebFetch — indexnow.org, różne repozytoria GitHub, własne strony Binga — i napotkał błędy 404 lub bloki Cloudflare prawie wszędzie. Dokumentował każdą niepowodzenie w sposób transparentny. Ostatecznie wciąż nie mógł zebrać wystarczających informacji, aby zbudować działające narzędzie, ale w przeciwieństwie do Qwen 3 14b, nie wymyślał rzeczy. Po prostu nie mógł przeforsować.

GPT-OSS 20b (wysokie myślenie)

Znacznie inna historia niż w trybie domyślnym. Z włączonym wysokim myśleniem model odzyskał się z tych samych martwych końców pobierania i zbudował kompletne, działające narzędzie — z poprawną analizą flag (--file, --host, --key, --engines, --batch, --verbose), GET dla pojedynczych URL i POST dla wielu, zgodnie ze specyfikacją IndexNow.

Kiedy poprosiłem o dokumentację i testy jednostkowe, dostarczył oboje. Testy przeszły:

=== RUN   TestReadURLsFile
--- PASS: TestReadURLsFile (0.00s)
=== RUN   TestReadURLsNoProtocol
--- PASS: TestReadURLsNoProtocol (0.00s)
ok  	indexnow-cli	0.002s

Również szybkie — początkowa budowa w 22,5 sekundy. Wysokie myślenie sprawia, że gpt-oss:20b jest naprawdę używalne.

qwen3-coder:30b

Najbardziej interesująca porażka. Faktycznie skompilował i uruchomił narzędzie przeciwko rzeczywistym punktom końcowym, zobaczył rzeczywiste błędy API z Binga, Google i Yandexa i zaczął je naprawiać:

Error notifying Bing: received status code 400 ... "The urlList field is required."
Error notifying Google: received status code 404 ...
Error notifying Yandex: received status code 422 ... "Url list has to be an array"

To dobry instynkt. Problem: działał przy 720% CPU i tylko 7% GPU — ekstremalnie nieefektywnie dla modelu o 22 GB. Zabrało to 11 minut 39 sekund, a ostateczny wynik wciąż był „nie do końca taki, jak oczekiwano". Utworzył również plik README.md, co jest miłym dodatkiem. Nie jest to zły model, po prostu bardzo wolny na moim setupie i nie całkowicie ujął format protokołu IndexNow.

qwen3.5:35b (Ollama)

Solidne wyniki, ale wolne. Utworzył odpowiedni projekt w Go, napisał testy i wszystkie przeszły:

=== RUN   TestHashIndexNowPublicKey/non-empty_key
--- PASS
=== RUN   TestGetPublicKeyName/standard_root
--- PASS
=== RUN   TestGetPublicKeyName/custom_root
--- PASS

Wada: czas budowania 19 minut 11 sekund. Dla modelu o 27 GB działającego z podziałem CPU/GPU 45%/55%, to jest zbyt wolne do użycia interaktywnego. Jakość jest na miejscu, ale opóźnienia zabijają przepływ pracy.

Bigpicle (big-pickle)

Najbardziej wyróżniający się wykonawca w pierwszym zadaniu. Przed napisaniem nawet jednej linii kodu, użył Exa Code Search, aby faktycznie zbadać protokół IndexNow:

◇ Exa Code Search "IndexNow protocol API endpoint how to notify search engines"

I znalazł odpowiednie punkty końcowe:

• Global: https://api.indexnow.org/indexnow
• Bing: https://www.bing.com/indexnow
• Yandex: https://webmaster.yandex.com/indexnow
• Yep: https://indexnow.yep.com/indexnow
• Amazon: https://indexnow.amazonbot.amazon/indexnow

Rozwiązał problem z importem cobra w czysty sposób (go mod tidy) i narzędzie zostało ukończone w 1 minucie 17 sekund. Odpowiedź dotycząca limitu prędkości, którą otrzymał z Binga podczas testów, była w rzeczywistości oczekiwanym zachowaniem dla nieprawidłowego klucza testowego — model poprawnie zidentyfikował to jako „narzędzie działa". Impresjonujące.

devstral-small-2:24b

Zatknął się na podstawowym poziomie: próbował zapisać polecenia powłoki (go mod init indexnowcli, go mod tidy) bezpośrednio do pliku go.mod, co wywołało błędy parsowania. Jakś sposób udało mu się zbudować binarne (7,9 MB), ale powstałe CLI było zbyt proste — tylko indexnowcli <url> <key> bez obsługi flag, bez wsparcia dla wielu silników, nic. Zabrało to 2 minuty 59 sekund + 1 minuta 28 sekund, aby uzyskać narzędzie, które nie było naprawdę użyteczne.

qwen3.5:27b (llama.cpp, kwantyzacja IQ3_XXS)

To zaimponowało mi najbardziej ze wszystkich lokalnych uruchamiających. Działając jako Qwen3.5-27B-UD-IQ3_XXS.gguf na llama.cpp (głównie CPU), utworzył kompletne narzędzie z pełnym pokryciem testów — wszystkie 8 testów przeszły — i odpowiednim README z instrukcjami instalacji i wyjaśnieniem protokołu:

PASS    indexnow    0.003s

Obsługiwane silniki: Bing, Yandex, Mojeek, Search.io. Czas budowania: 1 minuta 12 sekund dla narzędzia, 1 minuta 27 sekund dla testów i dokumentacji. Szybkość: 34 tokeny na sekundę. Jakość: 5 gwiazdek. Niesamowity wynik dla modelu kwantyzowanego działającego na CPU+GPU.

qwen3.5:35b (llama.cpp, kwantyzacja IQ3_S)

Działając jako Qwen3.5-35B-A3B-UD-IQ3_S.gguf na llama.cpp. Moje notatki tutaj są krótkie: „wspaniale!" — co mówi wszystko. Większy model przy tym samym poziomie kwantyzacji dostarczył co najmniej tak dobre wyniki jak wariant 27b, jeśli nie lepsze.

Wyniki mapy migracji

Dla drugiego zadania uruchomiłem osobną serię — 7 modeli, wszystkie otrzymały te same instrukcje, strukturę strony i listę stron. Ograniczenie było jawnym: slug (ostatni segment ścieżki) musi pozostać taki sam. Na przykład /post/2024/04/reinstall-linux/ musi stać się /.../reinstall-linux/, a nie coś innego.

Zmierzono, ile niezgodności slugów wyprodukował każdy model — przypadków, gdzie wygenerowany slug docelowy różnił się od slugu źródłowego.

Model	Linie	Niezgodności slugów	Błąd
minimax-m2.5-free	80	4	5.0%
Nemotron 3	78	4	5.1%
Qwen 3.5 27b Q3_XXS (llama.cpp)	80	4	5.0%
Qwen 3.5 27b Q3_M (llama.cpp)	81	6	7.4%
Bigpicle	81	9	11.1%
mimo-v2-flash-free	80	42	52.5%
Qwen 3.5 35b IQ3_S -second run (llama.cpp)	81	51	63.0%
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98.8%

Jedna rzecz, którą wszystkie 7 modeli zrobiło identycznie: stare URL w formacie 2022 miały prefiks miesiąca wbudowany w slug (np. /post/2022/06-git-cheatsheet/ → slug 06-git-cheatsheet). Każdy model usunął ten prefiks i użył git-cheatsheet jako nowego sluga. To są 4 spójne niezgodności w trzech najlepszych modelach — więc ich bazowa linia to 4 błędy każdy, a nie zero.

Prawdziwa dywergencja zaczyna się powyżej tej bazy. minimax-m2.5-free, Nemotron 3 i Qwen 3.5 27b Q3_XXS naruszyli zasadę sluga tylko na tych 4 ścieżkach legacy — nic więcej. Qwen 3.5 27b Q3_M dodał 2 dodatkowe (zmienił slug artykułu cognee i zamienił Base64 na małe litery). Bigpicle dodał 5 więcej ponad 4, głównie skracając długie slugi.

Odchylenia są w innej kategorii. Qwen 3.5 35b IQ3_S konsekwentnie przepisywał slugi z tytułów stron zamiast zachowywać źródło (np. executable-as-a-service-in-linux → run-any-executable-as-a-service-in-linux, file-managers-for-linux-ubuntu → context-menu-in-file-managers-for-ubuntu-24). Drugie uruchomienie było nieco lepsze (51 vs 59), ale pokazało to samo zachowanie. Halucynował również ścieżkę źródłową: cicho zmienił comparing-go-orms-gorm-ent-bun-sqlc na comparing-go-orms-gorm-ent-bun-sql (usuń c), więc obie strony tej linii się zgadzały — ale były obie błędne. mimov2 był podobnie agresywny w skracaniu: gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

Kwantyzacja IQ4_XS modelu 35b to zupełnie inna kategoria awarii: 98.8% niezgodności slugów — ale problemem nie są błędne slugi, tylko to, że model zapomniał całkowicie o uwzględnieniu slugów. Zamiast /new-section/page-slug/ wyprodukował ścieżki kategorii takie jak /developer-tools/terminals-shell/ i /rag/architecture/. Osiem stron źródłowych zostało zmappowanych na /developer-tools/terminals-shell/ — wszystkie wskazujące na ten sam URL, co byłoby katastrofalne, gdyby zostało użyte. Same /developer-tools/ zebrało pięć oddzielnych stron. Wyjście jest całkowicie nie do użycia.

Dla tego zadania, mniejszy, kwantyzowany Qwen 3.5 27b Q3_XXS dorównał najlepszym modelom w chmurze — podczas gdy dwie kwantyzacje 35b zawiodły bardzo źle, każda na swój sposób.

Podsumowanie

Jestem zadowolony z uruchamiania zarówno Qwen 3.5 35b, jak i Qwen 3.5 27b lokalnie na llama.cpp z wagami kwantyzowanymi — ograniczenia sprzętowe są realne (16 GB VRAM oznacza kwantyzacje IQ3/IQ4), ale przepływ pracy jest solidny.

27b Q3_XXS to niezawodny codzienny model. Dokładnie przestrzega instrukcji, produkuje kompletne wyjście i jest wystarczająco szybki do użycia interaktywnego. W zadaniu mapy migracji dorównał najlepszym modelom w chmurze.

35b jest zdolny, ale nieprzewidywalny w zadaniach strukturalnych. W przypadku otwartego kodowania — napisz mi narzędzie, zbuduj to — wykonuje się dobrze. Ale gdy zadanie ma ścisłe reguły (jak „slug musi pozostać taki sam"), halucynuje swobodnie we wszystkich kwantyzacjach, które przetestowałem: przepisywanie slugów z tytułów, całkowite usuwanie slugów, nawet ciche edytowanie ścieżek źródłowych, aby jego błędne wyjście wyglądało na spójne. Jeśli używasz 35b do czegokolwiek, co produkuje wyjście strukturalne, które planujesz użyć bezpośrednio, wbuduj krok walidacji do swojego przepływu pracy. Nie zakładaj, że wyjście jest poprawne tylko dlatego, że wygląda prawdopodobnie.

Jeśli jesteś ciekawy, z jaką prędkością działają te LLM, sprawdź Najlepsze LLM dla Ollama na 16GB VRAM GPU.