Время отклика системы. Всегда ли задержка - это главный показатель?

Нагрузки на обработку данных в эпоху ИИ иногда бывают жесткими по времени - но далеко не все задачи нужно выполнять в реальном времени.

Когда минимальная задержка действительно необходима

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

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

Некоторые вендоры называют задержку "убийцей производительности" в задачах ИИ, а в материалах Amazon Web Services подчеркивается, что низкая задержка для сценариев с генеративными моделями важна не меньше, чем качество входных данных. Тогда в каких случаях минимальная задержка жизненно необходима, а когда это просто приятный бонус?

Два вида задержки: время отклика и свежесть данных

Сначала важно оговорить - это не выбор "да или нет". По словам Эллиота Маркса, сооснователя платформы данных Chalk, руководителям ИТ стоит держать в голове два разных вида задержки.

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

Для руководителя ИТ здесь полезно разделять два вопроса:

как быстро система отвечает на запрос - это время отклика

насколько актуальны данные, на которых построен ответ - это задержка обновления данных

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

Но есть и второй тип задержки, который не менее болезненно влияет на результат.

Задержка в физической безопасности и «не типовых» сценариях распознавания

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

По его словам, значительная часть запросов на пилотные проверки с заказчиками - это не "типовые рецепты". Клиентов интересуют тонкие сценарии распознавания действий: например, понять, что человек присел, скользнул под машину и пытается снять катализатор. И такие запросы повторяются снова и снова - "можно ли сделать вот так?"

Пользовательское восприятие: «быстро» как базовое ожидание

С точки зрения пользователя ситуация похожая. Быстрая реакция интерфейса - будь то большая языковая модель или консоль охранной системы - воспринимается как базовое ожидание. Человек устроен так, что хочет получать ответ в темпе своей работы - и чем больше "визуальной обратной связи" в процессе, тем чувствительнее становится требование к времени отклика.

Из чего складывается задержка в инфраструктуре

Важно не сводить задержку к одному числу. В инфраструктуре она складывается из нескольких уровней, и узкое место в каждом сценарии может быть разным:

• сеть - расстояние, маршрутизация, качество канала, перегрузки, потери

• системы хранения данных - тип накопителей, контроллеры, глубина очередей, размер блоков, задержка записи и чтения, поведение журналов

• вычисления - процессор и память, параллелизм, конкуренция за ресурсы, эффективность кода

• модель и прикладной слой - сложность обработки, количество шагов, необходимость дополнительных запросов к данным и проверок

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

Как выбор площадки влияет на задержку

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

Конкретные значения зависят от того, где изначально хранились и обрабатывались данные. Так, компания Shearwater Geoservices, которая в 2024 году задействовала исландские дата-центры ради снижения операционных затрат, наблюдала рост задержки примерно с 3-4 мс при работе в Великобритании до 20-30 мс при размещении в Исландии. В итоге такой уровень признали приемлемым даже для задач, близких к реальному времени.

Еще один слой - сотрудники "в поле": выездные команды и мобильные специалисты вынуждены учитывать задержки сетей 5G или спутникового доступа. Это нужно соотносить с тем, что считается приемлемым для конкретной задачи, и обычно по задержке такие каналы проигрывают полноценной оптике.

Для ориентира по Великобритании: средняя задержка по Wi-Fi оценивается примерно в 19 мс, по 5G - около 33 мс, по 4G - около 42 мс. В отчетах Ookla по Starlink для Великобритании приводились значения порядка 41 мс.

«Как быстро» vs «насколько актуально»

Дальше возникает важный вопрос - насколько "свежие" данные используются. Можно очень быстро отдать ответ на основе давно собранных сведений - формально это будет низкая задержка по времени отклика, но по сути данные могут быть устаревшими и потому бесполезными. Маркс формулирует это просто: вопрос не только "как быстро", но и "насколько актуально".

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

Где задержка вторична: пакетные и регламентные процессы

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

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

Три практических вопроса, которые задают правильную архитектуру

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

Важен ли p99, а не среднее значение

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

Важна ли свежесть данных

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

Важна ли пропускная способность

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

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

Практики снижения задержки: модели, стек и «низкоуровневый» код

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

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

С точки зрения инженерии Маркс описывает подход, который хорошо знаком по высоконагруженным системам: для радикального сокращения задержки приходится уходить в "низкоуровневый" код. Его команда много пишет на Rust и C++.

При этом Python и SQL используются скорее как язык описания - логика переосмысливается и исполняется там, где это выгодно, в более быстрых системных компонентах. В сочетании с отказом от "обратной выгрузки данных из хранилища в прикладные системы" в пользу вычислений по месту и по запросу это позволяет уменьшать ожидание с 10-15 секунд до десятков миллисекунд.

Архитектура обработки: асинхронность против накопления задержек

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

Если последовательно "объявить граф", запустить детектор, затем распознавание лиц, затем распознавание действий и только потом смотреть результат - возникают две проблемы. Первая - задержка резко растет. Вторая - впустую расходуются вычислительные ресурсы.

Когда низкая задержка — бонус, а не требование

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

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

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

Итог: конкуренция в миллисекундах

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