Οδηγός ποσοτικοποίησης LLM: 7 μέθοδοι συγκρίνονται (με τα νούμερα των benchmarks)

Οδηγός ποσοτικοποίησης LLM: 7 μέθοδοι συγκρίνονται (με τα νούμερα των benchmarks)

Το Llama 3.3 70B σε FP16 χρειάζεται 140 GB μόνο για τα βάρη. Δύο H100. Σε Q4_K_M, το ίδιο μοντέλο χωράει σε περίπου 42 GB, δηλαδή μία μεταχειρισμένη RTX A6000 από το eBay. Αυτό το χάσμα είναι ολόκληρος ο λόγος που υπάρχει η ποσοτικοποίηση LLM, και η λάθος μέθοδος σας κοστίζει είτε σε ποιότητα που φαίνεται είτε σε VRAM που δεν έχετε.

Αυτός ο οδηγός ποσοτικοποίησης LLM συγκρίνει τις 7 μεθόδους που μετρούν το 2026, με κάθε νούμερο να ανιχνεύεται πίσω σε δημοσιευμένη πηγή.

Βασικά σημεία

• Η ποσοτικοποίηση ανταλλάσσει μνήμη και εύρος ζώνης με μια μετρήσιμη, συνήθως μικρή, απώλεια ποιότητας.
• Το GPTQ και το AWQ είναι GPU-first· το GGUF είναι η μορφή που τρέχει και σε CPU.
• Το Q4_K_M πέφτει κοντά στα 4,8 bits ανά βάρος, όχι 4. Η ονομασία κρύβει την επιβάρυνση.
• Η ποσοτικοποίηση 6-bit κάθεται στο ~0,1% της perplexity του FP16, σύμφωνα με το PR k-quants του llama.cpp.

Τι κάνει πραγματικά η ποσοτικοποίηση LLM στο μοντέλο σας;

Η ποσοτικοποίηση LLM αποθηκεύει τα βάρη του μοντέλου σε χαμηλότερη αριθμητική ακρίβεια, μικραίνοντας τη μνήμη και το εύρος ζώνης με κόστος το σφάλμα στρογγυλοποίησης. Ένα μοντέλο 70B παραμέτρων πέφτει από 140 GB σε FP16 σε περίπου 42 GB σε 4-bit. Η ευφυΐα μένει· τα δεκαδικά ψηφία φεύγουν. Κάθε μέθοδος σε αυτόν τον οδηγό είναι μια παραλλαγή αυτής της ανταλλαγής.

Η σκάλα ακρίβειας ξεκινά από FP32 (32 bits), περνά από FP16 και BF16 (16 bits το καθένα), μετά INT8 και μετά INT4. Κάθε σκαλί υποδιπλασιάζει τα bytes ανά παράμετρο. Το πρότυπο IEEE 754 ορίζει τις μορφές float· η εργασία του Mark Horowitz το 2014 "Computing's Energy Problem" έδειξε γιατί η μετακίνηση αυτών των bytes, και όχι η αριθμητική πάνω τους, κυριαρχεί στο ενεργειακό κόστος. Αυτός είναι ο φυσικός λόγος που η ποσοτικοποίηση επιταχύνει τον συμπερασμό.

Δύο παράμετροι κάνουν την ποσοτικοποίηση να δουλεύει: ένας παράγοντας κλίμακας (πολλαπλασιαστής που αντιστοιχίζει το εύρος ακεραίων πίσω σε πραγματικές τιμές) και ένα σημείο μηδενός (ο ακέραιος που αναπαριστά το 0,0). Η συμμετρική ποσοτικοποίηση κεντράρει το εύρος στο μηδέν και παραλείπει το σημείο μηδενός· η ασύμμετρη ποσοτικοποίηση το μετατοπίζει ώστε να χρησιμοποιεί όλο το εύρος ακεραίων όταν τα βάρη συγκεντρώνονται μακριά από το μηδέν.

Τα βάρη ποσοτικοποιούνται καθαρά επειδή είναι στατικά και κανονικά κατανεμημένα. Οι ενεργοποιήσεις όχι. Οι ακραίες ενεργοποιήσεις, μερικές φορές 100x η διάμεσος, εκτοξεύουν το σφάλμα στρογγυλοποίησης αν τις ποσοτικοποιήσετε αφελώς. Αυτή η ασυμμετρία είναι ο λόγος που οι περισσότερες μέθοδοι εδώ ποσοτικοποιούν μόνο τα βάρη (W4A16) και αφήνουν τις ενεργοποιήσεις σε FP16.

Η ποσοτικοποίηση μετά την εκπαίδευση (PTQ) μετατρέπει ένα ολοκληρωμένο μοντέλο μετά την εκπαίδευση. Η εκπαίδευση με επίγνωση ποσοτικοποίησης (QAT) προσομοιώνει τη στρογγυλοποίηση κατά την εκπαίδευση ώστε το μοντέλο να προσαρμοστεί. Ό,τι σε αυτό το άρθρο είναι PTQ. Το QAT κοστίζει περισσότερο σε υπολογισμό και σε μια εκπαίδευση· είναι ξεχωριστή απόφαση.

Οι σειρές INT4 και NF4 είναι θεωρητικό καθαρό 4-bit: 4 bits ανά βάρος και τίποτα άλλο. Οι πραγματικές μορφές 4-bit κουβαλούν κλίμακες και ελάχιστα block από πάνω, άρα πέφτουν ψηλότερα. Ένα μοντέλο 70B σε Q4_K_M είναι περίπου 42 GB, όχι 35. Ο πίνακας VRAM παρακάτω χρησιμοποιεί αντ' αυτού τα αποτελεσματικά ποσοστά.

Η ποσοτικοποίηση δεν μικραίνει την ευφυΐα του μοντέλου. Μικραίνει τον αριθμό των δεκαδικών ψηφίων στα οποία αποθηκεύει αυτή την ευφυΐα. Και αν πληρώνετε ανά token για συμπερασμό API, η μείωση του λογαριασμού LLM API συχνά ξεκινά από το να τρέξετε μόνοι σας ένα ποσοτικοποιημένο μοντέλο.

Οι 7 μέθοδοι ποσοτικοποίησης, δίπλα-δίπλα

Οι επτά μέθοδοι παρακάτω καλύπτουν κάθε παραγωγική διαδρομή για ποσοτικοποίηση ενός LLM το 2026. Δύο είναι μόνο για GPU (GPTQ, AWQ), μία τρέχει παντού (GGUF), μία ποσοτικοποιεί κατά τη φόρτωση (BitsandBytes), δύο στοχεύουν στην εξυπηρέτηση υψηλής απόδοσης (SmoothQuant, FP8) και μία είναι εγγενής στο PyTorch (TorchAO). Η σωστή επιλογή εξαρτάται από το υλικό σας, όχι από το ποια μέθοδος σκοράρει ψηλότερα σε κάποιο leaderboard.

Το GPTQ ποσοτικοποιεί στρώμα προς στρώμα χρησιμοποιώντας τον αντίστροφο Εσσιανό για να ανακατανείμει το σφάλμα στρογγυλοποίησης στα υπόλοιπα βάρη. Χρειάζεται σύνολο βαθμονόμησης και GPU. Η εργασία GPTQ αναφέρει ποσοτικοποίηση ενός μοντέλου 175B σε 3-4 bits σε περίπου 4 GPU-ώρες.

Το AWQ εντοπίζει το ~1% των βαρών που μετρούν περισσότερο (salient weights, που βρίσκονται από τα μεγέθη ενεργοποιήσεων) και τα κλιμακώνει ώστε να τα προστατεύσει από τη στρογγυλοποίηση. Η εργασία AWQ (καλύτερη εργασία MLSys 2024) αναφέρει επιτάχυνση πάνω από 3x έναντι της υλοποίησης FP16 του HuggingFace τόσο σε desktop όσο και σε mobile GPUs.

Το GGUF είναι μορφή αρχείου, όχι αλγόριθμος. Ο αλγόριθμος από μέσα είναι το σχήμα block k-quant από το llama.cpp PR #1684. Είναι η μόνη μέθοδος εδώ που τρέχει σε CPU, κάτι που την κάνει την προεπιλογή για τοπικό συμπερασμό. Δείτε τα μοντέλα ανοιχτών βαρών που αξίζει να ποσοτικοποιήσετε για το τι θα της ταΐσετε.

Το BitsandBytes ποσοτικοποιεί κατά τη φόρτωση και όχι εκ των προτέρων. Το NF4 (4-bit NormalFloat) είναι η χαρακτηριστική του μορφή και είναι η ραχοκοκαλιά του fine-tuning QLoRA. Δεν χρειάζεται σύνολο βαθμονόμησης.

Το SmoothQuant μεταφέρει τις ακραίες ενεργοποιήσεις στα βάρη ώστε και τα δύο να τρέχουν σε INT8. Η εργασία αναφέρει επιτάχυνση έως 1,56x και μείωση μνήμης 2x, και στοχεύει στην απόδοση στην εξυπηρέτηση μεγάλου batch, όπου οι μέθοδοι W4A16 αφήνουν επιδόσεις στο τραπέζι.

Το FP8 (W8A8) είναι η εγγενής διαδρομή σε GPUs H100 και B200. Σχεδόν χωρίς απώλειες στα 8-bit, χωρίς πονοκέφαλο βαθμονόμησης, και το vLLM το υποστηρίζει απευθείας.

Το TorchAO είναι η δική του βιβλιοθήκη ποσοτικοποίησης του PyTorch, φτιαγμένη να δουλεύει με το torch.compile. Αν το pipeline σας είναι ήδη PyTorch, είναι η διαδρομή με τη λιγότερη αντίσταση.

Υπάρχουν μόνο δύο αληθινά ερωτήματα: το υλικό σας το τρέχει, και μπορείτε να ζήσετε με την ποιότητα που κοστίζει;

Τι δείχνουν πραγματικά τα δημοσιευμένα benchmarks;

Τα δημοσιευμένα benchmarks λένε ότι η ποσοτικοποίηση 4-bit κοστίζει 1-2% perplexity σε ένα μοντέλο 7B, και το 6-bit κοστίζει κάτω από 0,1%. Αυτά τα νούμερα προέρχονται από το llama.cpp PR #1684 (2023), μετρημένα από τους συντηρητές του llama.cpp σε ένα μοναδικό μοντέλο 7B σε RTX 4080. Είναι τα πιο αναφερόμενα νούμερα στον χώρο της ποσοτικοποίησης, και είναι αληθινά. Είναι επίσης n = 1.

Πηγή: llama.cpp PR #1684 (2023). Μοντέλο 7B, RTX 4080, μετρημένο από τους συντηρητές του llama.cpp. n = 1 μοντέλο.

Μια σημείωση για τη στήλη bits/βάρος: αυτά είναι τα ονομαστικά ποσοστά για τον βασικό τύπο k-quant, και οι μίξεις _K ανεβάζουν το αποτελεσματικό ποσοστό. Το Q2_K είναι χαρακτηριστική περίπτωση. Τρέξτε τον ίδιο τον τύπο του άρθρου στο ονομαστικό 2,5625 και σε ένα μοντέλο 6,74B παραμέτρων και παίρνετε ~2,0 GB, αλλά η σειρά αναφέρει αρχείο 2,67 GB, που λύνεται αντίστροφα σε ~3,4 bits ανά βάρος. Το υπόλοιπο αυτού του άρθρου χρησιμοποιεί τα αποτελεσματικά ποσοστά, προκύπτοντα από αυτά τα μεγέθη αρχείων.

Τα νούμερα των μεθόδων GPU προέρχονται απευθείας από τις εργασίες. Το GPTQ αναφέρει επιταχύνσεις συμπερασμού end-to-end έναντι FP16 περίπου 3,25x σε A100 και ~4,5x σε A6000, με ένα μοντέλο 175B ποσοτικοποιημένο σε 3-4 bits σε περίπου 4 GPU-ώρες. Το AWQ αναφέρει "περισσότερο από 3x επιτάχυνση έναντι της υλοποίησης FP16 του HuggingFace τόσο σε desktop όσο και σε mobile GPUs", συν την πρώτη ανάπτυξη Llama-2 70B σε mobile GPU μέσω TinyChat. Παραθέτουμε τη διατύπωση της εργασίας αντί να παραφράσουμε ένα νούμερο σε ψευδή ακρίβεια.

Η αρχική συνεισφορά εδώ είναι αριθμητική. Η μνήμη για τα βάρη ακολουθεί: βάρη (GB) ≈ παράμετροι (B) × bits ανά βάρος ÷ 8. Η παγίδα είναι ποιο νούμερο bits-ανά-βάρος της ταΐζετε. Το PR #1684 δημοσιεύει το ποσοστό για τον βασικό τύπο k-quant (Q4_K = 4,5), και οι μίξεις _S/_M/_L κάθονται πάνω από αυτό το βασικό ποσοστό επειδή δίνουν επιπλέον bits στους τανυστές προσοχής και feed-forward. Άρα εξάγαμε τα αποτελεσματικά ποσοστά από τα μεγέθη αρχείων που δημοσιεύει το ίδιο το PR, σε ένα μοντέλο 7B που είναι στην πραγματικότητα 6,74B παράμετροι: το Q2_K στα 2,67 GB λύνεται αντίστροφα σε ~3,4 bpw, το Q4_K_S στα 3,56 GB σε ~4,5, το Q6_K στα 5,15 GB σε ~6,6. Το Q4_K_M πέφτει κοντά στο 4,8.

Αυτό αλλάζει το νούμερο του τίτλου. Ένα μοντέλο 70B σε Q4_K_M: 70 × 4,8 ÷ 8 = 42 GB. Τα περισσότερα άρθρα λένε 35 GB. Χρησιμοποιούν 4,0 bpw και παραλείπουν εντελώς την επιβάρυνση των κλιμάκων block. Ο έλεγχος παίρνει ένα κλικ: το Llama-3.3-70B-Instruct-Q4_K_M.gguf κυκλοφορεί στα 42,5 GB στο HuggingFace, το ίδιο στα repos bartowski, lmstudio-community και second-state. Υπολογίσαμε ξανά κάθε κελί στον πίνακα VRAM παρακάτω σε αυτή τη βάση.

Η ανάγνωσή μας για αυτά τα νούμερα: το χάσμα perplexity μεταξύ Q6_K (5,9110) και F16 (5,9066) είναι 0,0044, που είναι μικρότερο από το χάσμα μεταξύ δύο διαφορετικών fine-tune του ίδιου βασικού μοντέλου. Γι' αυτό η συμβουλή "απλά χρησιμοποιήστε Q4_K_M ή Q5_K_M" είναι αυτή που επιβιώνει στην επαφή με πραγματικό υλικό. Η στήλη ms/token δείχνει επίσης ότι το Q2_K δεν αγοράζει ταχύτητα έναντι του Q4_K_S (και τα δύο 15,5 ms/token) ενώ κοστίζει 0,75 perplexity. Το Q2_K είναι η χειρότερη ανταλλαγή στον πίνακα.

Αυτό που τα νούμερα δεν σας λένε: η perplexity wikitext δεν είναι το ίδιο με την ποιότητα στα δικά σας prompts. Ένα μοντέλο σε μία GPU είναι n = 1. Τα νούμερα ταχύτητας εξαρτώνται από το batch-size. Αντιμετωπίστε τα ως κατευθυντήρια, όχι καθολικά.

Η ποσοτικοποίηση 6-bit πέφτει στο περίπου 0,1% της perplexity του μοντέλου πλήρους ακρίβειας. Η συμπίεση είναι σχεδόν δωρεάν σε αυτό το επίπεδο.

GPTQ εναντίον AWQ: Επιλέγοντας ανάμεσα στις δύο μεθόδους GPU

Το GPTQ και το AWQ παράγουν και τα δύο checkpoints 4-bit για GPU από ένα σύνολο βαθμονόμησης, και τα δύο υποστηρίζονται καλά στο vLLM. Η διαφορά είναι πώς χειρίζονται το σφάλμα στρογγυλοποίησης. Το GPTQ το ανακατανέμει στα υπόλοιπα βάρη χρησιμοποιώντας τον αντίστροφο Εσσιανό. Το AWQ προστατεύει το 1% των βαρών που οι ενεργοποιήσεις σημαδεύουν ως σημαντικά. Και τα δύο δουλεύουν. Η επιλογή αφορά το μοτίβο εξυπηρέτησής σας.

Το GPTQ δουλεύει στρώμα προς στρώμα. Για κάθε στρώμα, ποσοτικοποιεί ένα βάρος τη φορά και μετά προσαρμόζει τα υπόλοιπα βάρη σε αυτό το στρώμα ώστε να αντισταθμίσει τη στρογγυλοποίηση που μόλις έκανε. Η προσαρμογή χρησιμοποιεί πληροφορίες δεύτερης τάξης από τον πίνακα Εσσιανής, γι' αυτό χρειάζεται ένα σύνολο βαθμονόμησης για να υπολογιστεί. Το αποτέλεσμα είναι ισχυρό για batch συμπερασμό όπου η απόδοση μετρά περισσότερο από την καθυστέρηση ανά token.

Το AWQ παίρνει διαφορετική γωνία. Εντοπίζει τα salient weights κοιτώντας τα μεγέθη ενεργοποιήσεων σε όλο το σύνολο βαθμονόμησης, περίπου το κορυφαίο 1% των καναλιών. Αυτά τα βάρη παίρνουν έναν παράγοντα κλίμακας ανά κανάλι που τα κρατά σε εύρος υψηλότερης ακρίβειας κατά τη στρογγυλοποίηση. Το σύνολο βαθμονόμησης μπορεί να είναι μικρότερο από του GPTQ, και το AWQ το υπερπροσαρμόζει λιγότερο επειδή προστατεύει δομικά χαρακτηριστικά αντί να προσαρμόζεται σε συγκεκριμένα inputs. Η εργασία αναφέρει ισχυρά αποτελέσματα στην εξυπηρέτηση ευαίσθητη σε καθυστέρηση.

Επιλέξτε GPTQ αν: κάνετε batch συμπερασμό σε GPU, έχετε ένα καλό σύνολο βαθμονόμησης που ταιριάζει στον τομέα σας, και η απόδοση είναι η μετρική.

Επιλέξτε AWQ αν: εξυπηρετείτε αιτήματα μονού χρήστη με χαμηλή καθυστέρηση, θέλετε μικρότερο σύνολο βαθμονόμησης, ή αναπτύσσετε σε edge/mobile GPUs.

# Serve a published AWQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-AWQ \
  --quantization awq \
  --max-model-len 4096

# Serve a published GPTQ checkpoint with vLLM
vllm serve TheBloke/Llama-2-7B-Chat-GPTQ \
  --quantization gptq \
  --max-model-len 4096

Αν επιλέγετε και ανάμεσα σε μηχανές εξυπηρέτησης, το vLLM εναντίον SGLang καλύπτει αυτή την απόφαση ξεχωριστά.

GGUF και K-Quants: Τι σημαίνει πραγματικά το Q4_K_M

Το GGUF είναι μορφή αρχείου, όχι αλγόριθμος ποσοτικοποίησης. Η προδιαγραφή GGUF ορίζει ένα κοντέινερ για βάρη μοντέλου, μεταδεδομένα και δεδομένα tokenizer. Ο αλγόριθμος ποσοτικοποίησης μέσα σε ένα αρχείο GGUF είναι το σχήμα block k-quant (ή i-quant) από το llama.cpp PR #1684. Το να μπερδεύετε το κοντέινερ με τον αλγόριθμο είναι το πιο συνηθισμένο λάθος σε αυτόν τον χώρο, και οδηγεί σε ερωτήσεις όπως "ποιο είναι καλύτερο, GGUF ή GPTQ;" που δεν πολυβγάζουν νόημα.

Το σχήμα ονοματολογίας αποκωδικοποιείται ως εξής. Q σημαίνει σχήμα block k-quant· IQ σημαίνει i-quant με πίνακα σημαντικότητας (μια νεότερη παραλλαγή που χρησιμοποιεί πίνακα σημαντικότητας για καλύτερη ποιότητα στο ίδιο βάθος bits). Ο αριθμός είναι το ονομαστικό βάθος bits. _K σημαδεύει την οικογένεια k-quant έναντι παλαιών μορφών όπως το Q4_0. _S, _M, _L ελέγχουν ποιες ομάδες τανυστών παίρνουν επιπλέον bits: small, medium, large. Υψηλότερο επίθημα σημαίνει περισσότερα bits κατανεμημένα στους τανυστές προσοχής και feed-forward που μετρούν περισσότερο.

Αποτελεσματικά ποσοστά, λυμένα αντίστροφα από τα μεγέθη αρχείων του 7B (6,74B παραμέτρων) που δημοσιεύονται στο PR #1684, όχι τα νούμερα του βασικού τύπου. Οι σειρές legacy είναι ακριβείς εξ ορισμού: ένα block Q4_0 είναι 32 βάρη σε 4 bits συν μία κλίμακα FP16, που είναι 4,5 bits ανά βάρος, και το Q8_0 είναι 32 βάρη σε 8 bits συν μία κλίμακα FP16, που είναι 8,5. Το PR το επιβεβαιώνει, παραθέτοντας τα αρχεία 7B Q4_0 και Q4_K_S στο ίδιο 3,56 GB.

Το Q4_K_M δεν είναι 4 bits ανά βάρος. Είναι περίπου 4,8. Οι κλίμακες και τα ελάχιστα block πρέπει να ζήσουν κάπου, και η μίξη _M μετά ξοδεύει επιπλέον bits στους τανυστές προσοχής και feed-forward, που είναι ακριβώς γιατί το Q4_K_M κάθεται πάνω από το Q4_K_S και το Q3_K_M κάθεται πάνω από το Q3_K_S αντί να το ταιριάζει.

Γιατί το GGUF τρέχει εκεί που το GPTQ δεν μπορεί: υποστηρίζει συμπερασμό CPU και offloading στρωμάτων μεταξύ VRAM GPU και μνήμης συστήματος. Ένα μοντέλο 32B που δεν χωράει ολόκληρο στην GPU σας μπορεί να τρέξει με τα μισά στρώματά του offloaded, αργά αλλά λειτουργικά. Το GPTQ δεν έχει διαδρομή CPU.

# Pull a specific quant tag with Ollama
ollama run llama3.1:8b-instruct-q4_K_M

# Convert an F16 GGUF to Q4_K_M with llama.cpp
llama-quantize model-f16.gguf model-q4_k_m.gguf Q4_K_M

Νέοι στα τοπικά μοντέλα; Ξεκινήστε με την πρώτη εκκίνηση τοπικού μοντέλου πριν ποσοτικοποιήσετε οτιδήποτε. Και αν θέλετε ένα browser UI, το Open WebUI πάνω από το Ollama παίρνει περίπου δέκα λεπτά. Τα docs GGUF του HuggingFace εξηγούν πώς το Hub εκθέτει την ονοματολογία τύπων quant.

BitsandBytes, Marlin, SmoothQuant και TorchAO

Αυτά τα τέσσερα καλύπτουν τις υπόλοιπες παραγωγικές διαδρομές. Κανένα δεν είναι "καλύτερο GPTQ". Λύνουν διαφορετικά προβλήματα.

Το BitsandBytes ποσοτικοποιεί κατά τη φόρτωση, όχι εκ των προτέρων. Το στρέφετε σε ένα checkpoint FP16 και μετατρέπει εν πτήσει σε NF4 ή FP4. Χωρίς σύνολο βαθμονόμησης, χωρίς offline βήμα. Η κύρια φήμη του είναι το QLoRA: ένα παγωμένο βασικό μοντέλο 4-bit με προσαρμογείς LoRA εκπαιδευμένους από πάνω, που κάνει το fine-tuning ενός μοντέλου 65B σε μία GPU εφικτό σε 48 GB VRAM. Το QLoRA είναι τεχνική εκπαίδευσης, όχι συμπερασμού, αλλά είναι ο λόγος που οι περισσότεροι συναντούν το BitsandBytes πρώτο.

Το Marlin δεν είναι μέθοδος ποσοτικοποίησης. Είναι ένας πυρήνας GEMM μικτής ακρίβειας INT4xFP16 που κάνει τα υπάρχοντα checkpoints 4-bit ταχύτερα σε μέτρια batch sizes. Η εργασία Marlin αναφέρει επιταχύνσεις σε A100 και H100. Αν η στοίβα εξυπηρέτησής σας το υποστηρίζει, το ενεργοποιείτε σε ένα ήδη ποσοτικοποιημένο μοντέλο. Δεν "ποσοτικοποιείτε με Marlin".

Το SmoothQuant μετατοπίζει τις ακραίες ενεργοποιήσεις στα βάρη μέσω ενός παράγοντα κλίμακας ανά κανάλι, κάνοντας το W8A8 (και βάρη και ενεργοποιήσεις σε INT8) βιώσιμο. Η εργασία στοχεύει στην εξυπηρέτηση μεγάλου batch όπου οι μέθοδοι W4A16 αφήνουν απόδοση στο τραπέζι. Αν εξυπηρετείτε εκατοντάδες ταυτόχρονες αιτήσεις, αυτό είναι το παιχνίδι.

Το TorchAO είναι ποσοτικοποίηση εγγενής στο PyTorch που δουλεύει με το torch.compile. Χωρίς εξωτερικές εξαρτήσεις, χωρίς μετατροπή μορφής. Αν το pipeline συμπερασμού σας είναι ήδη PyTorch, είναι η επιλογή με τη μικρότερη τριβή. Για την τοπική εκτέλεση μοντέλων embedding, η διαδρομή Ollama είναι συνήθως απλούστερη, αλλά το TorchAO ταιριάζει σε προσαρμοσμένες στοίβες PyTorch.

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

Ο τύπος είναι βάρη (GB) ≈ παράμετροι (B) × bits ανά βάρος ÷ 8. Ένα μοντέλο 70B σε Q4_K_M: 70 × 4,8 ÷ 8 = 42,0 GB. Τα ποσοστά παρακάτω είναι αποτελεσματικά, λυμένα αντίστροφα από τα μεγέθη αρχείων που δημοσιεύει το llama.cpp PR #1684 αντί από τα νούμερα του βασικού τύπου, επειδή οι μίξεις _M τρέχουν πάντα πάνω από το βασικό τους ποσοστό k-quant. Υπολογίσαμε ξανά αντί να αντιγράψουμε τη συνηθισμένη συντόμευση 4,0 bpw.

Υπολογισμένο από αποτελεσματικά bits-ανά-βάρος: Q8_0 = 8,5, Q6_K = 6,56, Q5_K_M = 5,7, Q4_K_M = 4,8, Q3_K_M = 3,9. Εξαγμένο από τα μεγέθη αρχείων του 7B (6,74B παραμέτρων) στο PR #1684, μετά διασταυρωμένο με ένα δημοσιευμένο build 70B: το Llama-3.3-70B-Instruct-Q4_K_M.gguf είναι 42,5 GB στο HuggingFace, έναντι 42,0 GB που προβλέπονται εδώ.

Η ειλικρινής επιφύλαξη: αυτό είναι μόνο βάρη. Η KV cache, το μήκος context και η επιβάρυνση του framework προστίθενται από πάνω. Η KV cache κλιμακώνεται με το μήκος context και το batch size. Μια συνεδρία 32k-context σε ένα μοντέλο 70B μπορεί να προσθέσει αρκετά GB. Ο πίνακας βαρών είναι το πάτωμα, όχι ο προϋπολογισμός. Το παράθυρο context σας νοικιάζει κι αυτό VRAM. Για την πλήρη εικόνα, δείτε τις αναλυτικές απαιτήσεις VRAM ανά μοντέλο.

Ποια μέθοδο ποσοτικοποίησης πρέπει να χρησιμοποιήσετε;

Το υλικό σας αποφασίζει πριν από τις προτιμήσεις σας. Μια μέθοδος που δεν τρέχει στην GPU σας δεν είναι επιλογή, είναι ευχή. Ο πίνακας παρακάτω αντιστοιχίζει συνηθισμένες εγκαταστάσεις στη μέθοδο που πραγματικά δουλεύει για αυτές, με βάση τους περιορισμούς υλικού και τις ανταλλαγές ποιότητας που καλύφθηκαν παραπάνω.

Για τους περισσότερους αναγνώστες σε καταναλωτικό υλικό, ένα προ-ποσοτικοποιημένο GGUF Q4_K_M ή Q5_K_M είναι η σωστή απάντηση. Τραβήξτε το από το HuggingFace, τρέξτε το σε Ollama ή llama.cpp, και σταματήστε να βελτιστοποιείτε. Η διαφορά ποιότητας μεταξύ Q4_K_M και Q5_K_M είναι αρκετά μικρή ώστε να επιλέγετε με βάση το αν χωράει το αρχείο, όχι με βάση έναν πίνακα perplexity. Ο,τιδήποτε πέρα από αυτό είναι βελτιστοποίηση για χάρη της βελτιστοποίησης, και αξίζει να γίνει μόνο αφού επιβεβαιώσετε ότι το μοντέλο λύνει πραγματικά το πρόβλημά σας σε Q4.

Ο οδηγός για τα εργαλεία που τρέχουν πραγματικά αυτά τα μοντέλα τοπικά καλύπτει την πλευρά εξυπηρέτησης μόλις διαλέξετε επίπεδο quant.

Πέντε τρόποι που η ποσοτικοποίηση πάει στραβά

Οι αποτυχίες ποσοτικοποίησης είναι σχεδόν πάντα προβλήματα διαμόρφωσης, όχι προβλήματα μεθόδου. Αυτά τα πέντε εμφανίζονται συνεχώς.

1. Το σύνολο βαθμονόμησης δεν ταιριάζει στον τομέα σας. Το GPTQ και το AWQ προσαρμόζονται και τα δύο στα δεδομένα βαθμονόμησης. Αν βαθμονομήσετε σε Wikipedia και αναπτύξετε σε ιατρικά απομαγνητοφωνημένα, το ποσοτικοποιημένο μοντέλο υποαποδίδει στα tokens που δεν είδε ποτέ. Διόρθωση: χρησιμοποιήστε ένα σύνολο βαθμονόμησης αντλημένο από την πραγματική σας κατανομή εισόδου, ακόμα και 128 δείγματα βοηθούν.

2. Το group size ρυθμίστηκε πολύ μεγάλο. Το group size του GPTQ ελέγχει πόσα βάρη μοιράζονται έναν παράγοντα κλίμακας. Το 128 είναι το στάνταρ. Το 256 ή 512 εξοικονομεί υπολογισμό κατά την ποσοτικοποίηση αλλά χτυπά γκρεμό ποιότητας σε μικρότερα μοντέλα. Διόρθωση: μείνετε στο 128 εκτός αν έχετε επιβεβαιώσει ότι η ποιότητα κρατά στα δικά σας prompts.

3. Περιμένετε το Q2_K να είναι χρήσιμο. Σύμφωνα με τα δεδομένα του PR #1684, το Q2_K κοστίζει ~0,87 perplexity έναντι F16 και δεν αγοράζει ταχύτητα έναντι του Q4_K_S (και τα δύο 15,5 ms/token στο benchmark 7B). Παίρνετε μικρότερο αρχείο και χειρότερα αποτελέσματα χωρίς κέρδος καθυστέρησης. Διόρθωση: το Q4_K_S είναι το πάτωμα εκτός αν το μέγεθος αρχείου είναι σκληρός περιορισμός.

4. Κάνετε benchmark σε perplexity wikitext αντί στα δικά σας prompts. Η perplexity είναι μετρική γλωσσικής μοντελοποίησης. Δεν μετρά αν το μοντέλο ακολουθεί το system prompt σας, μορφοποιεί σωστά JSON, ή χειρίζεται το λεξιλόγιο του τομέα σας. Διόρθωση: τρέξτε 20-30 από τα πραγματικά σας prompts τόσο στο ποσοτικοποιημένο όσο και στο μη ποσοτικοποιημένο μοντέλο και συγκρίνετε τα αποτελέσματα.

5. Μπερδεύετε το GGUF το κοντέινερ με τον αλγόριθμο ποσοτικοποίησης μέσα του. Αυτό οδηγεί στο να συγκρίνετε "GGUF εναντίον GPTQ" σαν να είναι η ίδια κατηγορία. Δεν είναι. Το GGUF είναι μορφή αρχείου. Το σχήμα k-quant μέσα του είναι ο αλγόριθμος. Διόρθωση: συγκρίνετε επίπεδα k-quant (Q4_K_M εναντίον Q5_K_M), όχι μορφές αρχείων.

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

Τι είναι η ποσοτικοποίηση LLM;

Η ποσοτικοποίηση LLM μειώνει την αριθμητική ακρίβεια των βαρών ενός μοντέλου, τυπικά από 16-bit floating point σε ακέραιους 4-bit ή 8-bit. Αυτό κόβει τη χρήση μνήμης και επιταχύνει τον συμπερασμό μειώνοντας το εύρος ζώνης. Ένα μοντέλο 70B πέφτει από 140 GB σε περίπου 42 GB σε 4-bit. Το κόστος ποιότητας είναι συνήθως 1-2% perplexity σε 4-bit, λιγότερο σε 6-bit.

Η ποσοτικοποίηση μειώνει την ακρίβεια ενός μοντέλου;

Ναι, αλλά λιγότερο από όσο περιμένουν οι περισσότεροι. Σύμφωνα με τα benchmarks του llama.cpp PR #1684, το Q4_K_S σε ένα μοντέλο 7B κοστίζει περίπου 2% perplexity έναντι F16, και το Q6_K κοστίζει κάτω από 0,1%. Η πρακτική επίπτωση σε πραγματικά prompts είναι συχνά μικρότερη από ό,τι υποδηλώνει το νούμερο perplexity, ειδικά σε Q4_K_M και πάνω.

Είναι καλύτερο το GPTQ ή το AWQ;

Κανένα δεν είναι καθολικά καλύτερο. Το GPTQ χρησιμοποιεί ανακατανομή σφάλματος αντίστροφης Εσσιανής και ταιριάζει στον batch συμπερασμό GPU. Το AWQ προστατεύει τα salient weights μέσω κλιμάκωσης με επίγνωση ενεργοποιήσεων και ταιριάζει στην εξυπηρέτηση ευαίσθητη σε καθυστέρηση. Το AWQ χρειάζεται μικρότερο σύνολο βαθμονόμησης και το υπερπροσαρμόζει λιγότερο. Αν εξυπηρετείτε αιτήσεις μονού χρήστη με χαμηλή καθυστέρηση, ξεκινήστε με AWQ.

Τι σημαίνει Q4_K_M;

Το Q4_K_M είναι ένα επίπεδο ποσοτικοποίησης k-quant GGUF. "Q4" σημαίνει ονομαστικό βάθος 4-bit, "K" σημαδεύει το σχήμα block k-quant (έναντι του legacy Q4_0), και "M" σημαίνει medium: οι τανυστές προσοχής και feed-forward παίρνουν επιπλέον bits. Τα αποτελεσματικά bits ανά βάρος είναι περίπου 4,8, όχι 4,0, επειδή οι κλίμακες και τα ελάχιστα block προσθέτουν επιβάρυνση και η μίξη medium ξοδεύει περισσότερα από πάνω.

Μπορώ να τρέξω ένα ποσοτικοποιημένο μοντέλο σε CPU;

Ναι, αλλά μόνο μέσω GGUF. Το GPTQ και το AWQ είναι μορφές μόνο για GPU. Τα μοντέλα k-quant του GGUF τρέχουν σε CPU μέσω llama.cpp ή Ollama, και υποστηρίζουν offloading στρωμάτων μεταξύ VRAM GPU και μνήμης συστήματος. Το Q4_K_M είναι το στάνταρ quant CPU. Περιμένετε πιο αργή παραγωγή tokens από GPU, αλλά λειτουργικό συμπερασμό.

Ποια είναι η διαφορά μεταξύ GGUF και GGML;

Το GGML είναι η παλαιότερη βιβλιοθήκη τανυστών και μορφή αρχείου που χρησιμοποιούσε αρχικά το llama.cpp. Το GGUF το αντικατέστησε τον Αύγουστο του 2023 ως μια πιο ευέλικτη μορφή κοντέινερ με καλύτερη υποστήριξη μεταδεδομένων. Τα αρχεία GGUF είναι ό,τι κατεβάζετε από το HuggingFace σήμερα. Τα αρχεία GGML είναι legacy και σπάνια διανέμονται πια.

Πρέπει να ποσοτικοποιήσω ένα μοντέλο μόνος μου ή να κατεβάσω ένα προ-ποσοτικοποιημένο;

Κατεβάστε ένα προ-ποσοτικοποιημένο πρώτα. Οι κοινότητες llama.cpp και HuggingFace έχουν ήδη ποσοτικοποιήσει τα περισσότερα δημοφιλή μοντέλα σε κάθε επίπεδο. Η δική σας ποσοτικοποίηση βγάζει νόημα μόνο αν χρειάζεστε ένα συγκεκριμένο σύνολο βαθμονόμησης για τον τομέα σας, ή αν δεν υπάρχει προ-ποσοτικοποιημένη έκδοση για το μοντέλο σας.

Πότε πρέπει να χρησιμοποιήσω ποσοτικοποίηση αντί για ένα μικρότερο μοντέλο;

Χρησιμοποιήστε ποσοτικοποίηση όταν χρειάζεστε την ικανότητα του μεγαλύτερου μοντέλου αλλά δεν χωράει στη μνήμη. Ένα ποσοτικοποιημένο μοντέλο 70B γενικά υπερτερεί ενός μη ποσοτικοποιημένου μοντέλου 13B σε σύνθετες εργασίες συλλογισμού. Χρησιμοποιήστε αντ' αυτού ένα μικρότερο μοντέλο όταν η καθυστέρηση είναι ο περιορισμός, αφού τα μικρότερα μοντέλα παράγουν tokens ταχύτερα ανεξάρτητα από την ποσοτικοποίηση.

Ποια είναι η διαφορά μεταξύ ποσοτικοποίησης και απόσταξης;

Η ποσοτικοποίηση μειώνει την αριθμητική ακρίβεια των βαρών ενός υπάρχοντος μοντέλου. Η απόσταξη εκπαιδεύει ένα μικρότερο μοντέλο να μιμείται ένα μεγαλύτερο, παράγοντας μια αληθινά διαφορετική (μικρότερη) αρχιτεκτονική. Η ποσοτικοποίηση διατηρεί την αρχιτεκτονική του αρχικού μοντέλου και είναι αναστρέψιμη κατ' αρχήν. Η απόσταξη δημιουργεί ένα νέο μοντέλο και απαιτεί μια εκπαίδευση.

Η σύντομη εκδοχή: η ποσοτικοποίηση είναι ο τρόπος να χωρέσετε ένα μοντέλο που θέλετε σε υλικό που έχετε. Για τους περισσότερους σε καταναλωτικές GPUs ή Apple Silicon, ένα προ-ποσοτικοποιημένο GGUF Q4_K_M τραβηγμένο από το HuggingFace είναι ολόκληρη η λύση. Το GPTQ και το AWQ είναι οι απαντήσεις εξυπηρέτησης GPU. Το FP8 και το SmoothQuant είναι οι απαντήσεις παραγωγικής απόδοσης. Ο,τιδήποτε άλλο είναι βελτιστοποίηση αφού επιβεβαιώσετε ότι το μοντέλο δουλεύει.

Αν αποφασίζετε τι θα φιλοξενήσετε μόνοι σας και θέλετε μια δεύτερη γνώμη για το ταίριασμα υλικού-μεθόδου, χαρούμενοι να μιλήσουμε.