Локальные модели для программирования на RTX 3060 с 12 ГБ и планировщике моделей

Несколько локальных моделей на одном GPU с 12 ГБ

Запустить одну LLM локально сегодня несложно. Интересное начинается, когда на одной карте с 12 ГБ нужно держать под рукой несколько специализированных моделей: для кода, для рассуждений и для агентной работы.

Представьте вполне обычную машину разработчика: RTX 3060 с 12 ГБ видеопамяти, Ryzen 7 5800, 64 ГБ оперативной памяти и Ubuntu. Цель — не локальное окно чата. Нужны локальные модели, с которыми реально могут работать агенты для программирования вроде OpenCode и другие OpenAI-совместимые инструменты. Значит, в списке требований навыки программирования, вызов инструментов, размер контекста и задержка, плюс ещё одно: переключаться между моделями, не следя за памятью GPU вручную.

На что на самом деле способны 12 ГБ

Современные модели на 7–12 млрд параметров, особенно хорошо квантованные, действительно полезны для программирования на карте с 12 ГБ. Ловушка в том, чтобы гнаться за самой большой моделью, которая загружается. Видеопамять съедают не только веса. Своя доля нужна контексту, KV-кэшу, буферам рантайма и другим процессам на GPU.

Агенты для программирования усугубляют ситуацию: в одном запросе могут оказаться системный промпт, описания инструментов, контекст репозитория, исходные файлы и вся предыдущая переписка, всё вместе.

Правило получше: запускайте самую сильную модель, которая помещается с запасом, а не самую большую, которая формально загружается.

На ограниченном железе обычно лучше выбрать GGUF с llama.cpp: квантование и выгрузка на CPU и в оперативную память дают много пространства для манёвра. На мощных GPU, где важна пропускная способность, привлекательнее SafeTensors с vLLM. И тут возникает следующая головная боль, ведь может понадобиться и то и другое.

Настоящая проблема — переключение

Реалистичному рабочему процессу нужна не одна модель: одна заточена под код, другая под рассуждения, третья проверена на вызов инструментов, ещё нужна модель эмбеддингов и несколько экспериментальных на оценке. 3060 не удержит их все в видеопамяти. И не обязана, если в момент прихода запроса загружена нужная. Желаемое поведение выглядит примерно так:

Request → Model B

А за ним — примерно такой порядок принятия решений:

Model B running?
      │
      No
      ↓
Drain Model A
      ↓
Unload Model A
      ↓
Free VRAM
      ↓
Load Model B
      ↓
Health check
      ↓
Serve request

Иначе говоря, какая модель окажется на GPU, решает запрос. В этот момент задача перестаёт быть про инференс и превращается в планирование.

Почему Ollama или LM Studio этого не покрывают

Оба инструмента очень хороши. Ollama — один из самых простых способов скачать модель и начать ею пользоваться, а LM Studio отлично подходит, чтобы находить, настраивать локальные модели и экспериментировать с ними. И у обоих всё более развитое управление моделями.

Здесь требование немного другое: несколько приложений должны воспринимать весь набор локальных моделей как общую инфраструктуру. Иначе получается куча отдельных портов:

Coding model       → localhost:8081
Reasoning model    → localhost:8082
Experimental model → localhost:8083
vLLM               → localhost:8000

А хочется, чтобы все клиенты обращались к одному эндпоинту:

OpenCode ────┐
AI Agents ───┤
Python SDK ──┼──→ One OpenAI-compatible API
Node SDK ────┤
Apps ────────┘
                    │
                    ▼
              Model Scheduler
                /        \
               /          \
          llama.cpp       vLLM
              │             │
             GGUF      SafeTensors

Клиентам не нужно знать, какой рантайм их обслуживает. Они просят модель, а инфраструктура сама решает, как её запустить.

GGUF Switchboard

Из этой идеи вырос GGUF Switchboard — планировщик моделей с открытым исходным кодом для локальных ИИ-систем. Он предоставляет один OpenAI-совместимый эндпоинт и берёт на себя жизненный цикл моделей. Девиз короткий: один эндпоинт, несколько локальных моделей, а GPU управляет инфраструктура.

Сейчас он сосредоточен на четырёх вещах.

Подбор моделей с учётом железа. Поиск вроде этого не должен просто выдавать все модели Qwen:

ggs models search "qwen"

Он должен подсказать, какие варианты имеют смысл при том объёме оперативной и видеопамяти, который реально есть на машине.

Переключение по запросу. Когда запросу нужна другая модель, Switchboard дожидается завершения текущей нагрузки, выгружает загруженную модель, загружает запрошенную и направляет трафик к ней.

Несколько бэкендов инференса. Каждому формату модели соответствует свой рантайм:

GGUF → llama.cpp
SafeTensors → vLLM

Клиентам не нужна отдельная настройка под каждый рантайм.

Проверка работы с инструментами. Модель, которая пишет хороший код, не становится автоматически надёжной внутри агента. Выбор инструментов, структурированные аргументы и поведение в рантайме стоит проверить, прежде чем доверять модели агентные сценарии.

Разница в одном предложении

Ollama и LM Studio упрощают запуск локальной модели. GGUF Switchboard стремится сделать эксплуатацию целого набора локальных моделей скучной. А на GPU с 12 ГБ скучная инфраструктура — именно то, что нужно.

Где найти

Проект открытый, его тестируют на потребительских машинах и машинах с несколькими GPU. Репозиторий: https://github.com/pradeepgudipati/gguf-switchboard.

Если у вас потребительские карты на 8–16 ГБ, интересные открытые вопросы такие: как вы сейчас работаете с несколькими моделями (одна модель на всё, ручное переключение, управление моделями в Ollama, llama.cpp напрямую, другой планировщик) и какие модели показали себя надёжными в вызове инструментов в OpenCode, Cline, Cursor или похожих агентах. Если какое-то сочетание железа и модели ведёт себя странно, самый полезный отчёт — issue в репозитории с подробностями: проект улучшается именно на реальных конфигурациях.