В этой статье мы рассмотрим, как использовать локальные большие языковые модели (LLM) для написания кода, сравнивая их с облачными аналогами. Мы протестируем различные модели на MacBook Pro с процессором M4 Pro, оценивая скорость, качество и удобство использования в режимах чата и агентской работы.

Ограничения облачных моделей

Облачные LLM имеют ряд существенных ограничений:

• Лимиты: Часовые, суточные и недельные квоты на использование, после исчерпания которых доступ к модели блокируется до начала нового периода. Решение — переход на другой тариф или другой сервис.
• Приватность: Все данные (код, промпты, файлы), обрабатываемые агентом, передаются на удалённые серверы провайдера LLM. Это вызывает опасения при работе с конфиденциальной информацией.
• SLA и сетевая задержка: Зависимость от стабильности сети и серверов провайдера, что может приводить к задержкам и недоступности сервиса.

Альтернативой является развёртывание LLM локально, что решает проблемы приватности и зависимости от сети.

Локальные модели: компромисс качества и ресурсов

Использование локальных моделей требует компромисса между качеством и доступными ресурсами компьютера. Мощные облачные модели требуют значительных объёмов оперативной (RAM) и видеопамяти (VRAM). Локально такие ресурсы ограничены, поэтому приходится выбирать модели с меньшим числом параметров.

Идеальный сценарий — полная загрузка модели в VRAM для максимальной скорости. Загрузка в RAM также возможна, но скорость будет ниже.

Основная цель тестирования — оценить, могут ли локальные модели отвечать с приемлемой скоростью и качеством, сравнимым с облачными.

Память Apple Silicon

Тестирование проводилось на MacBook Pro с процессором M4 Pro и 48 ГБ унифицированной памяти. Эта архитектура объединяет RAM и VRAM в один пул, что позволяет использовать весь объём для модели. Однако, другие запущенные приложения также потребляют эту память, что может влиять на производительность.

Поиск и выбор локальной модели

Для поиска локальных моделей удобно использовать платформы вроде Hugging Face, где доступны фильтры для выбора:

• Специализация: Модели могут быть узконаправленными (например, для кода — с префиксом 'coder') или универсальными.
• Ресурсы и совместимость: Важно учитывать требования модели к железу и доступный объём памяти, включая память для контекста.
• Форматы: GGUF — универсальный формат, MLX — оптимизированный для Apple Silicon.
• Режим «думающей модели» (thinking mode): Модели, которые демонстрируют процесс рассуждения перед ответом. Они медленнее, но могут давать более качественные результаты для сложных задач.
• Поддержка Function Calling: Важна для агентов, позволяя моделям взаимодействовать с внешними программами.

Разбор аббревиатур в названии модели

Понимание обозначений в названиях моделей помогает сделать правильный выбор:

• Семейство и назначение: Например, Qwen3-Coder указывает на модель семейства Qwen, ориентированную на код.
• Размер (параметры): 30B означает 30 миллиардов параметров. Большее количество параметров обычно улучшает качество, но увеличивает требования к ресурсам и снижает скорость.
• Архитектура: A3B (Mixture of Experts) позволяет активировать только часть параметров, ускоряя работу.
• Тип модели: Instruct — модель, отвечающая напрямую, без режима размышления.
• Оптимизация: MLX — для Apple Silicon.
• Квантизация: 4bit указывает на количество бит на слой. Меньшее число бит ускоряет модель, но может снизить качество ответов.

Оценки скорости работы моделей

Для оценки производительности используются специальные калькуляторы (например, VRAM-калькуляторы) и инструменты вроде oMLX для Mac. Они помогают прогнозировать скорость генерации токенов, но реальные замеры могут отличаться.

Запуск LLM локально

Существует несколько популярных инструментов для локального запуска LLM:

• Ollama: Консольный интерфейс, удобен для серверов.
• LM Studio: Графический интерфейс с удобным чатом и совместимым API, что делает его предпочтительным для локального использования.

После установки LM Studio необходимо включить локальный сервер для подключения агентов.

Загрузка и настройка модели в LM Studio

Для примера возьмём модель Qwen3-Coder-30B-A3B-Instruct-MLX-4bit. После скачивания в LM Studio, модель загружается. Для корректной работы с внешними агентами требуется включить CORS в настройках сервера.

LM Studio предлагает встроенный чат для прямого взаимодействия с LLM и замер скорости генерации ответов.

Подключаем агентов

Тестирование проводилось с использованием следующих агентов:

• Kilo Code: Плагин для VS Code, IntelliJ IDEA и CLI-версия.
• Open Code: Популярный CLI-агент.
• Claude Code: CLI-агент от Anthropic.
• Aider: Простой CLI-агент-помощник по кодингу.

Подключение агентов к локальной модели LM Studio обычно сводится к настройке переменных окружения и указанию пути к локальному API.

Настройка агентов

• Claude Code: LM Studio поддерживает его API напрямую. Требуется указать переменную окружения с именем модели.
• Kilo Code: Поддерживает LM Studio «из коробки».
• Open Code: Настраивается через конфигурационный файл.
• Aider: Настраивается через переменные окружения, указывается путь к модели.

Тестирование: Замеры в режиме чата

Тестирование проводилось в чате LM Studio с использованием различных локальных моделей. Оценивались скорость генерации токенов, время выполнения этапов задачи (рефакторинг, ревью, исправление) и качество полученных результатов по 10-балльной шкале.

Ключевые наблюдения:

• Скорость локальных моделей в чате сопоставима с облачными, но качество ответов может быть ниже.
• Модели с архитектурой MoE (Mixture of Experts) показывают хороший баланс скорости и качества.
• Режим thinking улучшает качество ответов как локальных, так и облачных моделей.
• Модели Qwen3.5-27B-4bit и Gemma-4-26B-A4B показали высокие результаты на этапе ревью.
• Gemma-4-26B-A4B выделяется хорошим качеством и скоростью.
• Большая битность (например, 6 бит против 4 бит) увеличивает время ответа без заметного прироста качества.
• Разница в скорости между форматами GGUF и MLX на Mac оказалась не столь значительной.

Сравнительное тестирование с облачными моделями показало, что они также требуют времени на ответ, особенно в режиме thinking.

Тестирование: Замеры в режиме агента

Эксперимент с агентами показал, что этот режим значительно более требователен к ресурсам. Замеры времени выполнения задач увеличились в разы.

Ключевые наблюдения:

• Режим агента требует значительно больше времени и ресурсов, чем чат. Локальные модели испытывают высокую нагрузку, что приводит к нагреву MacBook и шуму кулеров.
• Модели Qwen3.5-27B-4bit и nvidia-nemotron-3-nano-30b-a3b были остановлены из-за слишком долгого выполнения первого этапа.
• Gemma-4 показала хорошие результаты на этапе ревью.
• Облачные модели демонстрируют лучшее качество, скорость и комфорт в агентском режиме.
• При работе агентов требуется значительный объём памяти как для модели, так и для контекста.
• Более простые агенты (Aider, OpenCode) работают быстрее, но требуют большего взаимодействия. Продвинутые агенты (Kilo Code, Claude Code) генерируют больше контекста, что увеличивает нагрузку на модель.
• Некоторые агенты и модели предлагают компиляцию и запуск кода, что зависит от их возможностей и конфигурации.

Итоги и рекомендации

Общие выводы

Работа с локальными LLM на современном компьютере уровня MacBook M4 возможна, но с оговорками.

В режиме чата локальные модели обеспечивают приемлемую скорость и качество, сохраняя приватность данных. Рекомендуются модели с MoE-архитектурой.

В режиме агентов локальные модели подходят скорее для разовых задач, чем для постоянной работы. Высокая нагрузка на систему, память и постоянный нагрев снижают комфорт использования.

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

Рекомендации для использования локальных моделей

• Отдельный компьютер: Разверните модель на отдельном устройстве (например, Mac mini), чтобы не нагружать рабочую станцию и избежать конфликта ресурсов.
• Выбор моделей: Отдавайте предпочтение свежим моделям на MoE-архитектурах (например, Qwen3.6) и тестируйте их под свои задачи.
• Режим чата: Для простых задач используйте режим чата — это быстрее и продуктивнее.
• Агентский режим: При выборе агентов для локальных моделей отдавайте предпочтение более простым (Aider, OpenCode) вместо ресурсоёмких (Kilo Code, Claude Code).
• Выбор оборудования: При покупке компьютера для LLM ориентируйтесь на реальные замеры производительности и требования к VRAM.
• Качество: Помните, что локальные модели, как правило, уступают в качестве большим облачным моделям.

Полные таблицы с замерами и исходные коды тестов доступны на GitHub.

Когда возникают мысли про бесплатное использование агентов для написания кода, появляются два варианта: поискать бесплатные сервисы и использовать локальные модели. В прошлойстатьемы рассмотрели возможности бесплатного использования облачных моделей. В этой же статье мы посмотрим, можно ли использовать локальные модели для написания кода с помощью тех же агентов.

Ограничения у облачных моделей

У всех облачных моделей есть ряд ограничений. Рассмотрим основные из них.Лимиты(часовые, суточные и недельные). Когда квоты заканчиваются, вы не можете пользоваться моделью до начала нового периода с новыми квотами. Решения тут могут быть только такими: использовать другого провайдера или перейти на более дорогой тарифный план с большими квотами.Приватность. Всё, с чем работает ваш агент (код, промпты, файлы), передаётся на удалённые серверы провайдера LLM, который предоставляет вам модель. Моделям нужны ваши данные для анализа и подготовки ответов — по‑другому практически никак.Но есть альтернатива: развернуть модель локально и не передавать данные никуда.SLA и сетевая задержка. Как и любые другие сервисы, облачные модели требуют времени на передачу данных по сети и не всегда могут быть доступны.

Локальные модели: компромисс качества и ресурсовЛокальные модели и ресурсы

Сразу становится понятно, что за приватность придётся платить качеством модели. На серверах работают огромные модели, которым нужно много ресурсов. Критически важные из них — это оперативная память (RAM) и видеопамять (VRAM). Локально у нас нет столько ресурсов, и приходится балансировать между нашими ресурсами и качеством модели. И как следствие — использовать модели с меньшим числом параметров.

Для быстрой работы нужно, чтобы вся модель помещалась в VRAM — это идеальный вариант. Если она полностью поместится в RAM — это рабочий вариант, но уже не такой хороший по скорости.

Наша основная цель — проверить, может ли локальная модель отвечать за время, сравнимое с облачной, и при этом с приемлемым качеством.

Память Apple Silicon

Тестировать мы будем на MacBook Pro с процессором M4 Pro и 48 ГБ памяти. Машина достаточно мощная и должна себя хорошо показать. Мы ожидаем, что скорость её работы будет ненамного хуже, чем у облачных моделей, но качество — ниже. На других конфигурациях могут быть другие результаты.

Стоит ещё немного рассказать про память в устройствах Apple. Архитектура Apple Silicon: процессоры серии M используют так называемую unified memory (унифицированная память) — это общая память и для графического, и для центрального процессора. Значит, у нас нет раздельной оперативной памяти и видеопамяти. У нас один пул памяти, который доступен как центральному, так и графическому процессору. С одной стороны, это для нас очень хорошо, так как 48 ГБ памяти (за исключением затрат на приложения) доступны нам для модели, и это очень хорошие цифры. Но с другой стороны, все работающие приложения потребляют ту же память, что и модель, и могут мешать друг другу.

Поиск локальной модели

Как найти и выбрать локальную модель?

Теперь, когда мы разобрались с возможностями Mac, перейдём к выбору подходящей модели. Для поиска моделей существуют специальные агрегаторы с фильтрами, напримерHugging Face, где представлено множество моделей, доступных для локального использования. Там есть фильтры, которые помогают в поиске.

Что важно знать при поиске модели:

• Специализация.Модели могут быть узконаправленными (например,Qwen3-Coder, для написания кода — в названии часто встречаетсяcoder) или более общими (например,Qwen3.5, которая может работать как с текстом, так и с картинками).
• Ресурсы и совместимость.Если зарегистрироваться и добавить свою конфигурацию ресурсов, можно отслеживать, какая модель совместима с вашим железом, а какая потребует слишком много ресурсов. Такая же возможность проверки есть в поиске модели в LM Studio. Тут стоит помнить, что кроме ресурсов для модели вам еще нужна память для контекста, с которым модель будет работать.
• Форматы: GGUF и MLXGGUF— универсальный формат, работает на любых системах, обычно имеет больше настроек запуска моделиMLX— специальная версия для Mac с процессорами M-серии, оптимизированная для максимальной скорости.
• Думающие модели (thinking mode).Это модели, которые перед тем как дать ответ, как бы «думают» — вы видите их рассуждения и финальный результат. Обычно они медленнее, но дают лучший результат.Qwen3.5пример такой модели. Также стоит уточнить, что такие модели полезны для сложных рассуждений, но не для быстрого кодинга.
• Использование сторонних инструментов (Function Calling)—поддержка вызова инструментов (Function Calling) важна для агентов, так как позволяет модели взаимодействовать с внешними программами.

Разбор аббревиатур в названии модели

После того как вы познакомились с критериями выбора, полезно разобраться, что означают буквы и цифры в названии модели. Чтобы лучше понимать модели, разберём обозначения в названии модели на примереQwen3-Coder-30B-A3B-Instruct-MLX-4bit

• Qwen3— семейство моделей отAlibaba Cloud.
• Coder— указание на то, что модель ориентирована на работу с кодом.
• 30B— размер модели в миллиардах параметров (30 миллиардов). Обычно больше параметров даёт лучшее качество, но модель работает медленнее и требует больше памяти.
• A3B— обозначение архитектуры MoE (Mixture of Experts). Может отсутствовать в названии. Позволяет выжать максимум скорости: активируются только 3 миллиарда параметров из 30, благодаря чему скорость близка к 3B-модели, а качество — к 30B.
• Instruct— модель, которая даёт ответ без предварительного «размышления» (без режима Thinking). Обычно отвечает быстрее и точнее реагирует на ваши команды.
• MLX— версия для архитектуры Apple Silicon.
• 4bit— квантизация (количество бит на один слой). Чем больше бит, тем точнее модель, но медленнее; чем меньше — тем быстрее, но менее качественные ответы может давать.

Далее посмотрим на еще одну характеристику моделей, которую редко встретишь на агрегаторах.

Оценки скорости работы моделей

Вопрос довольно сложный, так как нужно искать баланс между качеством и скоростью работы. Ограничение сверху — модель должна помещаться в вашу память, и лучше с запасом. Есть ресурсы, напримерVRAM-калькуляторилиPerformance Explorer, которые помогают оценить скорость генерации токенов на вашей конфигурации для разных моделей. Стоит на него посмотреть, чтобы оценить производительность вашего железа. Вряд ли вас устроит модель, которая часами будет генерировать ответ. Однако слепо доверять таким прогнозам не стоит — это лишь ориентир для первичного сравнения.

Если у вас Mac с процессорами M-серии, то есть интересный проектoMLX, который пытается максимально оптимизировать скорость работы LLM, сам проект я не пробовал использовать. Но у него естьинтересная страница, с реальными замерами разных моделей с разными конфигурациями железа и с разными размерами контекстов. Данные со страницы выглядят достоверными и согласуются с моими наблюдениями.

Запуск LLM локально

Теперь, когда мы разобрались с оценкой скорости, перейдём к практическому запуску моделей. На сегодняшний день есть много способов запустить LLM локально. Рассмотрим несколько самых популярных из них:

• Ollama— консольный интерфейс, который позволяет скачивать и запускать LLM (на мой взгляд, больше подходит для развёртывания на своих серверах из-за отсутствия удобного интерфейса).
• LM Studio— имеет удобный графический интерфейс, работать в котором приятнее. Имеет встроенный чат и совместимый API со многими агентами.

Можно взять любую из них или любое другое решение — подход будет одинаковым. Мы же остановимся на LM Studio. Скачать её можно с официального сайта и установить. После запуска стоит сразу включитьлокальный сервер, чтобы агенты могли подключаться к модели по API. Сервер будет обрабатывать наши запросы и передавать их локальной модели.

Загрузка и настройка модели в LM Studio

После того как мы выбрали LM Studio в качестве инструмента, перейдём к загрузке и настройке конкретной модели. Возьмём для примера модельQwen3-Coder-30B-A3B-Instruct-MLX-4bit, которую ранее нашли на Hugging Face. Открываем LM Studio, вводим в поиск название модели и скачиваем её.

После того, как скачали, нам нужно её загрузить.

Для корректной работы с расширениями нужно ещё в настройках сервера включить CORS. CORS необходим для того, чтобы внешние агенты (например, Claude Code) могли подключаться к серверу LM Studio.

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

В LM Studio уже есть встроенный чат, через который мы можем общаться с LLM. Это довольно удобно, если нам не нужно менять существующий код (например, для генерации разового скрипта или других одноразовых задач). Кроме того, там есть встроенный замер скорости генерации ответа — очень полезная вещь, чтобы сравнить реальные результаты моделей между собой и с прогнозируемыми оценками.

Теперь, когда модель загружена и настроена, перейдём к подключению агентов.

Подключаем агентов

Тестировать мы будем на нескольких агентах: Claude Code, Kilo Code, Open Code, Aider. У нас будет несколько агентов, некоторые из них работают через CLI, другие — как плагины для VS Code. Не буду рассказывать, как установить каждый из них, про это есть много статей, только кратко расскажем как их подключить к локальной модели.

• Kilo Code (v5.12.0) — в эксперименте был какплагиндля VS Code, также плагин для IntelliJ IDEA и есть CLI. Kilo Code — форк Roo Code, который, в свою очередь,является форком Cline. Поэтому эти агенты так похожи между собой.
• Open Code —CLI-агентс большим количеством звезд на GitHub.
• Claude Code — наверное самый популярный CLIагентна сегодня от Anthropic.
• Aider — небольшой CLIагент, который себя позиционирует как помощник по кодингу

Claude Code

Нам нужно научить Claude Code работать с нашей локальной LLM. Первое, что стоит знать: у Claude Code свой API, немного другой, чем у всех остальных. В прошлый раз мы использовалиClaude Code Router. Но в этот раз нам это не нужно — LM Studio поддерживает этот формат API из коробки.

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

Запуск через стандартный вариант из консоли — нужно только указать название модели (можно скопировать из LM Studio):

claude --model qwen3-coder-30b-a3b-instruct-mlx

Kilo Code из коробки поддерживает LM Studio, поэтому просто добавляем нового провайдера и переключаем все профили для него.

Настройка конфигурации Open Code делается через файл, расположенный по пути~/.config/opencode/opencode.json. Вот пример файла с конфигурацией для 2 локальных моделей.

Далее при запуске Open Code в терминале нужно переключить на нужную нам модель, через команду/models

Aider настраивается схожим способом с Claude Code черезпеременные окружения

и запускается с указанием имени модели:

aider --model lm_studio/qwen3-coder-30b-a3b-instruct-mlx-4bit

После настройки всех агентов мы можем приступать к тестированию их работы.

Что и как попробуем тестировать

Данное тестирование очень субъективное и не отражает полной картины работы моделей или агентов, оно не предназначено для сравнения моделей или агентов между собой. К результатам стоит относиться с большой долей скепсиса. Но должно дать какое-то представление о времени работы моделей.

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

Краткое описание моделей

Возьмем несколько моделей, которые попробуем потестировать, я выбрал самые интересные для меня:

• Qwen3-Coder— возьмем за основную модель, так же возьмем ее вариации, модель в5-битнойи6-битнойквантизации иGGUF
• Qwen3-Coder-Next— новое поколение модели qwen3-coder
• Qwen3.5— думающая модель от Qwen, а также её варианты:9B, MoEQwen3.5-35B-A3Bи дообученная наOpus
• и пару новых моделейNvidia Nemotron-3иGemma-4-26B-A4B, Gemma-4 возьмем в формате GGUF, так как с MLX пока естьпроблемы.

План тестирования

Тест состоит из нескольких этапов: сначала модель получает код на рефакторинг, затем — на ревью, и наконец — замечания для исправления.

Подробное описание плана:

• Этап 1даем LLM задачу на рефакторингзамеряем время выполненияделаем оценку результата работы
• Этап 2просим модель сделать ревью полученного кода и найти проблемыпросим устранить проблемы, которые она нашлазамеряем время выполненияделаем оценку результата работы
• Этап 3даем модели замечания к устранениюзамеряем времяделаем оценку результата работысуммируем общее время работы

Делать оценку кода мы будем тоже через LLM, возьмем deepseek и прямо в чате будем ему давать код и файлы для оценки.

После нескольких подходов с deepseek, пришли к 10-балльной шкале оценок:

Макс. балл

Точность денежных расчётов (BigDecimal + округление + корректное преобразование)

Типобезопасность (enum для категорий, DTO вместо Map)

Настраиваемость порога (не магическое число)

Валидация и обработка ошибок (null, неотрицательность, диапазон скидки, пропуск элементов)

Логирование (не System.out/err)

Модульные тесты (наличие)

Иммутабельность DTO

Чистая архитектура (разделение ответственности, внедрение зависимостей)

Это формальные критерии. Баллы также будут снижаться за дублирование кода, нерабочий код и другие недочёты

Сам же изначальный код для рефакторинга оставим такой же как и в прошлой статье

Замеры в режиме чата

В LM Studio есть встроенный чат, на котором мы и протестируем наши модели. Это заняло немного времени и вот результаты:

локальная модель

скорость генерации токенов (ток/сек)

время 1 этапа (сек)

оценка после 1 этапа

время review (сек)

время 2 этапа(сек)

оценка после 2 этапа

время 3 этапа (сек)

оценка после 3 этапа

суммарное время работы (мин:сек)

qwen3-coder-30b-a3b-instruct-4bit-gguf

qwen3-coder-30b-a3b-instruct-mlx@4bit

qwen3-coder-30b-a3b-instruct-mlx@5bit

qwen3-coder-30b-a3b-instruct-mlx@6bit

qwen3-coder-next-reap-48b-a3b-oq3.5

Qwen3.5-27B-4bit (thinking)

Qwen3.5-9B-4bit (thinking)

qwen3.5-35b-a3b-4bit (thinking)

qwen3.5-35b-a3b-claude-4.6-opus-4bit (thinking)

nvidia-nemotron-3-nano-30b-a3b (thinking)

gemma-4-26b-a4b-it-gguf

Пояснения:

• (thinking) в названии модели обозначает, что часть токенов, которые генерирует модель, уходит на подготовку ответа, поэтому ее реальная скорость генерации ответа на 30-50% ниже и общий ответ получается дольше
• время review 0 - модель сразу начинала генерировать исправленный код, без предварительного анализа. Поэтому фактического ревью не проводилось
• время 587+ секунд на 3 этапе у Qwen3.5 9B указано, так как модель запуталась и не смогла исправить код и начала бесконечно генерировать тесты

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

облачная модель

время 1 этапа (мин:сек)

оценка после 1 этапа

время review (мин:сек)

время 2 этапа(мин:сек)

оценка после 2 этапа

время 3 этапа (мин:сек)

оценка после 3 этапа

суммарное время работы (мин:сек)

Qwen 3.6 plus (thinking) cloud chat

Qwen 3.6 plus (fast) cloud chat

Qwen 3 coder cloud chat

DeepSeek (thinking) cloud chat

ChatGPT 5.3

Анализ результатов

• скорость работы в режиме чата локальных моделей сравнима со скоростью облачных, однако локальные модели в общем дают худший результат (но не всегда) за то же время
• плотные модели Qwen3.5-27B-4bit и Qwen3.5-9B-4bit очень тяжелыми оказались для данного замера, было заметно, как кулеры начинали шуметь и компьютер начинал греться, хотя результаты у них получились лучше, время оказалось намного больше других результатов. На других моделях нагрузка не чувствовалась
• режим thinking помогает и локальным и облачным моделям генерировать лучший результат
• на втором этапе высокие оценки получили только 2 модели Qwen3.5-27B-4bit и Gemma-4-26B-A4B
• Gemma-4-26B-A4B очень хорошо выглядит на фоне других по качеству и скорости
• облачным моделям тоже нужно время на ответ, и иногда оно дольше, чем у локальных моделей, особенно в режиме thinking
• чем больше битность, тем дольше отвечает модель, особого прироста в качестве не было замечено
• GGUF и MLX: разница в скорости на Mac ожидаема, но оказалась не такой огромной

Далее посмотрим, как те же модели справляются в агентском режиме.

Замеры в режиме агента

Проведем этот же эксперимент, но уже с агентами, а не в чате. Все агенты были из коробки, без дополнительных настроек скиллов, саб-агентов и др. В данном эксперименте замеры уже оказались дольше. И получившиеся результаты ниже:

локальная модель

время 1 этапа (мин:сек)

оценка после 1 этапа

время review (мин:сек)

время 2 этапа(мин:сек)

оценка после 2 этапа

время 3 этапа (мин:сек)

оценка после 3 этапа

суммарное время работы (мин:сек)

Qwen3.5-27B-4bit

nvidia-nemotron-3-nano-30b-a3b

qwen3-coder-30b-a3b-instruct-mlx@4bit

qwen3-coder-30b-a3b-instruct-mlx@5bit

qwen3.5-35b-a3b-4bit

qwen3-coder-30b-a3b-instruct-mlx@4bit

qwen3-coder-30b-a3b-instruct-mlx@4bit

gemma-4-26b-a4b

Claude Code

gemma-4-26b-a4b

Пояснения:

• Qwen3.5-27B-4bit и nvidia-nemotron-3-nano-30b-a3b после первого этапа нет изменений. Эксперимент с этими моделями был остановлен из-за слишком долгого выполнения первого этапа
• Claude Code два времени в 1 этапе, так как сначала делалась команда/init, а потом уже выполнялась сама задача
• хотелось сделать замер qwen3-coder-30b-a3b-instruct-mlx@4bit и Claude Code, но на этапе ревью модель постоянно крашилась с ошибкой: Anthropic streaming error: The model has crashed without additional information. (Exit code: null). Возможная причина — нехватка памяти для контекста.
• при замерах MacBook заметно грелся и кулеры гудели, работать было не особо комфортно, температура под нагрузкой держалась около 100 градусов на GPU

И как и в прошлом эксперименте с чатом, попробуем сделать эксперимент с агентом и облачной моделью

облачная модель

время 1 этапа (мин:сек)

оценка после 1 этапа

время review (мин:сек)

время 2 этапа (мин:сек)

оценка после 2 этапа

время 3 этапа (мин:сек)

оценка после 3 этапа

суммарное время работы (мин:сек)

Qwen Code CLI

Qwen3.6 Plus

Qwen Code plugin

Qwen3.6 Plus?

Qwen3.5 Plus

Claude Opus 4.6

• модель для Qwen Code указана как Qwen3.6 Plus, но достоверного подтверждения этому нет, информация взята из самого агента

Анализ результатов

• секунды и минуты в режиме чата стали минутами и десятками минут в режиме агента, заметно, что режим агента со множеством вызовов и большим контекстом тяжелее дается локальным моделям
• во всех замерах с локальными моделями, разве что за исключением Aider, MacBook заметно нагревался и было ощущение, что Mac пытается взлететь. Кулеры практически не останавливаясь шумели.
• Gemma-4 единственная из моделей показала хорошие результаты на 2 этапе
• облачные модели здесь смотрятся заметно лучше по качеству, скорости и комфорту
• при работе агентов нужно много памяти не только на модель, но и на контекст, иногда файл подкачки раздувался до 20 ГБ
• чем проще агент, например Aider, тем быстрее он работает, но тем больше нужно с ним взаимодействовать
• Open Code работает заметно быстрее, поскольку генерирует меньше контекста
• Claude Code и Kilo Code генерируют больше контекста из-за чего модели тяжелее и она дольше работает
• агенты — это не только про написание кода, в половине замеров агенты предлагали скомпилировать java код, а также его запустить. Думаю тут зависит не только от агента, но и от модели. На модели qwen3-coder-30b-a3b-instruct-mlx@4bit редко были предложения скомпилировать, на остальных почти всегда.
• для локальных моделей лучше подходят более простые агенты Open Code и Aider, для Kilo Code и Claude Code кажется нужно заметно больше ресурсов.

Итоги и рекомендации

Общие выводы

С одной стороны, полученные выводы довольно очевидны, с другой — интересны.

Если отвечать на вопрос, можно ли сегодня на компьютере уровня MacBook M4 работать с локальными моделями, однозначного ответа нет. Точнее, он есть, но с уточнениями.

В режиме чата сегодня вполне можно работать с локальными ИИ и получать довольно приемлемые результаты за приемлемую скорость, при этом данные остаются у вас. Стоит выбирать модели с MoE-архитектурой — они хороши по скорости и приемлемы по качеству.

В режиме агентов я бы скорее ответил, что для постоянной работы это не подходит, но для разовых задач — неплохо. Это связано с большой нагрузкой на систему и память. Обычно на рабочей станции кроме модели крутится ещё много всего: IDE, Docker, десяток вкладок в браузере, и ресурсов явно будет не хватать. Также постоянный нагрев и работа кулеров не добавляет комфорта.

Для себя ещё отметил разницу в скорости работы агентов. И что ревью кода разумно делать другой моделью, чем той, которая его писала — так результат получается лучше.

Также есть вера в светлое будущее, так как локальные модели и их работа оптимизируются, появляются такие решения, как TurboQuant, и новые модели.

Рекомендации, которых я бы придерживался, если бы был ограничен только локальными моделями

После работы с локальными моделями у меня сформировались следующие мысли, которыми я бы руководствовался, если бы у меня не было выбора и стояла задача использовать только локальную модель:

• Развернуть модель на отдельном компьютере (например, Mac mini) и поставить его куда-нибудь подальше, где он будет шуметь. Так вам будет комфортнее работать на рабочем компьютере — не будет конфликта ресурсов между моделью, контекстом и вашими программами.
• Выбирать более свежие модели на MoE-архитектурах. Протестируйте несколько, посмотрите, какая лучше справляется с вашими задачами. Например, недавно вышлаQwen3.6
• Для простых задач лучше работать в режиме чата — это быстрее и продуктивнее.
• Если вы всё же решили использовать агентский режим, присмотритесь к более простым агентам, таким как Aider или OpenCode, вместо продвинутых вроде Kilo Code и Claude Code.
• Если думаете о покупке компьютера именно для LLM, лучше посмотреть расчёты скорости (например,VRAM-калькулятор). А если планируете покупать Mac — ориентироваться нареальные замеры.
• Помните, что локальные модели почти всегда будут уступать в качестве большим облачным, вопрос только в том, насколько.

Результаты работы моделей, исходные коды тестов и полные таблицы с замерами можно посмотреть наGitHub.