PaddlePaddle/ERNIE: Modellfamilie und ERNIEKit im Detail

Zehn Varianten, ein Toolkit: was das Repository abdeckt

Das Repository bündelt zwei Dinge, die man getrennt betrachten muss. Erstens die Gewichte und Modellkarten der ERNIE-4.5-Familie, zweitens ERNIEKit, ein Trainings- und Inferenz-Toolkit auf Basis von PaddlePaddle. Laut README umfasst die Familie zehn Varianten: vier reine Sprachmodelle (ERNIE-4.5-300B-A47B-Base und die instruktionstrainierte Fassung, dazu ERNIE-4.5-21B-A3B-Base und die instruktionstrainierte Fassung), vier Vision-Language-Modelle (ERNIE-4.5-VL-424B-A47B-Base und die instruktionstrainierte Fassung, ERNIE-4.5-VL-28B-A3B-Base und die instruktionstrainierte Fassung) sowie zwei dichte Modelle, von denen ERNIE-4.5-0.3B-Base im Auszug sichtbar ist. Die Kontextlänge gibt die Tabelle mit 128K für alle aufgeführten Zeilen an. Die Zielgruppe ist damit klar umrissen: Teams, die ein vortrainiertes Modell dieser Größenordnung feintunen oder als Dienst betreiben wollen, und nicht jemand, der eine Bibliothek zum Zusammenbauen eigener Architekturen sucht. Die Modellkarten verweisen auf Hugging Face (huggingface.co/baidu) und AI Studio als Bezugsquellen.

MoE mit getrennten Parametern pro Modalität

ERNIE 4.5 ist als Mixture-of-Experts-Familie beschrieben, mit 47B und 3B aktiven Parametern und einem größten Modell mit 424B Gesamtparametern. Die Bezeichnung A47B und A3B im Modellnamen bezieht sich auf diese aktive Parameterzahl, nicht auf die Gesamtgröße. Der architektonische Kern laut README ist eine heterogene Modalitätsstruktur: Parameter werden über Modalitäten hinweg geteilt, gleichzeitig behält jede Modalität eigene Parameter. Das erklärt, warum dieselbe Familie sowohl reine Textmodelle als auch VL-Modelle enthält, ohne dass die multimodale Erweiterung die Textleistung verdrängt. Für die Praxis heißt das: Die VL-Varianten sind keine nachträglich angeflanschten Bildencoder, sondern teilen sich den MoE-Unterbau mit den Sprachmodellen. Wer nur Text verarbeitet, kann trotzdem auf die VL-Checkpoints zugreifen, sollte aber beachten, dass die 424B-Variante deutlich mehr Speicher bindet als die 300B-Textvariante. Das README nennt 47 Prozent Model FLOPs Utilization beim Pretraining des größten Sprachmodells. Das ist eine Angabe zum Pretraining des Anbieters, keine Zusage für das Feintuning auf eigener Hardware.

Was ERNIEKit in den Versionen 1.0 bis 1.5 nachgeliefert hat

Die Release-Historie im README liest sich als Folge von Erweiterungen, die jeweils an ein konkretes Modell oder einen konkreten Trainingspfad gebunden sind. ERNIEKit v1.0 erschien im Juni 2025 zusammen mit der ERNIE-4.5-Veröffentlichung. v1.1 im September 2025 brachte SFT und LoRA für die ERNIE-4.5-VL-Serie. v1.2 ergänzte eine WebUI für Training und Konversation mit den 28B- und 424B-VL-Modellen, das Query-Response-Format in Trainingsdaten und Unterstützung für iluvatar-GPU-Hardware. v1.3 fügte SFT und Function-Call-Training für ERNIE-4.5-21B-A3B-Thinking hinzu. v1.4 erweiterte den Datenfluss um eine padding-freie Strategie, bei der Sequenzen innerhalb eines Batches gepackt werden, um Padding zu vermeiden, GPU-Speicher zu sparen und das Training zu beschleunigen; außerdem SFT für PaddleOCR-VL-0.9B. v1.5 schließlich unterstützt SFT und Function-Call-Training für ERNIE-4.5-VL-28B-A3B-Thinking. Auffällig ist die Reihenfolge: Thinking-Varianten und VL-Modelle kommen später, die Toolchain wächst also stückweise mit dem Modellportfolio. Wer eine dieser Varianten einsetzen will, sollte die Versionsnummer der Toolkit-Release gegen die eigene Zielarchitektur prüfen, statt die neueste Version als universell kompatibel anzunehmen.

Datenfluss, Padding und die Hardwarefrage

Der padding-freie Datenfluss aus v1.4 ist die technisch interessanteste Ergänzung, weil er eine reale Speichergrenze adressiert. Üblicherweise wird ein Batch auf die längste Sequenz aufgefüllt, wodurch kurze Beispiele Rechenzeit auf Fülltoken verbrennen. Das Packen mehrerer Sequenzen in eine Batch-Sequenz entfernt diesen Overhead. Der Preis ist ein aufwendigerer Datenpfad mit Aufmerksamkeitsmasken, und das README nennt keine Zahlen dazu, wie viel Speicher oder Zeit das in welcher Konfiguration spart. Hier ist die Dokumentation dünn: Wer den Effekt auf die eigene Sequenzlängenverteilung wissen will, muss selbst messen. Ähnlich verhält es sich mit der Hardware. Die Release Notes zu v1.2 nennen iluvatar-GPU-Unterstützung, was zeigt, dass die Toolchain nicht auf einen einzigen Beschleuniger festgelegt ist. Gleichzeitig bleibt PaddlePaddle die Grundlage für Training und Inferenz; das README verweist für den Betrieb auf FastDeploy. Eine reine PyTorch-Umgebung ist damit kein unterstützter Pfad, sondern ein Bruch in der Toolchain.

Inbetriebnahme: was im Material tatsächlich steht

Das README gibt für den Einstieg keine vollständige Kommandozeile her. Es verlinkt stattdessen auf einen Cookbook-Ordner, auf docs/erniekit.md für das Training und auf das FastDeploy-Repository für das Deployment. Für SFT speziell existiert mit docs/paddleocr_vl_sft.md ein dokumentiertes Beispiel, das an das PaddleOCR-VL-0.9B-Modell gebunden ist. Das ist ein konkretes Rezept, aber es beschreibt ein anderes Basismodell als die großen ERNIE-4.5-Varianten, und ob sich die Parameter eins zu eins übertragen, lässt sich aus dem Material nicht bestätigen. Wer die Dokumentation als Installationsanleitung liest, wird enttäuscht: Es gibt keinen sichtbaren pip-Befehl, keine versionsgepinnte Abhängigkeitsliste und keine Angabe, welche PaddlePaddle-Version zu welcher ERNIEKit-Version passt. Das ist bei einem Toolkit dieser Art ein relevanter Aufwandsposten, weil PaddlePaddle, CUDA-Treiber, Toolkit-Version und Modellvariante gemeinsam passen müssen. Vor dem ersten Trainingslauf sollte man deshalb klären, ob die Cookbook-Beispiele auf die eigene Modellgröße übertragbar sind oder ob sie nur für die kleineren Varianten gedacht sind.

Wo ERNIEKit die falsche Wahl ist

Die offensichtliche Grenze ist die Framework-Bindung. Wer seine Trainingspipelines auf PyTorch aufgebaut hat, mit eigenen DataLoadern, eigenen Distributed-Launchern und eigenem Checkpoint-Handling, muss für ERNIEKit einen parallelen Pfad aufbauen und pflegen. Das ist kein Detail, sondern eine dauerhafte Betriebslast. Die zweite Grenze ist die Modellgröße. Die 424B-Variante mit 47B aktiven Parametern lässt sich nicht auf einer einzelnen Workstation betreiben, und auch die 300B-Variante verlangt eine verteilte Konfiguration. Die Release Notes nennen Fehlerkorrekturen im AutoParallel-Pfad, darunter ein Problem mit pp, recompute und moe sowie ein Checkpoint-Speicherfehler und ein LoRA-Bug bei 128k-Kontext. Solche Einträge sind normal für verteiltes Training, sie zeigen aber, dass die parallelen Pfade noch in Bewegung sind. Ein dritter Punkt betrifft die Modellvielfalt: Wer ein Basismodell außerhalb der ERNIE-Familie feintunen will, findet hier keinen Nutzen, weil die Rezepte auf die mitgelieferten Checkpoints zugeschnitten sind.

Alternativen und der tatsächliche Unterschied

Die naheliegende Alternative ist, dieselben Checkpoints über die Hugging-Face-Bibliothek zu laden und mit einem frameworkeigenen Trainer zu arbeiten. Der Unterschied liegt nicht im Modell, sondern im Trainingspfad: ERNIEKit liefert verteilte Parallelisierung, Checkpoint-Verwaltung und die padding-freie Datenpipeline als zusammenhängendes Paket, während ein generischer Trainer diese Teile selbst zusammensetzen muss. Für kleinere Varianten wie ERNIE-4.5-0.3B-Base oder ERNIE-4.5-21B-A3B kann das der einfachere Weg sein, weil die Parallelisierungsprobleme dort gar nicht auftreten. Umgekehrt skaliert der generische Weg nicht ohne Weiteres auf 300B oder 424B. Die zweite Alternative ist der reine API-Zugriff über ERNIE Bot, den das README als eigenen Dienst verlinkt. Damit entfällt jede Trainings- und Betriebsarbeit, aber auch jede Kontrolle über Gewichte und Daten. Die Entscheidung ist also nicht Modell gegen Modell, sondern Kontrolle gegen Aufwand.

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

Der Code steht unter Apache-2.0, und das README gibt an, dass die Modelle ebenfalls unter Apache 2.0 öffentlich zugänglich sind. Das ist eine permissive Ausgangslage, aber die Angabe im README ist keine Rechtsberatung, und wer die Gewichte kommerziell einsetzt, sollte die Bedingungen auf den Modellkarten bei Hugging Face selbst nachlesen, weil Code-Lizenz und Gewichte-Lizenz getrennte Dokumente sind. Zur Wartung: Die Release-Kadenz ist dicht, zwischen Juni und November 2025 erschienen sechs Toolkit-Versionen. Das bedeutet regelmäßige Updates, aber auch, dass sich APIs und unterstützte Modellvarianten zwischen Versionen verschieben. Wer eine bestimmte Variante produktiv nutzt, sollte die Toolkit-Version pinnen und die Release Notes vor jedem Sprung lesen, insbesondere die Bug-Fix-Einträge zu AutoParallel und Checkpointing. Der Default-Branch ist release/v1.5, nicht main, was den Release-orientierten Charakter des Repositories bestätigt.

Redaktionelles Fazit

Wer ERNIE 4.5 mit eigenen Daten nachtrainieren will und PaddlePaddle bereits im Stack hat, findet in ERNIEKit einen konkreten Einstieg über die SFT- und LoRA-Rezepte der Cookbook- und docs-Ordner. Wer eine frameworkneutrale Trainingspipeline braucht oder die Modelle ausschließlich über Hugging Face beziehen will, sollte zuerst prüfen, ob die Checkpoints und der Trainingspfad ohne PaddlePaddle-Abhängigkeit nutzbar sind. Vor jedem Adoptionsentscheid sind zwei Dinge zu verifizieren: das tatsächliche GPU-Memory-Profil der gewählten Variante und ob die lizenzierte Nutzung der Gewichte denselben Bedingungen folgt wie der Code.

Offizielle Quellen

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