Реально ли заменить Claude локальной моделью для ежедневного кодинга?

Тред на Hacker News «Ask HN: Has anyone replaced Claude/GPT with a local model for daily coding?» набрал более 600 голосов и 300 комментариев — это явно больная тема. Разработчики делятся живыми кейсами: у кого-то локальный стек уже заменяет Claude в продакшне, у кого-то пока только «на поиграться». Главный вывод: это реально, но с оговорками.

Qwen3.6-35B-A3B как фаворит для агентного кодирования

Qwen3.6-35B-A3B — последняя открытая MoE-модель (Mixture of Experts, смесь экспертов) от Alibaba: 35 миллиардов параметров суммарно, но при генерации каждого токена активируются лишь 3 миллиарда. Это делает её исключительно эффективной для локального развёртывания.

Несмотря на компактность, Qwen3.6-35B-A3B показывает выдающиеся результаты в агентном кодировании — значительно превосходит предшественницу Qwen3.5-35B-A3B и конкурирует с куда более крупными плотными моделями, такими как Qwen3.5-27B и Gemma4-31B.

ℹ Железо
Для запуска Qwen3.6-35B-A3B достаточно Mac с 24 ГБ оперативной памяти (при GGUF-квантизации) или видеокарты RTX 3090/4090 с 24 ГБ VRAM. Mac Studio / MacBook с 36–128 ГБ unified memory — идеальный вариант.

Автор треда Greenpants рассказывает, что полностью перешёл на локальный стек из соображений конфиденциальности и бесплатности. Он запускает Qwen3.6-35B через Pi coding harness (агентный фреймворк для кодинга) в контейнере без доступа к интернету на Mac Studio с 128 ГБ RAM.

Qwen3.6 35b в агентном режиме — как джуниор со знаниями во всех областях, которого нужно постоянно направлять, тогда как Claude Opus — как сеньор, который думает вместе с тобой об архитектуре.

При этом автор оценивает локальную модель в 5× ускорение по сравнению с ручным кодингом, а Claude Opus — в 15×. Разница есть, но при нулевой стоимости результат всё равно впечатляет.

Сравнение: локальная модель vs Claude Opus

ПараметрQwen3.6-35B (локально)Claude Opus (облако)
СтоимостьБесплатноПлатно (API)
ПриватностьПолная (офлайн)Данные уходят в облако
Ускорение разработки~5×~15×
Работа с нишевыми фреймворкамиСлабееСильнее
Автономность рассужденийТребует чётких промптовДумает самостоятельно
ДоступностьЛюбое железоЗависит от API

Vulkan vs ROCm: неожиданный победитель

Пользователь lambda, работающий на ноутбуке Strix Halo с 128 ГБ unified memory и запускающий llama.cpp в контейнере, поделился интересным наблюдением: Vulkan-бэкенд оказывается быстрее ROCm даже при работе с AMD-железом.

Ранее уже фиксировались случаи, когда llama.cpp с Vulkan обгонял AMD ROCm в ряде LLM-бенчмарков. Vulkan обеспечивает наиболее широкое покрытие железа — Nvidia, AMD, Intel, старые GPU и ряд Apple/Asahi-конфигураций.

💡 Практический совет
Если запускаете llama.cpp на AMD GPU — попробуйте Vulkan-бэкенд вместо ROCm. Для большинства AMD-пользователей на Windows Vulkan — это практический выбор. На Linux ROCm может давать на 10–20% больше throughput, но Vulkan работает на любом железе без дополнительных настроек.

Проблема кэширования контекста и её решение

Один из технических нюансов, поднятых в треде, — неэффективное кэширование KV-кэша (Key-Value Cache) у гибридных MoE-моделей Qwen. При каждом новом ходе в диалоге модель пересчитывала весь контекст заново.

Пользователь lambda объясняет корень проблемы: старые модели Qwen не умели сохранять цепочку рассуждений (thinking trace) между ходами, и при следующем промпте весь interleaved context приходилось обрабатывать заново. Qwen3.6 это исправляет.

Решение — одна строка в конфиге llama.cpp:

chat-template-kwargs = {"preserve_thinking": true}

Эта настройка включает сохранение рассуждений между ходами, что резко сокращает повторные вычисления.

⚠ Важно
Обновите llama.cpp до последней версии — ряд багов с повторной обработкой контекста был исправлен в upstream. Флаг preserve_thinking работает только с Qwen3.6+.

Типичный локальный стек для кодинга в 2026 году


graph TD
    A[Разработчик] --> B[Pi / агентный фреймворк]
    B --> C[llama.cpp в контейнере]
    C --> D{Задача}
    D -->|Быстрое кодирование| E[Qwen3.6-35B-A3B\n3B активных параметров]
    D -->|Сложные задачи| F[Qwen3.5-122B-A10B\n10B активных параметров]
    D -->|Чат и переводы| G[Gemma 4 31B]
    D -->|Аудио| H[Gemma 4 12B]
    E --> I[Mac Studio / Strix Halo\n128 ГБ RAM]
    F --> I
    G --> I
    H --> I

Слабые стороны локального подхода

Пользователи честно говорят о минусах:

  • Нужна точность в промптах. Модель не додумывает за вас — любые неоднозначности она разрешает в сторону простейшего решения (например, пишет CSS прямо в HTML вместо отдельного файла).
  • Петли и ошибки инструментов. Агент нередко застревает в циклах или неправильно вызывает edit tool, после чего тратит много токенов на повторное чтение файлов.
  • Нишевые фреймворки — слабое место. Без доступа к интернету модель может не знать специфику менее распространённых библиотек вроде Wagtail.
📝 Модели под разные задачи
  • Агентное кодирование: Qwen3.6-35B-A3B (быстро) или Qwen3.5-122B-A10B (мощнее)
  • Чат и переводы: Gemma 4 31B
  • Аудио: Gemma 4 12B
  • Максимальное качество кодинга: Qwen3-Coder-480B-A35B — достигает SOTA-результатов, конкурируя с Claude Sonnet-4 и GPT-4.1

Контекст и значение для отрасли

Qwen3.6-35B-A3B вышла 16 апреля 2026 года под лицензией Apache 2.0 и доступна на Hugging Face, Ollama и Unsloth (в формате GGUF). Тот факт, что модель с конкурентоспособным качеством кодинга теперь работает на потребительском железе полностью офлайн — это серьёзный сдвиг.

Благодаря архитектуре MoE с ~3B активными параметрами модель генерирует токены примерно в 3–5 раз быстрее, чем плотная 27B-модель на аналогичном железе — и это при полном отсутствии затрат на API.

Дискуссия на Hacker News показывает: локальные модели перестали быть уделом энтузиастов и постепенно становятся реальной альтернативой для privacy-ориентированных разработчиков и компаний, которые не готовы отправлять свой код в облако.