પરિવારમાં મોડલ ક્ષમતા વિરુદ્ધ ખર્ચ અને latency ને વેપાર કરે છે: નાના મોડલ ઝડપી અને સસ્તા છે પરંતુ ઓછી ક્ષમતા ધરાવતા છે; મોટા મોડલ મુશ્કેલ સમસ્યાઓ પર વધુ સારી રીતે તર્ક કરે છે પરંતુ વધુ ખર્ચ કરે છે અને ધીમે જવાબ આપે છે। કૌશલ્ય એ છે કે મોડલને કાર્યની મુશ્કેલીને અનુરૂપ બનાવવું, હંમેશા સૌથી મોટો લેવું નહીં।
Anthropoic ના Claude પરિવાર ને ઉદાહરણ તરીકે ઉપયોગ કરીને (સર્વશેષ પેઢી: , , ):
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
ક્રમ સાપેક્ષ છે: Haiku < Sonnet < Opus કિંમત અને latency બંનેમાં, અને કાચી ક્ષમતામાં એક જ ક્રમ છે।
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)
પ્રથમ તો મોટો મોડલ નાણાં બગાડે છે અને સસ્તા ટાયર સારી રીતે હેન્ડલ કરે છે તેવા કાર્યોમાં latency ઉમેરે છે; પ્રથમ તો નાનો મોડલ સાચી રીતે મુશ્કેલ કામમાં ખરાબ પરિણામ આપે છે। જાણમાં પસંદ કરો — સસ્તામાં શરૂ કરો, ગુણવત્તાને જરૂરી હોય ત્યારે જ વધારો કરો — સિસ્ટમને સ્કેલ પર ઝડપી અને પોષણશીલ રાખે છે જ્યારે હજી પણ ભારે મોડલને તે સમસ્યાઓમાં લાવે છે જેને તે પણ જરૂર છે.