Spark3 Läck: iFLYTEK:s 1.7B- och 4B-småmodeller kopplas in i vLLM

Spark3 har inga offentliga vikter, inget modellkort, inget tillkännagivande – och ändå landade en pull request den här veckan i vLLM-inferensmotorn som beskriver två modeller, Spark3-1.7B och Spark3-4B, i anmärkningsvärd detalj. Pull request #53373 i vLLM-repot, "[Model] Add Spark3 Model," lägger till nativt stöd för Spark3-arkitekturen: sliding-window attention, en kontrollerbar tankebudget med fyra nivåer, inbyggt miljon-token-kontext på båda storlekarna och ett modell-ID som pekar på iFLYTEK. Inget av detta är bekräftat av tillverkaren, och ingenting har släppts. Det här är en "vad vi vet hittills"-text: pull requesten är äkta, och allt som modellerna påstås göra är overifierat tills iFLYTEK – eller den som än släpper Spark3 – faktiskt publicerar vikterna.

Läckan: en pull request som läses som ett specifikationsblad.

Signalen är en öppen vLLM-PR, inlämnad av en GitHub-användare vid namn KnightYao (en bidragsgivare baserad i Hefei som anger University of Science and Technology of China), och per den 23 augusti 2026 har den inte slagits samman. En vLLM-underhållare begärde ändringar den 22 augusti med anteckningen "hold for discussions." PR:n är tidig och omdiskuterad, vilket är normalt för den här typen av integration — och den är också ovanligt detaljerad för en framework-PR om en modell som ingen utanför labbet kan ladda ner.

Diffen rör åtta filer. Den lägger till en Spark3ForCausalLM-implementering i vLLM:s modellexekverare, en inbyggd Spark3Config registrerad i vLLM:s konfigurations- och modellregister, stöd för glidande-fönster-uppmärksamhet och full uppmärksamhet samt huvudvis gating av uppmärksamhetsutdata, tensor- och pipeline-parallell viktinläsning, och en Spark3 XML-verktygsparsern så att modellens verktygsanrop kan avkodas på ett strukturerat sätt. Den lägger också till en rad i vLLM:s dokumentation över stödda modeller som listar kontrollpunkten som XHToken/Spark3-1.7B. Beskrivningen hävdar till och med att integrationen har benchmarkats: 500 samtidiga förfrågningar, 100 % framgång, ungefär 106 förfrågningar per sekund och 13,5K utdatatokens per sekund på författarens testmiljö. Dessa siffror är självrapporterade av personen som skrev PR:n, inte ett oberoende benchmark, och de bör läsas på exakt det sättet.

Varför iFLYTEK är det uppenbara — men obekräftade — moderbolaget

Ingenting i PR:n namnger leverantören. Men kontrollpunkts-ID:t som den registrerar, XHToken/Spark3-1.7B, ligger under XHToken-organisationen på Hugging Face, och den organisationen är iFLYTEK:s: organisationssidan listar den som ett företag, länkar till opensource.iflytek.com, och visar för närvarande noll offentliga modeller och noll offentliga dataset. "XH" är den naturliga förkortningen för 星火 (Xinghuo, "Spark"), iFLYTEK:s modellfamilj. Lägg till författarens Hefei-plats — iFLYTEK har sitt huvudkontor i Hefei — och slutledningen är ungefär så stark som en slutledning kan bli innan leverantören bekräftar det.

Det passar in i iFLYTEK:s senaste mönster. Företagets Spark X2, som släpptes i februari 2026, var uttryckligen inriktad på användningsfall inom utbildning, medicin, fordonsindustrin och agenter, och dess SparkAuto-EMM-serie av modeller som körs på enheten levereras i små storlekar från 0,5B upp till 7B. Två dagar innan detta pressmeddelande dök upp, på sin delårsrapportkonferens den 21 augusti, sade iFLYTEK att en ny flaggskeppsmodell för allmänna ändamål, helt byggd på inhemsk datorkraft, var på väg, med en stegvis version beräknad "i slutet av augusti" och en fullständig lansering på sin 1024 Developer Day i oktober. Huruvida Spark3-1.7B och Spark3-4B ingår i den stegvisa releasen, eller utgör ett separat kantfokuserat spår, är en öppen fråga som pressmeddelandet inte besvarar.

Vad modellerna sägs vara

PR:ns påståenden, alla overifierade:

• Två storlekar.Spark3-1.7B och Spark3-4B. Båda beskrivs som effektivitetsinriktade arkitekturer som använder glidande fönster-uppmärksamhet snarare än en tät full-uppmärksamhetslayout.

• Nativ 1M-token-kontext på båda. Inte ett löfte om utökat läge — PR:n säger att kontexten är nativ till arkitekturen, vilket skulle placera en miljon tokens på en modell som är tillräckligt liten för att vara rimlig på en enda GPU.

• En tankebudget på fyra nivåer. Resonemang kan ställas in på inget, lågt, medel eller högt, en växlingsbar tankedesign som låter en applikation väga resonemangsdjup mot svarstid och kostnad per anrop.

• 200+ språk och styrka i kinesiska prov. PR:n hävdar stark prestation inom K-12 och Gaokao-frågesvar — en iFLYTEK-signatur, med tanke på företagets utbildningsverksamhet — och flerspråkig täckning över 200+ språk.

• Kodning och agentorientering. Påståenden om stark kodgenerering, verktygsanvändning, flerstegsexekvering och långkontextresonemang för sin storlek, underbyggda av XML-verktygsparsern som ingår i samma PR.

Native 1M-kontext på en 1.7B är den del som är värd att notera.

Kontextlängd är där små modeller har fastnat. I dagens open-weight-landskap levereras en 1,7B–4B-modell vanligtvis med ett native-fönster på 32K–256K: Qwe​n3:s små checkpoints har 32K native med 131K via rope-skalning, och även Qwen3.5:s förbättrade native 256K på små varianter är ett nytt steg. Miljon-token-kontext har hittills varit en funktion för stora modeller — G​LMs checkpoints med 1M-kontext har hundratals miljarder parametrar. Om Spark3 verkligen levererar ett native 1M-fönster på en 4B-modell skulle det vara en genuint ovanlig spec, och sliding-window-attention-arkitekturen är precis det som gör det billigt minnesmässigt. Förbehållet som måste tilläggas: en rubriksiffra på native 1M är lätt att skriva i en PR och svår att göra användbar i praktiken. Långkontextkvalitet — kan modellen faktiskt hitta och använda ett faktum 700K tokens tillbaka — är en separat fråga från hur många tokens som får plats i fönstret, och ingen oberoende utvärdering finns ännu.

Den kontrollerbara tankebudgeten är viktig av samma anledning. Fyra resonemangsnivåer (ingen / låg / medel / hög) är en omkopplingsbar tankedesign i andan av Qwe​n3:s på/av-tankeläge, men rikare: i stället för ett binärt val kan en applikation välja en nivå per förfrågan — inget tänkande för en översättning, hög för en flerstegs agentomgång — och betala bara för det resonemang den behöver. För en agentbaserad eller batch-arbetsbelastning är det exakt det reglage som förvandlar en ”kapabel men dyr” liten modell till en kostnadskontrollerad sådan.

Receptet för efterträning passar ett 2026-mönster.

PR:en säger att Spark3 eftertränades med "Scaled Reinforcement Learning and MOPD." MOPD — Multi-Teacher On-Policy Distillation — är en verklig och aktuell teknik, beskriven i en arXiv-artikel (2606.30406): träna parallella domänspecialiserade RL-lärare, destillera sedan tillbaka dem till en enda elev på elevens egna rollouts, med minimering av per-token omvänd KL mot rätt lärare per prompt. Det är 2026 års recept som låter en enda modell ärva matematik-, kodnings- och agentfärdigheter utan att en RL-körning bekämpar en annan, och det har offentligt krediterats i efterträningen av modeller som MiMo Flash V2, DeepSeek V4 och Nemotron 3 Ultra. Att Spark3 citerar samma recept placerar den i den generationen — små modeller, efterträningstekniker i framkant. Det innebär också att de "starka kodnings- och agentanspråken" har en plausibel mekanism bakom sig. Plausibilitet är inte detsamma som bevis: anspråken förblir leverantörsrapporterade tills vikter dyker upp och oberoende utvärderingar körs.

Vad som är genuint okänt

Nästan allt med en kalender på:

• Releasedatum. Inga vikter på Hugging Face, inget tillkännagivande, ingen tidslinje. XHToken-organisationen är tom idag.

• Leverantörsbekräftelse. iFLYTEK har inte sagt något om Spark3. Länken till XHToken-organisationen är starka bevis, inte ett officiellt uttalande.

• Huruvida det är det fasade flaggskeppet. iFLYTEK:s ”slutet av augusti”-fasversion av sitt nya flaggskepp kan vara detta — eller orelaterat. Pressmeddelandet ger inga datum alls.

• Prissättning och licens. Ingenting avslöjas. iFLYTEKs Spark-familj har historiskt sett mestadels serverats via API snarare än med öppna vikter, så det är en öppen fråga om Spark3-1.7B och Spark3-4B är öppna checkpoints eller ett internt servingmål.

• Vartenda riktmärke. Genomströmningssiffrorna i PR:n kommer från författarens eget serving-test, inte en oberoende utvärdering, och ingen topplista har rankat modellen eftersom ingen modell är offentligt tillgänglig.

Vad du ska titta på

XHToken Hugging Face-organisationen är releasekanalen att hålla koll på. Om modellen är verklig bör dess vikter – eller åtminstone ett modellkort – dyka upp där, och att organisationen går från noll till ett offentligt repo är den signal som betyder mest. Några saker att kontrollera i samma stund som det sker:

• Kontextnumret.Är 1M nativt, eller rope-utökat med en kvalitetsavvägning? PR:n säger nativt; model cards är där det avgörs.

• Tankebudget-API:t. Hur de fyra resonemangsnivåerna exponeras — som en samplingsparameter, ett chat-template-fält eller en separat modellvariant — avgör hur lätt det är att faktiskt använda.

• Licensen. Öppna vikter skulle göra Spark3 till den första sub-5B-modellen med nativt stöd för 1M-kontext som kan självhostas; en lansering med enbart API skulle göra den till en annan typ av produkt.

• iFLYTEK:s tillkännagivandekalender. Det etappvisa flaggskeppet utlovas senast i slutet av augusti och den fullständiga lanseringen på 1024 Developer Day i oktober. Om Spark3 ingår i något av dessa kommer den officiella beskrivningen att säga vad pressmeddelandet lämnar öppet.

• Huruvida PR:n mergas. vLLM-stödet är viktigt som kvalitetssignal och som infrastruktur: den första körningsmiljön med inbyggt Spark3-stöd gör modellen körbar i produktion samma dag som vikterna landar.

Vad en utvecklare bör göra just nu

Ingenting. Det finns ingen modell att anropa, inga vikter att ladda ner, ingen API-nyckel att tillhandahålla — alla verktyg som idag påstår sig leverera Spark3 levererar något annat. Vad du kan göra är att bestämma hur du ska utvärdera den den dag den dyker upp, eftersom det är en modell med ett mycket kontrollerbart löfte: en 1.7B eller 4B som läser en miljon tokens och resonerar på fyra djupnivåer är antingen en genuint ny småmodellskategori eller en specifikationshistoria, och skillnaden är mätbar på en eftermiddag med din egen arbetsbelastning.

Det är också där ett routinglager gör skäl för sig. På OrcaRouter är en modell inte ett kontrakt du förbinder dig till; den är en post i en katalog som du anropar via ett API, och leverantörernas listpriser förs vidare utan påslag — så när en ny modell dyker upp i en leverantörskatalog är dess verkliga pris live hos oss samma dag, och att prova den kostar ingen andra integration och ingen omförhandling. För en modell så obeprövad som Spark3 är det förnuftiga mönstret detsamma som du skulle använda för vilken lovande läcka som helst: sätt den bakom automatisk redundans i routing-DSL:et, låt en del av trafiken nå den, och ha en beprövad modell på andra sidan regeln, så att en dålig utvärdering, en licensöverraskning eller ett nedslående långkontextresultat blir en routingändring snarare än en incident. En nyckel, en endpoint, 200+ modeller — och när Spark3-1.7B eller Spark3-4B faktiskt går att köra, gäller vidareföringen och redundansen för den precis som för alla andra modeller.

Den ärliga sammanfattningen är en mening, inte en dom: en PR för ramverket som skrevs den här veckan hävdar att iFLYTEK har två små modeller med inbyggd kontext på en miljon token och en tankebudget i fyra nivåer, och inga vägande bevis har publicerats som stödjer något av det. Håll ett öga på XHToken-organisationen, håll ett öga på iFLYTEKs löfte från slutet av augusti, och när vikterna är verkliga, kör dem genom en routningsregel med failover innan du satsar en produktionssökväg på dem. Det är hela spelboken för en läcka — tro på infrastrukturen, verifiera modellen och håll utvägen billig.