Применение архитектуры Claude Code к локальным 9B моделям: ключевые выводы и оптимизации

Экспериментальная установка и ключевое открытие

Разработчик использовал RTX 5070 Ti (16 ГБ VRAM) с qwen3.5:9b через Ollama (6,6 ГБ) и локальный фреймворк агента OpenClaw. После 18 тестов и 10 оптимизаций ключевым выводом стало то, что qwen3.5:9b имеет нативные структурированные tool_calls, в то время как qwen2.5-coder:14b и qwen2.5:14b помещают JSON в поле content вместо правильных tool_calls, что требует дополнительного парсинга.

Сравнение производительности

Сравнение производительности моделей:

• qwen3.5:9b: Нативная структура tool_calls, включена цепочка размышлений, 39 ток/с
• qwen2.5-coder:14b: Сломанный вызов инструментов (в поле content), нет цепочки размышлений, ~30 ток/с
• qwen2.5:14b: Сломанный вызов инструментов (в поле content), нет цепочки размышлений, ~35 ток/с

10 оптимизаций из архитектуры Claude Code

• Структурированный системный промпт → +600% качества вывода (A/B-тестирование: 4 найденные проблемы против 25+)
• MicroCompact (сжатие результатов инструментов) → 80-93% сжатия, 11 КБ сокращено до 367 символов
• Жесткое ограничение (принудительный переход исследование→генерация) → Решена проблема циклов исследования, где 9B-модели застревают, читая файлы без генерации вывода
• think=false → 8-10-кратная эффективность токенов, устраняет языковое загрязнение
• Отложенная загрузка ToolSearch → -60% пространства промпта (229 против 568 токенов)
• Четырехтипная система памяти (пользователь/обратная связь/проект/справочная) → Персонализированные ответы
• Разветвление KV-кэша → Минимальный эффект на одном GPU (1,1x), требуется vLLM
• Строгая дисциплина записи → Проверка перед обновлением памяти, предотвращает повреждение памяти
• Параллельная инициализация → 9% быстрее холодный старт
• Отслеживание сброса кэша → Ollama кэширует идентичные промпты (182 мс→75 мс)

Основной вывод: Самодисциплина как реальный потолок

Самым важным выводом стало то, что реальный потолок для 9B-моделей — не способность к рассуждению или точность использования инструментов, а самодисциплина — понимание, когда прекратить исследование и начать генерировать вывод. Без жесткого ограничения модель использовала все 12 шагов на чтение файлов и произвела 0 байт отчета. С жестким ограничением: 5 шагов чтения + 1 шаг записи = 6080 байт структурированного отчета.

Что на самом деле может делать qwen3.5:9b

• Читать 800-строчные bash-скрипты и находить реальные ошибки (состояния гонки, неатомарные операции) — 2 мин
• Проектировать архитектуру системы обратной связи по продажам — документ 8,7 КБ за 2,5 мин
• Создать полный проект (калькулятор + тесты + запуск тестов) — 28 секунд
• 10-шаговое автономное выполнение: написать веб-скрапер → pip install не удается → найти обходной путь → повторить → тесты проходят — нулевое вмешательство человека
• Полный мини-конвейер фабрики: поиск → написание статьи → рецензирование → публикация в HTML — 2,5 мин

Производительность полного движка

Все 10 оптимизаций были упакованы в единый Python-движок (~280 строк). Результаты первого запуска:

• Инициализация: 527 мс (параллельная память + прогрев модели)
• Исследование: 5 шагов инструментов с MicroCompact (88% сжатия)
• Генерация: 1947 символов структурированного отчета
• Итого: 39,4 с / нулевая стоимость API

Что не сработало

• Разветвление KV-кэша на одном GPU (требуется multi-GPU или vLLM)
• Бюджет шагов в системном промпте (модель игнорирует мета-инструкции о своем собственном поведении)
• Серия qwen2.5 для вызова инструментов (проблемы с форматом)

Разработчик запускал это на WSL2 + Ubuntu 24.04 и готов поделиться дополнительными деталями или кодом движка.