Модель на устройстве и парк площадок: обновлять как прошивку, а не как чат

Red Hat начал разговор об управлении моделями на тысячах устройств, Hugging Face выпустил версию 1.0 библиотеки, с которой приложение на iPhone или Mac работает с локальной моделью, NVIDIA показала, как связать восемь настольных DGX Spark, а n8n собрал на одном таком ящике весь набор моделей для небольшой компании без облачного API. Для владельца бизнеса с несколькими площадками главный вопрос звучит так: кто и как обновит модель на каждой из них.

Что вышло

Red Hat 20 октября опубликовал статью о MLOps для AI на периферии: после того как модель оптимизирована и упакована, остаются вопросы управления. Какая версия где работает и как обновить её без инцидента на всём парке. У меня есть только начало статьи, поэтому ответы Red Hat я не пересказываю.

Hugging Face 20 октября выпустил AnyLanguageModel 1.0, замену фреймворку Apple Foundation Models: меняешь строку импорта, и тот же код сессии работает с системной моделью, с открытыми моделями через llama.cpp, MLX и Core ML или с облачными провайдерами, среди которых OpenAI, Anthropic, Gemini и Ollama. Вызов инструментов и структурированный вывод работают у всех провайдеров. Ключ API задаётся функцией, а не строкой, чтобы приложение могло получать короткоживущие токены со своего сервера. Для старта названы Gemma 4 E2B, около 3,4 ГБ, и LFM2.5 2.6B, около 1,7 ГБ, обе помещаются на iPhone; Qwen3.8 27B занимает около 16 ГБ и требует Mac с 32 ГБ памяти.

NVIDIA 22 октября анонсировала на GTC Berlin возможность связать до восьми узлов DGX Spark для моделей, которым нужны сотни гигабайт памяти. Это анонс, подробностей в нём мало.

n8n 19 октября показал, как на одном DGX Spark со 128 ГБ общей памяти держать все модели для рабочих процессов небольшой компании: чат и извлечение данных на Qwen3.6-35B-A3B, эмбеддинги, реранкер, Whisper для речи, GLM-OCR для документов, генерацию картинок и синтез речи, всё за одним OpenAI-совместимым адресом через LiteLLM с ключами на команду. Автор пишет, что клиника, юридическая фирма или бухгалтер часто не могут отправлять данные клиентов в облачный API, и приводит цифры: 120 токенов в секунду для одного пользователя и 359 суммарно на восемь. Самая полезная для меня часть про дисциплину. Каждая модель скачивается один раз с записью точного коммита в models.lock, контейнеры закрепляются по версии, а у образа перед запуском проверяется версия vLLM внутри. У автора nightly-тег оказался пятимесячной давности с vLLM 0.19, и модель не загрузилась с ошибкой, похожей на битый чекпоинт.

Пример: ферма на двух площадках

Возьмём ферму с двумя площадками и контроллерами на каждой. Допустим, на площадках стоит небольшая модель, которая по фото определяет болезнь растений. На одной площадке её обновили, на второй нет. Месяц обе площадки присылают «всё в порядке», но по разным правилам. Расхождение найдут через месяц, и никто не вспомнит, какая версия где стояла и с какого дня.

Модель на устройстве нужно вести как прошивку: с номером версии, с датой установки на каждом устройстве, с планом отката. Чат в облаке обновляют за вас, модель на вашей площадке обновляете вы.

Как это устроено у меня

С 2023 года я отвечаю за сервер и сеть гидропонной фермы в США. Оборудованием там управляют 25 контроллеров на базе Raspberry Pi на 2 площадках. У сетей площадок серые IP, поэтому я настроил обратные прокси, NAT, firewall и VPN, и получилась одна сеть, в которой сервер на Debian в Google Cloud с MariaDB видит все контроллеры. Данные с контроллеров приходят в базу, команды уходят обратно: полив, насосы.

Система на контроллерах закрытая. REST API у неё не было, только локальные сокеты. Я разобрался, как устроен этот интерфейс, и на его основе настроил интеграцию с сервером; эта связка работает и сейчас. Логику автоматизации и интерфейс делает другая команда, за мной сеть, база, обновления и поддержка. Сам я называю это DevOps.

Эта работа научила меня планировать обновления заранее: обновления и отладку я веду удалённо, через ту же сеть, с одного сервера. Если бы на ферме понадобилась модель на площадке, я бы вёл её тем же путём, что и остальное ПО контроллеров: версия, дата, устройство, путь назад. Железо и стеки из этих новостей я у себя не проверял.

Что я бы сделал

Завёл бы один сервер, который знает, какая версия модели и какого контейнера стоит на каждом устройстве. На ферме данные с контроллеров и так идут на один сервер с MariaDB; запись о версиях я бы держал там же.

Закрепил бы версии файлом, как models.lock у n8n, и запускал бы только по нему. Тег latest на площадке без интернета ничего не значит.

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

Проверил бы путь отката до обновления, а не во время инцидента.

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

Связанные материалы

Зачем системе общий центр, который хранит состояние и координирует обработку, я писал в статье Сервер: данные, доступ и выполнение процесса. Направления: автоматизация теплиц и гидропоники и мониторинг оборудования и уведомления. Сам проект: Гидропонная ферма в США: 25 контроллеров на 2 площадках. Рядом мои обзоры о маршрутизации между своей моделью и API, о наблюдаемости на одном сервере и о zero trust для компании из 30 человек. Раньше я писал, что выпуск модели на устройстве важнее одного быстрого ответа, и про аналитику рядом с промышленным архивом. Если у вас оборудование на нескольких площадках и вы думаете поставить туда модель, расскажите, что там уже стоит и как сейчас обновляется. Обсудить задачу.