Speculative decoding με DSpark: πώς το AI απαντά γρηγορότερα χωρίς να αλλάζει αποτέλεσμα

Το speculative decoding με DSpark επιταχύνει το LFM2.5 χωρίς αλλαγή της greedy εξόδου. Δείτε πώς λειτουργεί, τι έδειξαν H100 και M4 Max και πώς σχεδιάζεται ασφαλές production pilot.

Το speculative decoding με DSpark επιταχύνει την παραγωγή tokens χωρίς να αντικαθιστά το LFM2.5 target model. Ένας μικρός drafter προτείνει ολόκληρο block, το target το ελέγχει σε ένα forward pass και κρατά μόνο τα tokens που συμφωνούν. Με greedy decoding και temperature 0, η τελική ακολουθία παραμένει ίδια με το target-only baseline· το πραγματικό όφελος όμως εξαρτάται από workload, hardware, backend και acceptance rate.

Περιεχόμενα

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

Στο autoregressive decoding, το μοντέλο παράγει ένα token, ενημερώνει την κατάστασή του και επαναλαμβάνει τη διαδικασία. Η ακολουθία είναι σειριακή. Ακόμη και όταν ο επιταχυντής διαθέτει μεγάλη υπολογιστική ισχύ, κάθε νέο βήμα απαιτεί μεταφορά βαρών και πρόσβαση στη μνήμη. Γι’ αυτό η Liquid AI περιγράφει τη φάση decoding ως κυρίως memory-bound και όχι ως απλό πρόβλημα περισσότερων FLOPS.

Η καθυστέρηση γίνεται άμεσα ορατή σε local assistants, coding copilots και agentic workflows. Ένας agent παράγει πλάνο, επιλέγει εργαλείο, διαβάζει αποτέλεσμα και συνεχίζει. Η latency επαναλαμβάνεται πριν και μετά από κάθε tool call. Έτσι, μια βελτίωση στο decode δεν αφορά μόνο «γρηγορότερη πληκτρολόγηση», αλλά τον συνολικό χρόνο μιας εργασίας σε customer support, e-commerce ή εσωτερική αυτοματοποίηση.

Το DSpark δεν είναι ο μόνος δρόμος για καλύτερο inference. Τεχνικές όπως optimized kernels, quantization και native runtime integration μπορούν επίσης να μειώσουν καθυστερήσεις, όπως δείχνει η μετάβαση σε native-speed AI inference με vLLM και Transformers. Η διαφορά είναι ότι το speculative decoding στοχεύει ειδικά τα σειριακά decode steps, προβλέποντας περισσότερα από ένα tokens πριν από την επαλήθευση.

Πώς λειτουργεί το speculative decoding του DSpark

Το DSpark τοποθετεί δίπλα στο target model έναν μικρότερο drafter περίπου 300 εκατομμυρίων παραμέτρων. Ο drafter προτείνει ένα block εννέα υποψήφιων tokens. Το target model τα επαληθεύει μαζί σε ένα forward pass. Όσα συμφωνούν με τη δική του κατανομή γίνονται αποδεκτά· στην πρώτη απόρριψη, το target βάζει το δικό του token και η μη επαληθευμένη συνέχεια απορρίπτεται.

Αυτός ο έλεγχος είναι ο λόγος που η τεχνική μπορεί να είναι exact. Στο greedy decoding, ένα draft token εκπέμπεται μόνο όταν συμπίπτει με την επιλογή του target. Το μικρό μοντέλο δεν αλλάζει το κριτήριο και δεν επιλέγει διαφορετική απάντηση. Προσπαθεί να προβλέψει εκ των προτέρων την πορεία που θα ακολουθούσε ούτως ή άλλως το target, ώστε να μειωθούν τα ξεχωριστά target forward passes.

Target-only decoding ή DSpark;

Target-only

Ένα token ανά decode step

Το LFM2.5 επιλέγει το επόμενο token, ενημερώνει το state και επαναλαμβάνει. Η διαδρομή είναι απλή, αλλά κάθε token απαιτεί ξεχωριστό σειριακό βήμα.

DSpark

Block πρόβλεψης και μαζικός έλεγχος

Ο drafter προτείνει έως εννέα tokens και το ίδιο target τα επαληθεύει μαζί. Το κέρδος αυξάνεται όταν αρκετές διαδοχικές προτάσεις γίνονται αποδεκτές.

Τεχνική συνθήκη: ο ισχυρισμός περί ταυτόσημης εξόδου στο συγκεκριμένο release αφορά greedy decoding με temperature 0. Δεν πρέπει να επεκτείνεται αυτόματα σε κάθε sampling configuration χωρίς ξεχωριστό έλεγχο.

Τι περιέχει ο drafter των LFM2.5

Η Liquid AI κυκλοφόρησε drafters για τα LFM2.5-1.2B-Instruct, LFM2.5-2.6B και LFM2.5-8B-A1B. Ο πρώτος έχει 295,7 εκατομμύρια παραμέτρους, ενώ οι άλλοι δύο 327,7 εκατομμύρια. Η κοινή ραχοκοκαλιά περιλαμβάνει πέντε full-attention layers, hidden size 2.048, intermediate size 6.144 και grouped-query attention με 32 attention heads και 8 KV heads. Το block size είναι εννέα.

Η αρχιτεκτονική συνδυάζει τρία στοιχεία. Ένα DFlash-style parallel backbone, επηρεασμένο από context features του target, παράγει hidden states για όλες τις draft θέσεις. Ένα ελαφρύ sequential head, μοντελοποιημένο ως Markov chain ανάμεσα σε γειτονικά tokens, επαναφέρει εξάρτηση μεταξύ των προτάσεων. Ένας confidence-scheduled verifier εκτιμά ποια suffixes αξίζει να επαληθευτούν και κόβει εκείνα με χαμηλή πιθανότητα επιβίωσης όταν το πιθανό κόστος ξεπερνά το όφελος.

Ο drafter δεν αντικαθιστά το vocabulary του target. Συνδέεται με τα embeddings και το LM head του βασικού μοντέλου. Αυτό κρατά το πρόσθετο μοντέλο σχετικά μικρό, αλλά όχι δωρεάν: χρειάζεται επιπλέον μνήμη, δεύτερο checkpoint, συμβατό runtime και monitoring. Η τεχνική εικόνα συμπληρώνει την ευρύτερη ανάλυση του LFM2.5-DSpark ως επιλογής ταχύτερου AI inference, εδώ όμως το κρίσιμο ερώτημα είναι αν ο drafter προβλέπει σωστά τη συγκεκριμένη παραγωγική ροή.

Τι ακριβώς μετρήθηκε

Οι GPU δοκιμές της Liquid AI έγιναν σε μία NVIDIA H100 80 GB, με SGLang και BF16. Οι on-device δοκιμές έγιναν σε MacBook Pro M4 Max, με llama.cpp, Metal και FP16 GGUF weights. Και τα δύο setups χρησιμοποίησαν block size 9, batch size 1, temperature 0 και έως 256 output tokens στα MATH500, HumanEval, MBPP, GSM8K και MT-Bench.

Τα δημοσιευμένα DSpark benchmarks σε τέσσερις μετρικές

Vendor-reported αποτελέσματα Liquid AI στα συγκεκριμένα μοντέλα, datasets και runtimes· δεν αποτελούν γενική πρόβλεψη για production latency.

3,18×Μέγιστο στην H100LFM2.5-8B-A1B στο MATH500, 428 → 1.362 tok/s
2,87×Μέγιστο στο M4 MaxLFM2.5-1.2B-Instruct στο HumanEval, 136 → 389 tok/s
57%Μέση μείωση agent latencyVendor test με LFM2.5-2.6B σε multi-tool scenarios
1,18×Μέσο 8B-A1B στο M490 → 106 tok/s, παρά το υψηλό acceptance rate

Για το LFM2.5-2.6B, ο μέσος ρυθμός ανέβηκε από 323 σε 864 tokens ανά δευτερόλεπτο στην H100 και από 61 σε 139 στο M4 Max. Για το 1.2B-Instruct, οι αντίστοιχοι μέσοι όροι ήταν 2,10× και 2,54×. Το headline 3,18× είναι η καλύτερη δημοσιευμένη περίπτωση, όχι ο μέσος όρος όλων των workloads.

Όριο ερμηνείας: οι μετρήσεις προέρχονται από τον προμηθευτή, με batch size 1 και ελεγχόμενα benchmarks. Δεν τεκμηριώνουν ίση βελτίωση σε high concurrency, άλλο quantization, μεγαλύτερο context ή διαφορετικό prompt mix.

Από benchmark σε pilot

Το 3,18× δικαιολογεί δοκιμή, όχι υπόσχεση προς χρήστες. Η απόφαση χρειάζεται ίδια prompts, ίδιο target, ίδιο backend και μέτρηση end-to-end latency, throughput, μνήμης, ουράς και fallback στο πραγματικό περιβάλλον.

Η acceptance rate εξηγεί τις μεγάλες διαφορές

Το speculative decoding αποδίδει όταν ο drafter προβλέπει σωστά αρκετά διαδοχικά tokens. Στο MATH500, το 8B-A1B δέχτηκε 8,27 από τα 10 tokens ανά βήμα και έφτασε 3,18× στην H100. Στο GSM8K δέχτηκε 4,02 και περιορίστηκε σε 1,29× στην ίδια GPU. Για το 1.2B-Instruct, η acceptance στο MT-Bench ήταν 3,90 και το speedup στην H100 1,66×.

Το pattern δείχνει ότι το workload είναι μέρος της τεχνολογικής απόφασης. Δομημένη έξοδος, code completion ή επαναλαμβανόμενα function-call arguments μπορεί να είναι ευκολότερα για τον drafter από έναν ανοιχτό διάλογο με απρόβλεπτη συνέχεια. Αυτή είναι μηχανιστική ερμηνεία των μετρήσεων, όχι νέο benchmark ούτε υπόσχεση ότι κάθε structured task θα έχει υψηλή αποδοχή.

Η αποδοχή έχει επίσης όρια ως KPI. Ένα σύστημα μπορεί να δέχεται πολλά draft tokens, αλλά να χάνει το όφελος σε backend overhead, μεταφορά βαρών ή queueing. Όπως και στο constrained decoding με χιλιάδες επιλογές, η επίδοση δεν κρίνεται μόνο από τον αλγόριθμο· εξαρτάται από το πώς ο runtime υλοποιεί τον έλεγχο μέσα στο πλήρες request path.

Γιατί το Apple silicon δείχνει το βασικό όριο

Η καθαρότερη προειδοποίηση εμφανίζεται στο LFM2.5-8B-A1B, ένα Mixture-of-Experts μοντέλο. Στο M4 Max πέτυχε μέση επιτάχυνση μόλις 1,18×. Η Liquid AI αποδίδει το αποτέλεσμα στην τρέχουσα υλοποίηση MoE του Metal backend στο llama.cpp και στο ότι η επαλήθευση πολλών tokens ενεργοποιεί περισσότερους experts, αυξάνοντας την κίνηση βαρών σε σχέση με ένα κανονικό decode step.

Το εύρημα δεν ακυρώνει το on-device σενάριο. Δείχνει ότι αρχιτεκτονική target, kernels και backend ωριμότητα μπορούν να περιορίσουν το θεωρητικό όφελος. Μια επιχείρηση που σχεδιάζει offline copilot σε laptop πρέπει να μετρήσει στην πραγματική συσκευή, με ίδιο quantization, context length και thermal profile. Η H100 και το M4 Max δεν είναι εναλλάξιμες πλατφόρμες.

Η επιλογή συσκευής πρέπει να περιλαμβάνει μνήμη, bandwidth, κατανάλωση, χρόνο εκκίνησης και υποστήριξη runtime. Όταν το deployment απαιτεί εξειδικευμένο workstation ή server, η αξιολόγηση συνδέεται και με το κατάλληλο επαγγελματικό hardware, όχι μόνο με το θεωρητικό μέγεθος του μοντέλου.

Agents και function calling: πού μπορεί να φανεί περισσότερο

Η Liquid AI αναφέρει μέση μείωση 57% στη latency του LFM2.5-2.6B σε διάφορα multi-tool scenarios. Ο αριθμός είναι vendor-reported και δεν συνοδεύεται από πλήρη ανάλυση κάθε production workflow. Παρ’ όλα αυτά, η κατεύθυνση είναι ουσιαστική: ένας agent πληρώνει decode cost πριν από την επιλογή εργαλείου, κατά τη δημιουργία arguments και μετά την επιστροφή του αποτελέσματος.

Σε customer support, το κατάλληλο test δεν είναι μόνο tokens ανά δευτερόλεπτο. Είναι ο χρόνος από το αίτημα έως την ανάκτηση παραγγελίας, τον έλεγχο πολιτικής επιστροφών και την τελική απάντηση, με σωστά permissions και human handoff. Η επιλογή ανάμεσα σε AI agents για customer support παραμένει απόφαση workflow, data access και αξιοπιστίας· το DSpark βελτιστοποιεί ένα μέρος της διαδρομής.

Το pilot πρέπει να καταγράφει λάθος tool calls, retries, timeouts και εγκρίσεις. Η πραγματική λειτουργία των AI agents στην παραγωγή περιλαμβάνει περισσότερα από decoding. Γρηγορότερο token stream δεν διορθώνει λανθασμένη ανάκτηση δεδομένων ούτε μη ασφαλή ενέργεια.

Self-hosting, formats και άδεια χρήσης

Τα DSpark checkpoints διατίθενται ως Safetensors και GGUF. Η Liquid AI τεκμηριώνει χρήση μέσω SGLang για GPU serving και μέσω llama.cpp/Metal για on-device deployment. Τα συγκεκριμένα model cards δεν είναι αναπτυγμένα σε hosted Hugging Face Inference Provider, άρα η ομάδα πρέπει να οργανώσει self-hosting και να χρησιμοποιήσει build με συμβατή υποστήριξη DSpark για LFM2 targets.

Η λειτουργία δεύτερου μοντέλου αυξάνει την operational επιφάνεια: checkpoints, εκδόσεις, startup, μνήμη, telemetry και fallback. Το κόστος πρέπει να εξετάζεται μαζί με όσα ισχύουν για agent harnesses, έλεγχο και self-hosting. Αν ο drafter δεν φορτώνεται ή δεν είναι αποδοτικός για ένα workload, το προϊόν πρέπει να συνεχίζει με target-only decoding χωρίς διακοπή εμπειρίας.

Υπάρχει και αδειοδοτικό όριο. Η LFM Open License v1.0 ορίζει threshold ετήσιων εσόδων 10 εκατομμυρίων δολαρίων ή περισσότερο για εμπορική χρήση από legal entity. Πάνω από αυτό το όριο, η εμπορική χρήση δεν αδειοδοτείται από τη συγκεκριμένη συμφωνία. Η νομική ομάδα πρέπει να διαβάσει το ισχύον κείμενο της άδειας και να επιβεβαιώσει την εταιρική δομή πριν από παραγωγική χρήση.

Ένα σοβαρό evaluation plan πριν από την παραγωγή

Το baseline πρέπει να είναι το ίδιο target model χωρίς drafter, στην ίδια συσκευή και με τις ίδιες ρυθμίσεις. Μετρήστε time-to-first-token, inter-token latency, tokens ανά δευτερόλεπτο, end-to-end latency, peak μνήμη και ενέργεια όπου έχει νόημα. Μετά ενεργοποιήστε DSpark χωρίς να αλλάξετε ταυτόχρονα quantization, context ή backend.

Χωρίστε τα traces ανά πραγματική εργασία. Code completion, function calling, ανοιχτός διάλογος και παραγωγή ελληνικού περιεχομένου μπορούν να έχουν διαφορετική acceptance rate. Εξετάστε p50, p95 και p99, όχι μόνο μέσο όρο. Τα δημοσιευμένα benchmarks αφορούν batch size 1, επομένως η ουρά και το concurrency χρειάζονται δική τους δοκιμή.

Επτά βήματα για ασφαλές DSpark pilot

  1. Βήμα 1Κλειδώστε το target-only baseline

    Χρησιμοποιήστε το ίδιο LFM2.5 checkpoint, prompt set, context, sampling και runtime που θα χρησιμοποιήσει το προϊόν.

  2. Βήμα 2Ορίστε πραγματικά workloads

    Συλλέξτε αντιπροσωπευτικά traces για function calling, code, διάλογο και τις κρίσιμες ελληνικές ροές της επιχείρησης.

  3. Βήμα 3Μετρήστε acceptance ανά εργασία

    Μην κρύβετε τις διαφορές σε έναν γενικό μέσο όρο· συνδέστε accepted tokens με latency και business journey.

  4. Βήμα 4Ελέγξτε την exact συνθήκη

    Με temperature 0, συγκρίνετε κάθε έξοδο με το target-only baseline και κρατήστε ξεχωριστή διαδικασία για sampling modes.

  5. Βήμα 5Δοκιμάστε hardware και concurrency

    Επαναλάβετε H100, edge ή laptop tests με πραγματικό batch, ουρά, quantization, context length και θερμική συμπεριφορά.

  6. Βήμα 6Καταγράψτε operational κόστος

    Μετρήστε πρόσθετη μνήμη, startup, συμβατότητα builds, telemetry, updates και χρόνο αποκατάστασης.

  7. Βήμα 7Ενεργοποιήστε ασφαλές fallback

    Αν ο drafter αποτύχει ή δεν προσφέρει κέρδος, επιστρέψτε αυτόματα σε target-only decoding και επιβεβαιώστε την εμπειρία.

Η ίδια πειθαρχία ισχύει όταν ένα AI demo περνά στην παραγωγή. Χωρίς observability, version pinning, permission boundaries και recovery path, η ταχύτερη απόκριση μπορεί να κρύψει μεγαλύτερο λειτουργικό ρίσκο. Τα πέντε εμπόδια από το AI agent demo στην παραγωγή παραμένουν σχετικά, ακόμη κι όταν το μοντέλο αποκρίνεται πιο γρήγορα.

Πότε αξίζει το DSpark και πότε όχι

Το DSpark αξίζει όταν το decoding είναι μετρημένο bottleneck, τα workloads είναι αρκετά σταθερά, υπάρχει μνήμη για τον drafter και το runtime υποστηρίζεται αξιόπιστα. Είναι ιδιαίτερα ενδιαφέρον όταν πολλές μικρές καθυστερήσεις αθροίζονται σε agentic journey ή όταν το on-device προϊόν χρειάζεται πιο άμεση αίσθηση χωρίς αντικατάσταση του target.

Δεν είναι προτεραιότητα όταν ο χρόνος χάνεται κυρίως σε database queries, δίκτυο, tool execution ή ανθρώπινη έγκριση. Επίσης δεν αρκεί όταν η αποτυχία του agent προέρχεται από λάθος σχέδιο εργαλείων, αδύναμο retrieval ή αναξιόπιστη έξοδο. Σε αυτές τις περιπτώσεις, το optimization του decode βελτιώνει τη λάθος διαδρομή.

Η απόφαση είναι οικονομική και τεχνική μαζί. Συγκρίνετε την αξία της μειωμένης αναμονής με πρόσθετη μνήμη, engineering effort, υποστήριξη custom builds και αδειοδοτική συμμόρφωση. Αν το κέρδος μένει ουσιαστικό στα κρίσιμα journeys και στο p95, τότε μπορεί να δικαιολογεί rollout. Αν εμφανίζεται μόνο στο καλύτερο benchmark, μένει ενδιαφέρον πείραμα.

Η σωστή επιχειρηματική ανάγνωση του «έως 3,18×»

Το DSpark είναι σημαντικό επειδή επιχειρεί να μειώσει τη latency χωρίς να αλλάξει τη greedy έξοδο του target. Δεν απαιτεί αντικατάσταση με μικρότερο μοντέλο ούτε αποδοχή διαφορετικού quality profile στην επαληθευμένη διαδρομή. Το τίμημα είναι πρόσθετη μνήμη, δεύτερο checkpoint, συμβατό backend και απόδοση που εξαρτάται έντονα από την προβλεψιμότητα του workload.

Για μια επιχείρηση, το σωστό συμπέρασμα δεν είναι «το AI μας θα γίνει 3,18 φορές γρηγορότερο». Είναι «υπάρχει μια τεχνική που αξίζει να μετρηθεί στα δικά μας traces». Αν μειώνει σταθερά την end-to-end latency χωρίς αλλαγή εξόδου, χωρίς νέο operational ρίσκο και με βιώσιμο κόστος, τότε το speculative decoding περνά από εντυπωσιακό benchmark σε πραγματικό πλεονέκτημα εμπειρίας.

Αυτοματισμοί Επιχειρήσεων & AI

Μετρήστε το AI workflow πριν βελτιστοποιήσετε το μοντέλο

Η TWO DOTS σχεδιάζει ασφαλείς αυτοματισμούς και AI ροές με πραγματικά business journeys, permissions, monitoring και fallback, ώστε η ταχύτητα να μετατρέπεται σε αξιόπιστη εμπειρία.

Συχνές ερωτήσεις

Τι είναι το speculative decoding;

Είναι τεχνική όπου ένα μικρό draft model προτείνει πολλά επόμενα tokens και το target model τα επαληθεύει μαζί, μειώνοντας τα σειριακά decode steps όταν αρκετές προτάσεις γίνονται αποδεκτές.

Αλλάζει το DSpark την απάντηση του LFM2.5;

Με greedy decoding και temperature 0, η επαληθευμένη ακολουθία είναι ίδια με εκείνη του target-only baseline, επειδή κάθε draft token εκπέμπεται μόνο όταν συμφωνεί με την επιλογή του target.

Γιατί έχει σημασία το temperature 0;

Επειδή η τεκμηριωμένη exact ισοδυναμία αφορά greedy επιλογή. Δεν πρέπει να θεωρείται δεδομένη η ίδια συμπεριφορά σε κάθε sampling configuration χωρίς ξεχωριστή επαλήθευση.

Είναι κάθε workload 3,18 φορές γρηγορότερο;

Όχι. Το 3,18× είναι η καλύτερη vendor-reported περίπτωση σε H100 και MATH500. Η απόδοση αλλάζει ανά μοντέλο, dataset, acceptance rate, hardware, backend και ρυθμίσεις.

Πόση επιπλέον μνήμη χρειάζεται το DSpark;

Εξαρτάται από checkpoint και format. Οι δημοσιευμένοι drafters έχουν 295,7 ή 327,7 εκατομμύρια παραμέτρους, άρα χρειάζονται πρόσθετη μνήμη πέρα από το target model.

Ποια runtimes υποστηρίζουν τα LFM2.5-DSpark checkpoints;

Η Liquid AI τεκμηριώνει SGLang για GPU serving και llama.cpp με Metal για on-device χρήση, με κατάλληλα builds που υποστηρίζουν DSpark και LFM2 targets.

Γιατί το 8B-A1B κέρδισε λιγότερο στο M4 Max;

Η Liquid AI αποδίδει το μέσο 1,18× στην τρέχουσα MoE υλοποίηση του Metal backend και στην επιπλέον κίνηση βαρών όταν η επαλήθευση ενεργοποιεί περισσότερους experts.

Ποια είναι η σημαντικότερη μέτρηση σε ένα pilot;

Η end-to-end latency των πραγματικών workflows, μαζί με p95, acceptance ανά εργασία, μνήμη, concurrency, ποιότητα εξόδου και συμπεριφορά fallback. Τα tokens ανά δευτερόλεπτο δεν αρκούν μόνα τους.

Ενημερωτικό Δελτίο

Εισάγετε τη διεύθυνση email σας παρακάτω για να εγγραφείτε στο ενημερωτικό δελτίο μας