Περισσότερες GPUs ή μικρότερο KV cache; ο πραγματικός λογαριασμός του LLM serving

Το κόστος LLM serving εξαρτάται από το πραγματικό bottleneck: τα weights, το KV cache, το latency, το concurrency και το αποδεκτό quality floor. Γι’ αυτό το ερώτημα «περισσότερες GPUs ή μικρότερο cache;» δεν έχει μία καθολική απάντηση. Οι δύο επιλογές αγοράζουν διαφορετικό αποτέλεσμα και πρέπει να συγκριθούν πάνω στο ίδιο workload.

Η μελέτη More GPUs or a Smaller Cache? βάζει το tensor parallelism και το KV cache compression στον ίδιο οικονομικό άξονα: κόστος ανά εκατομμύριο tokens σε συνάρτηση με latency, throughput και memory relief. Το αποτέλεσμα δεν είναι ένας απλός νικητής. Είναι ένας πρακτικός κανόνας για το πότε η επιπλέον GPU είναι αναγκαία, πότε είναι χρήσιμη και πότε είναι απλώς ακριβή.

Η σύγκριση ενδιαφέρει κάθε ομάδα που λειτουργεί self-hosted ή dedicated LLMs για αναζήτηση, customer support, enrichment, content operations ή AI agents. Συνδέεται άμεσα με το πώς αξιολογούμε το πραγματικό κόστος μιας GPU υποδομής πέρα από την τιμή ανά ώρα και με το γιατί το AI ROI πρέπει να μετριέται ανά χρήσιμη εργασία, όχι μόνο ανά token.

Γιατί η σύγκριση είναι δύσκολη αλλά αναγκαία

Οι εργασίες για parallel scaling συνήθως παρουσιάζουν throughput και latency καθώς αυξάνεται ο αριθμός των συσκευών. Οι εργασίες για KV compression, αντίθετα, εστιάζουν στο ποσοστό εξοικονόμησης μνήμης ή στην ποιότητα σε κάποιο benchmark. Έτσι, ο ιδιοκτήτης μιας υποδομής δεν βλέπει εύκολα πόσο κοστίζει το ένα εκατομμύριο tokens όταν πρέπει να διατηρηθούν συγκεκριμένα επίπεδα latency, χωρητικότητας και ποιότητας.

Οι συγγραφείς όρισαν έναν κοινό δείκτη: κόστος ανά εκατομμύριο tokens, υπολογισμένο από την ωριαία τιμή κάθε GPU, τον αριθμό των GPUs και το simulated throughput. Στην πλευρά του tensor parallelism δοκιμάστηκαν βαθμοί 1, 2, 4 και 8. Στην πλευρά του compression δοκιμάστηκαν KV bit-width 16, 8 και 4, μαζί με keep-ratios 1, 0,5 και 0,25.

Ο αριθμός των GPUs πολλαπλασιάζει το hardware cost. Αν ο πολλαπλασιαστής αυτός λείπει, το scale-out μοιάζει τεχνητά δωρεάν και η οικονομική κατάταξη αντιστρέφεται. Είναι το ίδιο σφάλμα που προκύπτει όταν ένα γρήγορο GPU kernel αξιολογείται έξω από το πραγματικό μοντέλο: η τοπική βελτίωση δεν αρκεί για να αποδείξει καλύτερο end-to-end αποτέλεσμα.

Τι κάνουν οι δύο στρατηγικές

Το tensor parallelism μοιράζει τα weights και το KV cache σε πολλές GPUs. Η μνήμη ανά συσκευή μειώνεται περίπου όσο αυξάνεται ο βαθμός παραλληλισμού, με όρια που εξαρτώνται από την αρχιτεκτονική attention. Κάθε layer όμως πληρώνει επικοινωνία all-reduce, ενώ ο λογαριασμός hardware αυξάνεται με τον αριθμό των συσκευών.

Το KV cache compression μειώνει το αποτύπωμα των keys και values χωρίς να προσθέτει GPUs. Το quantization αποθηκεύει τα στοιχεία σε χαμηλότερο bit-width, ενώ το eviction κρατά μικρότερο μέρος των tokens. Η τεχνική αυξάνει τη χωρητικότητα, αλλά δεν μειώνει τα weights του μοντέλου και μπορεί να επηρεάσει την ποιότητα ή το per-token latency.

Η διάκριση εξηγεί γιατί τεχνικές όπως το retention-aware KV cache compression und die υβριδική προσοχή για μεγάλα contexts είναι χρήσιμες, αλλά δεν αντικαθιστούν αυτόματα τον σχεδιασμό χωρητικότητας των weights. Weight footprint και KV footprint πρέπει να παρακολουθούνται ξεχωριστά.

Μεθοδολογία και όρια των αποτελεσμάτων

Η μελέτη χρησιμοποίησε τον profiled simulator Vidur. Οι δημιουργοί της εργασίας δεν είχαν δική τους πρόσβαση σε GPUs και δεν έκαναν hardware measurements. Τα latency και throughput είναι simulated αποτελέσματα πάνω σε predictors που είχαν βαθμονομηθεί από τους δημιουργούς του Vidur με profiling σε A100, A40 και H100. Αντίθετα, οι υπολογισμοί μνήμης και feasibility είναι αριθμητικοί.

Το κύριο μοντέλο ήταν το Llama-2-7B σε A100 80 GB. Η ανάλυση υλικού επαναλήφθηκε σε A40 και H100, ενώ το Llama-2-70B χρησιμοποιήθηκε για τη ζώνη όπου τα fp16 weights δεν χωρούν σε μία A100. Το μέτριο interactive workload είχε 2.048 tokens prefill, 256 decode και 64 requests. Το κορεσμένο prefill-heavy workload είχε 3.840 prefill, 256 decode, 384 requests και 30 QPS.

Η compression πλευρά μοντελοποίησε τη μείωση μνήμης, όχι το kernel-level κόστος του dequantization. Παρ’ όλα αυτά, το μεγαλύτερο admitted batch αύξησε το simulated time per output token μέσω batching contention. Η ομάδα που θα εφαρμόσει INT8, INT4 ή eviction πρέπει επομένως να μετρήσει το πραγματικό runtime, όπως πρέπει να κάνει και όταν υιοθετεί native-speed inference με vLLM και Transformers.

Στα 7B, η συμπίεση κερδίζει στο κόστος — όχι στο latency

Στο prefill-heavy workload του Llama-2-7B σε A100, το fp16 με μία GPU κόστιζε 2,717 δολάρια ανά εκατομμύριο tokens. Το TP2 ανέβηκε στα 3,115, το TP4 στα 3,899 και το TP8 στα 4,888. Οι compressed διαμορφώσεις INT8, INT4 και INT4 με keep-ratio 0,5 συνέπεσαν στα 2,591 δολάρια, επειδή μετά το INT8 η μνήμη έπαψε να είναι ο δεσμευτικός πόρος.

Στο ίδιο setup, το TP8 μείωσε το P99 time-to-first-token από 234,9 σε 52,4 δευτερόλεπτα, περίπου 4,5 φορές. Το throughput αυξήθηκε, αλλά όχι αρκετά ώστε να καλύψει την οκταπλάσια τιμή των συσκευών. Σε matched memory relief, το compression ήταν φθηνότερο κατά 1,20 φορές στο μισό relief, 1,50 φορές στο ένα τέταρτο και 1,89 φορές στο ένα όγδοο.

Το latency trade-off ήταν πραγματικό μέσα στη simulation. Το INT4 αύξησε το median time per output token από 72,79 σε 78,83 ms, περίπου 8%, επειδή η ελεύθερη μνήμη επέτρεψε μεγαλύτερο batch και μεγαλύτερο contention. Άρα η συμπίεση αγοράζει capacity· δεν αποτελεί αυτόματα latency optimization. Για latency-sensitive serving, αξίζει να εξετάζονται και μηχανισμοί όπως το LLM routing με κοινό έλεγχο latency, accuracy και cost.

Το κρίσιμο όριο είναι το μέγεθος του μοντέλου

Για το Llama-2-7B σε συσκευή 80 GB, ο ακριβής υπολογισμός μνήμης έδειξε χωρητικότητα 29 ταυτόχρονων requests στο μέγιστο context των 4.096 tokens. Η διαμόρφωση θα αδυνατούσε να δεχθεί ακόμη και ένα request μόνο στα 131.072 tokens, δηλαδή 32 φορές πέρα από το context window του μοντέλου. Στο συγκεκριμένο setup, το 7B δεν μπορούσε να εξαντλήσει τον KV προϋπολογισμό μέσα στα δικά του όρια.

Η ουσιαστική γραμμή χωρισμού βρέθηκε στα weights. Με usable budget 72 GB μετά από safety margin 10%, το CodeLlama-34B με 61,9 GB fp16 weights χωρούσε σε μία συσκευή, ενώ τα Llama-2-70B και Llama-3-70B απαιτούσαν 127,5 GB. Οι συγγραφείς τοποθετούν το όριο περίπου στα 36B parameters για fp16 weights σε κάρτα 80 GB.

Το 36B δεν είναι καθολικός νόμος. Είναι το σημείο του συγκεκριμένου memory model και μετακινείται με weight quantization, άλλη αρχιτεκτονική, διαφορετικό runtime ή διαφορετικό safety margin. Η αρχή όμως μένει: αν δεσμεύουν τα weights, το KV compression δεν μπορεί να κάνει το μοντέλο εφικτό.

Τι αλλάζει στα 70B

Στο Llama-2-70B, το TP1 ήταν ανέφικτο και η σύγκριση ξεκίνησε από TP2. Η fp16 TP2 διαμόρφωση λειτουργούσε με 99% έως 100% KV occupancy και κρατούσε περίπου 13 concurrent requests. Εκεί το compression έπαψε να είναι αδρανές: το INT8 έδωσε 68,3 tokens ανά δευτερόλεπτο και το INT4 71,8, έναντι 53,3 για fp16 TP2.

Η εργασία αναφέρει 16,268 δολάρια ανά εκατομμύριο tokens για INT8 TP2 και 15,475 για INT4 TP2, έναντι 17,950 για fp16 TP4 και 24,089 για fp16 TP8 στο prefill-heavy workload. Το compression παρέμεινε οικονομικότερο στα matched relief σημεία, αλλά το ελάχιστο εφικτό TP2 δεν ήταν το φθηνότερο parallel configuration.

Στο interactive workload, το βήμα από TP2 σε TP4 έδωσε 3,38 φορές περισσότερο throughput για διπλάσια τιμή και μείωσε το κόστος ανά token κατά 41%. Στο prefill-heavy workload η μείωση ήταν 14%. Αυτό το superlinear κέρδος εμφανίστηκε επειδή το TP4 απελευθέρωσε έναν δεσμευτικό πόρο· μετά το TP4, το κόστος αυξήθηκε ξανά.

Η φθηνότερη GPU δεν δίνει πάντα φθηνότερο inference

Η σύγκριση A40, A100 και H100 έδωσε ακόμη ένα επιχειρηματικά σημαντικό εύρημα. Με τις υποθετικές ωριαίες τιμές της μελέτης — 1,00, 2,00 και 3,50 δολάρια αντίστοιχα — το κόστος ανά εκατομμύριο tokens ταξινομήθηκε αντίστροφα: H100 1,96, A100 2,59 και A40 3,29 δολάρια.

Η χαμηλή ωριαία τιμή της A40 δεν αντιστάθμισε το μικρότερο throughput της. Επιπλέον, η A40 ήταν memory-bound ακόμη και στα 7B με 99% occupancy στο fp16, οπότε το INT4 απέδωσε καλύτερα από το INT8. Το hardware model άλλαξε όχι μόνο την ταχύτητα, αλλά και το σημείο στο οποίο η επιπλέον συμπίεση έγινε χρήσιμη.

Αυτό δεν σημαίνει ότι η H100 είναι πάντα η καλύτερη αγορά. Οι τιμές ήταν round-number assumptions και η διασυσκευική σειρά εξαρτάται από το πραγματικό συμβόλαιο, τις εκπτώσεις, το interconnect, το workload και το software stack. Το lesson είναι ότι η αγορά δεν πρέπει να σταματά στο hourly rate, όπως δείχνει και η ευρύτερη ανάλυση για neoclouds και AI υποδομές.

Πρακτικός κανόνας επιλογής για μια AI ομάδα

Η απόφαση πρέπει να οργανωθεί ως σειρά ελέγχων και όχι ως προτίμηση σε μία τεχνική. Πρώτα εξασφαλίζεται feasibility, μετά μετριέται saturation, ύστερα γίνεται optimization κόστους και latency, και στο τέλος ελέγχεται αν το quality floor παραμένει αποδεκτό.

Ο κανόνας δεν αποκλείει άλλους μοχλούς. Speculative decoding, efficient attention, routing και weight quantization είναι ορθογώνιες επιλογές. Για παράδειγμα, το speculative decoding στοχεύει στον χρόνο παραγωγής, ενώ η KV compression στο footprint του state. Κάθε τεχνική πρέπει να αξιολογείται στο metric που πράγματι αλλάζει.

Τι σημαίνει για επιχειρησιακά AI workflows

Σε product enrichment ή campaign generation, ένα SLA με μικρή ανοχή καθυστέρησης μπορεί να επιτρέπει μεγαλύτερα batches και να ευνοεί τη συμπίεση. Σε live customer support, όπου ο χρήστης αντιλαμβάνεται άμεσα το TTFT, το parallelism ή το routing μπορεί να αξίζει περισσότερο από τη μέγιστη χωρητικότητα ανά δολάριο.

Σε workloads με επαναλαμβανόμενο prefix, η σωστή χρήση cache μπορεί να αλλάξει περισσότερο το κόστος από μια νέα GPU. Το KVBoost για κοινό περιεχόμενο που δεν βρίσκεται στην αρχή δείχνει γιατί το pattern των prompts έχει σημασία. Αντίθετα, όταν ένα 70B μοντέλο δεν χωρά καν, η συζήτηση ξεκινά από feasibility και όχι από prompt optimization.

Για μια ομάδα e-commerce ή marketing, η απόφαση πρέπει να συνδέει τέσσερα επίπεδα: customer journey, quality floor, workload shape και infrastructure economics. Ένα μικρότερο cache είναι κακή οικονομία αν μειώνει την ακρίβεια των απαντήσεων ή αυξάνει τα escalations. Μια επιπλέον GPU είναι επίσης κακή οικονομία αν αγοράζει latency που ο πελάτης δεν χρειάζεται.

Ποια metrics πρέπει να παρακολουθούνται

Ένα dashboard που δείχνει μόνο GPU utilization δεν αποκαλύπτει ποιος πόρος δεσμεύει. Χρειάζονται TTFT και TPOT σε P50/P99, throughput, KV occupancy, concurrent requests, OOM failures, batch size, queueing time και πραγματικό κόστος ανά εκατομμύριο input και output tokens.

Η ποιότητα πρέπει να βρίσκεται στο ίδιο report: task success, groundedness, retrieval hit rate, fallback rate, ανθρώπινα escalations και κόστος rework. Διαφορετικά, μια ρύθμιση INT4 μπορεί να φαίνεται φθηνότερη στην υποδομή αλλά ακριβότερη στην εργασία. Αυτός είναι ο ίδιος λόγος που το κρυφό κόστος του AI output δεν φαίνεται σε ένα απλό token bill.

Τέλος, τα metrics πρέπει να κόβονται ανά workload: μικρά chat requests, long-context retrieval, batch enrichment και agentic flows δεν μοιράζονται το ίδιο bottleneck. Η μία συνολική μέση τιμή κρύβει τα saturation regimes στα οποία αλλάζει η σωστή αρχιτεκτονική απόφαση.

Περιορισμοί και ουσιαστικό συμπέρασμα

Η εργασία δεν μέτρησε hardware με δικές της συσκευές, δεν αξιολόγησε ποιότητα, δεν μοντελοποίησε άμεσα το dequantization overhead των low-bit kernels και δεν έφτασε σε long-context καθεστώς πέρα από 4K. Το batch cap δέσμευσε ορισμένες διαμορφώσεις, το 70B δοκιμάστηκε μόνο σε A100 και η A40 δεν είχε all-reduce profiling για TP πάνω από 1.

Οι ωριαίες τιμές ήταν αντιπροσωπευτικές υποθέσεις, όχι συμβόλαια. Το όριο περίπου 36B αφορά fp16 weights σε usable budget 72 GB. Η weight quantization μπορεί να το μετακινήσει, ενώ νέα kernels και runtimes μπορούν να αλλάξουν τη σχετική απόδοση. Γι’ αυτό τα αποτελέσματα πρέπει να λειτουργούν ως υπόθεση σχεδιασμού που επαληθεύεται με profiling.

Το ουσιαστικό συμπέρασμα είναι ανθεκτικό: περισσότερες GPUs και μικρότερο KV cache δεν αγοράζουν το ίδιο πράγμα. Το tensor parallelism λύνει feasibility και latency. Το compression αγοράζει capacity με χαμηλότερο hardware cost, όταν τα weights ήδη χωρούν και το quality floor το επιτρέπει. Η σωστή απόφαση ξεκινά από το bottleneck και τελειώνει με μετρήσεις στο πραγματικό workload.