Статистика токенов: Статистические показатели с точки зрения затрат и интерпретация графиков
Вы уже подключили клиентов к 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 делится на три сегмента:
- Промежуточное ПО прокси пытается извлечь потребление токенов из ответа (совместимо с
usage/usageMetadata, потоковые запросы также разбираются) - Если одновременно получены
account_email + input_tokens + output_tokens, записывается в локальный SQLite (token_stats.db) - 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: Используйте «тренд потребления по моделям/по учётным записям», чтобы поймать аномальные пики
Почему Графики тренда — самый подходящий вход для поиска «внезапно подорожавших». Вам не нужно сначала знать причину, сначала выделите «какой день/какой час подорожел».
Действие:
- В правом верхнем углу графика переключитесь «По моделям / По учётным записям»
- Наведите мышь (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.tsx | 49-166 |
| UI Token Stats: подсказка «нет данных» ("暂无数据") | src/pages/TokenStats.tsx | 458-507 |
Извлечение потребления токенов: разбор model из запроса, разбор usage/usageMetadata из ответа | src-tauri/src/proxy/middleware/monitor.rs | 32-120 |
Извлечение потребления токенов: разбор поля usage/usageMetadata в потоке и в JSON | src-tauri/src/proxy/middleware/monitor.rs | 122-336 |
| Точка записи Token Stats: при получении учётной записи + токенов запись в SQLite | src-tauri/src/proxy/monitor.rs | 79-136 |
Имя файла БД и структура таблицы: token_stats.db / token_usage / token_stats_hourly | src-tauri/src/modules/token_stats.rs | 58-126 |
Логика записи: record_usage(account_email, model, input, output) | src-tauri/src/modules/token_stats.rs | 128-159 |
| Логика запроса: часы/дни/недели, по учётным записям/по моделям, тренд и итоговый обзор | src-tauri/src/modules/token_stats.rs | 161-555 |
Команды Tauri: get_token_stats_* для фронтенда | src-tauri/src/commands/mod.rs | 791-847 |
| При запуске приложения инициализация БД Token Stats | src-tauri/src/lib.rs | 50-56 |
Страница Settings: получение/открытие каталога данных (для поиска token_stats.db) | src/pages/Settings.tsx | 76-143 |