Планировщик

Резюме

Планировщик отвечает за две связанные задачи:

• Масштабирование: выберите лучшее размещение рабочих/графических процессоров для новых экземпляров модели.
• Уменьшение масштаба: ранжируйте существующие экземпляры модели и удаляйте наименее предпочтительные при уменьшении количества реплик.

В обоих направлениях планировщик работает в два простых этапа:

1. Фильтр: найдите кандидатов, которые действительно смогут запустить модель. Вы можете думать об этом как о составлении списка кандидатов.
2. Оценка: дайте каждому кандидату оценку, а затем выберите лучший для текущей цели.

Планирование масштабирования

1. Базовая фильтрация рабочих

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

Цепочка фильтров работает в следующем порядке:

1. Фильтр кластера Сохраняет только рабочих в целевом кластере модели.
2. Фильтр соответствия графических процессоров Сужает рабочий набор, когда модель явно выбирает графические процессоры.
3. Фильтр соответствия меток Сохраняет только рабочих, метки которых удовлетворяют селекторам меток модели.
4. Фильтр состояния Сохраняет только рабочих в состоянии READY.
5. Фильтр Backend Framework Удаляет рабочие процессы, чьи ускорители или возможности среды выполнения не соответствуют выбранному бэкэнду.
6. Фильтр локального пути Применяется к моделям LOCAL_PATH, когда графические процессоры выбраны явно. Он удаляет рабочие процессы, если настроенный путь к модели не существует.

Только работники, прошедшие этот базовый этап фильтрации, переходят к фильтрации на основе ресурсов.

2. Фильтрация кандидатов на основе ресурсов

Этот шаг также является фильтром. Вместо фильтрации по метаданным или состоянию работника он фильтрует по ресурсам: может ли этот работник или место размещения действительно обеспечить достаточно оперативной/видеопамяти для запуска модели?

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

• Модели GGUF: требования к ресурсам оцениваются с помощью анализатора GGUF.
• Другие типы моделей: требования к ресурсам оцениваются соответствующим сервером, например vLLM, SGLang, MindIE или VoxBox.

Возможности серверной части различаются, поэтому доступные резервные пути также различаются:

• vLLM, SGLang, MindIE: в основном используют размещения на основе графического процессора и не используют здесь резервные пути только с использованием ЦП или частичной разгрузкой.
• GGUF, пользовательские серверные части, VoxBox: Использует парсер GGUF для оценки требований к ресурсам модели. Поддержка разгрузки графического процессора, частичной разгрузки или выполнения процессора.
• Пользовательские серверные части, VoxBox: Поддержка разгрузки графического процессора или выполнения процессора.

Затем кандидаты оцениваются по порядку, и процесс останавливается, как только одна стратегия возвращает работоспособных кандидатов. В целом планировщик пытается:

1. Один рабочий, один графический процессор Одного графического процессора на одного рабочего достаточно, чтобы удовлетворить требования модели.
2. Один рабочий процесс, несколько графических процессоров Несколько графических процессоров в одном рабочем процессе используются вместе, когда одного графического процессора недостаточно.
3. Распределенный вывод между рабочими процессами Графические процессоры нескольких рабочих процессов могут использоваться, когда серверная часть поддерживает распределенное выполнение.
4. Частичная разгрузка или выполнение ЦП Используется только в том случае, если этот тип модели и серверная часть поддерживают эти резервные режимы.

Здесь важны несколько деталей:

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

3. Оценка кандидатов

Как только кандидаты найдены, планировщик оценивает их с помощью цепочки оценок и выбирает кандидата с наивысшим общим баллом.

Текущая оценка масштабирования:

1. Оценщик размещения
2. Счетчик местоположения файла модели

Общий балл кандидата равен сумме баллов всех включённых оценщиков.

Оценщик размещения

Система оценки размещения всегда включена для масштабирования.

• Бинпак

Эта стратегия направлена на «упаковку» как можно большего количества экземпляров модели в наименьшее количество «корзин» (например, рабочих/графических процессоров) для оптимизации использования ресурсов. Цель состоит в том, чтобы свести к минимуму количество используемых контейнеров при максимальной эффективности использования ресурсов, обеспечивая максимально эффективное заполнение каждого контейнера без превышения его вместимости. Экземпляры модели помещаются в корзину с наименьшим оставшимся пространством, чтобы минимизировать оставшуюся емкость в каждой корзине. - Распространение

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

Дополнительное поведение:

• При размещении графических процессоров нагрузка на видеопамять имеет больший вес, чем нагрузка на ОЗУ.
• При размещении только с использованием ЦП учитывается только использование оперативной памяти.

Средство оценки местоположения файла модели

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

Что он делает:

• Ищет рабочие процессы, у которых уже есть готовые файлы основной модели.
• Если настроено спекулятивное декодирование, он также ищет готовые файлы для черновой модели.
• Оценивает каждого кандидата по доле участвующих работников, у которых уже есть эти файлы.
• Придает основной местности модели больший вес, чем местности черновой модели.

4. Окончательный выбор

После оценки планировщик выбирает кандидата с наивысшим общим баллом и назначает экземпляр модели этому месту размещения.

Планирование уменьшения масштаба

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

При уменьшении масштаба используется отдельная цепочка оценок для существующих экземпляров модели:

1. Оценщик состояния
2. Оценщик переноса слоёв на GPU
3. Оценщик размещения

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

Оценщик состояния

Оценщик состояния предпочитает здоровые реплики. Это делает неработоспособные или еще не готовые реплики первыми кандидатами на удаление.

Оценщик переноса слоёв на GPU

Для моделей GGUF, сообщающих total_layers и offload_layers, этот оценщик предпочитает экземпляры, у которых больше слоёв уже перенесено на GPU:

• При переносе всех слоёв на GPU присваивается максимальный балл.
• Частичная разгрузка получает пропорциональную оценку.
• Экземпляры без метаданных уровня разгрузки получают 0 от этого средства оценки.

Оценщик размещения при уменьшении числа реплик

Тот же показатель размещения повторно используется при уменьшении масштаба, но он оценивает существующие места размещения с точки зрения удаления, а не с точки зрения размещения. Размещение по-прежнему отражает политику модели binpack или spread, но оценка интерпретируется как предпочтение сохранения, поэтому более низкие оценки размещения с большей вероятностью будут удалены в первую очередь.