OpenCode с NorthMiniCode на своем железе

В последнее время большинство обсуждений агентской разработки крутится вокруг Claude Code, Codex, Gemini CLI и других облачных инструментов. Но, с одной стороны, киты индустрии блокируют нам доступы снаружи, с другой — чиновничьи умы блокируют нам доступ изнутри, потому необходимо иметь под рукой локальный инструмент для агентской разработки.

9 июня 2026 вышла модель NorthMiniCode, в отличие от qwen и подобных, специально заточенная под агентские циклы. Планирование, инструменты, редактирование, терминал — это то, на что заточена модель. Подробно разбирать архитектурные особенности будем в следующий раз, а сейчас опишу свой опыт развертывания данной модели и использования ее в OpenCode на домашнем компьютере.

Железо

У меня такой домашний сервер/игровой/медиацентр, на котором гоняются всякие qwen, hashcat, Hermes и подобные, иногда играются StarCraft и каждый день ребёнок гоняет Minecraft и снимает видосы.

Если бы было две 5060 — было бы проще и быстрее. Но их нет. Вообще, для модели рекомендуется минимум одна H100, но ее у меня тоже нет, работаем с тем, что есть.

Настройка среды для инференса

Архитектура модели cohere2_moe в момент моего эксперимента была еще не добавлена в llama.cpp, пришлось собирать версию из PR. На момент написания статьи он уже влит в master, потому можно собирать из него:

git clone https://github.com/ggml-org/llama.cppcd llama.cppcmake -B build -DGGML_CUDA=ONcmake --build build --config Release -j

Если сборка падает с ошибкой «Unsupported gpu architecture», следует обновить драйвер Nvidia и Nvidia CUDA до последней версии.

После успешной сборки:

./build/bin/llama-cli --list-devices

должен показывать все имеющиеся видеокарты.

Качаем модель

Тут все просто, лучший способ — поставить huggungface cli, авторизоваться по токену и скачать GGUF версию в нужную директорию:

hf download unsloth/North-Mini-Code-1.0-GGUF \  --include "North-Mini-Code-1.0-UD-Q4_K_M.gguf" \  --local-dir ~/models/north-mini-code

Разумеется, при более мощном железе можно и нужно искать и качать другие веса.

Запускаем llama сервер

Первым делом следует учесть специфику железа — в случае с несколькими видеокартами правильно распределить по ним модель. В llama.cpp для этого используется параметр tensor-split. Для двух моих видеокарт:

RTX 5060 Ti = 16 GB
RTX 3060 = 12 GB

Правильное значение для этого параметра --tensor-split 16,12что дает нам распределение по картам:

57% -> GPU0
43% -> GPU1

Далее — контекст. Если просто запустить с параметром:

--ctx-size 131072

то в моем случае получается ошибка:

failed to allocate buffer for kv cache

Хотя свободной памяти, казалось бы, достаточно. Лог показал:

n_parallel = 4

То есть llama‑server автоматически создал четыре слота. Каждый слот хранит собственный KV Cache. Фактически я случайно попросил сервер зарезервировать память сразу под четыре независимых сессии. Если не планируется параллельная работа нескольких кодинг‑агентов и нет лишней памяти — это бессмысленно, стоит ограничить флагом:

--parallel 1

Финальная конфигурация запуска для моего железа выглядит так:

./build/bin/llama-server--model /media/storage/models/north-mini-code/North-Mini-Code-1.0-UD-Q4_K_M.gguf  --jinja  --n-gpu-layers 99   --ctx-size 65536--parallel 1  --cache-type-k q8_0  --cache-type-v q8_0  --tensor-split 16,12   --temp 0.2   --top-p 0.9   --top-k 40   --repeat-penalty 1.15   --repeat-last-n 2048   --host 0.0.0.0   --port 8080

Тут нужно прояснить — если модель поддерживает 500к контекста — она поддерживает, но не бесплатно. Каждый дополнительный токен контекста увеличивает KV Cache, который, если отдельно не шаманить, потребляет ту же видеопамять, которую потребляют загруженные веса модели. Поэтому, если с одним экземпляром контекста llama сервер всё равно падает, ругаясь на недостаток память — стоит попробовать уменьшить контекст.

Также можно уменьшить n‑gpu‑layers, уменьшив количество слоёв модели, загружаемых в видеопамять, но это может сильно ударить по производительности — часть слоёв будет лежать в озу и обрабатываться на cpu, мои эксперименты с подобным показали, что в этом случае видеокарты простаивают, ожидая cpu. Хотя, возможно, я чего‑то не знаю и можно это как‑то оптимизировать, глубоко не копал.

Также можно сэкономить видеопамять, увеличив квантование KV‑кешей. Если грубо — суть квантования в переходе с более точного формата на более грубый, от чего незначительно страдает качество ответов.

Подключаем OpenCode

Тут тоже все просто, llama.cpp предоставляет OpenAI-compatible API. Устанавливаем OpenCode, пишем в конфиг:

{  "provider": {    "llamacpp": {      "npm": "@ai-sdk/openai-compatible",      "name": "llama.cpp",      "options": {        "baseURL": "http://127.0.0.1:8080/v1",        "apiKey": "sk-local"      }    }  }}

После этого OpenCode начинает использовать локальную модель как обычный OpenAI API.

Результаты

Итоговая конфигурация:

Под рукой был такой проект:

Проект не маленький, далеко не идеальный, связан с финансами, в общем, близок к боевому проду. Нужно было добавить новую фичу — форму редактирования транзакции. Фаза планирования прошла успешно, связка OpenCode + NorthMiniCode успешно определила недостающие endpoints в backend части, позадавала вопросы о том, как будем реализовывать. На фазе реализации началось странное:

Модель начала зацикливаться, но это вылечилось корректировкой параметра –repeat-penalty и более не повторялось. Работа пошла:

Довольно интересно наблюдать за работой видеокарт при исполнении задачи, можно заметить рывки и приседания при вызове тулзов:

По итогу OpenCode бодро отчитался о результатах:

Но ревью показало, что результаты хоть и работоспособны, но не идеальны, забылось несколько старых импортов в TypeScript коде, размылись архитектурные границы. После фидбека OpenCode так же бодро все поправил. Задача решена, фича добавлена, NorthMiniCode работает.

Итог

В итоге мы имеем инструмент, способный на обычном домашнем компьютере помогать с планированием и писать код на уровне бухого мидла. Планирование и самопроверка — не самая сильная сторона NorthMiniCode, тут, возможно, стоит поэкспериментировать с другими моделями. Если углубится в эксперименты с квантированием и поглубже закопаться в llama.cpp — возможно, можно выжать ещё больше.

Пока оно у меня работает только на персональных проектах, в режиме «запустил проработанный заранее подробный план в ralphex loop и забыл до вечера». Но и в таком варианте это работает лучше, чем кодинг-агенты всего год назад. Полновесной заменой ClaudeCode или Codex это назвать сложно — нужно больше ревью, нужен более ответственный подход к планированию. Однако экономия времени налицо.

Сам факт self-hosted решения на таких мощностях дает надежду на скорое избавление от зависимости от воли нескольких крупных корпораций.

Иметь под рукой не зависящую от интернет-соединения вообще штуку, которая может быстро автоматизировать небольшой фикс/фичу/рефакторинг — бесценно.