Qwen3.5 в production: личный опыт использования для разработки на JavaScript, Go и Rust

От Claude к локальному монстру: как Qwen3.5 съел мои GPU и подавился Rust

Два месяца назад я выпилил Claude API из всех пайплайнов. Не из-за цены - хотя счета в $800 в месяц тоже радовали - а из-за латентности. Когда твой CI/CD ждет ответа от облака 10-15 секунд на каждый автоматический код-ревью, это не разработка, а симуляция страдания. Решение было очевидным: локальная LLM. Но не та, что для философских бесед, а та, которая будет пахать в production, генерируя код, фиксы и даже немного тестов. Выбор пал на Qwen3.5-Coder. И вот что из этого вышло.

1 Проблема: облако тормозит, а код должен летать

Наш стек: бекенд на Go (микросервисы), фронтенд на TypeScript/React, и системные утилиты на Rust. Задачи для LLM: рефакторинг, генерация boilerplate кода, написание unit-тестов, объяснение сложных участков в проде. Claude Copilot делал это хорошо, но с задержкой в секунды. В пересчете на 100 разработчиков - часы простоя в день. Локальная модель должна была отвечать за < 2 секунды на средней длине контекста.

2 Выбор железа и софта: неожиданный герой - Mac Studio

В теории, для 32B модели нужны GPU. На практике, Apple Silicon с 64GB Unified Memory оказался идеальным полигоном. Почему? Потому что в продакшене важна предсказуемость, а не пиковая производительность. M3 Max (48GB) тоже справлялся, но с оговорками - подробности в статье про Реальный тест Qwen3-Code-Next на Mac.

Софт:

• llama.cpp с поддержкой Qwen3.5 (обязательно версию после пулл-реквеста, который ускорил все на 30%)
• Свой оркестратор на Go, который управляет контекстом и вызовами
• Квантованные модели в формате GGUF (Q5_K_M - мой выбор)

3 Интеграция с JavaScript/TypeScript: React, промпты и боль

Здесь Qwen3.5 показал себя блестяще. Промпт для генерации React компонента:

// Промпт для Qwen3.5
Ты - Senior Frontend разработчик. Сгенерируй компонент React с TypeScript.
Требования:
- Используй функциональные компоненты и хуки
- Типизируй все пропсы через interface
- Добавь обработку состояния через useState
- Для side effects используй useEffect
- Экспортируй компонент как default

Задача: компонент модального окна с кнопкой закрытия, затемнением фона и анимацией появления.

Результат - готовый, работающий код. Но есть нюанс: Qwen3.5 иногда "забывает" про последние изменения в React 19 (актуальные на 2026), например, про новые хуки. Решение: добавлять в системный промпт актуальную справку по версии React. Метрика: среднее время генерации компонента - 1.8 секунды, против 4-6 секунд у Claude через API.

4 Битва с Go: когда generics приводят модель в замешательство

Go с его строгой типизацией и generics (которые стали еще сложнее к 2026) - тест на прочность для любой кодогенерирующей модели. Qwen3.5-Coder справлялся с типовыми задачами (генерация HTTP-хендлеров, worker pools) отлично. Но как только речь заходила о сложных generic-структурах, начинались галлюцинации.

Пример ошибки:

// Как НЕ надо делать - это сгенерировала Qwen3.5 в первых тестах
func MergeMaps[K comparable, V any](maps ...map[K]V) map[K]V {
    result := make(map[K]V)
    for _, m := range maps {
        for k, v := range m {
            result[k] = append(result[k], v) // Ошибка: V не обязательно slice
        }
    }
    return result
}

Исправленный промпт включал явное указание: "Проверь, что generic-типы используются корректно, V может быть любым типом, не только slice". После обучения модели на конкретных примерах из нашей кодовой базы, качество выросло до приемлемого. Помог детальный гайд по настройке Qwen Code локально, где описана fine-tuning на своих данных.

5 Rust: ад заимствований и как Qwen3.5 через него продирался

Это было самое сложное. Rust с его borrow checker - кошмар для генерации. Но и здесь нашлась хитрость. Вместо того чтобы просить модель генерировать целые модули, мы разбили задачу: сначала генерируем структуры и трейты, потом методы с заглушками, и только потом - реализацию с явными подсказками по lifetimes.

Системный промпт для Rust:

// Часть системного промпта
Ты генерируешь код на Rust. Важные правила:
1. Все ссылки должны иметь явные времена жизни, если функция их возвращает
2. Для ошибок используй anyhow::Result или свой тип ошибки
3. По умолчанию используй &str вместо String где возможно
4. Проверь, что нет нарушений правил заимствования

С такой настройкой Qwen3.5 генерировал код, который компилировался с первого раза в 60% случаев. Для сравнения: Claude давал 75%, но за 5 секунд. Наш Rust-оптимизированный пайплайн, вдохновленный статьей про Qwen3-TTS на Rust и Candle, сократил время генерации до 2.5 секунд.

Цифры, которые имеют значение

Вывод: локальная модель проигрывает в качестве генерации на 5-15%, но выигрывает в скорости и стоимости в десятки раз. Для production, где количество запросов измеряется тысячами в день, это очевидный выбор.

Ошибки, которые мы совершили (чтобы вы их не повторяли)

• Недооценка памяти. Запустили 32B модель на сервере с 48GB RAM. Она работала, но свопил на SSD, и время ответа выросло до 10 секунд. Решение: либо больше памяти, либо меньшая модель. 24B Qwen3.5-Coder с квантованием Q6_K - хороший компромисс.
• Игнорирование температуры (temperature). По умолчанию в llama.cpp стоит 0.8. Для генерации кода это много. Код становится "творческим", но нерабочим. Оптимально - 0.2-0.3. Для рефакторинга - 0.1.
• Прямые вызовы из CI/CD. Сначала интегрировали модель напрямую в GitLab CI. Один раз она сгенерировала код, который сломал сборку. Теперь все generation проходит через ревью-человека (или хотя бы статический анализ) перед коммитом.

Сравнение с Claude: неожиданный поворот

Claude 3.7 Sonnet (актуальный на февраль 2026) все еще лучше понимает контекст больших проектов. Его контекст в 200K токенов против 32K у Qwen3.5 - огромное преимущество. Но нужен ли он? В 95% наших задач хватало 8-10K токенов (файл + несколько связанных файлов). Для остальных 5% мы разбивали задачу на части.

Главное преимущество Qwen3.5 - предсказуемость. Нет внезапных даунтаймов API, нет rate limits, нет скачков цены. Модель загружена - она работает. Всегда.

Финальный совет: не гонитесь за размером

Самый неочевидный урок: мы потратили неделю, пытаясь запустить 72B модель на кластере GPU. Она генерировала код на 5% лучше, но в 10 раз медленнее. В production скорость часто важнее идеального качества. Qwen3.5-Coder-14B с грамотным промптингом и квантованием Q8 оказался тем самым "золотым сечением" для большинства задач. Он работает даже на MacBook Pro с 24GB памяти, как описано в том самом сравнении на Macbook Pro.

И последнее: если вы делаете что-то с TTS, обязательно посмотрите на Qwen3-TTS.cpp. Ускорение в 4 раза - это то, что меняет правила игры.

Qwen3.5 в production - это не про идеальный код с первой попытки. Это про скорость, контроль и независимость. А когда ваша модель сгенерирует код, который с первого раза проходит все тесты, вы почувствуете то самое удовольствие, которое не купишь за API-ключ.

Подписаться на канал