Spark3-Leak: iFLYTEKs 1,7B- und 4B-Kleinmodelle werden in vLLM integriert

Spark3 hat keine öffentlichen Gewichte, keine Modellkarte, keine Ankündigung – und doch ist diese Woche ein Pull Request in der vLLM-Inferenz-Engine eingegangen, der zwei Modelle, Spark3-1.7B und Spark3-4B, in bemerkenswertem Detail beschreibt. Pull Request #53373 im vLLM-Repository, „[Model] Add Spark3 Model“, fügt native Unterstützung für die Spark3-Architektur hinzu: Sliding-Window-Attention, ein steuerbares Denk-Budget mit vier Stufen, natives Million-Token-Kontextfenster in beiden Größen und eine Modell-ID, die auf iFLYTEK verweist. Nichts davon ist vom Hersteller bestätigt, und nichts wurde veröffentlicht. Dies ist ein Beitrag, der den aktuellen Wissensstand zusammenfasst: Der Pull Request ist echt, und alles, was die Modelle angeblich tun sollen, ist unverifiziert, bis iFLYTEK – oder wer auch immer Spark3 herausbringt – tatsächlich Gewichte veröffentlicht.

Das Leck: ein Pull-Request, der sich wie ein Pflichtenheft liest

Das Signal ist ein offener vLLM-PR, eingereicht von einem GitHub-Nutzer namens KnightYao (ein Beitragender mit Sitz in Hefei, der die University of Science and Technology of China angibt), und Stand 23. August 2026 wurde er noch nicht gemerged. Ein vLLM-Maintainer forderte am 22. August Änderungen an mit dem Hinweis „hold for discussions.“ Der PR ist früh und umstritten, was für diese Art von Integration normal ist – und er ist für einen Framework-PR über ein Modell, das niemand außerhalb des Labors herunterladen kann, auch ungewöhnlich detailliert.

Der Diff betrifft acht Dateien. Er fügt eine Spark3ForCausalLM-Implementierung im Modell-Executor von vLLM hinzu, eine native Spark3Config, die in vLLMs Konfigurations- und Modell-Registries registriert ist, Unterstützung für Sliding-Window-Attention und volle Attention sowie head-weise Gating der Attention-Ausgabe, Tensor- und Pipeline-paralleles Laden von Gewichten und einen Spark3-XML-Tool-Parser, damit die Tool-Aufrufe des Modells strukturiert dekodiert werden können. Außerdem wird eine Zeile zur Dokumentation der unterstützten Modelle von vLLM hinzugefügt, die den Checkpoint als XHToken/Spark3-1.7B auflistet. Die Beschreibung behauptet sogar, dass die Integration benchmarkt wurde: 500 gleichzeitige Anfragen, 100 % Erfolg, ungefähr 106 Anfragen pro Sekunde und 13,5K Ausgabe-Token pro Sekunde auf dem Testsetup des Autors. Diese Zahlen stammen vom Autor des PRs selbst, nicht von einem unabhängigen Benchmark, und sollten genau so verstanden werden.

Warum iFLYTEK die offensichtliche — aber unbestätigte — Muttergesellschaft ist

Nichts in der PR nennt den Anbieter. Aber die Checkpoint-ID, die sie registriert, XHToken/Spark3-1.7B, befindet sich unter der XHToken-Organisation auf Hugging Face, und diese Organisation gehört iFLYTEK: Die Organisationsseite listet sie als Unternehmen, verlinkt auf opensource.iflytek.com und zeigt derzeit null öffentliche Modelle und null öffentliche Datensätze. „XH“ ist die natürliche Abkürzung für 星火 (Xinghuo, „Spark“), iFLYTEKs Modellfamilie. Hinzu kommt der Hefei-Standort des Autors – iFLYTEK hat seinen Hauptsitz in Hefei – und die Schlussfolgerung ist so stark, wie eine Schlussfolgerung nur sein kann, bevor der Anbieter sie bestätigt.

Es passt zu iFLYTEKs jüngstem Muster. Das im Februar 2026 veröffentlichte Spark X2 des Unternehmens war ausdrücklich auf Bildungs-, Medizin-, Automobil- und Agenten-Anwendungsfälle ausgerichtet, und seine SparkAuto-EMM-Serie von On-Device-Modellen wird in kleinen Größen von 0,5B bis 7B angeboten. Zwei Tage bevor diese Pressemitteilung bekannt wurde, sagte iFLYTEK auf seiner Zwischenergebnis-Konferenz am 21. August, dass ein neues Flaggschiff-Allzweckmodell, das vollständig auf inländischer Recheninfrastruktur basiert, kommen werde, mit einer phasenweisen Version „bis Ende August“ und einer vollständigen Einführung am 1024 Developer Day im Oktober. Ob Spark3-1.7B und Spark3-4B Teil dieser gestaffelten Veröffentlichung sind oder eine separate, auf Edge-Computing fokussierte Linie, ist eine offene Frage, die die Pressemitteilung nicht beantwortet.

Was die Modelle angeblich sein sollen

Die Behauptungen des PR, alle unverifiziert:

• Zwei Größen. Spark3-1.7B und Spark3-4B. Beide werden als effizienzorientierte Designs beschrieben, die Sliding-Window-Attention anstelle eines dichten Full-Attention-Layouts verwenden.

• Nattiver 1M-Token-Kontext auf beiden. Kein Versprechen für einen erweiterten Modus — der PR sagt, der Kontext sei nativ für die Architektur, was eine Million Token auf ein Modell bringen würde, das klein genug ist, um auf einer einzelnen GPU plausibel zu sein.

• Ein vierstufiges Denkbudget.Das Denken kann auf „keins“, „niedrig“, „mittel“ oder „hoch“ eingestellt werden, ein umschaltbares Denkdesign, das es einer Anwendung ermöglicht, Denktiefe gegen Latenz und Kosten pro Aufruf abzuwägen.

• 200+ Sprachen und Stärke bei chinesischen Prüfungen. Die Pressemitteilung gibt an, starke Leistungen bei der Beantwortung von K-12- und Gaokao-Fragen zu erzielen – eine iFLYTEK-Signatur angesichts des Bildungsgeschäfts des Unternehmens – sowie mehrsprachige Abdeckung in 200+ Sprachen zu bieten.

• Coding- und Agentenorientierung. Behauptungen über starke Codegenerierung, Tool-Nutzung, mehrstufige Ausführung und Long-Context-Reasoning für seine Größe, gestützt durch den im selben PR enthaltenen XML-Tool-Parser.

Der native 1M-Kontext auf einem 1.7B ist der Teil, der Beachtung verdient.

Die Kontextlänge ist der Bereich, in dem kleine Modelle bisher feststecken. In der aktuellen Open-Weight-Landschaft kommt ein 1.7B–4B-Modell typischerweise mit einem nativen 32K–256K-Fenster: Qwe{{1}}n3s kleine Checkpoints sind nativ 32K groß und erreichen per Rope-Skalierung 131K, und selbst Qwen3.5s verbessertes natives 256K bei kleinen Varianten ist ein jüngster Schritt.{{/1}} Ein Millionen-Token-Kontext war bisher großen Modellen vorbehalten — G{{2}}LMs 1M-Kontext-Checkpoints haben mehrere hundert Milliarden Parameter.{{/2}} Wenn Spark3 wirklich ein natives 1M-Fenster auf einem 4B-Modell liefert, wäre das eine wirklich ungewöhnliche Spezifikation, und die Sliding-Window-Attention-Architektur ist genau das, womit man das günstig im Speicher umsetzt. Die Einschränkung, die man dazu nennen muss: Eine native 1M-Schlagzeilenzahl ist leicht in eine Pressemitteilung zu schreiben und in der Praxis schwer nutzbar zu machen. Long-Context-Qualität — kann das Modell tatsächlich eine Information finden und nutzen, die 700K Token zurückliegt — ist eine andere Frage als die, wie viele Token ins Fenster passen, und es gibt noch keine unabhängige Evaluierung.

Das steuerbare Denkbudget ist aus demselben Grund wichtig. Vier Denkstufen (keine / niedrig / mittel / hoch) sind ein umschaltbares Denkdesign im Geiste von Qwen3s Ein/Aus-Denkmodus, aber reicher: Statt einer binären Wahl kann eine Anwendung pro Anfrage eine Stufe wählen — kein Denken für eine Übersetzung, hoch für einen mehrstufigen Agenten-Turn — und nur für die Denkleistung bezahlen, die sie benötigt. Für eine agentische oder Batch-Workload ist das genau der Regler, der ein „leistungsfähiges, aber teures“ kleines Modell in ein kostenkontrolliertes verwandelt.

Das Post-Training-Rezept passt zu einem 2026er-Muster.

Die PR besagt, dass Spark3 mit „Scaled Reinforcement Learning and MOPD“ nachtrainiert wurde. MOPD – Multi-Teacher On-Policy Distillation – ist eine reale und aktuelle Technik, beschrieben in einem arXiv-Paper (2606.30406): Man trainiert parallele domänenspezialisierte RL-Lehrer und destilliert sie dann anhand der eigenen Rollouts des Schülers zurück in einen einzelnen Schüler, wobei der Reverse-KL pro Token gegenüber dem jeweils richtigen Lehrer pro Prompt minimiert wird. Es ist das Rezept von 2026, das es einem einzelnen Modell ermöglicht, Mathematik-, Programmier- und Agentenfähigkeiten zu erben, ohne dass ein RL-Lauf gegen einen anderen kämpft, und es wurde öffentlich als Technik im Post-Training von Modellen wie MiMo Flash V2, DeepSeek V4 und Nemotron 3 Ultra angeführt. Dass Spark3 dasselbe Rezept anführt, ordnet es in diese Generation ein – kleine Modelle, modernste Post-Training-Techniken. Es bedeutet auch, dass hinter den „starken Programmier- und Agenten-Behauptungen“ ein plausibler Mechanismus steckt. Plausibel ist nicht dasselbe wie gezeigt: Die Behauptungen bleiben herstellerseitig gemeldet, bis die Gewichte erscheinen und unabhängige Evaluierungen durchgeführt werden.

Was wirklich unbekannt ist

Fast alles mit einem Kalender darauf:

• Erscheinungsdatum. Keine Gewichte auf Hugging Face, keine Ankündigung, kein Zeitplan. Die XHToken-Organisation ist heute leer.

• Anbieterbestätigung. iFLYTEK hat nichts über Spark3 gesagt. Der XHToken-org-Link ist ein starkes Indiz, keine offizielle Stellungnahme.

• Ob es das phasenweise erscheinende Flaggschiff ist. iFLYTEKs phasenweise erscheinende „Ende August“-Version seines neuen Flaggschiffs könnte dies sein — oder auch nicht. Die Pressemitteilung nennt überhaupt keine Termine.

• Preise und Lizenz. Es wird nichts offengelegt. Die Spark-Familie von iFLYTEK war historisch gesehen hauptsächlich über eine API verfügbar und nicht als offene Gewichte, daher ist offen, ob Spark3-1.7B und Spark3-4B offene Checkpoints oder ein internes Serving-Ziel sind.

• Jeder Benchmark. Bei den Durchsatzwerten im PR handelt es sich um den eigenen Serving-Test des Autors, nicht um eine unabhängige Bewertung, und kein Leaderboard hat das Modell bewertet, weil kein Modell öffentlich existiert.

Was zu sehen

Die XHToken Hugging Face-Organisation ist der Veröffentlichungskanal, den man im Auge behalten sollte. Wenn das Modell echt ist, sollten seine Gewichte – oder zumindest eine Modellkarte – dort erscheinen, und die Organisation, die von null auf ein öffentliches Repository geht, ist das Signal, das am meisten zählt. Ein paar Dinge, die man in dem Moment überprüfen sollte, wenn es so weit ist:

• Die Kontextnummer. Ist 1M nativ oder rope-erweitert mit einem Qualitätskompromiss? Die PR sagt nativ; die Modellkarten sind der Ort, an dem das geklärt wird.

• Die Thinking-Budget-API. Wie die vier Reasoning-Ebenen bereitgestellt werden – als Sampling-Parameter, als Chat-Template-Feld oder als separate Modellvariante – bestimmt, wie einfach sie tatsächlich zu nutzen ist.

• Die Lizenz. Offene Gewichte würden Spark3 zum ersten Sub-5B-Modell mit nativem 1M-Kontext machen, das selbst gehostet werden kann; ein reiner API-Start würde es zu einer anderen Art Produkt machen.

• Der Ankündigungskalender von iFLYTEK. Das in Phasen veröffentlichte Flaggschiff wird bis Ende August versprochen und die vollständige Markteinführung am 1024 Developer Day im Oktober. Falls Spark3 in einem von beiden enthalten ist, wird die offizielle Beschreibung sagen, was die Pressemitteilung offen lässt.

• Ob der PR gemerged wird. vLLM-Unterstützung ist sowohl als Qualitätssignal als auch als Infrastruktur von Bedeutung: Die erste Laufzeitumgebung mit nativer Spark3-Unterstützung macht das Modell am Tag der Veröffentlichung der Gewichte produktionsreif.

Was ein Entwickler jetzt tun sollte

Nichts. Es gibt kein Modell, das man aufrufen könnte, keine Gewichte zum Herunterladen, keinen API-Schlüssel zum Bereitstellen – jedes Tool, das heute behauptet, Spark3 auszuliefern, liefert etwas anderes. Was Sie tun können, ist zu entscheiden, wie Sie es an dem Tag bewerten werden, an dem es erscheint, denn dies ist ein Modell mit einem sehr überprüfbaren Versprechen: Ein 1,7B- oder 4B-Modell, das eine Million Tokens liest und auf vier Tiefen argumentiert, ist entweder eine echte neue Kategorie kleiner Modelle oder eine Datenblatt-Geschichte – und der Unterschied ist an einem Nachmittag mit Ihrer eigenen Arbeitslast messbar.

Genau hier macht sich eine Routing-Ebene bezahlt. Bei OrcaRouter ist ein Modell kein Vertrag, auf den man sich festlegt; es ist ein Eintrag in einem Katalog, den man über eine einzige API aufruft, und die Listenpreise der Anbieter werden ohne Aufschlag durchgereicht — wenn also ein neues Modell im Anbieterkatalog erscheint, ist sein echter Preis noch am selben Tag live auf unserer Seite, und es auszuprobieren kostet weder eine zweite Integration noch eine Neuverhandlung. Für ein so unerprobtes Modell wie Spark3 ist das vernünftige Muster dasselbe, das man bei jedem vielversprechenden Leak anwenden würde: Man platziert es in der Routing-DSL hinter ein automatisches Failover, lässt einen Teil des Traffics darauf treffen und behält ein bewährtes Modell auf der anderen Seite der Regel, sodass eine schlechte Auswertung, eine Lizenzüberraschung oder ein enttäuschendes Long-Context-Ergebnis eher eine Routing-Änderung als ein Vorfall ist. Ein Schlüssel, ein Endpunkt, 200+ Modelle — und wenn Spark3-1.7B oder Spark3-4B tatsächlich lauffähig ist, gelten die Durchreichung und das Failover dafür wie für jedes andere Modell.

Die ehrliche Zusammenfassung ist ein Satz, kein Urteil: Ein Framework-PR, der diese Woche geschrieben wurde, behauptet, iFLYTEK habe zwei kleine Modelle mit nativem Million-Token-Kontext und einem vierstufigen Denkbudget, und es wurden keine stichhaltigen Belege veröffentlicht, um irgendetwas davon zu untermauern. Beobachten Sie die XHToken-Org, beobachten Sie iFLYTEKs Versprechen für Ende August, und wenn die Gewichte echt sind, testen Sie sie mit einer Routing-Regel mit Failover, bevor Sie einen Produktionspfad auf sie setzen. Das ist das gesamte Playbook für ein Leak: Glauben Sie der Infrastruktur, verifizieren Sie das Modell und halten Sie den Ausstieg günstig.