Задержка ответа ассистента

Как устроен расчёт

Ответ собирается в четыре такта, и каждый добавляет секунды.

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

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

Третий такт — обращения наружу. Поиск по векторной базе, запрос в CRM, проверка остатков на складе. В поле выбора зашиты три типовых значения: от десятых долей секунды до двух с небольшим.

Четвёртый такт — сеть и очередь. Фиксированные 0,4 секунды на каждый вызов. Столько уходит на дорогу до провайдера и ожидание свободного слота под нагрузкой.

Сумма четырёх тактов умножается на число вызовов. Цепочка «уточнить вопрос → найти → сформулировать» — это три вызова, а не один.

Что весит больше остального

Длина ответа. Каждая сотня лишних токенов на средней модели стоит примерно две секунды, и никакая оптимизация промпта этого не компенсирует. Короткий формат ответа — самый дешёвый способ ускорения.

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

Класс модели. Разница между компактной и крупной рассуждающей — примерно в пять раз по скорости выдачи. Крупную модель ставят туда, где ошибка дороже секунд: расчёт условий, юридические формулировки, спорные случаи. На типовых вопросах её держат в резерве.

Длина промпта влияет слабее всего. Пять тысяч лишних токенов контекста добавляют около трёх секунд. Контекст режут ради стоимости и точности выдачи, а секунды находят в других местах.

Две границы терпения

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

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

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

Как проверить цифру на своём контуре

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

Замер повторяют на двух длинах промпта: короткой и полной. Разница времени, делённая на разницу токенов, даёт скорость чтения для конкретного провайдера. Полученные числа подставляют вместо коэффициентов расчёта.

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

Когда хватает одного замера

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

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

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