cost と latency の tradeoff を踏まえて、適切な model tier をどう選びますか？

Question

Accepted Answer

同じ family 内の model は、**capability と cost/latency** を trade off します。小さい model は速く安い一方で能力は低めです。大きい model は難しい問題でより良く reasoning しますが、cost が高く response も遅くなります。skill は常に最大 model を選ぶことではなく、task の難しさに model を合わせることです。

## tiers（Anthropic の lineup）

Anthropic の Claude family を例にすると（latest generation: **Opus 4.8**, **Sonnet 4.6**, **Haiku 4.5**）:

```text
Haiku   → smallest, fastest, cheapest
          → high-volume / simple tasks: classification, extraction, quick edits
Sonnet  → balanced cost/quality
          → everyday coding and general work (the sensible default)
Opus    → most capable, highest cost & latency
          → hardest multi-step reasoning, architecture, tricky debugging
```

順序は相対的です。price と latency は **Haiku < Sonnet < Opus** で、raw capability も同じ順序です。

## 選び方

- **安いところから始める**。まず Haiku や Sonnet を使います。多くの task は top tier を必要としません。
- **quality が必要なときだけ escalate する**。安い model の output が wrong、shallow、または本当に難しい問題で goal を外し続ける場合に Opus へ上げます。
- **volume を考える**。tagging や routing のように millions of times 実行する task は、Opus が少し良くても Haiku にすべきです。cost と latency が掛け算で効くからです。

```text
Classify 1M support tickets   → Haiku   (volume dominates; task is simple)
Implement a feature           → Sonnet  (balanced everyday coding)
Debug a subtle race condition → Opus    (hard reasoning justifies the cost)
```

## なぜ重要なのか

最大 model を default にすると、安い tier で十分な task に money と latency を浪費します。最小 model を default にすると、本当に難しい work で poor result になります。意図的に選ぶ、つまり安いところから始め、quality が必要なときだけ escalate することで、scale した system を速く affordable に保ちつつ、本当に必要な問題には heavy model を投入できます。