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