LLM кодеры уже показывают отличные результаты на бенчмарках и в реальных задачах. Кажется, сейчас хорошее время, чтобы начать пробовать ими пользоваться.
В статье разберем открытые LLM для кодинга. Сравнимы ли они с подписочными моделями? Можно ли их использовать для работы? А есть ли вариант начать локально?
В части туториала:
-
Запустим через docker с помощью llama.cpp.
-
Сделаем замеры скорости генерации.
-
Ускорим за счет спекулятивного декодинга.
-
Подключим в vscode, заставим работать локально и через ssh.
Что можно делать с llm
Большинство моих знакомых узнали про llm кодеры, когда увидели, как с их помощью пишут готовый код или создают приложения с нуля. Такого полно на ютубе и форумах.
Действительно, LLM хорошо справляется с написанием небольшого MVP кода. Просто потому, что училась на большом количестве таких листингов. Да и с более сложными кусками кода справляется хорошо, если получается точно описать все его параметры в промпте.
В этом плане llm вполне на уровне junior/middle- разработчика. От того тоже нельзя гарантированно добиться нормального результата, пока досконально не сформулируешь задачу.
В ML разработке выделю такие кесы использования:
-
Реализовать функцию по описанию или по неэффективному коду с циклами.
-
Написать bash/python скрипт запускающий или обрабатывающий мультипоточно файлы.
-
Написать простой пример обучения для регрессии/классификации - отлично для разных тестов.
-
Написать комменты к функции/коду.
-
Написать argparse к коду.
-
Написать тесты к функции.
-
Реализовать X, используя Y - в половине случаев получается не совсем то. Во многом из-за промпта (сам не до конца знаешь, что именно нужно). Но интерфейсы получаются хорошими и можно от них оттолкнуться.
-
Попросить описать, как устроен код в репозитории/файле (*смотрите ниже на оговорку с контекстами).
Где есть проблемы
Стоит отметить, что не все так радужно.
Например, при увеличении контекста в какой-то момент качество очень сильно падает и llm начинает генерировать просто правдоподобную дурь. Это происходит либо при генерации большого количества кода подряд, либо использования большого числа файлов с кодом в контексте.
Поэтому же на открытых моделях пункт 6* с вопросами по базе работает скорее плохо. При этом antropic sonnet3.5 рассказывает о коде уже куда более внятные вещи.
Об этой проблеме есть забавный тред с реддита:
My project became so big that claude can't properly understand it
Разработчик с llm может вполне оказаться “слоном в посудной лавке“ и проблемой для всей команды:
-
Сгенерированный код иногда будет содержать баги. Для демонстрации MVP это нормально. Если суть видна, то все равно, как часто программа падает и работает ли корректно. Однако, для развития продукта такой подход не подойдет - пользователи будут расстраиваться.
-
Чтобы выявить баги, нужно как минимум понимать, что именно пишет нейронка. Можно попросить написать побольше комментариев и тестов, но и их правильность тоже нужно подтвердить. Это повышает требование к использующему нейросеть человеку.
-
Разработчик несет ответственность за свою часть продукта. Если она падает, его будут просить починить. А если проблемы с кодом возникают часто, то к такому разработчику появятся вопросы.
Есть статья фокусирующаяся на негативе на LessWrong: How Much Are LLMs Actually Boosting Real-World Programmer Productivity?
Также полезно почитать комменты, там люди поясняют, где именно и как их продуктивность ускоряется.
Основной вывод такой, что llm реально крутой инструмент, если использующий его
-
Пишет MVP. И вообще все равно, какая там производительность, глюки, падения и тд.
-
Использует сгенерированный код для референса.
-
Понимает каждую строчку, что ему пишут (то есть он техлид, у которого на пол ставки работает llm).
-
Применяет генерацию точечно и изолированно от других компонент.
Как попробовать?
Ладно, хватит душнить. Все равно - кто захочет ноги себе переломать, тот сам справится
Есть 3 варианта:
-
Купить подписку на cursor, copilot, sonnet, openai и тд. Стоимость 10-20$ в месяц.
Тут самые крутые модели. Ниже посмотрим на бенчмарки. -
Ухватить триал моделей, пока они бесплатны:
-
Запустить модель локально. Можно взять сервер в компании и развернуть на команду, можно просто поднять на собственной игровой видеокарте. Мы дальше разберем этот сценарий.
Что по качеству?
Закрытые модели самые крутые, тут без сомнений. Более того, пару недель назад были анонсы новых моделей от antropic.

Это бенчмарки, но в интернетах есть и мнение юзеров - многие из моего окружения сходятся на том, что sonnet в практических задачах супер крут (субъективное мнение). Тред с reddit по независимым бенчмаркам.
Открытые модели хуже, и они куда быстрее тупеют с увеличением контекста. Однако для рутинных задач и просто потестировать - они вполне подходят.


Благодаря относительно недавнему релизу qwen мы имеем набор хороших моделей для каждой весовой категории. Оптимальная первая модель - Qwen2.5-Coder-32B-Instruct. Но как мы дальше увидим, для игровой карты она скорее недостижима (нужна сильная квантизация и хотябы 24Gb, а лучше 2 карты по 16-24Gb VRAM)
Посмотреть бенчмарки и другие подробности устройства qwen2.5-coder моделей можно в техническом отчете qwen-coder.
И тут мы подходим к второй части статьи - а как попробовать это все? Нужна ли топовая видеокарта? У кого-то может не быть зарубежной платежной карты для оплаты подписки, кто-то переживает за приватность, кто-то просто хочет дать потестить сразу всей команде.
Локальный запуск на игровой AMD
Если у вас есть nvidia A100/H100 80Gb в доступе, то на ней прекрасно работает qwen_coder_32b. Если так - можете просто взять команды llama.cpp для запуска.
На a100 я тестировал кодинг изначально и теперь перекатываюсь в подписочный cursor.
Если же такого удовольствия нет, то тут придется снижать весовую категорию.
У меня есть карта amd 6800xt 16Gb. Стоимость у нее более чем доступная - около 40 тыс. на авито. Дальше - как запустить на ней и немного разочароваться. На cuda - то же самое, только не нужны флаги для проброса девайса.
Сборка инференса под AMD
Собираем образ под нашу карточку:
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
sudo docker build -t local/llama.cpp:server-rocm
--target server -f .devops/rocm.Dockerfile
--build-arg ROCM_DOCKER_ARCH=gfx1030 .
Также есть issue, где пишут о плохой производительности llama.cpp на rocm с qwen моделями. Для такого случая можно использовать vulkan сборку. Но в моем случае производительность не отличалась.
sudo docker build -t local/llama.cpp:server-vulkan
--target server -f .devops/vulkan.Dockerfile
--build-arg .
Если вы работаете на windows или вам просто хочется еще проще, можно использовать ollama. Под капотом она запустит тот же самый llama.cpp.
Запуск сервера
Веса можно скачать из коллекции Qwen2.5-Coder репозитория Qwen на huggingface. Нам нужны GGUF версии (у всех qwen coder моделей есть официальный GGUF).
docker run -p 8080:8080 -v ./models:/models
--device=/dev/kfd --device=/dev/dri
local/llama.cpp:server-rocm
-m /models/Qwen-Qwen2.5-Coder-14B-Instruct-GGUF/qwen2.5-coder-14b-instruct-fp16-00001-of-00004.gguf
--host 0.0.0.0 --port 8080
--n-gpu-layers 20 -t 20
-t
- ограничивает количество используемых cpu тредов. Много не нужно, тк основную задачу делает видеокарта, а подгрузка слоев в память много не требует от CPU.
По сравнению с запуском на карте nvidia, нужно вручную пробросить интерфейсы карты с помощью --device=/dev/kfd --device=/dev/dri
Для спекулятивного декодинга нужно добавить (модель и количество ее слоев на GPU)-md SPEC_DEC_GGUF -ngld DRAFT_GPU_LAYERS
Скорость работы
Сетап железа:
1. Amd threadripper 3960x.
2. 192Gb ram ddr4.
3. Sapphire Radeon 6800xt 16gb.
Сетап |
Слоев на GPU |
RAM |
VRAM |
Скорость генерации, токен/с |
Утилизация |
qwen coder 1.5b |
29/29 |
0,78 |
3,2 |
120 |
98+ cpu-bound |
qwen coder 7b |
29/29 |
1,6 |
15 |
30 |
97+ cpu-bound |
qwen coder 14b |
24/49 |
16 |
16 |
4 |
0-97 memory-bound |
qwen coder 32b |
14/65 |
51 |
16 |
1,5 |
0-50 memory-bound |
Для 14b модели выглядит грустно. Для комфортного использования нужно хотябы 10 токенов в секунду. Можно взять квантизованную модель и докрутить спекулятивный декодинг. У Qwen есть 0.5b модель и 1.5b.
Сетап |
Слоев на GPU |
RAM |
VRAM |
Скорость генерации, токен/с |
Утилизация |
14b + 1.5b 1/16 |
24/49 |
17 |
16 |
5 |
0-97 memory-bound |
14b q5_0 + 1.5b 1/6 |
49/49 |
1 |
12,7 |
12,7 |
50-70 memory-bound |
Оптимальным вариантом с точки зрения скорости для моей карточки оказалась основная 14b + 1.5b драфт модель. А 0.5b не привела к ускорению. Однако качество 14b моделей в сравнении с 32b fp16 мягко говоря не очень.
То есть это в любом случае существенно хуже подписочного сервиса и рассыпается от размера контекста быстрее. Так что если резюмировать, то да, на недорогой карте работать будет плохо. Нужно хотябы 3090 24gb, а лучше 2 карты по 16Gb (например, 4060. Т.к. нагрузка упирается в память).
Подключаем в vscode
Для проприетарных моделей часто есть свои плагины или ide (у cursor и traje - форк vscode).
Для локального деплоя удобно использовать плагин continue.dev. В него же можно подключить токен с вашей платной моделью, если плагин понравится или если вы уже платите подписку для других задач.
Набор фич у всех примерно одинаковый - чат, редактирование и автодополнение (для continue - тут демки).
Чат полезен чаще всего и принимает запросы в произвольном формате. Кодовые вставки выделяются для удобного копирования.
Редактирование - чуть более удобный чат для небольших изменений в коде. Но для редактирования большого числа строк мне показалось не очень удобно.
Автодополнением изначально никогда не пользовался, но при переходе в cursor оказалась вполне полезная штука.
Модели можно подключить через конфиг. Для этого откройте расширение, нажмите на шестиренку с настройками и дальше “Open Config File“.

Там можно указать произвольное количество моделей и дальше под чатом выбирать между ними. На скриншоте - llama.cpp и ollama. Других провайдеров можно посмотреть тут - в том числе LM Studio и vLLM, если они вам удобнее.
В случае с указанием локального интерфейса, vscode будет обращаться к локальной машине, даже если вы работаете по ssh. Поэтому, если нет белого IP, то придется прокидывать порт через ssh:
ssh -N -L 12000:localhost:12000 ssh-server-addr
Заключение
Ллм для кодинга стали достаточно круты, чтобы их использовать. Хорошо выполняется работа, которая:
-
Легко проверяется на корректность.
-
Требует написание кода, но не думать.
-
Делается быстрее, имея референсы или интерфейсы.
-
mvp - нужно быстро накидать и посмотреть, как работает. При этом контекст не большой.
Платные подписки стоят 10-20$ в месяц. И по сути равноценной альтернативы им нет.
Начать пользоваться можно с демо версий платных моделей.
Если хочется попробовать локально - нужна серверная видеокарта.
При этом можно запустить на игровой карточке с потерей качества и скорости. Но и карточка должна быть дорогой, потому что скорость тормозит доступный объем памяти GPU.
Канал автора в телеграм @deploy_ml
Автор: svtDanny