A.X K2 DSpark vs A.X K2 : ce qu'un modèle uniquement rédacteur vous apporte réellement

Ce qu'il y a de plus étrange dans une comparaison entre A.X K2 DSpark et A.X K2, c'est que ce n'est pas vraiment une comparaison. A.X K2 DSpark ne peut pas être utilisé à la place d'A.X K2 — il ne peut même pas être utilisé seul. C'est un « checkpoint réservé au draft » que SK Telecom a discrètement publié sur Hugging Face début août, sans aucune annonce : un modèle de draft pour décodage spéculatif dont l'unique mission est d'accélérer la génération de tokens d'A.X K2, le fleuron open-weight à mélange d'experts de 688 milliards de paramètres de l'entreprise, tout en laissant ses réponses inchangées. La vraie question que pose cette confrontation n'est donc pas « lequel est le meilleur ? », mais « faut-il faire tourner A.X K2 avec DSpark, ou sans ? » Tout dans cet article est sourcé, car l'écart entre ce que le dépôt nous dit et ce qui a réellement été mesuré est toute l'histoire.

Ce qu'est réellement A.X K2 DSpark

La fiche modèle de SK Telecom est exceptionnellement directe quant à ce à quoi sert le modèle. A.X K2 DSpark "est un modèle draft de décodage spéculatif pour A.X K2" et "un checkpoint réservé au rôle de drafter : il n'a aucune utilisation autonome et est destiné à être chargé par vLLM en même temps que A.X K2 via le décodage spéculatif." En pratique, cela signifie que vous le téléchargez, que vous pointez un vLLM compatible vers lui et vers A.X K2, et que les deux travaillent en équipe : DSpark propose des jetons candidats, A.X K2 les vérifie, et seuls les jetons vérifiés sont émis.

{{1}}Deux détails du mécanisme de draft peuvent être connus à partir du dépôt.{{/1}} {{2}}Premièrement, DSpark propose plusieurs jetons candidats en parallèle plutôt que d'écrire une séquence de draft un jeton à la fois, en s'appuyant sur les représentations cachées propres à A.X K2 ainsi que sur une modélisation légère des dépendances locales.{{/2}} {{3}}Deuxièmement, l'ensemble est conçu pour être sans perte : chaque candidat est vérifié par le modèle cible avant d'être validé, de sorte que la distribution de sortie d'A.X K2 est inchangée par construction.{{/3}}

La publication elle-même est un pré-annonce. La fiche indique que le modèle est « actuellement en validation finale et devrait être rendu public dans les prochains jours », et que l'évaluation est « actuellement en cours » — chaque métrique de débit, de TPOT et de longueur moyenne acceptée sur la fiche est toujours répertoriée comme TBD.

Pourquoi ce « versus » est en réalité « avec versus sans »

Comme A.X K2 DSpark n'a pas d'utilisation autonome, il n'existe aucun scénario dans lequel vous le choisiriez à la place d'A.X K2. Le choix se fait entre A.X K2 seul et A.X K2 avec le modèle de draft associé. En termes de qualité de sortie, les deux configurations sont identiques par construction ; le seul axe qui peut varier est la vitesse de décodage.

Pour mémoire, voici ce qu'est A.X K2 : un décodeur Mixture-of-Experts de 688B au total, 33B actifs, avec 256 experts plus un expert partagé (8 actifs par passe forward), 61 couches, 64 têtes d'attention et un vocabulaire de 163 840 tokens, publié avec des poids ouverts sous Apache 2.0 le 29 juillet. Il a été pré-entraîné sur environ 8,2 billions de tokens nativement en MXFP8, utilise la Sparse Gated Attention de SK Telecom pour l'efficacité sur les contextes longs, et dispose d'un contexte de 262 144 tokens (128K natif étendu à 256K via YaRN). SK Telecom rapporte une moyenne de +32,2 points de pourcentage par rapport à A.X K1 sur 14 benchmarks, avec des évaluations de contexte long et d'agents en hausse d'environ 83,9 points — le tout rapporté par le fournisseur, sans score composite indépendant publié à ce jour.

DSpark est conçu spécifiquement pour cette architecture. La fiche technique indique qu'il est adapté à la structure MoE du A.X K2, à son agencement de l'attention et à sa configuration native de 256K, et qu'il n'est validé pour aucune autre cible. Il hérite du même contexte de 262 144 jetons, donc son exécution ne vous coûte rien en termes de taille de fenêtre.

Lecture de la fiche modèle : connaissable, pas encore confirmé

Le repo vous donne une image claire de ce qu'est le modèle, et une courte liste de ce qu'il ne vous dit pas.

Connaissable aujourd'hui :

Il s'agit d'un checkpoint réservé au rôle de drafter, sans utilisation autonome, chargé par vLLM aux côtés de A.X K2 via le décodage spéculatif.

La licence est Apache 2.0 ; les poids sont libres à télécharger et à utiliser.

• La longueur du contexte correspond à celle d'A.X K2, soit 262 144 jetons.

Il s'exécute via le fork vLLM de SK Telecom (le dépôt SKT-AI/vllm, branche axk2-v0.23.0) en utilisant un indicateur --speculative-config.

• La méthode est documentée dans un article, « DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation » (arXiv:2607.05147, soumis le 6 juillet 2026) — cet article est également la source des chiffres d'accélération que vous verrez cités.

• Aucun fournisseur d'inférence ne le déploie aujourd'hui, donc il n'y a pas d'API hébergée à appeler.

Pas encore confirmé :

• Une annonce officielle — la carte promet une sortie publique « dans les prochains jours ».

• Tout chiffre d'accélération spécifique à A.X K2. L'évaluation est en cours et chaque métrique de performance reste à déterminer.

• Dans quelle mesure cela aide réellement sous charge, ce que la carte signale comme « dépendant de la charge de travail ».

• Toute mesure indépendante du modèle préliminaire effectuée par une tierce partie.

En quoi DSpark se distingue du décodage spéculatif ordinaire

Le décodage spéculatif est une astuce bien rodée : un petit modèle rapide ébauche une prédiction des quelques tokens suivants, et le grand modèle vérifie l'ensemble de la prédiction en une seule passe avant, acceptant le préfixe qui passe la vérification avant de faire un pas correctif. Bien fait, cela réduit considérablement la latence sans perte de qualité.

Le hic, comme l'article DSpark le formule, c'est que les récents rédacteurs parallèles — qui proposent de longues séquences en une seule passe — souffrent d'un « déclin rapide de l'acceptation », parce que les derniers jetons de l'ébauche ne portent aucune dépendance vis-à-vis des premiers, et sont donc rejetés beaucoup plus souvent. Et vérifier aveuglément de longs blocs gaspille la capacité des lots sur des jetons susceptibles d'être rejetés, ce qui nuit au débit précisément dans les systèmes de service à forte concurrence.

DSpark {{1}}attaque les deux problèmes{{/1}} :

• Drafting semi-autorégressif. Il couple un backbone parallèle avec un module séquentiel léger, ajoutant une modélisation des dépendances intra-bloc afin que les jetons de draft ultérieurs dépendent des jetons antérieurs — c'est ce qui atténue la dégradation du suffixe.

• Vérification planifiée par confiance. Au lieu de vérifier une longueur de bloc fixe, elle adapte la longueur de vérification à chaque demande, en fonction des probabilités estimées de survie du préfixe et du profil de débit du moteur. La vérification devient sensible à la charge.

Les chiffres de l'article — et ce qu'ils ne vous disent pas

Voici le chiffre que vous verrez cité : DSpark « accélère les vitesses de génération par utilisateur de 60 à 85 pour cent » à des niveaux de débit équivalents, par rapport à la référence de production MTP-1. L’article fait également état d’une longueur acceptée nettement améliorée par rapport aux drafteurs autorégressifs et parallèles de pointe sur des benchmarks hors ligne, et précise que cela évite une sévère dégradation du débit sous des contraintes d’interactivité strictes.

Lisez les petits caractères, car ils comptent pour cette confrontation spécifique : ce chiffre de 60 à 85 % a été mesuré dans le système de service de DeepSeek-V4 sous trafic utilisateur réel — pas sur A.X K2. C'est une affirmation concernant la méthode DSpark déployée sur la pile d'un autre modèle. La fiche DSpark pour A.X K2, en revanche, ne présente encore aucun chiffre d'accélération. Le tableau de bord honnête pour cette paire est donc : une sortie identique par construction, et une accélération que l'article de la méthode suggère comme plausible mais que SK Telecom elle-même n'a pas encore mesurée sur le modèle pour lequel ce point de contrôle provisoire a été construit.

Ce qu'il faut réellement pour le faire fonctionner

La condition préalable est la partie qui fera rebrousser chemin la plupart des gens : vous devez auto-héberger A.X K2. Il n'existe pas d'API hébergée pour le modèle cible — il est à poids ouverts, et servir un MoE de 688B/33B actifs est un engagement d'infrastructure sérieux. DSpark n'a d'intérêt que pour les équipes qui ont déjà pris cet engagement.

Si vous en avez, le coût marginal de l’ajout du modèle de draft est faible :

• Téléchargez le checkpoint draft Apache 2.0 et exécutez le fork vLLM de SK Telecom (branche axk2-v0.23.0).

• Activez le décodage spéculatif via l'option --speculative-config, en la pointant vers le checkpoint DSpark.

• Prévoyez de la mémoire supplémentaire pour les poids provisoires, et acceptez que vous êtes désormais sur un fork fournisseur de vLLM plutôt que sur la version standard — une considération de maintenance.

• Rappelez-vous la mise en garde de l'article lui-même : la vérification n'est pas gratuite. En cas de forte concurrence, une vérification imprudente dévore la capacité du lot, ce qui est exactement le mode de défaillance que la vérification planifiée selon la confiance est conçue pour gérer.

Encore un point à savoir : Hugging Face indique que les téléchargements ne sont « pas suivis pour ce modèle », il n'existe donc aucun indicateur public du nombre d'équipes qui l'ont réellement testé.

Qui devrait choisir quoi

Exécutez simplement A.X K2 si l’une de ces situations vous correspond.

• Vous utilisez vLLM standard et ne voulez pas d'un second checkpoint ni d'un fork de fournisseur dans le chemin.

Vos charges de travail sont limitées par le débit, mais pas par la latence, et les utilisateurs tolèrent d'attendre de longues générations.

• Vous préféreriez attendre la version officielle et les premières mesures indépendantes.

Exécutez A.X K2 et DSpark si c'est vous :

• Vous auto-hébergez A.X K2 et la latence de génération ou le débit de jetons est ce qui pose problème.

• Les charges de travail à contexte long et agentiques font attendre les utilisateurs sur de longues sorties — le régime pour lequel le décodage spéculatif est conçu.

• Vous êtes à l'aise pour exécuter un composant de pré-annonce dont l'inconvénient est limité : dans le pire des cas, il n'aide pas, et il ne peut pas modifier la qualité de la sortie.

Ne choisissez ni l'un ni l'autre si vous n'auto-hébergez pas du tout un MoE de 688B. La souveraineté et les atouts en langue coréenne d'A.X K2 ne vous parviennent que si vous l'exécutez, et de nombreuses équipes accéderont plutôt aux modèles ouverts de pointe via un catalogue hébergé. C'est là que le fait de garder votre intégration agnostique au modèle porte ses fruits : l'endpoint unique compatible OpenAI d'OrcaRouter couvre plus de 200 modèles au prix catalogue du fournisseur avec 0 % de marge, un basculement automatique et un DSL de routage pour composer plusieurs modèles en un seul appel. (Ni A.X K2 ni A.X K2 DSpark n'est hébergé nulle part aujourd'hui — y compris sur OrcaRouter — il s'agit donc du reste de votre pile, pas du routage de cette paire.) La posture reste transposable : testez un modèle non éprouvé sur une fraction du trafic et basculez automatiquement, plutôt que de lui confier un chemin de production.

Que regarder ensuite

L'état des lieux est simple : le dépôt est réel, la méthode est documentée, les mesures ne le sont pas. Les trois points à surveiller sont la publication publique promise (la fiche indique « dans les prochains jours »), les premiers chiffres de débit ou de latence spécifiques au K2 A.X une fois l'évaluation de SK Telecom terminée, et de savoir si un fournisseur d'inférence adoptera le duo — ce qui rendrait DSpark pertinent pour les équipes qui n'hébergent pas elles-mêmes.

FAQ

A.X K2 DSpark peut-il remplacer A.X K2 ?

Non. C'est un point de contrôle exclusivement réservé au drafter, sans usage autonome — il existe pour accélérer le décodage de A.X K2, et non pour s'y substituer. Vous ne pouvez pas exécuter A.X K2 DSpark sans A.X K2.

Est-ce que DSpark change la qualité de sortie de l'A.X K2 ?

Non, par construction. Chaque jeton candidat est vérifié par A.X K2 avant d'être validé, donc la distribution de sortie est inchangée — la fiche décrit l'approche comme étant sans perte.

Dois-je auto-héberger A.X K2 pour utiliser DSpark ?

Oui. DSpark est chargé par vLLM aux côtés de A.X K2, donc il n'a rien à ébaucher, sauf si vous exécutez la cible 688B. Il n'existe aucune API hébergée pour l'un ou l'autre modèle aujourd'hui.

DSpark fonctionne-t-il avec d'autres modèles ?

SK Telecom l'a conçu pour l'architecture MoE, la structure d'attention et le contexte 256K de l'A.X K2, et ne l'a validé pour aucune autre cible.

Le verdict

A.X K2 DSpark vs A.X K2 est un « versus » où la réponse honnête est « les deux ». Si vous exécutez déjà A.X K2 et que les utilisateurs attendent de longues générations, le modèle draft est une expérience gratuite et à faible risque : poids Apache 2.0, pire cas sans accélération, et aucune régression de qualité possible par construction. Si vous n'êtes pas limité par la latence — ou si vous n'hébergez pas du tout un MoE de 688B — vous pouvez l'ignorer en toute sécurité jusqu'à ce que les chiffres d'évaluation de SK Telecom arrivent et que la sortie publique promise rende le modèle officiel. Ce que vous ne devriez pas faire, c'est confondre le chiffre de 60 à 85 % de l'article avec une mesure de ce modèle : pour l'instant, tout ce qui est spécifique à DSpark dans A.X K2 est encore TBD.