Инфраструктура Meta* ускорила деплой ML-моделей в 3,6 раза без роста расходов на CPU
Meta* обрабатывает более 20 000 признаков (features) машинного обучения для каждого запроса на ранжирование рекламы в рамках инфраструктуры Facebook† Feature Framework. Система, впервые представленная Meta на конференции AI @ Scale 2020, отвечает за разработку, компиляцию и подачу признаков в продакшен-модели рекламы. Поскольку рабочие ML-системы редко используют сырые данные напрямую, движки подачи признаков обязаны считывать сохраненные сигналы, применять фильтры временных окон, рассчитывать агрегаты и объединять промежуточные переменные перед генерацией прогнозов.
Чтобы удерживать вычислительные затраты на приемлемом уровне, Facebook Feature Framework изначально компилировала все признаки в единый направленный ациклический граф. В этой архитектуре узлы выполняют отдельные операции (чтение данных или агрегацию), а ребра отслеживают зависимости вычислений. Однако этот монолитный граф исполнения одновременно служил единственной единицей развертывания. Это создало структурное бутылочное горлышко: ошибка в описании одного признака блокировала релизы всех остальных команд компании. Перед инженерами встал прикладной вопрос: как ликвидировать задержки релизов без взрывного роста расходов на вычисления.
Проблемы общего монолита
Когда Facebook Feature Framework обрабатывала всего несколько сотен признаков, объединение графов проходило успешно, а релизы оставались стабильными. По мере роста объема признаков свыше 20 000 для различных типов данных потребовались раздельные процедуры валидации. В их число вошли ресурсоемкие проверки моделей для признаков, уже задействованных в продакшене. Поскольку объединенный граф поставлялся строго единым пакетом, каждый новый или измененный признак был вынужден ожидать завершения полного цикла тестирования.
«F3 снижала вычислительные затраты за счет компиляции всех признаков в единый объединенный граф, но этот граф одновременно являлся единицей релиза. В итоге единичный сбой или некорректная конфигурация блокировали весь конвейер доставки».
По данным подразделения Engineering at Meta, любой сбой в одном признаке останавливал развертывание всех остальных невыпущенных компонентов в текущем цикле. Если на деплой отправлялись семь признаков и два из них содержали независимые ошибки, весь граф падал до тех пор, пока инженеры не устраняли обе проблемы в ходе повторных сборок. Ранние попытки изолировать релизы путем независимого развертывания признаков привели к падению аппаратной эффективности: раздельное исполнение исключало повторное использование общих вычислений.
Независимые релизы без дополнительных затрат на вычисления
Для преодоления этого компромисса Meta развернула F3 Lightning — инфраструктурный уровень, надстроенный непосредственно над Facebook Feature Framework. F3 Lightning отделяет процесс развертывания признаков от их выполнения в рантайме, превращая каждый признак в независимо обновляемую конфигурацию. Изоляция начинается на этапе компилятора: каждый признак компилируется отдельно, что позволяет валидировать, выкатывать или откатывать конкретную конфигурацию без влияния на другие пайплайны.
«Ранние прототипы с раздельными релизами увеличивали нагрузку на CPU, поскольку независимые признаки больше не делили между собой общие вычисления. Мы устранили эту проблему с помощью четырех оптимизаций: стабильных идентификаторов вычислений, единого общего плана исполнения, единого буфера памяти для всех признаков и плотного индексного сопоставления для прямого доступа к массивам».
Команда Engineering at Meta сохранила эффективность совместных вычислений при независимых релизах благодаря четырем оптимизациям среды исполнения: стабильным идентификаторам вычислений, единому плану исполнения, общему буферу памяти для всех признаков и плотному индексному маппингу для прямого доступа к массивам. Эта модернизация архитектуры заменила пакетный принцип все или ничего на упорядоченную очередь развертывания.
Под управлением F3 Lightning сопоставимые признаки экстракции попадают в продакшен примерно в 3,6 раза быстрее, чем в предыдущей версии Facebook Feature Framework, сохраняя затраты на вычислительную инфраструктуру на прежнем уровне.
Что не сходится
Где проходит грань между дешевыми вычислениями и скоростью разработки в боевом машинном обучении? Попытка Meta изолировать релизы признаков сразу уперлась в жесткий компромисс: раздельная поставка исключала переиспользование общих шагов и моментально раздувала нагрузку на CPU (чудес не бывает, за изоляцию надо платить железом). Решать эту дилемму инженерам пришлось не закупкой новых серверов, а разделением компиляции и среды исполнения через общий буфер памяти и единый план. Ускорение релизов в 3,6 раза компания получила без единого цента переплаты за вычислительную инфраструктуру.
Источник: Engineering at Meta