Spark3 Leak : les petits modèles 1.7B et 4B d'iFLYTEK sont en cours d'intégration dans vLLM

Spark3 n'a pas de poids publics, pas de fiche modèle, pas d'annonce — et pourtant une pull request a atterri cette semaine dans le moteur d'inférence vLLM décrivant deux modèles, Spark3-1.7B et Spark3-4B, avec un degré de détail remarquable. La pull request #53373 dans le dépôt vLLM, « [Model] Add Spark3 Model », ajoute la prise en charge native du serving pour l'architecture Spark3 : attention par fenêtre glissante, un budget de réflexion contrôlable avec quatre niveaux, un contexte natif d'un million de jetons sur les deux tailles, et un identifiant de modèle qui pointe vers iFLYTEK. Rien de tout cela n'est confirmé par le fournisseur, et rien n'a été livré. Ceci est un article de type « ce que l'on sait pour l'instant » : la pull request est réelle, et tout ce que ces modèles sont censés faire reste non vérifié tant qu'iFLYTEK — ou quiconque distribue Spark3 — n'a pas effectivement publié les poids.

La fuite : une pull request qui se lit comme une fiche technique

Le signal est une PR vLLM ouverte, soumise par un utilisateur GitHub nommé KnightYao (un contributeur basé à Hefei qui mentionne l'Université des sciences et technologies de Chine), et au 23 août 2026, elle n'a pas encore été fusionnée. Un mainteneur de vLLM a demandé des modifications le 22 août avec la note « hold for discussions ». La PR est précoce et contestée, ce qui est normal pour ce type d'intégration — et elle est aussi inhabituellement détaillée pour une PR de framework concernant un modèle que personne en dehors du laboratoire ne peut télécharger.

Le diff touche huit fichiers. Il ajoute une implémentation Spark3ForCausalLM dans l'exécuteur de modèles de vLLM, un Spark3Config natif enregistré dans les registres de configuration et de modèles de vLLM, la prise en charge de l'attention à fenêtre glissante et de l'attention complète, ainsi que le gating de sortie d'attention par tête, le chargement des poids en parallélisme tensoriel et pipeline, et un analyseur XML d'outils Spark3 pour que les appels d'outils du modèle puissent être décodés de manière structurée. Il ajoute également une ligne à la documentation des modèles pris en charge de vLLM, répertoriant le checkpoint comme XHToken/Spark3-1.7B. La description prétend même que l'intégration a été évaluée par des benchmarks : 500 requêtes concurrentes, 100 % de succès, environ 106 requêtes par seconde et 13,5K tokens de sortie par seconde sur la configuration de test de l'auteur. Ces chiffres sont auto-déclarés par la personne qui a écrit la PR, pas un benchmark indépendant, et ils doivent être lus exactement de cette façon.

Pourquoi iFLYTEK est la maison mère évidente — mais non confirmée —

Rien dans la PR ne nomme le fournisseur. Mais l'ID de checkpoint qu'elle enregistre, XHToken/Spark3-1.7B, se trouve sous l'organisation XHToken sur Hugging Face, et cette organisation appartient à iFLYTEK : la page de l'organisation la répertorie comme une entreprise, renvoie vers opensource.iflytek.com et affiche actuellement zéro modèle public et zéro jeu de données public. « XH » est le raccourci naturel de 星火 (Xinghuo, « Spark »), la famille de modèles d'iFLYTEK. Ajoutez le fait que l'auteur se trouve à Hefei — iFLYTEK a son siège social à Hefei — et l'inférence est aussi solide qu'une inférence peut l'être avant que le fournisseur ne le confirme.

Cela s'inscrit dans la tendance récente d'iFLYTEK. Le Spark X2 de l'entreprise, sorti en février 2026, visait explicitement les cas d'usage éducatifs, médicaux, automobiles et d'agents, et sa gamme SparkAuto-EMM de modèles embarqués est disponible en petites tailles, de 0,5B à 7B. Deux jours avant la diffusion de ce communiqué de presse, lors de sa conférence sur les résultats semestriels du 21 août, iFLYTEK a indiqué qu'un nouveau modèle phare polyvalent, reposant entièrement sur des capacités de calcul domestiques, était en préparation, avec une version progressive attendue « d'ici la fin août » et un lancement complet lors de son 1024 Developer Day en octobre. La question de savoir si Spark3-1.7B et Spark3-4B font partie de cette version progressive ou d'une filière distincte axée sur l'edge reste ouverte, et le communiqué n'y répond pas.

Ce que les modèles sont censés être

Les affirmations de la PR, toutes non vérifiées :

• Deux tailles. Spark3-1.7B et Spark3-4B. Les deux sont décrits comme des conceptions privilégiant l'efficacité, utilisant une attention à fenêtre glissante plutôt qu'une architecture d'attention dense complète.

• Contexte natif de 1 million de jetons sur les deux. Ce n'est pas une promesse de mode étendu — le PR indique que le contexte est natif à l'architecture, ce qui placerait un million de jetons sur un modèle assez petit pour être plausible sur un seul GPU.

• Un budget de réflexion à quatre niveaux. Le raisonnement peut être réglé sur aucun, faible, moyen ou élevé, une conception à raisonnement commutable qui permet à une application d'échanger la profondeur de raisonnement contre la latence et le coût par appel.

• 200+ langues et une maîtrise des examens chinois. Le communiqué de presse revendique de solides performances en matière de réponse aux questions pour le K-12 et le Gaokao — une signature d'iFLYTEK, compte tenu du secteur éducatif de l'entreprise — et une couverture multilingue dans plus de 200 langues.

• Orientation codage et agent. Des affirmations de génération de code performante, d'utilisation d'outils, d'exécution en plusieurs étapes et de raisonnement à long contexte pour sa taille, appuyées par l'analyseur d'outils XML inclus dans la même PR.

Le contexte natif de 1M sur un 1.7B est ce qui mérite l'attention.

C'est sur la longueur de contexte que les petits modèles ont buté. Dans le paysage actuel des poids ouverts, un modèle 1,7B–4B est généralement livré avec une fenêtre native de 32K à 256K : les petits checkpoints de Qwen3 offrent 32K en natif et 131K via le rope scaling, et même le 256K natif amélioré de Qwen3.5 sur les petites variantes est une étape récente. Le contexte d'un million de tokens a jusqu'ici été l'apanage des grands modèles — les checkpoints à contexte 1M de GLM comptent des centaines de milliards de paramètres. Si Spark3 livre réellement une fenêtre native de 1M sur un modèle 4B, ce serait une spécification vraiment inhabituelle, et l'architecture d'attention à fenêtre glissante est précisément ce qui permet de la rendre économique en mémoire. La réserve qui doit l'accompagner : un chiffre phare de 1M natif est facile à écrire dans un communiqué et difficile à rendre utile en pratique. La qualité du long contexte — le modèle peut-il réellement retrouver et utiliser une information située 700K tokens en arrière — est une question distincte de celle du nombre de tokens pouvant tenir dans la fenêtre, et aucune évaluation indépendante n'existe encore.

Le budget de réflexion contrôlable importe pour la même raison. Quatre niveaux de raisonnement (aucun / faible / moyen / élevé) constituent une conception à réflexion commutable dans l'esprit du mode de réflexion activable/désactivable de Qwe​n3, mais plus riche : au lieu d'un choix binaire, une application peut choisir un niveau par requête — aucune réflexion pour une traduction, élevé pour un tour d'agent multi-étapes — et ne payer que pour le raisonnement dont elle a besoin. Pour une charge de travail agentique ou par lots, c'est exactement le curseur qui transforme un petit modèle « capable mais coûteux » en modèle à coûts maîtrisés.

La recette de post-entraînement correspond à un schéma 2026.

Le communiqué indique que Spark3 a été post-entraîné avec « Scaled Reinforcement Learning and MOPD ». La MOPD — Multi-Teacher On-Policy Distillation — est une technique réelle et actuelle, décrite dans un article arXiv (2606.30406) : entraîner des enseignants RL spécialisés par domaine en parallèle, puis les distiller dans un unique étudiant à partir des propres trajectoires de ce dernier, en minimisant la divergence KL inverse par jeton par rapport au bon enseignant pour chaque prompt. C’est la recette de 2026 qui permet à un modèle unique d’hériter de compétences en mathématiques, en codage et en agentivité sans qu’une exécution de RL n’entre en conflit avec une autre, et elle a été publiquement créditée dans le post-entraînement de modèles comme MiMo Flash V2, DeepSeek V4 et Nemotron 3 Ultra. Le fait que Spark3 cite la même recette le place dans cette génération — petits modèles, techniques de post-entraînement de pointe. Cela signifie aussi que les « fortes affirmations en matière de codage et d’agentivité » reposent sur un mécanisme plausible. Mais plausible n’est pas démontré : ces affirmations restent rapportées par le fournisseur tant que les poids ne sont pas publiés et que des évaluations indépendantes ne sont pas menées.

Ce qui est véritablement inconnu

Presque tout avec un calendrier dessus :

• Date de sortie. Pas de poids sur Hugging Face, aucune annonce, aucun calendrier. L'organisation XHToken est vide aujourd'hui.

• Confirmation du fournisseur. iFLYTEK n'a rien dit à propos de Spark3. Le lien vers l'organisation XHToken est une preuve solide, pas une déclaration officielle.

• Qu'il s'agisse du flagship échelonné. La version « fin août » échelonnée du nouveau flagship d'iFLYTEK pourrait être celle-ci — ou sans rapport. Le communiqué de presse ne donne aucune date.

• Tarifs et licence. Rien n'est divulgué. La famille Spark d'iFLYTEK a historiquement été principalement servie via API plutôt qu'avec des poids ouverts, donc la question de savoir si Spark3-1.7B et Spark3-4B sont des checkpoints ouverts ou une cible de service interne reste ouverte.

• Chaque benchmark. Les chiffres de débit dans la PR sont le propre test de service de l'auteur, pas une évaluation indépendante, et aucun classement n'a noté le modèle car aucun modèle n'existe publiquement.

Que regarder

L'organisation XHToken Hugging Face est le canal de publication à surveiller. Si le modèle est réel, ses poids — ou au moins une fiche modèle — devraient y apparaître, et le passage de l'organisation de zéro à un dépôt public est le signal le plus important. Quelques éléments à vérifier dès que ce sera le cas :

• Le numéro de contexte. Est-ce que 1M est natif, ou étendu par rope avec un compromis sur la qualité ? Le PR dit natif ; c'est dans les fiches de modèles que cela se règle.

• L'API du budget de réflexion. La manière dont les quatre niveaux de raisonnement sont exposés — comme paramètre d'échantillonnage, champ de modèle de chat ou variante de modèle distincte — détermine leur facilité d'utilisation réelle.

• La licence. Des poids ouverts feraient de Spark3 le premier modèle sous 5B avec un contexte natif de 1M disponible en auto-hébergement ; un lancement uniquement via API en ferait un produit différent.

• Le calendrier des annonces d'iFLYTEK. Le produit phare déployé par phases est promis pour la fin août, et le lancement complet aura lieu lors du Developer Day 1024 d'octobre. Si Spark3 fait partie de l'un ou l'autre, la description officielle précisera ce que le communiqué de presse laisse en suspens.

• Que la PR soit fusionnée.Le support de vLLM est important à la fois comme signal de qualité et comme infrastructure : le premier runtime avec le support natif de Spark3 rend le modèle exécutable en production le jour où les poids sont publiés.

Ce qu'un développeur devrait faire en ce moment

Rien. Il n'y a pas de modèle à appeler, pas de poids à télécharger, pas de clé API à fournir — tout outil qui prétend servir Spark3 aujourd'hui sert autre chose. Ce que vous pouvez faire, c'est décider comment vous l'évaluerez le jour où il apparaîtra, car c'est un modèle avec une promesse très vérifiable : un 1.7B ou 4B qui lit un million de tokens et raisonne à quatre profondeurs est soit une catégorie de petits modèles réellement nouvelle, soit une histoire de fiche technique, et la différence est mesurable en un après-midi sur votre propre charge de travail.

C'est aussi là qu'une couche de routage justifie sa place. Sur OrcaRouter, un modèle n'est pas un contrat auquel vous vous engagez ; c'est une entrée d'un catalogue que vous interrogez via une seule API, et les prix catalogue des fournisseurs sont répercutés sans aucune marge — si bien que lorsqu'un nouveau modèle apparaît dans le catalogue d'un fournisseur, son prix réel est en ligne chez nous dès le jour même, et l'essayer ne nécessite ni seconde intégration ni renégociation. Pour un modèle aussi peu éprouvé que Spark3, la démarche raisonnable est la même que pour toute fuite prometteuse : le placer derrière un basculement automatique dans le DSL de routage, laisser une partie du trafic l'atteindre, et conserver un modèle éprouvé de l'autre côté de la règle, de sorte qu'une mauvaise évaluation, une surprise de licence ou un résultat décevant en long contexte soit un changement de routage plutôt qu'un incident. Une clé, un endpoint, plus de 200 modèles — et lorsque Spark3-1.7B ou Spark3-4B sera réellement exécutable, la transmission et le basculement s'appliqueront à lui comme à n'importe quel autre modèle.

Le résumé honnête est une phrase, pas un verdict : un PR de framework écrit cette semaine prétend qu'iFLYTEK dispose de deux petits modèles avec un contexte natif d'un million de jetons et un budget de réflexion à quatre niveaux, et aucune preuve substantielle n'a été publiée pour étayer tout cela. Surveillez l'organisation XHToken, surveillez la promesse d'iFLYTEK pour fin août, et lorsque les poids seront réels, soumettez-les à une règle de routage avec basculement avant de parier un chemin de production sur eux. C'est tout le manuel pour une fuite — croyez à l'infrastructure, vérifiez le modèle, et gardez la sortie bon marché.