Одной из наиболее недооцененных сил при проектировании систем ИИ является задержка при выполнении вычислений. Когда инженеры говорят о производительности модели, они часто сосредотачиваются на точности, полноте данных и производительности обучения.
Но в производственных системах для пользователей огромное значение имеет время. Для них важно, чтобы система отвечала на их запросы достаточно быстро. Потому что даже самая умная система ИИ начинает сильно раздражать, если ответ на запрос пользователя приходит слишком поздно.
Именно поэтому задержка часто определяет архитектуру модели в большей степени, чем общее проектное решение.
Важно понимать, что в реальных системах время ответа напрямую влияет на поведение пользователя.
Типичные пороговые значения с точки зрения восприятия пользователем выглядят следующим образом:
< 100 мс Мгновенное
~300 мс Быстрое реагирование
~1 секунда Заметное
2–5 секунд Разочаровывающее
> 5 секунд Неприемлемое (снижается с каждой новой генерацией)
Это означает, что многие системы ИИ работают с жесткими ограничениями по задержке.
Вот несколько примеров допустимой скорости работы для различных ИИ систем:
Для обнаружения мошенничества или ранжирования рекламы нам потребуются миллисекунды
Рекомендательные системы должны решать задачи менее чем за 100 мс
Разговорные агенты должны справляться менее чем за 2 секунды
Таким образом, архитектуры приложений, использующих ИИ должны проектироваться с учетом этих ограничений, в противном случае мы рискуем столкнуться с слишком низкой производительностью, которая вряд ли устроит пользователей.
Теперь давайте разберемся с тем, почему большие модели увеличивают задержку? Есть несколько причин появления задержек. Прежде всего, большие модели содержат большое количество различных параметров, также у них более высокие вычислительные требования и больший объем передаваемых данных в память. Как следствие, все это приводит к более длинным циклам генерации токенов.
Например, модель LLM, генерирующая текстовые токены по одному, может быстро накапливать задержки, так как каждый токен требует еще одного шага вывода. Это означает, что задержка увеличивается с длиной ответа.
Стек задержек запроса ИИ
Теперь давайте посмотрим из чего состоит типичный запрос ИИ. Обычно, он включает в себя несколько этапов, представленных в примере конвейера.
Запрос пользователя
→ Получение признаков
→ Векторный поиск
→ Вывод модели
→ Постобработка
→ Ответ
При этом, важно понимать, что каждый из этих этапов добавляет задержку и в итоге мы рискуем получить тормозящую систему.
Вот пример разбивки:
Запрос к хранилищу признаков 30 мс
Векторный поиск 50 мс
Вывод LLM 500 мс
Постобработка 20 мс
Итого: 600 мс
И это уже близко к заметной для пользователя задержке. Теперь давайте поговорим о том, почему хранилища признаков становятся узкими местами задержки. Многие команды разработчиков недооценивают время получения признаков.
Хранилища признаков часто требуют:
запросов к базе данных
логики агрегации
объединений между наборами данных
Если конвейеры обработки признаков не оптимизированы, задержка при извлечении признаков может быть доминирующей. Поэтому некоторые команды поддерживают кэши признаков в реальном времени.
Пример концепции:
feature_cache[user_id]
Вместо пересчета признаков для каждого запроса мы можем хранить их в кеше и тем самым тратить меньше времени на извлечение.
Задержка при извлечении в системах RAG
Системы генерации с расширенным извлечением (RAG) вводят новые уровни задержки.
Давайте рассмотрим типичный поток:
Встраивание запроса
Векторный поиск
Извлечение документов
Формирование запроса
Генерация ответа
В таком конвейере только задержка векторного поиска может достигать 50–150 мс, что делает оптимизацию извлечения крайне важной.
Для оптимизации мы можем использовать следующие методы:
приблизительный метод ближайших соседей (ANN)
меньшие размеры встраивания
кэширование при извлечении данных
предварительные вычисления запроса
Также, для снижения задержки можно воспользоваться параллельным выполнением. Тогда, вместо последовательных шагов:
Извлечение признаков → запуск модели → генерация выходных данных
Системы могут выполнять эти шаги параллельно.
Вот пример псевдокода:
features = fetch_features_async() context = retrieve_documents_async() await features await context
Параллелизация значительно снижает воспринимаемую задержку. А потоковая передача ответов улучшает восприятие. Даже когда получение полных ответов занимает больше времени, потоковая передача может улучшить пользовательский опыт. Так, вместо ожидания полного вывода пользователи получают токены по мере их генерации.
Например:
Токен 1 → Токен 2 → Токен 3 → Токен 4
Система по-прежнему требует времени, но взаимодействие ощущается быстрее. Именно поэтому потоковая обработка широко используется в системах разговорного ИИ. Вывод на периферии сети меняет уравнение задержки
Другая стратегия — перемещение моделей ближе к пользователям.
Вместо:
Пользователь → Облачный сервер → Модель
Вывод на периферии сети становится:
Пользователь → Периферийный узел → Модель
Здесь происходит значительное снижение сетевой задержки, так как нам не нужно выгружать все данные в облако. Такой подход особенно важен для мобильных приложений ИИ, систем машинного зрения в реальном времени, робототехники и автономных систем.
Компромисс между задержкой и точностью
Иногда снижение задержки означает использование более простых моделей.
Пример сравнения:
Точность модели Задержка
Большой трансформер 95% 800 мс
Упрощенная модель 92% 80 мс
Во многих системах более быстрая модель обеспечивает лучший пользовательский опыт. Это означает, что производительность системы зависит не только от качества прогнозирования, но также и от качества взаимодействия. Так лучшие системы ИИ должны оптимизировать, как точность и стоимость, так и задержку. Результатом такой оптимизации часто являются гибридные архитектуры, такие как:
Быстрая модель → резервный вариант — мощная модель
Это сохраняет скорость, поддерживая при этом возможности.
Заключение
В завершении статьи отметим, что задержка заставляет соблюдать архитектурную дисциплину. Она выявляет неэффективность и обнажает ненужную сложность системы ИИ. Также она напоминает нам, о том, что системы ИИ в конечном итоге служат взаимодействию с человеком, а не получению красивых бенчмарков.
Когда упираетесь в задержки и компромисс между скоростью, стоимостью и точностью, становится ясно: нужно уметь проектировать ИИ-системы целиком, а не только выбирать модели, чтобы решения работали в продакшене и давали ожидаемый пользовательский опыт.
На курсе «ИИ-архитектор» разбирают, как строить такие системы — от требований и прототипов до промышленной эксплуатации: архитектурные паттерны, RAG, оптимизация инференса, конвейеры MLOps, работа с данными и оценка стоимости. В честь дня рождения Otus по промокоду birthday действует -10%, эта скидка суммируется с другими скидками.
Если хотите понять формат обучения — приходите на демо-урок 16 апреля в 20:00 на тему «Архитектура ИИ-сервисов для High-Load и Low-Latency инференса». Это хороший шанс познакомиться с преподавателем, пообщаться с экспертами и закрыть пробелы в знаниях. Участие бесплатное, нужно записаться.
