Qwen Code локально означает, что кодовый агент работает в вашем терминале, а подсказки пишет открытая модель, запущенная на вашем компьютере или сервере, и код проекта остаётся внутри контура. Подключение делается через совместимый адрес локального сервера, а цена вопроса складывается из двух частей: качество модели на ваших задачах и дисциплина проверки результата. Путь оправдан там, где данные выносить нельзя, а слабость небольшой модели вы готовы компенсировать ревью.
Локальный путь
По документации Qwen Code, локальный сервер подключается в файле настроек как провайдер с типом openai, адресом вашего сервера и именем модели. Имя переменной с ключом задаётся полем envKey, а для сервера без авторизации ключ обычно формальный.
Облачный вариант устроен проще: вы входите в учётную запись, и запросы уходят вендору. Локальный вариант меняет два обстоятельства. Во-первых, код проекта остаётся в вашей сети, и это главное основание им пользоваться. Во-вторых, качество и скорость определяются вашим оборудованием и выбранной моделью, а значит, ответственность за них лежит на вас.
Общий обзор агента и его границ мы давали в статье про Qwen Code для программирования в компании, а выбор кодовой модели для собственного сервера — в материале про Qwen Coder на своём сервере. Здесь разбирается только связка: как соединить агента с локальным сервером и принять работу.
Выбирайте локальный режим, когда есть причина: требования к хранению данных, закрытые алгоритмы, ограничения заказчика, изолированная сеть. Без такой причины облачный путь даёт лучшее качество при меньших хлопотах, и признать это полезнее, чем держать сервер ради принципа.
Перед стартом откройте документацию Qwen Code: имена полей и способы входа меняются. Описанные ниже принципы от версии к версии сохраняются, а точные названия сверяйте на месте.
Подключение модели
Локальные серверы вроде Ollama, vLLM и LM Studio отдают модель по совместимому с OpenAI адресу; в документации Qwen Code для них приведены типовые адреса на локальном компьютере с портами 11434, 8000 и 1234. Агент подключается к такому серверу через раздел modelProviders файла настроек.
| Поле | Что задаёт | На что смотреть |
|---|---|---|
| id | Имя модели на вашем сервере | Совпадает ли с тем, что сервер реально загрузил |
| baseUrl | Адрес локального сервера | Нужен корень адреса с /v1, а полный путь запроса указывать нельзя |
| envKey | Имя переменной окружения с ключом | Для сервера без авторизации ключ обычно формальный, а сама переменная должна быть задана |
| generationConfig | Таймауты и параметры генерации | Задавайте при медленном железе и длинных ответах |
| Выбор модели | Команда /model в сеансе | Переключение в сеансе, выбор запоминается в настройках |
Ключи храните в файле .env проекта, в поле env файла настроек или в переменных окружения системы. Первый вариант документация называет предпочтительным по безопасности, если файл исключён из репозитория. Для локальной модели ключ часто формальный, но привычку отделять секреты от настроек лучше сохранить с первого дня.
На медленных серверах агент может обрывать долгие ответы по таймауту. Для таких случаев в настройках есть параметр ожидания простоя потока, и его увеличивают, если генерация идёт, но запрос закрывается раньше конца. Подробности запуска самого сервера смотрите в материалах про Ollama API и vLLM в контейнере.
Граница данных
Локальная модель сама по себе защиту обеспечивает лишь частично: данные остаются внутри контура только тогда, когда внутри остаётся весь маршрут запроса. Проверьте его целиком.
- Адрес сервера: убедитесь, что baseUrl ведёт на машину в вашей сети, а внешние сервисы с похожим интерфейсом исключены.
- Сетевой доступ: закройте исходящие соединения агента на время работы с секретными проектами и проверьте, что сеанс продолжает работать.
- Другие провайдеры: уберите из настроек облачные модели, чтобы при случайном выборе в /model код оставался внутри контура.
- Серверы MCP: каждый внешний инструмент возвращает вопрос о границе, поэтому подключайте только внутренние.
- Журналы: сервер модели пишет запросы в логи, а значит, их хранение и доступ к ним нужно закрыть.
Проверку маршрута делают один раз на проект: запустите агента и посмотрите сетевые соединения его процесса, чтобы убедиться, что запросы идут только на ваш сервер. Повторяйте проверку после смены настроек или обновления агента, потому что новая версия может добавить собственные обращения.
Отдельно решите, какие репозитории допустимо открывать агенту. Персональные данные клиентов, секреты и закрытые алгоритмы лучше держать в проектах, где локальный режим включён и проверен. Этот вопрос полезно закрепить в политике использования ИИ, и тогда сотрудникам незачем решать его каждый раз заново.
Проверка кода
Открытая модель среднего размера нередко слабее облачной на сложных задачах, и это нормально. Важно знать, где проходит граница: на каких задачах её результат можно принимать после беглого ревью, а на каких он годится только как черновик.
- Соберите десять-пятнадцать реальных задач из своего репозитория разной сложности: исправление ошибки, тест, небольшой рефакторинг, документация.
- Для каждой запишите проверяемый признак готовности, например тест, который должен пройти.
- Прогоните набор на локальной модели и, если допустимо, на облачной, фиксируя верность результата и время.
- Прочитайте diff каждого результата и отдельно изучите изменения в тестах: подгонка под проверку встречается часто.
- Определите уровень задач, которые локальная модель закрывает надёжно, и закрепите его в регламенте команды.
Скорость ответа зависит от видеопамяти и размера модели. Агент делает много обращений за одну задачу, поэтому задержка накапливается, и медленный сервер превращает полезный инструмент в раздражающий. Замерьте время на типовой задаче заранее и решите, приемлемо ли такое ожидание для разработчика, который сидит над задачей.
Сравнение двух вариантов на одном наборе даёт честную картину. Если локальная модель справляется с рутиной, а сложное уходит к человеку или в облако без секретов, схема работает. Если ревью съедает всю выгоду, выбирайте модель крупнее или пересматривайте набор задач.
На каких задачах локальная модель должна справляться сама?
Первая неделя
По итогам первой недели посчитайте долю задач, которые локальная модель закрыла с минимальной правкой, и время, потраченное на ревью. Оценка по одной удачной демонстрации обманывает: доступ расширяют только после того, как набор задач показал реальный уровень.
Обновление модели — отдельное решение. Новая версия способна улучшить одно и ухудшить другое, поэтому её сначала подключают рядом со старой, прогоняют тестовый набор и переключают команду после сравнения. Предыдущую версию держите на сервере: тогда откат сводится к переключению модели.
Версия модели, параметры генерации и набор задач, записанные в одном месте, превращают сравнение новой версии через месяц в обычный повторный прогон.
Из наблюдений вырастает практичная схема: простые и чувствительные задачи идут на локальную модель, остальное решает человек. Регламент фиксирует допустимые проекты, уровень ревью и порядок обновления модели. Когда внутри компании нет своей экспертизы по серверам и моделям, помощь с выбором и проверкой даёт консалтинг по внедрению ИИ, а подробности запуска открытых весов собраны в статье про локальный запуск Qwen.