Η περισσότερη κίνηση LLM σε παραγωγή δεν είναι δύσκολη. Είναι ταξινόμηση, εξαγωγή, σύντομες αναδιατυπώσεις και δρομολόγηση, το είδος δουλειάς που ένα μικρό γρήγορο μοντέλο κάνει σωστά και φθηνά. Ωστόσο το κοινό πρότυπο είναι να συνδέεις κάθε κλήση με το μεγαλύτερο διαθέσιμο μοντέλο, επειδή "απλά δουλεύει", και μετά να αναρωτιέσαι γιατί ο λογαριασμός και το latency είναι και τα δύο ψηλά. Στο Amazon Bedrock, το Claude Haiku 4.5 και το Claude Opus 4.5 είναι και τα δύο διαθέσιμα, και η μηχανική νίκη δεν είναι να διαλέξεις ένα, είναι να δρομολογείς ανά κατηγορία εργασίας ώστε το φθηνό μοντέλο να χειρίζεται την πλειοψηφία και το ακριβό να είναι διαδρομή κλιμάκωσης, όχι προεπιλογή.

Το reframing: η επιλογή μοντέλου είναι απόφαση ανά εργασία, όχι απόφαση σε επίπεδο project. Το να μεγεθύνεις κάθε αίτημα στο πιο δύσκολο αίτημά σου είναι το ίδιο λάθος με το να τρέχεις κάθε workload στον μεγαλύτερο τύπο instance σου. Το right-sizing σημαίνει να ταιριάζεις το μοντέλο με τη δυσκολία της συγκεκριμένης κλήσης, και για μεγάλο μερίδιο κλήσεων το σωστό μέγεθος είναι μικρό.

Γιατί το μεγάλο μοντέλο είναι λάθος προεπιλογή

Η προεπιλογή στο frontier μοντέλο νιώθεται ασφαλής και είναι ακριβή σε δύο διαστάσεις. Τα μοντέλα κλάσης Opus κοστίζουν αρκετές φορές περισσότερο ανά token από τα μοντέλα κλάσης Haiku, οπότε ένα workload που είναι 90 τοις εκατό μηχανικό πληρώνει τιμές frontier για δουλειά που ένα μικρό μοντέλο κάνει τέλεια. Είναι επίσης πιο αργά, γιατί τα πιο ικανά μοντέλα γενικά χρειάζονται περισσότερο χρόνο για να απαντήσουν, οπότε διογκώνεις το latency ακριβώς στις κλήσεις υψηλού όγκου, απλές, όπου οι χρήστες προσέχουν την ταχύτητα περισσότερο.

Το κρυφό κόστος είναι ότι ένα μεγάλο μοντέλο σε μια απλή εργασία σπάνια παράγει καλύτερο αποτέλεσμα. Η εξαγωγή μιας ημερομηνίας από ένα email ή η ταξινόμηση ενός ticket σε μία από έξι κατηγορίες δεν βελτιώνεται όταν ρίχνεις περισσότερη ικανότητα πάνω της. Πληρώνεις περισσότερο και περιμένεις περισσότερο για μια απάντηση που ένα μικρότερο μοντέλο θα έπαιρνε σωστά.

Δρομολόγησε ανά κατηγορία εργασίας

Ο σχεδιασμός που δουλεύει είναι να ταξινομείς το αίτημα κατά δυσκολία και να το στέλνεις στο μοντέλο που ταιριάζει. Όχι ανά χρήστη, όχι ανά feature, ανά κατηγορία εργασίας:

  • Η μηχανική δουλειά πάει στο Haiku. Ταξινόμηση, εξαγωγή, μετατροπή μορφής, σύντομες περιλήψεις, κατασκευή ορισμάτων εργαλείου και αποφάσεις δρομολόγησης. Υψηλός όγκος, χαμηλή ασάφεια, και ένα μικρό μοντέλο είναι και φθηνότερο και γρηγορότερο χωρίς απώλεια ποιότητας.
  • Η δουλειά κρίσης πάει στο Opus. Πολυβηματικό reasoning, ασαφείς οδηγίες, σύνθεση μεγάλου context, και οτιδήποτε όπου μια λάθος απάντηση είναι ακριβή. Χαμηλότερος όγκος, και αξίζει το επιπλέον κόστος γιατί η ικανότητα πραγματικά αλλάζει το αποτέλεσμα.
  • Ο ίδιος ο router είναι φθηνός. Μια ευρετική στο μήκος εισόδου και τον τύπο εργασίας, ή μία μόνο κλήση μικρού μοντέλου, αποφασίζει την κατηγορία. Το κόστος δρομολόγησης είναι σφάλμα στρογγυλοποίησης απέναντι σε αυτό που εξοικονομείς μη κάνοντας προεπιλογή τα πάντα στην κορυφή.

Το μεγάλο μοντέλο ως διαδρομή κλιμάκωσης

Το πιο αξιόπιστο πρότυπο είναι να κάνεις το frontier μοντέλο μια κλιμάκωση, όχι μια μπροστινή πόρτα. Δοκίμασε πρώτα το μικρό μοντέλο. Αν πετύχει, και για τη μηχανική πλειοψηφία θα πετύχει, τελείωσες με κλάσμα του κόστους και του latency. Αν αποτύχει σε έναν έλεγχο, χαμηλή σιγουριά, ένα output άκυρο ως προς το σχήμα, ένα ρητό "δεν είμαι σίγουρος", κλιμάκωσε αυτό το μεμονωμένο αίτημα στο μεγαλύτερο μοντέλο.

result = invoke(HAIKU, task)
if not passes_check(result):
    result = invoke(OPUS, task)   # escalate only the hard cases
return result

Αυτό αναστρέφει την οικονομία. Αντί να πληρώνεις τιμές Opus σε κάθε αίτημα για να καλύψεις τη σπάνια δύσκολη περίπτωση, πληρώνεις τιμές Haiku στην κοινή περίπτωση και φτάνεις στο Opus μόνο όταν η φθηνή προσπάθεια εμφανώς υστέρησε. Το trade-off είναι μία επιπλέον κλήση στη μειοψηφία των αιτημάτων που τη χρειάζονται, απέναντι σε μεγάλη εξοικονόμηση στην πλειοψηφία που δεν τη χρειάζεται.

Μέτρησε πριν υποθέσεις τον διαχωρισμό

Το σημείο όπου οι ομάδες κάνουν λάθος είναι το να μαντεύουν το μείγμα εργασιών αντί να το μετρούν. Πριν δρομολογήσεις, δειγματολόγησε πραγματική κίνηση και επισήμανε πόσο από αυτήν είναι γνήσια μηχανικό έναντι γνήσια δύσκολο. Ο αριθμός είναι σχεδόν πάντα πιο μηχανικός από όσο περιμένει η ομάδα, που είναι ακριβώς γιατί η προεπιλογή στο μεγάλο μοντέλο σπαταλά τόσα πολλά. Σου λέει επίσης πού να ρυθμίσεις το trigger κλιμάκωσης: αν το μικρό μοντέλο χειρίζεται καθαρά το 92 τοις εκατό της κίνησης, το ποσοστό κλιμάκωσής σου πρέπει να είναι κοντά στο 8 τοις εκατό, και ένα πολύ υψηλότερο ποσοστό σημαίνει ότι ο έλεγχός σου είναι πολύ αυστηρός ή η δρομολόγησή σου είναι κακά βαθμονομημένη.

Το συμπέρασμα

Και τα δύο, Haiku και Opus, είναι στο Bedrock εδώ και μήνες, και το νόημα δεν είναι να διαλέξεις ανάμεσά τους, είναι να χρησιμοποιήσεις το καθένα εκεί που ταιριάζει. Δρομολόγησε ανά κατηγορία εργασίας: στείλε τη μηχανική πλειοψηφία στο μικρό γρήγορο μοντέλο και κράτα το frontier μοντέλο για τη μειοψηφία που απαιτεί κρίση, ιδανικά ως διαδρομή κλιμάκωσης ενεργοποιημένη από αποτυχημένο έλεγχο παρά ως προεπιλογή. Μέτρησε το πραγματικό μείγμα εργασιών σου πριν συντονίσεις τον διαχωρισμό. Το right-sizing μοντέλου είναι η ίδια πειθαρχία με το right-sizing instance, και το ταχύτερο, φθηνότερο σύστημα είναι αυτό που σταματά να πληρώνει τιμές frontier για δουλειά που ένα μικρό μοντέλο κάνει σωστά.

Διάβασε αυτό στη συνέχεια

Για την πλευρά πλατφόρμας της δρομολόγησης και χωρητικότητας σε μοντέλα, οι σημειώσεις πεδίου cloud βρίσκονται στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.