AI agents: Γιατί το πιο «έξυπνο» μοντέλο δεν είναι πάντα η καλύτερη επιλογή

Η Red Hat εξηγεί γιατί στα agentic workflows η ταχύτητα μπορεί να είναι εξίσου σημαντική με την ευφυΐα ενός AI μοντέλου.

Μέχρι πρόσφατα, η σύγκριση των μοντέλων τεχνητής νοημοσύνης γινόταν κυρίως με βάση τα benchmarks. Ποιο μοντέλο λύνει περισσότερα προβλήματα; Ποιο γράφει καλύτερο κώδικα; Ποιο πετυχαίνει την υψηλότερη βαθμολογία;
Στα συστήματα που χρησιμοποιούν AI agents, όμως, αυτή η σύγκριση δεν είναι πλέον αρκετή.
Ένας agent δεν κάνει συνήθως μία μόνο κλήση προς ένα μοντέλο. Μπορεί να χρειαστεί να αναλύσει ένα πρόβλημα, να χρησιμοποιήσει ένα εργαλείο, να εξετάσει το αποτέλεσμα, να πάρει μια νέα απόφαση και να συνεχίσει τη διαδικασία πολλές φορές.
Σε ένα τέτοιο workflow, η ταχύτητα του μοντέλου αρχίζει να παίζει πολύ μεγαλύτερο ρόλο.

Τα benchmarks αρχίζουν να λένε λιγότερα

Benchmarks όπως τα GSM8K, MMLU και HumanEval χρησιμοποιούνται εδώ και χρόνια για τη σύγκριση μεγάλων γλωσσικών μοντέλων.
Το πρόβλημα είναι ότι τα ισχυρότερα μοντέλα έχουν πλέον φτάσει αρκετά κοντά μεταξύ τους σε ορισμένες από αυτές τις δοκιμές. Όταν πολλά μοντέλα πετυχαίνουν πολύ υψηλές βαθμολογίες, η διαφορά μερικών μονάδων δεν αρκεί για να αποφασίσει ένας developer ποιο μοντέλο ταιριάζει καλύτερα σε μια πραγματική εφαρμογή.
Για αυτόν τον λόγο, πλατφόρμες αξιολόγησης όπως η Artificial Analysis εξετάζουν πλέον και άλλες παραμέτρους:

• την ταχύτητα παραγωγής tokens,

• τον χρόνο που απαιτείται για την ολοκλήρωση μιας εργασίας,

• το κόστος,

• και τη συνολική απόδοση του μοντέλου.

Η ερώτηση επομένως δεν είναι μόνο «ποιο μοντέλο είναι πιο έξυπνο;».
Είναι περισσότερο:
Ποιο μοντέλο είναι αρκετά ικανό, αρκετά γρήγορο και οικονομικά βιώσιμο για τη συγκεκριμένη εργασία;

Γιατί η καθυστέρηση πολλαπλασιάζεται στους AI agents

Σε ένα απλό chatbot, ο χρήστης κάνει μια ερώτηση και το μοντέλο απαντά.
Ένας agent μπορεί να χρειαστεί δεκάδες διαδοχικές κλήσεις.
Η Red Hat χρησιμοποιεί ένα χαρακτηριστικό παράδειγμα με ένα workflow 20 κλήσεων.
Αν κάθε κλήση χρειάζεται περίπου δύο δευτερόλεπτα, ο συνολικός χρόνος μπορεί να φτάσει περίπου τα 45 δευτερόλεπτα.
Με ένα ταχύτερο backend, όπου κάθε βήμα ολοκληρώνεται σε λιγότερο από ένα δευτερόλεπτο, το ίδιο workflow μπορεί να ολοκληρωθεί περίπου σε 13 δευτερόλεπτα.
Η διαφορά είναι πολύ μεγάλη, ιδιαίτερα όταν ο developer περιμένει τον agent για να συνεχίσει τη δουλειά του.
Η ταχύτητα επομένως δεν είναι απλώς ένα τεχνικό χαρακτηριστικό. Επηρεάζει άμεσα το πόσο πρακτικό είναι ένα AI σύστημα στην καθημερινή χρήση.

Περισσότερη «νοημοσύνη» συνήθως σημαίνει και περισσότερο χρόνο

Η Red Hat αναφέρεται επίσης σε έρευνα της Epoch AI, η οποία εξέτασε τη σχέση μεταξύ ακρίβειας και χρόνου εκτέλεσης.
Τα αποτελέσματα δείχνουν ότι η μείωση του ποσοστού λάθους ενός μοντέλου στο μισό μπορεί να απαιτεί περίπου 2 έως 6 φορές περισσότερο χρόνο, ανάλογα με το είδος της εργασίας.
Αυτό δημιουργεί ένα σημαντικό trade-off.
Ένα μεγαλύτερο και ισχυρότερο μοντέλο μπορεί να δώσει καλύτερη απάντηση σε ένα δύσκολο πρόβλημα, αλλά δεν σημαίνει ότι πρέπει να χρησιμοποιείται σε κάθε βήμα ενός agent.
Για απλές εργασίες, όπως η ταξινόμηση δεδομένων, η δημιουργία ενός προσχεδίου, η ανάγνωση μιας πληροφορίας ή μια απλή κλήση σε κάποιο εργαλείο, ένα μικρότερο και γρηγορότερο μοντέλο μπορεί να είναι αρκετό.
Αντίθετα, σε ένα κρίσιμο σημείο όπου ένα λάθος μπορεί να επηρεάσει όλα τα επόμενα βήματα, ένα ισχυρότερο μοντέλο μπορεί να αποτελεί καλύτερη επιλογή.

Διαφορετικά μοντέλα για διαφορετικές δουλειές

Η Red Hat παρουσιάζει αρκετά παραδείγματα από τη σημερινή αγορά μοντέλων.
Το Kimi K3 της Moonshot βρίσκεται ψηλά σε δείκτες ικανότητας, αλλά παράγει περίπου 40 tokens το δευτερόλεπτο.
Το Qwen3.8 Max της Alibaba κινείται σε παρόμοια κατεύθυνση, με περίπου 47 tokens το δευτερόλεπτο.
Από την άλλη πλευρά, μοντέλα όπως το Nemotron 3.5 Lightning της NVIDIA έχουν σχεδιαστεί περισσότερο με στόχο τη γρήγορη εκτέλεση.
Υπάρχουν επίσης μοντέλα που προσπαθούν να βρεθούν κάπου στη μέση, συνδυάζοντας σχετικά υψηλές επιδόσεις με χαμηλότερο latency.
Το σημαντικό εδώ είναι ότι δεν υπάρχει απαραίτητα ένα μοντέλο που πρέπει να χρησιμοποιείται παντού.
Ένας agent μπορεί να χρησιμοποιεί διαφορετικά μοντέλα ανάλογα με το βήμα που εκτελεί.

Model routing αντί για ένα μοντέλο για τα πάντα

Αυτό οδηγεί σε μια ενδιαφέρουσα αρχιτεκτονική προσέγγιση.

Ένα AI σύστημα μπορεί να στέλνει τις συχνές και σχετικά απλές εργασίες σε ένα γρήγορο μοντέλο και να καλεί ένα μεγαλύτερο μοντέλο μόνο όταν χρειάζεται πιο σύνθετη συλλογιστική.

Για παράδειγμα:

Γρήγορο μοντέλο
→ ανάγνωση
→ ταξινόμηση
→ routing
→ drafting
→ απλές tool calls

Ισχυρότερο μοντέλο
→ σύνθετη ανάλυση
→ κρίσιμες αποφάσεις
→ δύσκολο debugging
→ έλεγχος αποτελεσμάτων
→ βήματα όπου ένα λάθος μπορεί να επηρεάσει ολόκληρο το workflow

Με αυτόν τον τρόπο, ένα agentic σύστημα μπορεί να γίνει ταχύτερο και οικονομικότερο χωρίς να θυσιάζει την ποιότητα εκεί όπου πραγματικά χρειάζεται.

Speculative decoding: περισσότερη ταχύτητα χωρίς αλλαγή μοντέλου

Υπάρχουν όμως τρόποι να αυξηθεί η ταχύτητα ακόμη και όταν θέλουμε να χρησιμοποιήσουμε ένα μεγαλύτερο μοντέλο.
Μία από τις τεχνικές που παρουσιάζει η Red Hat είναι το speculative decoding.
Η ιδέα είναι σχετικά απλή.
Ένα μικρότερο μοντέλο δημιουργεί προκαταβολικά μια σειρά πιθανών tokens. Στη συνέχεια, το μεγαλύτερο μοντέλο τα ελέγχει μαζικά και αποδέχεται όσα συμφωνούν με το αποτέλεσμα που θα παρήγαγε το ίδιο.
Σε υλοποιήσεις με vLLM, τη βιβλιοθήκη Speculators και τεχνικές τύπου EAGLE-3 έχουν αναφερθεί βελτιώσεις latency περίπου 1,5 έως 3 φορές, ανάλογα με το workload.

Quantization και μικρότερες απαιτήσεις σε hardware

Μια δεύτερη σημαντική τεχνική είναι το quantization.
Με τεχνικές όπως το FP8 μπορεί να μειωθεί η μνήμη που απαιτεί ένα μοντέλο και παράλληλα να αυξηθεί η ταχύτητα του inference.
Η Red Hat αναφέρει δημοσιευμένα παραδείγματα στα οποία μοντέλα με FP8 διατήρησαν πάνω από το 99% της αρχικής επίδοσης σε κοινά evaluations.
Εργαλεία όπως το LLM Compressor μπορούν να χρησιμοποιηθούν για τη συμπίεση των μοντέλων, ενώ το vLLM αναλαμβάνει την αποδοτική εκτέλεσή τους.

Τι σημαίνει αυτό για έναν developer

Για έναν developer που σχεδιάζει AI agents, το βασικό συμπέρασμα είναι ότι δεν χρειάζεται να κυνηγά πάντα το μεγαλύτερο ή το μοντέλο με το υψηλότερο benchmark score.
Η καλύτερη αρχιτεκτονική μπορεί να αποτελείται από πολλά μοντέλα.
Ένα γρήγορο και οικονομικό μοντέλο μπορεί να αναλάβει το μεγαλύτερο μέρος της καθημερινής εργασίας, ενώ ένα ισχυρότερο μοντέλο ενεργοποιείται μόνο όταν το πρόβλημα απαιτεί βαθύτερη ανάλυση.
Παράλληλα, τεχνικές όπως speculative decoding, quantization και σωστό inference serving μπορούν να μειώσουν ακόμη περισσότερο τον χρόνο απόκρισης.
Στα σύγχρονα agentic workflows, λοιπόν, η ερώτηση αλλάζει.
Δεν είναι πλέον μόνο:

«Ποιο είναι το πιο έξυπνο AI μοντέλο;»

Αλλά:

«Ποιο μοντέλο είναι αρκετά έξυπνο και αρκετά γρήγορο για τη συγκεκριμένη δουλειά;»

Και αυτή είναι πλέον περισσότερο μια απόφαση αρχιτεκτονικής και engineering παρά ένας απλός διαγωνισμός benchmarks.