Cloudflare新增任务分析以识别AI模型过度使用
Cloudflare AI··作者 Frank Meszaros
关键信息
Overkill视图不会给用户排名，也不会自动推荐替代模型，而是通过比较延迟、输入和输出令牌、对话轮数及总成本，为评估模型适配度提供起点。Cloudflare表示，这些信号可支持Potential Savings和Auto Router，但团队仍需确认更便宜或更快的模型是否能产生同等结果。
资讯摘要
Cloudflare推出User Insights，是为了帮助团队通过AI Gateway了解人员和代理如何使用AI。原有视图展示哪些用户、应用、任务和模型产生了流量，同时标记用户和代理的异常行为。Cloudflare表示，客户希望获得更多上下文，因为模型名称和请求数量无法说明流量究竟代表代码审查、研究、简单摘要，还是代理为完成任务而反复调用模型。更新后的User Insights将任务、模型、成本、用户、代理、应用和对话模式联系起来，帮助团队调查支出上升或请求异常变慢的原因。
模型Overkill视图可以发现高能力推理模型被用于简单格式整理或摘要等任务的情况。团队随后可以检查模型是否因为是默认选项、用户不确定如何选择，或代理被配置为所有步骤使用同一模型，并在调整工作流前比较性能和成本。此次更新还支持Potential Savings视图和Cloudflare公开测试版Auto Router，后者旨在自动应用任务与模型适配信号，但Overkill视图本身不会保证推荐替代模型，也不会自动带来成本下降。
资讯正文
使用 User Insights 识别 AI 模型过度使用
上个月推出 User Insights 时，我们希望帮助团队回答一个基本问题：人们实际上在用 AI 做什么？User Insights 让团队能够更清晰地了解 AI 的使用情况，展示哪些用户、应用、任务和模型正在推动流量增长。它还会突出显示用户和代理的异常情况，帮助团队在意外或失控的支出和使用量演变成更大问题之前，及时发现这些情况。
我们最新的更新加入了用户一直在要求的一项功能：上下文。
自产品发布以来，用户一直告诉我们，仅凭模型名称和请求数量只能了解部分情况。它们能显示流量流向何处，却很少透露流量背后的工作内容：这个请求是在进行代码审查、执行研究任务，还是由代理发起多次调用来完成一项工作？相同的 token 数量可能代表截然不同的工作类型；如果不了解任务，就无法评估模型选择是否合适。
现在，User Insights 可以显示：某个模型何时可能比任务所需的能力更强；哪些用户和代理正在推动这类使用；以及任务、模型、成本和对话模式之间的关联。团队可以利用这些洞察进行调查，并在组织内部采取有针对性的调整。这些功能面向 AI Gateway 用户免费提供。
为什么 AI 使用情况难以理解
设想这样一个团队：它已经通过 AI Gateway 路由内部 AI 流量。几周后，支出不断增加，一些请求的速度也比预期更慢。随着组织大规模采用 AI，这是一个常见挑战。
这背后可能有多种原因。开发者可能正在使用 AI 处理日益复杂的编码工作。代理可能为了完成一项任务而发起过多后续调用。又或者，少数用户或代理可能占据了组织使用量中不成比例的份额。
仅凭 token 数量和请求数量，无法判断究竟是哪种模式导致了增长。团队需要先了解这些流量代表什么，然后才能决定是否应该调整模型、工作流或路由规则。
帮助团队找出 AI 模型能力过剩的场景
模型过度使用视图可以帮助团队识别这样的对话：所选模型的能力似乎超过了任务的实际需求。例如，团队可能会发现，用户或代理正在将简单的格式处理或摘要请求发送给高能力推理模型。
这为组织提供了一个着手调查的方向。他们可以查看哪些用户、代理或应用与这一模式相关联，然后调查背后的具体任务。团队可能会发现，使用某个模型是因为它被设为默认模型，也可能是因为用户不确定该选择哪个模型，或者因为某个代理被配置为在每一步都使用同一个模型。
过度使用视图不是排行榜，也不会自动推荐替代模型。它的作用是帮助团队提出更好的问题：
这个模型适合这项任务吗？
额外的能力是否改善了结果？
更快或成本更低的模型能否产生同等结果？
问题是否仅限于某一个工作流、用户或代理？
在此基础上，团队可以比较成本、延迟、token 使用量和对话轮次，然后再决定需要进行哪些调整。
这些洞察既支持全新的“潜在节省”视图，也支持自动路由器（Auto Router）。自动路由器将随本次发布一同推出公开测试版。“潜在节省”视图可帮助团队识别那些在不影响输出质量的情况下，可能交由更快或成本更低的模型处理的请求。自动路由器会自动应用这些任务与模型匹配信号，帮助降低成本，而无需针对每种工作负载分别制定路由规则。
“过度配置”（Overkill）视图是评估模型匹配度的起点。团队可以针对同类任务，比较延迟、输入和输出 token 数量、对话轮数以及总成本。一项复杂的编码或研究任务可能需要能力更强的推理模型，而简短的摘要或简单的分类任务则未必需要。目标并不是将每个请求都转交给成本最低的模型，而是了解所选模型是否适合这项工作。
了解人们使用 AI 的目的
任务分析会按照对话所代表的工作类型对其进行分组。初始类别包括编码、研究、写作、摘要和数据分析。
这提供了单纯的模型名称列表无法提供的背景信息。一个工程团队可能主要使用 AI 进行编码和调试，而另一个团队可能将其用于研究和摘要。团队还可能发现，大量流量其实来自简单任务，尽管这些任务被发送给了高能力模型。
不同团队得到的答案会有所不同。类别数据提供了一种利用已经通过 AI Gateway 的流量来调查这些差异的方法。团队可以判断某个模型是否被用于其最擅长处理的工作，或者某个默认模型是否被过于广泛地应用。
了解一项任务的完整成本
有些任务一次交互就能完成，另一些则需要经过几轮提问、修正和跟进。轮次分析可以显示不同任务需要多少来回交互。较长的对话不一定是坏事，尤其是在处理复杂工作时。但如果一项简单任务总是需要多轮交互，就值得检查提示词、模型或工作流程。
首次请求只是成本的一部分。团队还应关注任务完成前所花费的时间、token 数量和资金。对比这些数据，可以发现某个工作流程在哪些地方耗时更长，或成本高于预期。
将洞察转化为自动路由
团队一旦发现某种过度配置模式，并通过任务、成本、延迟和轮次数据确认这一模式，就可以将该洞察转化为自动路由决策。
例如，任务视图可能显示，团队的大量 AI 使用场景是摘要和格式化。模型视图可能显示，这些请求被发送给了大型推理模型，而轮次视图则表明，大多数对话只需一轮即可完成。结合起来，这些信号就为团队提供了一个可以具体评估的工作负载。
除了对 User Insights 进行更新之外，Auto Router 现已进入封闭测试阶段。Auto Router 会利用对话轨迹、任务类别、任务复杂度和模型匹配度等信号，在考虑成本的同时，自动将请求路由至合适的模型。
在测试阶段，客户无需为每种工作负载分别创建路由规则，而是可以让 Auto Router 在其应用可用的模型中进行选择。路由器并不会简单地将每个请求都发送给成本最低的模型，而是会根据当前任务选择合适的模型。复杂的编程或研究工作可能仍然需要功能更强大的模型，而较简单的任务则可以交由响应更快或成本更低的选项处理。
如需进一步了解 Auto Router 并报名参加封闭测试，请阅读此处的博客文章。
Auto Router 使用的任务信号和对话信号，与 User Insights 所依赖的信号相同。下面将介绍这些信号是如何生成的。
User Insights 如何对流量进行分类
每个对话都会获得一个分析信号，该信号可以在 User Insights 中进行分组。该信号用于报告和路由分析，并不用于取代或暴露原始请求。
分类引擎是一个专用的 Cloudflare Worker，用于处理符合条件的 AI Gateway 日志。它会检查对话轨迹，包括用户请求、助手响应、工具调用和工具结果，并识别正在执行的工作类型，例如编程、调试、研究或摘要生成。它还会返回一个置信度分数，并评估任务复杂度、意图歧义性、风险程度和对上下文的依赖程度等维度。
Worker 会返回一个类别，该类别可以与控制面板使用的日志元数据关联起来。这些信号还可用于评估模型匹配度：将候选模型与任务的适配程度同其成本进行比较。当前实现侧重于一组易于理解的小型类别集合，而不是试图推断用户工作中的每一个细节。
该流水线遵循现有的 AI Gateway 日志架构。元数据与日志正文分开存储；当前实现使用 Durable Objects 存储元数据，使用 R2 存储日志正文。User Insights 展示派生类别和聚合视图，不会将控制面板变成原始提示词浏览器。底层日志正文的保留仍然遵循已配置的 AI Gateway 日志记录行为，因此团队在决定通过分类器发送哪些内容时，应当检查相关设置。
分类过程是异步的，也就是说，它发生在 AI Gateway 处理请求之后，而不是用户等待响应期间。AI Gateway 会先按照现有存储路径写入日志，随后由分类 Worker 对其进行处理。这样可以将分类过程排除在请求路径之外，不会增加用户获得响应的延迟。
代价在于，User Insights 并不是实时视图。新收到的对话可能不会立即显示在仪表板中；随着日志被处理和聚合，分析结果可能会比传入流量滞后约一天。团队应使用 User Insights 来识别一段时间内的使用模式，而不是监控实时请求活动。
流程如下：
将使用情况与用户、团队和工具关联起来
当任务类别能够按用户、团队或应用程序查看时，其实用性会更高。AI Gateway 具备身份感知能力，无需团队另外构建报告管道即可提供这些上下文信息。
这不仅适用于团队自行构建的应用程序，也适用于 Claude Code、Codex 和 OpenCode 等开发者工具及代理运行框架。通过将 AI Gateway 置于 Cloudflare Access 之后，团队可以把经过身份验证的用户和会话与其 AI 流量关联起来，从而让 User Insights 将活动归属于正确的人员和对话。
对于自定义应用程序，发出的请求必须同时包含稳定的 user_id 和 session_id，才能用于 User Insights 分析。具体的身份配置和字段名称取决于应用程序或工具的设置方式。重要的是，应提供稳定且不包含敏感信息的用户标识符和会话标识符，以便对使用情况进行分组，同时避免将身份数据放入提示词本身。
对于自定义应用程序，请求元数据可能如下所示：
POST https://gateway.ai.cloudflare.com/v1/$ACCOUNT_ID/$GATEWAY_ID/openai/chat/completions
Content-Type: application/json
Authorization: Bearer $OPENAI_API_KEY
cf-aig-metadata: { user_id: "user-123", session_id: "session-456", idp_group: "engineering", application: "code-review" }
请求正文包含该对话所使用的模型和消息。
在 AI Gateway 前配置好 Access 后，Claude Code、Codex 和 OpenCode 等工具可以自动继承这些身份上下文。对于最多 50 名用户的团队，Cloudflare Access 可免费使用，因此这是一个易于上手的方式。
开始使用 AI Gateway User Insights
AI 的使用方式正在快速变化。模型会不断更换，团队会开发新的工作流，而对一个团队来说合适的选择，对另一个团队来说可能并不合适。
User Insights 让团队能够通过识别某些模型可能被过度使用的场景，开始做出更明智的选择。随后，团队可以查看哪些用户和代理推动了这类使用，了解相关任务，并比较完成这些工作的成本。
如需了解更多信息，请参阅 AI Gateway User Insights 文档。在 Cloudflare 仪表板中打开 AI Gateway，并利用所获得的洞察，制定更有针对性的模型和路由决策。
来源与参考
收录于 2026-10-01