---
title: "贵了十倍，我为什么还是选了 Haiku"
author: "Shawn Jiang"
lang: zh
date: 2026-08-27
canonical: https://tplog.dev/zh/essay/choosing-haiku-over-cheaper-models/
translations:
  en: https://tplog.dev/en/essay/choosing-haiku-over-cheaper-models/
  ja: https://tplog.dev/ja/essay/choosing-haiku-over-cheaper-models/
---

# 贵了十倍，我为什么还是选了 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 的评测方法](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)也建议按照任务忠实度、一致性、延迟、单次调用成本和使用频率进行多维评估。[DoiT 提出的 Cost Per Task 框架](https://www.doit.com/research/economics-of-claude-openai-and-grok)则强调，便宜模型如果需要更多重试，或者更容易失败，完成一次任务的总成本可能反而更高。

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

## 最后的选择

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

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

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