С повече от 20 години опит ние променяме вашето цифрово присъствие. Специализирани сме в разработването на уебсайтове и електронни магазини, SEO и цифров маркетинг, ERP софтуер и интелигентна автоматизация, които извеждат бизнеса ви на следващото ниво.
Адрес:
Егнатия 154, Солун 546 36
Телефон:
+30 231 231 4095
Електронна поща:
hello@twodots.gr
Готови ли сте за следващата стъпка?;
Το latency-aware LLM routing συνδυάζει ποιότητα, κόστος και χρόνο μέχρι το πρώτο token. Τι δείχνει η νέα έρευνα και πώς μεταφράζεται σε παραγωγική αρχιτεκτονική AI.
Το latency-aware LLM routing επιλέγει μοντέλο και διαθέσιμο instance με κοινό κριτήριο την ποιότητα, το κόστος και τον χρόνο μέχρι το πρώτο token. Δεν αρκεί να γνωρίζει ποιο μοντέλο απαντά καλύτερα ή φθηνότερα· πρέπει να λαμβάνει υπόψη την τρέχουσα ουρά, το μείγμα prefill και decode και τον στόχο απόκρισης του συγκεκριμένου αιτήματος.
Η εργασία «Beyond Accuracy and Cost: Latency-Aware LLM Query Routing for Dynamic Workloads» προτείνει τη Serving Framework Simulation (SFS), έναν ελαφρύ estimator του time-to-first-token (TTFT). Για επιχειρησιακά assistants, customer support και e-commerce flows, το πρακτικό συμπέρασμα είναι σαφές: η ταχύτητα έναρξης της απάντησης είναι μέρος της ποιότητας υπηρεσίας και πρέπει να σχεδιάζεται μαζί με accuracy, token cost, αξιοπιστία και ασφάλεια.
Τι δεν αποδεικνύει η μελέτη: τα ποσοστά βελτίωσης αφορούν το συγκεκριμένο experimental setup, τα μοντέλα, το hardware, τα workloads και τα SLOs της εργασίας. Δεν αποτελούν εγγύηση για κάθε deployment, ούτε το TTFT υποκαθιστά τη συνολική διάρκεια, τον ρυθμό παραγωγής tokens ή τον ποιοτικό και ασφαλή έλεγχο της απάντησης.
Οι routers μοντέλων συνήθως μαθαίνουν ποιο μοντέλο αναμένεται να δώσει καλύτερη απάντηση και πόσο θα κοστίσει. Παράλληλα, το επίπεδο υποδομής εφαρμόζει τεχνικές όπως round robin ή join-the-shortest-queue για να μοιράσει το φορτίο. Τα δύο επίπεδα όμως λύνουν διαφορετικά προβλήματα. Ο πρώτος μηχανισμός γνωρίζει τις διαφορές ποιότητας και κόστους, αλλά συχνά αγνοεί την τρέχουσα συμφόρηση. Ο δεύτερος βλέπει τις ουρές, αλλά δεν γνωρίζει αν ένα αίτημα ωφελείται ουσιαστικά από ένα ισχυρότερο μοντέλο.
Δύο επίπεδα που πρέπει να αποφασίζουν μαζί
Εκτιμά ποιο μοντέλο ταιριάζει στο αίτημα με βάση αναμενόμενη ποιότητα και χρηματικό κόστος. Αν αγνοεί το live workload, μπορεί να επιλέξει σωστό μοντέλο σε κορεσμένο instance και να χάσει το TTFT SLO.
Βλέπει διαθεσιμότητα και ουρές, αλλά μια πολιτική round robin ή shortest queue δεν γνωρίζει αν το γρηγορότερο instance εξυπηρετεί το αίτημα με την απαιτούμενη ποιότητα και κόστος.
Αυτός ο διαχωρισμός μπορεί να οδηγήσει σε κακή απόφαση. Ένας latency-agnostic router ίσως προτιμήσει το μοντέλο με την υψηλότερη αναμενόμενη ποιότητα, παρότι το συγκεκριμένο instance είναι φορτωμένο και δεν θα τηρήσει το service-level objective. Αντίστροφα, μια πολιτική shortest queue μπορεί να στείλει το αίτημα σε διαθέσιμο αλλά λιγότερο κατάλληλο μοντέλο. Η έρευνα επιχειρεί να γεφυρώσει αυτά τα δύο επίπεδα με κοινό κριτήριο απόφασης.
Η συνολική διάρκεια παραγωγής μιας απάντησης περιλαμβάνει αναμονή στην ουρά, επεξεργασία του prompt και διαδοχική παραγωγή των output tokens. Οι ερευνητές εστιάζουν στο TTFT: τον χρόνο από την άφιξη του αιτήματος μέχρι την παραγωγή του πρώτου token. Το μέγεθος αυτό αποτυπώνει την αίσθηση ανταπόκρισης σε ένα chatbot, έναν AI assistant ή μια διαδραστική εφαρμογή, ακόμη κι αν η πλήρης απάντηση συνεχίζει να παράγεται.
Για ένα e-commerce περιβάλλον, αυτό μεταφράζεται σε πολύ συγκεκριμένες στιγμές: ο πελάτης ρωτά για συμβατότητα προϊόντος, ζητά βοήθεια στην επιλογή ή περιμένει περίληψη μιας πολιτικής επιστροφών. Η εργασία δεν μετρά conversion ή εγκατάλειψη καλαθιού και δεν πρέπει να της αποδώσουμε τέτοια ευρήματα. Επιτρέπει όμως μια ασφαλή επιχειρηματική ερμηνεία: όταν η εφαρμογή είναι διαδραστική, ο χρόνος μέχρι την έναρξη της απάντησης πρέπει να αποτελεί ρητή απαίτηση του συστήματος και όχι παρενέργεια της υποδομής.
Η καθυστέρηση δεν προκύπτει μόνο από το μήκος του εισερχόμενου prompt. Στο prefill, τα tokens του prompt επεξεργάζονται παράλληλα ώστε να δημιουργηθούν οι καταστάσεις key-value και να αρχικοποιηθεί η KV cache. Στο decode, τα νέα tokens παράγονται διαδοχικά και κάθε βήμα διαβάζει τις αποθηκευμένες καταστάσεις. Το prefill είναι συνήθως πιο compute-bound, ενώ το decode συνδέεται περισσότερο με μετακινήσεις μνήμης.
Τα σύγχρονα serving frameworks χρησιμοποιούν continuous batching: νέα requests μπορούν να εισέλθουν σε όρια token iteration, χωρίς να περιμένουν να τελειώσει ολόκληρο ένα στατικό batch. Τεχνικές όπως το PagedAttention διαχειρίζονται την KV cache σε blocks, ενώ τα chunked prefills χωρίζουν μεγάλα prompts σε τμήματα ώστε να συνδυάζεται prefill και decode εργασία. Συνεπώς, δύο instances του ίδιου μοντέλου μπορεί να δώσουν διαφορετικό TTFT, επειδή έχουν διαφορετικό μείγμα ενεργών prefills, decodes, μήκη context και διαθέσιμη μνήμη.
Ο πυρήνας της πρότασης ονομάζεται Serving Framework Simulation, ή SFS. Για κάθε υποψήφιο model instance, ο μηχανισμός λαμβάνει ένα snapshot των αιτημάτων που περιμένουν και όσων εξυπηρετούνται. Χρησιμοποιεί τα εναπομείναντα prefill tokens, εκτιμήσεις για τα decode tokens και τους κανόνες batching και scheduling του serving framework. Στη συνέχεια προσομοιώνει τη σύνθεση των επόμενων token batches έως ότου το νέο αίτημα παράγει το πρώτο του token.
Η προσομοίωση δεν χρειάζεται να συνεχιστεί μέχρι να ολοκληρωθούν όλα τα resident requests. Σταματά στο batch που καθορίζει το TTFT του νέου αιτήματος. Αυτό είναι κρίσιμο για το κόστος του router, επειδή η εκτίμηση βρίσκεται στο critical path. Η μελέτη αναφέρει μέσο overhead περίπου 10-4 δευτερόλεπτα, δηλαδή τάξη μεγέθους πολύ μικρότερη από TTFT που συνήθως μετριέται σε δευτερόλεπτα.
Μια απλούστερη προσέγγιση θα άθροιζε το υπολειπόμενο prefill workload και θα το διαιρούσε με το prefill throughput του instance, προσθέτοντας έναν μέσο χρόνο για το πρώτο decode token. Αυτή η μέθοδος είναι εύκολη, αλλά δεν αποτυπώνει την παρεμβολή του decode workload ούτε τον τρόπο με τον οποίο το batching αλλάζει τη χρήση compute και μνήμης.
Στο πείραμα της εργασίας, το latency-aware objective ξεκινά από τη χρησιμότητα ποιότητας και κόστους και λαμβάνει υπόψη αν η εκτιμώμενη TTFT τηρεί το per-query service-level objective. Η παράμετρος δ ελέγχει το trade-off μεταξύ utility και καθυστέρησης: όταν δ=0, η πολιτική επιστρέφει σε latency-agnostic routing, ενώ μεγαλύτερη βαρύτητα στην καθυστέρηση περιορίζει τις επιλογές που αναμένεται να παραβιάσουν το SLO. Οι επιμέρους εκτιμήσεις ποιότητας και κόστους κανονικοποιούνται σε κλίμακα από 0 έως 1.
Οι predictors ποιότητας και μήκους εξόδου βασίζονται σε LightGBM και χαρακτηριστικά που παράγονται από το prompt. Οι συγγραφείς χρησιμοποιούν signed hashing representation 512 διαστάσεων, PCA προβολή σε 16 διαστάσεις και πρόσθετα γνωρίσματα, όπως αριθμό tokens, χαρακτήρων και προτάσεων, μέσο αριθμό χαρακτήρων ανά token και ενδείξεις τύπου εργασίας. Πρόκειται για ελαφριά αρχιτεκτονική που αποφεύγει την ανάγκη ξεχωριστού sentence-embedding model στο routing path.
Καθώς αυξήθηκε το offered load, η SFS πολιτική παρουσίασε το υψηλότερο OnTimeUtility σε όλο το εξεταζόμενο εύρος. Η εργασία αναφέρει 33% βελτίωση στο area under the curve έναντι του καλύτερου baseline και 46% υψηλότερο OnTimeUtility στα 5 queries ανά δευτερόλεπτο. Όταν μεταβλήθηκε η έμφαση στην καθυστέρηση με φορτίο 8 qps, το latency-aware routing πέτυχε έως 40% υψηλότερο utility από την πολιτική Shortest Queue για συγκρίσιμες καθυστερήσεις.
Τι μέτρησε η latency-aware προσέγγιση
Τα μεγέθη προέρχονται από την εργασία arXiv 2607.18253 και περιγράφουν μόνο το δικό της πειραματικό πλαίσιο.
Οι αριθμοί πρέπει να διαβαστούν μέσα στο πειραματικό πλαίσιο. Οι τιμές μοντέλων, τα datasets, το hardware, οι predictors, τα SLOs και το serving policy επηρεάζουν το αποτέλεσμα. Η μελέτη δείχνει ότι η κοινή βελτιστοποίηση μπορεί να υπερέχει των αποσυνδεδεμένων αποφάσεων· δεν αποδεικνύει ότι κάθε εταιρεία θα δει την ίδια ποσοστιαία βελτίωση.
Το πραγματικό traffic δεν φτάνει πάντα με ομαλό ρυθμό. Η έρευνα δοκιμάζει και Markov-modulated Poisson arrivals με δύο καταστάσεις: χαμηλό φορτίο και περιόδους burst. Εξετάζει μέσους ρυθμούς 6, 7 και 8 qps, με το σύστημα να βρίσκεται 80% του χρόνου στη χαμηλή κατάσταση και 20% στην υψηλή. Οι λόγοι υψηλού προς χαμηλό φορτίο είναι 3 και 6.
Η latency-aware προσέγγιση διατήρησε καλύτερη επίδοση και σε αυτά τα μοτίβα. Το πρακτικό μήνυμα για μια ομάδα e-commerce ή marketing automation είναι ότι η στατική ανάθεση μοντέλων βάσει ενός μέσου benchmark δεν περιγράφει ώρες αιχμής, καμπάνιες, μαζικά support events ή ξαφνικά bursts. Το routing χρειάζεται επίγνωση της τρέχουσας κατάστασης, διαφορετικά μια σωστή επιλογή μοντέλου σε ήρεμο περιβάλλον μπορεί να γίνει λάθος όταν το instance κορεστεί.
Το πρώτο βήμα είναι να διαχωριστούν οι επιχειρηματικές κατηγορίες αιτημάτων. Ένα live assistant έχει διαφορετικό αποδεκτό TTFT από μια νυχτερινή παραγωγή περιγραφών προϊόντων. Ένα request με άμεση επίδραση στον πελάτη μπορεί να έχει αυστηρότερο στόχο, ενώ ένα background workflow μπορεί να δώσει μεγαλύτερη έμφαση σε κόστος ή ποιότητα. Η έρευνα υποστηρίζει per-query constraints, όχι έναν ενιαίο αριθμό για όλα.
Έξι βήματα για production LLM routing με επίγνωση καθυστέρησης
Διακρίνετε live support, shopping assistance, εσωτερική αναζήτηση και background παραγωγή περιεχομένου. Κάθε διαδρομή χρειάζεται δικό της όριο TTFT, ποιότητας, κόστους και κινδύνου.
Καταγράψτε percentile στόχους και συνθήκες αιχμής, όχι μόνο έναν μέσο χρόνο. Συνδέστε την παραβίαση με fallback, ουρά προτεραιότητας ή ασφαλή υποβάθμιση μοντέλου.
Χρησιμοποιήστε αντιπροσωπευτικά prompts, versioned acceptance criteria και πραγματικές τιμές inference. Ένα μοντέλο δεν είναι «καλύτερο» ανεξάρτητα από το task που εξυπηρετεί.
Παρακολουθήστε queued και active requests, prefill και decode φόρτο, context lengths, batching policy, hardware και έκδοση του serving framework.
Επαληθεύστε καμπάνιες, μαζικά support events, timeouts, κορεσμένα instances και λανθασμένες εκτιμήσεις output length. Μετρήστε τόσο SLO violations όσο και πτώση ποιότητας από fallback.
Αποθηκεύστε έκδοση router, επιλεγμένο model instance, predicted και observed TTFT, κόστος, outcome και λόγο fallback, ώστε μια αποτυχία να μπορεί να αποδοθεί σε μοντέλο, predictor, υποδομή ή policy.
Για μια ομάδα που σχεδιάζει Αυτοματισμούς Επιχειρήσεων & AI, το latency-aware routing δεν είναι ένα μεμονωμένο benchmark. Είναι πολιτική λειτουργίας που συνδέει κατηγορία αιτήματος, διαθέσιμα μοντέλα, live telemetry, SLO, fallback και ανθρώπινη κλιμάκωση. Η ίδια πειθαρχία χρειάζεται και στη στοχευμένη διάγνωση των αδύναμων ικανοτήτων ενός μοντέλου: κάθε metric πρέπει να οδηγεί σε συγκεκριμένη απόφαση και όχι σε ένα γενικό score.
Το δεύτερο βήμα είναι η παρατήρηση του serving layer. Απαιτούνται snapshots για queued και active requests, μήκη prompt, κατάσταση prefill/decode και γνώση του scheduler. Το τρίτο είναι η βαθμονόμηση ανά model instance, επειδή ο ίδιος αλγόριθμος σε διαφορετικό hardware ή με διαφορετική πολιτική batching δεν έχει την ίδια καμπύλη χρόνου. Τέλος, το offline evaluation πρέπει να αντικατασταθεί ή να συμπληρωθεί από online παρακολούθηση των πραγματικών violations.
Η SFS εξαρτάται από την ποιότητα του snapshot, τις εκτιμήσεις decode length και τη σωστή αναπαράσταση του serving framework. Οι συγγραφείς σημειώνουν ότι το TTFT είναι σχετικά ανθεκτικό σε μέτρια σφάλματα μήκους, επειδή η προσομοίωση σταματά στο πρώτο token και επειδή ο αριθμός των ενεργών decode sequences έχει μεγαλύτερη σημασία από το ακριβές υπόλοιπο κάθε sequence. Παρ’ όλα αυτά, μια αλλαγή scheduler, μοντέλου ή hardware απαιτεί νέα βαθμονόμηση.
Επίσης, το TTFT δεν εξαντλεί την εμπειρία. Μια εφαρμογή μπορεί να ξεκινά γρήγορα αλλά να παράγει αργά τα υπόλοιπα tokens, να δίνει χαμηλής ποιότητας απάντηση ή να αποτυγχάνει σε ασφάλεια και ορθότητα. Η σωστή ανάγνωση της εργασίας είναι ότι η καθυστέρηση πρέπει να μπει δίπλα στην ποιότητα και το κόστος, όχι να τα αντικαταστήσει.
Για marketers και business owners, το σημαντικότερο δίδαγμα είναι οργανωτικό: οι επιλογές μοντέλου, υποδομής και customer experience δεν μπορούν να σχεδιάζονται ανεξάρτητα. Αν η ομάδα περιεχομένου ζητά ισχυρότερο μοντέλο, η ομάδα προϊόντος αυστηρό latency και η οικονομική διεύθυνση χαμηλότερο token cost, ο router είναι το σημείο όπου αυτές οι απαιτήσεις γίνονται μετρήσιμη πολιτική.
Το production κριτήριο
Μην επιλέγετε router από ένα ενιαίο accuracy–cost benchmark. Επιλέξτε πολιτική που διατηρεί αποδεκτή ποιότητα και κόστος μέσα στο πραγματικό TTFT SLO κάθε business flow.
Η απόφαση χρειάζεται έλεγχο σε steady και bursty traffic, calibration ανά model instance, παρατήρηση των tail latencies και fallback που δεν παρακάμπτει κανόνες ασφάλειας ή ανθρώπινης έγκρισης.
Η παραγωγική λειτουργία χρειάζεται επίσης σαφή ιδιοκτησία όταν ένα request δρομολογηθεί λάθος ή παραβιάσει το SLO. Ο οδηγός για το ποιος ευθύνεται όταν ένας αυτοματισμός AI αποτυγχάνει εξηγεί γιατί τα traces, οι εκδόσεις και τα approval boundaries είναι μέρος της αρχιτεκτονικής. Αντίστοιχα, τα όρια για confidence, context και ανθρώπινη εποπτεία στους AI agents παραμένουν απαραίτητα ακόμη και όταν το latency prediction είναι ακριβές.
Η μελέτη προσφέρει έναν συγκεκριμένο τρόπο να γίνει αυτό: πρόβλεψη ανά request και ανά instance, φιλτράρισμα με βάση τον στόχο TTFT και επιλογή της καλύτερης διαθέσιμης σχέσης ποιότητας-κόστους. Η αξία της δεν βρίσκεται μόνο στο SFS ως τεχνική. Βρίσκεται στην ιδέα ότι η ταχύτητα είναι μέρος της ποιότητας της υπηρεσίας και πρέπει να συμμετέχει στην ίδια απόφαση.
Αυτοματισμοί Επιχειρήσεων & AI από την TWO DOTS
Σχεδιάστε AI assistants που απαντούν έγκαιρα χωρίς να θυσιάζουν ποιότητα, κόστος και έλεγχο.
Η TWO DOTS χαρτογραφεί τα business requests, τα διαθέσιμα μοντέλα, τα SLOs, το serving telemetry, τα fallbacks και τα ανθρώπινα checkpoints, ώστε το LLM routing να λειτουργεί ως μετρήσιμη παραγωγική πολιτική.
Често задавани въпроси
Είναι η διαδικασία επιλογής του μοντέλου ή model instance που θα εξυπηρετήσει κάθε αίτημα, με κριτήρια όπως αναμενόμενη ποιότητα, κόστος και καθυστέρηση.
Time-to-first-token είναι ο χρόνος από την άφιξη του request μέχρι να παραχθεί το πρώτο token της απάντησης. Περιλαμβάνει ουρά, prefill και τον πρώτο κύκλο decode.
Προσομοιώνει τα επόμενα token batches ενός serving framework με βάση το τρέχον workload και σταματά όταν το νέο αίτημα παράγει το πρώτο token, εκτιμώντας έτσι το TTFT.
Η μικρότερη ουρά δεν γνωρίζει ποιο μοντέλο είναι καταλληλότερο ως προς την ποιότητα και το κόστος του συγκεκριμένου αιτήματος.
Η κύρια SFS προσέγγιση αξιοποιεί workload snapshots. Η εργασία παρουσιάζει και average-case ουραιοθεωρητική εκτίμηση για περιπτώσεις χωρίς real-time πληροφορία, αλλά η δυναμική κατάσταση δίνει πλουσιότερο σήμα.
Όχι. Το έως 40% αφορά τη συγκεκριμένη πειραματική σύγκριση και δεν αποτελεί γενική εγγύηση για κάθε deployment.
Σε διαδραστικές εφαρμογές, όπως customer support, shopping assistants και εργαλεία παραγωγικότητας, όπου η καθυστέρηση του πρώτου token επηρεάζει άμεσα την αίσθηση ανταπόκρισης.
Όχι. Χρειάζεται παράλληλη παρακολούθηση συνολικής διάρκειας, ρυθμού παραγωγής tokens, ποιότητας, κόστους, αξιοπιστίας και ασφάλειας.
