Η συμπίεση KV cache είναι απόφαση υποδομής, όχι συζήτηση για μοντέλα
Η συμπίεση KV cache δεν είναι πλέον θέμα ποιότητας μοντέλου. Είναι μια απόφαση αγοράς υποδομής που συνοδεύεται από ένα μαθηματικό πρόβλημα.
Το λέω ξεκάθαρα γιατί πάρα πολλές ομάδες εξακολουθούν να αντιμετωπίζουν τη μνήμη των LLM μεγάλου πλαισίου σαν αγώνα επιδόσεων: TurboQuant εναντίον OSCAR εναντίον EpiCache, διάλεξε νικητή και προχώρα. Στην πράξη, δεν αποτυγχάνουν έτσι οι υλοποιήσεις. Αποτυγχάνουν επειδή η μία ομάδα βελτιστοποιεί για bit-width, η άλλη για φορητότητα και μια τρίτη ανακαλύπτει πολύ αργά ότι το ιστορικό συνομιλίας πολλών γύρων είναι διαφορετικό πρόβλημα από ένα μεμονωμένο prompt 128K. Σύμφωνα με την περίληψη της 18ης Ιουνίου του MarkTechPost, οι τρεις προσεγγίσεις επιλύουν γειτονικά σημεία συμφόρησης, όχι το ίδιο.
Η συμπίεση KV cache γίνεται επώδυνη όταν το HBM, όχι τα FLOPs, είναι το όριό σας
Τα μαθηματικά της μνήμης είναι το κομμάτι που οι διαχειριστές δεν μπορούν να αγνοήσουν. Το παράδειγμα πηγής χρησιμοποιεί το Llama-3.1-70B σε BF16: περίπου 0,31 MB KV cache ανά token, περίπου 40 GB στα 128K tokens και πάνω από 300 GB στο 1M tokens. Αυτό είναι το σημείο όπου η cache μπορεί να ξεπεράσει τα ίδια τα βάρη του μοντέλου. Αν εξυπηρετείτε αιτήματα μεγάλου πλαισίου με ταυτόχρονη εκτέλεση, κάθε αποκωδικοποιημένο token σέρνει αυτή την cache πίσω μέσω της μνήμης υψηλού εύρους ζώνης.
Αυτή η μετατόπιση έχει μεγαλύτερη σημασία από έναν ακόμα πόντο σε πίνακα κατάταξης. Μόλις η αποκωδικοποίηση δεσμευτεί από το εύρος ζώνης, η καμπύλη κόστους σας αλλάζει. Δεν ρωτάτε πλέον, «Μπορεί αυτό το μοντέλο να απαντήσει καλά;» αλλά «Πόσες συνεδρίες μπορώ να κρατήσω ενεργές πριν η κίνηση στη μνήμη καταστρέψει την καθυστέρηση (latency);»
Σε ένα τεστ φορτίου πελάτη που έτρεξα τον περασμένο μήνα, η επιλογή του μοντέλου δεν ήταν ο κύριος περιορισμός. Η επαναχρησιμοποίηση προθεμάτων (prefix reuse) φαινόταν εξαιρετική μεμονωμένα, αλλά μόλις αυξήθηκε ο αριθμός των ταυτόχρονων συνεδριών, η καθυστέρηση ουράς (tail latency) εκτινάχθηκε επειδή η μετακίνηση μνήμης, όχι ο υπολογισμός, ήταν ο περιοριστικός παράγοντας. Γι' αυτό η εργασία βάσης 2-bit του KIVI εξακολουθεί να έχει σημασία το 2026: πλαισίωσε την κβαντοποίηση KV cache ως πρόβλημα συστημάτων συμπερασμού, όχι απλώς ως κόλπο συμπίεσης.
Το TurboQuant είναι το παιχνίδι της φορητότητας, όχι ο καθολικός νικητής
Το TurboQuant είναι εντυπωσιακό για έναν λόγο. Η Google Research και το NYU δημιούργησαν μια προσέγγιση αγνοίας δεδομένων που επιτίθεται σε κανάλια ακραίων τιμών χωρίς βαθμονόμηση. Πρώτα περιστρέφει τυχαία τα διανύσματα ώστε οι συντεταγμένες να συμπεριφέρονται περισσότερο σαν ανεξάρτητες μεταβλητές Gaussian. Στη συνέχεια, εφαρμόζει έναν προϋπολογισμένο βαθμωτό κβαντιστή και έναν μετασχηματισμό 1-bit QJL στο υπόλοιπο. Ο θεωρητικός ισχυρισμός είναι ισχυρός: η παραμόρφωση παραμένει εντός ενός μικρού σταθερού συντελεστή του κάτω ορίου.
Αυτό είναι το σωστό εργαλείο όταν σας ενδιαφέρει η φορητότητα του μοντέλου και δεν έχετε την πολυτέλεια μιας προσαρμοσμένης βαθμονόμησης για κάθε στόχο εξυπηρέτησης. Το αναφερόμενο ιδανικό σημείο είναι το εύρος 3 έως 4 bit, όπου η ποιότητα παραμένει σχεδόν χωρίς απώλειες στα workloads που τονίζει η εργασία. Αυτό καθιστά το TurboQuant ελκυστικό για ομάδες που διαχειρίζονται μικτούς στόλους ή πειραματίζονται σε πολλαπλές αρχιτεκτονικές.
Αλλά εδώ είναι το αμφιλεγόμενο σημείο: οι άνθρωποι συνεχίζουν να επαναλαμβάνουν τη λάθος υπόσχεση. Ο πιο δυνατός ισχυρισμός γύρω από το TurboQuant είναι η γραμμή «8x ταχύτερη προσοχή σε H100» από το blog post της Google Research για το TurboQuant, ωστόσο το άρθρο πηγής σημειώνει σωστά ότι αυτό αναφέρεται σε ένα στενό microbenchmark, όχι σε end-to-end εξυπηρέτηση. Έχω δει αυτό το μοτίβο ξανά με πυρήνες συμπερασμού: μια νίκη σε ένα στάδιο γίνεται επιχείρημα προμήθειας για ολόκληρη τη στοίβα. Έτσι οι ομάδες αγοράζουν απογοήτευση.
Το OSCAR έχει σημασία γιατί κάποιος έστειλε πραγματικά τα δύσκολα κομμάτια
Αν ο στόχος σας είναι η υλοποιήσιμη συμπίεση KV cache INT2, το OSCAR είναι η πρακτική ιστορία αυτή τη στιγμή. Το σύστημα της Together AI δεν προτείνει απλώς μια περιστροφή με επίγνωση της προσοχής· συσκευάζει γύρω από αυτό paging μικτής ακρίβειας, πυρήνες Triton και ενσωμάτωση SGLang. Αυτό είναι σημαντικό γιατί τα κέρδη στην παραγωγή συνήθως προέρχονται από το πακέτο, όχι από το χαρτί.
Οι λεπτομέρειες έχουν σημασία. Το OSCAR διατηρεί τα sink και πρόσφατα tokens σε BF16 ενώ συμπιέζει τα ιστορικά tokens σε INT2, αφήνοντας μόνο περίπου 0,24% των tokens ασυμπίεστα σε πλαίσιο 128K σύμφωνα με την περίληψη. Επίσης, διαθέτει προϋπολογισμένες περιστροφές για υποστηριζόμενα μοντέλα, γεγονός που αφαιρεί ένα άσχημο βήμα ανάπτυξης. Το αναφερόμενο όφελος είναι σημαντικό: έως και 7,83x throughput σε επίπεδο εργασίας, περίπου 8x μείωση μνήμης KV-cache σε πλαίσιο 100K και έως και 3x ταχύτερη αποκωδικοποίηση στις δοκιμασμένες ρυθμίσεις.
Γι' αυτό πιστεύω ότι το OSCAR κερδίζει επί του παρόντος το επιχείρημα της υλοποιησιμότητας στο άκρο των χαμηλών bit. Όχι επειδή η ιδέα είναι πιο όμορφη. Αλλά επειδή κάποιος έκλεισε το χάσμα μεταξύ της θεωρίας κβαντοποίησης και της πραγματικότητας της εξυπηρέτησης.
Το επιχείρημα για έναν νικητή head-to-head εξακολουθεί να καταρρέει
Ένα δίκαιο αντεπιχείρημα είναι ότι οι επιχειρήσεις χρειάζονται μια απλή απάντηση. Αν μια μέθοδος κερδίζει μια άλλη στην ποιότητα και το throughput των benchmarks, η επιλογή του ηγέτη μειώνει την πολυπλοκότητα. Υπάρχει λογική σε αυτό. Κάθε επιπλέον διαδρομή συμπερασμού προσθέτει overhead δοκιμών, λογική επαναφοράς, εργασία παρατηρησιμότητας και βάρος υποστήριξης. Η τυποποίηση σε μία μέθοδο είναι συχνά η λογική επιλογή λειτουργίας.
Συμφωνώ με αυτό το ένστικτο. Απλώς δεν πιστεύω ότι τα τρέχοντα στοιχεία υποστηρίζουν έναν καθολικό νικητή.
Η αναφερόμενη σύγκριση του OSCAR υποδηλώνει ότι το TurboQuant πέφτει άσχημα σε παρόμοιους προϋπολογισμούς, αλλά αυτή η ανάγνωση συνοδεύεται από επιφυλάξεις που το άρθρο πηγής είχε δίκιο να επισημάνει: η σύγκριση εκτελείται εντός του πλαισίου του OSCAR, κβαντίζει όλα τα επίπεδα, χρησιμοποιεί έναν μόνο τυχαίο σπόρο και αξιολογεί το TurboQuant κάτω από το προβλεπόμενο καθεστώς 3 έως 4 bit. Αυτό δεν αρκεί για μια σαρωτική ετυμηγορία. Αντίθετα, η ιστορία φορητότητας του TurboQuant δεν απαντά στο αν μπορείτε να έχετε σταθερή συμπεριφορά παραγωγής INT2 στη δική σας στοίβα την επόμενη εβδομάδα.
Επομένως, η πραγματική απόφαση είναι πιο στενή και πιο βαρετή:
- Επιλέξτε το TurboQuant όταν η ανάπτυξη ανεξάρτητα από το μοντέλο και η συμπεριφορά 3 έως 4 bit σχεδόν χωρίς απώλειες έχουν μεγαλύτερη σημασία από την απόλυτη συμπίεση.
- Επιλέξτε το OSCAR όταν χρειάζεστε INT2 για υποστηριζόμενα μοντέλα, ενσωμάτωση στην παραγωγή και άμεση εξοικονόμηση μνήμης σε μεγάλο πλαίσιο.
- Μην αναγκάζετε κανένα από τα δύο να λύσει τη διαχείριση μνήμης πολλών γύρων, γιατί αυτή δεν είναι η δουλειά τους.
Το EpiCache είναι η υπενθύμιση ότι τα μεγάλα prompts και οι μεγάλες συνομιλίες είναι διαφορετικά προβλήματα συστημάτων
Αυτό είναι το κομμάτι που πολλές ομάδες χάνουν. Ένα μεμονωμένο prompt 128K και μια δίωρη συνομιλία δεν είναι το ίδιο workload, ακόμα κι αν και τα δύο μοιάζουν με «μεγάλο πλαίσιο» σε μια παρουσίαση.
Το EpiCache της Apple αντιμετωπίζει άμεσα την περίπτωση της συνομιλίας. Αντί να ρωτά μόνο πόσο ακριβώς να αποθηκεύσει τα tokens, ρωτά ποιο ιστορικό να διατηρήσει ενεργό, πώς να το χωρίσει σε συνεκτικά επεισόδια και πώς να ανακτήσει το σωστό επεισόδιο κατά τον συμπερασμό. Το πλαίσιο προσθέτει block-wise prefill, επεισοδιακή ομαδοποίηση, ανάκτηση μέσω επεισοδίων και προϋπολογισμό μνήμης ανά επίπεδο.
Λειτουργικά, αυτός είναι ένας διαφορετικός άξονας από την κβαντοποίηση KV cache. Είναι διαχείριση cache, όχι απλώς συρρίκνωση cache. Τα αναφερόμενα κέρδη στο υλικό πηγής είναι ακριβώς ο λόγος για τον οποίο αυτή η διάκριση έχει σημασία: έως και 40% υψηλότερη ακρίβεια από τις βασικές γραμμές εκδίωξης, ακρίβεια σχεδόν πλήρους cache σε συμπίεση 4 έως 6x, έως και 3,5x χαμηλότερη μέγιστη μνήμη και περίπου 2,4x χαμηλότερη καθυστέρηση στα αξιολογημένα benchmarks συνομιλίας.
Η απάντησή μου στη νοοτροπία «απλώς διάλεξε έναν νικητή» είναι απλή: το EpiCache συνδυάζεται με το TurboQuant ή το OSCAR. Έτσι, αν το workload σας είναι ένα copilot υποστήριξης, βοηθός έρευνας ή εσωτερικός πράκτορας με βαθύ ιστορικό συνομιλίας, η καλύτερη στοίβα μπορεί να είναι μία μέθοδος για διατήρηση συν μία άλλη για ακρίβεια αποθήκευσης. Αυτό δεν είναι αναποφασιστικότητα. Είναι σχεδιασμός συστημάτων.
Το σωστό ερώτημα είναι ποιος περιορισμός σας κοστίζει χρήματα πρώτα
Όταν μπαίνω σε μια αναθεώρηση συμπερασμού, δεν ξεκινάω με τα ονόματα των εγγράφων. Ξεκινάω με τρεις ερωτήσεις.
Πρώτον, ο στόλος εξυπηρέτησης δεσμεύεται από τη μνήμη κατά τον χρόνο αποκωδικοποίησης ή είμαστε ακόμα δεσμευμένοι από τον υπολογισμό; Δεύτερον, χρειαζόμαστε φορητότητα μεταξύ μοντέλων ή μπορούμε να βελτιστοποιήσουμε σκληρά για μια υποστηριζόμενη στοίβα; Τρίτον, το workload κυριαρχείται από ένα μεγάλο prompt ή από πολλούς γύρους συνομιλίας;
Αυτές οι ερωτήσεις συνήθως περιορίζουν το πεδίο γρήγορα. Αν κυριαρχεί η φορητότητα, το TurboQuant έχει το πιο καθαρό επιχείρημα. Αν η ομάδα σας βρίσκεται ήδη σε μια στοίβα που υποστηρίζει το OSCAR και χρειάζεστε επιθετική εξοικονόμηση INT2 τώρα, το OSCAR φαίνεται ισχυρότερο. Αν οι συνεδρίες υποστήριξης ή η μνήμη του πράκτορα είναι το σημείο πόνου, το EpiCache ανήκει στον σχεδιασμό ακόμα κι αν κάνετε κβαντοποίηση.
Γι' αυτό επιστρέφω συνεχώς στην ίδια αντίθετη θέση: η συμπίεση KV cache δεν είναι πραγματικά αγώνας. Είναι ένα πρόβλημα σχεδιασμού στοίβας που διαφημίστηκε σαν αγώνας σε κλουβί.
Σχετικά αναγνώσματα
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation