Modelele dintr-o familie schimbă capacitate cu cost și latență: modelele mai mici sunt mai rapide și mai ieftine, dar mai puțin capabile; cele mai mari raționează mai bine pe probleme dificile, dar costă mai mult și răspund mai lent. Abilitatea constă în potrivirea modelului cu dificultatea sarcinii, nu în apelarea mereu la cel mai mare.
Utilizând familia Claude a Anthropic ca exemplu (generația cea mai recentă: , , ):
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
Ordinea este relativă: Haiku < Sonnet < Opus atât în preț cât și în latență, și aceeași ordine în capacitate brută.
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)
A opta în mod implicit pentru modelul cel mai mare risipă bani și adaugă latență pe sarcini pe care un nivel mai ieftin le gestionează bine; a opta implicit pentru cel mai mic dă rezultate proaste la lucrări cu adevărat dificile. A alege în mod deliberat — începe mai ieftin, escaladează doar când calitatea o cere — ține sistemele rapide și accesibile la scară, în timp ce aduce în continuare modelul greu la problemele care chiar îl au nevoie.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează