LFM2.5-DSpark: όταν το ταχύτερο AI inference δεν απαιτεί μικρότερο μοντέλο

Τι ακριβώς κυκλοφόρησε η Liquid AI

Η Liquid AI κυκλοφόρησε ξεχωριστά DSpark draft checkpoints για τα LFM2.5-1.2B-Instruct, LFM2.5-2.6B και LFM2.5-8B-A1B. Δεν πρόκειται για νέα target models ούτε για μικρότερες εκδόσεις που αντικαθιστούν την ποιότητα και τη συμπεριφορά των βασικών μοντέλων. Κάθε drafter παράγει γρήγορα μια ομάδα υποψήφιων tokens και το αντίστοιχο LFM2.5 αποφασίζει ποια γίνονται αποδεκτά.

Τα checkpoints διατίθενται σε Safetensors και GGUF, με υποστήριξη για SGLang σε GPU serving και llama.cpp σε τοπικές συσκευές. Αυτή η διαθεσιμότητα κάνει το DSpark πρακτικά αξιολογήσιμο από ομάδες που ήδη εξετάζουν native-speed AI inference με σύγχρονα serving runtimes, χωρίς να χρειάζεται να σχεδιάσουν δικό τους speculative decoder από την αρχή.

Τα draft models έχουν περίπου 295,7 έως 327,7 εκατομμύρια παραμέτρους. Ο ρόλος τους είναι στενός: δεν δίνουν την τελική απάντηση και δεν αποτελούν αυτόνομη εναλλακτική του target. Η χρησιμότητά τους μετριέται από το πόσο συχνά προβλέπουν tokens που το target θα δεχτεί και από το αν το κόστος της πρότασης και της επαλήθευσης παραμένει μικρότερο από τον χρόνο που εξοικονομείται.

Γιατί το decode γίνεται σημείο συμφόρησης

Κατά την παραγωγή μιας απάντησης, ένα language model δημιουργεί συνήθως ένα token κάθε φορά. Η φάση decode είναι συχνά memory-bound: μεγάλο μέρος της καθυστέρησης προέρχεται από τη μεταφορά των βαρών από DRAM προς ταχύτερη μνήμη, όχι από έλλειψη καθαρής υπολογιστικής ισχύος. Όταν ο ίδιος κύκλος επαναλαμβάνεται για κάθε token, το bandwidth και η πρόσβαση στη μνήμη γίνονται κεντρικοί περιορισμοί.

Το speculative decoding χρησιμοποιεί έναν ελαφρύτερο drafter για να προτείνει περισσότερα tokens και επιτρέπει στο target model να τα ελέγξει μαζί σε ένα forward pass. Αν αρκετές προτάσεις γίνουν αποδεκτές, το σύστημα μοιράζει το κόστος φόρτωσης των βαρών σε περισσότερα παραγόμενα tokens. Αν οι προτάσεις απορρίπτονται συχνά, το πρόσθετο compute μπορεί να περιορίσει ή ακόμη και να ακυρώσει το όφελος.

Η ίδια αρχή εμφανίζεται σε διαφορετικές μορφές και σε τεχνικές όπως το constrained decoding. Εκεί, όπως και στα trie automata για χιλιάδες επιτρεπτές επιλογές, η αρχιτεκτονική της παραγωγής επηρεάζει το latency χωρίς να αλλάζει υποχρεωτικά το βασικό μοντέλο.

Τα τρία συστατικά του DSpark

Το πρώτο στοιχείο είναι ένας παράλληλος κορμός τύπου DFlash, ο οποίος χρησιμοποιεί context features του target model και παράγει hidden states για όλα τα draft tokens σε ένα forward pass. Έτσι το βαρύτερο μέρος της πρότασης δεν εκτελείται αποκλειστικά token προς token.

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

Το τρίτο είναι το confidence-scheduled verification. Μια confidence head εκτιμά την πιθανότητα να επιβιώσει κάθε draft token και ο scheduler μπορεί να κόψει ένα χαμηλής εμπιστοσύνης suffix πριν καταναλωθεί άσκοπα verification compute. Η πρωτογενής εργασία DSpark τονίζει ότι το μήκος επαλήθευσης πρέπει να προσαρμόζεται στις πιθανότητες αποδοχής και στο πραγματικό προφίλ απόδοσης του engine.

Πώς εκπαιδεύτηκαν τα draft models

Η Liquid AI αναφέρει ότι χρησιμοποίησε τη συνταγή DSpark με δεδομένα supervised fine-tuning, chat, code και function calling. Οι πρώτες εκδόσεις είναι attention-only draft models με πέντε layers και block size 9. Για κάθε έκδοση έγιναν 15 epochs και επιλέχθηκε το checkpoint με το υψηλότερο acceptance rate, όχι εκείνο με το χαμηλότερο training loss.

Η επιλογή αυτή ταιριάζει στον πραγματικό ρόλο του drafter. Δεν χρειάζεται να είναι το καλύτερο αυτόνομο language model· χρειάζεται να προβλέπει αποτελεσματικά την ακολουθία που θα δεχτεί το συγκεκριμένο target. Ο decoder stack αντιστοιχεί σε 241,2 εκατομμύρια παραμέτρους και η hidden-state projection σε 21 εκατομμύρια. Η Markov head είναι 33,6 εκατομμύρια στο 1.2B-Instruct και 65,5 εκατομμύρια στα άλλα δύο checkpoints.

Τι σημαίνει «ίδιο αποτέλεσμα» στο greedy decoding

Στο exact speculative setup με greedy decoding, ένα draft token γίνεται αποδεκτό μόνο όταν συμφωνεί με την κατανομή του target model. Αν απορριφθεί, χρησιμοποιείται το token του ίδιου του target. Η τελική ακολουθία είναι επομένως ίδια με τη baseline greedy ακολουθία εκ κατασκευής, και μετρικές όπως pass@1 ή exact match δεν αλλάζουν εξαιτίας του drafter.

Αυτό δεν πρέπει να μετατραπεί σε γενική υπόσχεση ότι κάθε ρύθμιση sampling, backend, quantized build ή μελλοντική έκδοση παράγει πάντοτε byte-for-byte ίδιο κείμενο. Τα benchmarks της Liquid AI έγιναν με temperature 0 και συγκεκριμένες εκδόσεις SGLang και llama.cpp. Η ισοδυναμία πρέπει να επαληθεύεται στο ακριβές production configuration.

Για μια ομάδα προϊόντος, το πλεονέκτημα είναι ότι μπορεί να εξετάσει γρηγορότερο serving path χωρίς να ξεκινήσει αυτομάτως επιλογή διαφορετικού target model. Παραμένουν όμως απαραίτητα integration tests, logs, fallback και οι ίδιοι έλεγχοι που απαιτούνται πριν ένα μοντέλο περάσει από αξιολόγηση σε παραγωγή.

Τι μετρήθηκε σε H100 και M4 Max

Οι server δοκιμές έγιναν με SGLang σε μία NVIDIA H100 80 GB και BF16. Οι on-device δοκιμές έγιναν με llama.cpp και Metal σε MacBook Pro M4 Max, με FP16 GGUF weights. Και στις δύο περιπτώσεις χρησιμοποιήθηκαν block size 9, batch size 1, temperature 0 και έως 256 output tokens. Η αξιολόγηση κάλυψε MATH500, HumanEval, MBPP, GSM8K και MT-Bench.

Για το LFM2.5-2.6B, ο μέσος ρυθμός ανέβηκε από 323 σε 864 tokens ανά δευτερόλεπτο στην H100 και από 61 σε 139 στο M4 Max. Για το LFM2.5-1.2B-Instruct, οι αντίστοιχοι μέσοι όροι ήταν 2,10× και 2,54×. Η Liquid AI επισημαίνει ότι η διακύμανση ανά dataset για το 1.2B μπορεί να φτάσει το 52%, άρα η κατανομή κειμένου επηρεάζει έντονα το αποτέλεσμα.

Γιατί το MoE κέρδισε λιγότερο στη συσκευή

Το LFM2.5-8B-A1B είναι Mixture of Experts. Παρότι εμφάνισε υψηλότερο acceptance rate από τα δύο dense models, η μέση επιτάχυνση στο M4 Max έμεινε στο 18%. Η Liquid AI αποδίδει τη διαφορά στην τρέχουσα MoE υλοποίηση του Metal backend στο llama.cpp και στο ότι η επαλήθευση πολλών tokens ενεργοποιεί περισσότερους experts, προκαλώντας περισσότερη μεταφορά βαρών από ένα απλό decode step.

Το παράδειγμα δείχνει γιατί το acceptance rate δεν αρκεί ως επιχειρησιακή μετρική. Το end-to-end αποτέλεσμα περιλαμβάνει κόστος drafter, verifier, kernels, μετακινήσεις δεδομένων, quantization και χαρακτηριστικά του target. Το ίδιο pattern συναντάται όταν εξετάζονται agent harnesses, self-hosting και συνολικό λειτουργικό κόστος: ένα επιμέρους benchmark δεν αντικαθιστά τη μέτρηση ολόκληρης της διαδρομής.

Function calling και agentic workflows

Η Liquid AI αναφέρει μέση μείωση 57% στο latency του LFM2.5-2.6B σε διάφορα multi-tool σενάρια. Το εύρημα είναι σχετικό με agents, επειδή μια εργασία μπορεί να περιλαμβάνει επιλογή εργαλείου, δημιουργία arguments, ανάγνωση αποτελέσματος και επόμενο βήμα. Μικρές καθυστερήσεις σε κάθε στάδιο αθροίζονται στην εμπειρία του χρήστη.

Ο αριθμός είναι vendor claim από το σύνολο δοκιμών της Liquid AI· δεν δημοσιεύεται πλήρης ανάλυση για κάθε παραγωγικό agent workflow και δεν ισχύει αυτομάτως για άλλη εφαρμογή. Για e-commerce, το σωστό test θα ήταν ο συνολικός χρόνος από το αίτημα έως την ανάκτηση αποθέματος, πολιτικής επιστροφών και τελικής απάντησης. Για marketing operations, θα μπορούσε να είναι η ανάκτηση δεδομένων, η σύνθεση και η δρομολόγηση μιας ενέργειας.

Η μέτρηση πρέπει να καλύπτει και αποτυχίες εργαλείων, retries και human approval, όπως επιβάλλει η πραγματική λειτουργία των AI agents στην παραγωγή. Ένα γρηγορότερο token stream δεν αντισταθμίζει λανθασμένα tool calls ή ανεπαρκή παρακολούθηση.

Τι σημαίνουν τα ευρήματα για το κόστος

Περισσότερα tokens ανά δευτερόλεπτο μπορούν να αυξήσουν τη χωρητικότητα ενός σταθερού hardware budget ή να μειώσουν τον χρόνο απασχόλησης μιας συσκευής ανά απάντηση. Η δημοσίευση, όμως, δεν παρέχει πλήρες total cost of ownership, κατανάλωση ενέργειας ή τιμές ανά παραγωγική εργασία. Δεν είναι τεκμηριωμένο να μετατραπεί το 3,18× σε ισόποση μείωση κόστους.

Ο drafter προσθέτει μνήμη και πολυπλοκότητα. Η οικονομία εξαρτάται επίσης από utilization, batching, concurrency, μήκος prompt και απάντησης, acceptance rate, tail latency, retries και λειτουργικό overhead. Οι δημοσιευμένες δοκιμές με batch size 1 δεν απαντούν από μόνες τους πώς θα συμπεριφερθεί ένας shared production server σε ώρες αιχμής.

Υπεύθυνο πλάνο αξιολόγησης

Η αξιολόγηση πρέπει να κρατήσει σταθερά target model, prompts, sampling, hardware και runtime. Έπειτα συγκρίνει baseline και DSpark σε διαφορετικές κατηγορίες πραγματικού workload, όχι μόνο σε έναν μέσο όρο. Για local deployment, χρειάζεται δοκιμή στην ίδια συσκευή και στο ίδιο quantization που θα χρησιμοποιηθεί.

Για on-device agents, η δοκιμή πρέπει να συμπεριλάβει θερμική συμπεριφορά, διάρκεια μπαταρίας και πραγματικές δυνατότητες της συσκευής. Το ότι οι AI agents μπορούν να λειτουργούν τοπικά δεν σημαίνει ότι κάθε speculative configuration είναι κατάλληλο για κάθε edge target.

Η ουσία πίσω από το «έως 3,18×»

Το LFM2.5-DSpark δείχνει ότι η βελτιστοποίηση inference δεν περιορίζεται στην ποσοτικοποίηση ή στην επιλογή μικρότερου μοντέλου. Η οργάνωση του decoding μπορεί να αξιοποιήσει καλύτερα την πρόσβαση στη μνήμη και να αυξήσει το throughput, ενώ το target model παραμένει ο τελικός κριτής κάθε token στο exact greedy setup.

Το 3,18× είναι πραγματικό δημοσιευμένο αποτέλεσμα για το LFM2.5-8B-A1B στο MATH500 και σε μία H100 80 GB· δεν είναι γενικός μέσος όρος. Οι μέσοι όροι κυμαίνονται από 2,10× έως 2,67× στην H100 και από 1,18× έως 2,54× στο M4 Max, ανάλογα με το μοντέλο. Αυτή η πλήρης εικόνα είναι πιο χρήσιμη από το headline, επειδή συνδέει το όφελος με dataset, architecture και runtime.

Για decision makers, το συμπέρασμα είναι συγκεκριμένο: αξίζει pilot όταν το latency ή η χωρητικότητα περιορίζουν το προϊόν, αλλά η απόφαση πρέπει να βασιστεί σε controlled benchmark με πραγματικές εργασίες. Για τέτοια συστήματα, η ανθρώπινη εποπτεία και το σωστό context παραμένουν εξίσου κρίσιμα με την ταχύτητα.