Мы давно присматривались к локальному ИИ— своей, изолированной LLM без облачных API.
Зачем вообще запускать языковую модель локально, если есть облачные API вроде OpenAI или Anthropic? Как минимум три причины.
Данные клиентов не покидают периметр — это важно, когда работаешь с кодом, который передаешь клиентам, или документами с персональными данными.
Не нужно платить за каждый токен подписки.
Можно тестировать модели без ограничений провайдера.
Но на старте покупать Mac Studio или другое дорогое железо ради экспериментов тоже не хотелось. Поэтому взяли два старых MacBook Air M1 по 16 ГБ, которые лежали без дела, соединили их кабелем Thunderbolt и собрали из них собственный кластер для локального запуска языковых моделей. Инструмент, который это позволяет сделать, называется EXO.
EXO простыми словами
EXO — это открытый проект (exo-explore/exo на GitHub) для запуска локального ИИ на кластере из нескольких компьютеров Apple. EXO объединяет несколько Mac в единый вычислительный кластер для запуска больших языковых моделей. Идея простая: одна модель редко помещается в память одного Mac, а память нескольких Mac, соединённых вместе, — уже вполне рабочий объём.
На каждом компьютере запускается узел EXO. Узлы находят друг друга по сети, договариваются, кто на себя берёт какую часть модели, и вместе обрабатывают запросы. Для пользователя это выглядит как один сервис: открываешь веб-интерфейс или обращаешься к API, а дальше EXO сам решает, какой узел что считает.
Мы собрали кластер из двух M1 по 16 ГБ и получили около 28 ГБ общей памяти. На таком объёме уже можно тестировать модели, которые не влезли бы в один ноутбук.
Что удалось проверить даже на этой скромной конфигурации:
Qwen3.6-35B нормально справляется с OCR — распознаванием текста на изображениях.
Qwen3-Coder-30B неплохо делает код-ревью.
Главный плюс такого подхода — не нужно сразу покупать Mac Studio за пару сотен тысяч рублей, чтобы понять, подходит ли вам локальный ИИ. Старых MacBook или Mac mini на M1/M2 у многих компаний и так хватает — они простаивают после апгрейда парка техники. Мы сейчас присматриваемся к паре Mac Studio или Nvidia DGX Spark — но уже понимая, зачем они нужны и какие модели на них имеет смысл гонять.
Технический блок
Дальше — для тех, кому интересны детали реализации локального ИИ-кластера.
Сеть. Два Mac соединяются напрямую кабелем Thunderbolt (3/4/5, разъём USB-C). macOS автоматически поднимает интерфейс Thunderbolt Bridge. По умолчанию он получает link-local адрес (169.254.x.x), но для стабильной работы кластера лучше задать статику вручную, например 192.168.100.1 и 192.168.100.2 через networksetup -setmanual. Узлы находят друг друга через Zenoh — это протокол для обмена сообщениями между узлами, пришедший на смену более раннему libp2p в EXO.
Требования. EXO работает только на Apple Silicon, потому что использует MLX — фреймворк Apple для машинного обучения на его чипах. Для сборки MLX нужен не просто Command Line Tools, а полный Xcode из App Store плюс отдельно устанавливаемый Metal Toolchain (xcodebuild -downloadComponent MetalToolchain). Без него сборка падает с ошибкой про отсутствующий инструмент metal.
Установка. Дальше стандартный набор для macOS-разработки: Homebrew, uv (пакетный менеджер Python), Node для сборки веб-дашборда, Rust nightly. Сам EXO клонируется из репозитория, дашборд собирается через npm run build, а Python-окружение с MLX разворачивается через uv sync --extra mlx. На 16 ГБ ОЗУ первую сборку лучше ограничить одним потоком (CMAKE_BUILD_PARALLEL_LEVEL=1) — иначе сборка может упасть по памяти. Первая сборка занимает 15–40 минут.
Запуск. На каждом Mac задаётся одна и та же переменная EXO_ZENOH_NAMESPACE — это имя кластера, по которому узлы находят друг друга. После этого просто uv run exo, и на порту 52415 поднимается дашборд и API, совместимый с OpenAI. Если запустить EXO на обоих Mac с одинаковым неймспейсом, в дашборде появятся оба узла, и при выборе модели, которая не помещается в память одного компьютера, EXO автоматически распределит её слои между узлами — это называется pipeline parallelism.
Доступ и безопасность. По умолчанию API слушает 0.0.0.0:52415, то есть доступен любому в локальной сети. Встроенной аутентификации у EXO нет, поэтому выставлять порт наружу без reverse proxy и авторизации не стоит — для этого лучше поставить nginx или Caddy с Basic Auth или Keycloak.
Ограничения!!!. Модели должны поддерживать формат MLX, мы искали-выбирали тут - https://huggingface.co/mlx-community
Если у кого-то тоже есть опыт локальных серверов для ИИ — делитесь, интересно сравнить подходы.
Больше информации в ТГ - @SaaSoftRu
Комментарии (14)
bloomeatt
03.08.2026 07:03Здравствуйте. Из текста не очень понял, может ли быть больше двух маков? У меня на складе как раз целая коробка ноутов валяется, было бы забавно попробовать что нибудь эдакое собрать.
Temoxa Автор
03.08.2026 07:03Направляйте нам коробку макбуков, мы протестируем =)
Да может, в целом EXO описывает что рабочая схема при которой остается эффективна 4 мака в сети.
bloomeatt
03.08.2026 07:03Спасибо, изучу подробнее. На таком количестве уже сетевой слой как будто бы появляется, да и порты на маках сильно не бесконечные.
Temoxa Автор
03.08.2026 07:03тандерболт 4 у м1 поддерживается поэтому лимиты тут 40 Гбит/с в обе стороны (двунаправленно). В целом неплохие, если вы не огромная корпорация
А вот уже например у современных м5 тандерболт 5ой версии и тут уже все приятнее - 80 Гбит/с в обе стороны (двунаправленно).
мы в сетевые ограничения не упираемся
spiteman
03.08.2026 07:03Какие потери из за сети? Я смотрел на подобное ролик примерное 3 месяца назад и там было 4 mac studio. И скажем так 4 компьютера были отнюдь не равны производительности каждого из них умноженного на 4. Вполне вероятно, что за это время реализация таких вычислений потянулась, но так или иначе сеть для этого - бутылочное горлышко.
P.s. вообще 28 гб мало, я вот так мак взял на 64 гб, думал, ну сейчас то что то произойдёт:). Ровным счётом 64 тоже мало, как и 32, что было до этого.
Temoxa Автор
03.08.2026 07:03У нас компания малая, наши потребности закрывает, в сеть мы никак не упираемся.
Да вы правы, 4 мака это не х4 скорость обработки, потому что важны еще также CPU для токенизации ввода, вывода. Т/е 4 в одну сеть это именно для поднятия бОльших моделей, которые на 64Гб вашем ноуте не взлетит, но взлетит если их будет 2)spiteman
03.08.2026 07:03Зачем это делается - понятно, видимо у вас реально малые потребности, что вам хватает и M1 у которого в целом пропускная способность памяти маленькая + объединяете. Мне интересно было для программирования и в целом готов сказать, что 27B модели еще пока не тянут нормально + квантизацию лучше использовать не 4, а 6 или 8 бит.
Понятно, что я даже решал что то на процессоре i5-8350U, но в целом если нет необходимости отказываться от внешних ИИ сетей - как бы не выгодно даже с точки зрения электричества использовать ИИ на своем железе. А если занавес, то да, тут без вариантов.Temoxa Автор
03.08.2026 07:03Для кодинга конечно это мало, для ревью, как описано в статье - Qwen3-Coder-30B
вполне делает неплохо, если прописаны чоткие инструкции что ему проверять и как.
Сейчас мы на стадии покупки Nvidia (https://www.nvidia.com/en-us/products/workstations/dgx-spark/)
Купим сразу 2, в итоге получится уже более серьезный объем и скорости. Потестим - отпишем инфу для всех желающих)
Yuri_BY
03.08.2026 07:03Если у кого-то тоже есть опыт локальных серверов для ИИ — делитесь, интересно сравнить подходы..
Начинал с простейшего выделенного сервера инференса на одной RTX-3060/12GB + i5-4520/32GB DDR3 для llama-server под MX Linux 25.2 XFCE на обычных GGUF моделях. Это самый бюджетный однопользовательский вариант ( --parallel 1 - не забываем!).
Сейчас в том же корпусе с более мощным БП 2х RTX-3060/12GB, MB ASUS P9X79 LE, i7-4820k, 4x 8GB DDR3 + "самописное" приложение для удалённого управления сервером.MODEL=“/srv/models/gemma-4-26B‑A4B‑it‑qat‑q4_0-unquantized‑uncensored‑heretic.i1-Q4_K_M/gemma-4-26B‑A4B‑it‑qat‑q4_0-unquantized‑uncensored‑heretic.i1-Q4_K_M.gguf”HOST=“0.0.0.0”PORT=“8080”THREADS=“8”CTX=“36864”BATCH=“768”NGL=“auto”
И финал лога по задаче:
авг 01 19:35:02 rtx run-llama.sh[197016]: 2.33.827.998 I slot print_timing: id 0 | task 0 | prompt eval time = 3136.40 ms / 5265 tokens ( 0.60 ms per token, 1678.68 tokens per second)авг 01 19:35:02 rtx run-llama.sh[197016]: 2.33.828.003 I slot print_timing: id 0 | task 0 | eval time = 102895.95 ms / 5964 tokens ( 17.25 ms per token, 57.96 tokens per second)
авг 01 19:35:02 rtx run-llama.sh[197016]: 2.33.828.004 I slot print_timing: id 0 | task 0 | total time = 106032.35 ms / 11229 tokens
авг 01 19:35:02 rtx run-llama.sh[197016]: 2.33.828.020 I slot print_timing: id 0 | task 0 | graphs reused = 5940
авг 01 19:35:02 rtx run-llama.sh[197016]: 2.33.828.366 I slot release: id 0 | task 0 | stop processing: n_tokens = 11228, truncated = 0
Temoxa Автор
03.08.2026 07:03круто, а почему скорость выдачи токенов так скачет? в первом 1678 замере, во втором уже всего 57
danilovmy
Вам не кажется что 2 x M1 для ocr задач это, как бы, ну многовато что ли?
Temoxa Автор
Смотря для каких моделей
Мы проверяли от дипсика которые реально весят до 4ГБ - они слабо справляются с исходной задачей, нужно прикладывать доп усилия (обработку, подготовка и т/д) чтобы распознование прошло
По итогу мы остановились на Qwen3.6-35B - она сходу распознает, без всяких доп плясок и не сильно много требует 19ГБ, как раз на 2 M1
danilovmy
Без доп плясок abby Hot folder распознавал уже в 2008 входящие картинки в папке с исправлением ориентациию картинки, искажение линий, с обрезкой, улучшение контраста (там штук 16 инструментов) с определением языка, язые,правда, из предустановленных. Единственное отличие - модель и 2м1 были не нужны.
Сама идея прикольная, эдакий распределеный computing. Только не биткоины майнятся, а токены. Действительно надо попробовать, у меня тоже есть коробка с компами как и в коммент ниже.
Temoxa Автор
круто, пишите по итогу