Поделиться через

Оптимизация сервисных точек для развертывания модели в производственной среде

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

Стратегии оптимизации делятся на три категории:

Когда оптимизировать конечную точку

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

  • Большой объем запросов: приложение отправляет более 50 тысяч запросов в секунду (QPS) в одну конечную точку.
  • Требования к задержке: приложению требуется время отклика под 100 мс
  • Узкие места в масштабировании: конечные точки испытывают очереди или возврат ошибок HTTP 429 во время пиков трафика
  • Оптимизация затрат: вы хотите сократить затраты на обслуживание при сохранении целевых показателей производительности
  • Подготовка к производственной среде: вы готовитесь перейти от разработки к производственным нагрузкам

Оптимизация инфраструктуры

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

Оптимизация маршрутов

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

Преимущества производительности:

Функция Ограничение стандартной конечной точки Ограничение оптимизированной конечной точки маршрута
Запросы в секунду (QPS) на рабочую область 200 50 000+ (обратитесь в Databricks для более высоких лимитов)
Конкуренция клиентов для каждой рабочей области 192-1024 (зависит от региона) Нет явного ограничения (ограничено выделенной параллельностью)
Подготовленная параллельность для конечной точки для каждой обслуживаемой сущности 1,024 1 024 (свяжитесь с Databricks для более высоких лимитов)

Когда следует использовать оптимизацию маршрутов:

  • Рабочие нагрузки, требующие более 200 QPS
  • Приложения с строгими требованиями к задержке (накладные расходы на под 50 мс)
  • Рабочие развертывания, обслуживающие несколько одновременных пользователей

Это важно

Оптимизация маршрутов доступна только для конечных точек обслуживания пользовательских моделей. API-интерфейсы модели Foundation и внешние модели не поддерживают оптимизацию маршрутов. Маркеры OAuth необходимы для проверки подлинности; личные маркеры доступа не поддерживаются.

См. Оптимизация маршрутов для конечных точек обслуживания для инструкций по настройке и Запрос конечных точек обслуживания, оптимизированных по маршруту для получения сведений о запросах.

Выделенная одновременность

Выделенная параллельность определяет количество одновременных запросов, которые может обрабатывать точка доступа. Настройте выделенную конкуренцию на основе ваших ожиданий по QPS и задержке.

Рекомендации по настройке:

  • Минимальный параллелизм: установите достаточно высокий уровень, чтобы обрабатывать базовый трафик без ожидания в очереди
  • Максимальная конкуренция: установите достаточно высокий уровень, чтобы учитывать пики трафика, одновременно контролируя затраты
  • Автомасштабирование: включение автоматического масштабирования для динамической настройки емкости на основе спроса

Вычисление требуемого параллелизма:

Required Concurrency = Target QPS × Average Latency (seconds)

Например, если ваша цель - 100 QPS со средней задержкой 200 мс:

Required Concurrency = 100 × 0.2 = 20

Используйте нагрузочное тестирование для измерения фактической задержки и определения оптимальных параметров параллелизма.

Типы экземпляров

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

Тип экземпляра Лучше всего подходит для Trade-offs
ЦП (малый, средний, большой) Упрощенная модель, простая логика вывода Более низкая стоимость, медленнее для моделей с интенсивным вычислением
GPU (малый, средний, большой) Большие модели, сложные вычисления, обработка изображений и видео Более высокая стоимость, оптимальная производительность для глубокого обучения

Подсказка

Начните с экземпляров ЦП для разработки и тестирования. Переключитесь на экземпляры GPU только если наблюдается высокая задержка инференса или если ваша модель требует специализированных вычислений (например, для операций глубокого обучения).

Оптимизация моделей

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

Размер модели и сложность

Размер и сложность модели: меньшие, менее сложные модели обычно приводят к более быстрому времени вывода и более высокому QPS. Рассмотрите такие методы, как квантизация или обрезка модели, если ваша модель имеет большой размер.

Пакетирование

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

Предварительная обработка и оптимизация после обработки

Выгрузите сложную предварительную обработку и после обработки из конечных точек обслуживания, чтобы снизить нагрузку на инфраструктуру вывода.

Оптимизация на стороне клиента

Оптимизация на стороне клиента улучшает взаимодействие приложений с конечными точками обслуживания.

Пулинг соединений

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

  • Используйте пакет SDK Databricks, который автоматически реализует рекомендации по пулу подключений
  • При использовании кастомных клиентов реализуйте пул соединений самостоятельно.

Стратегии обработки ошибок и повторных попыток

Реализуйте надежную обработку ошибок для корректной обработки временных сбоев, особенно во время автомасштабирования событий или сбоев в сети.

Оптимизация размера полезной нагрузки

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

Измерение и повышение производительности

Отслеживание производительности

Отслеживайте производительность конечной точки с помощью инструментов, предоставляемых службой модели ИИ Для мозаики:

Единица измерения Что он измеряет Цель Действие при превышении
Задержка (P50, P90, P99) Время отклика для запросов Зависимость от приложений (обычно <100–500 мс) Проверка очереди, оптимизации модели или клиента
Пропускная способность (QPS) Количество выполненных запросов в секунду Зависимые от рабочей нагрузки Включение оптимизации маршрута, увеличение выделенной параллельности
Уровень ошибок Процент неудачных запросов <1% Проверка журналов служб, проверка проблем с емкостью
Длина очереди Запросы, ожидающие обработки 0 (без очереди) Увеличение предоставленной параллельности или активация автомасштабирования
Использование ЦП и памяти Загруженность ресурсов <80% Увеличение масштаба типа экземпляра или увеличение параллелизма

См. Мониторинг качества моделей и работоспособности конечных точек для получения детальных указаний и Отслеживание и экспорт метрик работоспособности конечных точек в Prometheus и Datadog для передачи метрик в системы наблюдения.

Нагрузочное тестирование

Нагрузочное тестирование измеряет производительность конечной точки в условиях реального трафика и помогает:

  • Определение наилучших параметров подготовленной параллельности
  • Узкие места производительности
  • Проверка требований к задержке и пропускной способности
  • Общие сведения о связи между параллелизмом клиента и параллелизмом сервера

См раздел Нагрузочное тестирование для конечных точек обслуживания.

Устранение распространенных проблем с производительностью

Queuing

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

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

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

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

Узкие места внешнего API

Модели часто вызывают внешние API для обогащения данных, извлечения признаков или других задач во время вывода. Эти внешние зависимости могут стать узкими местами производительности:

  • Задержка. Измерение времени отклика каждого внешнего вызова API. Высокая задержка в этих вызовах напрямую увеличивает общую задержку обслуживания и уменьшает пропускную способность.
  • Ограничения пропускной способности: внешние API могут накладывать ограничения скорости или ограничения емкости. Превышение этих ограничений может привести к регулированию, ошибкам и снижению производительности.
  • Частота ошибок. Частые ошибки из внешних API могут активировать повторные попытки и увеличить нагрузку на конечную точку обслуживания.
  • Кэширование. Реализуйте кэширование для часто доступных данных из внешних API, чтобы уменьшить количество вызовов и повысить время отклика.

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

Дополнительные ресурсы

  • Last updated on