🎯 О чём этот конспект: Разбор реального опыта перехода на 100% локальную разработку с использованием мощных LLM (GLM-4.5 Air, Qwen2.5-Coder-32B, GPT-OSS-120B). Автор тестирует связку из двух машин (Framework Desktop с 128 ГБ RAM и ПК с RTX 5090), пытаясь заставить агентные инструменты (Cursor, OpenCode, Crush) работать без облачных API.

👤 Кому будет полезно: Вайбкодерам, которые хотят приватности, независимости от подписок и готовы инвестировать в собственное железо для запуска моделей уровня GPT-4 локально.

✨ Что получите: Понимание ограничений локальных моделей в агентных циклах, оптимальные настройки LM Studio для скорости и готовую стратегию распределения задач между «умными, но медленными» и «быстрыми» моделями.

1. Железо для локального AI: Лимиты пропускной способности

Контекст: Для запуска моделей уровня 100B+ параметров требуется огромный объем видеопамяти (VRAM). Автор использует Framework Desktop с 128 ГБ объединенной памяти (Unified Memory), из которых 96 ГБ выделено под VRAM в BIOS. Однако главной проблемой становится не объем, а пропускная способность памяти (Memory Bandwidth) — у данной системы она составляет 256 ГБ/с, что значительно медленнее топовых GPU (например, RTX 5090). Это создает «бутылочное горлышко» при обработке длинных контекстов.

Выгода: Возможность запускать модели, которые не влезают в обычные потребительские видеокарты (до 120B параметров), сохраняя тишину и умеренное энергопотребление (около 140 Вт).

Как применить:

• Шаг 1: Настройка BIOS — Framework Desktop — В настройках BIOS вручную выделите максимальный объем памяти под iGPU (в данном случае 96 ГБ из 128 ГБ), чтобы загружать тяжелые квантованные модели.
• Шаг 2: Выбор Runtime — LM Studio / llama.cpp — Если используете чипы AMD, тестируйте Vulcan вместо Rockm. Автор обнаружил, что Vulcan стабильнее работает с большими контекстами и не вызывает переполнения буфера.
• Шаг 3: Контроль лимитов мощности — Windows/Linux Power Settings — Установите режим «Performance», чтобы CPU/GPU могли буститься до 140 Вт, иначе скорость генерации (TPS) упадет при длительной нагрузке.

Результат: Стабильная работа тяжелых моделей (GLM-4.5 Air) на скорости 14-18 токенов в секунду (TPS).

---

2. Оптимизация LM Studio для ускорения Prompt Processing

Контекст: Самая долгая часть в локальном кодинге — это не сама генерация текста, а обработка входного промпта (Prompt Processing). Если вы скармливаете агенту весь кодовую базу (20k+ токенов), ожидание может составить 2-3 минуты. Автор экспериментально подобрал параметры, которые минимизируют это время.

Выгода: Сокращение времени ожидания первого токена (TTFB) и предотвращение тайм-аутов в IDE.

Как применить:

• Шаг 1: Тюнинг Batch Size — LM Studio — Установите Evaluation Batch Size на значение 2048. Это «золотая середина» между 512 и 4096, дающая максимальный прирост скорости на Framework Desktop.
• Шаг 2: Квантование KV-кэша — LM Studio — Включите K-cache Quantization и V-cache Quantization (выберите Q8). Это немного увеличит задержку, но существенно снизит потребление VRAM, позволяя работать с контекстом 100k+.
• Шаг 3: Активация Flash Attention — LM Studio — Всегда держите включенным Flash Attention для ускорения обработки длинных последовательностей.

Результат: Скорость обработки промпта около 170 токенов в секунду, что позволяет «переварить» 20k токенов за ~2 минуты.

---

3. Проблема тайм-аутов в агентных инструментах

Контекст: Популярные инструменты (OpenCode, Roo Code) не рассчитаны на медленную работу локальных моделей. Когда локальная LLM тратит 3 минуты на обдумывание, IDE обрывает соединение по тайм-ауту. Единственным инструментом, который позволил ждать завершения генерации сколько угодно долго, оказался Crush.

Выгода: Возможность использовать «тяжелые» модели в автоматических циклах правки кода без вылетов.

Как применить:

• Шаг 1: Смена инструмента — Crush — Используйте Crush вместо Cursor или Roo Code, если ваша локальная модель выдает меньше 5-10 TPS. Он не имеет жестких ограничений на время ожидания ответа.
• Шаг 2: Проверка Tool Calling — LM Studio — При выборе модели в LM Studio ищите иконку «молотка» (Tool Calling). Например, GLM-4.5 Air на текущий момент не поддерживает нативный вызов функций в LM Studio, что делает её бесполезной для агентов, но отличной для чата.

Результат: Работающая агентная связка, которая не «отваливается» на середине сложной задачи.

---

4. Стратегия «Двух моделей»: Worker + Planner

Контекст: Попытка использовать одну тяжелую модель для всего провалилась из-за медлительности. Автор пришел к гибридной схеме: маленькая и быстрая модель делает «грязную» работу, а большая — планирует и отвечает на сложные вопросы.

Выгода: Баланс между качеством кода и скоростью разработки.

Как применить:

• Шаг 1: Настройка "Воркера" — Qwen2.5-Coder-32B (или 7B) — Запустите её на быстрой видеокарте (например, RTX 3060/4090). Используйте её для автодополнения и простых правок в реальном времени.
• Шаг 2: Настройка "Планировщика" — GPT-OSS-120B или GLM-4.5 Air — Запустите её на системе с большим объемом RAM (Framework/Mac Studio). Используйте её через чат (например, Jan AI) для проектирования архитектуры или ревью кода.
• Шаг 3: Ручной перенос — Копируйте сложные архитектурные решения из чата с большой моделью в вашу IDE, где работает быстрая модель.

Результат: Вы получаете интеллект уровня GPT-4 для сложных задач и мгновенный отклик для рутинного кодинга.

---

FAQ

В: Какую модель лучше всего использовать для локального дизайна и фронтенда? О: Автор выделил GLM-4.5 Air. Несмотря на медлительность, она лучше всех справилась с задачей стилизации UI и создания современного дизайна страниц, превзойдя Qwen 30B и GPT-OSS-120B.

В: Почему агентные IDE (Roo Code, OpenCode) выдают ошибку при работе с локальными моделями? О: Основная причина — тайм-ауты. Локальные модели долго обрабатывают контекст (Prompt Processing), и IDE считает, что сервер не отвечает. Используйте Crush, так как он более терпим к задержкам.

В: Стоит ли покупать Framework Desktop для AI-кодинга? О: Да, если вам нужно 96ГБ+ VRAM по доступной цене. Но помните, что из-за низкой пропускной способности памяти (DDR5 vs VRAM на видеокартах) генерация будет медленной (около 15 TPS для больших моделей).

В: Какие настройки в LM Studio сильнее всего влияют на скорость? О: Evaluation Batch Size (ставьте 2048) и использование Flash Attention. Также важно следить за температурой: если процессор троттлит выше 80°C, скорость резко падает.

В: Можно ли полностью отказаться от Claude/GPT-4 в пользу локальных моделей? О: Да, но придется изменить стиль работы. Вместо полностью автономных агентов придется чаще использовать чат-интерфейсы (Back to Basics) и вручную переносить код, так как агентные циклы на локальном железе пока слишком медленны и склонны к ошибкам.

Конспект создан на основе видео «I coded locally all day... it was painful.» канала [Mckay Wrigley]. Все права на оригинальный материал принадлежат авторам. Источник: https://www.youtube.com/watch?v=0DET4YFzS6A