vLLM Expert-Parallel-Bereitstellung für DeepSeek und andere MoE-Modelle
vLLM Expert Parallel ist der Bereitstellungsmodus, den Sie verwenden sollten, wenn die Expertenschichten eines MoE-Modells auf GPUs aufgeteilt werden sollen, statt als eine große Tensor-Parallel-Gruppe behandelt zu werden. Im aktuellen vLLM lautet der Schalter --enable-expert-parallel. Die Größe der Expert-Parallelität wird indirekt über die Einstellungen für Tensor-Parallelität (TP) und Daten-Parallelität (DP) bestimmt: vLLM dokumentiert EP_SIZE = TP_SIZE × DP_SIZE.
Dieses Detail ist wichtig. Viele Runbooks suchen nach einem separaten „vLLM Expert-Parallel-Größen-Flag“ und versuchen dann, ein Flag zu erzwingen, das nicht Teil ihres gepinnten Builds ist. Beginnen Sie mit dem unterstützten Schalter, prüfen Sie vllm serve --help im exakten Image, das Sie bereitstellen werden, und treffen Sie TP-/DP-Entscheidungen anhand eines gemessenen Kapazitätsplans.
Dieses Playbook beschreibt einen sicheren Weg von einer DeepSeek-MoE-Bereitstellung auf einem einzelnen Knoten zu vLLM Expert Parallel über mehrere Knoten hinweg, einschließlich Backend-Auswahl, Ausgleich der Expertenlast, Abnahmetests und Fehlerisolierung. Es richtet sich an ML- und KI-Infrastrukturentwickler, nicht an eine Ein-Befehl-Demo.
Versionshinweis: Die MoE-Kernels, Abhängigkeiten und CLI-Oberfläche von vLLM entwickeln sich schnell weiter. Das unten dokumentierte Verhalten und die Befehle wurden am 16. Oktober 2026 anhand der offiziellen vLLM-Dokumentation geprüft. Pinnen Sie das vLLM-Image und überprüfen Sie die Flags anhand dieser gepinnten Version vor einem Produktions-Rollout.
Die kurze Antwort
| Frage | Praktische Antwort |
|---|---|
| Was aktiviert vLLM Expert Parallel? | Fügen Sie --enable-expert-parallel zu einer unterstützten MoE-Bereitstellung hinzu. |
| Wie wird die EP-Größe gewählt? | In der aktuellen vLLM-Dokumentation zu Expert Parallel wird sie als TP × DP berechnet; setzen Sie --tensor-parallel-size und --data-parallel-size, nicht ein geratenes EP-Größen-Flag. |
| Was ändert sich? | MoE-Expertenschichten werden auf EP-Ränge verteilt; Attention-Schichten folgen weiterhin dem dokumentierten TP-/DP-Verhalten. |
| Wann sollten Sie es verwenden? | Wenn ein MoE-Modell, die GPU-Topologie, das Kommunikationsnetzwerk und das Anfragevolumen die Verteilung der Expertenarbeit rechtfertigen. Es ist kein allgemeiner Beschleunigungsschalter für dichte Modelle. |
| Wo sollten Sie anfangen? | Ein Knoten, feste Modellrevision, fester Traffic-Trace und eine Basislinie ohne EP. |
Der offizielle vLLM-Leitfaden zur Expert-Parallel-Bereitstellung ist die maßgebliche Quelle für dieses Feature. Er beschreibt Expert Parallel als die Verteilung von MoE-Experten über GPUs, üblicherweise zusammen mit Datenparallelität.
Was vLLM Expert Parallel tatsächlich verändert
Ein MoE-Modell leitet jedes Token an eine kleine Teilmenge vieler Expertennetzwerke weiter. Ohne Expert Parallel bildet das dokumentierte MoE-Verhalten von vLLM eine Tensor-Parallel-Gruppe über DP × TP. Mit --enable-expert-parallel verwenden die Expertenschichten stattdessen Expert Parallel, während Attention-Schichten ihr eigenes TP-/DP-Verhalten beibehalten.
Betrachten Sie als konkrete Topologie TP=2 und DP=4:
| Komponente | Parallelverhalten bei aktiviertem EP |
|---|---|
| Expertenschichten | Eine EP-Gruppe über 8 Ränge; Experten werden auf diese GPUs verteilt. |
| Attention-Schichten | Tensor-Parallel-Gruppen von 2 innerhalb jeder der 4 DP-Gruppen. |
| Effektive EP-Größe | 2 × 4 = 8. |
Deshalb ist vLLM Expert Parallel kein Ersatz dafür, zu entscheiden, wie Attention, KV-Cache-Kapazität, Anfrageparallelität und Netzwerktopologie zusammenpassen. Es ist ein Teil eines verteilten Serving-Designs.
Eine umfassendere Einführung dazu, welches Multi-GPU-Muster zu einem Workload passt, finden Sie unter vLLM Multi-GPU-Inferenz: Einrichtung von Tensor- und Pipeline-Parallelität.
Das vLLM-Expert-Parallel-Flag und die Frage nach dem „Größen-Flag“
Die aktuelle öffentliche Dokumentation nennt das kanonische Aktivierungs-Flag:
--enable-expert-parallel
Sie gibt außerdem an, dass die Expert-Parallel-Größe aus den Größen für Tensor- und Datenparallelität berechnet wird:
EP_SIZE = TP_SIZE × DP_SIZE
Das Muster der vLLM-Dokumentation für Expert-Parallel-Bereitstellungen lautet daher:
vllm serve <MODEL> --tensor-parallel-size <TP> --data-parallel-size <DP> --enable-expert-parallel
Kopieren Sie keine separate Option --expert-parallel-size aus einem alten Issue, einem internen Wrapper oder einem anderen Serving-Stack und nehmen Sie an, dass sie für Ihren vLLM-Build gilt. Behandeln Sie die Frage „Wie groß ist mein EP?“ als Topologiefrage:
- Wählen Sie die Anzahl der GPUs und Knoten, die einer Serving-Gruppe zur Verfügung stehen.
- Wählen Sie TP für das Sharding der Attention-Schichten und das lokale Modellverhalten.
- Wählen Sie DP für unabhängige Engine-Kapazität und Anfrageverteilung.
- Aktivieren Sie EP für die MoE-Schichten.
- Bestätigen Sie die berechnete Prozesstopologie in den Startprotokollen und führen Sie einen Lasttest durch.
Die vLLM-Serve-CLI-Referenz ist die endgültige Instanz für Flags in einer bestimmten Release-Version.
Vor der Bereitstellung: die Bereitschaftsprüfung
Führen Sie diese Prüfungen durch, bevor Sie Expert Parallel für ein Start- oder Durchsatzproblem verantwortlich machen.
| Prüfpunkt | Was zu prüfen ist | Warum es wichtig ist |
|---|---|---|
| Version | Fixieren Sie den vLLM-Container, den CUDA-Stack und die Modellrevision auf allen Workern. | Ein gemischtes Image oder ein nicht übereinstimmendes Wheel kann ein Topologieproblem in einen undurchsichtigen Kernel-Fehler verwandeln. |
| Modell-Fit | Berücksichtigen Sie Modellgewichte, KV-Cache, Runtime-Workspaces und alle redundanten Experten, bevor Sie die GPU-Anzahl wählen. | EP macht Speicherplanung nicht überflüssig. |
| Abhängigkeiten | Befolgen Sie die aktuellen Voraussetzungen für vLLM-EP-Kernel, einschließlich DeepEP und DeepGEMM, sofern die Dokumentation dies verlangt. | Die Dokumentation zur Expertenparallelität führt diese als Voraussetzungen auf. |
| Fabric | Überprüfen Sie die GPU-Topologie auf einem Knoten und die GPU-Kommunikation zwischen Knoten vor der ersten Produktionsanfrage. | EP fügt jedem MoE-Forward-Pass Kommunikation hinzu. |
| Steuerungsnetzwerk | Machen Sie die Adresse des primären Knotens, die Erreichbarkeit des Ports und die Auswahl der NIC explizit. | Eine intakte Datenebene hilft nicht, wenn die Erkennung der Steuerungsebene auf die falsche Schnittstelle verweist. |
| Baseline | Erfassen Sie Latenz, Durchsatz, Fehlerrate und GPU-Speicherreserve ohne EP. | Sie benötigen eine vergleichbare Antwort auf die Frage: „Hat EP geholfen?“ |
Für die Speicherseite dieses Prüfpunkts nutzen Sie den Leitfaden zu GPU-Speicheranforderungen für LLMs, um vor der Reservierung eines größeren Clusters ein Kapazitätsarbeitsblatt zu erstellen.
Halten Sie das erste Experiment einfach
Verwenden Sie eine Modellrevision, einen bekannten Tokenizer, einen Anfrage-Mix, einen Parallelitätsrahmen und einen festen Satz von Start-Flags. Vermeiden Sie es, Quantisierung, Cache-Einstellungen, Hardware und All-to-All-Backend im selben Test zu ändern. Eine saubere Baseline ermöglicht es, festzustellen, ob die vLLM-Expertenparallelität den nutzbaren Durchsatz verändert oder nur den Engpass verlagert hat.
DeepSeek-MoE-Bereitstellung auf einem einzelnen Knoten
Der aktuelle vLLM-Leitfaden verwendet DeepSeek-V3-0324 als Beispiel für einen einzelnen Knoten mit einwegigem TP, achtfachem DP und aktiviertem EP:
vllm serve deepseek-ai/DeepSeek-V3-0324 --tensor-parallel-size 1 --data-parallel-size 8 --enable-expert-parallel
Die Dokumentation erläutert den beabsichtigten Effekt: Attention-Gewichte werden über DP-Ränge repliziert, während Expertengewichte auf GPUs aufgeteilt werden. Sie verwendet einen H200- oder H20-Knoten mit acht GPUs als Beispieltopologie und empfiehlt Teams mit anderer Hardware, die eigene Eignung zu validieren, statt das Beispiel als allgemeingültige Größenempfehlung zu betrachten.
Verwenden Sie diesen Befehl als Ausgangspunkt für die Topologie, nicht als Copy-and-Paste einer Produktionskonfiguration. Bevor Sie einen Endpunkt bereitstellen:
- Bestätigen Sie, dass der Server einen fehlerfreien Bereitschaftszustand erreicht, ohne stillschweigend auf einen anderen Kernelpfad zurückzufallen.
- Führen Sie einen Korrektheitstest mit bekannten Prompts und erwartetem Schema- oder Tool-Call-Verhalten durch.
- Erzeugen Sie eine kleine konstante Last, anschließend einen Burst und ein Sample mit langem Kontext.
- Vergleichen Sie p50 und p99 für die Zeit bis zum ersten Token, die Inter-Token-Latenz, den Output-Durchsatz, die Speicherreserve und Fehler mit der Nicht-EP-Baseline.
- Speichern Sie den Startbefehl, den Image-Digest, die Modellrevision, die Treiberversion und den Metrik-Snapshot zusammen mit dem Benchmark-Ergebnis.
Wenn Sie die umgebende API-Schicht noch aufbauen, behandelt dieser vLLM-Bereitstellungsleitfaden den OpenAI-kompatiblen Serverpfad getrennt von der Entscheidung zur MoE-Parallelität.
Wählen Sie das All-to-All-Backend nach Workload, nicht nach Gewohnheit
vLLM stellt --all2all-backend für die Kommunikation der Expertenparallelität bereit. Der offizielle Leitfaden beschreibt derzeit einen universell einsetzbaren Standard sowie spezialisierte DeepEP-Modi. Passen Sie das Backend an den tatsächlich gemessenen Datenverkehr an.
| Backend | Dokumentierter Einsatzzweck | Auswirkung auf die Bereitstellung |
|---|---|---|
allgather_reducescatter |
Allgemeine EP- und DP-Bereitstellungen | Eine sinnvolle Kontrollkonfiguration vor spezialisierter Optimierung. |
deepep_high_throughput |
Multi-Knoten-Workloads mit überwiegendem Prefill | Bewerten Sie dies, wenn lange Prompts und aggregierter Durchsatz das Serviceziel dominieren. |
deepep_low_latency |
Multi-Knoten-Workloads mit überwiegender Decodierung | Bewerten Sie dies, wenn die Latenz generierter Tokens wichtiger ist als maximaler Prefill-Durchsatz. |
| FlashInfer-NVLink-Modi | MNNVL- / NVLink-spezifische Systeme | Verwenden Sie diese nur, wenn Hardware und aktuelle vLLM-Dokumentation den Anforderungen des Backends entsprechen. |
Es geht nicht darum, das am schnellsten wirkende Label auszuwählen. Testen Sie stattdessen jeweils ein Backend anhand Ihres Prompt-Längen-Mix, Ihrer Parallelität, Ihrer Fabric und Ihres SLO. Messen Sie neben Tokens pro Sekunde auch die Auswirkung auf die Tail-Latenz.
vLLM-Expertenparallelität über mehrere Knoten: ein Zwei-Knoten-Muster
Für die Bereitstellung über mehrere Knoten verwendet die vLLM-Dokumentation einen primären Knoten, der API-Traffic verarbeitet, und einen sekundären --headless-Worker-Knoten. Das Folgende ist eine parametrisierte Form dieses dokumentierten Musters. Ersetzen Sie Adressen und Anzahlen durch Werte, die dem Cluster entsprechen, den Sie tatsächlich getestet haben.
Auf dem primären Knoten:
export GLOO_SOCKET_IFNAME=eth0
vllm serve deepseek-ai/DeepSeek-V3-0324 --all2all-backend deepep_low_latency --tensor-parallel-size 1 --enable-expert-parallel --data-parallel-size 16 --data-parallel-size-local 8 --data-parallel-address <PRIMARY_NODE_IP> --data-parallel-rpc-port 13345 --api-server-count 8
Auf dem zweiten Knoten:
export GLOO_SOCKET_IFNAME=eth0
vllm serve deepseek-ai/DeepSeek-V3-0324 --all2all-backend deepep_low_latency --tensor-parallel-size 1 --enable-expert-parallel --data-parallel-size 16 --data-parallel-size-local 8 --data-parallel-start-rank 8 --data-parallel-address <PRIMARY_NODE_IP> --data-parallel-rpc-port 13345 --headless
Die Zahlen sind wichtig:
--data-parallel-sizeist die gesamte DP-Größe in der Serving-Gruppe.--data-parallel-size-localist die Anzahl der auf diesem Knoten gestarteten DP-Ränge.--data-parallel-start-rankist die kumulierte lokale DP-Größe der vorherigen Knoten.- Der sekundäre Knoten ist headless, weil der primäre Knoten Client-Anfragen verarbeitet.
Für InfiniBand-Cluster weist der aktuelle vLLM-Leitfaden ausdrücklich auf GLOO_SOCKET_IFNAME=eth0 hin, damit die Erkennung verteilter Gruppen über die ausgewählte Ethernet-Steuerungsschnittstelle erfolgt. Dies ersetzt nicht die Validierung von NCCL und der GPU-zu-GPU-Kommunikation über Knoten hinweg.
Abnahme-Checkliste für mehrere Knoten
Bevor Sie Kundenverkehr an eine vLLM-Expert-Parallel-Gruppe mit mehreren Knoten senden, weisen Sie Folgendes nach:
- Jeder Worker löst dieselbe Modellrevision auf und startet mit dem vorgesehenen Rang.
- Der primäre Knoten kann die konfigurierte RPC-Adresse und den Port von jedem Peer aus erreichen.
- Die verteilte Gruppe wird nach einem sauberen Neustart wiederholt initialisiert.
- Eine Anfrage wird bei geringer Parallelität und anschließend unter einer anhaltenden Trace-Last abgeschlossen.
- Ein absichtlich verzerrter Anfragenmix verursacht weder stille Hänger noch einen Einbruch der Tail-Latenz.
- Der Neustart eines Test-Workers erzeugt ein beobachtbares, umsetzbares Fehlersignal statt unbefristet wartender Anfragen.
Der Leitfaden zur Fehlerbehebung für verteiltes vLLM empfiehlt, die GPU-Kommunikation zwischen Knoten zu überprüfen und Kommunikationsumgebungsvariablen auf jedem Knoten verfügbar zu machen. Wenn Sie Ray verwenden, dokumentiert er außerdem, dass die Host-IP-Konfiguration von vLLM und Ray aufeinander abgestimmt bleiben muss.
Fügen Sie Expert-Parallel-Lastverteilung erst hinzu, wenn Sie ein Ungleichgewicht beobachten
MoE-Routing ist in der Produktion nicht immer gleichmäßig verteilt. Der Expert Parallel Load Balancer (EPLB) von vLLM erfasst Lastdaten und verteilt Expert-Zuordnungen regelmäßig über EP-Ränge neu. Die Funktion wird mit --enable-eplb aktiviert.
vllm serve Qwen/Qwen3-30B-A3B --enable-expert-parallel --enable-eplb --eplb-config '{"window_size":1000,"step_interval":3000,"num_redundant_experts":2,"log_balancedness":true}'
Beginnen Sie ohne EPLB, sofern Sie keine Hinweise auf stark ausgelastete Experten, ungleichmäßige Arbeit pro Rang oder anhaltende Tail-Latenz haben, die mit Routing-Verzerrungen korreliert. EPLB kann redundante Experten verwenden, und diese zusätzlichen Expertenkopien verbrauchen GPU-Speicher. Betrachten Sie es als Optimierung mit Kapazitätskosten, nicht als obligatorisches vLLM-Flag für Expert Parallel.
Für ein erstes Experiment:
- Protokollieren Sie die Auslastung pro Rang und die Anfrage-Latenz ohne EPLB.
- Aktivieren Sie das Balancedness-Logging für ein kontrolliertes Zeitfenster.
- Fügen Sie die kleinste Redundanzeinstellung hinzu, die in das Speicherbudget passt.
- Vergleichen Sie Tail-Latenz, Durchsatz, Speicherreserve und Auswirkungen der Neuausbalancierung unter demselben Trace.
- Halten Sie den Rollback-Befehl und die Deployment-Konfiguration ohne EPLB bereit.
Ein Benchmark-Plan, der die richtige Frage beantwortet
Betrachten Sie einen EP-Rollout nicht als erfolgreich, nur weil der Prozess startet. Verwenden Sie für jeden Vergleich dieselbe Modellrevision, dieselben Prompts, Ausgabelimits, Parallelität, Quantisierung, Cache-Einstellungen und Hardware-Reservierung.
| Test | Was er aufzeigt | Entscheidungssignal |
|---|---|---|
| Decodierung mit kurzen Prompts und hoher Parallelität | Verhalten von Collectives und Warteschlangen auf der Decodierungsseite | p99-Latenz zwischen Tokens und Durchsatz generierter Tokens |
| Prefill mit langen Prompts | Prefill- und All-to-All-Overhead | p99-Zeit bis zum ersten Token und aggregierter Prefill-Durchsatz |
| Trace mit Expertenverzerrung | Ob eine kleine Gruppe von Experten stark ausgelastete Ränge erzeugt | Rangungleichgewicht, Wachstum der Warteschlange und Argumente für EPLB |
| Kapazitätstest mit langem Kontext | Speicherreserve unter realistischer Cache-Auslastung | OOM-Rate, Zulassungsfehler und sichere Parallelität |
| Neustart-/Partitionierungsübung | Betriebsverhalten bei einem ausgefallenen Peer oder blockierten Port | Zeit bis zur Erkennung, Sichtbarkeit von Fehlern und Wiederherstellungspfad |
Erfassen Sie mehr als den durchschnittlichen Durchsatz. Ein Deployment, das den Mittelwert verbessert, aber die p99-Latenz verschlechtert oder die Wiederherstellung undurchsichtig macht, ist kein eindeutiger Gewinn für die Produktion.
Fehlerbehebung bei vLLM-Expert-Parallel-Deployments
| Symptom | Wahrscheinliche Ursache | Erster Schritt |
|---|---|---|
Unbekanntes Argument --expert-parallel-size |
Runbook und installierte vLLM-Version stimmen nicht überein | Führen Sie vllm serve --help aus, pinnen Sie den Build und verwenden Sie die für diesen Build dokumentierte TP/DP-Dimensionierung. |
| Der Start schlägt bei einem EP-Kernel oder All-to-All-Backend fehl | Fehlende oder inkompatible EP-Abhängigkeit bzw. Container-Stack | Prüfen Sie die aktuellen EP-Voraussetzungen und das Container-Image erneut, statt mehrere Start-Flags gleichzeitig zu ändern. |
| Multi-Node-Worker hängen während der Initialisierung | Adresse der Steuerungsebene, Port, NIC oder Prozessgruppen-Konfiguration | Überprüfen Sie Erreichbarkeit, ausgewählte Schnittstellen, Rank-Berechnung und verteilte Kommunikation, bevor Sie Kernel optimieren. |
| Die erste Anfrage hängt, nachdem die Worker bereit zu sein scheinen | Node-übergreifende GPU-Kommunikation ist nicht funktionsfähig | Führen Sie die Kommunikationsprüfungen des Anbieters/vLLM aus und untersuchen Sie anschließend die NCCL- und Schnittstellenkonfiguration. |
| Der Durchsatz verbessert sich nicht | Traffic-Mix, Fabric, Batch-Verhalten oder die Konfiguration auf der Attention-Seite sind weiterhin der Engpass | Vergleichen Sie anhand von Prompt-Länge und Parallelität mit der Baseline; ändern Sie jeweils nur eine Topologievariable. |
| Nicht genügend Speicher nach Aktivierung von EPLB | Der Speicher für redundante Experten hat die Sicherheitsreserve aufgebraucht | Reduzieren Sie die Redundanz oder reservieren Sie mehr Speicherreserve; wiederholen Sie den Kapazitätstest. |
| Ein Rank ist dauerhaft langsamer | Schieflage beim Experten-Routing oder ungleichmäßige Host-/Fabric-Leistung | Messen Sie zuerst die Last auf Rank-Ebene; ziehen Sie EPLB nur in Betracht, wenn die Daten dies stützen. |
Die wichtige Gewohnheit ist eine eng eingegrenzte Diagnose. Halten Sie Modell, Image, Traffic-Trace und Topologie konstant, während Sie einen Faktor ändern. So wird aus einem vagen Bericht wie „EP ist langsam“ eine umsetzbare Beobachtung.
Ablauf für den Produktions-Rollout
- Baseline erstellen. Führen Sie das Ziel-MoE-Modell ohne EP aus und bewahren Sie Metriken, Logs und Startmanifest auf.
- EP auf einem Node aktivieren. Verwenden Sie
--enable-expert-parallelmit einer explizit gewählten TP/DP-Topologie. - Qualität und Kapazität prüfen. Kontrollieren Sie Ausgabeverhalten, Speicherreserve, p50/p99-Latenz und nachhaltigen Durchsatz.
- Backend nach Traffic-Profil auswählen. Vergleichen Sie das allgemeine Backend nur mit demselben Trace mit einem relevanten spezialisierten Backend.
- EPLB nur bei belastbaren Nachweisen hinzufügen. Nutzen Sie Daten zur Ausgewogenheit und zur Speicherreserve, um redundante Experten zu rechtfertigen.
- Auf mehrere Nodes erweitern. Überprüfen Sie Rank-Zuweisung, Steuerungsnetzwerk und Node-übergreifende GPU-Kommunikation, bevor Sie den Traffic erhöhen.
- Fehlerübung durchführen. Testen Sie Neustart, Port-Ausfall und einen fehlerhaften Worker, bevor Produktions-Traffic die Lücke für Sie findet.
- Pinnen und dokumentieren. Speichern Sie Versionen, Start-Flags, Topologie, Metriken und Rollback-Schritte neben dem Deployment.
Wann Sie die MoE-Serving-Schicht nicht selbst hosten sollten
vLLM Expert Parallel ist die richtige Investition, wenn die Kontrolle über Modellplatzierung, Datenpfad, Hardwarereservierung und Serving-Verhalten Teil der Produktanforderungen ist. Es passt schlecht, wenn das Team hauptsächlich Modellzugriff benötigt und GPU-Auslastung, verteiltes Netzwerk, Upgrade-Tests und Wiederherstellung im Bereitschaftsdienst nicht selbst verantworten kann.
Bevor Sie einen größeren Cluster reservieren, vergleichen Sie das Betriebsmodell mit einem verwalteten API-Weg in GPU-Cloud vs. Modell-API: Wann Self-Hosting tatsächlich Geld spart. Die richtige Antwort kann ein Hybrid sein: Hosten Sie die Workload, die Infrastrukturkontrolle benötigt, selbst und verwenden Sie für den Rest eine API-Schicht.
FAQ
Aktiviert --enable-expert-parallel vLLM Expert Parallel?
Ja. Die aktuelle vLLM-CLI dokumentiert --enable-expert-parallel als Verwendung von Expert Parallelism anstelle von Tensor Parallelism für MoE-Schichten.
Wie lautet das vLLM-Flag für die Expert-Parallel-Größe?
Für den aktuell dokumentierten Deployment-Ablauf wird die EP-Größe aus --tensor-parallel-size und --data-parallel-size abgeleitet: EP_SIZE = TP × DP. Überprüfen Sie die genaue CLI-Oberfläche in Ihrer gepinnten vLLM-Version, statt von einem separaten Größen-Flag auszugehen.
Ersetzt Expert Parallel Tensor Parallelism überall?
Nein. EP verändert die Strategie für MoE-Expertenschichten. Das Verhalten der Attention-Schichten hängt weiterhin von den gewählten TP- und DP-Werten ab.
Sollte jedes DeepSeek-Deployment EPLB aktivieren?
Nein. Weisen Sie zunächst unter repräsentativem Traffic eine unausgewogene Expertenlast nach und bestätigen Sie, dass die Speicherkosten redundanter Experten in den Cluster passen. EPLB ist eine Optimierung, keine Standardanforderung.
Welches All-to-All-Backend sollte ich verwenden?
Beginnen Sie mit der aktuellen vLLM-Empfehlung und testen Sie dann das Backend, das zu Ihrem Workload-Profil passt: eine universelle Option für breite Kompatibilität, einen DeepEP-Modus mit hohem Durchsatz für prefill-lastigen Traffic oder einen DeepEP-Modus mit niedriger Latenz für decode-lastigen Traffic.
Referenzen
- Dokumentation zur vLLM-Expert-Parallel-Bereitstellung
- Dokumentation zur vLLM-Datenparallel-Bereitstellung
- vLLM-serve-CLI-Referenz
- Fehlerbehebung bei verteilter vLLM-Bereitstellung
Nächster Schritt: Verwenden Sie den Single-Node-Befehl als kontrollierte Validierungsumgebung, erfassen Sie eine Baseline und übernehmen Sie nur die Topologie, die den SLO verbessert, der Ihnen tatsächlich wichtig ist. So wird vLLM Expert Parallel zu einer Produktionsentscheidung statt zu einem Flag, von dem Sie hoffen, dass es schneller ist.
