Зачем нужен дашборд для локального AI-кластера
Два Mac Studio M3 Ultra в стойке, на каждом крутится MLX с несколькими моделями. Чтобы проверить, сколько памяти занято и какие модели загружены, вы открываете SSH-сессию на каждой машине, вводите команды, смотрите вывод. Чтобы выгрузить модель, снова SSH, поиск PID, kill. Это отнимает минуты и раздражает. Единый интерфейс решает проблему: вы видите обе машины на одном экране, нажимаете кнопку и модель выгружается. Готовых решений для связки Mac Studio и oMLX мало, поэтому энтузиасты создают свои. Один из таких проектов - приложение для iOS и macOS, которое мониторит два Mac Studio и управляет моделями удалённо. Автор использовал AI-инструменты Hermes и GLM-5.3-flash, чтобы ускорить разработку. В статье разберём архитектуру, сбор метрик, удалённое управление, интеграцию с Apple-экосистемой и ограничения подхода.
Архитектура решения: как связать Mac Studio и приложение
Система состоит из трёх частей: агенты на каждой машине, API для управления и клиентское приложение. Агент - это лёгкий скрипт на Python, который собирает метрики (использование RAM, список загруженных моделей) и принимает команды (загрузить или выгрузить модель). Он может предоставлять REST API или работать через SSH. Клиентское приложение на iOS/macOS обращается к API агентов и отображает данные. Для простоты можно поднять HTTP-сервер на каждой машине, но тогда нужно позаботиться о безопасности: ограничить доступ по IP, использовать токены или SSH-туннели. Альтернатива - выполнять команды по SSH напрямую из приложения, но это менее удобно для мобильного клиента.
Сбор метрик: что мониторить и как
Ключевые метрики для локального AI-кластера: общий объём RAM, используемая RAM, список процессов, связанных с MLX, и имена загруженных моделей. Можно также отслеживать температуру и нагрузку CPU/GPU, но для быстрого контроля достаточно памяти и списка моделей. На macOS данные можно получить командами ps aux | grep mlx, vm_stat, system_profiler SPHardwareDataType. Python-библиотеки вроде psutil упрощают сбор: psutil.virtual_memory() вернёт использование RAM, а список процессов с именами, содержащими "mlx", покажет активные модели. Агент должен периодически опрашивать систему и отдавать данные в формате JSON.
Удалённое управление моделями: API и безопасность
Агент может предоставлять эндпоинты /load и /unload, принимающие имя модели. Например, POST-запрос на http://mac-studio-1:8000/unload с телом {"model": "llama-3-8b"}. Внутри агент выполнит команду для выгрузки модели из MLX. Безопасность критична: не открывайте порт наружу без защиты. Используйте токены аутентификации, ограничение по IP, VPN или SSH-туннели. Для домашней сети можно ограничиться файрволом и сложным токеном, но при доступе из интернета обязателен VPN.
Использование AI-инструментов для ускорения разработки
Автор проекта применил Hermes и GLM-5.3-flash для генерации кода. LLM хорошо справляются с шаблонными задачами: создание SwiftUI view, сетевого слоя, парсинга JSON. Например, можно попросить: «Создай SwiftUI view для отображения списка моделей с кнопками выгрузки». Модель сгенерирует каркас, который останется доработать. Это экономит часы, но не отменяет необходимости понимать Swift и SwiftUI. LLM могут ошибаться в API, использовать устаревшие методы или генерировать некомпилируемый код. Поэтому код нужно проверять и тестировать.
Практические примеры промптов для генерации кода
Вот несколько шаблонов запросов, которые можно адаптировать:
- «Создай модель данных для ответа API: struct ClusterStatus { var hostname: String; var totalRAM: Int; var usedRAM: Int; var models: [ModelInfo] }»
- «Напиши функцию на Swift для выполнения GET-запроса к http://mac-studio-1:8000/status с использованием async/await и декодированием JSON»
- «Создай SwiftUI view с List, отображающим массив ModelInfo, и кнопкой "Unload" для каждой строки»
Уточняйте требования: указывайте, что нужно использовать async/await, обработку ошибок, конкретные имена полей. Чем точнее промпт, тем меньше правок.
Ограничения и подводные камни AI-генерации
LLM не знают всех деталей вашего окружения. Они могут предложить несуществующие API или устаревшие фреймворки. Для сложной логики, например безопасного хранения ключей, лучше писать код вручную. Также модели могут генерировать код с утечками памяти или неправильной обработкой ошибок. Поэтому базовое знание Swift и SwiftUI обязательно. AI-инструменты ускоряют рутину, но не заменяют разработчика.
Интеграция с экосистемой Apple: виджеты и Siri
Приложение можно расширить виджетами и голосовыми командами. Виджеты показывают использование RAM и список моделей прямо на домашнем экране. Siri позволяет управлять кластером голосом: «Siri, сколько памяти занято на Mac Studio?» или «Siri, выгрузи модель Llama».
Создание виджетов для быстрого мониторинга
WidgetKit позволяет создавать виджеты с таймлайнами обновления. Для мониторинга подойдёт виджет, который каждые 15 минут запрашивает статус у агентов и показывает процент использования RAM и количество загруженных моделей. Настройте TimelineProvider для периодического обновления. Пользователь может разместить виджет на главном экране iPhone или в центре уведомлений Mac.
Голосовое управление через Siri и Shortcuts
Создайте Shortcuts, которые вызывают API приложения, и активируйте их через Siri. Например, shortcut «Выгрузить модель» принимает имя модели и отправляет POST-запрос на /unload. Затем можно сказать: «Siri, выгрузи модель Llama». Для более глубокой интеграции используйте App Intents, чтобы команды были доступны без настройки shortcuts. Это удобно, когда руки заняты или вы далеко от компьютера.
Альтернативы и готовые решения
Существуют готовые панели мониторинга, например Grafana с агентами, или специализированные инструменты для ML-кластеров. Но для домашнего использования они избыточны: требуют настройки сервера, баз данных и часто не заточены под MLX. Можно использовать SSH-клиенты с виджетами, но они не дают специализированного интерфейса. Собственное приложение даёт гибкость и интеграцию с Apple-экосистемой, но требует времени на разработку. Если вам нужно только изредка проверять статус, хватит SSH и пары скриптов. Для регулярного использования дашборд удобнее.
Пошаговый план: от идеи до работающего приложения
- Настройте агенты на Mac Studio: напишите Python-скрипт, который собирает метрики и предоставляет REST API. Используйте
psutilдля памяти и процессов. Запустите скрипт как службу черезlaunchd. - Создайте проект в Xcode: выберите шаблон iOS App или macOS App, добавьте необходимые capabilities.
- Сгенерируйте базовый код с помощью LLM: модели данных, сетевой слой, простые view.
- Реализуйте сетевой слой и UI: подключитесь к API агентов, обработайте ошибки, отобразите данные в списке.
- Добавьте виджеты и Siri: настройте WidgetKit и Shortcuts/App Intents.
- Протестируйте и обеспечьте безопасность: проверьте работу на локальной сети, настройте аутентификацию, при необходимости VPN.
Каждый шаг можно выполнять итеративно, начиная с минимальной функциональности.
Заключение: стоит ли собирать свой дашборд
Собственный дашборд даёт полный контроль, интеграцию с Apple-экосистемой и возможность кастомизации. Вы видите все машины в одном интерфейсе, управляете моделями с телефона и можете расширять функциональность. Но это требует времени и навыков программирования. AI-инструменты снижают порог входа, но не устраняют необходимость понимать основы. Для простых сценариев хватит SSH и скриптов, но для регулярного использования дашборд удобнее. Если у вас несколько Mac Studio и вы часто переключаете модели, такой проект окупается.