Локальные модели для кода: когда это оправдано

Допустим, вы попросили модель дописать тест для одной функции. Она ответила быстро, тест прошёл, ноутбук почти не нагрелся. На следующей задаче ей понадобились пять файлов, история диалога и лог сборки. Ответ пришлось ждать, IDE начала тормозить, а исправление потеряло важное условие.

Оба результата могут относиться к одной локальной модели. Рабочий сценарий определяется размером входа, инструментами и ценой проверки результата. Поэтому сначала стоит выбрать задачу, которую вы хотите перенести на свой компьютер, и только потом — модель.

Когда локальный запуск приносит пользу

Я бы проверял его в трёх ситуациях.

Код должен оставаться внутри определённого контура. Например, команда разрешает обрабатывать репозиторий на рабочей станции, но запрещает отправлять его внешнему провайдеру. Тогда сначала проверяют допустимость всей цепочки: модель, редактор, журналы, подключённые инструменты. Разрешение на локальную модель само по себе не разрешает остальные способы обработки данных.

Есть много однотипных коротких задач. Черновики тестов, объяснение небольшого фрагмента, преобразование формата. Для такого пилота легко заранее определить правильный результат и посчитать, сколько времени ушло на исправления.

Нужна работа без сети. Здесь важно заранее скачать всё необходимое и проверить именно свой сценарий: ответ в чате, поиск по файлам, запуск тестов. Зависимость от внешней документации или удалённого инструмента может остаться.

Если код разрешено отправлять выбранному провайдеру, задачи редкие, а основную сложность составляет поиск причины между несколькими сервисами, облачный инструмент тоже стоит включить в сравнение. Как организовать такой выбор, разобрано в статье про Cursor, Claude Code и Windsurf.

Модель, сервер и агент — три разных выбора

Модель содержит веса и умеет продолжать текст в формате, на котором её обучали. Сервер инференса загружает её и обрабатывает запросы: в примере ниже это Ollama. Агент выбирает файлы, вызывает инструменты, применяет изменения и решает, что делать дальше.

Замена адреса API не переносит автоматически все возможности облачного агента на ноутбук. Клиент должен корректно передавать инструкции, историю и вызовы инструментов, а модель — справляться с этим форматом. Для автодополнения внутри файла нужен свой сценарий проверки; удачный диалог о коде его не заменяет.

Начните с обычного запроса к модели. Подключайте редактор или агента после того, как понятны качество ответа и задержка. Это помогает различать ошибку модели и ошибку интеграции. Подробнее о цикле «модель → инструмент → результат» — в разборе AI-агентов.

Сколько памяти нужно: смотрите на сборку и контекст

Для первой оценки веса можно считать так: число параметров × число бит на параметр ÷ 8. У условной модели с 8 млрд параметров при ровно 4 битах получилось бы 4 ГБ. Это упрощённый расчёт: реальные форматы хранят дополнительные данные, а разные части модели могут иметь разную точность.

Квантование уменьшает объём весов за счёт представления чисел с меньшей точностью. Например, llama.cpp поддерживает несколько вариантов квантования и работу на CPU, GPU или их сочетании. Выбранную сборку всё равно нужно проверять на качестве нужных вам задач.

Два конкретных примера из каталога Ollama на 12 октября 2026 года:

Размеры проверяются по карточкам Qwen2.5-Coder 7B и Qwen3-Coder 30B. У второй модели около 30 млрд параметров, из которых на токен активируется около 3,3 млрд. Число активных параметров описывает вычисления, но не означает, что вся модель занимает память как модель на 3,3 млрд параметров.

К весам при работе добавляются KV-кэш — данные о контексте для генерации следующих токенов — и служебная память. Оставьте место для операционной системы, редактора и сервисов проекта. У дискретной видеокарты отдельно смотрят VRAM и оперативную память; в системе с унифицированной памятью приложения конкурируют за общий объём.

Из размера файла нельзя вывести обещание «точно работает на ноутбуке с N ГБ». Проверяйте под рабочей нагрузкой: модель вместе с IDE, браузером и запущенным проектом.

Большое окно контекста ещё нужно настроить

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

В Ollama размер можно явно задать через options.num_ctx. Команда ollama ps показывает, как загруженная модель распределена между CPU и GPU. Параллельные запросы тоже увеличивают потребление памяти — эти настройки описаны в FAQ Ollama.

Для первого прохода возьмите одну задачу и ограниченный набор файлов. Затем повторите её с типичным для работы объёмом контекста. Если короткий пример проходит, а реальный — нет, зафиксируйте это как границу применения. Обрезанный вход нельзя считать полноценной проверкой репозитория.

Первый запрос через Ollama

Пример рассчитан на установленный Ollama. Если его сервер уже работает, остановите его перед ручным запуском с новыми параметрами. В терминале запустите сервер:

OLLAMA_NO_CLOUD=1 OLLAMA_HOST=127.0.0.1:11434 ollama serve

Переменная отключает облачные функции именно у процесса сервера. Для фоновой службы или приложения настройте её в окружении этого процесса и перезапустите его. В журнале должна появиться строка Ollama cloud disabled: true; соответствующий параметр и способы настройки приведены в документации.

В другом терминале скачайте сборку и посмотрите её параметры:

ollama pull qwen2.5-coder:7b
ollama show qwen2.5-coder:7b

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

curl --fail-with-body --silent --show-error \
  http://127.0.0.1:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen2.5-coder:7b",
    "prompt": "API возвращает объект {items: [{id: 1, name: \"Анна\"}], total: 1}. Ошибочный клиент: function names(data) { return data.map(x => x.name) }. Исправь функцию и предложи два теста: непустой и пустой items. Сохрани исходный контракт API.",
    "stream": false,
    "keep_alive": "5m",
    "options": {
      "temperature": 0,
      "num_ctx": 8192,
      "num_predict": 512
    }
  }' > local-coding-result.json

Здесь ограничены контекст и длина генерации, а stream: false возвращает один JSON. Если ответ закончился из-за лимита генерации, он может быть неполным: проверьте done_reason и сам результат. Нулевая температура не заменяет проверку корректности.

В ответе API есть load_duration, prompt_eval_duration, eval_duration и eval_count. Длительности указаны в наносекундах. Скорость генерации можно посчитать как eval_count / (eval_duration / 1e9), когда длительность больше нуля. Значение полей описано в справочнике API.

Повторите запрос, пока модель остаётся загруженной, и сравните с первым запуском. Сохраняйте оба результата: загрузка весов влияет на редкие обращения. Этот запрос без стриминга показывает время завершения ответа; для измерения времени до первого токена нужен отдельный замер со стримингом.

Проверка на задачах IT-X: контракт между Go и TypeScript

В IT-X Go API и три фронтенда. Публичный список менторов возвращается в объекте с items и total; клиент платформы описывает такой же контракт. Это удобная основа для учебного задания: модель должна сохранить согласованность между ответом сервера и потребителем.

Ошибочная функция в запросе выше придумана специально для проверки. Она не означает, что сейчас в продукте есть такой баг. Здесь мы предлагаем протокол пилота, а результаты скорости и качества нужно получить на своём оборудовании.

Начните с двух условий приёмки: при одном элементе функция возвращает его имя, при пустом items — пустой массив. Модель не должна менять API на массив, чтобы оправдать исходный клиент.

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

Оценивайте три результата отдельно:

1. Поняла ли модель контракт в небольшом текстовом примере.
2. Нашла ли нужную связь в контексте файлов.
3. Получился ли проверенный патч через выбранного агента.

Соберите около 20 заданий из своего проекта: тесты на границы, небольшие исправления, объяснение кода, изменения между двумя слоями. Это стартовый набор для поиска ограничений, а не доказательство превосходства модели. Сохраняйте исходный коммит, сборку модели, настройки, переданный контекст, число попыток и время ручной доработки. Требования к результату удобно брать из чек-листа ревью AI-кода.

Приватность проверяется по всему маршруту кода

Для локального запуска Ollama сообщает, что не получает ваши промпты и данные. У облачной модели запрос обрабатывается внешним сервисом. Это различие описано в FAQ, и его нужно учитывать при выборе модели.

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

Когда агент умеет выполнять команды, значение имеют и его права. Локальная модель с доступом к секретам и сети может выполнить нежелательное действие. Практические границы инструментов и окружения разобраны в статье про AI-агентов в CI.

Как посчитать стоимость принятой задачи

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

Возьмём условный месячный расчёт. Все цифры придуманы для примера, час работы в обоих вариантах оценён в 1000 ₽:

• Облако: 4000 ₽ за сервис и 2 часа проверки — 6000 ₽.
• Локально: 1500 ₽ амортизации, 300 ₽ электричества, 1000 ₽ доли настройки, 1 час обслуживания и 4 часа проверки — 7800 ₽. Настройка в примере стоила 6000 ₽ и распределена на шесть месяцев.

При одинаковых 20 принятых задачах это 300 ₽ и 390 ₽ за задачу соответственно. Измените время ручной доработки или используйте уже оплаченное оборудование — результат изменится. Важно не терять эти статьи расходов из расчёта.

Задача считается принятой после проверки исходного требования. Скомпилировавшийся ответ с ослабленным тестом не увеличивает число принятых задач. Если результат не получен, затраты на попытки всё равно остаются.

Для общего сервера добавьте очередь и конкуренцию пользователей. Один быстрый запрос не показывает задержку, которую получит команда утром. Такой сценарий проверяют отдельно от одиночного запуска на ноутбуке.

Какое решение принять после пилота

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

Если модель постоянно требует ручного восстановления контекста или мешает работе IDE, сначала сузьте задачу и проверьте настройки. Покупку оборудования имеет смысл обсуждать после замера, который показывает конкретное ограничение памяти или скорости.

Для совместного разбора модели, контекста и качества патчей посмотрите практику вайбкодинга в IT-ХОЗЯЕВА и менторов сообщества. На такой разбор полезно принести несколько одинаково поставленных задач и их результаты: тогда обсуждение быстро переходит от впечатлений к конкретным исправлениям процесса.