Spark3-lek: iFLYTEK's kleine 1.7B- en 4B-modellen worden in vLLM geïntegreerd

Spark3 heeft geen openbare gewichten, geen modelkaart, geen aankondiging — en toch is er deze week een pull request binnengekomen in de vLLM-inferentie-engine die twee modellen beschrijft, Spark3-1.7B en Spark3-4B, in opmerkelijk detail. Pull request #53373 in de vLLM-repository, "[Model] Add Spark3 Model," voegt native ondersteuning toe voor de Spark3-architectuur: sliding-window-attentie, een controleerbaar denkbudget met vier niveaus, native context van een miljoen tokens op beide formaten, en een model-ID dat naar iFLYTEK verwijst. Niets daarvan is door de leverancier bevestigd, en er is niets uitgebracht. Dit is een 'wat we tot nu toe weten'-stuk: de pull request is echt, en alles wat de modellen zouden doen is ongeverifieerd totdat iFLYTEK — of wie Spark3 ook uitbrengt — daadwerkelijk gewichten publiceert.

Het lek: een pull request die leest als een specificatieblad.

Het signaal is een open vLLM-PR, ingediend door een GitHub-gebruiker met de naam KnightYao (een bijdrager uit Hefei die de University of Science and Technology of China vermeldt), en per 23 augustus 2026 is deze nog niet samengevoegd. Een vLLM-beheerder heeft op 22 augustus wijzigingen aangevraagd met de opmerking "hold for discussions." De PR is vroeg en wordt betwist, wat normaal is voor dit soort integratie — en hij is ook ongewoon gedetailleerd voor een framework-PR over een model dat niemand buiten het lab kan downloaden.

De diff betreft acht bestanden. Het voegt een Spark3ForCausalLM-implementatie toe in de model-executor van vLLM, een native Spark3Config geregistreerd in de config- en modelregisters van vLLM, ondersteuning voor sliding-window-attention, volledige attention en head-wise attention-output-gating, het laden van tensor- en pipeline-parallelle gewichten, en een Spark3-XML-toolparser zodat de toolaanroepen van het model op een gestructureerde manier kunnen worden gedecodeerd. Het voegt ook een rij toe aan de documentatie van ondersteunde modellen van vLLM, waarin de checkpoint wordt vermeld als XHToken/Spark3-1.7B. De beschrijving beweert zelfs dat de integratie is gebenchmarkt: 500 gelijktijdige verzoeken, 100% succes, ongeveer 106 verzoeken per seconde en 13,5K outputtokens per seconde op de testopstelling van de auteur. Die cijfers zijn zelfgerapporteerd door degene die de PR schreef, niet afkomstig van een onafhankelijke benchmark, en moeten precies zo worden opgevat.

Waarom iFLYTEK de voor de hand liggende — maar onbevestigde — moedermaatschappij is

Niets in de PR noemt de leverancier. Maar de checkpoint-ID die in de PR wordt geregistreerd, XHToken/Spark3-1.7B, valt onder de XHToken-organisatie op Hugging Face, en die organisatie is van iFLYTEK: de pagina van de organisatie vermeldt deze als een bedrijf, linkt naar opensource.iflytek.com en toont momenteel geen openbare modellen en geen openbare datasets. "XH" is de natuurlijke afkorting voor 星火 (Xinghuo, "Spark"), de modelfamilie van iFLYTEK. Voeg de locatie van de auteur, Hefei, toe — iFLYTEK heeft zijn hoofdkantoor in Hefei — en de gevolgtrekking is ongeveer zo sterk als een gevolgtrekking maar kan zijn voordat de leverancier het bevestigt.

Het past in het recente patroon van iFLYTEK. De Spark X2 van het bedrijf, uitgebracht in februari 2026, was expliciet gericht op use cases in het onderwijs, de medische sector, de auto-industrie en agents, en de SparkAuto-EMM-lijn van on-device-modellen wordt geleverd in kleine formaten van 0,5B tot 7B. Twee dagen voordat dit persbericht naar buiten kwam, zei iFLYTEK tijdens de conferentie over de tussentijdse resultaten op 21 augustus dat er een nieuw vlaggenschipmodel voor algemeen gebruik zou komen, volledig gebouwd op binnenlandse rekenkracht, met een gefaseerde versie die "uiterlijk eind augustus" zou verschijnen en een volledige lancering op de 1024 Developer Day in oktober. Of Spark3-1.7B en Spark3-4B deel uitmaken van die gefaseerde release, of een aparte edge-gerichte track, is een open vraag die het persbericht niet beantwoordt.

Wat de modellen zouden zijn

De beweringen van de PR, allemaal ongeverifieerd:

• Twee formaten. Spark3-1.7B en Spark3-4B. Beide worden omschreven als efficiëntiegerichte ontwerpen die gebruikmaken van sliding-window attention in plaats van een dense full-attention layout.

• Natieve 1M-token context op beide. Geen extended-mode-belofte — de PR zegt dat de context native is aan de architectuur, wat een miljoen tokens op een model zou plaatsen dat klein genoeg is om op een enkele GPU aannemelijk te zijn.

• Een denkbudget met vier niveaus. Redeneren kan worden ingesteld op geen, laag, medium of hoog, een ontwerp met schakelbaar denken waarmee een toepassing de redeneerdiepte kan afwegen tegen latentie en kosten per oproep.

• 200+ talen en sterk in Chinese examens. Het persbericht beweert sterke prestaties bij het beantwoorden van vragen op K-12- en Gaokao-niveau — een iFLYTEK-kenmerk, gezien de onderwijsactiviteiten van het bedrijf — en meertalige dekking in meer dan 200 talen.

• Coderen en agentoriëntatie. Beweringen over sterke codegeneratie, toolgebruik, meerstapsuitvoering en redeneren over lange contexten voor zijn omvang, ondersteund door de XML-toolparser die in dezelfde PR is opgenomen.

Het deel dat opvalt is de native 1M context op een 1.7B

De contextlengte is waar kleine modellen tot nu toe vastliepen. In het huidige open-weight-landschap wordt een model van 1,7B–4B doorgaans geleverd met een native contextvenster van 32K–256K: de kleine checkpoints van Qwen3 zijn native 32K, met 131K via rope-schaling, en zelfs de verbeterde native 256K van Qwen3.5 op kleine varianten is een recente stap. Een context van een miljoen tokens is tot nu toe een kenmerk van grote modellen geweest — de checkpoints van GLM met 1M-context bestaan uit honderden miljarden parameters. Als Spark3 daadwerkelijk een native 1M-venster op een 4B-model levert, zou dat een echt ongebruikelijke specificatie zijn, en de sliding-window-attentiearchitectuur is precies hoe je dat geheugenefficiënt maakt. De kanttekening die daarbij hoort: een native 1M-cijfer is gemakkelijk in een persbericht te zetten en moeilijk om in de praktijk nuttig te maken. De kwaliteit van lange context — kan het model daadwerkelijk een feit vinden en gebruiken dat 700K tokens terug in de context staat — is een andere vraag dan hoeveel tokens er in het venster passen, en er bestaat nog geen onafhankelijke evaluatie.

Het beheersbare denkbudget is om dezelfde reden belangrijk. Vier redeneerniveaus (geen / laag / medium / hoog) vormen een ontwerp met schakelbaar denken, in de geest van Qwe​n3's aan/uit-denkmodus, maar rijker: in plaats van een binaire keuze kan een applicatie per verzoek een niveau kiezen — geen denken voor een vertaling, hoog voor een meerstaps-agentbeurt — en alleen betalen voor de redenering die ze nodig heeft. Voor een agentische of batch-workload is dat precies de knop die een 'capabel maar duur' klein model verandert in een model met beheerste kosten.

Het post-trainingrecept past in een 2026-patroon

Het persbericht zegt dat Spark3 een post-training heeft ondergaan met "Scaled Reinforcement Learning and MOPD." MOPD — Multi-Teacher On-Policy Distillation — is een echte en actuele techniek, beschreven in een arXiv-paper (2606.30406): train parallelle domeinspecialistische RL-teachers en destilleer ze vervolgens terug in één student op basis van de eigen rollouts van die student, waarbij per token de reverse KL wordt geminimaliseerd ten opzichte van de juiste teacher per prompt. Het is het recept van 2026 waarmee één model wiskunde-, codeer- en agentvaardigheden kan erven zonder dat de ene RL-run tegen de andere vecht, en het is publiekelijk vermeld als bijdrage aan de post-training van modellen als MiMo Flash V2, DeepSeek V4 en Nemotron 3 Ultra. Dat Spark3 hetzelfde recept noemt, plaatst het in die generatie — kleine modellen, geavanceerde post-trainingstechnieken. Het betekent ook dat de "sterke codeer- en agentclaims" een plausibel mechanisme achter zich hebben. Plausibel is niet hetzelfde als aangetoond: de claims blijven leveranciersclaims totdat de gewichten verschijnen en er onafhankelijke evaluaties draaien.

Wat is werkelijk onbekend

Bijna alles met een kalender erop:

• Releasedatum. Geen gewichten op Hugging Face, geen aankondiging, geen tijdlijn. De XHToken-organisatie is vandaag leeg.

• Leveranciersbevestiging. iFLYTEK heeft niets gezegd over Spark3. De XHToken org-link is sterk bewijs, geen officiële verklaring.

• Of dit nu het gefaseerde vlaggenschip is. De "eind augustus"-gefaseerde versie van iFLYTEK's nieuwe vlaggenschip zou dit kunnen zijn — of niets daarmee te maken hebben. Het persbericht geeft helemaal geen datums.

• Prijzen en licentie. Er wordt niets bekendgemaakt. De Spark-familie van iFLYTEK is historisch gezien meestal via API aangeboden in plaats van als open gewichten, dus of Spark3-1.7B en Spark3-4B open checkpoints zijn of een intern serving-doelwit is een open vraag.

• Elke benchmark. De doorvoercijfers in de PR zijn de eigen servingtest van de auteur, geen onafhankelijke evaluatie, en geen enkel leaderboard heeft het model gescoord, omdat er geen model openbaar beschikbaar is.

Wat te kijken

De XHToken Hugging Face-organisatie is het releasekanaal om in de gaten te houden. Als het model echt is, zouden de gewichten — of op zijn minst een modelkaart — daar moeten verschijnen, en het feit dat de organisatie van nul naar één openbare repo gaat, is het belangrijkste signaal. Een paar dingen om te controleren op het moment dat dat gebeurt:

• Het contextnummer. Is 1M native, of rope-extended met een kwaliteitsafweging? De PR zegt native; modelkaarten zijn waar dat wordt beslist.

• De thinking-budget-API. Hoe de vier redeneerniveaus beschikbaar worden gemaakt — als een samplingparameter, een chat-template-veld of een aparte modelvariant — bepaalt hoe gemakkelijk ze daadwerkelijk te gebruiken zijn.

• De licentie. Open gewichten zouden van Spark3 het eerste sub-5B-model met native 1M-context maken dat beschikbaar is om zelf te hosten; een API-only lancering zou er een ander soort product van maken.

• iFLYTEK's aankondigingskalender. Het gefaseerde vlaggenschip wordt tegen eind augustus beloofd en de volledige lancering vindt plaats op de October 1024 Developer Day. Als Spark3 deel uitmaakt van een van beide, zal de officiële beschrijving zeggen wat de PR openlaat.

• Of de PR wordt gemerged. vLLM-ondersteuning is belangrijk als kwaliteitssignaal en als infrastructuur: de eerste runtime met native Spark3-ondersteuning maakt het model in productie draaibaar op de dag dat de gewichten uitkomen.

Wat een ontwikkelaar nu zou moeten doen

Niets. Er bestaat geen model om aan te roepen, geen gewichten om te downloaden, geen API-sleutel om in te richten — elk hulpmiddel dat beweert Spark3 vandaag te draaien, draait iets anders. Wat je wel kunt doen, is bepalen hoe je het zult evalueren op de dag dat het verschijnt, want dit is een model met een zeer controleerbare belofte: een 1.7B of 4B die een miljoen tokens leest en op vier dieptes redeneert, is ofwel een werkelijk nieuwe categorie kleine modellen, ofwel een specbladverhaal — en het verschil is op een middag meetbaar op je eigen workload.

Daar verdient een routinglaag ook zijn bestaansrecht. Bij OrcaRouter is een model geen contract waar je je aan committeert; het is een vermelding in een catalogus die je via één API aanroept, en de lijstprijzen van providers worden zonder opslag doorgegeven — dus wanneer een nieuw model in een providercatalogus verschijnt, is de echte prijs dezelfde dag live aan onze kant, en het uitproberen kost geen tweede integratie en geen heronderhandeling. Voor een model dat zo onbewezen is als Spark3 is het verstandige patroon hetzelfde als bij elke veelbelovende lek: zet het achter automatische failover in de routing-DSL, laat een deel van het verkeer erop uitkomen, en houd een bewezen model aan de andere kant van de regel, zodat een slechte evaluatie, een licentieverrassing of een teleurstellend long-context-resultaat een routingwijziging is in plaats van een incident. Eén sleutel, één endpoint, 200+ modellen — en wanneer Spark3-1.7B of Spark3-4B daadwerkelijk draaibaar is, gelden de pass-through en de failover ervoor net zo als voor elk ander model.

De eerlijke samenvatting is een zin, geen oordeel: een framework-PR die deze week is geschreven beweert dat iFLYTEK twee kleine modellen heeft met een native context van een miljoen tokens en een denkbudget met vier niveaus, en er is geen enkel bewijs gepubliceerd om ook maar iets daarvan te staven. Houd de XHToken-organisatie in de gaten, houd iFLYTEK's belofte van eind augustus in de gaten, en wanneer de gewichten echt zijn, voer ze door een routeringsregel met een failover voordat je er een productiepad op baseert. Dat is het hele draaiboek voor een lek — vertrouw de infrastructuur, verifieer het model en houd de exit goedkoop.