Claude Code на Mac M3: как заменить облако локальными моделями и не сойти с ума

Почему Claude Code раздражает на M3 Pro с 36 ГБ ОЗУ

Сидишь ты, пишешь Swift код в Xcode. Нужно быстро сгенерировать обработчик ошибок для сетевого запроса. Открываешь Claude Code, ждешь 3 секунды пока он подумает... и получаешь лимит запросов. Опять. На Mac M3 Pro с 36 ГБ оперативки, который мог бы запускать локальные модели размером с небольшую страну.

Я тестировал это на реальных задачах: рефакторинг 2000 строк SwiftUI кода, генерация тестов для Core Data, оптимизация алгоритмов сортировки. Облачные решения спотыкаются на третьем запросе. Локальные модели работают, пока не выключишь компьютер. Разница как между арендой квартиры и владением домом.

Какие модели реально работают на M3 Pro

Забудь про 70-миллиардные параметры. На M3 Pro с 36 ГБ ты упираешься в память, а не в вычислительную мощность. Вот что имеет смысл запускать:

Цифры из реальных тестов на моем M3 Pro. Q4 означает 4-битное квантование - модель теряет 2-5% качества, но занимает в 4 раза меньше памяти. Для кодинга это идеальный компромисс.

Три способа запустить локального кодинг-ассистента

1 LM Studio: для тех, кто ненавидит терминал

Если последний раз ты видел терминал в фильме про хакеров, начинай с LM Studio. Качаешь приложение, выбираешь модель из встроенного хаба, жмешь "Load". Через 2 минуты у тебя работает чат-интерфейс, куда можно копировать код и просить его исправить.

Но есть нюанс: LM Studio жрет память как не в себя. Загрузил модель на 12 ГБ - приложение занимает 14. Плюс 2 ГБ на само приложение. На 36 ГБ это терпимо, но если параллельно запущен Xcode с симулятором - начинается подкачка.

# Как проверить, сколько реально ест LM Studio:
sudo powermetrics --samplers smc | grep -i "ram"
# Или проще:
htop  # если установлен через brew

2 Ollama: терминальный вариант для минималистов

Ollama - это как Docker для моделей. Устанавливаешь одну команду, потом запускаешь любую модель из каталога. Потребляет на 20-30% меньше памяти, чем LM Studio, потому что нет графического интерфейса.

# Установка:
brew install ollama

# Запуск модели для кодинга:
ollama run deepseek-coder:6.7b

# В отдельном терминале можно делать запросы через API:
curl http://localhost:11434/api/generate -d '{
  "model": "deepseek-coder:6.7b",
  "prompt": "Напиши функцию на Swift для парсинга JSON"
}'

Ollama автоматически использует Metal Performance Shaders на Mac. Модели оптимизированы под Apple Silicon. Но если что-то пойдет не так, получишь загадочную ошибку типа "Exit code 6" - знакомо по LM Studio на M5.

3 Cline: клон Claude Code, который работает локально

Cline - это открытый аналог Claude Code, который цепляется к твоему редактору кода. Устанавливаешь расширение в VS Code или Zed, настраиваешь подключение к локальной модели (Ollama или LM Studio), и получаешь инлайн-подсказки прямо в редакторе.

Выглядит так: выделяешь код, жмешь Cmd+I, пишешь "оптимизируй этот цикл". Cline отправляет запрос в твою локальную модель и вставляет результат обратно. Без облаков, без API ключей.

Агенты против тулов: что лучше для реальной работы

Терминальные инструменты вроде Claude Code хороши для разовых задач. Но что если нужно автоматизировать процесс? Вот где появляются агенты.

Представь: ты пишешь команду "добавь обработку ошибок во все сетевые запросы в проекте". Агент:

• Сканирует проект, находит все URLSession вызовы
• Анализирует существующую обработку ошибок
• Генерирует единообразные обработчики
• Вставляет их в нужные места
• Создает коммит с изменениями

Самые интересные агенты для Mac:

1. Smithery - специализирован на рефакторинг. Умеет понимать архитектуру проекта, предлагать улучшения. Работает с локальными моделями через Ollama.
2. Cursor Agent Mode - встроен в редактор Cursor. Менее автономный, но лучше интегрирован. Требует облачную модель, но есть хаки для локального использования.
3. OpenDevin - открытый аналог Devin. Слишком сырой для production, но интересен для экспериментов.

Проблема агентов в том, что они часто "галлюцинируют". Попросишь добавить обработку ошибок - он перепишет половину проекта, сломав логику. Нужно ставить жесткие ограничения и проверять каждый шаг.

Конфигурация для Swift/Xcode разработки

Swift - особый язык. Многие модели тренировались в основном на Python и JavaScript. Swift для них как диалект. Вот как настроить локальную модель для максимальной эффективности:

# Создаем файл конфигурации для Ollama
cat > ~/.ollama/swift-coder-modelfile << EOF
FROM deepseek-coder:6.7b

# Системный промпт для Swift разработки
SYSTEM """
Ты - эксперт по Swift и iOS разработке. Ты работаешь в Xcode 15+
и знаешь современные фреймворки: SwiftUI, Combine, Swift Concurrency.

Твои ответы должны быть:
1. Краткими и по делу
2. С примерами кода на Swift 5.9+
3. С учетом best practices от Apple
4. Без лишних объяснений, если не просили

Особое внимание уделяй:
- Memory management (без retain cycles)
- Main actor isolation
- Error handling с Result типами
- Modern concurrency (async/await)
"""

PARAMETER temperature 0.2  # Меньше креативности, больше точности
PARAMETER top_p 0.9
EOF

# Создаем кастомную модель
ollama create swift-coder -f ~/.ollama/swift-coder-modelfile

Теперь при запуске ollama run swift-coder модель будет заточенной под Swift. Температура 0.2 вместо стандартных 0.7 - модель меньше "фантазирует", больше следует паттернам.

Оптимизация памяти: как не убить M3 Pro

36 ГБ звучит много. Но Xcode с симулятором iPhone 15 Pro съедает 8-12 ГБ. Остается 24 ГБ на модель. Кажется, много. На практике:

• Модель 16B в Q4: ~12 ГБ
• Контекст 8192 токенов: +4 ГБ
• Буферы для Metal API: +2 ГБ
• Итого: 18 ГБ

Остается 6 ГБ на систему и фоновые процессы. Если запустить Chrome с парой вкладок - начинается memory pressure. Решение:

# 1. Уменьшаем контекст для кодинга
# Для работы с кодом достаточно 4096 токенов
OLLAMA_CONTEXT_LENGTH=4096 ollama run swift-coder

# 2. Используем memory mapping
# В LM Studio включаем "Use memory mapping"
# Модель загружается частями, а не целиком

# 3. Закрываем всё лишнее перед работой
pkill -f "Adobe"  # Да, именно так
pkill -f "Google Chrome"
pkill -f "Slack"

Если планируешь серьезно работать с локальными моделями, посмотри как выбрать Mac для локальных LLM. M3 Pro с 36 ГБ - хороший баланс. M3 Max с 96 ГБ - роскошь, но дорого.

Чего не хватает в локальных решениях

После месяца работы с локальными моделями вместо Claude Code, я выделил три проблемы:

1. Нет понимания контекста проекта. Облачные ассистенты запоминают историю диалога, могут ссылаться на ранние обсуждения. Локальные модели - каждый запрос как первый.
2. Слабый анализ кода. Попросишь "найди баг в этом классе" - модель сгенерирует что-то общее. Claude Code умеет запускать код, тестировать, видеть реальные ошибки.
3. Нет доступа к документации. Когда пишешь "используй новый API из iOS 18", локальная модель тренировалась на данных до 2024 года. Не знает про новые фреймворки.

Решение? Гибридный подход. Простые задачи - локальная модель. Сложный анализ с доступом к интернету - облачный сервис. Но уже через локальный прокси, чтобы не отправлять весь код. Как в статье про обход ограничений Claude Code.

Мой стек на M3 Pro сегодня

После всех тестов и ошибок, вот что работает у меня ежедневно:

Это не идеально. Это компромисс. Но это работает без лимитов, без блокировок, без зависимости от интернета в поезде.

Через год, когда появятся 7B модели уровня сегодняшних 34B, возможно, локальное решение станет единственным нужным. Пока что - это мощное дополнение, которое экономит деньги и сохраняет контроль над кодом. А на Mac M3 Pro с 36 ГБ - еще и работает быстрее, чем облачные аналоги.