Бюджет задержки ИИ представляет собой максимально допустимое время от действия пользователя до полезного видимого ответа, распределённое между всеми этапами системы. В него входят интерфейс, сеть, аутентификация, поиск, очередь, работа модели, проверка, хранение и доставка. Функция, которой будут пользоваться, защищает первый полезный отклик, полное завершение, качество ответа и предсказуемое поведение при росте спроса.
Это сначала продуктовое решение и только потом инфраструктурная метрика. Фоновый отчёт может выполняться дольше, чем встроенный помощник. Частичный поток способен показать пользу до полного завершения. Сначала определите пользовательский шаг и принятый результат, затем распределяйте время.
Определите пользовательскую цель задержки
Выберите один сценарий: вопрос в поддержке, подготовку карточки товара или проверку документа. Зафиксируйте действие, запускающее таймер, и событие, создающее ценность. Для потоковой функции измеряйте время до первого полезного фрагмента, ритм последующей выдачи и время до проверенного результата. Индикатор загрузки сообщает о работе, но не является результатом.
По возможности измеряйте на клиенте. Серверная метрика не видит устройство, браузер, мобильную сеть, шлюз и региональное расстояние. Разделяйте распределение по типу запроса, размеру входа и выхода, модели, региону, состоянию кеша и пути ошибки. Стабильное среднее может скрывать группу пользователей с заметно худшим опытом. Сравнивайте измерения до и после каждого изменения на одном наборе сценариев, иначе ускорение лёгких запросов способно замаскировать ухудшение важных операций.
Задайте цель как распределение с окном наблюдения и правилами включения запросов. Рядом держите корректность. Быстрый ответ, не прошедший продуктовую проверку, потратил бюджет без завершения работы.
Разбор стоимости контекста и времени первого ответа в RAG помогает исследовать один участок пути. Бюджет этой статьи шире и начинается в интерфейсе пользователя, а заканчивается принятым результатом.
Распределите время по полному пути запроса
Проследите запрос через интерфейс, edge, приложение, проверки политик, поиск, сбор контекста, очередь модели, генерацию, валидацию, инструменты, запись и доставку. Дайте каждому этапу владельца и ожидаемый диапазон. Оставьте явный резерв на вариативность вместо того, чтобы незаметно отдать весь бюджет модели.
Время очереди заслуживает отдельной строки. Быстрый ускоритель за перегруженным планировщиком создаёт медленную функцию. Отдельно фиксируйте холодный старт, ожидание batching, установку соединения, промах кеша, rate limit и медленный внешний инструмент. Тогда понятно, где нужна оптимизация: в serving, коде, данных, сети или мощности.
Streaming меняет восприятие, но не отменяет завершение. Первый фрагмент должен быть полезным, последующие приходить равномерно, а финальная проверка не должна опровергать уже показанное. Если проверка обязана завершиться заранее, используйте честный прогресс или ограниченный preview.
Практика отказоустойчивых высоконагруженных систем показывает, почему очередь и режим отказа нужно проектировать вместе с вычислениями. Разбор аварийного восстановления серверов помогает задать время возврата, не подменяя пользовательскую цель задержки на практике.
Проверьте хвост и заранее задайте деградацию
Нагрузочный тест должен воспроизводить смесь реальных запросов, а не один идеальный промпт. Включите обычные и длинные входы, инструменты, промахи кеша, параллельных пользователей и задержку зависимостей. Сравните нормальный спрос, ожидаемый рост и короткий пик. Наблюдайте первый полезный ответ, завершение, приёмку качества, очередь, таймауты, повторы и насыщение ресурсов.
Повторы обязаны помещаться в исходный бюджет пользователя. Повтор медленного вызова на нескольких слоях умножает трафик и усугубляет перегрузку. Назначьте одного владельца повторов, ограничьте попытки, применяйте backoff и jitter там, где это уместно, и останавливайтесь, когда оставшегося времени уже недостаточно для полезного результата.
Спроектируйте graceful degradation заранее. Система может использовать меньшую одобренную модель, пропустить необязательное обогащение, вернуть кеш с информацией о свежести, перенести работу в фон или попросить сузить задачу. Для каждого режима нужна своя проверка качества и понятный статус.
Для бюджета задержки важен публичный кейс MYOD.IT с архитектурой Life.ru для масштаба около одного миллиона пользователей. Этот опыт подтверждает важность совместного тестирования очередей, отказов и наблюдаемости, но не задаёт универсальный latency target, throughput или uptime.
Частые вопросы
Это максимально допустимое время от действия пользователя до полезного ответа, распределённое между интерфейсом, сетью, поиском, очередью, моделью, проверкой и доставкой.
Измеряйте первый полезный ответ, ритм streaming, полное завершение, хвост распределения, очередь, таймауты, повторы и долю результатов, прошедших проверку качества.
Стабильное среднее скрывает длинный хвост для части пользователей. Сегментация по типу запроса, региону, размеру входа, кешу и ошибкам показывает реальный опыт.
Используйте заранее проверенный режим: меньшую модель, кеш с датой свежести, сокращённое обогащение, фоновое выполнение или сужение задачи, сохраняя отдельный quality gate.
Если нужно превратить пользовательский путь в измеряемый бюджет задержки и план нагрузочного теста, изучите услуги ИТ-поддержки и DevOps MYOD.IT. Результат должен назвать этапы, владельцев, метрики хвоста, quality gate и режимы деградации.
