01 · вход
Telegram → Мост
0,39–0,40 с
До первой подтверждённой карточки в двух старых ping. Само сообщение уже было принято локально в момент старта метрики.
Где TBridge тратит время
Фактический разбор двух последних текстовых Ping на версии 0.5.0-dev.13 и план измерений после обновления. Начало замера — сообщение уже принято локальным Мостом; доставка от телефона до Telegram и прочтение ответа не входят.
Обычный ping теперь проверяет полный путь. Текстовое или голосовое
ping → pong проходит очередь Codex, входного и рабочего агентов, begin и report. Только служебная команда /ping остаётся быстрой транспортной проверкой.Что проверяет выбранный путьПолный Codex-путь
Фактическая старая база61,8–81,9 с
Плановый ориентир20–40 с
02 · только голос
Скачивание + ASR
медиана 2,65 с
Исторические 16 голосовых запросов: 0,95–6,34 с. Зависит от длины записи и прогрева.
03 · Codex
Очередь → входной агент
7,55–10,20 с
Ожидание take. Квитанция очереди ещё не означает, что задача открыта и прочитана.
04 · маршрутизация
Входной → рабочий агент
+42,74–58,63 с
Самый большой участок: выбор модели, создание/продолжение задачи и ожидание begin.
05 · работа
Ответ или инструменты
+7,06–8,46 с
Для старого ping это короткий модельный ответ. В реальном поручении время действий может быть намного больше.
06 · выход
Карточка + Telegram
4,45–4,61 с
От готового результата до подтверждения Telegram. Файлы при наличии входят в окончание замера.
Текстовый ping проходит обычные take, выбор модели, создание рабочей задачи, begin и report; только внешние инструменты намеренно не вызываются.
Лестница проверок: от связи до реальной работы
1. Служебный /ping
Мост и исходящий Telegram без Батлера. Это быстрая проверка транспорта, а не поручения.
2. Текстовый ping
Полное короткое поручение: SQLite, очередь Codex, входной агент, модель, рабочая задача, report и карточка.
3. Голосовой ping
Весь текстовый end-to-end путь плюс скачивание аудио, прогрев и настоящее распознавание речи.
4. Поручение с инструментом
Весь путь плюс разрешения, управление ПК/сервисом, проверка результата и выходные файлы.
Оценка ускорения по узлам
| Узел | Сейчас / база | Реалистичная цель | Возможный выигрыш | Что менять |
|---|---|---|---|---|
| Первая карточка | 0,39–0,40 с | < 1 с | 0–0,2 с | Уже близко к полу; не главный приоритет. |
| Голос и ASR | медиана 2,65 с | 1–2 с на тёплом коротком голосе | 0,5–1,5 с | Держать WarmSpeech готовым, отдельно считать холодный старт, не повторять после сбоя. |
Очередь до take | 7,55–10,20 с | 3–6 с | 4–6 с | Стабильное пробуждение входной задачи и измерение квитанции отдельно от фактического приёма. |
Маршрутизация до begin | +42,74–58,63 с | +12–25 с | 25–40 с | Главный кандидат: сократить холодный старт/создание задачи, проверить прямое продолжение и убрать лишние ожидания. |
| Работа над коротким ответом | +7,06–8,46 с | +3–6 с | 2–4 с | Сравнивать одну фиксированную просьбу и одинаковые модель/усилие. Для инструментов цель отдельная. |
| Финальная доставка | 4,45–4,61 с | 1–2,5 с | 2–3,5 с | Одна изменяемая карточка вместо отдельного отчёта; файлы остаются отдельными вложениями. |
Что считать успехом
После установки: сделать минимум 5 служебных /ping, затем по 5 текстовых и голосовых end-to-end ping и по 3 одинаковых поручения с инструментом. Для обычных поручений сравнить speechMs, intakeMs, workerMs, resultReadyMs, deliveryMs и полный resultMs.
Инженерный ориентир, не обещание: текущий end-to-end ping сначала должен остаться около старой базы за вычетом отдельного отчёта. План дальнейшей оптимизации — 20–40 с вместо 61,8–81,9 с; голос добавит примерно 1–6 с. Инструментальные задачи оцениваются только фиксированными сценариями.