Реальный тест Qwen3-Code-Next на Mac: как избежать таймаутов при длинных контекстах и пересборке проектов

Когда 137 миллиардов параметров не спасают от таймаутов

В теории все звучит идеально. Берешь Qwen3-Code-Next — самую продвинутую MoE-модель для кодинга на 23 февраля 2026 года. Загружаешь ее в llama.cpp с MLX-бэкендом. Думаешь: "Сейчас закину весь проект, и нейросеть перепишет его с iOS на Windows за пару часов". Реальность бьет по лицу на 32-й минуте работы.

Зачем вообще переписывать iOS-проект под Windows в 2026?

Контекст: у клиента есть работающее iOS-приложение на SwiftUI с кастомным C++ движком для обработки видео. Приложение зарабатывает неплохие деньги. Но рынок Windows в их нише растет на 40% в год, а команда из трех человек не потянет параллельную разработку.

Решение? Автоматизировать переписывание через локальную LLM. Звучит как фантастика, но Qwen3-Code-Next с ее 137B параметрами (из которых активно ~36B) теоретически справится. Теоретически.

Железо, на котором все это крутилось

Mac Studio M4 Ultra с 192GB унифицированной памяти. Кажется, этого должно хватить для чего угодно. Но есть нюанс: llama.cpp с MLX-бэкендом все еще не идеально оптимизирован под MoE-архитектуры. Особенно под такие большие, как Qwen3-Code-Next.

Первая ошибка: закинуть весь проект разом

Начинаешь с простого: загружаешь в контекст все 120 файлов проекта. Общий размер — около 2.5MB кода. В токенах это примерно 650 тысяч. Даже сжатый контекст в llama.cpp не резиновый.

Первые 10 минут все работает. Модель анализирует архитектуру, предлагает структуру для Windows-версии. Потом начинается генерация первых файлов. Еще 15 минут — и скорость падает с 25 токенов в секунду до 3. Еще через 7 минут — клиент отваливается с таймаутом.

1 Как НЕ надо работать с длинным контекстом

Типичная ошибка новичка:

# ПЛОХО: загружаем все сразу
llama-cli -m qwen3-code-next-137b-q8.gguf \
  --ctx-size 131072 \
  --prompt "$(cat entire_project/*.swift)" \
  --instruction "Convert this iOS app to Windows C++"

Почему это плохо? Контекст в 131к токенов — это не просто память. Это активные вычисления для каждого нового токена. С каждым шагом модель должна "прогнать" внимание через все предыдущие токены. Экспоненциальный рост вычислений.

Решение, которое сработало: чанкование с умом

Вместо загрузки всего проекта разом, разбиваешь его на логические модули. Но не просто по файлам — по функциональным блокам.

Алгоритм:

1. Сначала загружаешь только файлы архитектуры (AppDelegate, SceneDelegate в iOS-мире)
2. Просишь модель создать каркас Windows-версии
3. Сохраняешь сгенерированный каркас
4. Перезапускаешь клиент (важно!)
5. Загружаешь следующий модуль + сгенерированный каркас как контекст
6. Повторяешь для каждого модуля

2 Правильный скрипт для поэтапной конвертации

#!/bin/bash
# convert_project.sh

MODEL="qwen3-code-next-137b-q8.gguf"
CTX_SIZE=32768  # Не больше! Иначе таймауты
MODULES=("core" "ui" "network" "database" "business_logic")

for module in "${MODULES[@]}"; do
  echo "Processing module: $module"
  
  # Собираем файлы модуля
  find ./ios_project -name "*$module*.swift" -exec cat {} + > temp_module.txt
  
  # Загружаем предыдущие результаты
  if [ -f "output/windows_framework.h" ]; then
    FRAMEWORK_CONTENT=$(cat output/windows_framework.h)
  else
    FRAMEWORK_CONTENT=""
  fi
  
  # Запускаем с ограничением по времени
  timeout 1800 llama-cli -m $MODEL \
    --ctx-size $CTX_SIZE \
    --prompt "Framework:\n$FRAMEWORK_CONTENT\n\nModule $module:\n$(cat temp_module.txt)" \
    --instruction "Convert this module to C++ for Windows, maintaining existing architecture" \
    > "output/${module}_converted.cpp"
  
  # Принудительный перезапуск клиента между модулями
  pkill -f llama-cli
  sleep 5
  
  echo "Module $module done"
done

Магия здесь в timeout 1800 — 30 минут максимум на модуль. И принудительный pkill между модулями. Жестко? Зато работает.

Проблема с CMake и системами сборки

Qwen3-Code-Next генерирует отличный C++ код. Но CMakeLists.txt — это отдельная боль. Модель часто "забывает", какие файлы уже сгенерированы, и создает конфликтующие таргеты.

Решение: отдельная сессия только для CMake. Сначала генерируешь весь код, собираешь список всех .cpp и .h файлов, потом одной командой просишь создать CMakeLists.txt.

Таймауты — это не баг, это фича

После недели экспериментов понял главное: таймауты в llama.cpp при работе с Qwen3-Code-Next — это не ошибка, а защита. Защита от перегрева железа и от бесконечных циклов генерации.

Когда контекст превышает 50к токенов, а модель пытается сгенерировать еще 10к кода, вычисления становятся слишком тяжелыми даже для M4 Ultra. Клиент отваливается, потому что серверная часть (llama.cpp) просто не успевает обрабатывать запросы.

Решение? Принудительные паузы и перезапуски. Каждый час работы — полный перезапуск llama-cli. Да, теряешь контекст. Но зато не теряешь всю сессию из-за таймаута.

Сравнение с другими моделями

Пробовал тот же проект на других моделях:

• Qwen2.5-Coder-72B: быстрее, меньше жрет памяти, но качество конвертации хуже. Путает современные C++ фичи.
• NousCoder-14B-GGUF: удивительно хорош для своего размера, но не тянет архитектурные решения. Подробнее в нашей статье про NousCoder-14B.
• IQuest-Coder-V1-40B-Instruct: полный провал. Генерирует красивый код, который не компилируется. Как мы писали в разборе IQuest-Coder, модель страдает от "галлюцинаций" синтаксиса.

Итоговые цифры проекта

После всех оптимизаций:

Что делать, если у тебя не Mac Studio Ultra

192GB памяти — это роскошь. Что если у тебя MacBook Pro M5 с 96GB или, не дай бог, 64GB?

Советы из реального боя:

1. Используй Q4_K_M вместо Q8_0. Качество падает на 10-15%, но модель занимает в 2 раза меньше памяти. Для многих задач этого достаточно.
2. Уменьшай контекст до 16384. Да, придется еще мельче дробить проект. Зато не будет таймаутов.
3. Пробуй Qwen2.5-Coder-32B. Серьезно. Для многих задач переписывания кода 32-миллиардная модель справляется почти так же хорошо, как 137B, но требует в 4 раза меньше ресурсов. Подробнее в сравнении моделей для MacBook.
4. Кэшируй результаты. Не генерируй один и тот же код дважды. Сохраняй вывод модели в файл и используй как шаблон.

Будущее локального кодинга с MoE

Qwen3-Code-Next — это первый реально рабочий MoE-кодер. Но архитектура еще сырая. Проблемы с таймаутами при длинном контексте — это симптом более глубокой проблемы: MoE-модели плохо оптимизированы для последовательных длинных вычислений.

Что ждет нас в 2026-2027?

• Лучшая поддержка в llama.cpp. Сейчас MLX-бэкенд обрабатывает MoE как обычную плотную модель. Когда появится native поддержка, скорость вырастет в 2-3 раза.
• Специализированные "эксперты" для разных языков. Представь модель, где Swift-эксперт и C++-эксперт работают параллельно над конвертацией.
• Динамическая загрузка экспертов. Вместо хранения всех 137B параметров в памяти — подгрузка нужных экспертов с SSD по мере необходимости.

Пока что Qwen3-Code-Next — это Ferrari в мире локальных код-моделей. Быстрая, мощная, но требующая умелых рук и дорогого бензина (в виде оперативной памяти). Если научишься обходить ее грабли в виде таймаутов и перегрева контекста — получишь инструмент, которого нет у 99% разработчиков.

А следующий шаг? Ждать Qwen4-Code-Next с обещанной оптимизацией под длинные контексты. Или переходить на специализированные инструменты вроде OpenCode с плагинами для работы с кодом. Но это уже другая история.