Локальные LLM для кода: месяц на Qwen3-Coder и DeepSeek без облака
В мае мы решили провести эксперимент, который давно висел в воздухе: месяц команда Quillon работала без облачных LLM. Никаких Claude, GPT или Cursor с подпиской. Только две локальные модели на железе, которое можно купить и поставить в офисе: Qwen3-Coder-30B и DeepSeek-Coder-V2-Lite в квантизации Q5.
Причин было две. Первая — деньги. Подписки на облачные ассистенты для десяти человек обходятся уже дороже зарплаты опытного разработчика. Вторая — конфиденциальность. Нам всё чаще задают вопрос: можем ли мы гарантировать, что код клиентов не утечёт в чужой датасет? Раньше мы разводили руками. Теперь хотели ответить честно.
Дальше — рассказ о том, что получилось, что сломалось, и где локальные модели в 2026 году дотягивают до облачных, а где нет.
Железо и почему мы выбрали именно эти модели
Стенд собирали на базе того, что уже было в офисе, с небольшим дополнением. Для тяжелых задач — двухсокетный Epyc с 256 ГБ оперативной памяти и двумя RTX 6000 Ada по 48 ГБ. На ней запустили основную инференс-ноду через vLLM. У отдельных членов команды были Mac Studio M3 Ultra с 192 ГБ объединенной памяти, на которых через MLX запускали квантованные версии моделей напрямую.
Qwen3-Coder-30B-A3B выбрали, потому что это MoE (Mixture of Experts): активных параметров всего три миллиарда, а на M3 Ultra она выдаёт около 60 токенов в секунду в Q5. Это комфортно для интерактивной работы. Полная 480B-версия даже в низкобитном кванте (3-bit) еле помещается в 192 ГБ, и места под приличный контекст почти не остаётся — поэтому для повседневной работы от неё отказались в пользу 30B.
DeepSeek-Coder-V2-Lite взяли как второй взгляд. Это тоже MoE — 16 миллиардов параметров, из них активных всего 2.4 миллиарда, контекст 128k. Она заточена под код, в некоторых задачах даёт иную, чем Qwen, формулировку решения, что и ценно для второго мнения. По контексту, кстати, Qwen даже шире — у Qwen3-Coder-30B нативные 256k против 128k у DeepSeek, так что брали её не ради длины окна, а именно ради другого «характера» ответов.
Сразу скажу, о чём редко пишут в обзорах: разница между Q4 и Q8-квантизациями в реальной разработке ощутимая. На синтетических бенчмарках она почти незаметна, а вот на живом коде Q4 начинает терять контекст функции уже на 600-й строке, путать импорты и выдумывать методы фреймворка, которых нет. Q5 — разумный компромисс. Q8 — золотой стандарт, но для него уже нужны два M3 Ultra или серверная видеокарта.
Первая неделя: эйфория, а потом — реальность
Первые три дня было ощущение, будто нашли что-то волшебное. Локальная модель отвечает мгновенно, без ожидания, без лимитов. Ребята в чате активно делились впечатлениями: «написала мне полноценный CRUD на FastAPI за один промпт», «разобрался с куском легаси-кода на Go, который я неделю боялся трогать».
Но к концу четвёртого дня эйфория стала спадать.
Первой проблемой стала работа с большими кодовыми базами. У нас есть проект на Flutter объёмом примерно 80 тысяч строк. Когда инженер просил Qwen «посмотри, почему роутинг ломается после обновления go_router до 14-й версии» и подкладывал два десятка файлов — модель путалась. Она запоминала первые файлы, забывала средние и вместо решения предлагала код, который противоречил тому, что было в коде ближе к концу.
DeepSeek-Coder-V2-Lite на тех же задачах вела себя чуть иначе — другой почерк, иногда удачнее цеплялась за нужный файл. Но и она начинала плыть задолго до заявленного окна: на 50-60 тысячах токенов реального кода связность падала, хотя в паспорте честные 128k.
Вывод первой недели: с локальными моделями нужно перестать «скидывать весь проект на подумать». Облачный Claude это как-то прощает (хотя и не любит). Локальной модели такое не подходит. Контекст нужно готовить вручную — вырезать нужные функции, четко давать определения типов и не давать ей всё подряд.
Что заработало как надо
К концу второй недели команда адаптировалась, и задачи распределились так.
Локальные модели отлично закрывают «тактику»: дописать функцию, переписать кусок в другом стиле, объяснить незнакомый API, сгенерировать юнит-тесты, найти опечатку. Тут Qwen3-Coder работает на уровне GPT-4-Turbo полгода назад, и для повседневной разработки этого с запасом хватает. Команда QA писала на ней селекторы для Playwright целыми днями и вообще забыла про облако.
Хорошо показал себя и code review. Мы прикрутили локальный инференс к pre-commit хуку: модель проверяет изменения, ищет очевидные ошибки, незакрытые await, утечки контекста, странные имена переменных. Это не заменяет просмотр кода человеком, но отлавливает примерно 20-30% мелочи до того, как она дойдёт до pull request. Раньше мы это делали через облачный API и платили за каждый коммит. Теперь — бесплатно и в офлайне.
Не хуже пошла работа с документацией. Локальная модель отлично пересказывает RFC, объясняет, что делает библиотека, переводит документацию. Там важна скорость и отсутствие лимитов.
Хорошо встала генерация повторяющегося кода: миграции, схемы, фикстуры для тестов, типовые контроллеры. Всё, где нужно много печатать, а не думать.
Что не заработало
Вот список.
Сложная отладка с гипотезами. Когда есть баг на стыке трёх систем, и нужно не просто исправить, а понять, почему так произошло — локальная модель пасует. Она предлагает первое правдоподобное объяснение и начинает его упорно защищать. Облачный Claude или GPT в этой ситуации хотя бы перебирают варианты и сомневаются. Qwen в Q5 — нет.
Архитектурные решения. «У нас сервис на 2000 RPS, начали упираться в постгрес на джойнах, что делать?» — здесь локальные модели выдают банальности из статей на Хабре 2019 года: менее предсказуемого и более привязанного к нашему контексту совета от них не дождёшься.
Работа с совсем новыми технологиями. У нас часть проектов на Mojo и свежем Gleam — модели обучены на старых данных, поэтому о синтаксисе полугодовой давности они не знают. Облачные модели тоже не идеальны, но обновляются чаще.
Длинные многошаговые задачи в агентном режиме. Когда нужно «сходи в файл, прочитай, исправь, прогони тесты, посмотри ошибку, поправь» — локальная модель быстро теряет нить. После 5-6 шагов она забывает, зачем всё это началось. На облачных Sonnet или Opus агентные циклы длиной 30-40 шагов работают, на локальных пока нет.
Деньги: сколько мы заработали и потеряли
За месяц мы сэкономили около 180 тысяч рублей на подписках и API-кредитах. Это для команды из десяти разработчиков с разной интенсивностью использования ИИ.
Косвенные потери труднее посчитать. По ощущениям, на задачах из второго списка (отладка, архитектура) команда просела по производительности — на величину, которой не хватает, чтобы покрыть экономию. То есть по деньгам в чистом виде локальная схема для нас пока убыточна.
Но это без учёта пары моментов. Во-первых, несколько разработчиков отметили побочный эффект: когда модель не может всё сделать за тебя, ты больше думаешь сам. Поначалу это раздражало, но к концу месяца многие сказали, что стали лучше понимать собственный код. В деньги это не пересчитаешь, но из эксперимента мы это вынесли.
Во-вторых, один из клиентов после нашего разговора об офлайн-разработке подписал с нами контракт, который раньше тормозил из-за опасений о коде в облаке. Этот контракт окупил железо за квартал.
Что мы оставили после эксперимента
По итогам месяца мы не вернулись полностью в облако и не остались полностью локально. Получилась гибридная схема, которая, похоже, и есть будущее для большинства команд в 2026 году.
Всё, что касается клиентского кода, повседневной тактики, ревью, документации, генерации шаблонов, — запускаем локально. На это уходит большая часть рабочего дня.
Облако — для сложных задач, агентных сценариев, архитектурных консультаций, работы с новыми технологиями. Это та оставшаяся часть, где локальная модель пасует.
Инженеры сами решают, куда отправить запрос. Через месяц практики выбор делается за секунду: «это в Qwen», «это в Sonnet».
Подписки в итоге обходятся примерно втрое дешевле, скорость работы не просела, а по безопасности данных мы наконец можем что-то обещать клиентам.
Что это значит для тех, кто только входит в IT
К нам на курсы часто приходят люди, которые сначала боятся, что ИИ отнимет у них работу, а потом — что не научатся им пользоваться. Месяц без облака показал важную вещь, которую стоит сказать всем студентам.
Локальные модели сделали то, что должны были сделать: убрали из разработки самую утомительную и глупую часть — рутину. Они не убрали разработчика. Сложные задачи по-прежнему требуют квалифицированного ума, понимания архитектуры, умения читать чужой код, навыка формулировать гипотезы при отладке — всё это важнее доступа к LLM.
Если вы учите Python, Flutter или QA-автоматизацию, не думайте, что локальные модели заменят знания. Воспринимайте их как очень способного, но ограниченного джуниора, который сидит рядом 24/7. Чтобы он приносил пользу, вы должны быть мидлом. Хотя бы для него.
И ещё одно наблюдение, которое нас самих удивило. За месяц никто из команды не попросил вернуть облако. Все привыкли. Через две недели локальная модель воспринимается как нормальный инструмент, а не как урезанная версия чего-то лучшего. Наверное, это и есть главный результат эксперимента: на адекватном железе локальная LLM перестаёт быть игрушкой и превращается в рабочую часть стенда.
Подходит ли это конкретно вашей команде — зависит от того, что вы делаете и сколько у вас денег на железо. Но если раньше вопрос «а можно ли вообще без облака» был риторическим, то теперь это нормальный инженерный вопрос с ответом «да, частично, и вот при каких условиях».