Задержка TTS API: методы точного измерения сетевой и генеративной latency
Замер TTFB на потоковом TTS-эндпоинте возвращает 50 мс. Первый чанк с PCM-данными приходит через 200 мс после первых байт. Пользователь слышит звук через 250 мс. Наивный TTFB-бенчмарк занижает фактическую задержку в 5 раз.
Анатомия задержки в TTS API: из чего складывается общая latency пайплайна
Это систематическая ошибка, которая возникает при тестировании скорости TTS API без парсинга аудиоконтейнера потока.
Общая latency пайплайна складывается из трёх компонент: сетевого RTT (DNS, TCP, TLS), серверного инференса (генеративная задержка) и буферизации на клиенте. Каждый компонент откусывает из бюджета, заданного диалоговым контекстом.
Целевая пауза между репликами человека и агента — около 200 мс. Норма естественного диалога — 100–300 мс. В каскадном пайплайне (STT + LLM + TTS) на TTS API обычно выделяют 200–400 мс. Одна только стадия синтеза речи упирается в потолок всего диалогового бюджета. При суммарной задержке свыше 500 мс пользователи начинают перебивать агента или сбрасывать звонок.
Ключевая метрика для голосового ИИ-агента — TTFA (Time to First Audio): первый воспроизводимый звуковой сэмпл. Не сетевой TTFB, не время получения HTTP-ответа. Первые байты потока содержат метаданные контейнера или тишину.
Ловушки сетевого TTFB: почему первые байты потока обманывают разработчиков
Пример: сервер отвечает первыми байтами за 50 мс. Это 44 байта заголовка WAV или страницы идентификации Ogg/Opus. Первый чанк с реальными аудиоданными придёт на 200 мс позже. Итоговая задержка до воспроизведения — 250 мс. Наивный TTFB-замер фиксирует 50 мс.
| Параметр замера | Наивный TTFB | TTFA |
|---|---|---|
| Что фиксирует | Первые байты HTTP-ответа | Первый чанк с PCM-данными |
| Учитывает заголовки контейнера | Нет — байты съедаются как аудио | Парсится и отбрасывается |
| Учитывает начальную тишину | Нет | Отсекается до первого ненулевого сэмпла |
| Соответствие слышимому звуку | Нет | Да |
Разрыв между TTFB и TTFA зависит от контейнера. WAV содержит 44 байта заголовка, которые сервер отправляет первыми. MP3 вставляет ID3-тег. Ogg-страницы содержат блок идентификации и комментариев. Плюс некоторые провайдеры генерируют начальные сэмплы тишины, которые физически присутствуют в потоке, но аудио для пользователя не производят.
Замер TTFB без парсинга контейнера даёт результат, который не коррелирует с пользовательским восприятием. При декомпозиции пайплайна эта ошибка маскирует реальное bottleneck-место: разработчик видит «50 мс TTFB — отлично» и не ищет источник оставшихся 200 мс.
Парсинг аудиоконтейнеров и отсечение тишины для точного замера генеративной задержки
Для измерения генеративной задержки нужен тест-харнесс, который парсит поток на уровне байтов. Библиотека-контейнерер (как pydub для WAV или soundfile для Ogg) открывает поток, отсекает заголовок и отдаёт первые PCM-сэмплы.
Алгоритм замера TTFA:
1. Отсечь байты заголовка контейнера: 44 байта для WAV, страницы идентификации и комментариев для Ogg/Opus. Для MP3 — ID3v2-тег, если он присутствует.
2. Отфильтровать начальные сэмплы тишини, если провайдер их генерирует. Порог определяется как первый сэмпл с амплитудой выше установленного уровня (обычно −60 дБFS).
3. Зафиксировать временную метку первого ненулевого сэмпла — это и есть TTFA.
4. Разделить TTFA на сетевое плечо (до прихода первых байт от сервера) и генеративную задержку (от первых байт до первого чанка с PCM). Для чистого замера серверного инференса использовать локальный эндпоинт или считать сетевую составляющую как отдельный компонент.
Если провайдер отдаёт аудио через WebSocket или WebRTC, накладные расходы протокола варьируются от реализации SDK и не поддаются обобщённому учёту. Для сравнительных бенчмарков между провайдерами стоит фиксировать один и тот же транспортный протокол на всех тестируемых API.
Парсинг контейнера — единственная операция, которая превращает TTFB в измеримую TTFA. Без неё числовой результат бенчмарка лишён смысла.
Декомпозиция сетевого плеча: curl-тайминги и влияние географии эндпоинтов
Сетевая задержка в публичном интернете составляет 20–200 мс в зависимости от географии клиента и точки присутствия сервера. Для разложения сетевого плеча на компоненты используется curl с флагом -w:
| Параметр curl | Что измеряет |
|---|---|
%{time_namelookup} | Разрешение DNS |
%{time_connect} | Установка TCP-соединения |
%{time_appconnect} | SSL/TLS рукопожатие |
%{time_starttransfer} | Первый байт ответа (TTFB) |
Разность %{time_starttransfer} − %{time_appconnect} даёт интервал от готовности TLS-туннеля до первого ответа сервера — это примерная нижняя граница генеративной задержки, но верхняя граница до парсинга контейнера.
География эндпоинта — один из самых заметных факторов latency. Внедрение региональных эндпоинтов (multi-region serving) снижает TTFB на 50–200 мс — от 20 до 40 % глобально — за счёт сокращения сетевого плеча до дата-центра. Для мультирегиональных продакшенов геолокация клиента и POP сервера должны фиксироваться в каждом замере. Latency без указания этих двух координат несравнима с latency другого провайдера.
Процентили P50–P99 и коэффициент RTF: стандарты бенчмаркинга под нагрузкой
Два независимых измерения, которые часто путают: процентили latency и скорость генерации относительно длительности аудио.
Процентили вместо средних
Средние (mean) метрики скрадывают всплески из-за холодного старта, очередей и троттлинга под нагрузкой. Стандарт измерений Voice-AI требует фиксации:
- P50 — медиана для типичного пользователя;
- P90 или P95 — типичный худший случай;
- P99 — всплески холодного старта и rate limiting.
Разрыв между P50 и P99 указывает на проблемы масштабирования. Маленький P50 при большом P99 — троттлинг под нагрузкой или неэффективная маршрутизация к GPU.
RTF: скорость генерации
RTF (Real-Time Factor) вычисляется как время генерации, делённое на продолжительность сгенерированного аудио:
RTF = время генерации / длительность звука
RTF < 1.0 — необходимое условие потокового синтеза в реальном времени без заиканий буфера. Легковесные модели, вроде Kokoro на GPU, достигают RTF порядка 0.03: 3 секунды аудио синтезируются за 90 мс. Тяжёлые zero-shot модели клонирования голоса ведут себя иначе — RTF близок к единице или превышает её, что делает их непригодными для диалоговых агентов без серверного ускорения.
| Режим синтеза | Критичная метрика | Применение |
|---|---|---|
| Streaming (потоковый) | TTFA, RTF < 1.0 | Диалоговые агенты, телефония, ассистенты |
| Batch (пакетный) | RTF, общее время обработки | Озвучка файлов, дубляж, подкасты |
Пакетная генерация и потоковый синтез — разные задачи. Замер latency для batch-рендера не показывает производительность в диалоговом контексте. Benchmarks от вендоров на прогретых одиночных запросах в продакшене часто дают задержку в 2–3 раза выше.
Сухой итог
Задержка TTS API измеряется через TTFA, не через TTFB. Точный замер требует парсинга контейнера потока (44 байта WAV-заголовка, Ogg-страницы), отсечения начальной тишины и фиксации первого ненулевого сэмпла. Сетевое плечо разбирается curl-таймингами, география эндпоинта фиксируется обязательно. Метрики берутся в процентилях P50–P99, RTF считается отдельно. Вендорские бенчмарки на прогретых запросах не отражают поведение в телефонном канале. Для сравнения провайдеров нужен единый тест-харнесс с фиксированным транспортом, геолокацией и протоколом парсинга.