Skip to content

Статистика токенов: Статистические показатели с точки зрения затрат и интерпретация графиков

Вы уже подключили клиентов к Antigravity Tools, но «кто на самом деле тратит деньги, что дорого, не стал ли вдруг скачок модели» обычно трудно судить по интуиции. В этом уроке будет рассказано только об одном: чётко объяснить показатели данных Token Stats, и научить быстро находить проблемы затрат с помощью графиков.

Что вы сможете сделать после изучения

  • Понять, откуда берутся данные Token Stats (когда записываются, в каких случаях будут отсутствовать)
  • Переключать окно наблюдения по часам/дням/неделям, чтобы избежать ошибочного суждения из-за «только одного дня»
  • В видах «по моделям/по учётным записям» использовать графики тренда для поиска аномальных пиков
  • Использовать списки Top для фиксации самых дорогих моделей/учётных записей, а затем вернуться к журналам запросов для поиска причины

Ваша текущая проблема

  • Вы чувствуете, что вызовы стали дороже, но не знаете, изменилась ли модель, учётная запись, или внезапно увеличился объём за один день
  • Вы видели X-Mapped-Model, но не уверены, по какому стандарту модели считается статистика
  • В Token Stats иногда 0 или «нет данных», вы не знаете, это отсутствие трафика или отсутствие статистики

Когда использовать этот подход

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

Что такое Token Stats?

Token Stats — это страница локальной статистики потребления Antigravity Tools: после того, как прокси пересылает запрос, он пытается извлечь токены из поля usage/usageMetadata в ответе JSON, и записывает каждый запрос по учётной записи и модели в локальный SQLite (token_stats.db), а затем в UI суммирует и отображает по времени/моделям/учётным записям.

Сначала об одной ловушке

Показатель «модель» в Token Stats берётся из поля model вашего запроса (или из разбора пути /v1beta/models/<model> для Gemini), не равен X-Mapped-Model после маршрутизации.

🎒 Подготовка перед началом

  • Вы уже выполнили один успешный вызов прокси (не останавливаетесь на /healthz для проверки работоспособности)
  • Ответы вашего вышестоящего провайдера содержат поля token, которые можно разобрать

Рекомендуется чтение вместе с другим уроком

Если вы используете маршрутизацию моделей, чтобы сопоставить model с другой физической моделью, сначала посмотрите Маршрутизация моделей: Пользовательские маппинги, приоритеты подстановок и предустановленные стратегии, затем вернитесь к этому уроку, чтобы понять «стандарт статистики» более интуитивно.

Основная идея

Цепочка данных Token Stats делится на три сегмента:

  1. Промежуточное ПО прокси пытается извлечь потребление токенов из ответа (совместимо с usage/usageMetadata, потоковые запросы также разбираются)
  2. Если одновременно получены account_email + input_tokens + output_tokens, записывается в локальный SQLite (token_stats.db)
  3. UI через Tauri invoke(get_token_stats_*) вытягивает агрегированные данные и отображает по часам/дням/неделям

Следуйте за мной

Шаг 1: Сначала подтвердите, что у вас есть «трафик»

Почему Статистика Token Stats записывается от реальных запросов. Если вы только запустили прокси, но ни разу не отправляли запрос модели, страница будет отображать «нет данных».

Действие: используйте метод вызова, который вы уже подтвердили как работающий в Запуск локального обратного прокси и подключение первого клиента, отправьте 1-2 запроса.

Вы должны увидеть: страница Token Stats меняется с «загрузка/нет данных» на графики или списки.

Шаг 2: Выберите правильное окно наблюдения (часы/дни/недели)

Почему Одни и те же данные при разных окнах наблюдения выглядят совершенно по-разному. В UI три окна соответствуют разным диапазонам выборки:

  • Часы: последние 24 часа
  • Дни: последние 7 дней
  • Недели: последние 4 недели (вид тренда будет агрегирован по последним 30 дням)

Вы должны увидеть: после переключения, горизонталь графика меняется (часы отображаются до «часа», дни до «день/месяц», недели до «год-Wнеделя»).

Шаг 3: Сначала посмотрите на итоговый обзор, чтобы определить «масштаб затрат»

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

Обратите внимание на эти элементы:

  • Всего токенов (total_tokens)
  • Токены ввода/вывода (total_input_tokens / total_output_tokens)
  • Количество активных учётных записей (unique_accounts)
  • Количество используемых моделей (UI напрямую использует длину списка «статистика по моделям»)

Вы должны увидеть: если «количество активных учётных записей» внезапно увеличилось, это обычно означает, что в короткое время вы использовали больше учётных записей (например, переключились на стратегию ротации).

Шаг 4: Используйте «тренд потребления по моделям/по учётным записям», чтобы поймать аномальные пики

Почему Графики тренда — самый подходящий вход для поиска «внезапно подорожавших». Вам не нужно сначала знать причину, сначала выделите «какой день/какой час подорожел».

Действие:

  1. В правом верхнем углу графика переключитесь «По моделям / По учётным записям»
  2. Наведите мышь (Tooltip) и обратите внимание на значение Top, сначала на那条 «внезапно вышедшую на первое место»

Вы должны увидеть:

  • По моделям: какая-то модель внезапно поднялась в определённый период
  • По учётным записям: какая-то учётная запись внезапно поднялась в определённый период

Шаг 5: Используйте список Top, чтобы «зафиксировать самый дорогой целевой объект»

Почему График тренда говорит вам «когда аномально», список Top говорит вам «кто самый дорогой». Перекрестив эти два, вы сможете быстро определить область устранения неполадок.

Действие:

  • В представлении «По моделям» посмотрите на таблицу «подробная статистика по моделям: total_tokens / request_count / доля`
  • В представлении «По учётным записям» посмотрите на таблицу «подробная статистика по учётным записям»: total_tokens / request_count

Вы должны увидеть: самые дорогие модели/учётные записи стоят спереди, а request_count может помочь вам различить «разово очень дорого» от «особенно много раз».

Шаг 6 (необязательно): Найдите token_stats.db, чтобы создать резервную копию/сверку

Почему Когда вы подозреваете «отсутствие статистики» или хотите выполнить оффлайн-анализ, напрямую взять файл SQLite — самый надёжный.

Действие: перейдите в область Advanced в Settings и нажмите «Открыть каталог данных», вы найдете token_stats.db в каталоге данных.

Вы должны увидеть: в списке файлов есть token_stats.db (имя файла жёстко задано на стороне бэкенда).

Контрольная точка ✅

  • Вы можете чётко сказать, что статистика Token Stats — это «извлечение из поля usage/usageMetadata в ответе, затем запись в локальный SQLite», а не облачное биллинг
  • Вы можете указать конкретный период времени пика в двух представлениях тренда «по моделям/по учётным записям»
  • Вы можете дать выполнимое заключение по устранению неполадок с помощью списка Top: сначала проверить, какая модель или учётная запись

Напоминания о возможных ошибках

ЯвлениеЧастая причинаЧто вы можете сделать
Token Stats показывает «нет данных»Вы действительно не генерировали запросы модели; или ответ вышестоящего провайдера не содержит разборимых полей токеновСначала отправьте запрос с уже подтверждённым клиентом; затем посмотрите, содержит ли ответ usage/usageMetadata
Статистика «по моделям» выглядит неправильноСтатистика использует model запроса, а не X-Mapped-ModelСчитайте маршрутизацию моделей как «запрос модели → модель маршрутизации»; статистика смотрит на «запрос модели»
Отсутствует статистика по учётным записямТолько при получении X-Account-Email и разборе потребления токенов будет записьПодтвердите, что запрос действительно прошёл через пул учётных записей; затем сравните с журналами запросов/заголовками ответа
После включения Proxy Monitor данные статистики завышеныКогда Proxy Monitor включён, токены каждого запроса будут записаны дваждыЭто известная деталь реализации, не влияет на анализ относительного тренда; если нужно точное значение, временно отключите Monitor и протестируйте снова

Краткое содержание урока

  • Основная ценность Token Stats — это «количественное определение проблем затрат», сначала найти, затем оптимизировать
  • При записи необходимы учётная запись и потребление токенов; при отсутствии модели она будет записана как "unknown" (не блокирует запись)
  • Если вы хотите более точный контроль затрат, следующим шагом обычно вернуться к маршрутизации моделей или управлению квотами

Предварительный просмотр следующего урока

Следующий урок мы решим «скрытые проблемы стабильности» в длинных сессиях: Стабильность длинных сессий: Контекстное сжатие, кеширование подписей и сжатие результатов инструментов.

Вам нужно узнать:

  • Что делают три слоя прогрессивного сжатия контекста
  • Почему «кеширование подписей» может уменьшить ошибки подписи 400
  • Что будет удалено/сохранено при сжатии результатов инструментов

Приложение: Ссылка на исходный код

Нажмите, чтобы развернуть и просмотреть местоположение исходного кода

Дата обновления: 2026-01-23

ФункцияПуть к файлуНомер строки
---------
UI Token Stats: переключение окна наблюдения/представления/получение данныхsrc/pages/TokenStats.tsx49-166
UI Token Stats: подсказка «нет данных» ("暂无数据")src/pages/TokenStats.tsx458-507
Извлечение потребления токенов: разбор model из запроса, разбор usage/usageMetadata из ответаsrc-tauri/src/proxy/middleware/monitor.rs32-120
Извлечение потребления токенов: разбор поля usage/usageMetadata в потоке и в JSONsrc-tauri/src/proxy/middleware/monitor.rs122-336
Точка записи Token Stats: при получении учётной записи + токенов запись в SQLitesrc-tauri/src/proxy/monitor.rs79-136
Имя файла БД и структура таблицы: token_stats.db / token_usage / token_stats_hourlysrc-tauri/src/modules/token_stats.rs58-126
Логика записи: record_usage(account_email, model, input, output)src-tauri/src/modules/token_stats.rs128-159
Логика запроса: часы/дни/недели, по учётным записям/по моделям, тренд и итоговый обзорsrc-tauri/src/modules/token_stats.rs161-555
Команды Tauri: get_token_stats_* для фронтендаsrc-tauri/src/commands/mod.rs791-847
При запуске приложения инициализация БД Token Statssrc-tauri/src/lib.rs50-56
Страница Settings: получение/открытие каталога данных (для поиска token_stats.db)src/pages/Settings.tsx76-143