Содержание

Локальный coding agent на ds4: что проверить до покупки железа

ds4 поддерживает несколько моделей и GPU-бэкендов. Разбираем выбор конфигурации, приватность и проверку качества на своих задачах без неподтверждённых бенчмарков.

Запустить модель локально и получить полезного coding agent — разные задачи. Первая заканчивается ответом в терминале. Вторая — корректной правкой, которая проходит тесты и не требует больше времени на исправление, чем ручная работа.

Эта статья — разбор проекта и план проверки, а не отчёт о собственном тестировании на Mac с большим объёмом памяти. Прежние советы «только Metal», «только Flash» и универсальный порог 128 ГБ устарели. По ним нельзя выбирать оборудование.

Что изменилось в ds4

На 7 сентября 2026 репозиторий antirez/ds4 представляет проект как DwarfStar: движок с поддержкой Metal, CUDA и ROCm. В описании перечислены DeepSeek V4 Flash и Pro, а также модели семейства GLM. Проект использует подготовленные для него GGUF-файлы; произвольный GGUF не обязательно совместим.

Поддержка бэкенда не означает одинаковую производительность на всех видеокартах. Перед установкой откройте документацию выбранной модели и платформы в этом репозитории. Старый рецепт для одного Mac не следует переносить на Linux с другой схемой памяти.

Сначала заполните паспорт конфигурации

До скачивания весов запишите:

ПараметрЗачем он нужен
Commit движкаСвязать результат с конкретной реализацией
Модель и файл весовНе сравнивать разные модели под одним названием
КвантованиеУчитывать компромисс памяти и качества
CPU, GPU, RAM, VRAMПонять, где размещаются веса и рабочие данные
Контекст и максимальный ответПовторить реальную нагрузку
Версии ОС и драйвераВоспроизвести запуск и ошибки
Параметры запускаОтделить поведение модели от настроек движка

Объём файла на диске не равен всей памяти процесса. Кроме весов нужны рабочие буферы, контекст и память остальных программ. Даже успешная загрузка не показывает, насколько удобно будет работать с длинным диалогом. Проверяйте нужную конфигурацию до покупки, на доступной машине или по воспроизводимому отчёту с теми же параметрами.

Три задачи вместо одного красивого ответа

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

  1. Поиск причины ошибки. Дайте падающий тест и попросите объяснить путь данных. Оценивайте ссылки на реальные файлы, а не уверенность объяснения.
  2. Локальная правка. Попросите исправить ошибку без смены публичного API. Сравните diff и проверьте соседние сценарии.
  3. Работа после ошибки инструмента. Верните неуспешный результат теста. Проверьте, исправляет ли агент причину или просто повторяет команду.

Для каждого запуска сохраните время до первого полезного действия, полное время, результат тестов, число вмешательств и потребление памяти. Скорость генерации токенов записывайте отдельно: более быстрый текст не обязательно даёт более быстрый принятый PR.

Локальность проверяется по всей цепочке

Локальная модель может работать вместе с сетевым поиском, MCP-сервером или облачным fallback. Поэтому надпись localhost не доказывает, что данные остаются на машине. Проверьте конфигурацию инструментов, исходящие соединения и поведение при отключённой сети.

В тестовом репозитории нужны тестовые данные. Выдайте агенту только требуемые инструменты и отдельно проверьте отмену операции. Если он умеет отправлять сообщения или изменять удалённые ресурсы, это уже отдельные права — они не становятся безопасными из-за локального inference.

Когда эксперимент можно считать полезным

Сначала задайте собственный критерий: например, агент должен исправить выбранную регрессию, сохранить API и пройти тесты без ручной переписи решения. Это критерий приёмки, не результат проведённого здесь эксперимента.

Если задача не проходит, зафиксируйте точный сбой: неверный tool call, потеря инструкции, нехватка памяти или неправильная правка. Такой отчёт помогает выбрать следующую настройку. Обещание «заменяет облачный агент» без этой информации мало что говорит.

Для настройки инструкций пригодится шаблон CLAUDE.md.