Задержка ASR Compare: факты и направления исправления

Проверен сохранённый прогон A и выполнен повтор B на том же PCM, Whisper Turbo, на действующей странице. Код и сервисы в этой проверке не менялись. Это два наблюдения, не benchmark p50/p95.

Источник: latency-live-evidence.json, repeat-live.png. Исходники Front/Core/Ingress/Gateway: база 0b8ed1212c42cb49745af68619bfc0674d1b2e5b плюс локальная правка отображения предыдущего хода. ASR: d6e12511bd3ee26bf4208192607ac70b58e9049a. Наличие файлов не заменяет проверку OCI всего deployed стека.

Разбор A, мс

• Подготовка Silero и сегментация: 477.5. Чистое вычисление VAD для выделенной фразы: 50.9; это не всё время анализа всей записи.
• Допуск и подключение: 822.7 = audio_replay(start) 123.5 + start 126.1 + остаток 573.1 (новое WSS/NATS-соединение, подписка с flush и локальная обвязка; отдельного разделения внутри остатка нет).
• Передача и границы: 903.3 = phrase_start 96.4 + phrase_end 113.7 + остаток 693.2 (публикация PCM и четыре последовательных flush; отдельные flush не измерены).
• Последний ответ получен на 2388.0; показ на 2402.9; полный конец 3021.8. После показа ещё 618.9.
• END 355.2; status 95.1; release 94.8; после release до закрытия около 187.3. Эти интервалы не все относятся к задержке до текста.

Сервер

• Audio Ingress: обработка входных пакетов 0.328 мс, lock wait 0.100 мс, 356352 байта / 45 пакетов.
• Подготовка выбранного диапазона PCM: 13.050 мс.
• Приём batch в Bridge: 1.530 мс.
• Очередь Bridge: 0.234 мс.
• Bridge ↔ GPU: 181.165 мс, в том числе decoder 157.435 мс; остаток 23.730 мс включает транспорт и обвязку, а не только сеть.
• Worker preparation: 0.234 мс. GPU upload: 3 пакета, 103680 байт, 1 логический запрос. Повторного серверного VAD нет, score_filtering=false.

Контроль B

Сегментация переиспользована (событие segmented уже на 0.00 с). Старая страница ошибочно продолжает показывать 477.5 мс VAD. Подготовка 712.7, передача 1101.4, decoder 154.3, Bridge ↔ GPU 186.0, показ 2018.6, завершение 2648.1 мс. Показ быстрее на 384.3 мс (16.0%), но сетевой этап вырос: это наблюдаемая разница, не чистый замер выигрыша от VAD.

Причина и минимальный порядок изменений

Готовый batch проходит жизненный цикл живого аудиопотока: новый audio grant/соединение, start, PCM порциями с PING/PONG, phrase_start, phrase_end, end, status, release, close. Основные расходы возникают до GPU.

1. Убрать избыточные flush перед командами, которые уже подтверждают приём/последовательность. Сохранить отдельный ограничитель реально накопленного PCM; нельзя отправить 30 секунд залпом в двухсекундную очередь.
2. Передавать готовую границу одним подтверждаемым действием, не двумя последовательными RPC. Сохранить владельца, last_seq, координаты, хеш и идемпотентность. Для передачи использовать ограниченные пачки, не ожидание PONG после каждой секунды аудио.
3. Определять границы во время записи Compare, как в плагине; кнопка запускает только ASR. Это убирает повторный проход всей записи после нажатия, не меняя аудио и параметры VAD.
4. Завершение: ответ/событие фактического окончания вместо опроса pending каждые 250 мс; совместить завершающий снимок и освобождение в одном подтверждении. Не освобождать GPU раньше реального конца.
5. Затем оценить повторное использование авторизованного аудиотранспорта между прогонами. Сейчас повторный start на старом client_id запрещён состоянием ends, поэтому просто убрать disconnect нельзя. Нужен явный сброс состояния задания при сохранении ACL и нового допуска на каждое задание; не новый сервис и не безусловное удержание диагностического слота.

Нормализация 13 мс и серверный upload 1.5 мс не приоритет. Точный выигрыш изменений устанавливается одинаковым PCM в повторных cold/warm прогонах; суммировать вложенные интервалы нельзя.

Исходники

• src_front/src/asrCompare/session.ts:59 — новый транспорт на каждый запуск; :148 — VAD после нажатия; :169 — пачки/flush; :185 — две границы; :195 — завершение.
• src_front/src/net/natsClient.ts:150 — flush после SUB; :216 — flushAudio; :229 — close.
• src_shared/batch_capture.py:138 — опрос окончания с паузой 250 мс.
• src_shared/audio_batch.py:39 — одна нормализация, бинарные блоки и один commit RPC.
• src_api_gateway/audio_replay.py:195 — capabilities и reservation.
• src/streaming_asr/batch_bridge.py:111 — бинарная передача на GPU и model_exchange_ms.

Subjects: browser PCM chat.audio..pcm; управляющие chat.audio..cmd.* → Gateway → chat.browser.audio → Ingress; admission chat.agent.audio.control; replay chat.ui..cmd.audio_replay → chat.internal.audio_replay; Ingress → Bridge webrtc.komaroff.asr.stream.; Bridge → GPU to.inference.webrtc.asr.sample.; ответ from.inference.webrtc.asr.sample.result.; ASR result webrtc.komaroff.asr.text. → Core → chat.audio..events.audio. Внешний транспорт браузера WSS /chat-ws.