Потоковый учет токенов в шлюзе AI API: окончательное использование, отмены и частичные ответы

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

Потоковое вещание в стиле Gemini и Vertex

Gemini поддерживает фрагменты потоковой передачи, чтобы уменьшить задержку. В SDK в стиле Vertex потоковая передача может предоставлять как асинхронный поток, так и объект агрегированного ответа. Шлюз должен сохранять этот агрегированный путь, когда он доступен.

conststreamingResult = await model.generateContentStream(request);
for await (const chunk ofstreamingResult.stream) {
  впередЧанк (кусок);
  countDeliveredBytesOrText (кусок);
}
constагрегированный = ожидание потокового результата.ответ;
SettleFromAggregatedUsage(aggregated);

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

Обрабатывать отключения клиентов как первоклассные учетные события

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

Шлюз должен сделать явный выбор политики:

Практическое значение по умолчанию для интерактивной потоковой передачи — отмена восходящего потока при отключении нижестоящего клиента, а затем пометка строки реестра как client_aborted. Если окончательное использование происходит во время отмены, расчет производится на основе этого авторитетного использования. Если нет, отметьте строку оценка или pending_reconciliation, а не притворяйтесь, что она точна.

downstream.on("close", async () => {
  если (!providerCompleted) {
    ledger.markClientAborted(requestId);
    await upstream.abort().catch(() => {
      ledger.emit("upstream_cancel_failed", requestId);
    });
  }
});

Рекомендация: указывайте прозрачные метки выставления счетов, такие как final, provider_reconciled, estimated, waived или pending_reconciliation. Это более оправданно, чем показывать каждый потоковый вызов как сразу точный.

Применение квоты во время трансляции

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

Используйте два механизма вместе:

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

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

События наблюдения, которые выявляют ошибки учета

Ошибки потокового выставления счетов легче отлаживать, если шлюз отправляет целевые события, а не только общие журналы запросов. Добавьте такие события, как:

Факт: Семантические соглашения OpenTelemetry GenAI рекомендуют использовать информацию об использовании, возвращаемую поставщиком, для потоковой передачи ответов, если она доступна, и предостерегают от сообщения показателей использования, если количество токенов невозможно получить эффективно или точно.

Для аналитики использования ИИ это означает, что панели мониторинга должны поддерживать уровни достоверности. Диаграмма, на которой смешаны окончательные, расчетные и сверенные значения без меток, может выглядеть понятной, но вводит в заблуждение отделы финансов и поддержки.

Тестирование соответствия для учета потоковой передачи

Не полагайтесь на ручное тестирование с подсказкой в чате. Каждый адаптер провайдера должен иметь тесты на соответствие для случаев нарушения реестров:

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

Контрольный список практической реализации

Что показать арендаторам

Арендаторам не нужны все внутренние события, но им нужны честные ярлыки. Полезная таблица использования может показать:

Такая конструкция снижает неоднозначность поддержки. Если пользователь увидел только часть ответа, на информационной панели можно будет объяснить, завершил ли поставщик уже работу, отменен ли входной шлюз и является ли плата окончательной или ориентировочной.

Рекомендации и прогнозы

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

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

Практическое заключение

Если ваш шлюз поддерживает потоковую передачу, проведите аудит сегодня по одному пути: принудительно отключите клиента после первых нескольких фрагментов и проверьте строку реестра. Если там написано «успех» с точным количеством токенов, вероятно, ваша аналитика лжет.

Решение заключается в том, чтобы не отказываться от потоковой передачи. Сохраняйте быстроту взаимодействия с пользователем, но сделайте явными состояния учета завершения, отмены, ошибок поставщика, отсутствия окончательного использования и сверки. Это дает продуктовым командам оперативный результат, финансовым командам оправданные затраты, а командам поддержки достаточно доказательств, чтобы объяснить частичные ответы без догадок.

Связанная литература

• разработка реестра счетов для каждого вызова модели
• объединение трассировок, реестров токенов и аналитика безопасного использования
• создание контракта совместимости шлюза, совместимого с OpenAI