必须启用Google Cloud原生日志采集以获取Gemini API调用原始审计数据，配置Logs Router接收器写入BigQuery，并通过解析textPayload中的usageMetadata或回退tokenizer统计Token，结合X-Api-Key-ID实现密钥级追踪与隐式膨胀风险识别。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要在生产环境中实时掌握每一次Gemini API调用的完整上下文，包括谁发起的请求、用了哪个模型、输入输出各多少Token、是否成功、耗时多久、IP来自哪里——这些信息必须自动记录、不可篡改、可按任意维度筛选回溯。
启用Google Cloud原生日志采集
这一步是所有审计能力的基础，不开启就无法获取原始日志条目。【必须在API调用发生前完成配置，否则历史调用永远丢失】
登录 Google Cloud Console → 进入目标项目 → 左侧导航栏依次点击 Logging → Logs Router → 创建接收器。
接收器名称填 gemini-audit-sink，目的地选择 BigQuery Dataset，新建一个 dataset（如 gemini_audit_logs），表名设为 access_log；在“包含日志”中输入过滤表达式：resource.type="cloud_run_revision" AND logName="projects/YOUR_PROJECT_ID/logs/run.googleapis.com%2Fstdout" AND textPayload:"generateContent" OR textPayload:"countTokens"。
点击创建后，系统将自动把匹配的日志结构化写入BigQuery表，每条记录自带 timestamp、severity、textPayload 字段。注意：textPayload 是 JSON 字符串，需后续用 JSON_EXTRACT 解析。
从响应体中直接提取Token用量
这是最精准、最低延迟的方式，无需依赖外部日志系统，适用于需要毫秒级用量反馈的计费场景。
方法一：检查响应 body 中的 usageMetadata 字段。正常成功响应中该字段必存在，结构为 {"promptTokenCount":179,"candidatesTokenCount":86,"totalTokenCount":265}。
方法二：若使用流式响应（stream=true），usageMetadata 仅出现在最后一个 data: 块中，且格式为 data: {"usageMetadata":{...}}。必须等 stream 结束才能拿到准确值，中间 chunk 不含此字段。
方法三：当 response.status_code ≠ 200 或 usageMetadata 缺失时，需本地 tokenizer 回退统计——用 tiktoken 加载 cl100k_base 编码器，对 request.body.contents[0].parts[0].text 进行编码计数，再对 response.candidates[0].content.parts[0].text 重复一次。这步不能省，否则失败请求的用量将永久空白。
构建密钥级审计追踪链
团队协作中，必须把每次调用绑定到具体 API Key 才能分摊成本、定位异常、满足等保审计要求。
第一步：在网关层拦截所有出向请求，在 HTTP Header 中注入 X-Api-Key-ID（值为 Taotoken 或 OneAPI 分配的 key_id）或自定义 bearer token 解析出 user_id。
第二步：将该标识与 Gemini 响应中的 request_id、client_ip、model_name、latency_ms 一并写入审计事件表，字段命名统一为 api_key_id、req_id、src_ip、model、duration_ms。
第三步：在 BigQuery 中建立视图，用 JSON_EXTRACT(textPayload, "$.usageMetadata.totalTokenCount") 提取 token 数，并关联 api_key_id 字段。执行如下查询即可获得某密钥昨日总消耗：
SELECT SUM(CAST(JSON_EXTRACT_SCALAR(textPayload, "$.usageMetadata.totalTokenCount") AS INT64)) FROM `gemini_audit_logs.access_log` WHERE DATE(timestamp) = "2026-06-01" AND JSON_EXTRACT_SCALAR(textPayload, "$.api_key_id") = "key_abc123"
注意：Google Cloud 日志默认不记录 client_ip，需确保反向代理（如 Envoy）已正确设置 X-Forwarded-For 并透传至 Cloud Run 容器内，否则 src_ip 将全是内网地址。
识别隐式Token膨胀风险点
图像上传、system_instruction 超长、JSON Schema 校验这三类操作会悄悄增加账单，但日志中不会显式标注“隐式Token”，必须靠模式匹配主动识别。
在 BigQuery 中运行以下查询，可定位高风险调用：
SELECT COUNT(*) c, JSON_EXTRACT_SCALAR(textPayload, "$.contents[0].parts[0].inlineData.mimeType") mime_type
FROM `gemini_audit_logs.access_log`
WHERE DATE(timestamp) = "2026-06-01"
AND JSON_EXTRACT_SCALAR(textPayload, "$.contents[0].parts[0].inlineData.mimeType") LIKE "%image/%"
GROUP BY mime_type
ORDER BY c DESC
若返回 image/jpeg 行数量突增，立即检查对应请求的 input_tokens 是否远超文本长度预期——例如 500 字中文 prompt 却报出 13200 input_tokens，基本可判定是图像像素预处理导致的隐式膨胀。
对 system_instruction 的检测更简单：用正则匹配 textPayload 中是否存在 "system_instruction.*?.{200,}"，命中即告警。
