AWS добавила учёт расхода в голосовых потоках: 12 минут аудио — 720 единиц

У голосового агента разговор длится двадцать минут, но часть времени клиент молчит, слушает ответ или ищет номер заказа. Что именно попадёт в счёт за модель? AWS добавила в SageMaker AI механизм, который позволяет поставщикам потоковых моделей передавать фактический расход в AWS Marketplace по ходу сессии. Если продукт считает секунды обработанного аудио, 12 минут такого аудио превращаются в 720 оплачиваемых единиц.

Это полезное изменение для команд, которые продают или разворачивают распознавание и синтез речи через Marketplace. Оно позволяет привязать плату за программную часть к потреблению. При этом стоимость инфраструктуры SageMaker остаётся отдельной строкой: включённый endpoint продолжает стоить денег.

Почему одного ответа сервера недостаточно

В обычном API всё относительно просто: отправили запрос, получили результат, сервер указал объём использования в заголовке ответа. К этому моменту работа завершена и расход известен.

В голосовом интерфейсе соединение живёт дольше. Клиент непрерывно отправляет звук и получает расшифровку; сессия может занимать полминуты или полчаса. Заголовок, переданный при установке соединения, не позволяет регулярно сообщать новый расход. А почасовая оплата программной части может включать периоды, когда модель доступна, но ничего не обрабатывает.

AWS решила эту задачу вторым WebSocket-соединением между SageMaker и сервером модели. Первое переносит данные для обработки и результаты, второе — небольшие сообщения для биллинга. Общий идентификатор запроса связывает оба соединения с одним разговором.

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

Как считать расход во время разговора

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

AWS рекомендует сообщать использование постепенно и отправлять последнюю запись сразу после завершения сессии. Так при внезапном обрыве меньше обработанного аудио останется неучтённым. Открытое соединение само по себе ещё не означает оплачиваемое аудио: это определяется правилами конкретного продукта.

У канала есть ограничения: одно сообщение в секунду на соединение, максимум 512 байт и ровно одна запись в каждом текстовом кадре. Несколько накопленных единиц можно передать одной записью. Для защиты от повторов предусмотрен ClientToken: дубликат с тем же токеном в пределах одного соединения отбрасывается.

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

Где можно потерять учёт

Главный выбор для поставщика — поведение при отказе канала биллинга. По умолчанию обработка продолжается, даже если этот канал не открылся или оборвался. Разговор сохраняется, но передача расхода прекращается. Можно включить обязательность канала: тогда его потеря остановит обработку.

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

Перед выпуском AWS рекомендует тест с известным объёмом: передать 12 минут учитываемого аудио, получить в сумме 720 единиц и сверить записи сервера с отчётами продавца и начислениями покупателю. Отдельно проверить обрывы и некорректные сообщения. Практический вывод для покупателя: выяснить определение единицы и посчитать инфраструктуру отдельно. Для поставщика — встроить сверку начислений в подготовку релиза.