Лучшие LLM для OpenCode — протестированы локально

Я протестировал, как работает OpenCode с несколькими локальными LLM на базе Ollama, и для сравнения добавил несколько бесплатных моделей из OpenCode Zen.

OpenCode — один из самых перспективных инструментов в экосистеме инструментов для разработчиков ИИ на данный момент.

TL;DR — Лучшие LLM для OpenCode

Безусловный лидер для локального использования: Qwen 3.5 27b Q3_XXS на llama.cpp

Модель 27b с квантованием IQ3_XXS обеспечила создание полностью рабочего Go-проекта: все 8 тестов прошли успешно, создан полный README, а скорость на моей конфигурации с 16 ГБ VRAM (смешанный режим CPU+GPU) составила 34 токена в секунду. Пять звезд, никаких оговорок. Это мой основной выбор для локальных сессий OpenCode.

Qwen 3.5 35b на llama.cpp — быстро для кодинга, но требующий проверки

Модель 35b отлично подходит для быстрых задач агентного программирования — однако мои тесты с картой миграции выявили серьезную проблему с надежностью. В двух запусках с квантованием IQ3_S она показала 63–73% несоответствий в слагах (slug), а при квантовании IQ4_XS модель вообще забыла включить слаг страницы, генерируя пути категорий, которые отображали бы 8 разных страниц на один и тот же URL. Качество кодинга в задаче IndexNow было действительно хорошим, поэтому модель стоит использовать — но никогда не доверяйте её выходным данным в структурированных задачах с соблюдением правил без проверки. Валидация обязательна.

Удивительно хорошие результаты: Bigpicle (из OpenCode Zen)

Самая быстрая модель для выполнения задачи — 1 минута 17 секунд. Что еще более важно, это единственная модель, которая перед написанием кода остановилась и действительно поискала спецификацию протокола IndexNow с помощью Exa Code Search. Она нашла все правильные конечные точки с первого раза. Если у вас есть доступ к OpenCode Zen, этот вариант значительно превосходит свои ожидания.

Хорошо, но только с высоким режимом мышления: GPT-OSS 20b

В режиме по умолчанию GPT-OSS 20b терпит неудачу — он натыкается на тупиковые вызовы WebFetch и останавливается. Переключение на режим высокого мышления превращает его в действительно способного ассистента по программированию: полный разбор флагов, правильная логика пакетной обработки, прохождение тестов — все это выполняется быстро. Учитывайте это, прежде чем списывать её со счетов. GPT-OSS 20b не справился со структурированными задачами даже в режиме высокого мышления.

Пропустите для агентного программирования: GPT-OSS 20b (по умолчанию), Qwen 3 14b, devstral-small-2:24b

Раньше они были моими фаворитами для скорости в чате и задачах генерации. Но в агентном режиме у всех них есть реальные проблемы. Qwen 3 14b галлюцинирует документацию, вместо того чтобы признать, что не может найти информацию. GPT-OSS 20b (по умолчанию) зависает при сбое WebFetch. Devstral запутывается в базовых операциях с файлами. Для OpenCode конкретно качество следования инструкциям и вызова инструментов гораздо важнее, чем чистая скорость.

Об этом тесте

Я дал каждой модели, работающей в opencode, две задачи/подсказки:

1. Создай мне CLI-инструмент на Go, который будет вызывать конечные точки indexnow поисковых систем Bing и других, чтобы уведомлять об изменениях на моем сайте.
2. Подготовить карту миграции сайта.

Вы знаете, что такое протокол Indexnow, верно?

Для второй задачи у меня есть план миграции некоторых старых статей на этом сайте с формата URL для блогов (например, https://www.glukhov.org/post/2024/10/digital-detox/) на тематические кластеры (как URL этой статьи: https://www.glukhov.org/ai-devtools/opencode/llms-comparison/). Поэтому я попросил каждую LLM в OpenCode подготовить для меня карту миграции согласно моей стратегии.

Большинство LLM я запускал на локальном хостинге Ollama, а некоторые другие — на локальном llama.cpp. Модели Bigpicle и другие очень большие языковые модели были получены из OpenCode Zen.

Результаты по каждой модели

qwen3.5:9b

Полный провал в первой задаче. Модель прошла через процесс мышления — правильно определив релевантные сервисы (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex) — но так и не вызвала ни одного инструмента. Она создала сводку “Build”, не коснувшись ни одного файла. Ни одного вызова инструмента.

qwen3.5:9b-q8_0

Шаг вперед по сравнению с квантованием по умолчанию: она хотя бы создала файлы go.mod и main.go. Но затем она сразу же застряла, признала необходимость добавить отсутствующие импорты, попыталась переписать весь файл, используя shell heredoc — и провалилась. Время сборки составило 1 минуту 27 секунд для того, что не работало.

Qwen 3 14b

Классическая галлюцинация под давлением. Она пыталась получить документацию IndexNow трижды подряд, каждый раз получая 404 с неверного URL (github.com/Bing/search-indexnow). Вместо того чтобы признать, что ничего не может найти, она сфабриковала уверенно звучащий ответ — неверный API-конечный пункт, неверный метод аутентификации. Когда я заставил её искать снова, она выдала второй сфабрикованный ответ, указывающий на еще один URL, который также возвращает 404. Информация, которую она сообщила, была неверной. Это тот режим отказа, которого я больше всего хочу избежать.

GPT-OSS 20b

Хотя бы поведение было честным и методичным. Она попробовала длинную цепочку вызовов WebFetch — indexnow.org, различные репозитории GitHub, собственные страницы Bing — и получила 404 или блокировки Cloudflare почти везде. Она прозрачно задокументировала каждый провал. В конце концов, она так и не смогла собрать достаточно информации для создания рабочего инструмента, но в отличие от Qwen 3 14b, она ничего не выдумала. Просто не смогла продвинуться дальше.

GPT-OSS 20b (высокий режим мышления)

Значительно другая история по сравнению с режимом по умолчанию. При включенном высоком режиме мышления модель восстановилась после тех же тупиковых запросов и создала полностью рабочий инструмент — с правильным разбором флагов (--file, --host, --key, --engines, --batch, --verbose), GET для одиночных URL и POST-пакетами для нескольких, согласно спецификации IndexNow.

Когда я попросил документацию и тесты, она предоставила и то, и другое. Тесты прошли:

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

Быстро тоже — начальная сборка за 22,5 секунды. Высокий режим мышления делает gpt-oss:20b действительно пригодным для использования.

qwen3-coder:30b

Самый интересный провал. Она действительно скомпилировала и запустила инструмент против реальных конечных точек, увидела реальные ошибки API от Bing, Google и Yandex и начала их исправлять:

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"

Это хороший инстинкт. Проблема: она работала на 720% CPU и лишь 7% GPU — крайне неэффективно для модели размером 22 ГБ. Это заняло 11 минут 39 секунд, а финальный результат все еще был «не совсем то, что ожидалось». Она также создала README.md, что является приятным штрихом. Модель не плохая, просто очень медленная на моей конфигурации, и она не полностью разобралась с форматом протокола IndexNow.

qwen3.5:35b (Ollama)

Надежные результаты, но медленно. Она создала правильный Go-проект, написала тесты, и все они прошли:

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

Минус: время сборки 19 минут 11 секунду. Для модели размером 27 ГБ с распределением CPU/GPU 45%/55% это слишком медленно для интерактивного использования. Качество есть, но задержка убивает рабочий процесс.

Bigpicle (big-pickle)

Ярко выделяющийся исполнитель для первой задачи. Прежде чем написать хоть строку кода, она использовала Exa Code Search, чтобы действительно исследовать протокол IndexNow:

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

И она нашла правильные конечные точки:

• 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

Она чисто решила проблему импорта cobra (go mod tidy), и инструмент был готов за 1 минуту 17 секунд. Ответ о лимите скорости, который она получила от Bing во время тестирования, был ожидаемым поведением для невалидного тестового ключа — модель правильно определила это как «инструмент работает». Впечатляюще.

devstral-small-2:24b

Запуталась на базовом уровне: она попыталась записать команды оболочки (go mod init indexnowcli, go mod tidy) прямо в файл go.mod, вызвав ошибки парсинга. Каким-то образом она все же сумела собрать бинарный файл (7.9 МБ), но полученный CLI был слишком простым — только indexnowcli <url> <key> без обработки флагов, без поддержки нескольких движков и ничего. Заняло 2 минуты 59 секунд + 1 минуту 28 секунд, чтобы получить инструмент, который на самом деле не был полезен.

qwen3.5:27b (llama.cpp, квантование IQ3_XXS)

Эта модель впечатлила меня больше всего среди всех локальных исполнителей. Запускаясь как Qwen3.5-27B-UD-IQ3_XXS.gguf на llama.cpp (в основном на CPU), она создала полный инструмент с полным покрытием тестов — все 8 тестов прошли — и правильный README с инструкциями по установке и объяснением протокола:

PASS    indexnow    0.003s

Поддерживаемые движки: Bing, Yandex, Mojeek, Search.io. Время сборки: 1 минута 12 секунд для инструмента, 1 минута 27 секунд для тестов и документации. Скорость: 34 токена в секунду. Качество: 5 звезд. Непревзойденный результат для квантованной модели, работающей на CPU+GPU.

qwen3.5:35b (llama.cpp, квантование IQ3_S)

Запускается как Qwen3.5-35B-A3B-UD-IQ3_S.gguf на llama.cpp. Мои заметки здесь кратки: «отлично!» — это говорит само за себя. Более крупная модель при том же уровне квантования показала результаты, не менее хорошие, чем вариант 27b, если не лучше.

Результаты карты миграции

Для второй задачи я запустил отдельную партию — 7 моделей, всем были даны одинаковые инструкции, структура сайта и список страниц. Ограничение было явным: слаг (последний сегмент пути) должен оставаться неизменным. Например, /post/2024/04/reinstall-linux/ должно стать /.../reinstall-linux/, а не чем-то другим.

Я измерил, сколько несоответствий слага каждая модель произвела — случаи, когда сгенерированный целевой слаг отличался от исходного слага.

Модель	Строк	Несоответствия слага	Процент ошибок
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 - второй запуск (llama.cpp)	81	51	63.0%
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98.8%

Одна вещь, которую все 7 моделей сделали идентично: старые URL в формате 2022 года имели префикс месяца, встроенный в слаг (например, /post/2022/06-git-cheatsheet/ → слаг 06-git-cheatsheet). Каждая модель убрала этот префикс и использовала git-cheatsheet в качестве нового слага. Это 4 последовательных несоответствия в трех лучших моделях — так что их базовая линия составляет 4 ошибки каждая, а не ноль.

Настоящее расхождение начинается выше этой базовой линии. minimax-m2.5-free, Nemotron 3 и Qwen 3.5 27b Q3_XXS нарушали правило слага только на этих 4 устаревших путях — ничего больше. Qwen 3.5 27b Q3_M добавил еще 2 (переименовал слаг статьи cognee и перевел в нижний регистр Base64). Bigpicle добавил еще 5 сверх 4, в основном укорачивая длинные слага.

Аутсайдеры относятся к другой категории. Qwen 3.5 35b IQ3_S последовательно переписывала слага из заголовков страниц, вместо того чтобы сохранять исходные (например, 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). Второй запуск был немного лучше (51 против 59), но показывал то же поведение. Она также галлюцинировала исходный путь: она тихо изменила comparing-go-orms-gorm-ent-bun-sqlc на comparing-go-orms-gorm-ent-bun-sql (убрав букву c), так что обе стороны этой строки согласовались друг с другом — но были обе неверны. mimov2 был так же агрессивен в укорачивании: gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

Квантование IQ4_XS модели 35b относится к совершенно другой категории сбоев: 98.8% несоответствий слага — но проблема не в неправильных слага, а в том, что модель забыла включить слага вообще. Вместо /new-section/page-slug/ она производила пути категорий, такие как /developer-tools/terminals-shell/ и /rag/architecture/. Восемь исходных страниц оказались отображены на /developer-tools/terminals-shell/ — все указывающие на один и тот же URL, что было бы катастрофой при использовании. Только /developer-tools/ собрал пять отдельных страниц. Выходные данные полностью непригодны для использования.

Для этой задачи меньшая квантованная модель Qwen 3.5 27b Q3_XXS соответствовала лучшим исполнителям — в то время как две квантования 35b провалились ужасно, каждый по-своему.

Вывод

Я с удовольствием использую как Qwen 3.5 35b, так и Qwen 3.5 27b локально на llama.cpp с квантованными весами — аппаратные ограничения реальны (16 ГБ VRAM означает квантования IQ3/IQ4), но рабочий процесс надежен.

27b Q3_XXS — надежный повседневный инструмент. Она точно следует инструкциям, производит полный вывод и достаточно быстрая для интерактивного использования. В задаче карты миграции она соответствовала лучшим облачным моделям.

35b способен, но непредсказуем в структурированных задачах. Для открытого кодинга — напиши мне инструмент, создай это — он выполняет работу хорошо. Но когда задача имеет строгие правила (например, «слаг должен оставаться тем же»), он свободно галлюцинирует во всех квантованиях, которые я тестировал: переписывая слага из заголовков, полностью опуская слага, даже тихо редактируя исходные пути, чтобы сделать свой неверный вывод выглядящим самосогласованным. Если вы используете 35b для чего-либо, что производит структурированный вывод, который вы планируете использовать напрямую, встройте шаг валидации в свой рабочий процесс. Не предполагайте, что вывод корректен только потому, что он выглядит правдоподобно.

Если вам любопытно, с какой скоростью работают эти LLM, ознакомьтесь с Лучшими LLM для Ollama на GPU с 16 ГБ VRAM.