FastDeploy: PaddlePaddles Serving-Stack für ERNIE und Qwen auf sechs Beschleuniger-Familien

Welche Lücke FastDeploy schließt und für wen

Wer ein Sprachmodell hinter eine HTTP-Schnittstelle stellen will, trifft zwei Entscheidungen, die selten zusammen gedacht werden: das Serving-Framework und die Hardware. FastDeploy adressiert beide gleichzeitig. Das Repository beschreibt sich als Inferenz- und Deployment-Toolkit für LLMs und VLMs auf Basis von PaddlePaddle, lizenziert unter Apache-2.0, mit Linux und Python 3.10 bis 3.12 als Laufzeitvoraussetzungen. Die Zielgruppe lässt sich aus der Installationsstruktur ablesen: Für NVIDIA GPU, Kunlunxin XPU, Iluvatar CoreX, Enflame S60, Hygon DCU, Metax GPU und Intel Gaudi liegt jeweils eine eigene Anleitung unter docs/zh/get_started/installation/ vor. Wer eine dieser Beschleunigerkarten betreibt und ein Modell aus der PaddlePaddle-Familie einsetzen will, muss die Anbindung nicht selbst bauen. Der zweite Adressat sind Betreiber von ERNIE-4.5, ERNIE-4.5-VL oder PaddleOCR-VL, für die die Release Notes eigene Deployment-Abschnitte führen. Für beide Gruppen ist der Nutzen konkret: eine Kommandozeile statt eines eigenen Inference-Servers.

Prefill und Decode als getrennte Instanzrollen

Die Architektur folgt dem Muster, das als Prefill-Decode-Disaggregation bekannt ist. Das README nennt es lastverteilte PD-Zerlegung und beschreibt zwei Eigenschaften, die über die übliche Trennung hinausgehen: Kontext-Caching und dynamischer Rollenwechsel einer Instanz. Statt einer festen Zuordnung von Maschinen zu Prefill- oder Decode-Aufgaben kann eine Instanz ihre Rolle wechseln, was die Auslastung bei schwankender Anfragelast verbessern soll. Dazu kommt eine Transportschicht für den KV-Cache, die laut README zwischen NVLink und RDMA wählt. Das ist der Punkt, an dem die Entscheidung für oder gegen FastDeploy technisch hängt: Die Qualität dieser Übertragung bestimmt, ob die Zerlegung Gewinn bringt oder durch Netzwerklatenz aufgefressen wird. Das README macht dazu keine Zahlen. Wer die Zerlegung plant, sollte den Netzwerkpfad zwischen den Rollen zuerst vermessen.

OpenAI-kompatible API und vLLM-Schnittstelle

FastDeploy bietet laut README einen OpenAI-API-Service und Kompatibilität mit der vLLM-Schnittstelle, bereitgestellt über einen einzelnen Befehl. In der Danksagung heißt es, man habe Teile des vLLM-Codes übernommen, um die Schnittstellenkompatibilität zu wahren. Für bestehende Clients bedeutet das: Ein Wechsel des Backends erfordert in der Regel keine Anpassung des Anfrageformats. Die Grenze dieser Kompatibilität ist im Material nicht ausgeführt. Ob Streaming, Tool-Calling oder bestimmte Sampler-Parameter identisch funktionieren, lässt sich aus dem README nicht belegen. Wer darauf angewiesen ist, sollte die Endpunkte gegen die eigene Client-Bibliothek prüfen, bevor die Migration geplant wird. Dass die Topics des Repositories openai und vllm enthalten, bestätigt die Ausrichtung, nicht den Umfang der Abdeckung.

Quantisierung, Spekulation und Chunked Prefill

Die Beschleunigungsoptionen sind breit gestreut. Das README listet W8A16, W8A8, W4A16, W4A8, W2A16 und FP8 als unterstützte Formate. Release v2.5 ergänzt W4AFP8. Neben der Quantisierung stehen spekulative Dekodierung, Multi-Token-Prediction und Chunked Prefill zur Verfügung, jeweils mit eigener Dokumentationsseite unter docs/zh/features/. Jede dieser Optionen verändert das Verhältnis von Durchsatz zu Ausgabequalität oder Latenz, und keine davon ist im Material mit Messwerten belegt. Das ist keine Kritik an FastDeploy, sondern eine Einschränkung der Quellenlage: Wer eine dieser Techniken einschalten will, muss die Auswirkung auf seinem eigenen Modell und seiner eigenen Karte bestimmen. Die Feature-Dokumentation beschreibt nach der Repository-Struktur zu urteilen die Konfiguration, nicht die Ergebnisse.

Installation und Inbetriebnahme

Die Installation ist hardwareabhängig und läuft über die Seite, die zur eigenen Karte passt. Das README verlinkt für NVIDIA GPU auf ./docs/zh/get_started/installation/nvidia_gpu.md, für Kunlunxin XPU auf kunlunxin_xpu.md, für Iluvatar auf iluvatar_gpu.md, für Enflame auf Enflame_gcu.md, für Hygon auf hygon_dcu.md, für Metax auf metax_gpu.md und für Intel Gaudi auf intel_gaudi.md. Ein einheitlicher pip-Befehl für alle Plattformen ist im README nicht angegeben, und die konkreten Paketnamen stehen in den verlinkten Seiten, die hier nicht vorliegen. Nach der Installation führt der Weg über ./docs/zh/get_started/quick_start.md, das als Zehn-Minuten-Einstieg beschrieben wird. Für den Betrieb relevant sind zwei Dokumente: ./docs/zh/online_serving/README.md für den Dienst und ./docs/zh/online_serving/router.md für die Lastverteilung. Wer ohne Netzwerkzerlegung starten will, findet unter ./docs/zh/offline_inference.md den Einstieg ohne Server. Die Konfigurationsschlüssel für die einzelnen Beschleunigungstechniken stehen in den jeweiligen Feature-Seiten, nicht im README.

Wo FastDeploy die falsche Wahl ist

Die Abhängigkeit von PaddlePaddle ist der wichtigste Vorbehalt. FastDeploy ist kein frameworkneutraler Server. Wer seine Gewichte in einem anderen Format hält, muss den Konvertierungspfad prüfen; das README verweist dazu auf die Modellliste in ./docs/zh/supported_models.md und erwähnt die Unterstützung von Torch-Formaten als eigenen Punkt. Ein zweiter Vorbehalt betrifft die Hardwarebreite. Sieben Plattformen zu unterstützen bedeutet, dass keine davon die Aufmerksamkeit bekommt, die eine einzelne Implementierung erhielte. Ob die dokumentierten Quantisierungsformate auf jeder dieser Plattformen vollständig verfügbar sind, geht aus dem README nicht hervor. Wer auf einer exotischen Karte W2A16 oder FP8 einsetzen will, sollte das vor der Architekturentscheidung verifizieren. Drittens: Die Release-Kadenz ist hoch. Drei Releases zwischen November 2025 und April 2026, mit v2.5 allein über 170 Fehlerbehebungen und Leistungsoptimierungen laut Release Note. Diese Zahl stammt aus der Ankündigung, nicht aus einer unabhängigen Zählung. Wer einen gepinnten Stand braucht, muss die Upgrade-Kosten einplanen.

Der Unterschied zu vLLM

vLLM ist die naheliegende Alternative, und FastDeploy nennt es selbst als Referenz. Der Unterschied liegt nicht in der API, die absichtlich kompatibel gehalten wird, sondern im Modell- und Hardwarekatalog. vLLM ist auf NVIDIA-Hardware und die breite Landschaft der HuggingFace-Modelle ausgerichtet. FastDeploy ist auf die Modelle der PaddlePaddle-Familie und auf Beschleuniger ausgerichtet, die vLLM nicht oder nicht vollständig bedient: Kunlunxin XPU, Enflame GCU, Hygon DCU, Metax GPU. Wer ERNIE-4.5-VL auf einer Hygon-Karte betreiben will, hat mit vLLM keinen dokumentierten Pfad. Umgekehrt gilt: Wer ein beliebiges Community-Modell auf NVIDIA-Hardware einsetzt, findet dort die größere Abdeckung. Die Entscheidung ist damit keine Frage der Leistungsfähigkeit, sondern eine Frage der Schnittmenge aus Modell und Karte.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

FastDeploy steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Modifikation und Weitergabe unter Beibehaltung der Lizenzhinweise und Patenthinweise. Wer den Code übernimmt, sollte die im Repository enthaltene LICENSE-Datei selbst lesen; eine Rechtsberatung ersetzt das nicht. Praktisch wichtiger ist die Frage der Wartungslast. Der Default-Branch heißt develop, die letzte Aktivität im Repository datiert auf August 2026, das letzte Release v2.5.0 auf April 2026. Diese Kadenz bedeutet, dass ein gepinnter Stand regelmäßig veraltet und ein ungepinnter Stand regelmäßig bricht. Wer FastDeploy produktiv einsetzt, sollte die Version fixieren und die Release Notes vor jedem Sprung lesen, insbesondere die Abschnitte zu PD-Disaggregation und Quantisierung, die in v2.4 und v2.5 mehrfach angefasst wurden. Der Router aus ./docs/zh/online_serving/router.md ist die Komponente, deren Verhalten sich zwischen Releases am ehesten ändert, weil er direkt an der Lastverteilung hängt.

Redaktionelles Fazit

Sinnvoll ist FastDeploy für Teams, die ERNIE-4.5, ERNIE-4.5-VL oder PaddleOCR-VL auf chinesischer Beschleuniger-Hardware betreiben und dafür keine eigene Serving-Schicht schreiben wollen. Wer auf einer reinen NVIDIA-Flotte mit austauschbaren Modellen arbeitet, findet in vLLM den breiter abgedeckten Modellkatalog. Vor dem Rollout zu klären sind drei Dinge: ob das Zielmodell in docs/zh/supported_models.md auftaucht, welche Installationsseite unter docs/zh/get_started/installation/ zur eigenen Karte passt, und ob der Router aus docs/zh/online_serving/router.md einen Lastverteilungsmodus anbietet, der zu den eigenen SLOs passt.

Offizielle Quellen

1. License: Apache-2.0
2. PaddlePaddle/FastDeploy on GitHub
3. Project website
4. README
5. Releases