Skip to main content
DeepSeekApple Siliconлокальный ИИ

DeepSeek 4 Flash q2 на M5: что показал локальный запуск

Появился практический опыт запуска DeepSeek 4 Flash q2 на M5 MacBook с 128 ГБ RAM: около 30 tok/s, модель ест до 80 ГБ памяти, а tool calling местами ломает теги. Для локального AI implementation это уже не теория, а понятный ориентир по железу и ограничениям.

Технический контекст

Я люблю такие новости не за хайп, а за то, что они быстро ставят AI implementation на землю. Тут все просто: DeepSeek 4 Flash q2 уже гоняют локально на M5 MacBook с 128 ГБ RAM, и вживую получается около 30 tok/s.

Для однопользовательского локального сценария это уже не игрушка. Особенно если вы смотрите в сторону AI automation без облака, с приватными данными и предсказуемой задержкой.

Из того, что меня реально зацепило: по памяти сам DeepSeek занимает где-то до 80 ГБ. Остальное доедают соседние процессы, вроде Claude Code, Codex и прочих инструментов, которые легко откусывают еще примерно 35 ГБ.

То есть история не только про модель, а про весь рабочий стек вокруг нее. На бумаге у вас 128 ГБ, а по факту запас тает очень быстро, если вы не держите машину почти выделенной под инференс.

Еще один живой нюанс: tool calling работает не идеально, и модель иногда забывает закрывать теги. Я такие вещи считаю не косметикой, а инженерной деталью, потому что именно на них ломаются агентные пайплайны и автоматические цепочки действий.

Хорошая новость в том, что это выглядит как фиксимая проблема на уровне обвязки, валидации и постобработки. Плохая в том, что из коробки на это нельзя слепо опираться, если у вас продовая логика завязана на строгий формат.

Что это меняет для бизнеса и автоматизации

Я вижу тут три практических вывода. Первый: локальный деплой больших моделей на Apple Silicon уже реально обсуждать не как эксперимент, а как рабочую AI integration для команд, которым важны приватность и контроль.

Второй: порог по железу никуда не делся. Если у вас нет 128 ГБ и дисциплины по фоновым процессам, красивая идея быстро превращается в борьбу за память и нестабильный UX.

Третий: выигрывают те, кому нужен локальный кодовый ассистент, внутренний агент или закрытая обработка документов. Проигрывают те, кто ожидает облачную скорость и идеальный tool use без дополнительной инженерии.

Мы в Nahornyi AI Lab как раз разбираем такие кейсы руками: где локальная модель правда выгоднее API, как собрать AI architecture без лишних затрат и чем страховать tool calling, чтобы автоматизация не рассыпалась на мелочах. Если у вас назрел локальный AI automation контур, можно спокойно посмотреть на ваш стек и собрать решение без гадания по форумам.

Помимо оптимизации конкретных моделей вроде DeepSeek для локального оборудования, понимание различных реализаций локальных ассистентов имеет решающее значение для практического применения. Ранее мы исследовали Rust LocalGPT, который предлагает локального ассистента в виде единого бинарного файла с постоянной памятью и HTTP API, демонстрируя другой подход к практической реализации ИИ без лишних затрат.

Поделиться статьёй