MoE μοντέλα στην άκρη: γιατί η cache δεν λύνει μόνη της το bandwidth bottleneck

Πώς η αραιή ενεργοποίηση συναντά το bandwidth wall

Σε ένα Mixture-of-Experts μοντέλο, κάθε layer περιέχει πολλούς εξειδικευμένους feed-forward experts και ένας router επιλέγει μικρό υποσύνολο για κάθε token. Η συνολική χωρητικότητα μπορεί έτσι να είναι πολύ μεγάλη, ενώ το ενεργό υπολογιστικό φορτίο παραμένει μικρότερο. Το Qwen3-235B-A22B, για παράδειγμα, αποθηκεύει 235 δισ. παραμέτρους και ενεργοποιεί περίπου 22 δισ. ανά token.

Αυτό το sparsity κάνει ένα μεγάλο open-weight μοντέλο θεωρητικά εκτελέσιμο έξω από data center, αλλά δεν σημαίνει ότι όλα τα βάρη χωρούν στη γρήγορη μνήμη. Αν οι experts που χρειάζεται το επόμενο token βρίσκονται σε RAM ή SSD, πρέπει να μεταφερθούν πριν χρησιμοποιηθούν. Στο autoregressive decode η πράξη επαναλαμβάνεται token προς token, οπότε η απόδοση μπορεί να καθορίζεται περισσότερο από το memory bandwidth παρά από τα διαθέσιμα FLOPs.

Η κρίσιμη διάκριση είναι ανάμεσα στο model fit και στο usable throughput. Το πρώτο απαντά αν το μοντέλο φορτώνεται και παράγει έξοδο. Το δεύτερο αν η έξοδος φτάνει αρκετά γρήγορα για chatbot, copilot, παραγωγή περιεχομένου ή άλλη πραγματική ροή. Η ίδια λογική εμφανίζεται και στην εξισορρόπηση experts στα MoE συστήματα: το routing, η μνήμη και το serving engine είναι εξίσου σημαντικά με το όνομα του μοντέλου.

Τι μέτρησε το πείραμα σε consumer hardware

Η μελέτη χρησιμοποίησε desktop με Intel i9-12900, RTX 3070 8 GB, 32 GB DDR4 RAM και WD SN530 NVMe. Το Qwen3-235B-A22B σε Q4_K_M GGUF καταλάμβανε 134 GB. Περίπου 40 GB μπορούσαν να τοποθετηθούν στα γρηγορότερα επίπεδα VRAM και RAM, ενώ το υπόλοιπο έμενε στον SSD.

Κάθε token ενεργοποιούσε περίπου 22 δισ. παραμέτρους, που αντιστοιχούσαν σε περίπου 12 GB αναγνώσεων τετραμπιτων expert weights. Το warm single-stream decode μετρήθηκε στα 0,441 token ανά δευτερόλεπτο. Ο ρυθμός συμφωνούσε με το διαθέσιμο I/O και με το απλό μοντέλο throughput = bandwidth / bytes ανά token.

Για στόχο 10 token ανά δευτερόλεπτο με 12 GB expert reads ανά token, ο υπολογισμός απαιτεί περίπου 120 GB/s συνεχούς μεταφοράς προς τα βάρη. Ο SSD έδινε 2,4 GB/s: ένα κενό 50×. Η εκτίμηση δεν αποδεικνύει ότι κάθε σύστημα θα έχει ίδια ταχύτητα· δείχνει γιατί μια μικρή ρύθμιση λογισμικού δεν μπορεί να ακυρώσει το φυσικό όριο αυτού του hardware.

Γιατί το batching κατέρρευσε αντί να επιταχύνει

Το batching θα μπορούσε θεωρητικά να μοιράσει μία ανάγνωση experts σε πολλές παράλληλες ροές. Το μοντέλο πρόβλεψης της μελέτης ταίριαξε με τις μετρήσεις για batch 1 και 8, όπου η aggregate απόδοση έφτασε αντίστοιχα 0,128 και 0,189 token ανά δευτερόλεπτο. Στο batch 32, όμως, αντί για την προβλεπόμενη άνοδο στα 0,35 token ανά δευτερόλεπτο, η μέτρηση έπεσε στα 0,087.

Η αιτία αποδόθηκε σε paging thrash. Οι 32 ταυτόχρονες ροές δημιούργησαν καταιγισμό page faults και το λειτουργικό σύστημα έχασε την αποδοτική σειριακή πρόσβαση στον δίσκο. Το αποτέλεσμα δεν ακυρώνει την ιδέα ενός shared disk sweep. Δείχνει ότι το συγκεκριμένο llama.cpp setup δεν μπορούσε να την εκφράσει αποδοτικά πάνω από περίπου batch 8 και ότι ένας purpose-built sequential-sweep engine θα ήταν διαφορετικό πείραμα.

Τι αποκάλυψε το llama-moe-trace για το routing

Για να επιλεγεί τι θα μείνει στην cache, χρειάζεται πρώτα πραγματικό routing profile. Ο συγγραφέας πρόσθεσε στο evaluation callback του llama.cpp το llama-moe-trace, ένα εργαλείο που καταγράφει τις top-k επιλογές του router χωρίς να αλλάζει τα βάρη. Κατέγραψε Qwen3-30B-A3B σε 8.000 tokens για καθεμία από τέσσερις κατηγορίες: πεζό λόγο, κώδικα, μαθηματικά και ιατρικό κείμενο.

Η πιθανότητα επαναχρησιμοποίησης expert στο επόμενο token ήταν 0,444, έναντι τυχαίας πιθανότητας 0,223. Το 95% της κίνησης περνούσε από το 52,5% των experts. Το code workload είχε μικρή επικάλυψη με τα άλλα domains, ενώ general prose, μαθηματικά και ιατρικό κείμενο εμφάνιζαν μεγαλύτερη μεταξύ τους ομοιότητα. Άρα μία ενιαία cache policy μπορεί να αποδίδει διαφορετικά όταν αλλάζει το μίγμα εργασιών.

Η τεχνική ιστορία του tracer είναι επίσης σημαντική για το E-E-A-T της μελέτης. Μια πρώτη υλοποίηση αντέγραψε λανθασμένα ένα μη συνεχόμενο tensor view και έδωσε ομοιόμορφα αλλά άχρηστα δεδομένα. Οι ανωμαλίες εντοπίστηκαν, η αντιγραφή διορθώθηκε ώστε να σέβεται τα strides και το αρχικό run απορρίφθηκε στο δημόσιο corrections record.

Πόσο βοηθούν η LRU cache και το Path-Mapped Serving

Στο replay των traces, ανά-layer LRU cache που χωρούσε το 13,4% των experts εξυπηρετούσε το 65,9% των expert requests. Στο ίδιο budget, το static pinning έφτασε 59,2%, η LFU 60,1% και ο μη υλοποιήσιμος clairvoyant Belady oracle 79,1%. Η LRU κέρδισε επειδή αξιοποίησε τη χρονική τοπικότητα και όχι μόνο τη συνολική δημοτικότητα κάθε expert.

Η συγκεκριμένη cache αφορά expert weights και δεν πρέπει να συγχέεται με prompt caching ή KV cache. Το prompt cache αποφεύγει επανάληψη υπολογισμού για κοινό prefix, ενώ η KV cache αποθηκεύει ενδιάμεσες καταστάσεις attention για το υπάρχον context. Εδώ το πρόβλημα βρίσκεται στην ανάκτηση των ενεργών feed-forward experts από διαφορετικά memory tiers σε κάθε νέο token. Μια εφαρμογή μπορεί επομένως να έχει αποτελεσματικό prefix cache και να εξακολουθεί να σκοντάφτει στο expert-weight bandwidth.

Το προτεινόμενο Path-Mapped Serving κρατά τους θερμούς experts στη γρήγορη μνήμη και φορτώνει από τον δίσκο μόνο τα misses, χωρίς να αλλάζει τα weights. Με προβολή στο Qwen3-235B, 18 GB fast-memory budget και το μετρημένο I/O, η miss traffic εκτιμήθηκε περίπου στα 2,7 GB ανά token και η single-stream απόδοση περίπου στα 0,9 token ανά δευτερόλεπτο. Η βελτίωση δύο έως επτά φορές είναι χρήσιμη, αλλά εξακολουθεί να απέχει από interactive ρυθμό.

Για 10 token ανά δευτερόλεπτο, η προβολή απαιτεί περίπου 95% cache hit rate, που αντιστοιχεί σε περίπου 70 GB resident experts — περίπου τέσσερις φορές το fast-memory budget του πειράματος. Εδώ φαίνεται γιατί η απόφαση για self-hosted open-weight AI δεν πρέπει να ξεκινά από το αν κατεβαίνουν τα weights, αλλά από capacity, latency, ενέργεια, monitoring και λειτουργική ευθύνη.

Γιατί η cache-aware εκπαίδευση δεν πέρασε το όριο ποιότητας

Η μελέτη προεγγράφηκε: υποθέσεις, metrics και όρια επιτυχίας καθορίστηκαν πριν από τα κύρια runs. Εκπαιδεύτηκαν MoE μοντέλα 137 εκατ. παραμέτρων με 16 experts και top-2 routing σε 300 εκατ. tokens από WikiText-103, codeparrot-clean και OpenWebMath. Δοκιμάστηκαν temporal-locality loss, που επιβραβεύει παρόμοιο routing σε διαδοχικά tokens, και domain-confinement loss, που περιορίζει κάθε domain σε προκαθορισμένο slice experts.

Το locality κριτήριο ζητούσε τουλάχιστον 30% μείωση cache misses και αύξηση perplexity έως 1%. Σε χαμηλό βάρος, η αύξηση perplexity ήταν 0,3%, αλλά η μείωση misses μόλις 15%. Σε υψηλότερο βάρος, τα misses μειώθηκαν 59% έως 60% σε δύο seeds, όμως το perplexity αυξήθηκε 2,1% έως 3,1%. Η domain εκδοχή έφτασε static-pin hit rate 99,1%, αλλά με αύξηση perplexity 3,1%, πάνω από το όριο 2%.

Το αποτέλεσμα είναι αρνητικό μόνο ως προς το κοινό, προεγγεγραμμένο όριο. Η cacheability όντως βελτιώθηκε, αλλά δεν ήταν δωρεάν στο συγκεκριμένο multi-domain scale. Το paper αντιπαραβάλλει προσεκτικά το StickyMoE, που μελέτησε μικρότερα single-domain μοντέλα. Τα δύο πειράματα δεν δικαιολογούν καθολική ετυμηγορία· δείχνουν ότι corpus, μέγεθος, budget και κριτήριο ποιότητας αλλάζουν το trade-off.

Ο συνδυασμός training και rerouting

Η πιο υποσχόμενη κατεύθυνση προέκυψε όταν η εκπαιδευμένη locality συνδυάστηκε με training-free cache-aware rerouting στο inference. Αν ο κορυφαίος expert δεν βρισκόταν στην cache, το σύστημα μπορούσε να επιλέξει cached expert μόνο όταν το router score του ήταν μέσα σε προκαθορισμένη σχετική ανοχή.

Πάνω στο baseline, το έντονο rerouting υποβάθμιζε γρήγορα την ποιότητα. Πάνω στο locality-trained μοντέλο, η ίδια παρέμβαση είχε μικρότερο οριακό κόστος. Στα μοντέλα των 137 εκατ. παραμέτρων, η training-time locality έδινε 58% έως 61% μείωση misses με 1,4% έως 2,2% αύξηση perplexity. Με το πρόσθετο rerouting, η μείωση έφτανε 80% έως 82% με συνολικό κόστος 1,9% έως 3,1%. Στο rung των 340 εκατ. παραμέτρων, το stacking έφτασε 82% μείωση misses με αύξηση perplexity 3,4%.

Αυτά είναι αποτελέσματα των συγκεκριμένων checkpoints και όχι εγγύηση για production Qwen3. Η αρχιτεκτονική ιδέα όμως είναι χρήσιμη: training objective, router, cache policy και serving engine μπορούν να συν-σχεδιαστούν, αντί κάθε επίπεδο να βελτιστοποιείται ανεξάρτητα.

Τι σημαίνει για επιχειρήσεις και ομάδες AI

Για μια επιχείρηση, το βασικό μάθημα είναι να μη συγχέει την ιδιωτική ή τοπική εκτέλεση με την έτοιμη παραγωγική λειτουργία. Ένα μοντέλο μπορεί να φορτώνεται σε desktop και να παραμένει υπερβολικά αργό για support, live content assistance ή interactive copilots. Αντίστροφα, ένα μικρότερο μοντέλο μπορεί να προσφέρει καλύτερο κόστος ανά επιτυχημένη εργασία. Για αυτό η επιλογή AI μοντέλου για επιχείρηση χρειάζεται workload-specific evaluation και όχι μόνιμο στοίχημα στο μεγαλύτερο checkpoint.

Η μέση ταχύτητα επίσης δεν αρκεί για εμπειρία χρήστη. Ένα cache hit μπορεί να είναι σχετικά γρήγορο, ενώ ένα miss να περιμένει SSD I/O και να δημιουργεί αισθητή ουρά. Για interactive ροές χρειάζονται percentiles latency, χρόνος έως το πρώτο token, ρυθμός μετά το πρώτο token και συχνότητα ακραίων καθυστερήσεων. Για batch εργασίες, αντίθετα, μπορεί να έχει μεγαλύτερη σημασία η συνολική ολοκλήρωση ανά ώρα και η ενεργειακή κατανάλωση. Το ίδιο hardware μπορεί να είναι ακατάλληλο για live chat αλλά αποδεκτό για προγραμματισμένη νυχτερινή επεξεργασία.

Το δεύτερο μάθημα είναι ότι τα averages κρύβουν domain διαφορές. Στα traces, ο κώδικας είχε σχεδόν διακριτό σύνολο experts. Στα training runs, τα penalties επίσης διέφεραν ανά domain. Αν το ίδιο σύστημα γράφει product descriptions, συνοψίζει tickets και βοηθά developers, η cache policy πρέπει να δοκιμαστεί στο πραγματικό μίγμα και στις πραγματικές μεταβάσεις μεταξύ εργασιών.

Το τρίτο μάθημα αφορά το συνολικό κόστος. Περισσότερη RAM μπορεί να μειώσει SSD I/O, αλλά αυξάνει επένδυση και ενέργεια. Rerouting μπορεί να μειώσει μεταφορές, αλλά πρέπει να περάσει quality gates. Μια rack-scale λύση μπορεί να δώσει πολύ υψηλότερο bandwidth, αλλά αλλάζει εντελώς οικονομία και λειτουργία· αυτό φαίνεται και όταν η AI υποδομή αξιολογείται σε επίπεδο πλήρους stack και όχι μεμονωμένου accelerator.

Τέλος, το local δεν σημαίνει αυτομάτως αξιόπιστο. Η διαφορά ανάμεσα στο «τρέχει» και στο «λειτουργεί σωστά» ισχύει τόσο για τεράστια MoE όσο και για μικρότερα μοντέλα που εκτελούνται τοπικά. Χρειάζονται ανεξάρτητες αξιολογήσεις, observability, fallback και σαφής ιδιοκτησία της απόφασης.

Επτά έλεγχοι πριν από pilot MoE στην άκρη

Ένα χρήσιμο pilot πρέπει να μπορεί να διαψεύσει την αρχική υπόθεση. Δεν ξεκινά από αγορά hardware, αλλά από workload, αποδεκτό αποτέλεσμα και μετρήσιμο operating point.

Περιορισμοί που δεν πρέπει να χαθούν

Η εργασία είναι arXiv v1 προδημοσίευση ενός ανεξάρτητου ερευνητή και δεν έχει περάσει peer review. Οι serving μετρήσεις έγιναν σε έναν υπολογιστή, έναν DRAM-less PCIe 3 SSD, συγκεκριμένο GGUF και συγκεκριμένη διαμόρφωση llama.cpp. Άλλο hardware, engine, kernel, filesystem ή sequential-sweep scheduler μπορεί να αλλάξει ουσιαστικά τα αποτελέσματα.

Το Path-Mapped Serving διατηρεί τα ήδη παραδομένα τετράμπιτα βάρη bit-exact και δεν προσθέτει νέα quantization ή distillation. Αυτό εξηγεί τη διατύπωση «πλήρης ακρίβεια» μέσα στο paper: σημαίνει ίδια weights με το Q4_K_M artifact που σερβίρεται, όχι ισοδυναμία με BF16 checkpoint ούτε απόδειξη ότι η αρχική τετραμπιτη έκδοση έχει μηδενική απόκλιση ποιότητας.

Τα routing traces έγιναν στο Qwen3-30B-A3B, όχι στο artifact των 235B. Τα training πειράματα έγιναν σε 137M και 340M παραμέτρους, πολύ κάτω από frontier scale, και το μεγαλύτερο rung ήταν undertrained στο matched budget. Η perplexity είναι χρήσιμο proxy, όχι πλήρης μέτρηση ποιότητας για business tasks. Επομένως, ούτε το quality tax ούτε τα hit rates πρέπει να μεταφερθούν αυτούσια σε παραγωγικό σύστημα.

Τα δημοσιευμένα hit rates και το quality tax δεν πρέπει να μεταφερθούν αυτούσια σε παραγωγικό σύστημα. Πρέπει να αντιμετωπιστούν ως υποθέσεις προς δοκιμή με ίδιο model artifact, ίδια κατανομή δεδομένων και ίδια πολιτική cache.

Η μελέτη ενισχύεται από την προεγγραφή, τον δημόσιο κώδικα, τα traces, τα seeds, τα data hashes και το corrections log. Αυτή η διαφάνεια επιτρέπει αναπαραγωγή και έλεγχο, αλλά δεν αντικαθιστά την ανεξάρτητη επικύρωση σε διαφορετικό εξοπλισμό και workload.

Η cache είναι μέρος της λύσης, όχι όλη η λύση

Η εργασία μετατρέπει μια ελκυστική υπόσχεση — «κάνε τον router πιο φιλικό στην cache» — σε ελέγξιμη υπόθεση. Η LRU αξιοποίησε πραγματική temporal locality, η cache-aware εκπαίδευση μείωσε τα misses και το rerouting πρόσθεσε όφελος. Παρ’ όλα αυτά, κανένα μεμονωμένο τέχνασμα δεν εξαφάνισε ταυτόχρονα το bandwidth wall και το κόστος ποιότητας.

Για μια επιχείρηση, η σωστή απόφαση είναι συν-σχεδιασμός μοντέλου, router, cache, memory hierarchy, serving engine και workload. Το edge ή on-premise AI αξίζει όταν η ιδιωτικότητα, το latency, ο σταθερός όγκος ή ο έλεγχος δικαιολογούν τεκμηριωμένα την υποδομή. Η απόφαση πρέπει να παραμένει αναστρέψιμη, με σαφές baseline και μετρήσεις που συνδέουν τεχνική απόδοση με πραγματική επιχειρησιακή αξία.