Vier lokale KI-Modelle, 2.213 echte Spam-Mails und ein klarer Überraschungssieger: In diesem Spam-Benchmark erreicht Laya Multilingual eine Erkennungsrate von 99,86 Prozent. Noch interessanter ist allerdings der Vergleich mit den anderen Modellen, insbesondere bei Geschwindigkeit und Ressourcenbedarf.
Getestet wurden Julia-1, Laya Multilingual, Kev-0.8B und Kev-4B. Alle vier sind spezialisierte KI-Modelle, die Texte analysieren und Entscheidungen treffen können, ohne dafür einen vollständigen Antworttext generieren zu müssen.
Der Benchmark wurde lokal auf CPU-Hardware durchgeführt. Die Testdaten stammen aus echten Spam-E-Mails mehrerer Thunderbird-Postfächer.
Spam-Benchmark: Die Ergebnisse im Überblick
Alle vier Modelle wurden mit vier und acht CPU-Threads getestet. Für den direkten Vergleich diente ein gemeinsamer Datensatz aus 32 Spam-Nachrichten.
| KI-Modell | Spam erkannt | Recall | p50 | p95 |
|---|---|---|---|---|
| Julia-1 | 9/32 | 28,12 % | 344 ms | 991 ms |
| Laya Multilingual | 31/32 | 96,88 % | 885 ms | 2.594 ms |
| Kev-0.8B | 3/32 | 9,38 % | 3.487 ms | 8.523 ms |
| Kev-4B | 23/32 | 71,88 % | 15.171 ms | 34.592 ms |
p50 ist die mediane Antwortzeit. p95 bezeichnet die Latenz, unterhalb der 95 Prozent der gemessenen Anfragen liegen. Die Werte stammen aus dem gemeinsamen 32-Nachrichten-Test.
Laya Multilingual liefert die beste Kombination aus Spam-Erkennungsrate und Antwortzeit. Julia-1 ist zwar schneller, übersieht aber einen erheblichen Teil des Spam-Korpus. Kev-4B erreicht eine deutlich bessere Erkennungsrate als Julia, benötigt dafür jedoch wesentlich mehr Zeit.
Da der gemeinsame Vergleich nur 32 Nachrichten umfasst, handelt es sich zunächst um eine Momentaufnahme. Die große Differenz zwischen den Modellen ist interessant, aber nicht automatisch auf beliebige andere Datensätze übertragbar.
Die vier KI-Modelle im Detail
Julia-1 – Kompakter multilingualer Encoder
Julia-1 wurde von Supersonic Labs entwickelt und besitzt rund 144,3 Millionen Parameter.
Technische Grundlage ist mmBERT-small, ein multilingualer Transformer-Encoder. Julia ergänzt diesen um Komponenten, mit denen sich vorgegebene Antwortmöglichkeiten anhand eines Textes bewerten lassen.
Das Modell ist für Klassifikation, Routing und andere Entscheidungen mit klar definierten Antwortoptionen gedacht. Es unterstützt außerdem einen ONNX-Export und die Ausführung über WebGPU.
Im Spam-Benchmark war Julia-1 mit 344 Millisekunden Median das schnellste Modell. Allerdings erkannte es lediglich 9 der 32 Spam-Nachrichten.
Das Ergebnis verdeutlicht, dass eine geringe Latenz allein noch keinen brauchbaren Klassifikator ergibt. Julia-1 kann bei anderen Klassifikationsaufgaben durchaus bessere Ergebnisse erreichen. Seine Entwickler berichten beispielsweise von 94 Prozent Genauigkeit auf einem kleinen AG-News-Test mit vier Kategorien.
Modell: Julia-1 auf Hugging Face
Laya Multilingual – Der Überraschungssieger
Laya Multilingual stammt von Convai Innovations und basiert auf mmBERT-base. Das Modell besitzt rund 322 Millionen Parameter und wurde für mehrsprachige Klassifikations- und Entscheidungsaufgaben entwickelt.
Anders als ein klassisches generatives Sprachmodell erzeugt Laya keine Antwort Token für Token. Stattdessen verarbeitet es den Eingabetext und die vorgegebenen Entscheidungsoptionen in einem Durchlauf.
Die Architektur verwendet einen bidirektionalen Encoder mit einem zusätzlichen Decision Head. Dadurch lassen sich Fragen wie „Ist diese Nachricht Spam?“ direkt als Klassifikationsaufgabe formulieren.
Die Entwickler geben Unterstützung für mehr als 100 Sprachen an. Das Modell verwendet standardmäßig ein Eingabelimit von 1.024 Tokens und kann mit angepasster Konfiguration längere Texte bis zu 8.192 Tokens verarbeiten.
Im gemeinsamen Spam-Benchmark erkannte Laya 31 von 32 Nachrichten und benötigte dafür im Median 885 Millisekunden.
Aufgrund dieses Ergebnisses wurde anschließend der gesamte bereinigte Spam-Korpus mit Laya verarbeitet.
Modell: Laya Multilingual auf Hugging Face
Quellcode: Laya auf GitHub
Kev-0.8B – Kompaktes Qwen-basiertes Entscheidungsmodell
Kev-0.8B wurde von Jared Palmer entwickelt und verwendet Qwen3.5-0.8B-Base als Grundlage.
Kev ist eine Familie spezialisierter Entscheidungsmodelle. Die Modelle verwenden einen eingefrorenen Qwen-Backbone, einen trainierten LoRA-Adapter und einen sogenannten Pointer Head, um Antwortmöglichkeiten zu bewerten.
Kev-0.8B ist die kleinste Variante der Familie und richtet sich insbesondere an Umgebungen mit begrenztem Speicher.
Im Gegensatz zu Laya basiert Kev auf einem ursprünglich autoregressiven Sprachmodell. Für die Entscheidungsaufgaben wird jedoch keine normale Textgenerierung verwendet: Der Backbone verarbeitet den Eingabetext, und der zusätzliche Head bewertet die Antwortoptionen.
Mit nur 3 von 32 erkannten Spam-Nachrichten lieferte Kev-0.8B im vorliegenden Test die niedrigste Erkennungsrate aller vier Modelle.
Auch die mediane Antwortzeit von 3.487 Millisekunden war wesentlich höher als bei Laya.
Das ist kein allgemeines Urteil über Kev-0.8B, sondern das Ergebnis dieser konkreten Spam-Klassifikationsaufgabe.
Modell: Kev-0.8B auf Hugging Face
Kev-4B – Mehr Parameter, aber nicht das beste Ergebnis
Kev-4B verwendet Qwen3.5-4B-Base als Grundlage und besitzt ungefähr vier Milliarden Parameter.
Wie die kleinere Kev-Variante setzt es auf einen LoRA-Adapter und einen Pointer Head. Die Modelle wurden für Klassifikation, Dokumentbewertung, Routing und andere strukturierte Entscheidungsaufgaben entwickelt.
Kev-4B besitzt damit mehr als das Zehnfache der Parameter von Laya Multilingual.
Im Spam-Benchmark erkannte Kev-4B immerhin 23 der 32 Spam-Nachrichten. Das entspricht einem Recall von 71,88 Prozent.
Allerdings benötigte es im Median 15.171 Millisekunden pro Klassifikation. Die p95-Latenz lag sogar bei mehr als 34 Sekunden.
Damit war Kev-4B im gemessenen Test wesentlich langsamer als Laya, obwohl seine Spam-Erkennungsrate niedriger ausfiel.
Bei anderen Aufgaben kann sich dieses Verhältnis umkehren. Die Kev-Entwickler veröffentlichen beispielsweise Ergebnisse für Dokumententscheidungen, Regelinterpretation und Klassifikationsaufgaben außerhalb der Trainingsverteilung.
Modell: Kev-4B auf Hugging Face
Quellcode für beide Kev-Modelle: Kev auf GitHub
Warum ist Laya trotz weniger Parametern schneller?
Der Architekturvergleich liefert einen interessanten Ansatz zur Erklärung der Messergebnisse.
Julia-1 und Laya verwenden bidirektionale Transformer-Encoder. Solche Modelle sind darauf ausgelegt, einen vollständigen Text zu analysieren und daraus Repräsentationen für Klassifikationsaufgaben abzuleiten.
Kev verwendet dagegen einen Qwen3.5-Backbone, der ursprünglich aus der Familie generativer Sprachmodelle stammt. Zwar verzichtet Kev bei diesen Entscheidungsaufgaben auf die eigentliche Textgenerierung, muss aber weiterhin den wesentlich größeren Backbone ausführen.
Hinzu kommen Unterschiede bei den Modellgrößen, verwendeten Operatoren und der jeweiligen Inferenzimplementierung.
Die geringere Parameterzahl von Laya kann somit zur besseren CPU-Performance beitragen. Ob sie der entscheidende Faktor ist, lässt sich aus den vorliegenden Messungen allein jedoch nicht beweisen.
Ein größeres Modell ist nicht automatisch der bessere Klassifikator. Entscheidend ist, wie gut Modellarchitektur und Training zur konkreten Aufgabe passen.
Spam-Benchmark: Laya mit 2.213 echten Nachrichten
Der vollständige Testkorpus wurde aus mehreren realen Thunderbird-Spam-Ordnern aufgebaut.
Nach dem Einlesen und Bereinigen der Daten ergab sich folgende Zusammensetzung:
- 3.254 ursprünglich gefundene E-Mails
- 3.252 erfolgreich geparste Nachrichten
- 2 fehlerhafte Nachrichten übersprungen
- 1.039 inhaltliche Duplikate entfernt
- 2.213 verbleibende, vorläufig als Spam klassifizierte E-Mails
- 5.403.409 Bytes normalisierter Text
Die Bereinigung ist relevant, weil Spam-Kampagnen häufig identische Inhalte mehrfach verschicken. Ohne Deduplizierung könnten einzelne Kampagnen im Ergebnis überrepräsentiert sein.
Anschließend wurden sämtliche 2.213 Nachrichten mit Laya Multilingual klassifiziert.
| Messgröße | Ergebnis |
|---|---|
| Verarbeitete Spam-Nachrichten | 2.213 |
| Als Spam erkannt | 2.210 |
| Nicht erkannt | 3 |
| Spam-Recall | 99,86 % |
| Verarbeitungsfehler | 0 |
| Gesamtlaufzeit | 46,1 Minuten |
| Maximaler RAM-Verbrauch | 5,39 GiB |
Von 2.213 Spam-Nachrichten wurden lediglich drei nicht als Spam erkannt.
Der gesamte Korpus wurde in 46,1 Minuten verarbeitet, ohne einen einzigen Verarbeitungsfehler. Der maximale gemessene RAM-Verbrauch lag bei 5,39 GiB.
Für ein vollständig lokal ausgeführtes Modell auf CPU-Hardware ist das ein interessantes Resultat – insbesondere, wenn man es mit den erheblich höheren Latenzen der größeren Kev-Variante vergleicht.
Was bedeuten 99,86 Prozent Spam-Recall tatsächlich?
Bei diesem Ergebnis ist eine wichtige Unterscheidung notwendig: Spam-Recall ist nicht dasselbe wie allgemeine Klassifikationsgenauigkeit.
Der Testkorpus bestand ausschließlich aus Nachrichten, die aufgrund ihrer Herkunft aus den Spam-Ordnern vorläufig als Spam eingestuft wurden.
Es wurden keine legitimen E-Mails, auch HAM genannt, als separate Gegenprobe getestet.
Deshalb können für diesen Benchmark noch keine belastbaren Aussagen über folgende Kennzahlen getroffen werden:
- False-Positive-Rate: Anteil legitimer E-Mails, die fälschlicherweise als Spam eingestuft werden.
- Precision: Anteil tatsächlicher Spam-Nachrichten unter allen als Spam klassifizierten Nachrichten.
- Accuracy: Anteil insgesamt korrekt klassifizierter Nachrichten.
- F1-Score: Harmonisches Mittel aus Precision und Recall.
Ein Klassifikator, der grundsätzlich jede Nachricht als Spam markiert, würde auf diesem Datensatz sogar 100 Prozent Recall erzielen. Er wäre dennoch kein brauchbarer Spamfilter.
Hinzu kommt, dass die ursprünglichen Spam-Labels noch nicht vollständig manuell überprüft wurden. Die Ergebnisse beziehen sich daher auf den vorläufig annotierten Datensatz.
Diese Einschränkungen ändern nichts an den gemessenen Werten, sind aber entscheidend für deren Interpretation.
Klassische Spamfilter und KI-Entscheidungsmodelle
KI-basierte Spam-Klassifikation ist nicht zwangsläufig ein Ersatz für bestehende Filterverfahren.
Systeme wie Apache SpamAssassin kombinieren beispielsweise unterschiedliche Signale und Bewertungsverfahren zur Spam-Erkennung.
Auch der Zeitpunkt der Klassifikation spielt eine Rolle. Manche unerwünschten Nachrichten lassen sich bereits während der SMTP-Verarbeitung erkennen und ablehnen, ohne ihren Inhalt durch ein KI-Modell analysieren zu müssen.
Ein praktisches Beispiel dafür habe ich bereits in meinem Beitrag Rejecting Google Groups Spam Mail with Stalwart Mail beschrieben.
Die hier getesteten KI-Modelle untersuchen hingegen den Inhalt einer Nachricht. Dadurch können sie potenziell auch Fälle bewerten, die sich nicht mit einer einfachen Absender- oder Header-Regel entscheiden lassen.
Wie gut eine Kombination beider Ansätze funktioniert, lässt sich aus diesem Benchmark allein noch nicht ableiten.
Fazit: Laya überzeugt im lokalen Spam-Benchmark
Die Messergebnisse zeigen deutliche Unterschiede zwischen den vier getesteten Entscheidungsmodellen.
Julia-1 bietet die niedrigste Latenz, erkennt aber nur einen kleinen Teil des Spam-Korpus. Kev-0.8B liefert in diesem Test sowohl bei der Geschwindigkeit als auch bei der Erkennungsrate schwache Ergebnisse. Kev-4B erkennt deutlich mehr Spam, benötigt dafür aber erheblich mehr Rechenzeit.
Laya Multilingual liefert die überzeugendste Kombination aus Geschwindigkeit und Spam-Recall.
Besonders bemerkenswert ist das Ergebnis des vollständigen Korpus: 2.210 von 2.213 als Spam eingeordneten Nachrichten erkannt, bei 46,1 Minuten Gesamtlaufzeit und maximal 5,39 GiB RAM.
Eine allgemeine Aussage darüber, welches Modell der beste Spamfilter ist, lässt sich daraus noch nicht ableiten. Dafür fehlen insbesondere Tests mit legitimen Nachrichten und überprüften Labels.
Der Benchmark zeigt aber bereits, dass spezialisierte, vergleichsweise kleine Entscheidungsmodelle auf CPU-Hardware eine interessante Alternative zu deutlich größeren Modellen darstellen können.
Benchmark vom 8. Oktober 2026. Alle Tests wurden lokal mit einem wiederverwendbaren Go-Benchmark-Framework durchgeführt. Die privaten E-Mail-Daten wurden nicht veröffentlicht oder in ein Git-Repository übertragen. Die hier vorgestellten Modellarchitekturen und Spezifikationen stammen aus den jeweiligen öffentlichen Modellbeschreibungen.
#SpamAPI #SpamBenchmark #SpamErkennung #AI, #LLM, #LocalAI, #LayaMultilingual, #Go, #CPUInference, #MachineLearning