Με πάνω από 20 χρόνια εμπειρίας, μεταμορφώνουμε την ψηφιακή σας παρουσία. Εξειδικευόμαστε στην κατασκευή ιστοσελίδων και E-Shop, το SEO και το Digital Marketing, τα ERP λογισμικά και τους έξυπνους αυτοματισμούς που απογειώνουν την επιχείρησή σας.
Διεύθυνση:
Εγνατία 154, Θεσσαλονίκη 546 36
Τηλέφωνο:
+30 231 231 4095
E-mail:
[email protected]
Έτοιμοι για το επόμενο βήμα;
Τα masked diffusion LLMs αποκαλύπτουν πολλά tokens παράλληλα, αλλά το serving τους χρειάζεται profiling CPU, GPU, batching και generation budgets.
Απάντηση πρώτα: στο μετρημένο masked diffusion LLM serving, η H200 δεν ήταν το κύριο όριο. Μόλις το 24,4% του συνολικού χρόνου ήταν GPU kernel execution, ενώ το 75,6% καταναλώθηκε στον CPU-side control loop και στο dispatch.
Τα masked diffusion LLMs αποκαλύπτουν πολλά tokens παράλληλα, αλλά το serving τους χρειάζεται profiling CPU, GPU, batching και generation budgets.
Η παράλληλη αποκάλυψη tokens δεν εγγυάται από μόνη της υψηλό throughput: αν ο host δεν προλαβαίνει να οργανώσει τα denoising steps, η ακριβή GPU περιμένει.
Η εργασία Serving Masked Diffusion LLMs: Characterization and Design Principles from Real Hardware των Farhana Amin, Sabiha Afroz, Mona Moghadampanah και Dimitrios S. Nikolopoulos εξετάζει ακριβώς αυτό το serving workload. Χρησιμοποιεί LLaDA-8B-Instruct με D2F LoRA adapter, τα benchmarks GSM8K και HumanEval και μετρήσεις σε μία NVIDIA H200.
Το επιχειρησιακό συμπέρασμα δεν είναι ότι η GPU παύει να έχει σημασία. Είναι ότι ένα capacity plan για νέα αρχιτεκτονική παραγωγής δεν μπορεί να βασιστεί μόνο σε FLOPS, VRAM ή μέσο latency. Χρειάζεται profiling ολόκληρης της διαδρομής, generation budgets που δεν κόβουν τεχνητά τις απαντήσεις και batching policy προσαρμοσμένη στο computational pattern του μοντέλου.
Ένα autoregressive μοντέλο παράγει το επόμενο token με βάση όσα έχουν προηγηθεί. Ένα masked diffusion LLM ξεκινά με καλυμμένες θέσεις και τις αποκαλύπτει σταδιακά μέσα από denoising steps. Στην υλοποίηση D2F της μελέτης, η παραγωγή οργανώνεται σε blocks. Νέο block αρχίζει μόνο όταν το προηγούμενο περάσει ένα καθορισμένο όριο ολοκλήρωσης.
Η διαφορά αυτή αλλάζει το σχήμα του computational work και, επομένως, το πώς πρέπει να γίνονται batching, admission και eviction. Οι συγγραφείς δεν παρουσιάζουν έναν ολοκληρωμένο ανταγωνιστικό inference engine. Πρώτα χαρτογραφούν πόσο μεταβάλλεται το κόστος ανά request, αν η δυσκολία προβλέπεται πριν αρχίσει η παραγωγή, πόσο παραμορφώνει το generation budget τις μετρήσεις και πού καταναλώνεται πραγματικά ο χρόνος.
Η αρχή ισχύει πέρα από το συγκεκριμένο paper. Όπως δείχνει και η ανάλυση για το γρήγορο GPU kernel μέσα στο πραγματικό μοντέλο, ένα τοπικό microbenchmark δεν αρκεί όταν ο end-to-end χρόνος καθορίζεται από ολόκληρο το serving stack.
Σε 100 requests του GSM8K, με thresholds τadd=0,5 και τdecode=0,9, ο αριθμός των denoising steps πήρε ακριβώς 11 τιμές: από 178 έως 468, με απόσταση 29 steps μεταξύ διαδοχικών επιπέδων. Το μοτίβο προκύπτει από τον κανόνα προσθήκης blocks και όχι από τυχαίο θόρυβο.
Το step count προέβλεψε σχεδόν τέλεια το end-to-end latency στο συγκεκριμένο πείραμα: r=0,9997 και R²=0,9994. Θεωρητικά, αν το σύστημα γνώριζε από την είσοδο σε ποιο επίπεδο θα καταλήξει ένα request, ο scheduler θα επέλεγε ανάμεσα σε 11 γνωστές εκβάσεις αντί να εκτιμά έναν συνεχόμενο χρόνο υπηρεσίας. Η πληροφορία αυτή, όμως, δεν ήταν διαθέσιμη πριν ξεδιπλωθεί η διαδικασία denoising.
Η διακύμανση ήταν ουσιαστική. Στο GSM8K με ceiling 512 tokens, η μελέτη μέτρησε coefficient of variation 0,272 και λόγο μέγιστου προς ελάχιστο latency 2,64×. Οι συγγραφείς αναφέρουν CV από 0,256 έως 0,283 σε διαφορετικά measurement passes με n=100 και τις κρατούν χωριστές αντί να τις συγχωνεύσουν τεχνητά.
LLaDA-8B-Instruct + D2F · μία H200
Τα τέσσερα μεγέθη που αλλάζουν το capacity plan
Κάθε τιμή αφορά το συγκεκριμένο πειραματικό setup και δεν αποτελεί γενικό benchmark για όλα τα diffusion LLMs.
Η ομάδα δοκίμασε τέσσερα φθηνά signals που είναι διαθέσιμα μετά το πρώτο denoising step: το ποσοστό tokens πάνω από το confidence threshold, το μέσο token confidence, το output entropy και το prompt length. Τα R² ως προς το τελικό difficulty level ήταν αντίστοιχα 0,011, 0,004, 0,023 και 0,150. Όλα έμειναν πολύ κάτω από το πρακτικό κατώφλι 0,5 που έθεσαν οι συγγραφείς.
Η εξήγηση είναι δομική. Μετά το πρώτο step, και οι 32 θέσεις του πρώτου block παραμένουν masked ανεξάρτητα από τη δυσκολία του προβλήματος. Ένα πολύ πρώιμο signal αντανακλά κυρίως τη γενική prior συμπεριφορά του μοντέλου και όχι τη συγκεκριμένη διαδρομή που θα ακολουθήσει το request. Η δυσκολία αναδύεται μέσα στη διαδρομή denoising.
Για product και operations teams αυτό αποκλείει μια δελεαστική αλλά μη τεκμηριωμένη συντόμευση: ένα σύντομο prompt δεν είναι κατ’ ανάγκη φθηνό και ένα γρήγορο confidence check δεν προβλέπει αξιόπιστα τον χρόνο ολοκλήρωσης. Το routing χρειάζεται evidence από το συγκεκριμένο model, task και engine, όπως ακριβώς χρειάζεται ξεχωριστή μέτρηση και το LLM routing με επίγνωση latency, accuracy και κόστους.
Η μελέτη επανέλαβε το GSM8K με budgets 128, 256, 512 και 1024 tokens, χρησιμοποιώντας 100 requests ανά budget σε single-request inference. Στα 128 tokens, το 100% των απαντήσεων κόπηκε από το όριο και η accuracy ήταν 6%. Στα 256 tokens, το truncation παρέμενε 83% και η accuracy έφτασε 48%. Στα 512 tokens, το truncation υποχώρησε σε 3% και η accuracy ήταν 76%, ενώ στα 1024 tokens οι αντίστοιχες τιμές ήταν 1% και 73%.
Το workload χρειαζόταν περίπου 320 tokens κατά μέσο όρο για να ολοκληρώσει ένα GSM8K πρόβλημα: 317,4 tokens στη δοκιμή με όριο 512 και 323,5 με όριο 1024. Παρ’ όλα αυτά, το latency CV συνέχισε να ανεβαίνει από 0,283 στα 512 tokens σε 0,360 στα 1024. Τα P50/P90/P99 ήταν 6,46/9,72/11,48 δευτερόλεπτα στα 512 και 6,41/9,05/10,66 στα 1024.
Το συμπέρασμα δεν είναι ότι μεγαλύτερο budget είναι πάντα καλύτερο. Είναι ότι ένα benchmark κάτω από το φυσικό completion length μετρά κυρίως τη συμπεριφορά truncation και όχι το πραγματικό serving workload. Μια ομάδα που συγκρίνει providers ή architectures με μικρά caps μπορεί να εμφανίσει χαμηλό variance απλώς επειδή κόβει τις δύσκολες απαντήσεις πριν φανεί η διαφορά.
Για να ελέγξουν αν το εύρημα περιορίζεται στα μαθηματικά προβλήματα, οι ερευνητές επανέλαβαν block-size sweep και variance characterization σε 64 HumanEval code-completion problems. Μέσα στο ίδιο request, το latency έμεινε σχεδόν σταθερό για block sizes 16, 32, 64 και 128, με CV 0,0096. Μεταξύ διαφορετικών requests, το CV ήταν 0,345. Η απόσταση ήταν περίπου 36×, πολύ κοντά στο αντίστοιχο 36× του GSM8K, όπου οι τιμές ήταν 0,0073 και 0,260.
Το HumanEval είχε μεγαλύτερη διακύμανση: CV 0,343-0,346 έναντι 0,256-0,263 στο GSM8K, και max-to-min ratio 3,99-4,09× έναντι 2,60-2,70×. Το prompt length είχε ισχυρότερη συσχέτιση με τη δυσκολία στο HumanEval, r=0,648 και R²=0,42, αλλά και πάλι δεν έφτασε το πρακτικό κατώφλι πρόβλεψης της μελέτης.
Οι ίδιοι οι συγγραφείς χαρακτηρίζουν τη συμφωνία συνεπή αλλά περιορισμένη και όχι καθολική απόδειξη. Η σωστή επιχειρηματική ανάγνωση είναι αντίστοιχα προσεκτική: το pattern αξίζει να επαληθευτεί σε διαφορετικά tasks, models και hardware πριν μετατραπεί σε production policy.
Στο synchronized batching, όλα τα requests ενός batch προσαρμόζονται σε κοινό shape και προχωρούν με ένα shared forward pass σε κάθε denoising step. Μετά το pass, κάθε request συνεχίζει να κάνει sampling με το δικό του stream. Η μελέτη το συγκρίνει με per-request dispatch, όπου κάθε request εκτελεί ανεξάρτητο forward pass σε κάθε step.
Στο batch size 16, το synchronized batching έφτασε 1,939 requests ανά δευτερόλεπτο έναντι 0,121 requests ανά δευτερόλεπτο στο single-request throughput: βελτίωση 16,0×. Το πρόσθετο overhead του per-request dispatch ακολούθησε στενά το batch size: 2,4× στο B=2, 5,1× στο B=4 και 8,1× στο B=8. Για B requests, η ανεξάρτητη εκτέλεση πληρώνει B forward passes ανά denoising step, ενώ η κοινή εκτέλεση πληρώνει ένα.
Το ίδιο batch, διαφορετική μονάδα παραλληλισμού
Το κέρδος έρχεται από την κοινή εργασία ανά denoising step
Η μελέτη απομονώνει τον dispatch μηχανισμό· δεν συγκρίνει έναν ολοκληρωμένο νέο engine με όλα τα production features του vLLM ή του Orca.
Per-request dispatch
Κάθε ενεργό request πληρώνει δικό του forward pass σε κάθε step, οπότε το host overhead αυξάνεται σχεδόν μαζί με το batch size.
Synchronized batch
Τα requests μοιράζονται ένα forward pass ανά step και αποσβένουν το σταθερό κόστος του control loop σε όλο το batch.
Slot-based design
Η προτεινόμενη επόμενη κατεύθυνση κρατά σταθερά GPU slots και γεμίζει άμεσα ένα slot όταν ολοκληρώνεται το request του· παραμένει future work.
Οι συγγραφείς διευκρινίζουν ότι το baseline δεν είναι το ίδιο με continuous batching σε vLLM ή Orca, όπου ήδη μοιράζεται forward pass ανάμεσα στα ενεργά requests κάθε iteration. Η σύγκριση απομονώνει το CPU dispatch overhead. Για τη σωστή ανάγνωση των inference trade-offs βοηθά και η ανάλυση για το vLLM και το native-speed AI inference.
Σε profiling ενός request με budget 512 tokens, η πλήρης παραγωγή διήρκεσε 10,28 δευτερόλεπτα. Από αυτά, 2,511 δευτερόλεπτα ή 24,4% ήταν GPU kernel execution. Τα υπόλοιπα 7,77 δευτερόλεπτα ή 75,6% αποδόθηκαν στον CPU-side control loop: παρακολούθηση κατάστασης blocks, κατασκευή attention masks, έλεγχος thresholds και συγχρονισμός μεταξύ forward passes.
Αυτό μεταφέρει την προτεραιότητα βελτιστοποίησης. Το batching δεν βοηθά κυρίως επειδή «γεμίζει» καλύτερα την GPU με τον κλασικό τρόπο των AR workloads. Βοηθά επειδή μοιράζει το σταθερό κόστος του control loop σε πολλά requests. Η παρατήρηση συνδέεται με tightly coupled CPU-GPU υποδομές, όπως GH200-class superchips, και με τεχνικές dispatch elimination όπως CUDA Graphs. Πρόκειται για κατεύθυνση που προκύπτει από τη μέτρηση, όχι για μετρημένη σύγκριση διαφορετικού hardware στο paper.
Σε micro-experiment, η σύλληψη ενός forward-pass call με torch.cuda.CUDAGraph μείωσε το CPU dispatch time από 19,4 ms σε 10,0 ms, δηλαδή κατά 48,6%, με μέγιστη απόλυτη διαφορά logits 0,0. Το profiled request είχε 235 forward-pass calls. Αν παρόμοια εξοικονόμηση ίσχυε σε όλα τα διαφορετικά KV-cache shapes, η προβολή της ομάδας είναι αφαίρεση 2,22 δευτερολέπτων, δηλαδή 28,5% του συνολικού dispatch overhead.
Η δεύτερη εκτίμηση είναι extrapolation και όχι end-to-end CUDA Graph measurement. Το υπόλοιπο 71,5% βρίσκεται έξω από το forward call, στον Python control flow. Η επίσημη τεκμηρίωση της NVIDIA εξηγεί γιατί τα CUDA Graphs μειώνουν επαναλαμβανόμενο CPU launch cost, αλλά και γιατί ωφελούν μόνο όταν συλλαμβάνεται το πραγματικό CPU-bound τμήμα.
Στο single-request GSM8K με generation length 512, μία δοκιμή έδωσε exact-match accuracy 74% και μια ξεχωριστή δοκιμή 76%. Οι συγγραφείς αποδίδουν τη διαφορά στο stochastic sampling με temperature μεγαλύτερο από μηδέν. Από τις 24 λανθασμένες απαντήσεις στη δοκιμή 74%, μόνο δύο έφτασαν στο όριο των 512 tokens, άρα το truncation ήταν μικρός και όχι ο κύριος παράγοντας σφάλματος σε εκείνο το run.
Για το synchronized batching, το paper δεν ολοκλήρωσε άμεση empirical quality evaluation στα batch sizes 8 και 16. Αντί γι’ αυτό δίνει δομικό επιχείρημα που απαιτεί τρεις προϋποθέσεις: attention mask και positional encoding κάθε request να παραμένουν ίδια κάτω από padding, κάθε request να έχει ανεξάρτητο RNG stream και οι batched attention/sampling kernels να είναι αριθμητικά ισοδύναμοι με τις single-request εκδόσεις.
Επειδή η εμπειρική επιβεβαίωση λείπει, μια production ομάδα δεν πρέπει να μετατρέψει αυτή την υπόθεση σε εγγύηση. Throughput regression tests και quality regression tests είναι δύο ξεχωριστές πύλες έκδοσης.
Το fixed-fill synchronized batching δημιουργεί ένα trade-off: μεγάλη αναμονή γεμίζει το batch αλλά αυξάνει το latency, ενώ πρόωρη αποστολή δημιουργεί underfull batches που κοστίζουν ένα πλήρες forward pass. Η ανάλυση χρησιμοποιεί B=8, μέσο measured service time S=8,74 δευτερόλεπτα από οκτώ batches και Poisson arrivals. Η full-batch capacity είναι περίπου 0,915 requests ανά δευτερόλεπτο.
Η προσομοίωση 20.000 requests έδειξε U-shaped mean latency ως προς το utilization ρ, με χαμηλότερο μέσο latency κοντά στο ρ≈0,70. Σε χαμηλό load κυριαρχεί το batch-fill delay, με μέση αναμονή (B-1)/(2λ), δηλαδή 3,5/λ όταν B=8. Σε υψηλό load κυριαρχεί η αναμονή πίσω από προηγούμενα batches.
Για sparse arrivals, οι συγγραφείς προσεγγίζουν το expected batch size ως 1+λT. Από τη συνθήκη σταθερότητας προκύπτει ο κανόνας Tmin=S-1/λ. Δεν είναι universal constant: εξαρτάται από arrival rate και measured service time του συγκεκριμένου συστήματος. Μεταγενέστερο sample 32 batches άλλαξε την εκτιμώμενη capacity κατά περίπου 24%, άρα τα percentiles και η βαθμονόμηση χρειάζονται μεγαλύτερο δείγμα πριν χρησιμοποιηθούν ως τελική production πολιτική.
Πρώτον, το benchmark πρέπει να επιτρέπει στο task να ολοκληρώνεται φυσικά. Διαφορετικά, το χαμηλό latency και το χαμηλό variance μπορεί να είναι αποτέλεσμα truncation. Δεύτερον, η παρακολούθηση μόνο GPU utilization δεν εξηγεί ένα host-side bottleneck. Χρειάζεται διάκριση ανάμεσα σε wall-clock time, kernel time, control-loop time και dispatch overhead.
Τρίτον, το batching policy δεν είναι μόνο παράμετρος throughput. Επηρεάζει queue stability και tail latency, ενώ η ορθότητα της ποιότητας απαιτεί ξεχωριστή επαλήθευση. Τέταρτον, schedulers βασισμένοι σε prompt length ή σε πολύ πρώιμο confidence χρειάζονται μέτρηση στο συγκεκριμένο model και task. Πέμπτον, οι σχεδιαστικές επιλογές των AR inference engines δεν πρέπει να θεωρούνται αυτόματα βέλτιστες για masked diffusion.
Για e-commerce, marketing automation ή customer-experience workloads, η επίπτωση είναι λειτουργική. Αν ένα σύστημα δημιουργεί πολλές περιγραφές προϊόντων, απαντήσεις υποστήριξης ή παραλλαγές περιεχομένου ταυτόχρονα, η πραγματική χωρητικότητα θα εξαρτηθεί από το πώς μοιράζονται τα steps και όχι μόνο από το μέγεθος του μοντέλου. Όπως και στο κόστος του LLM serving με GPUs και KV cache, το σωστό capacity plan χρειάζεται τις πραγματικές distributions των requests και όχι ένα demo average.
Production gate
Αγοράστε compute μόνο αφού μετρήσετε το bottleneck της πλήρους διαδρομής
Αν ο host control loop κρατά την GPU ανενεργή, περισσότερη accelerator χωρητικότητα δεν λύνει μόνη της το serving πρόβλημα. Προηγούνται trace, representative load, quality checks και queue model.
Επτά έλεγχοι πριν από production rollout
Χρησιμοποιήστε πραγματικές κατανομές prompt, task και output length αντί για λίγα ομοιόμορφα demo prompts.
Επιλέξτε generation budget που επιτρέπει στο task να ολοκληρώνεται και καταγράψτε χωριστά το ποσοστό κομμένων απαντήσεων.
Μετρήστε wall-clock, kernel execution, dispatch, mask construction, synchronization και control-loop time στο ίδιο trace.
Ελέγξτε single-request, per-request dispatch και shared-step batching με ίδιο model, thresholds και quality protocol.
Τρέξτε repeated trials με ανεξάρτητα RNG streams και ελέγξτε numerical equivalence πριν θεωρήσετε ασφαλές το throughput gain.
Χρησιμοποιήστε αρκετά measured batches, arrival distributions και tail-latency στόχους αντί για έναν γενικό timeout.
Ορίστε πότε το σύστημα μειώνει batch size, επιστρέφει σε ασφαλές baseline ή ζητά ανθρώπινη παρέμβαση όταν quality ή queue stability αποκλίνουν.
Η οικονομική αξιολόγηση πρέπει επίσης να συνδέει το infrastructure metric με την εργασία που ολοκληρώνεται. Το AI ROI δεν κρίνεται μόνο από tokens, αλλά από το κόστος και την ποιότητα κάθε ολοκληρωμένου business outcome.
Η έρευνα καλύπτει μία οικογένεια αρχιτεκτονικής, LLaDA base και D2F, και μία GPU, την H200. Το task generalization και το configuration generalization εξετάστηκαν χωριστά, όχι μαζί. Δεν έγινε άμεση σύγκριση με υπάρχοντα dLLM inference engines όπως το dInfer. Η δομή των 11 tiers με τύπο 178+29k μετρήθηκε σε ένα μόνο ζεύγος thresholds και μπορεί να είναι ειδική για αυτή τη ρύθμιση.
Αρκετά αποτελέσματα προέρχονται από single runs χωρίς repeated trials. Η scheduling simulation ξεκίνησε από μόλις οκτώ measured batches, ενώ ένα μεταγενέστερο run 32 batches μετακίνησε την capacity κατά 24%. Το slot-based design δεν ολοκληρώθηκε σε πλήρως σωστή υλοποίηση και η ποιότητα σε batch sizes 8 και 16 δεν επαληθεύτηκε εμπειρικά.
Οι περιορισμοί δεν ακυρώνουν τα ευρήματα· καθορίζουν πού τελειώνει η μέτρηση και πού αρχίζει η σχεδιαστική υπόθεση. Το ισχυρότερο συμπέρασμα είναι μεθοδολογικό: το serving ενός νέου μοντέλου πρέπει να χαρακτηρίζεται πάνω σε πραγματικό hardware, με budgets που δεν παραμορφώνουν το task, με profiling host και accelerator και με σαφή διάκριση ανάμεσα σε measured result, analytical rule και future design.
AI υποδομή με μετρήσιμο capacity
Σχεδιάστε το serving γύρω από το πραγματικό workload της επιχείρησης
Η TWO DOTS χαρτογραφεί requests, model calls, latency, batching, monitoring, κόστος και fallback ώστε ένα AI workflow να αξιοποιεί σωστά CPU, GPU και διαθέσιμο budget.
Συχνές ερωτήσεις
Είναι γλωσσικό μοντέλο που παράγει κείμενο αποκαλύπτοντας σταδιακά masked θέσεις μέσω denoising steps, αντί να προσθέτει αυστηρά ένα token κάθε φορά όπως ένα autoregressive μοντέλο.
Στο συγκεκριμένο D2F setup, ο κανόνας προσθήκης blocks και τα thresholds οδήγησαν σε step counts από 178 έως 468 ανά 29 steps. Οι συγκεκριμένες σταθερές πιθανότατα εξαρτώνται από τη ρύθμιση.
Όχι αξιόπιστα με τα τέσσερα signals που δοκιμάστηκαν. Η καλύτερη τιμή ήταν R²=0,150 για prompt length στο GSM8K, κάτω από το πρακτικό κατώφλι 0,5 της μελέτης.
Στα 128 και 256 tokens κόπηκε αντίστοιχα το 100% και το 83% των requests. Το benchmark μέτρησε κυρίως truncation και έκρυψε το φυσικό latency variance του workload.
Στο batch size 16, το synchronized batching μοιράστηκε ένα forward pass ανά denoising step για όλο το batch και έφτασε 1,939 requests/s έναντι 0,121 requests/s στο single-request baseline.
Όχι. Σημαίνει ότι στο μετρημένο setup το άμεσο bottleneck ήταν κυρίως ο CPU-side control loop. Άλλα models, engines και hardware μπορούν να έχουν διαφορετικό breakdown.
Όχι πλήρως. Το paper παρέχει δομικό επιχείρημα με τρεις προϋποθέσεις, αλλά δεν ολοκλήρωσε άμεση quality evaluation στα batch sizes 8 και 16.
Να μετράτε το πραγματικό workload στο πραγματικό hardware, να αποφεύγετε truncation-biased benchmarks και να σχεδιάζετε batching και scheduling σύμφωνα με το computational pattern του μοντέλου.
Πηγές
