Эксперимент с локальной Qwen на Go-сервисе / forpes.ru

Главная
Эксперимент с локальной Qwen на Go-сервисе

Эксперимент с локальной Qwen на Go-сервисе +6

03.06.2026 09:58

Ladygin 29 11000 Источник

После выхода новых локальных моделей мне захотелось проверить не абстрактный бенчмарк, а более приземленную вещь: можно ли отдать маленькой модели обычную задачу из backend-разработки и получить рабочий результат.

Не "построй мне стартап за вечер". Не "спроектируй идеальную архитектуру". А нормальную небольшую задачу: Go-сервис с регистрацией, логином, JWT, PostgreSQL, Docker Compose и тестами.

Главный вывод эксперимента: простые вещи уже можно отдавать дешевым моделям. Но не в формате "вот тебе проект, разбирайся". Рабочая схема оказалась другой: сильная модель готовит постановку и план, а дешевая модель выполняет маленькие хорошо описанные шаги.

Коротко

Параметр	Значение
Задача	Demo auth service
Стек	Go, PostgreSQL, Docker
Агент	Opencode
Модель	`qwen/qwen3.5-9b`
Запуск	LM Studio
Железо	RTX 5080 16 GB, 64 GB RAM, i5-12600K
Скорость	примерно 120 токенов/сек при контексте около 200K
Результат	рабочий backend-скелет, 19 unit-тестов

Что я проверял

Задача была стандартная, сервис работы с пользователями:

регистрация пользователя;
авторизация по email/password;
выдача JWT access token;
endpoint для получения текущего пользователя;
смена пароля;
хранение пользователей в PostgreSQL;
миграции;
запуск через Docker Compose;
тесты через go test ./....

Стек: Go, PostgreSQL, Docker.

Модель qwen/qwen3.5-9b я запускал через LM Studio. Подбирал ее через canirun.ai: хотелось, чтобы модель полностью помещалась в GPU-память и при этом оставалось место под большой контекст. Для агентской работы скорость важна не меньше качества. Если генерация слишком медленная, экономия быстро превращается в раздражение.

В качестве агента я использовал Opencode.

Главная идея эксперимента

Я не просил локальную модель "сделай весь проект". Это почти гарантированный способ получить хаос, особенно с небольшой моделью.

Вместо этого процесс был таким:

GPT-5.5 -> подробное ТЗ и план разработки
        -> разбиение на маленькие сессии
        -> Qwen 3.5 9B через Opencode
        -> одна сессия = одна ограниченная задача
        -> go test ./... как критерий готовности
        -> ручной review результата

То есть дорогая модель работала как архитектор и постановщик задачи. Локальная модель работала как исполнитель.

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

Методика

Сначала сильная модель подготовила общий план: API-контракты, схему базы данных, бизнес-логику, ограничения по стеку и порядок разработки.

Потом весь проект был разбит на маленькие сессии:

Скелет проекта, доменные структуры, bcrypt и JWT.
Сервисный слой и fake repository для unit-тестов.
HTTP API и middleware.
PostgreSQL repository, config и миграции.
Dockerfile, Docker Compose и README.
Финальная стабилизация.

У каждой сессии были:

одна понятная цель;
список ожидаемых файлов или компонентов;
ограничения, что не нужно делать;
критерий готовности;
команда проверки.

Пример одной сессии

Вот пример задачи для локального агента:

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

Контекст:
Мы делаем demo auth service на Go. Полные требования описаны в plan.md.

Задача этой сессии:
1. Изучи текущий код.
2. Создай repository interface для пользователей.
3. Создай service layer для auth/user logic.
4. Реализуй методы:
   - Register(ctx, email, password, name)
   - Login(ctx, email, password)
   - GetCurrentUser(ctx, userID)
   - ChangePassword(ctx, userID, oldPassword, newPassword)
5. В сервисе:
   - валидируй email, password, name;
   - password минимум 8 символов;
   - email не должен быть пустым;
   - name не должен быть пустым;
   - duplicate email должен возвращать отдельную доменную ошибку;
   - неверный login должен возвращать ошибку unauthorized;
   - неверный old_password должен возвращать ошибку forbidden;
   - password_hash не должен выходить наружу через response model.
6. Напиши fake in-memory repository для тестов.
7. Напиши service tests:
   - успешная регистрация;
   - duplicate email;
   - register с коротким паролем;
   - успешный login;
   - login с неверным паролем;
   - получение пользователя по ID;
   - смена пароля работает;
   - после смены пароля старый пароль не работает;
   - после смены пароля новый пароль работает.
8. Запусти:
   gofmt
   go test ./...

Критерий готовности:
go test ./... проходит успешно.

Именно такой формат оказался рабочим. Не "сделай auth service", а "сделай сервисный слой, не трогай HTTP, проверь тестами".

Необходимые знания и навыки

Отдельно я подобрал skills под проект:

golang-patterns;
golang-testing;
docker-patterns;
database-migrations;
security-best-practices;
supabase-postgres-best-practices.

Это важный момент. Маленькая модель хуже держит в голове специфичные практики: как лучше структурировать Go-код, как писать тесты, как не накосячить с Docker Compose, как аккуратно обращаться с JWT и паролями.

У большой облачной модели часть этих знаний чаще уже "внутри". С локальной 9B-моделью лучше не надеяться на это. Ей нужно положить рядом справочники, правила проекта и критерии готовности.

По сути, skills превращают маленькую модель из "модели обо всем" в более узкого исполнителя под конкретную задачу.

Что получилось

В итоге локальная модель собрала demo auth service.

Структура проекта получилась примерно такой:

cmd/server/main.go
internal/auth/jwt.go
internal/auth/jwt_test.go
internal/auth/password.go
internal/auth/password_test.go
internal/config/config.go
internal/domain/errors.go
internal/domain/user.go
internal/http/handlers.go
internal/http/middleware.go
internal/http/response.go
internal/http/routes.go
internal/repository/fake_repository_test.go
internal/repository/postgres_user_repository.go
internal/repository/user_repository.go
internal/service/auth_service.go
internal/service/auth_service_test.go
migrations/001_create_users.up.sql
migrations/001_create_users.down.sql
docker-compose.yml
Dockerfile
README.md

Пример теста, который сгенерировала модель:

func TestRegisterSuccess(t *testing.T) {
	userRepo := repository.NewMockUserRepository()
	authService := service.NewAuthService(userRepo, "test-secret")

	user, err := authService.Register(
		context.Background(),
		"user@example.com",
		"password123",
		"John Doe",
	)

	require.NoError(t, err)
	assert.Equal(t, "user@example.com", user.Email)
	assert.Equal(t, "John Doe", user.Name)
}

go test ./... проходит.

Получилось 19 unit-тестов: для auth helper'ов, сервисного слоя и fake repository. docker compose config тоже проходит.

Для эксперимента это неплохой результат. Особенно если помнить, что реализацию делала маленькая локальная модель.

Что получилось, а что нет

Область	Результат
Auth helpers	Сделано, покрыто тестами
Service layer	Сделано, покрыто тестами
PostgreSQL repository	Сделано
HTTP handlers	Сделано
Docker Compose	`docker compose config` валиден
README	Есть, но с артефактами форматирования
Миграции	Достаточно для demo, требуют review перед production
Отладка	Долго не могла проверить сервис по http. Она пталась использовать curl которго нет на win11, пришлось подсказывать.

Где дешевая модель экономит

Лучше всего она справилась с тем, что было хорошо ограничено:

реализовать bcrypt helper;
написать JWT generate/parse;
сделать сервисный слой;
покрыть бизнес-логику unit-тестами;
добавить repository interface;
подготовить PostgreSQL repository;
собрать базовый Docker Compose.

То есть все, что похоже на понятную инженерную рутину, маленькая модель тянет нормально.

И это главный вывод эксперимента: простые вещи уже можно отдавать дешевым моделям.

Дешевая не обязательно значит локальная

В этой статье я использовал локальную модель, но вывод не только про локальный запуск.

Речь шире: про весь класс дешевых моделей. Это могут быть локальные модели, small/mini cloud-модели или более дешевые inference endpoints.

Их не обязательно противопоставлять сильным моделям. На практике полезнее разделять роли:

сильная модель лучше подходит для постановки задачи, декомпозиции и review;
дешевая модель лучше подходит для выполнения маленьких понятных шагов;
разработчик остается ответственным за итоговое решение.

Такой подход позволяет не выбирать между "все делает дорогая модель" и "все делаем руками". Можно тратить сильную модель там, где нужна сила, а не там, где нужен аккуратный boilerplate.

Практический вывод

Я все больше думаю, что рабочая схема будет не "одна большая модель делает все", а распределение задач по стоимости.

Сильная модель = постановка задачи + декомпозиция + review.
Дешевая модель = реализация маленьких понятных шагов.

Если хотите попробовать похожий подход:

Не отдавайте маленькой модели весь проект целиком.
Сначала сделайте подробный план сильной моделью.
Разбейте работу на маленькие сессии.
Для каждой сессии задайте критерий готовности.
Добавьте skills под стек проекта.
Просите модель запускать проверки.
Делайте финальный review руками.
Не верьте README, пока сами не запустили команды.

Мой вывод после эксперимента простой: локальные и дешевые модели уже полезны в разработке, если не требовать от них невозможного.

Они не должны быть архитекторами. Им достаточно быть аккуратными исполнителями для хорошо поставленных задач. А это уже закрывает заметную часть повседневной разработки.

Комментарии (29)

gybson_63
03.06.2026 10:29
#30058726
Фактически создан агент "Go-coder". Может быть, если выделить отдельно "Go-tester", то будет еще лучше.
1. Ladygin Автор
  03.06.2026 10:29
  #30060616
  Да, без условно если получше подробить на разные агенты с разными скилами то результат будет еще лучше.
1. MIHAnik22
  03.06.2026 10:29
  #30064776
  Текст статьи прям чувствуется написан нейронкой. Этот оборот который постоянно пихают нейронки в текст " сделать так, а не делать так" прям уже раздражает.
  1. gybson_63
    03.06.2026 10:29
    #30066090
    Меня раздражает когда ей говоришь что-то типа "не используй хардкод" и она потом кругом в документации это пишет. "Программа супер (не хардкод!)", "архитектура приложения бла-бла-бла и в ней НЕТ ХАРДКОДА", скачивайте наше приложение без хардкода. Вот это очень смешно.

paramtamtam
03.06.2026 10:29
#30059074
разрешите поинтересоваться, а в чем в (общем и) целом смысл?
- если вы устали от рутины шлепать однотипные сервисы - может быть проблема в архитектуре?
- если цель это экономия времени - вы действительно выпускаете в прод то что llm написало, само “протестировало” и сказало “я сделаль” без детального ревью и сотен “u did a bulshit, coz … and … should be …”
- если llm пишет код лучше чем тот, кто её использует, то (токсичный текст тут был замечен НЛО и удален)
нет, вы не подумайте, ваш покорный не из лагеря “llm-на-вилы”, сам пользуюсь каждый день, но с оговоркой - только для ревью написанного кода (руками), перевода текста с ну-понятно-но-коряво на православно-английский и изредка траблшутинга (понять какого хрена контекст отменился где-то где не надо в реально сложной цепочке, или пошукать в тернистой SDK или объемной доке подсказки).

я правда пытаюсь понять - зачем?
1. Ladygin Автор
  03.06.2026 10:29
  #30060646
  На мой взгляд для 80% задач продуктовой разработки писать код руками не имеет смысла из-за низкой эффективности. LLM пишет быстрее и качественнее если достаточный контекст и описание задачи.
  
  Отвечая на ваш вопрос - конечно код сгенерированный LLM уже давно работает в продакшене.
1. gybson_63
  03.06.2026 10:29
  #30060654
  Потому что логично все делать единообразно. А аргументы "мужики едят шашлык руками" не логичны.

alexandr93
03.06.2026 10:29
#30059094
Я пробовал как хобби в формате:
1. Спроектируй такую фичу -> маленькая модель
2. Напиши замечания -> ChatGPT
3. Исправь замечания -> маленькая модель
4. 2-3 итерации
5. Реализуй -> маленькая модель

По факту какие я сделал выводы:
1. Как агенты модели могут допускать серьёзные огрехи, например у меня в режиме Ask редактировал код без предупреждения, модифицировал системный питон с флагом --break-system(без него в питоне стояла защита от этого) и т. д.
2. Маленькая модель может игнорировать инструкции. Например, по плану мы сошлись на то, что нужно добавить haptic feedback, у модели с ходу не получилось, она не добавила, а по фактуотписала, что всё сделала
3. Своеволие. Например, попросил внести изменения, модель внесла, попросил поправить варнинги(в том числе, которые висят давно) - модель сделала git stash, проверила варнинги и отказалась делать, мол это было до меня.
  Или такой кейс. И часто это "я не буду этого делать" лечится только перезапуском сессии.
  Пытался сделать 2 приложения, которые должны были интегрироваться. Интеграция не заработала. Запустил 2-х агентов. Одного для одного проекта, другого - для другого. Так они друг на друга гнали, мол у меня всё ок, смотри что в другом проекте.
4. Ну и не получилось до сих пор у меня приучить ни локальные, ни платные модели к хорошему коду. Если модель сделает большой кусок проекта, а потом что-то не сможет пофиксить, то нужно лезть самому. А там, как правило, что-то трудное для понимания. И поэтому когда в приложении баг, из-за которого им невозможно пользоваться, приходится сначала делать рефакторинг практически в ручном режиме и потом уже искать ошибку.
И главное, что хороший план в этой ситуации не помогал мне избежать этого всего. План был достаточно подробный, со структурой проекта, примерами кода и т. д.
1. Ladygin Автор
  03.06.2026 10:29
  #30060664
  Подобное наблюдал с более старыми моделями, например с Qwen coder 3.
  Ранее пробовал с ней похожий эксперимент, он не справилась совсем и периодически уходила в рекурсии на правках и тестах.
  
  При использовании более свежих версия то ситуация сильно лучше.

kedzoo
03.06.2026 10:29
#30059320
План можно и самому наклепать и задачи поставить. Кстати кто-то кодил с 27B последней версией? Которая 3.6
1. Mi11er
  03.06.2026 10:29
  #30059430
  Нужно много ОЗУ ... очень:(
  
  5070ти и 32ддр4 не вывезли...( 4 tps )
1. Vakavakas
  03.06.2026 10:29
  #30059906
  35b не хуже справляется и запустить можно на довольно скромном железе.
  1. exelens
    03.06.2026 10:29
    #30060120
    А если взять q6.... мммм

DamirMur
03.06.2026 10:29
#30059604
На такое железо можно qwen 3.6-35b-a3b поставить Q5.

По мне правильная бесплатная разработка, это обсуждаешь проект, архитектуру, включая содержание модулей go, на облачной модели, крайне желательно того же семейства что и локальная. А локальной потом куски допиливаешь, тесты, отладки, когда в облачную надоест копировать логи, ошибки и и.т.д.
1. Ladygin Автор
  03.06.2026 10:29
  #30060676
  А вот не нашел такую, которая бы помещалась в GPU полностью и место хватала для нормального контекста + тулы. Если подскажите где такую скачать для LM Studio будут благодарен.
  1. DamirMur
    03.06.2026 10:29
    #30061902
    https://habr.com/ru/articles/1026482/
    
    Ladygin Автор
    03.06.2026 10:29
    #30062884
    Спасибо, но 42 токена/сек и контекст 65 536 не подходят для реальной агентной работы. Контекст нужен минимум 150 тыс иначе ничего хорошего не выйдет, будет постоянно в него упираться.
    
    С Qwen 3.5 получается скорость генерации 120 токенов в секунду и контекст 200K.
    
    DamirMur
    03.06.2026 10:29
    #30062912
    У меня больше t/c получалось, там на 12Г у меня 16Г , а насчет контекст 200K.
    
    Модель Qwen 3.5 9B поддерживает нативный контекст в 262 144 токена (с возможностью расширения до 1 млн). При этом, как и большинство современных LLM на архитектуре Transformer, она сталкивается с эффектом «потерянного в середине» (Lost in the Middle) — наибольшую точность показывают начало и конец промпта, а середина длинного контекста может игнорироваться. [1]
    
    Для наглядности, вот главные особенности работы 9-миллиардной модели Qwen с длинным контекстом:
    
    ⚡ Ключевые аспекты
    
    Окно памяти: До 262 144 токенов «из коробки». [1]
    
    Архитектурная особенность: Модель имеет тенденцию пересчитывать промпт при каждом новом повороте диалога. Без оптимизаций это может приводить к долгим ожиданиям при загрузке больших текстов. [1]
    
    Потери в середине (Lost in the Middle): Как и другие LLM, модель склонна забывать факты, спрятанные в середине длинного документа. Ключевые инструкции или термины лучше дублировать в начале и конце большого текста.
  1. krendelbok
    03.06.2026 10:29
    #30066824
    Я запускаю qwen3.6-35 q4 на стареньком ноуте асус с амд процом и мобильной ненавидиа на 6гб vram. 25-30 т/с и контекст 120к. Секрет - выгрузка мое в оперативку
1. for7raid
  03.06.2026 10:29
  #30061476
  Поддерживаю. Сделал на таком подходе недавно проект с использованием дипсика веб интерфейс и его апи для агента.

Vakavakas
03.06.2026 10:29
#30059876
Одно не пойму, почему при наличии новых моделей люди упорно лезут что-то делать на старье и не самом лучшем? Специально для того чтобы сказать фу локальный модели ничего не могут и агетировать за платные модели?

Qwen 3.5 довольно старая по меркам моделей и к тому же очень плохо работает с тулзами.

Даже Gemma 4 будет лучше, молчу уже про Qwen 3.6.

Qwen 3.6 35/27b вообще отличная модель получилась, она очень хорошо делает все, от планирования до конечного проекта с тестами и сборкой.
1. exelens
  03.06.2026 10:29
  #30060130
  Полностью согласен, ждём 3.7
1. Ladygin Автор
  03.06.2026 10:29
  #30060604
  Да, конечно более новые должны быть лучше, но 3.6 на моем железе выдавала низкую скорость ответа и контекстное окно сильно меньше. Поэтому остановился на 3.5

evgeniy_kudinov
03.06.2026 10:29
#30060454
Подскажите:
1. Как сам процесс проходил, есть какие-то циклические этапы, как, например, plan -> implements -> test -> review?
2. Сколько по времени от старта до конечного результата прошло времени и есть ли понятие, за какое время вы бы сами вручную реализовали этот функционал.
3. Какая трудоемкость подготовить среду для процесса, который вы описали.
4. Была ли попытка использовать методологии SDD
1. Ladygin Автор
  03.06.2026 10:29
  #30064370
  1) Создана подробная спецификация сервиса и разбито на задачи
  
  скелет проекта, домен, password и JWT
  
  сервисный слой и fake repository tests
  
  HTTP API, middleware и handler tests
  
  PostgreSQL repository, config и миграции
  
  Dockerfile, Docker Compose и запуск всех зависимостей
  
  Каждая задача это отдельная сессия, все сессии идут последовательно. После каждой задачи смотрел что он сделал все верно.
  
  2) Сервисы реализован в течении дня между делом, чистого времени работы агента около 1-1,5 часа Руками писать 1-2 дня
  
  3) У меня уже все было установлено, поэтому сложно оценить.
  
  4) По сути так и было в простом варианте - Бизнес описание сервиса, план реализации и описание каждой задачи все в .md файлах в проекте.

Inoriol
03.06.2026 10:29
#30062332
А почему эта модель? На ваших спеках можно новую Qwen3.6 35B A3B запустить и она будет значительно лучше

Upd: прочитал ваши ответы, понял что глупый вопрос, игнорируйте пожалуйста.

mazdai19
03.06.2026 10:29
#30062834
Как то пришел к тому что всегда сложные задачи разделяю на этап "напиши план" и "реализуй план". Даже если план будет писать не более дорогая модель а та же самая что будет делать, все равно результат лучше (ну и план можно/нужно проверить и исправить). Ну и даже большие дорогие модели вроде опуса лажают если им просто скормить проект и сказать "делай". Всегда лучше делать план, имхо

NeverIn
03.06.2026 10:29
#30063920
Как развернуть модель локально?
1. Ladygin Автор
  03.06.2026 10:29
  #30064088
  Установить программу https://lmstudio.ai/ скачать модель qwen/qwen3.5-9b установив GPU Offload на максимум и Context Length на 200K.
  Далее подключить в opencode так https://opencode.ai/docs/ru/providers/#lm-studio

Эксперимент с локальной Qwen на Go-сервисе +6

Коротко

Что я проверял

Главная идея эксперимента

Методика

Пример одной сессии

Необходимые знания и навыки

Что получилось

Что получилось, а что нет

Где дешевая модель экономит

Дешевая не обязательно значит локальная

Практический вывод

Комментарии (29)

Ladygin Автор

Ladygin Автор

Ladygin Автор

Ladygin Автор

Ladygin Автор

Ladygin Автор

Ladygin Автор

Ladygin Автор