Скорость нейросети: почему ИИ-ассистент отвечает медленно

Когда ИИ-ассистент начинает отвечать слишком долго, первое предложение обычно звучит так: «Нужно поставить модель быстрее».

Иногда это действительно помогает. Но часто команда меняет модель, а пользователь почти не замечает разницы. Причина проста: он ждёт не одну нейросеть. Он ждёт, пока система примет сообщение, проверит доступ, найдёт документы, обратится к CRM, вызовет внешние сервисы, сформирует ответ и проведёт финальную проверку.

Скорость нейросети и скорость всего ИИ-приложения — разные показатели.

Поэтому начинать нужно не со смены модели, а с измерения полного маршрута запроса. Только после этого можно понять, что именно тормозит систему и какое изменение даст реальный эффект.

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

Что именно считать скоростью нейросети

Фраза «ассистент отвечает медленно» слишком общая. Для диагностики её нужно разложить на несколько измеримых показателей.

Показатель	Что он показывает	Где искать проблему
Время до первого токена, TTFT	Сколько пользователь ждёт начала ответа	Очередь, поиск, инструменты, фильтры, модель
Полное время ответа	Сколько занимает вся операция	Длина ответа, последовательные вызовы, внешние API
Скорость генерации	Как быстро модель выдаёт текст после начала ответа	Модель, инфраструктура, загрузка
p95	Насколько медленными оказываются худшие 5% запросов	Нагрузка, повторы, нестабильные интеграции
Время инструментов	Сколько занимают поиск, CRM и другие сервисы	Интеграции и внешние зависимости

TTFT — это время от отправки запроса до появления первого фрагмента ответа. Полная задержка заканчивается только тогда, когда операция завершена. Для пользователя важны оба показателя: быстрый первый фрагмент создаёт ощущение реакции, но не компенсирует минутное ожидание результата.

Microsoft рекомендует отдельно измерять TTFT, полную задержку, время очереди, длительность поиска и инструментов, количество токенов, повторы и p95/p99. Это позволяет ответить на главный вопрос: задерживает работу сама модель или система вокруг неё.[1]

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

Поэтому для рабочего процесса полезнее смотреть как минимум медиану и p95 — значение, быстрее которого выполняется 95% запросов.

Где ИИ-система теряет время

Условный корпоративный ассистент может выполнять такую последовательность:

1. Получить сообщение пользователя.
2. Проверить авторизацию и права доступа.
3. Определить, нужен ли поиск по документам.
4. Найти фрагменты в базе знаний.
5. Запросить сведения из CRM или учётной системы.
6. Передать собранный контекст модели.
7. Проверить структуру и безопасность ответа.
8. Отправить результат пользователю.

Модель отвечает только за один участок этого маршрута.

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

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

Причина 1. Ассистент генерирует слишком длинный ответ

Генерация текста происходит последовательно: модель выдаёт токены один за другим. Чем длиннее ответ, тем позже он завершится.

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

Для бизнеса практический вывод проще:

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

Сначала определите, какой объём действительно нужен следующему участнику процесса. Всё остальное увеличивает задержку и стоимость.

Причина 2. Одна задача разбита на лишние вызовы модели

В демонстрации архитектура может выглядеть убедительно:

1. одна модель переписывает вопрос;
2. вторая определяет необходимость поиска;
3. третья классифицирует обращение;
4. четвёртая формирует ответ;
5. пятая проверяет результат.

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

OpenAI рекомендует уменьшать количество последовательных запросов и параллельно выполнять операции, которые не зависят друг от друга.[2]

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

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

А подтверждение успешного сохранения записи в CRM вообще не требует генерации. Здесь достаточно обычного сообщения интерфейса.

Причина 3. В контекст передаётся слишком много данных

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

Так появляется контекст, в котором действительно нужная информация занимает несколько абзацев, а всё остальное передаётся модели «на всякий случай».

Для обычных коротких запросов уменьшение входного текста не всегда даёт такой же эффект, как сокращение ответа. Но при работе с большими документами, изображениями, длинной историей и RAG лишний контекст становится существенным источником задержки.[2]

Рациональнее контролировать:

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

Задача RAG — найти достаточный контекст, а не загрузить в модель всю корпоративную базу знаний.

Причина 4. Медленно работают поиск и внешние системы

В корпоративном ассистенте модель редко работает одна. Ей могут потребоваться:

• векторный или полнотекстовый поиск;
• CRM;
• ERP или учётная система;
• сайт поставщика;
• почта;
• файловое хранилище;
• внутренний API;
• сервис распознавания документа.

Microsoft отдельно выделяет задержку инструментов и поиска как самостоятельную метрику. Медленный внешний API или последовательная цепочка инструментов может занимать значительную часть полного времени ответа.[1]

Для каждого внешнего вызова нужны собственные:

• тайм-аут;
• журнал;
• код результата;
• число попыток;
• ограничение повторов;
• запасной сценарий.

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

Причина 5. Под нагрузкой появляется очередь

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

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

Поэтому нагрузку нужно проверять отдельно:

• в обычный период;
• в часы пик;
• при пакетной загрузке документов;
• при недоступности одного из сервисов;
• при срабатывании повторных попыток.

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

Причина 6. Агент выполняет работу, для которой достаточно правил

Каждый дополнительный шаг агента стоит времени. Модель выбирает инструмент, формирует параметры, получает результат, оценивает его и решает, что делать дальше.

Для открытой задачи это может быть оправданно. Для фиксированного процесса — часто нет.

Проверка формата телефона, выбор отдела по региону, расчёт суммы, поиск записи по идентификатору и сообщение «заявка сохранена» должны выполняться обычным кодом или workflow. Языковая модель здесь добавит задержку, стоимость и неопределённость.

Подход к разделению правил, workflow и ИИ подробнее описан в статье «Автоматизация с помощью ИИ: какие процессы ему поручать, а какие — правилам».

Позиция простая: не нужно ускорять нейросеть там, где нейросеть вообще не нужна.

Как найти реальную причину задержки

1. Определите, какую операцию вы измеряете

Нельзя установить единый норматив для всех ИИ-систем.

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

Сначала зафиксируйте:

• кто ждёт результат;
• какое действие считается завершением;
• можно ли выполнять задачу в фоне;
• какой уровень задержки мешает процессу;
• что происходит при превышении лимита.

2. Разделите запрос на измеряемые этапы

Для одного запроса временная шкала может выглядеть так:

получение запроса
→ авторизация
→ поиск документов
→ обращение к CRM
→ вызов модели
→ проверка ответа
→ отправка пользователю

Каждый этап должен иметь время начала, время завершения и результат.

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

OpenTelemetry развивает общие соглашения для наблюдаемости генеративных ИИ-систем: можно фиксировать модель, длительность вызова, входные и выходные токены, инструменты и результаты операций.[5]

Минимальный набор данных:

• сценарий запроса;
• версия модели;
• время каждого этапа;
• число входных и выходных токенов;
• количество вызванных инструментов;
• повторы и запасные маршруты;
• технический результат;
• итоговая стоимость;
• оценка качества или решение сотрудника.

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

3. Смотрите результаты по сценариям

Не объединяйте в один график короткую классификацию и анализ договора на десятки страниц.

Разделите запросы хотя бы на группы:

• простой ответ без инструментов;
• ответ с поиском документов;
• запрос к CRM;
• несколько инструментов;
• длинный документ;
• ошибка внешнего сервиса;
• передача сотруднику.

Тогда станет видно, какой сценарий создаёт основную задержку.

4. Проверяйте скорость вместе с качеством

Ускорить систему можно очень просто: убрать документы, отключить проверки и попросить модель отвечать одним предложением.

Только рабочим решением это не станет.

Любое изменение нужно прогонять на одном тестовом наборе и сравнивать как минимум по трём направлениям:

• скорость;
• качество результата;
• стоимость успешной операции.

Методика подготовки тестового набора для систем, отвечающих по документам, описана в статье «Тестирование чат-ботов с ИИ: как проверить RAG-систему перед запуском».

В каком порядке ускорять ИИ-ассистента

Уберите ненужную работу

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

Ограничьте длину ответа

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

Сократите последовательные вызовы

Объедините операции, которые рационально выполнить одним запросом. Независимые действия запускайте параллельно, если это не нарушает ограничения доступа и бизнес-логику.

Ограничьте контекст

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

Кэшируйте повторяющиеся части

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

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

Показывайте реальный прогресс

Потоковая передача не всегда уменьшает полное время вычисления, но пользователь раньше видит начало ответа. Для многошагового процесса можно показывать понятные состояния: «Ищу документы», «Получаю данные из CRM», «Проверяю результат».

И OpenAI, и Anthropic рекомендуют streaming как способ улучшить воспринимаемую скорость пользовательского приложения.[2][3]

При этом структурированные данные и критические действия лучше сначала полностью проверить. Частично переданный JSON или преждевременно показанное подтверждение оплаты — плохая плата за ощущение скорости.

Маршрутизируйте запросы между моделями

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

Вместо одной модели «на всё» можно построить маршрут:

• простые и частые запросы — быстрая модель;
• сложные запросы — более мощная;
• критические случаи — модель плюс проверка человека;
• детерминированные действия — без модели.

Но маршрутизация тоже добавляет этап. Её стоит вводить только после измерения и проверки качества.

Когда модель действительно нужно менять

Смена модели оправданна, когда трассировка показывает, что:

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

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

• время до первого токена;
• полное время;
• p50 и p95;
• качество выполнения задачи;
• число ошибок;
• стоимость успешной операции;
• доля запросов, переданных человеку.

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

Что измерять на пилоте

Метрика	Зачем нужна
TTFT p50 и p95	Понять, как быстро начинается ответ
Полное время p50 и p95	Оценить реальный пользовательский сценарий
Время поиска и инструментов	Найти внешние узкие места
Входные и выходные токены	Контролировать контекст и длину ответа
Количество вызовов модели	Найти лишние последовательные шаги
Повторы и fallback	Увидеть скрытые повторные операции
Успешное выполнение задачи	Не ускорить неправильный результат
Стоимость успешной операции	Связать архитектуру с экономикой

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

Главное, чтобы метрика описывала завершённую бизнес-задачу, а не только красивую скорость генерации текста.

Вывод

Если ИИ-ассистент отвечает медленно, не начинайте со смены модели.

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

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

Технически ускорить можно почти любую систему. Вопрос в другом: сохранит ли она после этого качество, безопасность и способность решать нужную задачу.

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

Частые вопросы

Какая скорость ответа нейросети считается нормальной?

Универсального значения нет. Норматив зависит от процесса, длины результата и ожиданий пользователя. Для диалога критично время до первого фрагмента, а для фонового анализа важнее срок выполнения всей задачи. Цель нужно устанавливать отдельно для каждого сценария и проверять по p50 и p95.

Длинный промпт всегда сильно замедляет нейросеть?

Не всегда. Для коротких запросов длина ответа и количество последовательных вызовов могут влиять сильнее. Но при передаче больших документов, длинной истории и множества результатов RAG объём входного контекста становится существенным фактором.

Streaming действительно ускоряет нейросеть?

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

Нужно ли выбирать самую быструю модель?

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

Источники

1. AI App Architecture for Startups — Microsoft Learn, обновлено 15 мая 2026 года.
2. Latency optimization — OpenAI API Documentation, дата обращения: 23 июля 2026 года.
3. Reducing latency — Claude Platform Documentation, дата обращения: 23 июля 2026 года.
4. Prompt caching — Claude Platform Documentation, дата обращения: 23 июля 2026 года.
5. Inside the LLM Call: GenAI Observability with OpenTelemetry — James Newton-King, OpenTelemetry, 14 мая 2026 года.
6. Agent tracing overview — Microsoft Learn, обновлено 28 марта 2026 года.