A.X-K2-DSpark : le modèle draft à décodage spéculatif de SK Telecom est arrivé sans prévenir

A.X-K2-DSpark est un modèle que vous n'appellerez probablement jamais directement — et c'est exactement pour cela qu'il vaut la peine de s'y intéresser. SK Telecom l'a discrètement publié sur Hugging Face, sans article de lancement ni communiqué de presse ; la fiche du modèle commence simplement par indiquer que le checkpoint est « actuellement en validation finale et prévu pour une sortie publique dans les prochains jours ». Il s'agit d'un checkpoint de type drafter uniquement, destiné au décodage spéculatif, avec une seule mission : rendre le modèle phare A.X K2 de SK Telecom, fort de 688 milliards de paramètres, plus rapide et moins coûteux à servir en proposant des jetons que A.X K2 vérifie ensuite. Voici ce que le dépôt nous apprend réellement, ce qui reste non confirmé, et pourquoi un petit modèle auxiliaire comme celui-ci est l'endroit où se cache la prochaine série de réductions des coûts de service des LLM.

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

A.X-K2-DSpark n'est pas un modèle autonome à proprement parler. La fiche du modèle le précise dans ses notes d'utilisation prévue : il s'agit d'un « point de contrôle réservé à la rédaction » sans « utilisation autonome », chargé par vLLM aux côtés de sa cible, A.X K2, dans une boucle de décodage spéculatif. C'est l'étape de rédaction d'un générateur en deux étapes — un petit modèle propose rapidement des jetons candidats, et le modèle cible les vérifie avant qu'un jeton ne soit validé dans la sortie.

La cible, pour le contexte, est l'un des plus grands modèles open-weight existants. A.X K2 est le modèle Mixture-of-Experts de SK Telecom, avec 688B de paramètres au total et 33B actifs, publié sur Hugging Face fin juillet 2026 sous licence Apache 2.0, construit sur une architecture de base qui associe Multi-head Latent Attention à DeepSeek Sparse Attention et ajoute la modification longue-contexte Sparse Gate Attention propre à SK Telecom. A.X-K2-DSpark se conditionne sur les états cachés d'A.X K2 et ajoute une modélisation légère des dépendances locales entre positions candidates, ce qui lui permet de proposer plusieurs tokens en parallèle au lieu de rédiger un brouillon de manière strictement autorégressive. Chaque candidat est ensuite vérifié par A.X K2 avant d'être validé — c'est pourquoi la fiche du modèle qualifie le résultat de « lossless by construction » : la distribution de sortie est inchangée par le rédacteur de brouillon ; seule la vitesse de service change.

Comment fonctionne le décodage spéculatif, et pourquoi un MoE de 688B en a besoin

Le décodage spéculatif existe parce que la génération autorégressive est sérielle et limitée par la mémoire. Générer chaque token implique de lire les poids du modèle depuis la mémoire, et pour un modèle de 688B, cela représente un nombre énorme d’octets à déplacer pour chaque token — même si seulement 33B paramètres sont actifs à chaque passage avant. L’astuce consiste à dépenser un peu de calcul supplémentaire sur un petit modèle draft qui prédit les prochains tokens d’un coup, puis à faire vérifier toutes les prédictions par le grand modèle en un seul passage avant et à conserver le préfixe le plus long qui correspond à sa propre distribution. Quand le modèle draft est bon, on obtient deux ou trois tokens par passage du grand modèle au lieu d’un, sans aucun changement dans la sortie finale.

Tout se joue sur le taux d'acceptation. Un drafter qui devine mal voit ses propositions rejetées, et la passe de vérification coûte toujours la même bande passante mémoire, donc l'accélération s'évapore. C'est pourquoi les drafters sont devenus un sujet de recherche sérieux à part entière : pour un modèle de la taille d'A.X K2, la différence entre une accélération de 1,5x et de 3x est la différence entre une flotte de service de dix GPU et une de cinq. C'est dans des couches d'efficacité comme celles-ci que viendra la prochaine série de baisses de prix des API LLM hébergées — non pas des chiffres de qualité des modèles de base, mais de la stack de service qui les enveloppe.

DSpark est la méthode — et elle vient de l'équipe DeepSeek

Le « DSpark » dans le nom du modèle est une technique spécifique, et ce n'est pas une invention de SK Telecom. La fiche du modèle cite l'article « DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation » (arXiv 2607.05147), une prépublication du 6 juillet 2026 provenant d'une équipe de 33 auteurs chez DeepSeek, qui a déployé cette méthode dans son propre système de service de l'ère V4 en conditions de trafic réel. SK Telecom a adapté la même technique à son propre modèle cible.

Les deux contributions de l'article correspondent directement à ce que décrit la carte A.X-K2-DSpark. Premièrement, la génération de brouillons semi-autorégressive : un backbone parallèle propose des tokens sur une fenêtre, tandis qu'un module séquentiel léger modélise les dépendances entre les positions candidates, résolvant le problème classique selon lequel les taux d'acceptation des générateurs parallèles chutent fortement le long de la séquence proposée. Deuxièmement, la vérification planifiée par confiance : au lieu de toujours vérifier un nombre fixe de tokens de brouillon, le système estime la probabilité que chaque préfixe survive et fixe la longueur de vérification par requête, ajustée au profil de débit du moteur — l'effort de vérification est ainsi adapté à la charge plutôt qu'uniforme.

Selon les chiffres mêmes de l’article — qui sont des mesures des auteurs, non vérifiées de manière indépendante — DSpark a offert une génération par utilisateur 60 à 85 % plus rapide que la référence de production MTP-1 à débit équivalent, et a évité une grave dégradation du débit sous des contraintes d’interactivité strictes. Deux réserves sont importantes pour lire cette publication. Ces résultats ont été mesurés sur la pile et la cible propres aux auteurs, et non sur A.X K2 ; et la fiche de modèle A.X-K2-DSpark indique explicitement que sa propre évaluation est encore en cours. L’article prouve que la méthode fonctionne en production. Il ne prouve pas que le point de contrôle de SK Telecom reproduise ces gains — c’est précisément la partie non confirmée.

Ce que dit le dépôt — et ce qu'il ne dit pas.

Voici ce qui est actuellement connaissable depuis le dépôt, tout cela provenant de la fiche du modèle :

• Rôle — point de contrôle réservé au drafter pour A.X K2 ; aucune utilisation autonome ; non validé avec aucune autre cible et « incompatible avec les modèles non liés. »

• Cible — A.X K2, 688B au total / 33B actifs en mélange d'experts.

• Longueur du contexte — 262 144 tokens (256K), correspondant à la configuration native de l'A.X K2.

• Licence — Apache 2.0.

• Mécanisme — Génération semi-autorégressive DSpark ; chaque candidat est vérifié par A.X K2 avant validation (sans perte).

• Statut — "actuellement en validation finale" ; sortie prévue "dans les prochains jours."

Et voici ce qui n'est explicitement pas encore confirmé :

• Précision et taille du point de contrôle — les deux sont indiqués comme TBD sur la fiche du modèle.

• Débit, TPOT et longueur moyenne acceptée — les trois chiffres qui vous diraient si le rédacteur fonctionne réellement, tous à déterminer, avec « l'évaluation est actuellement en cours ».

• Résultats par domaine — la carte promet des décompositions en coréen, mathématiques, sciences et code « plus tard », sans date.

• Une annonce officielle — SK Telecom n'a annoncé A.X-K2-DSpark nulle part où nous puissions le trouver ; le dépôt est l'annonce.

• Scores indépendants — il n'en existe aucun. Tout ce qui figure sur la carte est une affirmation de SK Telecom, et la majeure partie n'est encore qu'une promesse.

Le nombre non confirmé le plus important est la longueur moyenne acceptée — le nombre moyen de jetons de brouillon qu'A.X K2 accepte par passe de vérification. Ce seul nombre décide si ce générateur de brouillon est un simple plus de 1,2x ou une mise à niveau de service de 2,5x, et c'est aussi le nombre le plus susceptible de circuler sans source une fois la version en ligne. Traitez-le avec scepticisme lorsqu'il apparaît : le chiffre de 60–85% de l'article DSpark a été mesuré sur la pile de service d'un modèle différent, et A.X K2 a ses propres caractéristiques d'acceptation de brouillons.

Comment vous l'exécuteriez réellement

Exécuter le drafter signifie servir A.X K2 depuis le fork de vLLM de SK Telecom. L'exemple de la fiche du modèle, légèrement tronqué, est :

vllm serve skt/A.X-K2 --tensor-parallel-size 8 --tool-call-parser hermes --reasoning-parser deepseek_v3 --speculative-config '{"method": "dspark", "model": "skt/A.X-K2-DSpark", "num_speculative_tokens": N}'

avec le fork installé depuis le dépôt vLLM de SKT-AI sur la branche axk2-v0.23.0. Quelques mises en garde que la fiche assume d'emblée : la configuration cible le contexte natif de 256K de l'A.X K2, et l'accélération dépend de la charge de travail — la concurrence, la longueur de sortie, le taux d'acceptation et le coût relatif du draft par rapport à la vérification font tous varier le résultat. En d'autres termes, il s'agit d'une infrastructure de service, pas d'un script à télécharger et à exécuter. Vous avez besoin des poids de l'A.X K2, d'un cluster assez grand pour le tensor-parallel 8, et de la patience pour ajuster num_speculative_tokens en fonction de votre propre trafic. C'est un projet pertinent pour une équipe qui sert déjà l'A.X K2 ; ce n'est pas une raison pour en monter un.

L'économie : les couches d'efficacité surpassent les allégations de qualité

La raison pour laquelle un modèle de draft pour un modèle de 688B mérite d'être suivi est que la course aux benchmarks des modèles de base est en grande partie saturée, tandis que la course aux coûts de service ne l'est pas. Le propre lancement de SK Telecom misait déjà sur l'efficacité — le changement Sparse Gate Attention aurait augmenté le débit total de tokens de 67,7 % par rapport à la génération précédente pour des entrées de 120K tokens — et un modèle de draft applique la même thèse au décodage. Chaque token de draft accepté est une passe avant du grand modèle que vous n'avez pas payée.

Pour quiconque consomme ces modèles via une API plutôt qu'en les hébergeant, le drafter est invisible — et c'est précisément le but. Lorsqu'un fournisseur ajoute le décodage spéculatif à sa pile de service, vous ne voyez pas un nouveau modèle ; vous voyez le même modèle devenir plus rapide et moins cher par token. La couche de tarification importe pour la même raison : chez OrcaRouter, nous transmettons le prix catalogue du fournisseur directement avec une marge de 0 %, donc lorsque le travail d'efficacité de service d'un fournisseur se traduit par une baisse de prix, c'est en ligne de notre côté le jour même — sans renégociation, sans changement de contrat. Et pour un modèle non éprouvé qui pourrait ou non faire ses preuves, le routage avec bascule automatique est la façon de l'essayer sans y engager une chaîne de production : une seule clé API, et la requête bascule vers un autre fournisseur si le premier se dégrade.

Une note d'honnêteté spécifique à cette version : A.X-K2-DSpark est un checkpoint réservé au drafter, ce n'est donc pas quelque chose qu'une API de modèle hébergé peut router — y compris la nôtre. Les drafters sont un composant côté serveur, pas un produit appelable. Lorsque le drafter sera livré et que les chiffres d'évaluation seront publiés, ce qui apparaîtra dans une liste de prix sera un A.X K2 plus rapide et moins cher — et non un nouvel endpoint appelé « DSpark ».

Quelques questions qui méritent réponse.

Puis-je utiliser A.X-K2-DSpark seul ? Non — c'est le fait déterminant de cette version. Il s'agit d'un checkpoint réservé au draft, sans utilisation autonome ni API publique ; il n'existe que comme auxiliaire dans une boucle de décodage spéculatif vLLM servant A.X K2, et la fiche précise qu'il n'a pas été validé avec une autre cible.

A.X-K2-DSpark est-il un concurrent d'A.X K2 ? C'est tout le contraire. C'est un accélérateur pour A.X K2 — le même modèle devient plus rapide, la distribution de sortie restant inchangée. Considérez-le comme une pièce d'efficacité rapportée, et non comme une nouvelle entrée dans la gamme.

Quand sera-t-il réellement publié ? La fiche du modèle indique qu'il est en validation finale et que sa sortie publique est prévue « dans les prochains jours ». C'est tout ce qui est confirmé. La date à surveiller est le jour où les chiffres TBD — débit, TPOT et longueur moyenne acceptée — seront renseignés, car c'est à ce moment que la sortie cesse d'être une promesse et devient quelque chose que vous pouvez évaluer.

Dois-je y penser si j'utilise A.X K2 via une API ? Probablement pas directement. La pile serveur derrière une API décide si un drafter est dans la boucle ; vous voyez le résultat comme un prix et une latence, pas comme un indicateur. C'est surtout important pour les équipes qui auto-hébergent A.X K2, où l'activation est une modification de configuration vLLM qu'elles contrôlent.

L'histoire ici n'est pas {{1}}le drafter lui-même — c'est ce que le drafter signale{{/1}}. Le travail d'efficacité devient discrètement une catégorie de sortie à part entière, et les modèles les plus intéressants de cette année sont de plus en plus {{2}}des assistants qui rendent les grands modèles abordables, pas des modèles plus grands{{/2}}. {{3}}A.X-K2-DSpark{{/3}} est l'exemple le plus clair à ce jour : {{4}}un checkpoint sans usage autonome, publié avant l'annonce, portant l'essentiel de ses propres preuves comme TBD{{/4}}. Surveillez {{5}}le chiffre de longueur acceptée quand il arrivera, traitez les gains de l'article DSpark comme une preuve de provenance de la méthode plutôt qu'une promesse pour ce checkpoint{{/5}}, et si vous servez A.X K2 vous-même, {{6}}prévoyez un budget pour le benchmark — c'est la seule façon de savoir si le drafter publié discrètement est un petit plus de 1,2x ou la vraie affaire{{/6}}.