Локальні моделі для програмування на 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 в репозиторії з подробицями: проєкт покращується саме на реальних конфігураціях.