В прототипе FLUX API для генерации изображений может быть таким же простым, как промпт и возвращённое изображение. В продакшене всё выглядит иначе. Задачи выполняются за разное время, спрос поступает всплесками, а повторная попытка может создать вторую тарифицируемую задачу. Надёжная система принимает запрос отдельно от работы по генерации, фиксирует изменения состояния и имеет чёткую реакцию на изменения доступной мощности или задержки.
OdiRouter может находиться в точке контроля доступа к моделям. На его официальном сайте заявлены единый API для доступа к моделям, маршрутизация на основе цены, задержки и доступности, а также поиск моделей, управление API-ключами и журналы запросов. Перед запуском ознакомьтесь с model catalog, pricing и getting-started documentation. Доступность моделей и цены могут меняться, поэтому проверьте маршрут, который собираетесь использовать.
Начните с контракта запроса
Не заставляйте браузер ждать длительного запроса на генерацию без надёжной записи на стороне сервера. Пусть клиент отправит задачу в ваше приложение, после чего верните идентификатор запроса и начальное состояние. Ваш сервис может вызвать выбранный маршрут модели и обновлять запись по мере выполнения работы.
Как минимум сохраняйте:
идентификатор пользователя или рабочего пространства;
ключ идемпотентности, предоставленный клиентом;
маршрут модели, выбранный для запроса;
хеш промпта или другой безопасный отпечаток запроса;
текущий статус и временные метки для каждого перехода; а также
ссылку на результат или категорию ошибки.
Используйте стабильный автомат состояний, например queued, running, succeeded, failed и cancelled. Точные названия менее важны, чем правило: перед запуском новой генерации каждая повторная попытка должна проверять существующую запись. Если для того же ключа идемпотентности уже имеется завершённый результат, верните его. Если задача всё ещё выполняется, верните её статус вместо повторной отправки.
POST /generation-jobs
Idempotency-Key: 6f0d5b34-4a44-4dc1-b0fa-4ad964d5a563
202 Accepted
{
"job_id": "img_01",
"status": "queued"
}Разместите очередь между пользователями и мощностями генерации
Запрос на изображение может быть корректным, даже если его не следует запускать немедленно. Ограниченная очередь позволяет приложению поглощать кратковременный всплеск нагрузки, не превращая каждый входящий запрос в одновременную работу на стороне внешнего сервиса.
Установите уровень параллелизма на основе измеренной доступной мощности, затем оставьте запас для повторных попыток и более медленных задач. Предоставьте пользователям видимое состояние задачи в очереди и возможность получить к ней доступ позже. Когда очередь достигнет своего предела, выберите явное поведение: отклонить новую задачу, поместить ее в очередь с более низким приоритетом или предложить пользователю попробовать позже. Тайм-ауты без уведомления сложно эксплуатировать и сложно объяснять.
Политика организации очередей должна учитывать категории товаров и специфику работы. Для небольшого изображения предпросмотра и пакета больших изображений нужны разные лимиты. Сохраните политику в конфигурации, чтобы оператор мог ее корректировать, не изменяя поведение клиента и не переписывая код запроса.
Оцените объем работы, которую выполняют пользователи.
Пропускная способность — лишь часть общей картины. Система может принимать множество заданий, в то время как пользователи слишком долго ждут результата. Отслеживайте отдельные таймеры для следующего пути:
Метрика | Что она показывает |
|---|---|
Время в очереди | Превышает ли спрос лимит параллелизма. |
Задержка провайдера | Сколько времени занимает генерация после запуска задачи. |
Сквозное время завершения | Сколько пользователь фактически ждёт. |
Доля успешных операций и ошибок | Концентрируются ли сбои по маршруту, типу промпта или временному интервалу. |
Доля отмен | Отказываются ли пользователи от работы до её завершения. |
Стоимость одного завершённого изображения | Искажают ли повторные попытки, сбои или дорогой маршрут удельную стоимость. |
Для задержки используйте перцентили, а не только среднее значение. Среднее значение может выглядеть приемлемо, тогда как небольшая группа пользователей ждёт значительно дольше. Записывайте выбранный маршрут и безопасный идентификатор запроса вместе с каждой метрикой. Это позволит исследовать изменения, не сохраняя конфиденциальный текст промптов в операционных дашбордах.
Определите политику маршрутизации до инцидента
Маршрутизация — это решение как продукта, так и инфраструктуры. Зафиксируйте порядок ограничений для каждого класса задач. Интерактивный предпросмотр может отдавать приоритет задержке завершения, тогда как фоновая пакетная обработка может использовать более медленный маршрут, если его стоимость укладывается в бюджет. Премиальный рабочий процесс может требовать определённого уровня качества и должен явно завершаться ошибкой, если подходящий маршрут недоступен.
OdiRouter описывает маршрутизацию по цене, задержке и доступности. Используйте эти параметры для выражения политики, но оставляйте контроль над обещаниями пользователям за своим приложением. Простая политика может включать:
маршруты, соответствующие требуемым ограничениям качества и функций;
максимально допустимое время выполнения для интерактивной работы;
лимит стоимости для класса задач; и
резервное поведение, когда ни один маршрут не соответствует этим ограничениям.
Не выполняйте незаметную замену маршрута, если она меняет ожидаемый пользователем результат. Если резервный вариант меняет поведение вывода, отобразите этот выбор в продукте или приостановите задачу для проверки.
Контролируйте повторные попытки и расходы
Повторять попытку следует только в тех случаях, когда сбои предположительно носят временный характер, например, кратковременный сбой в сети или ограничение скорости передачи данных от источника. Ограничьте количество повторных попыток, добавьте механизм задержки и используйте одну и ту же запись идемпотентности повторно. Политика повторных попыток без ограничений может превратить сбой в резкий рост расходов.
Считайте тайм-ауты исходами с неопределённым результатом. Перед повторной отправкой проверьте, дошел ли первоначальный запрос до поставщика услуг и не получен ли уже результат. Это еще одна причина вести надежную запись о выполненных заданиях, а не рассматривать каждый HTTP-запрос как весь рабочий процесс целиком.
Установите бюджеты на уровне аккаунта и рабочего пространства до широкого развёртывания. Оповещение о внезапном изменении стоимости обработки одного изображения, частоты ошибок или времени ожидания в очереди. Оповещение должно указывать на решение оператора, например уменьшить параллелизм, отключить второстепенную пакетную очередь или переключить утверждённый маршрут для определённого класса задач.
Выполняйте развёртывание по контролируемому плану нагрузки
Проверьте весь путь на репрезентативных запросах и ожидаемых типах задач, прежде чем открывать его для всех пользователей. Убедитесь, что статус задачи отображается, повторные отправки возвращают правильный результат, отмены высвобождают зарезервированную ёмкость очереди, а завершённые результаты можно получить после обновления страницы.
Увеличивайте нагрузку поэтапно. На каждом этапе отслеживайте время в очереди, перцентили времени выполнения, сбои и стоимость одного завершённого изображения. Ведите операционную заметку с выбранными лимитами, политикой маршрутизации и действием по откату. Она даёт поддержке и инженерной команде одинаковое объяснение при изменении спроса.
Контрольный список для эксплуатации
Отправка клиента имеет ключ идемпотентности и возвращает устойчивый идентификатор задачи.
Приложение различает принятие задачи, работу в очереди, активную генерацию, завершение, сбой и отмену.
Лимиты параллелизма и очереди настроены для класса задач и уровня пользователя.
Панели мониторинга отдельно показывают время в очереди, задержку провайдера, сквозную задержку, ошибки, отмены и стоимость завершённого изображения.
Политика маршрутизации содержит ограничения по качеству, задержке, стоимости и доступности, соответствующие обещаниям продукта.
Количество повторных попыток ограничено, и они сначала сверяются с исходной записью задачи.
Перед развёртыванием были проверены выбранный маршрут OdiRouter, текущая запись в каталоге и текущие цены.
При большем объёме полезными результатами являются наблюдаемый запрос, безопасное поведение повторных попыток и понятный статус для человека, ожидающего результат. Эти практики позволяют команде наращивать ёмкость, не превращая изменчивую работу по генерации медиа в непрозрачный режим сбоев.