QoS-aware autoscaling для AI inference становится сложнее, когда нагрузка растёт быстрее, чем центральная инфраструктура. В этой работе показано, как распределить inference между сервером и ресурсами пользователей, не теряя контроль над QoS.
Проблема здесь не в самом inference, а в том, как он масштабируется. Центральная модель обслуживания дороже по мере роста спроса, а в AI inference операционные затраты быстро начинают доминировать над разовой стоимостью обучения. Авторы отдельно подчёркивают и другой ограничитель: облачная инфраструктура масштабируется надёжно, но цена такого масштабирования растёт почти линейно с нагрузкой. Поэтому упор сделан не на простое увеличение server capacity, а на архитектуру, которая может использовать дополнительные ресурсы там, где они уже есть, то есть на пользовательских устройствах.
Предложение строится вокруг collaborative distributed inference. Базовая идея прагматична: dedicated server держит минимально необходимую полосу надёжности и QoS, а volunteered resources у пользователей принимают часть вычислений, когда онлайн-пул растёт. Это компромисс между двумя крайностями. Чисто централизованная схема даёт предсказуемость, но плохо переносит рост спроса. Чисто volunteer computing снижает стоимость, но страдает от гетерогенности и непостоянной доступности. Авторы выбирают промежуточную модель: сервер остаётся якорем системы, а пользовательские ресурсы работают как эластичный внешний буфер.
Чтобы этот буфер можно было анализировать и не превращать архитектуру в набор эвристик, система описана через high-dimensional generative Markov model. Это важный инженерный ход. Модель учитывает пользователей, ресурсы, subtasks, длительности состояний и политики планирования как связанные, но sparse-переменные. Такой подход позволяет не только симулировать поведение системы, но и разбирать, где именно возникает деградация: на этапах download, execution, upload или при нехватке памяти, bandwidth и CPU. Для autoscaling это полезнее, чем статическая оценка capacity, потому что QoS зависит не от одной метрики, а от цепочки состояний.
Реализация разделяет систему на несколько уровней состояния. Есть availability пользователей, их inference requests, allocated resources, readiness subtasks, execution states и total resource consumption. Для каждого класса состояния использованы свои вероятностные модели. Availability и request timing описаны через survival distributions. Resource trajectories моделируются ARMA-моделями. Для completion фаз и resource consumption тоже используются generative models, основанные на измерениях. Это не просто академическая детализация. Она нужна, чтобы scheduler видел не абстрактный “свободный ресурс”, а динамическую систему с инерцией, лагами и ограничениями по памяти.
Отдельно стоит executor policy. Она не планирует работу, а проверяет локальную feasibility и жёстко останавливает перерасход. Если возникает non-storage overflow, активные downloads на узле ставятся на pause. Если не хватает storage, downloads с наибольшим footprint abort’ятся. Если ресурсов всё ещё недостаточно, система начинает последовательно снимать нагрузку с execution стадий. Это строгий, но понятный trade-off: лучше остановить часть работы, чем допустить неконтролируемую деградацию всего узла. Такое разделение на scheduler и executor делает модель ближе к реальной эксплуатации, где policy for placement и policy for enforcement решают разные задачи.
Поверх этого авторы сравнивают три стратегии: centralized, uniform и affinity-based scheduling. Centralized policy отправляет всё на сервер. Uniform policy распределяет subtasks между подходящими online nodes равномерно. Affinity-based policy старается увеличить batching, то есть co-locate одинаковые subtasks для более плотного исполнения. Здесь уже виден классический компромисс между throughput и tail latency. Большие batches могут повысить эффективность, но они же связывают несколько запросов в один отказной контур. Если узел выходит из строя или executor abort’ит batch, цена ошибки растёт.
Результаты показывают именно это. По мере роста числа пользователей distributed scheduling становится всё выгоднее. Uniform policy в экспериментах чаще всего даёт лучший баланс между completed и canceled requests, особенно при больших user populations. Она также обеспечивает более низкий P99 latency на высоких нагрузках. Affinity-based policy иногда выигрывает на batching, но чаще проигрывает по завершению запросов и tail latency, потому что крупные batch’и дольше удерживают ресурсы и сильнее страдают от aborts. Centralized policy остаётся конкурентной на малых масштабах, но упирается в saturation по CPU и memory. Авторы отдельно отмечают, что примерно диапазон 30×–50× server capacity уже достаточно хорошо дополняет volunteered resources, а дальнейшее наращивание центра даёт diminishing returns.
Главный вывод практический. Эта схема не отменяет dedicated infrastructure, но снижает её необходимый объём. Система остаётся QoS-aware, потому что baseline capacity удерживает сервис от провала, а пользовательские устройства берут на себя рост нагрузки. При этом авторы честно фиксируют ограничения: пользователи считаются homogeneous, fairness не моделируется, а production-level security и privacy оставлены на future work. Но как архитектурный разбор это сильная работа. Она показывает, что autoscaling для AI inference можно строить не только вокруг центра, но и вокруг динамического пула внешних ресурсов, если у системы есть модель, способная выдержать такую неоднородность.
Источник информации
arXiv — крупнейший открытый репозиторий препринтов (с 1991 года, под эгидой Корнелла), где исследователи оперативно размещают рабочие версии статей; материалы общедоступны, но не проходят полное рецензирование, поэтому результаты следует считать предварительными и, по возможности, сверять с обновленными версиями или рецензируемыми журналами. arxiv.org