Φιλοξενία του Qwen στο Blackwell

Πώς εξυπηρετούμε το Qwen3 235B σε racks NVIDIA GB200 NVL72, μειώνοντας το κόστος εξαγωγής συμπερασμάτων διατηρώντας παράλληλα την ακρίβεια του μοντέλου.

ΣυγγραφείςPerplexity Research

Τα racks NVIDIA GB200 NVL72 με GPU NVIDIA Blackwell συνδεδεμένα μεταξύ τους μέσω NVLink 72 κατευθύνσεων είναι ιδανικά για την ανάπτυξη μεγάλων μοντέλων μείγματος ειδικών (MoE). Σε αυτήν την ανάρτηση ιστολογίου, περιγράφουμε τη ρύθμιση εξαγωγής συμπερασμάτων που εξυπηρετεί μοντέλα Qwen3 235B μετά την εκπαίδευση, τα οποία υποστηρίζουν ένα μερίδιο της κίνησης του Perplexity. Δείχνουμε πώς προσαρμόσαμε τη δική μας εσωτερική μηχανή εξαγωγής συμπερασμάτων για να αξιοποιήσουμε τους προηγμένους πυρήνες τανυστών και τη διασύνδεση υψηλής ταχύτητας των GPU NVIDIA Blackwell. Με αυτό το υλικό, διαχειριζόμαστε μεγαλύτερη κίνηση με χαμηλότερο κόστος χωρίς να θυσιάζουμε την ακρίβεια των υποκείμενων μοντέλων.

Ανάπτυξη σε GB200 NVL72

Τα racks GB200 NVL72 αποτελούνται από 18 κόμβους με 2 CPU NVIDIA Grace βασισμένες σε ARM και 4 GPU βασισμένες σε Blackwell, καθεμία εξοπλισμένη με 180 GB HBM. Οι 72 GPU διασυνδέονται μέσω NVLink και 18 ASIC διακοπτών NVLink, παρέχοντας εύρος ζώνης 1800 GB/s μεταξύ οποιωνδήποτε δύο ομοτίμων και μοιράζονται επαρκή μνήμη για τη φιλοξενία μοντέλων ενός τρισεκατομμυρίου παραμέτρων. Επιπλέον, οι προσαρμογείς ConnectX-7 InfiniBand παρέχουν επιπλέον εύρος ζώνης 400 Gb/s τόσο εντός των κόμβων ενός rack όσο και σε γειτονικά racks.

Για να διαχειριστούμε την κίνηση, επιλέξαμε να κάνουμε post-training και να εξυπηρετούμε μοντέλα Qwen. Σε αυτή την ανάρτηση, εστιάζουμε στο Qwen3 235B, αλλά πολλές από τις τεχνικές εξυπηρέτησης και τα χαρακτηριστικά απόδοσης που συζητούνται είναι παρόμοια με εκείνα των νεότερων μοντέλων Qwen3.5 397B και 122B, στα οποία μεταβαίνουμε. Όσον αφορά τον παραλληλισμό, η γραμμική προσοχή είναι παρόμοια με την πλήρη self-attention και η υπάρχουσα υλοποίηση του επιπέδου MoE μπορεί εύκολα να προσαρμοστεί ώστε να υποστηρίξει τους νέους όρους gate. Για να διατηρήσουμε σταθερό ρυθμό αποκωδικοποίησης ενώ μεγιστοποιούμε τη διαμεταγωγή, επιλέξαμε να αποδιασπάσουμε το prefill από το decode, αναπτύσσοντας διαφορετικές στρατηγικές παραλληλισμού για τους δύο τύπους κόμβων. Η επικοινωνία από τα prefiller προς τα decoder γίνεται μέσω InfiniBand, ενώ το bandwidth του NVLink διατίθεται για την επικοινωνία εντός των prefiller και των decoder. Τα χαρακτηριστικά απόδοσης των συσκευών Blackwell κατά την εκτέλεση πολλαπλασιασμού πινάκων και επικοινωνίας μεταξύ συσκευών, που εξετάζονται σε αυτή την ανάρτηση, καθορίζουν τις στρατηγικές sharding που χρησιμοποιούνται. Σε σύγκριση με τις GPU NVIDIA Hopper, βλέπουμε βελτιώσεις ανά kernel λόγω του μεγαλύτερου αριθμού streaming multiprocessors, της αυξημένης bandwidth μνήμης και των χαμηλότερων καθυστερήσεων peer-to-peer.

Αποσυζευγμένη προφόρτωση και αποκωδικοποίηση, με InfiniBand μεταξύ των προφορτωτών και των αποκωδικοποιητών και NVLink εντός κάθε ανάπτυξης.

Το TransferEngine μας, το οποίο υλοποιεί αποσυγκεντρωμένη προ-συμπλήρωση, χειρίστηκε αυθαίρετο και πιθανώς ανατιστοίχιστο κατακερματισμό σε προ-συμπληρωτές και αποκωδικοποιητές. Οι κρυφές μνήμες KV διατάσσονται στη μνήμη με σειρά HND, με τις κεφαλές στην κύρια διάσταση και τα tokens να διατηρούνται συνεχόμενα, επιτρέποντας σε μια κατακερματισμένη κρυφή μνήμη KV σε έναν προ-συμπληρωτή να διασπαστεί περαιτέρω ή να συνενωθεί εν πτήσει κατά τη μεταφορά στον κόμβο αποκωδικοποιητή.

Προ-συμπληρωτές

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

Κατά συνέπεια, διαπιστώσαμε ότι η ανάπτυξη tensor parallel είναι κατάλληλη, με το μοντέλο κατανεμημένο σε 4 GPU μέσα σε έναν μόνο κόμβο GB200 και τα projections και οι experts κατανεμημένα (TP=4, EP=4). Εφόσον τόσο η προσοχή όσο και τα MLPs είναι compute-bound, και τα δύο επωφελούνται από τον παραλληλισμό, κατανέμοντας τους experts και τα attention heads σε ξεχωριστά ranks. Περαιτέρω παραλληλισμός θα απέφερε φθίνουσες αποδόσεις, καθώς η βελτίωση της διαμεταγωγής από τη φιλοξενία λιγότερων experts σε κάθε rank (16 αντί για 32) δεν θα αντιστάθμιζε το πρόσθετο κόστος ενός 8-way all-reduce και το overhead του διαχωρισμού του κώδικα στην πλευρά του host σε δύο κόμβους, απαιτώντας επικοινωνία μέσω Ethernet.

Το Qwen3 235B έχει μόνο 4 key-value heads, γεγονός που απαιτεί τα projections k και v να αναπαράγονται σε ζεύγη ranks αν χρησιμοποιούνται 8 συσκευές. Θα μπορούσαμε να είχαμε εξετάσει πιο επιθετικό sharding για να μειώσουμε την ποσότητα μνήμης που απαιτείται για την αποθήκευση των weights σε κάθε rank, απελευθερώνοντας χώρο για περισσότερα tokens στην KV cache. Ωστόσο, διαπιστώσαμε ότι μια ευρύτερη ανάπτυξη δεν άξιζε τον κόπο.

Υποθέτοντας μήκος εισόδου περίπου 6000 tokens, σε καθέναν από τους 128 ειδικούς δρομολογούνται περίπου 6000 * 8 / 128 = 375 tokens, διασφαλίζοντας ένα πυκνό πρόβλημα για το MoE GEMM. Δεδομένου ότι αυτό κορεσμόει ήδη την υπολογιστική απόδοση της συσκευής, ο παραλληλισμός δεδομένων δεν είναι απαραίτητος για την προ-συμπλήρωση.

Παρά το τετραγωνικά αυξανόμενο κόστος προσοχής, οι προ-συμπληρωτές προσφέρουν συνεπή απόδοση, επιτρέποντας μια πρόχειρη εκτίμηση για τον αριθμό των tokens εισόδου που μπορούν να επεξεργαστούν από έναν κόμβο σε ένα δευτερόλεπτο. Βασιζόμενοι σε μετρήσεις που παρακολουθούν τον συνολικό αριθμό tokens εισόδου από αιτήματα, οι κόμβοι προ-συμπλήρωσης μπορούν να κλιμακωθούν προς τα πάνω για να διασφαλιστεί ότι η συνολική απόδοση προ-συμπλήρωσης έχει το κατάλληλο μέγεθος. Προκειμένου να αποφευχθεί η αναμονή σε ουρά, ο αριθμός των αντιγράφων προ-συμπλήρωσης αντιστοιχίζεται στον συνολικό αριθμό των tokens εισόδου που λαμβάνονται.

Αποκωδικοποιητές

Οι κόμβοι αποκωδικοποίησης λαμβάνουν τις κρυφές μνήμες KV από τους προ-συμπληρωτές και δημιουργούν tokens ένα προς ένα. Η αποκωδικοποίηση είναι γενικά δεσμευμένη στη μνήμη: με λίγα tokens εισόδου, ο πολλαπλασιασμός πινάκων εξαρτάται εξ ολοκλήρου από το κόστος φόρτωσης βαρών από την HBM στους Tensor Cores. Εκτός από τη χρήση διαφορετικής στρατηγικής κατακερματισμού, αρκετοί πυρήνες πρέπει να τροποποιηθούν ώστε να παραλληλοποιήσουν καλύτερα τους υπολογισμούς και τις προσβάσεις στη μνήμη.

Σε αντίθεση με το prefill, το sharding της προσοχής δεν είναι πλέον ωφέλιμο: ο διαχωρισμός των attention heads σε πολλαπλές συσκευές θα σήμαινε ότι υπάρχουν λιγότερες ευκαιρίες για παραλληλισμό μέσα σε μία μόνο συσκευή. Κατά συνέπεια, χρησιμοποιούνται μόνο data parallelism και expert parallelism: οι experts κατανέμονται σε πολλαπλές συσκευές, αλλά κάθε συσκευή διαχειρίζεται τη δική της KV cache και τα δικά της requests. Χωρίς tensor parallelism, το μέγεθος της KV cache ανά token σε μια συσκευή είναι μεγαλύτερο. Ωστόσο, απελευθερώνεται χώρος στη μνήμη με την τοποθέτηση λιγότερων experts σε έναν μόνο κόμβο. Σε αντίθεση με το Hopper, όπου περιορίσαμε το tensor parallelism εντός ενός μόνο NVLink domain σε κόμβο 8 GPU, στο Blackwell διαπιστώσαμε ότι η επέκταση σε πολλαπλούς κόμβους εντός ενός domain, με χρήση έως και 16 συσκευών, είναι ωφέλιμη.

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

Παρόμοια με τις προηγούμενες αναπτύξεις Hopper, χρησιμοποιούμε κερδοσκοπική αποκωδικοποίηση με επίπεδα MTP εκπαιδευμένα εσωτερικά για την αύξηση των ρυθμών αποκωδικοποίησης. Ευτυχώς, το υποκείμενο υλικό και τα πλαίσια προγραμματισμού είναι αρκετά παρόμοια ώστε να μοιράζονται πλήρως την υλοποίηση μεταξύ των δύο αρχιτεκτονικών.

Επικοινωνία εντός κόμβου και μεταξύ κόμβων

Η κύρια διαφορά μεταξύ των GB200 NVL72 και των προηγούμενων κόμβων Hopper είναι ο μεγάλος τομέας NVLink, ο οποίος επιτρέπει επικοινωνία από ομότιμο σε ομότιμο πέρα από το προηγούμενο όριο των 8 συσκευών. Παρόλο που οι συσκευές Blackwell έχουν αναπτυχθεί σε κόμβους 8 GPU, υπάρχει μεγάλη αξία στην κλιμάκωση σε πολλαπλούς κόμβους μέσω NVLink σε σύγκριση με το πιο αργό δίκτυο InfiniBand.

Στους κόμβους προ-συμπλήρωσης, βασιζόμαστε στην επικοινωνία all-reduce εντός των επιπέδων προσοχής και σε μια ειδική παράλληλη μείωση που μοιάζει πολύ με την all-reduce. Σε 4 GPU, αξιοποιούμε τόσο το NVLink όσο και το NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): εκτός από το εύρος ζώνης από ομότιμο σε ομότιμο, εκμεταλλευόμαστε επίσης μειώσεις στους διακόπτες NVLink για την περαιτέρω μείωση των καθυστερήσεων και την υλοποίηση γρήγορων μεταδόσεων. Στους κόμβους αποκωδικοποιητή, χρησιμοποιείται μια προσαρμοσμένη υλοποίηση αποστολής και συνδυασμού all-to-all μέσω NVLink. Οι πυρήνες έχουν υλοποιηθεί εσωτερικά χρησιμοποιώντας χαρτογραφήσεις CuTeDSL και cuMem ή χαρτογραφήσεις multicast.

All-Reduce

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

Σε συστήματα NVIDIA HGX H200 και GB200 NVL72 επιπέδου datacenter, οι GPU συνήθως συνδέονται μέσω NVLink Switches. Εκτός από τη δρομολόγηση, τα switches μπορούν να εκτελούν πράξεις μείωσης σε συνδεδεμένες συσκευές μέσω του SHARP. Αφού δημιουργηθούν memory mappings και καταχωρηθούν σε ένα multicast group χρησιμοποιώντας τα CUDA APIs, τα kernels μπορούν να χρησιμοποιούν τα multicast.ld_reduce και multicast.st για να συγκεντρώνουν και να εκπέμπουν τιμές μέσω των switches. Προκειμένου να δημιουργήσουμε μια βάση και επαναχρησιμοποιήσιμα components που μπορούν να συγχωνευθούν σε άλλα kernels, διατηρούμε εσωτερικά ένα CuTeDSL all-reduce kernel χρησιμοποιώντας αυτά τα primitives.

Σε ένα σύστημα με N GPU που μειώνουν B bytes, μια απλή υλοποίηση θα είχε έναν ομότιμο να φορτώνει τιμές από όλους τους άλλους ομότιμους, για ένα σύνολο N * (N - 1) * B bytes κίνησης ανάγνωσης. Μια πιο αποτελεσματική υλοποίηση θα χώριζε τα δεδομένα που πρόκειται να μειωθούν σε ομότιμους, με καθέναν να μειώνει ένα φέτα της εισόδου, μεταδίδοντάς το στη συνέχεια στα υπόλοιπα. Αυτό έχει ως αποτέλεσμα (N - 1) * (B / N) bytes να διαβάζονται σε έναν ομότιμο και να μεταδίδονται στα υπόλοιπα, για ένα σύνολο (N - 1) * B * 2 αναγνώσεις και εγγραφές, μειώνοντας την κίνηση μέσω των διακοπτών.

Κίνηση NVSwitch all-reduce με συσσώρευση στην πλευρά της GPU και μείωση με υποστήριξη switch.

Με το SHARP, η μείωση και η μετάδοση μπορούν να εκτελεστούν πιο αποτελεσματικά: αντί να διαβάζονται (N - 1) * (B / N) bytes σε μια συσκευή για τοπική συσσώρευση, μόνο B / N μετακινούνται από τον διακόπτη, καθώς εκτελεί ο ίδιος τη μείωση χρησιμοποιώντας δεδομένα από τους ομότιμους. Για τη μετάδοση, υπάρχει παρόμοια βελτίωση, καθώς ο αριθμός των συναλλαγών μεταξύ μιας GPU και του διακόπτη μέσω καναλιών NVLink μειώνεται σημαντικά. Χωρίς το SHARP, η συσσωρευτική συσκευή θα εκτελούσε (N - 1) * (B / N) συναλλαγές μέσω NVLink με τον διακόπτη, με τον διακόπτη να διαβάζει την ίδια ποσότητα δεδομένων από τους ομότιμους, για ένα σύνολο 2 * (N - 1) * (B / N) συναλλαγών. Με το SHARP, B / N συναλλαγές εκτελούνται μεταξύ της GPU και του διακόπτη, και περαιτέρω (N - 1) * (B / N) με τους ομότιμους, για ένα σύνολο B συναλλαγών.

Λόγω της απλότητάς του, το SHARP είναι ένα πολύτιμο εργαλείο, καθώς παρέχει μια απλή υλοποίηση υλικού για έναν αλγόριθμο. Παρόλο που οι μεταφορές μειώνονται κατά ένα θεωρητικό κλάσμα N / (2 * (N - 1)) (το οποίο αποτιμάται σε 33% με 4 ομότιμους), στην πράξη παρατηρούμε βελτίωση 10% τόσο στις καθυστερήσεις προ-συμπλήρωσης όσο και αποκωδικοποίησης σε συστήματα H200 και GB200 NVL72.

Καθυστέρηση αποστολής NVLink και NVLS σε H200 και GB200 με TP=4 και 16K tokens.

MoE Dispatch - Combine

Για τα μοντέλα MoE, οι πυρήνες αποστολής και συνδυασμού μετακινούν και ομαδοποιούν tokens για τα επακόλουθα προβλήματα MoE GEMM μεταξύ ομοτίμων, εκτελώντας μια σταθμισμένη συσσώρευση στη συνέχεια στον συνδυασμό. Έχουμε προσαρμόσει τους υπάρχοντες πυρήνες αποστολής και συνδυασμού στο Blackwell, μεταφέροντάς τους στο CuTeDSL, τροποποιώντας τις κατανομές μπλοκ και ειδικεύοντάς τους επιθετικά μεταξύ προ-συμπλήρωσης και αποκωδικοποίησης.

Ειδικός Παράλληλος

Ο ειδικός παράλληλος πυρήνας (EP) χρησιμοποιείται στους προ-συμπληρωτές. Δεδομένου ότι οι είσοδοι του αναπαράγονται σε όλες τις τάξεις, ο πυρήνας αποστολής πρέπει απλώς να επιλέξει τα tokens που δρομολογούνται σε ειδικούς στην τρέχουσα τάξη. Συγκεντρώνει πληροφορίες δρομολόγησης και προετοιμάζει tokens σε buffers που χρησιμοποιούνται ως είσοδοι στο MoE GEMM. Ο πυρήνας συνδυασμού εκτελεί πρώτα μια τοπική συσσώρευση μεταξύ των συνεισφορών των tokens που δρομολογούνται σε ειδικούς στην τρέχουσα τάξη, και στη συνέχεια εκτελεί μια all-reduce σε όλες τις τάξεις.

Για την αποκωδικοποίηση, ολόκληρος ο πυρήνας συγχωνεύεται σε έναν. Ο πυρήνας προ-συμπλήρωσης χωρίζεται σε πολλαπλούς πυρήνες, καθώς η δρομολόγηση και η all-reduce απαιτούν λιγότερα μπλοκ από το βήμα τοπικού συνδυασμού. Με το CuTeDSL, θα μπορούσαμε να κατασκευάσουμε μια γενική βιβλιοθήκη τόσο για το SHARP όσο και για την all-reduce NVLink και τον συγχρονισμό από ομότιμο σε ομότιμο, συνθέτοντάς την τόσο στους πυρήνες all-reduce όσο και στους ειδικούς παράλληλους πυρήνες.

Καθυστέρηση αποστολής και συνένωσης προφόρτωσης παράλληλης ως προς experts σε H200 και GB200 σε διαμορφώσεις παράλληλες ως προς experts.

Από πλευράς απόδοσης, παρατηρούμε ότι το Blackwell είναι σημαντικά ταχύτερο από το Hopper, λόγω βελτιωμένων ταχυτήτων μεταφοράς, υψηλότερου bandwidth μνήμης και καλύτερης υπολογιστικής απόδοσης. Κατανεμημένα σε 8 συσκευές και πολλαπλούς κόμβους σε GB200 (EP=8), τα kernels γίνονται ταχύτερα καθώς η τοπική συσσώρευση εκτελείται σε πολύ λιγότερα tokens σε κάθε συσκευή και, με το SHARP, το κόστος της μείωσης σε περισσότερα ranks κλιμακώνεται καλύτερα. Ωστόσο, στην πράξη περιορίζουμε τον παραλληλισμό σε 4 συσκευές, καθώς αυτές οι επιταχύνσεις δεν είναι καθολικές για όλα τα kernels.

Παράλληλα Δεδομένων και Παράλληλα Ειδικών

Ο πυρήνας παράλληλων δεδομένων και παράλληλων ειδικών (DP-EP) χρησιμοποιείται στους αποκωδικοποιητές παράλληλων δεδομένων. Μεταδίδει διαφορετικά tokens από όλες τις τάξεις σε ειδικούς, μεταφέροντας τα αποτελέσματα στις αρχικές τάξεις και συσσωρεύοντάς τα. Δεδομένου ότι υλοποιεί ένα αραιό πρόβλημα all-to-all, βασίζεται αποκλειστικά στο NVLink.

Στο Hopper, αυτός ο πυρήνας περιορίζεται σε 8 συσκευές εντός του τομέα NVLink ενός μόνο κόμβου. Ωστόσο, σε συστήματα GB200 μπορούμε να τον κλιμακώσουμε σε ολόκληρο το rack. Το μεγαλύτερο μέρος του κώδικα επαναχρησιμοποιείται. Η μόνη διαφορά είναι η χρήση λαβών fabric για την ανταλλαγή πληροφοριών ομοτίμων μέσω IMEX για την αρχική ρύθμιση.

Καθυστέρηση αποστολής και συνένωσης στο GB200 σε διαμορφώσεις παράλληλες ως προς τα δεδομένα και παράλληλες ως προς experts.

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

MoE GEMM

Τα μοντέλα MoE επωφελούνται από τον expert parallelism, καθώς το κόστος του πολλαπλασιασμού όλων των tokens με όλους τους experts μπορεί εύκολα να παραλληλιστεί σε πολλαπλές συσκευές. Με tensor parallelism στα prefillers, σε dense προβλήματα το όφελος είναι αρκετά άμεσο, καθώς κάθε rank χρειάζεται πλέον να εκτελεί λιγότερους υπολογισμούς. Στην περίπτωση του decode, το data parallelism προσφέρει ένα επιπλέον όφελος πάνω από το expert parallelism, καθώς ο μεγαλύτερος αριθμός παράλληλων requests δρομολογεί περισσότερα tokens σε κάθε expert, πυκνώνοντας τα προβλήματα.

Στην υλοποίησή μας, βασιζόμαστε προς το παρόν σε πυρήνες CUTLASS CUDA/C++ για τον πολλαπλασιασμό πινάκων. Τους υποβάλαμε σε benchmark σε εισόδους αραιής αποκωδικοποίησης με διάφορα σχήματα κβάντωσης και επίπεδα παραλληλισμού προκειμένου να αποφασίσουμε τη βέλτιστη στρατηγική κατακερματισμού για τους αποκωδικοποιητές. Στα παρακάτω benchmarks, όλοι οι ειδικοί ενεργοποιούνται με ένα ενιαίο token.

Καθυστέρηση Grouped MoE GEMM σε διαμορφώσεις παράλληλες ως προς experts και σε σχήματα κβάντισης σε H200 και GB200.

Διαπιστώσαμε ότι η κλιμάκωση 128 experts σε περισσότερα από 16 ranks αποφέρει φθίνουσες αποδόσεις με το CUTLASS, καθώς το κόστος του πολλαπλασιασμού 2 experts δεν είναι σημαντικά χαμηλότερο από του πολλαπλασιασμού 4. Υπάρχει σαφής βελτίωση στο Blackwell σε σχέση με το Hopper, ακόμη και με τη μη βέλτιστη στρατηγική block scaling. Εφόσον η αύξηση της καθυστέρησης κατά περίπου 5 us μεταξύ EP=8 και EP=16 του dispatch/combine αντισταθμίζεται από μείωση άνω των 10 us στο κόστος του GEMM, στα συστήματα GB200 η κατανομή των decoders σε 16 ranks δικαιολογείται, όπως επιβεβαιώνεται και από end-to-end benchmarks.

Κβάντωση

Το Blackwell εισάγει υποστήριξη υλικού για νέα σχήματα κβάντωσης 8-bit και 4-bit. Σε αντίθεση με το Hopper, το οποίο βασιζόταν σε παράγοντες κλιμάκωσης ανά τανυστή ή ανά μπλοκ, το Blackwell απαιτεί μικροκλιμάκωση για την επίτευξη της καλύτερης απόδοσης προ-συμπλήρωσης και αποκωδικοποίησης. Ενώ το σχήμα κλιμάκωσης μπλοκ που χρησιμοποιείται για μοντέλα όπως το DeepSeek ή το Kimi είναι διαθέσιμο, η μικροκλιμάκωση είναι πιο αποτελεσματική.

Έχουμε αναπτύξει το Qwen3 235B με το σχήμα κβάντωσης MXFP8, μετατρέποντας τα βάρη στατικά μετά την προσαρμογή (fine-tuning) του μοντέλου. Ο αντίκτυπος στην ακρίβεια ήταν παρόμοιος με τον αντίκτυπο της κλιμάκωσης μπλοκ με στοχαστική κβάντωση, αλλά η απόδοση που παραδόθηκε ήταν πολύ βελτιωμένη, όπως φαίνεται από τα microbenchmarks MoE GEMM. Έχουμε επίσης εξετάσει τα σχήματα κβάντωσης MXFP4 και NVFP4, αν και ο αντίκτυπος στην ακρίβεια χωρίς εκπαίδευση με επίγνωση κβάντωσης (Quantization-Aware Training) ήταν πολύ σημαντικός για την αρχική μετάβαση από το Hopper στο Blackwell. Σχεδιάζουμε να εξερευνήσουμε αυτές τις μορφές πιο διεξοδικά σε μελλοντική εργασία.

Απόδοση End-to-End

Υποβάλαμε σε benchmark τους αποκωδικοποιητές των αναπτύξεων Blackwell Qwen3 235B και τους συγκρίναμε με τις προηγούμενες αναπτύξεις μας στο Hopper. Σε αυτή τη ρύθμιση, εξετάσαμε την κλιμάκωση μπλοκ και στις δύο αναπτύξεις προκειμένου να εστιάσουμε στον αντίκτυπο του παραλληλισμού. Οι προ-συμπληρωτές TP=4 διαχωρίστηκαν για τις δύο αρχιτεκτονικές προκειμένου να απομονωθεί η απόδοση αποκωδικοποίησης. Το παρακάτω σχήμα απεικονίζει την απόδοση αποκωδικοποίησης υποθέτοντας έναν ρεαλιστικό ρυθμό αποδοχής πρόχειρων δεδομένων που παρέχεται από τα επίπεδα MTP μας.

Ταχύτητα αποκωδικοποίησης και απόδοση ανά GPU του Qwen3 235B FP8 σε διαμορφώσεις παράλληλες ως προς experts σε H200 και GB200, με την υπόθεση μήκους αποδοχής draft 0,8.

Στο Hopper, η κατανομή της ανάπτυξης σε περισσότερες από 8 GPU δεν είναι βιώσιμη, καθώς οι καθυστερήσεις μέσω InfiniBand, ιδιαίτερα σε EFA adapters, είναι σημαντικά μεγαλύτερες. Ωστόσο, στο Blackwell, επιτυγχάνουμε σημαντικά υψηλότερη διαμεταγωγή, χάρη στα μεγαλύτερα NVLink domains.

Πετυχαίνουμε μια αρχική υλοποίηση Blackwell γενικεύοντας τους υπάρχοντες πυρήνες Hopper και προωθώντας την απόδοση των πυρήνων που βασίζονται σε NVLink. Θα μειώσουμε περαιτέρω το κόστος εξυπηρέτησης του Qwen βελτιώνοντας την κβάντωση και προσαρμόζοντας την απόδοση αποκωδικοποίησης και την απόδοση προ-συμπλήρωσης των άλλων πυρήνων στην αλυσίδα.

Παραπομπές

Ανάρτηση ιστολογίου Transfer Engine

Ανάρτηση ιστολογίου CuTeDSL

Ανάρτηση ιστολογίου Prefill-Disagg

Ανάρτηση ιστολογίου Speculative Decoding

CUTLASS

NVLink

Παραπομπή

BibTeX
@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}