Сравнение локальных моделей Qwen3.5 для генерации баг-репортов: тест на Swift с оценкой от Claude Sonnet

Проблема: облачные модели тормозят iOS разработку

Ты пишешь игру на Swift. Каждый баг - это не просто ошибка, это потенциальный вылет в App Store review. Раньше я кидал куски кода в Claude или GPT, ждал 10 секунд, получал развернутый баг-репорт и шел чинить. Пока команда не выросла до 15 iOS-разработчиков. Счета за API перевалили за $500 в месяц, а латентность превратила код-ревью в игру "кто дольше всех будет смотреть на спиннер".

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

Почему Qwen3.5? Потому что он не боится Swift

Я уже писал про Qwen3.5 в production для Go и Rust. С Swift история особая. Apple Silicon, ARC, Combine, SwiftUI - это не просто синтаксис, это целая экосистема. Большинство локальных моделей спотыкаются на optionals и async/await.

Qwen3.5-Coder (особенно версии 14B и 32B, актуальные на начало 2026) обучен на гигантском датасете кода, включая Swift. Он понимает разницу между @StateObject и @ObservedObject. Знает, что DispatchQueue.main.async может сломать анимацию. Это критично для генерации точных баг-репортов.

Выбор квантования: Q4_K_M против Q5_K_M и других

Скачивать исходные 32B модели - это 60GB. Безумие. Квантование GGUF спасает, но какое выбрать? Я протестировал три варианта на Mac Studio M4 Max с 96GB памяти:

Q5_K_M выиграл. Разница в 4GB памяти того стоила - модель почти не галлюцинировала на сложных багах с race condition. Q4_K_M иногда предлагала "фиксы", которые ломали ARC. IQ4_NL - новая техника квантования, о которой я писал в обзоре квантований на 2026 год. Быстрее, но требует сборки llama.cpp с флагами.

1Настройка LM Studio: неочевидные параметры

LM Studio 2026.03 (актуальная на март 2026) стала стабильнее. Но по умолчанию она использует настройки для чата, а не для анализа кода. Вот что меняю:

• Context length: 16384 (хватит для 5-7 Swift файлов)
• Temperature: 0.1 (баг-репорты должны быть точными, не творческими)
• GPU Offload: все слои на GPU (для M4 Max это 60+ слоев для 32B модели)
• Batch size: 512 (ускоряет обработку контекста)

2Opencode CLI: для автоматизации в CI/CD

LM Studio хороша для тестов, но в продакшене нужен скриптовый подход. Opencode CLI (новая версия 3.2 на 2026) работает поверх llama.cpp. Установка:

curl -fsSL https://opencode.dev/install.sh | bash
opencode model add qwen3.5-coder-32b-instruct-q5_k_m.gguf --source huggingface

Конфигурационный файл .opencode.yaml:

model: "qwen3.5-coder-32b-instruct-q5_k_m.gguf"
gpu_layers: 60
context: 16384
temperature: 0.1
template: |
  [INST] Анализируй следующий Swift код на наличие багов.
  Сгенерируй баг-репорт в формате:
  1. Шаги воспроизведения
  2. Ожидаемое поведение
  3. Фактическое поведение
  4. Версия iOS
  5. Возможная причина
  6. Предложи фикс

  Код:
  {{code}}
  [/INST]

Тест: реальный баг из игры на SpriteKit

Я взял проблемный код из своего проекта - утечка памяти в анимации SKAction. Далее - отрывок:

class GameScene: SKScene {
    var enemies: [SKSpriteNode] = []
    
    func spawnEnemy() {
        let enemy = SKSpriteNode(imageNamed: "enemy")
        enemies.append(enemy)
        addChild(enemy)
        
        let moveAction = SKAction.moveTo(x: 100, duration: 2.0)
        let removeAction = SKAction.removeFromParent()
        let sequence = SKAction.sequence([moveAction, removeAction])
        
        enemy.run(sequence) {
            // Этот completion блок создает retain cycle
            self.enemies.removeAll { $0 == enemy }
        }
    }
}

Я скормил этот код трем моделям: Qwen3.5-32B-Q5_K_M, Qwen3.5-14B-Q4_K_M и для сравнения Codex 5.3 через API (как эталон). Запрос: "Сгенерируй баг-репорт для этого кода".

Оценка через Claude Sonnet: как и зачем

Локальные модели могут генерировать тонны текста, но как оценить качество? Вручную проверять 100 баг-репортов в день - нет. Я автоматизировал оценку с помощью Claude Sonnet 3.7 API (на март 2026 это все еще самая надежная модель для аналитических задач).

Скрипт на Python отправляет сгенерированный баг-репорт в Claude с инструкцией: "Оцени баг-репорт по шкале от 1 до 10 по критериям: точность, полнота, ясность, полезность фикса. Ответь в JSON".

import anthropic
import json

client = anthropic.Anthropic(api_key="your_key")

def evaluate_bug_report(report, code):
    prompt = f"""Оцени этот баг-репорт для Swift кода.
    Код: {code}
    Баг-репорт: {report}
    
    Верни JSON: {{"accuracy": 1-10, "completeness": 1-10, "clarity": 1-10, "fix_quality": 1-10}}"""
    
    response = client.messages.create(
        model="claude-3-7-sonnet-20250224",
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": prompt}]
    )
    return json.loads(response.content[0].text)

Результаты: 32B-Q5_K_M почти догнал облако

После 50 тестовых баг-репортов получились такие средние оценки от Claude:

32B-Q5_K_M проигрывает облачным моделям в точности на 0.5-0.7 баллов, но в 2 раза быстрее и стоит $0.0001 за запрос (электричество + амортизация). Для 95% багов этого достаточно. 14B модель быстрее, но ее предложения по фиксам иногда опасны - например, она предлагала использовать unowned вместо weak в том самом completion блоке, что привело бы к крешам.

Нюансы, которые разорвут ваш пайплайн

Переход на локальные модели - не просто замена API эндпоинта. Вот что сломается точно:

• Контекст переполнится. Swift файлы могут быть большими. Решение: предварительно разбивай код на логические блоки или используй RAG с векторной базой по кодовой базе, как в этом гайде.
• Модель забудет инструкцию. В длинных сессиях LM Studio иногда "теряет" системный промпт. Решение: вставлять инструкцию в каждый пользовательский запрос.
• Температура накапливается. При последовательных запросах температура должна быть 0, но некоторые обертки llama.cpp сбрасывают ее не полностью. Решение: явно указывать --temp 0 в каждом вызове.

FAQ: ответы на частые вопросы

Можно ли использовать это для Objective-C?

Да, но качество будет ниже. Qwen3.5-Coder обучен в основном на Swift. Для Objective-C лучше взять специализированную модель, например, CodeLlama-34B-Instruct, но ее нужно дообучить.

Сколько стоит содержание такой системы в месяц?

Mac Studio M4 Max потребляет ~150Вт при полной нагрузке. При 8 часах работы в день это 36 кВт*ч в месяц. По московским тарифам на март 2026 - ~250 рублей. Плюс амортизация железа. В 10 раз дешевле облачных API для команды от 5 человек.

А если баг в многопоточном коде?

Локальные модели слабы в анализе concurrency. Они могут найти очевидные гонки, но сложные deadlock-и часто пропускают. Здесь без облачного Claude или ручного код-ревью не обойтись. Я использую гибридный подход: сначала локальная модель, если оценка Claude ниже 7 - отправляю в облако.

Где скачать актуальные GGUF модели Qwen3.5?

Hugging Face Hub - основной источник. Ищи TheBloke/Qwen3.5-Coder-32B-Instruct-GGUF. На март 2026 там есть все квантования до Q6_K. Избегай случайных источников - были случаи с троянами в весах.

Попробуй запустить Qwen3.5 на своем Mac. Начни с 14B-Q4_K_M, если памяти мало. Через неделю автоматической генерации баг-репортов ты удивишься, сколько проблем в коде ты раньше не замечал. И да, первый же отчет о memory leak в твоем коде будет немного обиден. Но это путь к качеству.

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