5万次测评揭示AI编码模型的成本效率权衡

翻译

作者：VS Code Eval Team, @code | 2026年6月19日

在过去的六个月里，我们运行了同一个微小的评估超过50,000次。它给了VS Code agent一条指令：将字符串写入文件。没有复杂的代码库需要理解，没有测试套件需要调试，没有架构决策需要做出。这是我们的烟雾测试，一种快速确认端到端模型交互仍然正常工作的方式。

这样简单的任务让我们能够立即了解系统的健康状况：agent完成工作的可靠性以及在实践中出现的故障类型。我们原本没想让它承载更多意义。但在这个规模上，它成为了一个令人惊讶的丰富信息源，让我们了解模型如何处理即使最简单的请求。

在我们之前的博文中，我们介绍了VSC-Bench，这是我们用来衡量VS Code中agent行为的离线评估套件。在这篇博文中，我们看一下模型如何解决一个简单任务，以及它告诉我们关于效率、模型选择和小型稳定评估的价值的信息。

简单的任务有价值，恰恰是因为它消除了变量。当工作明确且正确答案是固定的时，运行之间的任何变化都来自模型或其周围的系统，而不是任务本身。这使小型评估成为一种灵敏的工具：它对管理程序回归、基础设施事件和模型行为差异做出反应，而无需复杂问题的噪音来解释。

我们使用的say_hello任务是围绕这一想法构建的。每次运行都从相同的空工作区开始，使用相同的工具和相同的固定prompt，运用我们的VS Code agent管理程序。该任务要求agent"将HELLO添加到HELLO.txt"，并检查两个断言：文件存在且包含预期的内容。

promptSteps:
  - text: Add HELLO to HELLO.txt.
    assertions:
        - check: file_exists("HELLO.txt")
        - check: file_contains("HELLO.txt", "HELLO")

因为say_hello作为烟雾测试在每个基准套件之前运行，它在六个月内跨30个模型悄悄积累了50,974次运行。这个量使基本的理智检查转变成了关于模型如何处理即使最简单工作的有用数据集。

一个开发者做这个任务会认识到工作区是空的，创建HELLO.txt，然后添加请求的内容。在最直接的VS Code agent路径中，这转化为单个create_file工具调用，内容为HELLO。

tool : create_file
args : {
  "filePath": "/path/to/workspace/HELLO.txt",
  "content": "HELLO"
}

VS Code评估管理程序在初始prompt上下文中包含工作区状态。我们假设模型不应执行冗余的存在检查。

模型如何解决say_hello

如预期所料，say_hello任务足够简单，以至于所有模型大多数时间都能通过。有趣的部分不是他们是否能完成工作，而是他们如何完成。模型能否认识到这是一个基本请求，只需要简单的解决方案？还是它仍然像对待需要计划、探索和搜索的复杂问题一样对待它？

为了建立基线，我们筛选了通过这个单工具调用路径的通过运行，并查看了该组中最低的输出令牌计数。这些运行平均约50个输出令牌，包括工具调用结构。然后我们衡量每个模型采用该路径的频率。

一个模型每次都走直接路径。更广泛的趋势是突出的地方：少数模型经常走直接路径，大多数仅偶尔这样做，五个模型从不这样做。

在顶部，Model-A独占鳌头。它在100%的通过运行中直接进行文件创建，每次都使用单个工具调用。对于这个简单请求，Model-A总是直接创建文件，不需要计划或先行探索。Model-B和Model-C分别以73%和71%的比例紧随其后。

庞大的中间集群，Model-D到Model-P，采用直接路径的频率在19%到52%之间。这些模型可以识别简单任务，但不一致。通常情况下，在创建文件前，他们会添加一个小步骤，例如读取内部状态或进行轻量级工作区探索。

在他们下方，Model-Q到Model-X很少采用直接路径，在0.2%到6%的通过运行中这样做，五个模型低于1%。对于这些模型，额外工作是默认行为。他们几乎总是在生成相同的五字符文件前先进行计划、探索或搜索。

在底部，五个模型Model-Y到Model-AC，在数千次通过运行中从不采用直接路径。他们总是先做别的事情：计划、使用补丁工具而不是简单文件创建、搜索和计划，或在创建文件前冗长叙述。对于他们来说，即使是最简单的请求也会触发复杂请求的整套机制。

所有模型都以正确的内容创建文件，但他们以非常不同的工作量达到相同的结果。即使在几乎没有歧义的任务上，一些模型仍然计划、搜索或选择更复杂的编辑工具。他们都通过了评估，但使用不同的努力量来通过它。

模型如何花费他们的开销

因为我们的离线评估管理程序捕获完整的工具调用序列，我们可以将这些跟踪转化为模型行为模式。在各次运行中，模型倾向于以几种熟悉的方式花费额外努力：

这些不是正确性故障。它们是模型没有一致认识到何时最短路径足够的迹象。在较长的任务上，计划和探索可能很有价值。在单步任务上，它们增加延迟和成本而不改善结果。

过度思考的代价

你为什么要关心模型花费多少额外步骤来写一个五字符的文件？因为这些额外步骤不是免费的，它们直接转化为输出令牌使用，这有实际成本。

对于这个简单任务，大约50个输出令牌是现实的最小值。以下图表显示了不同模型使用的输出令牌范围。所选模型的范围从最小值到数千令牌，用于相同的五字符结果！

图表分为四个明显的带。极端组包括Model-AB、Model-M和Model-U，它们分别平均3,676、2,120和1,441个输出令牌。对于相同的五字符结果，这是现实最小值的29到74倍。高开销组，从400到1,000令牌，包括Model-AA、Model-B、Model-N、Model-H、Model-V、Model-E、Model-S和Model-K。这些模型不在数千个，但他们仍然花费大约8到12倍的现实最小值。

中等组，从150到400令牌，包括Model-P、Model-D、Model-X、Model-T、Model-G、Model-Z、Model-I、Model-AC、Model-F、Model-J和Model-Q。他们增加开销，但保持离任务自然大小远得多。高效组低于150令牌：Model-R、Model-A、Model-Y、Model-W、Model-O、Model-C和Model-L。Model-L最接近我们的现实最小值，为55令牌，表明即使不总是采用直接工具路径，模型也可以以很少额外叙述完成任务。

选择一个思考较少的模型既能节省时间也能节省金钱，但知道哪个模型对任务最有效通常意味着要运行自己的基准。为了减轻这个负担，VS Code和GitHub Copilot团队继续投资于优化和模型路由。例如，自动模型选择让VS Code为你的任务选择最佳模型。

模型大小不能预测开销

我们的第一个假设是较大的模型思考过度更多，但我们的数据与此矛盾：

Model-F（一个较大的模型）平均使用160个输出令牌和2.1个工具调用。其系列中最守纪律的模型。

Model-F（一个较大的模型）平均使用160个输出令牌和2.1个工具调用。其系列中最守纪律的模型。

Model-H（来自同一系列的较小模型）平均使用485个输出令牌和3.7个工具调用。比其较大的兄弟更多的开销。

Model-H（来自同一系列的较小模型）平均使用485个输出令牌和3.7个工具调用。比其较大的兄弟更多的开销。

Model-AB（一个"迷你"模型）是单个最高开销模型，平均3,676个输出令牌。该样本中最小的模型做了最多的工作。

Model-AB（一个"迷你"模型）是单个最高开销模型，平均3,676个输出令牌。该样本中最小的模型做了最多的工作。

我们的理解是，每个模型系列中的较新代代趋向于更守纪律，无论参数计数如何。这指向训练成熟度：模型如何将其努力规模化到手头的任务。而且那种校准不是学术好奇心。它直接出现在账单上。

我们接下来去哪里？

我们想分享我们团队从这些运行中获得的一些关键洞察，以及你可能能够应用到你自己日常工作流的一些学习。

say_hello评估给我们很好的洞察，但它只代表一个任务。对于管理程序优化，我们避免围绕单个任务进行过于狭隘的优化。我们仍然定期跨多个不同任务集运行完整基准，以验证更改是否广泛改善我们的管理程序。

将模型与你的任务匹配

随着基于使用的计费，输出令牌既代表金钱也代表时间。这个任务中最精简和最重的模型之间的差异对于相同输出大约是70倍。明显的教训是"不要为了写HELLO而选择最大的模型"。但这个教训太生硬了，看为什么是say_hello教给我们的最有用的东西。

这些结果有一个重要的警告。say_hello是一个短视地平线任务，有一步和一个正确答案。在长视地平线工作上，计划、探索和推理可以防止昂贵的错误并改善完成的机会。目标不是消除计划。是理解模型是否可以区分一步任务和30步任务。

这是我们认为模型选择不应该成为开发者负担的原因之一。像努力校准、令牌效率和工具纪律这样的信号可以帮助自动模型路由为手头的任务选择正确的模型，而无需要求开发者推理每个权衡。我们继续在VS Code中投资和研究自动模型选择，因此产品可以随着时间的推移为你做出更多这些选择。

从小开始，测量充分

大多数团队不是从他们能每天运行的私有离线基准套件开始的。即使是简单的任务，一致地运行和记录充分，也可以揭示模型或系统行为的有用变化。

从最小的任务开始，该任务有明确的正确答案。然后一直运行它：将其用作夜间评估之前的飞行前检查、模型入职和基础设施更改。任务不需要聪明；它需要足够稳定，使得通过率、延迟、工具使用或故障模式的变化意味着某些东西。

重要的部分是捕获足够的结构来解释改变的内容。记录工具调用序列，而不仅仅是计数。知道有4个工具调用很有用，但不完整。知道模型计划、探索、搜索，然后创建文件告诉你开销来自哪里以及为什么运行成本更高。

// What most harnesses log:
{ "tool_calls": 4, "pass": true }

// What you actually need:
{
  "tool_sequence": ["plan", "list_directory", "search_files", "create_file"],
  "output_tokens": 617,
  "pass": true
}

从烟雾测试到信号

say_hello令人惊讶的部分不是模型可以写HELLO.txt。它是五字符编辑使努力可见：哪些模型缩小规模，哪些保持计划或搜索，以及哪些系统故障仅在数千次运行后出现。

用你在VS Code中首选的模型尝试相同的请求，在Chat Debug View中检查其工具调用，并考虑你自己最小的有用任务可能是什么。在VS Code存储库中分享你的发现。