Как обучить ML-модели на Edge-устройствах с памятью менее 256 МБ? В этой статье рассматривается реализация федеративного обучения (FL) на ресурсоограниченных устройствах — точках доступа, где доступна лишь небольшая оперативная память. Рассказываем об экспериментальной платформе, архитектуре, выборе моделей, результатах и практических рекомендациях.

Экспериментальная платформа

Разработка прошла в три этапа: симуляция концепции, тестирование на реальных точках доступа и нагрузочное тестирование. Целевые метрики были строгими: точность выше 90% относительно базовой линии, задержка инференса до 100 мс, потребление памяти — до 256 МБ, сетевой трафик — не более 10 МБ в день на устройство.

Поскольку модель весит 65 МБ, прямая синхронизация создала бы 130 МБ трафика на раунд — это превышает лимит. Чтобы уложиться в 10 МБ, была применена экстремальная спарсификация градиентов (Extreme Sparsification): на сервер отправляется только 1% самых значимых обновлений (top-k), остальные накапливаются локально.

Альтернативно — использование HeteroFL, который формирует урезанные подсети для слабых устройств. Например, уровень E — всего 25 КБ, в то время как полная версия (уровень A) — 5,9 МБ.

Для тестирования использовался Docker-контейнер, эмулирующий точку доступа. В нём работают системные сервисы AP, а радиоинтерфейс и беспроводная среда симулируются программно — это цифровой двойник сети.

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

Реализация и архитектура

Архитектура построена на нескольких фреймворках. Координацией FL управляет Flower — гибкий инструмент, совместимый с разными ML-движками. Цифровые двойники работают в TensorFlow Federated. На самих устройствах для инференса используется LiteRT (ранее TensorFlow Lite) с C++ API. Запуск полноценных сред на устройствах с жёсткими лимитами памяти нецелесообразен.

Сбор метрик выполняется через eBPF. Управляющие команды передаются по NETCONF, телеметрия — через WebSocket. Данные из eBPF фильтруются и валидируются до попадания в модель, чтобы избежать искажений от аномальных значений.

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

Выбор моделей

Модель на точке доступа анализирует статистику и прогнозирует рост трафика для превентивного расширения полосы. Были протестированы четыре архитектуры: ARIMA, TCN (Temporal Convolutional Network), GCN (Graph Convolutional Network) и TimesFM от Google. Базовой стала ARIMA.

Выбор модели зависит от объёма ОЗУ:

• На устройствах с 128 МБ работает только ARIMA и статистические модели.
• На 256 МБ — TCN, но при условии коротких окон, батча ≤2 и квантования в INT8.
• На 512 МБ можно развернуть TCN + локальную GCN с ленивой загрузкой слоёв и матрицей смежности только по соседним узлам.

Тяжёлые модели вроде TimesFM (200 млн параметров) нельзя запускать на самих точках из-за нехватки памяти. Они применимы только в архитектуре Edge-Offloading, где вычисления идут на сервере, а устройство лишь передаёт телеметрию. Для локальной оптимизации выбрана TCN.

Без оптимизаций TCN с тремя слоями требовала 162 МБ только под модель — не считая runtime, данных и активаций. Основная нагрузка на память возникает из-за экспоненциального роста тензоров активаций O(B×L×C), особенно при обработке длинных последовательностей.

Чтобы снизить потребление, временной ряд разбивается на неперекрывающиеся фрагменты — как в TimesFM. Это уменьшает длину контекста и вычислительную сложность.

Применение полной 8-битной квантизации (INT8) даёт строгое сжатие в 4 раза (на 75%) по сравнению с FP32. Это касается не только весов, но и тензоров активаций.

С квантованием и другими оптимизациями модель уменьшена до 65 МБ без потери точности — теперь её можно размещать на точках доступа.

Сравнение подходов к загрузке:

• Статическая загрузка: до 400 МБ — выходит за пределы возможностей средних устройств.
• С квантованием: около 200 МБ.
• С динамической подзагрузкой: пик — 150 МБ, минимум — до 50 МБ в зависимости от этапа.

Динамическая загрузка снижает среднее потребление с 400 МБ до 110 МБ на активные процессы.

Анализ паттернов доступа к памяти (прямой проход, градиенты, обновление в FL) показал почти 60% снижения потребления при оптимизации.

Результаты экспериментов

Сравнение моделей по точности:

• Скользящая средняя: 65–75%.
• TCN: 85–90%.
• GCN и TimesFM: потенциал до 95–100%.

Архитектура процессора влияет на эффективность оптимизаций. На ARM-чипах квантование в INT8 работает с минимальными потерями. На старых MIPS-процессорах — резкое падение точности из-за отсутствия поддержки векторных инструкций.

Для автоматизации настроен базовый MLOps-конвейер: контроллер собирает метрики, при необходимости дообучает модель на сервере и рассылает обновлённые бинарники через NETCONF.

Заключение

Ключевые выводы:

• Федеративное обучение на ресурсоограниченных устройствах возможно, но требует дополнительных оптимизаций.
• Стек Flower + TensorFlow Lite (LiteRT) — зрелый и стабильный выбор.
• Парадигма «память по требованию» с динамической подгрузкой, предзагрузкой и асинхронной обработкой даёт значительный выигрыш в эффективности.
• Цифровой двойник — обязательный этап MLOps при работе с железом. Он позволяет сравнивать ожидаемое и реальное поведение устройств.

Практические рекомендации

Для архитектурных решений:

• Используйте иерархическое FL и адаптивное квантование (INT8 → INT4). Эффективность зависит от архитектуры процессора — на MIPS возможна потеря точности без экономии.
• Реализуйте динамическую подзагрузку слоёв: задержка минимальна, а экономия памяти — максимальна.

Оптимальной комбинацией оказалась связка TCN + FedBN + HeteroFL:

• TCN — эффективна для прогнозирования трафика.
• FedBN — решает проблему разных радиоусловий: параметры нормализации остаются на устройстве, не искажая глобальную модель.
• HeteroFL — адаптирует размер сети под объём ОЗУ, позволяя подключать слабые устройства.

Эта комбинация обеспечивает стабильную работу без перегрузки ресурсов.

Что дальше?

Планируется запуск GCN на физическом оборудовании. Далее — разработка методики тестирования в реальной корпоративной среде. Цель — измерить реальный прирост скорости с учётом фоновых вычислений и синхронизации на точке доступа.

Последний этап — оценка применимости модели TimesFM в архитектуре Edge-Offloading, где основные вычисления выполняются на локальном сервере.

Как обучить ML-модели на Edge-устройствах с памятью <256 МБ? Привет, Хабр! Я — Александр Лошкарев, инженер-программист, и это вторая часть материала о федеративном обучении. Впервоймы рассматривали, зачем в принципе понадобилось добавлять устройствам интеллект, о преимуществах FL, архитектурных подходах и вызовах.

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

Экспериментальная платформа

Разработка и валидация платформы прошли три этапа. Сначала мы проверили концепцию в симуляторе. Затем провели тестирование на нескольких реальных точках доступа в корпоративной сети. Целевые метрики были жесткими: точность прогнозов выше 90% по сравнению с базовой линией, задержка инференса до 100 мс, расход памяти до 256 МБ и сетевой трафик не более 10 МБ в день на устройство. Последнее требование исключает прямую пересылку весов. Наша модель весит 65 МБ, и один раунд синхронизации сгенерировал бы 130 МБ трафика. Чтобы уложиться в 10 МБ, мы применили экстремальную спарсификацию градиентов (Extreme Sparsification). На сервер уходит только 1% самых значимых обновлений (top-k), а остальные накапливаются локально. Альтернативный путь — использование уровней сложности алгоритма HeteroFL. Он формирует для слабых устройств урезанные подсети размером вплоть до 25 КБ (уровень E), тогда как полная версия весит 5.9 МБ (уровень A).

Для нагрузочного тестирования мы использовали эмулятор точки доступа в виде Docker-контейнера. Внутри работают системные сервисы AP, а радиоинтерфейс и беспроводная среда симулируются программно. По сути, это цифровой двойник беспроводной сети.

Оркестратор позволяет объединить такие контейнеры в виртуальную копию всей корпоративной сети.

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

Реализация и архитектура

Архитектура решения базируется на нескольких фреймворках. Координацией федеративного обучения управляет Flower — гибкий инструмент, поддерживающий разные ML-движки. Цифровые двойники работают в TensorFlow Federated. На самих точках доступа для инференса установлен LiteRT (официальная среда Google, ранее TensorFlow Lite) с C++ API. Запускать полноценные среды выполнения на устройствах с жесткими лимитами памяти нерационально. Сбор метрик выполняет eBPF. Инфраструктуру управления мы не меняли.

Управляющие команды передаются по протоколу NETCONF, а телеметрия идет через WebSocket. Данные из eBPF фильтруются и валидируются до попадания в модель, чтобы аномальные значения не исказили прогноз. Оперативной памятью управляет отдельный менеджер, отвечающий за динамическую подгрузку слоев, сборку мусора и политики кэширования.

Выбор моделей

Модель на точке доступа анализирует статистику и предсказывает рост трафика для превентивного расширения полосы. Мы протестировали четыре архитектуры: ARIMA, TCN (Temporal Convolutional Network), GCN (Graph Convolutional Network) и гугловскую TimesFM. Базовым алгоритмом стала ARIMA. Выбор модели напрямую зависит от объема оперативной памяти. На точках со 128 МБ работает только ARIMA и алгоритмы на основе статистических признаков. Устройства с 256 МБ тянут TCN, но при условии использования коротких окон планирования, размера батча не более двух и квантования до INT8. На железе с 512 МБ можно развернуть связку TCN и локальной GCN с ленивой загрузкой слоев. При этом матрица смежности в графе строится только по соседним узлам. Разворачивать тяжелые модели временных рядов вроде TimesFM (даже версии на 200 млн параметров) на самих точках нельзя из-за нехватки ОЗУ. Они применимы только в архитектуре Edge-Offloading, когда вычисления идут на выделенном сервере, а точка доступа просто поставляет телеметрию. Для локальной оптимизации мы выбрали TCN.

Временная сверточная сеть в наших тестах даже с тремя слоями привела к тому, что нам понадобилось без оптимизации 162 МБ только под саму модель, без runtime — на хранение данных, промежуточных результатов, активацию и прочее. Потребление такого объема оперативной памяти для базовой архитектуры обусловлено не размером весовых коэффициентов, а экспоненциальным ростом тензоров промежуточных активаций O(BxLxC) (где B – батч, L – длина последовательности, C – каналы) при обработке длинных последовательностей сырых данных. Для большего снижения потребления памяти активаций, описываемого сложностью, необходимо предварительное разбиение временного ряда на неперекрывающиеся фрагменты. Данный подход, примененный в TimesFM, сокращает длину контекста и вычислительную сложность.

Использование полной целочисленной 8-битной квантизации (INT8) обеспечивает строгое математическое сжатие объема данных ровно в 4 раза (на 75%) относительно 32-битного формата с плавающей запятой (FP32). Применение Full Integer Quantization снижает потребление памяти не только для весов модели, но и для тензоров активаций

С применением 8-битного квантования мы уменьшили все дополнительно на 75%. То есть с применением различных походов мы ужали модель примерно до 65 МБ без существенных снижений точности результата. При этом модель в таком подходе уже дает возможность ее использовать на точках доступа.

Как выглядит статическая и динамическая загрузка:

При статической загрузке, если рассматривать полностью все (модель, runtime, внутренние сервисы), берем за основу, что нам необходимо 400 МБ. За эти пределы мы уже вылетаем — средний класс точек доступа это не выполняет. С квантизацией это около 200 МБ, с динамической подзагрузкой — пиково 150 МБ, а снижение может быть и до 50 МБ в зависимости от того, какой этап считается. Динамическая загрузка приводит к тому, что 400 МБ в среднем может быть снижено до 110 МБ на основные текущие процессы на устройстве, в том числе, в процессах работы.

Анализ доступа к памяти у нас был произведен следующим образом:

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

Результаты экспериментов

Если сравнивать различные модели, получается, что скользящая средняя при оптимизациях максимум может выдать 75%, но ориентироваться стоит на 65-70%. Временные сверточные сети — 85-90%. Если сравнивать потенциал дальнейшего развития графовых сетей, сверточных сетей и моделей Google, то достижение 95% и 100% вполне возможно.

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

Аппаратная архитектура напрямую влияет на процесс квантования. На процессорах ARM перевод весов в формат INT8 проходит с минимальными потерями.

На старых чипах MIPS агрессивное сжатие приводит к резкой деградации точности прогноза из-за отсутствия аппаратной поддержки векторных инструкций. Для автоматизации мы настроили базовый MLOps-конвейер: контроллер собирает метрики, дообучает модель на сервере при необходимости и рассылает обновленные бинарники на точки доступа через NETCONF.

Заключение

Есть несколько главных выводов из этого всего:

1. Практически можно осуществить работу федеративного обучения на различных устройствах, но при дополнительных ограничениях.
2. Flower и TensorFlow C++ (LiteRT) — достаточно зрелый и стабильный стек, который можно использовать.
3. Парадигма «память по требованию» с возможностями предзагрузки, параллельно-асинхронной предподготовки, распараллеливания процессов — это то, что касается системного подхода к разработке программного обеспечения и дает очень ощутимый результат.
4. Цифровой двойник как обязательный этап MLOps для FL при работе с аппаратным обеспечением на данный момент можно считать обязательной частью всего процесса обучения для того, чтобы сравнивать, как представляется работа устройства и как оно работает на самом деле.

Практические рекомендации

В архитектурных решениях используйте иерархическую FL и адаптивное квантование (INT8→INT4). От процессорной архитектуры будет зависеть то, какую точность вы получите. А экономию, возможно, вы не получите вовсе.

Реализуйте dynamic layer loading (динамическую подзагрузку слоев) для экономии памяти. Она создает не такую большую задержку, а экономия по памяти — максимальная.

По итогам тестов оптимальной архитектурой оказалась связка TCN, FedBN и HeteroFL. Модели TCN хорошо подходят для прогнозирования трафика. Алгоритм FedBN решает проблему разных радиоусловий: параметры нормализации остаются на устройстве, поэтому глобальная модель не портится от специфичного локального шума. Метод HeteroFL позволяет подключить к обучению слабое железо, адаптируя размер нейросети под доступный объем оперативной памяти. Комбинация этих трех подходов дает работающую систему без перегрузки аппаратных ресурсов точки доступа.

Что дальше?

Дальнейшая работа по проекту включает запуск графовых сетей (GCN) на физическом оборудовании. Сейчас предстоит разработать методику тестирования в живой корпоративной среде. Нам нужно измерить фактический прирост скорости с учетом того времени, которое процессор точки доступа тратит на фоновые вычисления и синхронизацию. Последним этапом станет оценка применимости тяжелой модели TimesFM для архитектуры Edge-Offloading, где основные расчеты вынесены на локальный сервер.

А пока что рекомендую ознакомиться с материалами прикладной технической конференции по Data ScienceAiConf 2026.В 2026 году мы собрали программу вокруг ключевых вызовов AI-команд. Под каждую тему были организованы не только доклады, но и интерактивные форматы, чтобы каждый получил на выходе конкретные идеи и список «что делать завтра».

Среди основных тем — аргументация технологических решений бизнесу, датасеты (от legacy-свалки до работающей модели), мультиагентные системы, как заставить LLM отвечать точно и по правилам, как правильно ставить задачи для ML и AI, будущее поиска и рекомендаций, RAG от архитектуры до production и экономика AI: как считать и сокращать стоимость железа. Присоединяйтесь!