Spark NLP: Transformer-Inferenz als Spark-Stage, nicht als Python-Service

Ein Spark-Job, der Text annotiert, statt ein Dienst daneben

Das Problem, das Spark NLP adressiert, ist organisatorischer Natur. Viele Teams betreiben ihre NLP-Modelle als separaten Dienst, meist in Python, und schieben Daten per HTTP oder Batch über eine Systemgrenze. Sobald die Textmenge wächst, wird dieser Dienst zum Engpass und zum zweiten Betriebssystem im Haus. Spark NLP setzt an einer anderen Stelle an: Annotationen sind Spark-Transformationen, ausgeführt in den Executors desselben Jobs, der auch die Daten liest. Die README beschreibt die Bibliothek als NLP-Annotationsschicht auf Apache Spark, die Pipelines in verteilten Umgebungen skalieren lässt. Der Adressat sind Data-Engineering- und Plattform-Teams, die bereits Spark betreiben und keine zweite Laufzeit einführen wollen. Wer bisher pro Anfrage einen Python-Prozess startet, findet hier ein anderes Betriebsmodell vor, nicht bloß eine schnellere Variante desselben Modells.

Der Annotationsfluss: Pipeline, Annotator, AnnotatorModel

Die Architektur folgt der Spark-ML-Konvention. Eine Pipeline ist eine geordnete Folge von Annotatoren; jeder Annotator erzeugt eine Spalte mit Annotationen, die der nächste liest. Ein AnnotatorModel ist die trainierte, serialisierte Form eines Annotators. Die README zeigt das Ergebnis dieser Verkettung explizit: Nach dem Aufruf von pipeline.annotate(text) enthält das zurückgegebene Dictionary die Schlüssel entities, stem, checked, lemma, document, pos, token, ner, embeddings und sentence. Diese Liste ist der sichtbare Datenfluss. Ein Tokenizer erzeugt token, ein Lemmatizer liest token und schreibt lemma, ein NER-Modell liest Token- und Embedding-Spalten und schreibt ner. Die Reihenfolge in der Pipeline ist damit keine Konvention, sondern eine harte Abhängigkeit: Fehlt ein vorgelagerter Annotator, findet der nachgelagerte seine Eingabespalte nicht. Wer eigene Pipelines baut, muss diese Spaltennamen kennen, weil sie die Schnittstelle zwischen den Stufen bilden.

Vortrainierte Pipelines und der Modellkatalog

Der Einstieg über PretrainedPipeline('explain_document_dl', lang='en') lädt eine fertige Kette, ohne dass einzelne Annotatoren verdrahtet werden müssen. Die README nennt für diesen Fall die Beispielausgabe zu einem kurzen Text über die Mona Lisa: Die Entitätenerkennung liefert Mona Lisa, Leonardo, Louvre und Paris. Das ist kein Benchmark, sondern die dokumentierte Ausgabe eines Beispielaufrufs. Der Katalog umfasst laut README über 100000 vortrainierte Pipelines und Modelle in mehr als 200 Sprachen, an anderer Stelle im Dokument ist von 36000 Modellen in über 200 Sprachen die Rede. Diese beiden Zahlen widersprechen sich in der README, und wer den Katalog als Auswahlkriterium heranzieht, sollte die Modellübersicht auf sparknlp.org selbst durchsuchen, statt sich auf eine der Zahlen zu verlassen. Für den Betrieb relevanter ist die Frage, welche Lizenz das konkrete Modell trägt: Die Bibliothek selbst steht unter Apache-2.0, die Gewichte einzelner Modelle können anderen Bedingungen unterliegen. Das ist keine Rechtsberatung, aber ein Prüfpunkt, der vor dem Produktivgang anfällt.

Installation und die Paketwahl nach Spark-Version

Die Schnellstartanleitung beginnt mit einer Java-Abfrage und der Feststellung, dass es Java 8 oder 11 sein soll, Oracle oder OpenJDK. Danach folgen conda create -n sparknlp python=3.7 -y, conda activate sparknlp und pip install spark-nlp==6.4.2 pyspark==3.3.1. Die README hält fest, dass spark-nlp standardmäßig auf pyspark 3.x basiert. Die Version ist an eine Spark-Linie gebunden, und die Paket-Cheatsheet-Tabelle macht das explizit: Für die Spark-Versionen 3.0 bis 3.5 ist das CPU-Paket spark-nlp, das GPU-Paket spark-nlp-gpu, für Linux auf AArch64 spark-nlp-aarch64 und für Apple Silicon spark-nlp-silicon. Passend dazu variiert der Startaufruf: sparknlp.start(), sparknlp.start(gpu=True), sparknlp.start(aarch64=True), sparknlp.start(apple_silicon=True). Die Startfunktion nimmt laut README drei Parameter: gpu, apple_silicon und memory, wobei sparknlp.start(memory="16G") den Standard-Driver-Speicher ändert. Auffällig ist der Hinweis, dass M1/M2 und AArch64 als experimentell eingestuft sind. Wer auf diesen Plattformen plant, sollte das als Vorbehalt lesen und nicht als gleichwertigen Betriebsmodus.

Modellimport: TensorFlow, ONNX, OpenVINO, GGUF

Spark NLP beschränkt sich nicht auf eigene Gewichte. Die README listet Importpfade für TensorFlow, ONNX, OpenVINO und Llama.cpp im GGUF-Format. Das ist der Punkt, an dem das Projekt für Teams interessant wird, die bereits Modelle außerhalb des Spark-Ökosystems trainiert haben. Der Import ist allerdings kein Einzeiler: Ein fremdes Modell muss in die Annotator-Abstraktion überführt werden, und die Spalten, die es liest und schreibt, müssen zur restlichen Pipeline passen. Die README nennt die unterstützten Formate, beschreibt aber nicht, welche Modellarchitekturen je Format tatsächlich durchlaufen. Diese Lücke ist praktisch relevant, weil ONNX ein Containerformat ist und nicht jede Operation von jedem Backend abgedeckt wird. Wer ein spezifisches Modell importieren will, sollte vor der Architekturentscheidung einen einzelnen Annotator mit genau diesem Modell aufsetzen und prüfen, ob die Ausgabe plausibel ist.

Wo Spark NLP die falsche Wahl ist

Die Bindung an Spark ist der größte Kostenfaktor. Ein Anwendungsfall mit wenigen tausend Dokumenten pro Tag rechtfertigt keinen Spark-Cluster, und die JVM-Startzeit sowie die Serialisierung zwischen Treiber und Executors fallen unabhängig von der Datenmenge an. Für interaktive Szenarien mit einzelnen Anfragen und niedriger Latenz ist eine Python-Bibliothek ohne Cluster deutlich einfacher zu betreiben. Ein zweiter Grenzfall ist die Modellverfügbarkeit: Die README führt zwar eine lange Liste unterstützter Transformer-Architekturen von BERT über RoBERTa bis Mistral und Qwen2, doch das ist eine Liste der Architekturen, nicht der vortrainierten Gewichte. Wer ein bestimmtes, namentlich bekanntes Modell aus einer anderen Quelle benötigt, muss prüfen, ob es im Katalog existiert oder importiert werden kann. Drittens bleibt die Plattformunterstützung ungleich: GPU, AArch64 und Apple Silicon sind eigene Pakete mit eigenen Startflags, und die beiden letzteren sind laut README experimentell. Ein Team, das auf ARM-Hardware standardisiert, trägt hier ein zusätzliches Risiko.

Der Unterschied zu spaCy und Hugging Face

Die naheliegende Alternative für klassische NLP-Aufgaben ist spaCy, für Transformer-Inferenz Hugging Face Transformers. Der Unterschied liegt nicht in der Modellqualität, sondern im Ausführungsmodell. spaCy und Transformers sind Python-Bibliotheken, die im Prozess der aufrufenden Anwendung laufen. Skalierung entsteht dort durch mehr Prozesse, durch Batch-Verarbeitung oder durch einen vorgelagerten Dienst. Spark NLP verschiebt dieselbe Arbeit in die Spark-Ausführungsschicht, wodurch Partitionierung, Fehlertoleranz und Ressourcenverwaltung vom Cluster übernommen werden. Der Preis dafür ist die Kopplung: Wer Spark NLP nutzt, betreibt einen Spark-Cluster, hält die Java-Version im genannten Bereich und passt die Paketwahl an die Spark-Version an. Umgekehrt ist der JVM-Zugang ein Alleinstellungsmerkmal, das die README ausdrücklich betont: Dieselben Pipelines stehen nicht nur Python und R zur Verfügung, sondern auch Java, Scala und Kotlin. Für ein Scala- oder Kotlin-Backend, das Textverarbeitung ohnehin im selben Prozess erledigen soll, entfällt damit eine Sprachgrenze, die bei den Python-Alternativen bestehen bleibt.

Wartung, Versionen und was vor dem Einsatz zu klären ist

Die Release-Historie ist dicht getaktet: 6.4.0 im April 2026, 6.4.1 im Mai, 6.4.2 im Juni, bei einem letzten Push im September 2026. Diese Kadenz bedeutet, dass ein Upgrade-Pfad eingeplant werden muss. Die Kopplung an Spark-Versionen über die Paketnamen macht Upgrades zweistufig: Erst die Spark-Linie, dann das passende spark-nlp-Paket. Der Sprung auf eine neue Spark-Major-Version ist damit kein Bibliotheksupdate, sondern eine Plattformmigration. Die Lizenz der Bibliothek ist Apache-2.0, was die Einbettung in kommerzielle Produkte erlaubt. Das gilt nicht automatisch für die Gewichte der Modelle und Pipelines aus dem Katalog; deren Bedingungen sind pro Eintrag zu prüfen. Vor dem Produktivgang sind drei Dinge konkret zu verifizieren: dass die Zielumgebung Java 8 oder 11 bereitstellt, dass das gewählte Paket zur Spark-Version passt, und dass die Lizenz des ausgewählten Modells zum eigenen Verwendungszweck passt. Wer diese drei Punkte vorab klärt, vermeidet die häufigsten Nacharbeiten.

Redaktionelles Fazit

Spark NLP passt zu Teams, die Textverarbeitung in bestehende Spark-Jobs einbetten und dabei eine JVM-Pipeline statt eines separaten Python-Inferenzdienstes betreiben wollen. Wer nur gelegentlich einzelne Texte klassifiziert oder ausschließlich mit Hugging-Face-Modellen arbeitet, sollte bei Python-Bibliotheken bleiben. Vor dem Einsatz ist zu prüfen, ob die gewählte Modell- oder Pipeline-Variante unter der Apache-2.0-Lizenz steht und ob die Zielumgebung auf Java 8 oder 11 läuft, da die Schnellstartanleitung genau diese beiden Versionen nennt.

Offizielle Quellen

1. JohnSnowLabs/spark-nlp on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases