Cloudflare AI Gateway 增加模型过度使用识别能力
Cloudflare 为 AI Gateway 的 User Insights 增加了新的分析维度,用于帮助团队更具体地理解组织内 AI 的使用情况。更新后的能力包括任务类别、模型匹配、对话轮次、用户与代理维度等,面向 AI Gateway 用户免费开放。
为什么仅看请求数和 Token 不够
在组织开始大规模使用 AI 后,成本上升、响应变慢或某些工作流调用过多模型,都是常见问题。但仅凭模型名称、请求次数和 Token 数量,很难判断真实原因。
同样的 Token 消耗,可能对应完全不同的工作:
- 代码审查
- 研究任务
- 文档总结
- 简单格式调整
- 代理为了完成任务发起的多次调用
如果不知道请求背后的任务类型,就很难判断当前模型选择是否合理。
识别“模型过度使用”
新的模型过度使用视图可以帮助团队发现:某些对话中选用的模型能力可能超过任务本身所需。
例如,一个团队可能发现,用户或代理正在把简单的格式化、摘要任务发送给高能力推理模型。该视图不会自动给出替代模型,也不是用户排行榜,而是帮助团队提出更具体的问题:
- 当前模型是否适合这个任务?
- 额外的模型能力是否提升了结果质量?
- 是否可以用更快或更低成本的模型获得相近结果?
- 问题是否集中在某个工作流、用户或代理上?
团队可以进一步对比成本、延迟、Token 使用量和对话轮次,再决定是否调整模型、提示词、工作流或路由规则。
按任务理解 AI 使用方式
User Insights 现在可以按任务类型对会话分组。初始类别包括:
- 编程
- 研究
- 写作
- 摘要
- 数据分析
这比单纯查看模型列表更有上下文。例如,一个工程团队可能主要将 AI 用于编码和调试,另一个团队可能主要用于研究和总结。团队也可能发现,大量流量其实来自简单任务,但这些任务正在调用高能力模型。
这些分类数据可用于判断模型是否被用于其最适合的工作,或者默认模型是否被过度泛化使用。
观察任务的完整成本
有些任务一次交互即可完成,有些任务需要多轮追问、修正和补充。轮次分析用于展示不同任务需要多少来回交互。
长对话并不一定是坏事,复杂研究或编码任务可能确实需要多轮。但如果简单任务反复需要多轮完成,就值得检查:
- 提示词是否清晰
- 模型是否合适
- 工作流是否设计不当
- 代理是否产生了不必要的后续调用
一次请求只是成本的一部分。团队还应关注任务完成前累计花费的时间、Token 和费用。
与自动路由结合
当团队通过任务、成本、延迟和轮次数据确认存在模型过度使用模式后,可以将这些洞察转化为自动路由策略。
例如:
- 任务视图显示大量使用来自摘要和格式化
- 模型视图显示这些请求被发送给大型推理模型
- 轮次视图显示多数会话一轮即可完成
这些信号可以帮助团队评估是否应将此类任务路由到更快或更低成本的模型。
Cloudflare 同时提到 Auto Router 已进入封闭测试。该能力会基于对话轨迹、任务类别、任务复杂度和模型匹配信号,在考虑成本的情况下自动选择合适模型。它不会简单地把所有请求发往最便宜的模型,而是根据任务需求选择模型:复杂编码或研究任务仍可能需要更强模型,简单任务则可能由更快或更低成本的模型处理。
分类信号如何生成
每个会话会生成一个分析信号,用于 User Insights 中的分组展示。该信号用于报告和路由分析,并不是为了替代或暴露原始请求内容。
分类引擎由专门的 Cloudflare Worker 处理符合条件的 AI Gateway 日志。它会分析会话轨迹,包括:
- 用户请求
- 助手回复
- 工具调用
- 工具结果
随后识别任务类型,例如编码、调试、研究或摘要,并返回置信度,同时评估任务复杂度、意图模糊度、重要性和上下文依赖等维度。
当前实现重点放在少量易理解的类别上,而不是试图推断用户工作的所有细节。
日志与延迟特性
该流程沿用 AI Gateway 现有日志架构:元数据与日志正文分开存储。当前实现中,元数据使用 Durable Objects,日志正文使用 R2。
User Insights 展示的是派生类别和聚合视图,不会把仪表盘变成原始提示词浏览器。底层日志正文的保留策略仍遵循 AI Gateway 的日志配置,因此团队在决定哪些内容进入分类器时,需要检查相关设置。
分类是异步进行的:AI Gateway 先处理请求并写入日志,再由分类 Worker 后续处理。因此分类不会进入请求路径,也不会增加用户响应延迟。
相应的取舍是,User Insights 不是实时监控视图。新会话可能不会立刻出现在仪表盘中,分析结果可能比实时流量滞后约一天,更适合用于观察一段时间内的使用模式,而不是监控实时请求。
连接用户、团队和工具
任务类别如果能按用户、团队或应用查看,会更有价值。AI Gateway 支持身份感知,可以在不单独构建报告系统的情况下提供这些上下文。
这不仅适用于团队自建应用,也适用于 Claude Code、Codex、OpenCode 等开发工具和代理框架。通过将 AI Gateway 放在 Cloudflare Access 后面,团队可以把经过身份验证的用户和会话与 AI 流量关联起来。
对于自定义应用,请求需要包含稳定的 user_id 和 session_id,以便 User Insights 分析。具体身份配置和字段名称取决于应用或工具的设置。关键是提供稳定、非敏感的用户与会话标识,避免把身份数据直接放进提示词中。
适用价值
这次更新的重点不是简单压低模型成本,而是让团队更清楚地看到:
- AI 在组织内主要用于哪些任务
- 哪些用户、代理或应用贡献了主要流量
- 哪些任务可能使用了能力过高的模型
- 哪些工作流的轮次、延迟或成本异常
- 是否可以用自动路由减少手工规则维护
对于已经通过 AI Gateway 统一管理模型调用的团队,这类分析有助于从“看请求量”进一步走向“理解任务与模型是否匹配”。
