Amplitude开放模型评估指南：Kimi实现Sonnet级性能

7月24日，微软发布了一封公开信，《开放权重与美国AI领导力》，主张开放权重模型是竞争、安全以及AI融入日常业务的关键基础设施。最初的25家签署方是特定类型的公司：英伟达、微软、Meta、戴尔、IBM、Palantir、Mistral、Hugging Face。他们显然在开放模型这一类别中有切身利益。在第一周，该名单增长到超过200家签署方，新增了OpenAI、谷歌、亚马逊、优步、Databricks、GitHub和Fireworks AI（我们自己的基础设施供应商）等众多公司。

Amplitude也在名单上。我们的首席执行官Spenser Skates发布了他致微软的电子邮件请求加入。在邮件中，他提到了我们在各大技术栈上的开源SDK，并将Amplitude描述为“开放权重AI的重度用户”。他指出，Kimi和GLM已经成为我们运营的核心，无论是在内部还是在面向客户的AI功能中。

行业正在发生转变，我们很高兴能参与其中。构建AI产品的公司愿意将开放权重视为值得捍卫的基础设施。我们想更进一步。在这篇文章中，我将详细说明Amplitude如何使用开放权重模型来改进我们的Agents。如果你的团队正在考虑开放权重模型，请以我们的示例为灵感，运行自己的测试，让你的产品变得更好。

为什么现在是测试用于Agentic产品的开放权重模型的好时机

在过去一年中，开放权重模型一直在快速改进。截至目前，它们已显著缩小了与前沿模型的性能差距。斯坦福HAI AI指数报告称，在Chatbot Arena上，开放与封闭模型之间的人类偏好差距在短短一年内从8%下降到1.7%。最新的证据是Kimi K3，这是Moonshot在7月下旬发布的2.8万亿参数开放模型，该公司称其性能与Anthropic的Fable 5不相上下。

这些开放权重模型并不是对OpenAI或Anthropic模型的自动改进。相反，它们是团队做出特定权衡的机会。The New Stack详细说明了团队在选择Kimi K3而非封闭前沿模型时所做的确切权衡：“相同结果，三分之一成本，四倍速度。”成本一直是讨论开放权重模型时的头条话题，但还有一个更重要的原因最终会更重要：自主性。

开放权重模型可以被下载，安装在公司基础设施上，并在服务真实请求之前针对特定产品表面进行微调。数据保留在该基础设施内部，而不是每次调用都发送给第三方。简而言之，它是可定制且可拥有的。随着团队制定策略以管理不断上涨的token价格，开放权重模型提供的控制力正成为一个有吸引力的选择。

背景设定：我们原有的专有设置

在开放权重模型成为可能之前，Amplitude产品内智能体体验Global Agent背后的AI系统在其全部分支智能体上运行的是Sonnet 4.6：Global Chat、Chart Agent、Data Assistant、Session Replay SQL、Preference Extractor以及一些较小的智能体。像所有前沿模型一样，Sonnet被设计为在各方面表现普遍良好，而不是针对我们需要的Global Chat或Chart Agent的特定功能。由于Sonnet的权重不开放，我们可以针对失败模式进行提示，但无法针对这些模式对模型本身进行微调。它运行良好，但仍有改进空间。

我们的测试目标是找出开放权重模型能否在显著降低成本的同时，保持Global Agent现有的客户体验（使用Amplitude自己的评估标准）。我们想要一个真实的部署决策，而不仅仅是假设性的研究结果，所以我们尽可能详细地说明了具体细节：哪个模型、什么成本、面向哪些客户等。

我们如何组织开放权重模型测试

在哪里运行。我们考虑了以下两个主要选项：

• Fireworks提供托管式开放权重模型目录（Kimi、GLM、gpt-oss），按token计费，无需运维基础设施。
• Modal提供原始GPU容器，你可以自带服务栈，并自行管理量化和批处理的所有部分。

由于我们的模型已经在托管目录中，位于生产智能体之后，Fireworks胜出。在Fireworks内部，专用GPU实例在Amplitude自己的质量套件上与无服务器模式完全匹配，提供了团队测得的最高一致性延迟，并且具有随量增长而非token数增长的固定小时成本。这种组合使专用成为安全的默认选择。

运行哪个模型。团队首先将三个开放权重选项映射到Claude产品线的层级，以便更容易比较。

• gpt-oss-120B接近Haiku：在τ-bench上具有很强的工具调用能力，价格便宜11到25倍，但在指令遵循方面较弱，因此适合狭窄的子智能体工作，而非编排。
• Kimi K2.6和K2.7接近Sonnet：专门针对长智能体工具链（200到300步）训练，在独立的τ²-bench Telecom基准上排名第一，准确率为93%，代价是思考token消耗大约翻倍。
• GLM 5.2接近Opus，但尚未完全达到：在SWE-bench和Terminal-Bench上比Opus低约4个百分点，成本大约低6倍，但在盲选偏好评审中失利，并在长时任务上表现不佳。

Amplitude为Global Agent的主智能体选择了Kimi K2.7，并非因为它在纸面得分最高，而是因为它最匹配。

选择模型类别是第一步。让Kimi K2.7在生产中真正像Sonnet一样运行是更长的项目。这项工作分为两个独立问题：延迟和可靠性，我将在下面详细讨论。

测试结构。我们的模型测试运行在一个包含186个案例的内部评估套件上，该套件旨在模拟Amplitude流量的真实形态：对话能力问题、工具路由和调度、图表生成，以及日期/算术处理。一个独立的测试环境，与生产路径隔离，并根据结果而非中间步骤进行评分，让团队在改动触及实时路由之前验证新架构。

延迟修复。 我们的数据显示，子代理很少触发，但一旦触发就占主导的挂钟时间。我们的数据科学（299秒）和图表深度研究（217秒）子代理调用耗时远高于处理大部分流量的代理。

按代理划分的平均AI响应延迟，最近30天的生产流量。

通过单代理编译器流程而不是完整的子代理调度来路由图表工作，与生产正确性匹配，平均延迟降低了约15%。另外两项已上线的变更完成了大部分剩余工作：

1. 权限检查以前每次工具调用都重新运行昂贵的阻塞查找，现在被缓存并并行化。这使数秒的开销变成了亚秒级任务，并消除了错误的图表权限拒绝这一副作用。
2. 图表定义以前是松散的JSON，只有到达后端才会失败，现在成为带类型的、经过验证的契约。这确保无效的图表定义一开始就不会被持久化。

可靠性修复。团队追踪了内部评估套件中的每个失败案例，追溯到特定的、反复出现的模式。几乎没有一个问题在Sonnet运行相同测试时出现：

• 能力幻觉：根据训练数据回答“Amplitude能否做X”而不检查，虚构不存在的UI路径或计划限制
• 退化工具循环：反复重试相同的错误工具，直到轮次结束且没有任何答案
• 手工计算和日期：计算错误的表格，年份错误的纪元转换，星期标签偏移一天
• 图表语义接近失误：定义在语法上有效但在语义上错误，比如错误的事件或遗漏归因，却作为成功反馈给用户
• 输出泄漏：原始模型推理泄漏到最终答案，或者最终消息返回为空

约80%的失败案例追溯到主代理而非子代理，这也是修复首先针对主代理的部分原因。没有一个修复是措辞更好的指令。相反，我们构建了专门针对常见失败情况的修复措施。

我们使用循环断开来在重复错误调用后切断工具访问，并强制给出诚实答案而不是死轮次。我们添加了专用的计算工具和日期表，使数字和日期永远不会经过模型自身的算术。更清晰的接地规则现在要求在任何能力声明之前进行文档或工具检查。一个清理器会剥离泄漏的推理标签，并确保即使生成中途失败，也有真实的最终消息。上下文钳制将历史压缩与模型的实际上下文窗口绑定，结果发现这几乎是所有“提示太长”失败的根源。

测试结果和启示

不做任何调整的情况下，Kimi K2.7最初在我们的186个案例套件中得分为64，与Sonnet 4.6存在明显差距。经过我们的修复工作，Kimi得分73.7，在相同的测试用例上略高于Sonnet的72.7。

Kimi K2.7在Amplitude内部评估中的得分，修复工作前后对比，以Sonnet 4.6作为生产参考

这些修复缩小了性能差距，而不影响成本。在Kimi K2.7上运行相同工作负载的成本仍然约为Sonnet的三分之一。由于Anthropic对缓存写入收费而Fireworks不收费，实际差距可能更大。

Fireworks与Anthropic每百万token定价。

全局聊天，即主代理，是成本倍增因子最重要的地方。它本身约占全局代理总花费的44%，这就是为什么模型切换和调优工作首先集中在那里。

按子代理划分的全局代理花费占比，最近测量周期。

Kimi K2.7并非开箱即用就表现优越。它是一款Sonnet级别的开放权重模型，需要针对Amplitude进行特定的调优和修正以解决特定失败。经过我们的调整，在Amplitude重要的指标上，Kimi K2.7产生了与Sonnet相当的结果，而成本仅为三分之一。

模型对话还没结束。Kimi自己的发布基准是供应商报告的，独立报道很少。一些第三方追踪器仍然认为Sonnet在工具路由可靠性方面更优。在决定什么适合特定产品或特定用户群体时，存在很多主观性。

我们的计划不是立即将所有Amplitude客户迁移到开放权重模型。Amplitude正在跨客户群测试，以确定是否一个模型应该服务所有人，或者某些客户最终使用开放权重模型而其他客户继续使用Sonnet。也许实时生产流量将帮助我们解决评估套件无法回答的问题。

Agent Analytics如何驱动我们的测试

Amplitude能够进行这次评估，是因为我们已经收集产品使用数据并构建评估，以确定模型更换是否对客户有效。Agent Analytics旨在为任何运行自己AI代理的团队回答这类问题：代理表现如何、每次会话的成本是多少，以及两者之间的真实权衡在哪里。

延迟图表、按子代理划分的支出明细、故障分类以及前后评估分数，都是我们自己的全球代理的Agent Analytics视图。正是我们的 instrumentation 将模型替换变成了一项部署决策。基准测试告诉我们Kimi K2.7在纸面上是Sonnet级别的。仅全球聊天就占全球代理支出的44%，因此主代理是3倍成本差距首先显现的地方。它显示数据科学调用耗时299秒，因此延迟工作有了目标。它还将9分评估差距追溯到五个反复出现的故障模式，因此每次修复都针对具名故障，而不是凭直觉，重跑得分为73.7，而Sonnet为72.7。

如果您正在权衡为自己的代理进行开放权重替换，流程与我们运行的相同：基于生产流量计算每次会话的基线成本和故障模式，针对自己的评估测试候选模型，修复特定差距，然后让一部分实时流量来确定评估套件无法确定的事项。

去年，当我们发现自己代理用例中传统产品分析和可观测性工具之间存在测量差距时，我们为自己构建了Agent Analytics。了解更多此处。