CodeLlama 13B внутри корпоративного контура: VS Code указывает на внутренний endpoint

В августе мы поднимали Llama 2 13B на GPU-сервере внутри DMZ и убеждались, что модель не звонит домой. В октябре строили RAG поверх внутренней документации. Оба раза модель была генерального назначения - хорошо отвечала на вопросы, но про код знала примерно столько же, сколько средний junior в первую неделю.

В конце августа Meta выпустила CodeLlama - семейство моделей на базе Llama 2, дообученных специально на коде. А к октябрю появились вполне рабочие расширения для VS Code, которые умеют бить не в GitHub Copilot, а в произвольный API-совместимый endpoint. Это и стало поводом для нового витка.

Задача клиента

Команда разработки - около пятнадцати человек, пишут преимущественно на Python и Go. Часть команды работает с репозиториями, которые содержат инфраструктурный код с конфигами, адресами, внутренними именованиями. Политика безопасности клиента: этот код не должен уходить ни в какой внешний сервис, включая GitHub Copilot и любые облачные LLM.

GitHub Copilot для них закрыт не потому, что дорогой, а потому что просто закрыт решением ИБ. Альтернатив на рынке немного - и большинство тоже облачные. Локальный code-assistant с внутренним API выглядел как логичный следующий шаг.

Выбор модели

Смотрели на два варианта: CodeLlama от Meta и StarCoder от BigCode. Оба - открытые модели, оба ориентированы на код.

• CodeLlama 13B Instruct - на базе Llama 2, знакомый рантайм, понятная лицензия. Есть Fill-in-the-Middle (FIM) режим, который нужен для автодополнения: модель видит контекст до и после курсора и заполняет середину. 13B в 4-bit GPTQ влезает в 24 GB VRAM с запасом.
• StarCoder 15.5B - обучен на 80+ языках программирования, в том числе на коде из GitHub с открытыми лицензиями. Лицензия BigCode OpenRAIL-M разрешает коммерческое использование с рядом ограничений, которые клиент изучил и счёл приемлемыми. Тоже поддерживает FIM.

Взяли CodeLlama 13B - не потому что StarCoder хуже, а потому что стек уже знаком: тот же llama.cpp, тот же формат GGUF, та же схема деплоя, которую мы уже отладили.

Как устроен стек

Сервер тот же - физическая машина с RTX 4090 24 GB, Rocky Linux 9. Рантайм - llama-cpp-python с выставленным OpenAI-совместимым API на внутреннем порту. CodeLlama 13B в формате GGUF, квантование Q4_K_M - около 8.3 GB VRAM, остаток используем для контекста.

Схема простая:

VS Code (разработчик)
      |  HTTP  (внутренняя сеть)
      v
llama-cpp-python API  :8080
      |
      v
CodeLlama 13B GGUF (RTX 4090)

На стороне VS Code - расширение Continue (open-source, lanceolate.io). Оно поддерживает произвольный OpenAI-совместимый endpoint и умеет в FIM-режим для инлайн-автодополнения. Конфиг занимает буквально десять строк JSON: адрес сервера, имя модели, параметры генерации.

{
  "models": [{
    "title": "CodeLlama 13B (internal)",
    "provider": "openai",
    "model": "codellama-13b",
    "apiBase": "http://10.10.5.42:8080/v1",
    "apiKey": "internal"
  }],
  "tabAutocompleteModel": {
    "title": "CodeLlama 13B FIM",
    "provider": "openai",
    "model": "codellama-13b",
    "apiBase": "http://10.10.5.42:8080/v1"
  }
}

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

Что работает, что нет

Автодополнение строк и небольших блоков - самое сильное место. Питоновские функции, стандартные паттерны, типичные конструкции Go - дополняет уверенно, часто попадает в то, что нужно. Разработчики говорят, что привыкание занимает день-два, после чего Tab начинают нажимать рефлекторно.

Инлайн-чат и объяснение кода - работает, но медленнее и с большими оговорками. На сложных вопросах модель теряется или даёт общий ответ. Это не Copilot Chat с GPT-4 за спиной - возможности принципиально другого порядка.

Специфика клиентского кода - здесь ожидаемо слабее всего. Внутренние пакеты, нестандартные паттерны, самописные DSL - модель их не знает. Автодополнение работает на уровне синтаксиса и общих паттернов, но не понимает бизнес-логику. RAG поверх кодовой базы тут мог бы помочь, но это следующая задача.

Латентность - ощутима. На RTX 4090 подсказка для одной строки появляется примерно за полтора-два секунды, для блока кода - дольше. GitHub Copilot, работающий на инфраструктуре Microsoft, быстрее. Для разработчиков, привыкших к мгновенному отклику, это заметно. Часть команды адаптировалась, часть говорит, что раздражает.

Накладки при развёртывании

Первая проблема случилась на этапе переноса весов. GGUF-файл CodeLlama 13B весит около 8 GB - поехал через бастион как обычный scp, но корпоративный прокси обрезал соединение после нескольких гигабайт. Решилось через rsync с --partial и --append: передаёт по кускам, умеет продолжать с места обрыва.

Вторая - коллизия с антивирусом на рабочих станциях. Continue при установке распаковывает нативные бинарники (Node.js extension хост), и корпоративный AV на нескольких машинах поднял тревогу. Пришли к ИБ, показали исходники, добавили директорию расширения в исключение. Нестандартный сценарий для ИБ-команды клиента, но без конфликта разобрались.

Текущий статус

Расширение установлено у восьми разработчиков из пятнадцати - пока добровольно, принудительного rollout не было. Из восьми четверо используют активно, трое - периодически, один сказал что мешает и выключил. Это нормальное распределение для любого нового инструмента.

Интеграция с рабочим окружением разработчиков в данном случае оказалась нетривиальнее, чем сам деплой модели: Configure extension в VS Code, разобраться с антивирусом, объяснить ИБ что это такое и почему не страшно. Технически это несложно; организационно занимает столько же времени, сколько и всё остальное.

Насколько это реально повышает скорость разработки - честно не знаем. Субъективные ощущения у активных пользователей положительные, но измерить это корректно сложно. Посмотрим ещё месяц.