Федеративное обучение в условиях дефицита памяти на Edge-устройствах. Часть 2

Как обучить ML-модели на Edge-устройствах с памятью ^[1] <256 МБ? Я — Александр Лошкарев, инженер-программист, и это вторая часть материала о федеративном обучении ^[2]. В первой ^[3] мы рассматривали, зачем в принципе понадобилось добавлять устройствам интеллект ^[4], о преимуществах 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% вполне возможно. 

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

Аппаратная архитектура напрямую влияет на процесс квантования. На процессорах 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 Science AiConf 2026. ^[6] В 2026 году мы собрали программу вокруг ключевых вызовов AI-команд. Под каждую тему были организованы не только доклады, но и интерактивные форматы, чтобы каждый получил на выходе конкретные идеи и список «что делать завтра».

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