Hvordan velger du riktig modelltier gitt kostnad og latensstilgjenginger?

Question

Accepted Answer

Modeller innen en familie handler **evne mot kostnad og latens**: mindre modeller er raskere og billigere men mindre dyktige; større er bedre til å resonnere over vanskelige problemer men koster mer og svarer saktere. Kunsten er å samsvare modellen med vanskelighetsgraden på oppgaven, ikke alltid gripe etter den største.

## Tierene (Anthropic sitt utvalg)

Bruk Anthropic's Claude-familie som eksempel (nyeste generasjon: **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
```

Rekkefølgen er relativ: **Haiku < Sonnet < Opus** både i pris og latens, og samme rekkefølge i rå evne.

## Hvordan velge

- **Start billigere.** Gå for Haiku eller Sonnet først; de fleste oppgaver trenger ikke topptieren.
- **Eskalér bare når kvalitet krever det.** Hvis output fra en billigere modell er feil, overflatisk eller fortsetter å misse målet på et genuint vanskelig problem, gå opp til Opus.
- **Tenk på volum.** En oppgave du kjører millioner av ganger (tagging, routing) burde være på Haiku selv om Opus er litt bedre — kostnaden og latensen multipliseres.

```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)
```

## Hvorfor det betyr noe

Å gå for den største modellen på stok sløser penger og legger til latens på oppgaver som en billigere tier klarer fint; å gå for den minste gir dårlige resultater på genuint vanskelig arbeid. Velge bevisst — start billigere, eskalér bare når kvalitet krever det — holder systemer raske og rimelige i stor skala mens du fortsatt tar med deg den tunge modellen til problemene som virkelig trenger det.