Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Федеративное дообучение LLM научились проводить с меньшим обменом данными между устройствами и сервером. В препринте, который ещё не прошёл рецензирование и содержит замеры самих авторов, FLoKD сократил объём связи на 50–65% при сопоставимой перплексии, то есть модель не стала заметно хуже предсказывать следующий токен. Схема подходит проектам с приватными данными и узким исходящим каналом, но требует общего набора примеров.
Вместо параметров клиент отправляет промежуточные активации
При федеративном обучении исходные данные остаются у клиентов. Каждый клиент дообучает локальную модель и передаёт серверу результат, после чего сервер объединяет обновления и возвращает новую общую версию.
LoRA уменьшает этот обмен: клиент меняет не всю модель, а небольшие низкоранговые адаптеры. Однако размер адаптеров всё равно растёт вместе со скрытой размерностью LLM. Для сравнения, полные параметры LLaMA3-8B в половинной точности занимают около 16 ГБ на один раунд связи.
Дистилляция знаний позволяет не отправлять параметры, а передавать выходные оценки модели на общем наборе данных. Для LLM такой вариант тоже дорог: объём зависит от длины последовательности и размера словаря. Если передавать оценки только для части токенов, сервер получает менее полное обучающее указание.
FLoKD использует другой сигнал. Клиент пропускает общие примеры через локальную модель и для выбранных трансформерных блоков сохраняет вектор после понижающей проекции LoRA. Его размер определяется рангом адаптера, а не размером словаря или полной скрытой размерностью блока.
Сервер сопоставляет активации по номерам блоков и усредняет каждый блок только между теми клиентами, которые его прислали. Затем он обучает глобальные адаптеры LoRA так, чтобы направление их активаций приблизилось к агрегированным клиентским активациям. Для сравнения используется косинусное расстояние, которое меньше зависит от различий в масштабе векторов между клиентами.
Канал делят между информативными блоками и полезными примерами
Передача активаций всех блоков на всём общем наборе данных снова сделала бы обмен дорогим. FLoKD поэтому сокращает сигнал сразу по двум направлениям: выбирает блоки и отбирает примеры.
Метод оценивает вклад каждого трансформерного блока по его промежуточным активациям. Клиент отправляет блоки с наивысшей оценкой, а блоки с небольшим вкладом пропускает. В экспериментах такой отбор давал меньшую перплексию, чем случайный выбор или передача блоков с самыми низкими оценками. Добавление новых блоков после умеренного количества уже не улучшало результат: лишние представления занимали канал, но не приносили соразмерного объёма знаний.
Для примеров предложены две стратегии. Первая сравнивает распределение токенов в общем наборе с локальными данными и один раз отбрасывает плохо согласованные тексты. Вторая оставляет примеры, на которых модель сильнее ошибается: они дают более содержательный сигнал для обучения, но оценку ошибки приходится обновлять по мере изменения модели.
При жёстком лимите выгоднее отправить меньше блоков, но охватить больше подходящих примеров. Когда канал расширяется, часть бюджета можно отдать дополнительным блокам. Это важнее фиксированного правила вроде передачи одинаковой доли блоков и данных при любом доступном объёме связи.
Когда FLoKD меняет архитектурный план
В режиме без лимита на канал FLoKD завершил обучение с перплексией около 25. Ближайший вариант FedPET остановился примерно на 27, а FedMKT и FedSA — около 38. Для достижения одинаковой целевой перплексии FLoKD требовал более чем на 50% меньше переданных данных, чем FedPET.
Работу проверяли на генеративном языковом моделировании с WikiText-103, PTB и DailyDialog. Клиенты получали неоднородные локальные данные, но использовали одну архитектуру, общий замороженный каркас модели и доступный всем набор текстов. Сравнение охватывало передачу параметров LoRA, их сокращённой части и выходных оценок модели.
Архитектурный план стоит пересмотреть, если несколько организаций или устройств совместно дообучают одну LLM, не собирают исходные записи на сервере и ограничены именно исходящим каналом. Вместо проектирования протокола вокруг пересылки адаптеров можно заранее заложить общий набор данных, нумерацию совместимых блоков и серверную дистилляцию активаций.
Схема хуже переносится на систему, где участники используют разные базовые модели: серверу нужно сопоставлять активации одних и тех же блоков. Ей также нужен общий набор примеров, близкий к локальным задачам. Если такой набор нельзя подготовить или централизованное дообучение уже допустимо, дополнительный контур отбора и дистилляции не устраняет основное ограничение проекта.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
