K-EXAONE-2.0-750B-A37B-DSpark : le MoE coréen de 750B de LG arrive sur vLLM

Le 9 août 2026, une pull request a été ouverte dans le dépôt vLLM pour ajouter K-EXAONE-2.0-750B-A37B-DSpark — la variante de décodage spéculatif du fleuron coréen de 750 milliards de paramètres de LG AI Research. Quatre jours plus tard, le 13 août, une deuxième PR, plus fondamentale, a concrétisé la fuite : vLLM dispose désormais d'un chemin de configuration générique DSparkDraftModel, qui mappe tout checkpoint Hugging Face déclarant architectures=DSparkDraftModel avec model_type=qw​en​3 vers le modèle reconnu Qw​en3DSparkModel, avec un plan de test qui sert réellement le drafter RadixArk Qw​en​3.8-2.4T-A95B-DSpark via la méthode spéculative dspark. Le modèle de base K-EXAONE-2.0-750B-A37B est sorti le 31 juillet sous licence Apache 2.0, et au lancement, vLLM pouvait le servir avec la méthode de draft MTP mais pas avec DSpark — le drafter que LG fournit également et dont elle affirme qu'il vaut une accélération du décodage de 3 à 5×. DSpark est elle-même la méthode de Deep​Seek, le même drafter semi-autorégressif qui fonctionne sur Deep​Seek-V4-Pro-DSpark et Deep​Seek-V4-Flash-DSpark. Ces deux PR ensemble constituent donc le signe le plus clair à ce jour que la pile de décodage spéculatif de Deep​Seek devient la norme par défaut pour les poids ouverts.

Ceci est un article récapitulatif de ce que l'on sait à ce jour, pas un article de lancement. Les deux pull requests sont ouvertes et non fusionnées, le checkpoint DSpark n'a fait l'objet d'aucun benchmark indépendant, et le chiffre d'accélération de LG est une allégation du fournisseur. Tout ce qui suit est étiqueté en conséquence. Ce qui est réel aujourd'hui : les poids sont sur Hugging Face, le modèle de base a été publié, le décodeur spéculatif DSpark de vLLM sert déjà les checkpoints Deep​Seek et Kim​i, et le chemin de configuration générique qui permettrait à un drafter DSpark tiers de se charger — la pièce que cette fuite attendait — se trouve maintenant dans une pull request publique, testé mais non publié.

La version courte

• La PR #51558, ouverte le 9 août 2026, ajoute K-EXAONE-2.0-750B-A37B-DSpark à vLLM ; elle est ouverte sans aucune approbation pour le moment.

• PR #52197, ouvert le 13 août 2026, introduit le support de configuration générique DSparkDraftModel — architectures=DSparkDraftModel avec model_type=qw​en​3, normalisé en Qw​en3DSparkModel — et son plan de test exécute le drafter RadixArk Qw​en​3.8-2.4T-A95B-DSpark avec la méthode de spec dspark et sept tokens de spec. Également ouvert, également non fusionné.

• DSpark est le drafter de la famille EAGLE que Deep​Seek a open-sourcé et qui équipe Deep​Seek-V4-Pro-DSpark et Deep​Seek-V4-Flash-DSpark ; LG est l’adoption la plus médiatisée par un autre laboratoire à ce jour, et le drafter Qw​en​3.8 de RadixArk en est un second indépendant.

• La variante DSpark est un MoE 750B à 78 couches, plus cinq couches de draft supplémentaires ; LG affirme que DSpark et MTP offrent chacun une accélération du décodage d'environ 3 à 5×, destinée aux charges de travail agentiques à long horizon.

• Au lancement, vLLM prenait en charge MTP pour K-EXAONE 2.0 mais pas DSpark ; le support de DSpark arrive via la PR spécifique au modèle et le chemin de configuration générique.

• Aucun fournisseur n'héberge aujourd'hui de checkpoint K-EXAONE 2.0, et tous les benchmarks sur la fiche sont propres à LG.

Ce que sont les pull requests (et ce qu'elles ne sont pas)

La PR vLLM #51558, « [Model] Add K-EXAONE-2.0-750B-A37B-DSpark », a été ouverte par lkm2835 — le même contributeur à l'origine du support K-EXAONE précédent dans vLLM (#50524 pour le modèle de base) et dans SGLang (#33648). C'est une PR de fork étiquetée avec le label new-model. Une revue a été demandée aux propriétaires du code de vLLM, et elle n'a encore aucune approbation. La description est composée de trois lignes : elle ajoute le support du checkpoint DSpark « développé par LG AI Research », lie la fiche de modèle Hugging Face et le rapport technique K-EXAONE 2.0 (arXiv 2608.04505), et fait référence aux travaux vLLM antérieurs dans #50524.

Le PR du 13 août est différent en nature. #52197, « Support DSpark configs with architectures=DSparkDraftModel + model_type=qw​en​3 », ajoute une couche de normalisation générique : un checkpoint de brouillon Hugging Face qui se déclare comme DSparkDraftModel sur un type de modèle qw​en​3 est remappé vers un Qw​en3DSparkModel que le spec-decoder existant de vLLM peut charger. Le modèle de référence dans son plan de test est RadixArk/Qw​en​3.8-2.4T-A95B-DSpark — un spéculateur DSpark pour la cible max-class Qw​en​3.8-2.4T-A95B — servi avec la méthode spec dspark et une fenêtre spec de sept jetons. Le message de commit résume toute l’idée : « architectures=DSparkDraftModel+model_type=qw​en​3 ». Le but de ce changement est qu’un drafter DSpark tiers puisse être chargé par configuration plutôt que de nécessiter du code spécifique à chaque modèle, comme c’est le cas aujourd’hui pour tous les checkpoints DSpark pris en charge. Il est ouvert et non fusionné, tout comme #51558.

Lisez ce statut au pied de la lettre. « Le support est en cours d'ajout » n'est pas « le support est disponible » : jusqu'à ce que l'une ou l'autre PR soit fusionnée et publiée dans une version, une build vLLM standard ne chargera toujours pas la variante DSpark. La fiche du modèle elle-même indique que le service de K-EXAONE 2.0 avec DSpark n'est actuellement pas pris en charge sur vLLM, qui utilise MTP à la place. Ces deux PR sont les étapes qui changeront cette phrase — si et quand elles seront fusionnées.

Pourquoi DSpark est la vraie histoire ici

Le nom du modèle en dit long. « A37B » signifie 37 milliards de paramètres actifs par jeton. « DSpark » est le réducteur de décodage spéculatif que Deep​Seek a introduit cette année : un modèle draft semi-autorégressif de la famille EAGLE qui propose un bloc de jetons en une seule passe et laisse le modèle cible les vérifier, si bien que la qualité de sortie reste inchangée tandis que la génération devient plus rapide. Deep​Seek l’a publié en open source et fournit ce draft avec ses propres checkpoints Deep​Seek-V4-Pro-DSpark et Deep​Seek-V4-Flash-DSpark, avec des accélérations rapportées par la communauté de l’ordre de 60–85 % pour Flash et de 57–78 % pour Pro par rapport à une ligne de base MTP à jeton unique.

Ce que la nouvelle PR met en évidence, c'est que le support de DSpark dans vLLM n'a jamais été la question ouverte. La documentation de vLLM répertorie déjà les modules DSpark pour les checkpoints {{1}}Deep​Seek-V4{{/1}}, Kimi K3 et {{2}}Gem​ma​4{{/2}}, et l'équipe a présenté la conception dans un article d'ingénierie en juillet. Chacune de ces intégrations est toutefois câblée manuellement — une liste approuvée de checkpoints, pas une route que n'importe qui peut utiliser. Le checkpoint {{3}}K-EXAONE{{/3}} ne figure tout simplement pas sur cette liste. {{4}}#52197{{/4}} est la tentative de rendre la route générique : un mappage de configuration ({{5}}DSparkDraftModel plus qw​en​3{{/5}}) au lieu d'une autre classe de modèle sur mesure, et un drafter tiers comme cas de test de référence plutôt qu'un modèle {{6}}Deep​Seek{{/6}}. C'est pourquoi une histoire de checkpoint draft divulgué est en réalité une histoire d'infrastructure.

K-EXAONE-2.0-750B-A37B-DSpark conserve les 78 couches du modèle de base et ajoute cinq couches de draft DSpark. La carte de modèle de LG affirme que DSpark et MTP accélèrent tous deux la génération d'environ 3–5× — ses propres chiffres, destinés aux « charges de travail à long horizon telles que les tâches agentiques », où la latence de décodage est le goulot d'étranglement. Deux conséquences en découlent. Premièrement, le décodage spéculatif devient une fonctionnalité de première classe des modèles frontières ouverts, plutôt qu'une astuce d'inférence que l'on greffe après coup. Deuxièmement, c'est la pile de draft de Deep​Seek qui devient la norme — c'est exactement pourquoi un fleuron souverain soutenu par le gouvernement coréen qui l'embarque compte au-delà du simple battage médiatique habituel autour d'un « nouveau modèle ».

Le modèle derrière la PR

K-EXAONE-2.0-750B-A37B-DSpark est une variante de K-EXAONE 2.0, la suite de la gamme K-EXAONE de 236B de LG et le plus grand modèle de fondation d'origine sud-coréenne, construit dans le cadre du programme d'IA souveraine du gouvernement. Le modèle de base — 750B de paramètres au total, 37B actifs, Mixture-of-Experts avec 256 experts et 8 actifs par jeton, une fenêtre de contexte de 262 144 jetons, dix langues, Apache 2.0 — a été publié sur Hugging Face le 31 juillet 2026, recyclé à partir du prédécesseur de 236B plutôt que formé de zéro.

Les moyennes de référence de LG lui-même (24 benchmarks, 70,1 au total) montrent la forme attendue pour un modèle souverain coréen : de solides résultats rapportés en récupération de contexte long, en sécurité sociétale coréenne et en codage agentique, ainsi que des chiffres en retrait par rapport à Qw​en​3.5 d'Alibaba en raisonnement général (83,5 contre 89,8 sur MMLU-Pro, par exemple). Aucun de ces résultats n'a encore été vérifié de manière indépendante. La variante DSpark ne change aucun de ces scores — c'est un artefact de service, une façon plus rapide d'exécuter le même modèle — et c'est exactement pour cela qu'elle apparaît dans les pull requests des frameworks d'inférence plutôt que dans une annonce.

La réalité derrière le service d'un MoE de 750B

C'est là que le support DSpark prend tout son sens. K-EXAONE-2.0-750B-A37B-DSpark est un checkpoint de 751 milliards de paramètres en BF16/F32, et LG recommande un minimum de deux nœuds de huit GPU NVIDIA H200 (16 GPU, tensor-parallel 16). À cette échelle, le débit de décodage est tout ce qui compte — les tokens par seconde et le coût d'un long tour agentique — et c'est précisément ce que le décodage spéculatif attaque. Une accélération du décodage de 3 à 5×, si elle se confirme hors du banc d'essai de LG, fait la différence entre un cluster H200 rentable ou non. LG documente également un problème d'effondrement de la génération sur les GPU B200 qui nécessite le contournement --disable-prefill-cuda-graph en attendant un correctif — un rappel qu'il s'agit de serving à la pointe, pas d'une solution clé en main.

Ce que ça coûte, et comment vous pourriez réellement l'essayer

Aucune API ne sert K-EXAONE 2.0 aujourd'hui. La fiche Hugging Face pour la variante DSpark indique toujours « ce modèle n'est déployé par aucun fournisseur d'inférence », et une empreinte de 16×H200 signifie qu'il n'atteint une API hébergée que lorsque quelqu'un disposant de ce matériel décide de l'héberger. C'est là le véritable point de friction : la frontière des poids ouverts est de plus en plus un problème de service, et non de disponibilité.

Quand un fournisseur le prendra en charge, l'accélération par décodage spéculatif se reflètera dans le prix par jeton, et le coût de migration pour l'essayer devrait être quasi nul si votre application est déjà agnostique au modèle. Sur OrcaRouter — un point d'accès compatible Open​AI parmi plus de 200 modèles, avec le prix catalogue du fournisseur répercuté sans marge — un modèle qui atterrit sur n'importe quel fournisseur en amont devient un changement de routage plutôt qu'une réintégration, et le basculement automatique signifie qu'un tout nouveau MoE de 750B qui se révèle lent ou instable retombe sur un modèle éprouvé sans incident. Pour être explicite : OrcaRouter n'héberge pas K-EXAONE-2.0-750B-A37B-DSpark aujourd'hui, et aucune autre API que nous ayons trouvée ne l'héberge non plus. L'intérêt de la couche de routage est d'être prête pour le jour où l'un d'eux le fera.

Ce que nous regardons

• Les deux PR à fusionner. #51558 (spécifique au modèle) et #52197 (configuration générique) sont toutes deux ouvertes, sans aucune approbation. Fusionner puis publier est ce qui transforme « DSpark support » de pull requests en de véritables options que vous pouvez passer.

• La portée du chemin générique. Si #52197 est fusionné, tout DSparkDraftModel typé qw​en​3 sur Hugging Face devient chargeable par configuration — la différence entre DSpark comme liste de checkpoints approuvés et DSpark comme standard ouvert.

• Un premier score indépendant. Tous les benchmarks sur la fiche sont réalisés par LG. Le premier point de données d'Artificial Analysis ou d'arène sur un MoE coréen de 750B sera le premier chiffre non publié par le fournisseur.

• DSpark au-delà de DeepSeek. LG et RadixArk sont désormais deux producteurs indépendants de la méthode de draft de DeepSeek, et le chemin générique vLLM est un troisième signal que la pile est en train de se consolider.

• Service quantifié. LG publie des checkpoints FP8 et NVFP4 du modèle de base ; une variante DSpark quantifiée qui tient sur moins de GPU changerait la donne économique plus vite que n'importe quel benchmark.

FAQ

Est-ce que K-EXAONE-2.0-750B-A37B-DSpark a été publié ?

Les poids sont sur Hugging Face sous Apache 2.0, mais ce n'est pas une histoire de lancement : le support de vLLM se compose de deux pull requests ouvertes et non fusionnées (#51558 et #52197), le chiffre d'accélération provient de LG, et aucun fournisseur n'héberge le modèle. Ce que « confirmé » signifie ici, c'est le chemin de service — le support de configuration générique DSparkDraftModel existe désormais dans un PR public avec un plan de test exécutable — pas qu'une version publiée de vLLM puisse déjà le servir.

Quelle est la différence entre K-EXAONE-2.0-750B-A37B et la variante DSpark ?

Les 78 couches du modèle de base plus cinq couches d'ébauche DSpark pour le décodage spéculatif — les mêmes poids sous-jacents, les mêmes benchmarks, et un artefact de service plus rapide à décoder plutôt qu'un modèle différent.

DSpark appartient-il à LG ou à DeepSeek ?

DSpark est la méthode de décodage spéculatif open source de Deep​Seek, également intégrée aux modèles Deep​Seek-V4-Pro-DSpark et Deep​Seek-V4-Flash-DSpark ; LG en est, à ce jour, l'adoptant le plus en vue, et le Qw​en​3.8-2.4T-A95B-DSpark de RadixArk est un second drafter indépendant reposant sur la même méthode. La fiche technique du modèle de LG revendique la même accélération, de 3 à 5×.

Puis-je exécuter K-EXAONE-2.0-750B-A37B-DSpark sur mon propre matériel aujourd'hui ?

Uniquement en auto-hébergement : les recommandations de LG sont un minimum de seize GPU NVIDIA H200, et les versions standard de vLLM, SGLang et Transformers nécessitent encore des forks non fusionnés ou le chemin de configuration générique en attente pour reconnaître l'architecture. Le support de DSparkDraftModel dans #52197 est ce qui se rapproche le plus d'une solution partagée, mais il s'agit toujours d'une pull request ouverte.

Ce qui rend cela digne d’intérêt, ce ne sont pas les pull requests en elles-mêmes — c’est ce qu’elles signalent. Un fleuron souverain coréen de 750 milliards de paramètres sous licence Apache-2.0 a choisi d’adopter la pile de décodage spéculatif de Deep​Seek, une société d’inférence indépendante a construit un drafter DSpark pour un Qw​en​3.8 de classe max, et vLLM répond avec un chemin de configuration générique au lieu d’un correctif par modèle. C’est ainsi que les modèles ouverts de pointe deviennent réels — pas au moment où les poids sont publiés, mais au moment où les drafters sont fusionnés.