何时使用哪种模型

本视频中的演示录制于2026年8月，运行在 Claude Haiku 4.5、Claude Sonnet 5 和 Claude Opus 5 上。在更新的模型上，结果会有所不同。每节课的演示都是一次独立的评估运行，因此其分数和成本不会与其他课程中的相符。

当您为某项任务选择 Claude 模型时，您可能是凭直觉，或者听从同事的建议。Claude 的模型在能力、速度和成本上确实存在差异，但任何已发布的比较都从未见过您的具体提示，因此它们都无法告诉您某个模型在您的任务上会表现如何。正确的选择方法是先衡量每个模型正确完成您任务的频率，然后再看各自的成本。

这很像买一把梯子来爬到墙顶。在看价格之前，您要先弄清楚墙有多高，因为一把太短的梯子不管多便宜都没用。靠猜测无法知道哪些梯子够得着，所以您要去量一量，在够得着的梯子中，买最便宜的那把。更高的墙需要更长的梯子，即使价格更贵，那也是该买的那把。

对于模型而言，这种衡量是通过评估（eval）来完成的，评估是一组您让每个模型都运行一遍的用例。每个用例包含提示将看到的一个输入，以及您期望得到的答案，而这个答案是在任何模型运行之前，由人根据该输入写出来的。每次运行都会得到一个分数，表示模型答对了多少个用例。

本课将跟随 Meridian 展开。它每月会收到50份 Markdown 格式的项目报告，一个提示会从每份报告中提取三个字段：项目 ID、进度状态和首要风险。它的用例就是某一个月的这50份报告，而它目前还不知道的是应该用哪个模型来运行这个提示。

Meridian 通过五个步骤得出结论，您也可以用自己的提示遵循同样的步骤：

1. 确定模型需要多高的准确率
2. 用相同的用例为每个模型打分
3. 算出一次调用的成本
4. 按每个已完成任务的成本比较模型
5. 选择在满足所需准确率的前提下成本最低的模型

确定模型需要多高的准确率

这就是墙的高度，您要在看任何成本之前先确定它。您的准确率底线是模型在您愿意上线使用之前，必须答对的用例比例。要设定这条底线，需要先算出一个错误答案会让您付出多大代价，因为代价越高，底线就应该设得越高。

对 Meridian 来说，一个错误答案意味着必须有人手动检查那份报告，大约需要5分钟。它的工程师每月能承受5次这样的检查，而50份报告中的5份正好是10%，所以 Meridian 的底线是90%。

换一个任务，底线可能会高得多。假设一个错误答案会造成1000美元的损失，比如因为它传达给了客户。那么底线就要提高到100%，此时模型的成本几乎无关紧要。

用相同的用例为每个模型打分

在用模型去衡量之前，底线只是一个数字。让每个模型都用相同的提示在相同的用例上运行，这样从一次运行到下一次运行，唯一变化的就是模型本身。 Meridian 用同一个提示，在 Claude Haiku 4.5、Claude Sonnet 5 和 Claude Opus 5 这三个模型上运行了它的50份报告。

Meridian 的一个脚本会将每个字段与预期答案进行核对。项目 ID 和进度状态必须完全匹配，但首要风险是一个句子，因此脚本对它的比较更宽松，允许措辞上的细微变化。每个用例就是一个任务，对 Meridian 而言，这意味着从一份报告中提取三个字段。只有当模型把三个字段都答对时，它才算完成了该任务。

在这50个用例中，30份是典型报告，10份同时涵盖多个项目，还有10份没有风险部分。下表按这三种类型分解了每个模型的得分。

在相同提示和90%底线下，按报告类型划分的每个模型答对用例的比例

Sonnet 5 和 Opus 5 都全部答对了50个用例。Haiku 4.5 答对了42个，即84%，因此在这项任务和这个提示下，它没有达到底线。

算出一次调用的成本

既然已经有两个模型达到了底线，接下来就要考虑成本了。计费是按令牌（token）计算的，令牌是模型处理的一段文本，而 Messages API 的每个响应都包含一个 usage 数据块，其中记录了您被计费所依据的确切令牌数。下面的例子是一个示意，是一次规模与 Meridian 的调用相近的 Sonnet 5 调用，输入令牌780个，输出令牌41个。

"usage": {
  "input_tokens": 780,
  "output_tokens": 41
}

对每个模型，都应该从 usage 中读取这些数值，而不是靠估算文本得出。模型的分词器（tokenizer）是把文本拆分成令牌的部分，并非每个模型都使用同一个分词器。因此同一段文本在不同模型上可能得到不同数量的令牌。Sonnet 5 和 Opus 5 使用一个更新的分词器，对同样的文本会生成大约多30%的令牌，而 Haiku 4.5 使用的是旧的分词器。

输入令牌和输出令牌有各自独立的费率，均以每百万令牌为单位给出。下表展示了三个模型在2026年8月（即 Meridian 运行此次评估时）列出的费率，而 Claude 定价页面上则是当前适用的费率。

2026年8月列出的各模型每百万输入和输出令牌的费率

一次调用的成本等于其输入令牌数乘以输入费率，再加上输出令牌数乘以输出费率。 该示例是一次 Sonnet 5 调用，因此使用的是上表中 Sonnet 5 的费率。

780 input tokens  × $2 per million  = $0.0016
 41 output tokens × $10 per million = $0.0004
                              total = $0.0020

按每个已完成任务的成本比较模型

把一次运行中每次调用的成本相加，得到的总数称为运行成本。用运行成本除以模型完成的任务数，就得到了每个已完成任务的成本，这正是您用来比较模型的那个数字。

您要除以已完成的任务数，而不是调用次数。这是因为每次调用都要计费，哪怕这次调用答错了。因此，一个模型答错的那些答案，会摊加到该模型确实完成的每个任务的成本上。

按2026年8月列出的费率计算的50个用例的运行成本和每个已完成任务的成本

选择在满足所需准确率的前提下成本最低的模型

您的底线决定了哪些模型有资格成为候选，而在这些候选模型中，您要选择每个已完成任务成本最低的那一个。 Sonnet 5 和 Opus 5 都答对了全部50个，每个已完成任务的成本分别为0.0020美元和0.0046美元，因此在这项任务上 Meridian 选择了 Sonnet 5。Haiku 4.5 的0.0009美元是表中最低的数字，但它没有资格成为候选，因为它没有达到底线。

在更难的任务上，最强大的模型可能是唯一能达到底线的模型，那样它就是正确的选择。每个结果也都与评估所用的提示和用例密切相关。一旦改变提示或用例，正确的模型选择也可能随之改变，因此只要改动了其中任何一项，就应该重新运行评估。

这个评估并不衡量延迟。如果您的用户需要等待答案，就请像这里为答案打分一样，在您自己的用例上对响应计时。

降低运行评估的成本

这五个步骤能帮您选出一个模型，此外还有一种方法可以降低评估本身的成本。没有人需要实时等待评估的答案，因此您可以通过 Batch API 来发送请求，该 API 会异步处理请求。Batch API 运行相同的模型，但输入和输出令牌的价格只有一半。

在比较模型时，不要在同一次比较中混用批处理费率和标准费率。要么按批处理费率算出每个模型的成本，要么按标准费率算出每个模型的成本。

要点总结

1. 首先根据一个错误答案会给您带来的代价，设定您的准确率底线。
2. 让每个模型运行相同的用例，并剔除任何没有达到底线的模型。
3. 从每次调用的 usage 数据块中获取其成本，然后用运行成本除以该模型完成的任务数。
4. 在达到底线的候选模型中，选择每个已完成任务成本最低的那一个。