Локальный AI-агент для автоматизации багтрекинга на базе Qwen3-Coder-Next

Локальный AI-агент для автоматизации багтрекинга на базе Qwen3-Coder-Next

📋 Контекст проекта

Задача: Внедрить внутреннего AI-агента, который автоматически обрабатывает поступающие баг-репорты:

  • Классифицирует тип ошибки (UI, backend, инфраструктура, документация)
  • Предлагает приоритет и предполагаемую сложность фикса
  • Генерирует черновик ответа для разработчика
  • Связывает баг с похожими историческими тикетами

Ключевое требование: Полностью локальный запуск.

  • Код и данные не должны покидать периметр компании
  • Каждый разработчик должен иметь возможность запустить агента на своей рабочей станции
  • Стандартная конфигурация команды: 16 ГБ VRAM + 32 ГБ RAM

🔍 Почему мы выбрали Qwen3-Coder-Next

На этапе исследования мы протестировали 5 моделей для задач код-ревью и анализа багов:

CodeLlama-7B

Параметры: 7B

Качество: 62.3%

Контекст: 16K

DeepSeek-Coder-33B

Параметры: 33B

Качество: 71.8%

Контекст: 16K

Qwen2.5-Coder-32B
Параметры: 32B
Качество: 74.1%
Контекст: 128K

Qwen3-Coder-Next
Параметры: 80B (MoE)
Качество: 79.6%
Контекст: 16K

Облачные модели не рассматривались из-за специфики задачи.

Результаты внутреннего бенчмарка (на 500 реальных баг-репортах):

Метрики качества: ├─ Точность классификации: Qwen3-Coder-Next — 94.2% (лучший) ├─ Релевантность предложений: Qwen3-Coder-Next — 87.8% ├─ Отсутствие галлюцинаций: Qwen3-Coder-Next — 91.5% └─ Понимание контекста (256K): Уникальная фича модели

Вывод:

Qwen3-Coder-Next показал наилучшее качество, особенно в задачах, требующих анализа длинного контекста (история тикетов, связанные коммиты, документация).

Проблема:

Оригинальная модель в формате BF16 требует ~159 ГБ памяти. Даже 4-битное квантование — ~46 ГБ. Наш лимит: 48 ГБ суммарно (VRAM+RAM), из которых только 16 ГБ — быстрая видеопамять.

🧪 Протестированные подходы к оптимизации

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

🔹 Вариант 1: 4-битное квантование через Transformers + bitsandbytes

Реализация:

from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, ) model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen3-Coder-Next", quantization_config=bnb_config, device_map="auto", # Распределение между GPU и CPU torch_dtype=torch.bfloat16, )

Метрики:

  • Потребление VRAM: 15.8 ГБ (на пределе)
  • Потребление RAM: 12.4 ГБ (оффлоадинг слоёв)
  • Скорость генерации: 3.2 токена/секСтабильность
  • Частые OOM при контексте >4K
  • Качество: 78.9% (-0.7% от оригинала)

Вывод: Технически работает, но нестабильно. При длинных баг-репортах (типичный кейс) модель вылетает. Скорость недостаточна для интерактивной работы.

🔹 Вариант 2: Оптимизация через Unsloth

Реализация:

from unsloth import FastLanguageModel model, tokenizer = FastLanguageModel.from_pretrained( model_name="unsloth/Qwen3-Coder-Next", load_in_4bit=True, max_seq_length=8192, # Ограничили контекст )

Метрики:

  • Потребление VRAM: 14.2 ГБ (-1.6 ГБ)
  • Скорость генерации: 5.8 токена/сек (+81%)
  • Стабильность: Работает, но только с контекстом ≤8K
  • Качество: 78.4%

Вывод: Unsloth дал заметный прирост скорости и экономии памяти благодаря Flash Attention 2 и оптимизированному загрузчику. Однако гибридная архитектура модели (MoE + DeltaNet) не всегда корректно обрабатывалась патчами. Требовалось ручное управление распределением слоёв.

Вариант 3: Структурное прунинг (удаление слоёв и экспертов)

Реализация:

# Уменьшаем архитектуру в config config.num_hidden_layers = 50 # было 80 config.num_experts = 4 # было 8 config.num_experts_per_tok = 1 # было 2 # Загружаем "облегчённую" архитектуру и копируем веса первых слоёв model = AutoModelForCausalLM.from_config(config) # ... (копирование весов и дообучение)

Метрики:

  • Потребление VRAM: 11.5 ГБ
  • Скорость генерации: 9.1 токена/сек
  • Качество: 71.3% (-8.3%)
  • Время дообучения: ~18 часов на 1xRTX 4060 Ti

Вывод: Удаление 37% слоёв и 50% экспертов дало хороший прирост скорости, но качество упало критически. Модель начала пропускать важные детали в баг-репортах. Дообучение на наших данных не компенсировало потерю знаний. Не подошло для продакшена.

🔹 Вариант 4: Дистилляция знаний в меньшую модель

Реализация:

Студент (Qwen2.5-Coder-7B) обучался на выходах учителя (Qwen3-Coder-Next 4-bit).

# Loss = α * KL(soft_labels) + (1-α) * CE(hard_labels) loss = 0.7 * soft_loss + 0.3 * hard_loss

Метрики:

  • Потребление VRAM: 6.2 ГБ (только студент)
  • Скорость генерации: 28.4 токена/сек
  • Качество: 75.1% (-4.5%)
  • Время обучения: ~42 часа

Вывод: Отличная скорость и низкие требования к памяти. Качество приемлемое, но не дотягивает до оригинала в сложных кейсах (анализ стека, кросс-репозиторные зависимости). Хороший вариант для "быстрого режима", но не как основное решение.

🔹 Вариант 5: GGUF-формат через llama.cpp

Реализация:

# 1. Скачиваем 2-битный квант от Unsloth huggingface-cli download unsloth/Qwen3-Coder-Next-GGUF \ --include "*UD-IQ2_XXS*" \ --local-dir ./models # 2. Запускаем с тонкой настройкой оффлоадинга ./llama-cli \ --model Qwen3-Coder-Next-UD-IQ2_XXS.gguf \ --ctx-size 8192 \ --n-gpu-layers 22 \ # Подбирали эмпирически --batch-size 512 \ --cache-type-k q8_0 --cache-type-v q4_0 \ # Оптимизация KV-cache --temp 0.2 --top-p 0.95

Метрики:

  • Потребление VRAM: 15.1 ГБ
  • Потребление RAM: 8.3 ГБ
  • Скорость генерации: 6.7 токена/сек
  • Качество: 77.8%

Вывод: параметр --n-gpu-layers даёт точный контроль над памятью, квантование ключей/значений (q8_0/q4_0) экономит 2-3 ГБ при длинном контексте

Финальное решение: гибридный деплой

Мы внедрили двухрежимную архитектуру агента:

┌─────────────────────────────────────┐ │ 🤖 AI Agent for Bug Tracking │ ├─────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ Режим: FULL │ │ Режим: FAST │ │ │ │ Qwen3-Coder │ │ Qwen2.5-7B │ │ │ │ Next GGUF │ │ GGUF Q4_K_M │ │ │ │ (Q2, 8K ctx)│ │ (4-bit) │ │ │ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ │ │ • Сложные │ │ • Простые │ │ │ │ баги │ │ тикеты │ │ │ │ • Анализ │ │ • Быстрая │ │ │ │ контекста │ │ классиф- │ │ │ │ • Генерация │ │ икация │ │ │ │ решений │ │ • Черновики │ │ │ └─────────────┘ └─────────────┘ │ │ │ │ 🔄 Авто-переключение по: │ │ • Длине тикета (>2K токенов → FULL) │ │ • Приоритету (Critical → FULL) │ │ • Ручной выбор разработчика │ └─────────────────────────────────────┘

Преимущества подхода:

  1. Качество там, где нужно: сложные кейсы обрабатывает мощная модель
  2. Скорость в рутине: простые задачи решаются мгновенно
  3. Предсказуемое потребление: оба режима укладываются в 16 ГБ VRAM
  4. Гибкость: разработчик может переключить режим вручную

📈 Результаты внедрения (через 4 недели)

📊 Метрики эффективности: ├─ Время обработки тикета: │ ├─ Было (ручная сортировка): 12.4 мин ± 3.1 │ └─ Стало (с агентом): 4.7 мин ± 1.8 (-62%) │ ├─ Точность авто-классификации: 91.3% │ (порог принятия: ≥85%) │ ├─ Удовлетворённость разработчиков: 4.6/5 │ "Агент реально экономит время, не тупит" │ ├─ Инциденты с OOM: 0 за 4 недели │ (при 100% использовании в команде из 12 человек) │ └─ Экономия времени команды: ~28 часов/неделю

🔧 Чеклист для повторения

Если вы хотите воспроизвести наш опыт:

# 1. Подготовка окружения git clone https://github.com/ggml-org/llama.cpp cd llama.cpp && cmake -B build -DGGML_CUDA=ON && cmake --build build -j # 2. Скачивание модели (выбирайте квант под вашу память) huggingface-cli download unsloth/Qwen3-Coder-Next-GGUF \ --include "*UD-IQ2_XXS*" \ # или Q3_XXS, если есть запас памяти --local-dir ./models # 3. Тестовый запуск с мониторингом памяти watch -n 1 nvidia-smi # в отдельном терминале ./build/bin/llama-cli \ --model ./models/Qwen3-Coder-Next-UD-IQ2_XXS.gguf \ --ctx-size 8192 \ --n-gpu-layers 20 \ # Начните с 10, увеличивайте до стабильности --batch-size 512 \ --cache-type-k q8_0 --cache-type-v q4_0 \ --prompt "Классифицируй баг: [вставьте пример]" \ --temp 0.2 --top-p 0.95 # 4. Настройка под вашу нагрузку # Если скорость <5 т/с → уменьшите --ctx-size или --n-gpu-layers # Если качество страдает → попробуйте Q3_XXS квант

💡 Ключевые инсайты, которые мы сделали для себя при работе над данным проектом

  1. Не гонитесь за 100% сохранением качества. Потеря 1-2% качества ради стабильного локального запуска — оправданный компромисс.
  2. Контроль над памятью важнее "магии". device_map="auto" удобен, но --n-gpu-layers даёт предсказуемость.
  3. Гибридные архитектуры требуют особого подхода. Для MoE-моделей квантование весов экспертов влияет на качество сильнее, чем удаление слоёв.
  4. Двухрежимная архитектура — лучший паттерн для продакшена. Не заставляйте одну модель решать все задачи.
  5. Измеряйте не только accuracy. Стабильность, скорость и потребление памяти — критичные метрики для локального деплоя.

🔗 Ресурсы, которые использовавли

Какой вывод можно сделать:

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