贵了十倍，我为什么还是选了 Haiku

最近，我需要为一个上下文释义功能选择模型。用户点选英文单词后，系统要结合它所在的句子和段落，只返回一个 1～8 个汉字的中文释义。

任务看起来很轻，真正测试时却不简单。技术语境里的 race 应该译成“竞态条件”，而不是“竞争”；消息系统里的 Kafka 也不能只音译成“卡夫卡”。模型既要判断准确，又要输出足够短、严格符合 JSON 格式，还不能让用户等太久。

最初，我优先考虑的是 Gemini 2.5 Flash Lite。它的输入和输出价格分别是每百万 token 0.10 美元和 0.40 美元。按照一次请求输入 200～400 token、输出 10～15 token 估算，每千次调用大约只需 0.021 美元。

这个价格很难拒绝。但重新梳理场景后，我把选型标准排成了准确性、稳定性、速度，最后才是成本。用户未必能感受到几十毫秒的差距，却会直接受到错误释义的影响。

便宜模型并不差

Gemini 2.5 Flash Lite 在前期测试中表现不错。63 次调用没有出现 HTTP 错误，结果全部可以解析；固定路由后的 15 条样例中，14 条可以接受，中位响应时间约为 1.2 秒。

问题在于，它对 prompt 和 provider 比较敏感。

如果只要求返回“词典式基本含义”，它会把技术语境中的 race 译成“竞争”。明确要求法律、技术和学术语境使用领域通行术语后，它才稳定输出“竞态”。同一个模型通过不同 provider 调用，结构化输出的稳定性也可能明显不同。

这让我意识到，真正需要评估的不是一个模型名称，而是一套完整配置：

模型 × provider × prompt × 参数 × 输出校验

任何一项变化，都可能改变结果。

四个模型的实际表现

随后，我使用同一组 15 条样例横向测试了四个候选模型。测试内容包括多义词、固定搭配、技术术语和隐喻表达；所有模型都使用相同 prompt，并被要求返回严格 JSON。

模型	JSON 合规	中位延迟	主要问题
Claude Haiku 4.5	15/15	861ms	个别措辞不够精确
GPT-4.1 Mini	15/15	817ms	关键短语出现语义错误
GPT-5.4 Mini	15/15	966ms	技术专名只做音译
Gemini 3.7 Flash	10/15	937ms	多次结构化输出失败

GPT-4.1 Mini 最快，比 Haiku 的中位延迟少 44ms，但它把 bears directly on 译成了“具有”。GPT-5.4 Mini 的格式完全合规，却把技术语境中的 Kafka 直接译成“卡夫卡”。Gemini 3.7 Flash 在部分案例中回答得不错，但多次没有生成有效的结构化结果。

这些结果也说明，JSON 正确不等于任务完成。Schema 只能保证程序能够解析，无法保证用户不会被误导。

Haiku 同样不完美。它把 forked 译成了“分支”，不如“分叉”精确。不过在整组测试中，它没有出现明显改变原意的错误，15 次输出全部符合格式要求，响应速度也足够快。

十倍价格，未必是十倍成本

相比 Gemini 2.5 Flash Lite，Haiku 的 token 单价高出约十倍。如果只看倍率，这个差距很大；换算成绝对金额后，Haiku 每千次调用大约需要 0.25～0.48 美元。

这个功能由用户主动触发，调用频率有限，输出又很短。比较时应当换算每月增加的费用，并估计更稳定的结果可以减少多少错误。

可以用一个简单的判断方式：

月度增量成本 = 月调用数 × 两个模型的单次成本差

如果较贵模型减少的预期错误成本高于这笔增量，选择它反而更经济。错误成本不只包括重试和人工纠正，也包括用户误解内容后对功能失去信任。

Anthropic 的评测方法也建议按照任务忠实度、一致性、延迟、单次调用成本和使用频率进行多维评估。DoiT 提出的 Cost Per Task 框架则强调，便宜模型如果需要更多重试，或者更容易失败，完成一次任务的总成本可能反而更高。

这些资料不能证明 Haiku 在所有类似任务中都更好。最终判断仍然来自这组真实输入、当前调用频率和可以接受的错误风险。

最后的选择

最终，我选择了 Claude Haiku 4.5，并固定 provider、关闭随机性、限制输出 token，再用 JSON Schema 和应用层规则共同校验结果。

Haiku 在这次测试里没有拿下每项单项第一，但 15 次输出均符合格式要求，没有出现明显改变原意的错误，中位延迟为 861ms；新增成本也在当前调用量下可以接受。

上线后，我会继续记录语义错误率、延迟和月度调用量。如果用量或错误分布发生变化，再用同一组标准重跑测试。这次选择只对当前任务和当前数据负责。