DSpark : accélérer l’inférence des LLM grâce au speculative decoding [pdf]

 (github.com/deepseek-ai)
1 points par GN⁺ 6 시간 전 | 1 commentaires | Partager sur WhatsApp
  • DSpark : un framework de speculative decoding combinant génération semi-autorégressive et ordonnancement par confiance
  • Le parallel drafter propose de longs blocs de tokens en une seule passe forward, mais l’absence de dépendances entre tokens provoque une chute du taux d’acceptation en fin de bloc (acceptance decay) ; DSpark résout simultanément ce problème avec une architecture semi-autorégressive et une vérification sensible à la charge
  • Il combine un backbone parallèle lourd avec un module séquentiel léger pour injecter des dépendances internes au bloc, atténuant le suffix decay tout en conservant la vitesse de draft
  • Une confidence head estime, par position, la probabilité de survie du préfixe, et un ordonnanceur sensible au matériel ajuste dynamiquement la longueur de vérification pour chaque requête en fonction de la courbe de débit du moteur
  • Sur des benchmarks offline, amélioration constante de l’accepted length par rapport au baseline autorégressif (Eagle3) et au baseline parallèle (DFlash) ; lors du déploiement en production de DeepSeek-V4, réduction du gaspillage de vérification
  • Par rapport au baseline de production existant MTP-1, accélération de 60 à 85 % de la vitesse de génération par utilisateur à débit identique, ouvrant des zones de performance jusque-là inaccessibles sous de fortes contraintes d’interactivité et élargissant la frontière de Pareto

Définition du problème — deux goulets d’étranglement des parallel drafters

  • Les LLM génèrent les tokens de manière autorégressive : chaque token nécessite une passe forward conditionnée sur tous les tokens précédents. La latence d’inférence est donc proportionnelle à la longueur de sortie, et la faible utilisation GPU ainsi que les temps d’attente élevés constituent des goulets d’étranglement majeurs pour le serving en production
  • Le speculative decoding accélère l’inférence sans perte de qualité : un modèle draft léger propose un bloc candidat, puis le modèle target le vérifie en une seule passe forward ; avec le rejection sampling, le plus long préfixe conforme à la distribution du target est accepté

  • Limites des drafters autorégressifs

    • Ils disposent d’une forte capacité de modélisation en conditionnant chaque position sur les tokens précédents, mais le coût de drafting croît linéairement avec la taille du bloc (𝑇draft ∝ 𝛾), ce qui les contraint à de petits blocs et des architectures peu profondes

  • Limites des parallel drafters

    • Ils génèrent toutes les positions en une seule fois, de sorte que la latence de draft dépend très peu de la taille du bloc, ce qui permet d’utiliser de grands blocs (par exemple 𝛾=16)
    • Chaque position étant prédite indépendamment, ils ne peuvent pas modéliser les dépendances entre tokens, ce qui entraîne des collisions multimodales (multi-modal collision) et une forte baisse du taux d’acceptation en fin de bloc
    • Vérifier sans discernement l’intégralité de longs blocs dégrade le débit, en particulier dans les environnements à forte concurrence où des tokens à haut risque de rejet occupent la capacité de batch
    • La longueur de vérification idéale varie selon deux axes : côté données (les requêtes structurées comme le code ont un taux d’acceptation élevé, les chats ouverts un taux faible) et côté système (à faible charge, une vérification supplémentaire est presque gratuite ; à forte charge, elle empiète sur la capacité des autres requêtes actives)

Architecture — deux composants complémentaires

  • La latence par token est 𝐿 = (𝑇draft + 𝑇verify)/𝜏 ; l’accélération se ramène à trois leviers : réduire 𝑇draft, augmenter 𝜏 et réduire le 𝑇verify effectif

  • Cycle de décodage : à partir du prompt ABC, le modèle target génère le token suivant D (rôle d’ancre) → le backbone parallèle et la tête séquentielle génèrent le draft EFGH et les scores de confiance c1–c4 → l’ordonnanceur conserve le préfixe EFG et retire le token H à faible confiance → le modèle target vérifie en parallèle, accepte E et F, puis, si G est rejeté, génère le token de correction G*

  • Génération semi-autorégressive (Semi-Autoregressive Generation)

    • Un parallel drafter peut générer des combinaisons incohérentes comme “of problem” face à des suites multiples possibles comme “of course”/“no problem”, car chaque position marginalise sur tous les tokens précédents possibles plutôt que sur les tokens précédents réellement échantillonnés
    • Étape parallèle (Parallel stage) : le backbone parallèle (DFlash adopté) effectue une seule passe forward sur l’ensemble du bloc, génère les états cachés et les logits de base, traite l’ancre elle-même comme première position prédite et produit 𝛾 logits à partir de 𝛾 entrées, réduisant le calcul de draft
    • Étape séquentielle (Sequential stage) : ajoute aux logits de base un biais de transition dépendant du préfixe 𝐵𝑘, afin que chaque position soit conditionnée sur les tokens précédents échantillonnés dans le bloc ; induit une distribution de bloc causale par factorisation autorégressive et doit rester suffisamment léger par rapport à l’étape parallèle (𝑇sequential ≪ 𝑇parallel), puisqu’il est séquentiel
      • Tête Markov : simplification en transition du premier ordre dépendant uniquement du token précédent ; approximation de la matrice complète 𝑉×𝑉 par une factorisation de bas rang 𝐵 = 𝑊1𝑊2 (𝑟=256 par défaut), minimisant le stockage et le calcul par étape ; après échantillonnage de “of”, renforce “course” et réprime “problem”, atténuant les collisions inter-modes
      • Tête RNN : accumule tout l’historique du préfixe dans le bloc via un état récurrent 𝑠𝑘 ; les mises à jour par portes donnent accès à l’information antérieure au token précédent, mais la complexité d’implémentation est plus élevée et les caractéristiques de déploiement moins favorables

  • Vérification ordonnancée par confiance (Confidence-Scheduled Verification)

    • Comme le taux d’acceptation des drafts varie selon les domaines (élevé pour le code, faible pour le chat ouvert) et que le coût de vérification de tokens supplémentaires dépend de la charge du moteur, il faut un mécanisme intégré pour router vers le calcul target uniquement les tokens à espérance de gain positive
    • Tête de confiance (Confidence Head) : sort une estimation scalaire 𝑐𝑘 ∈ (0,1) pour chaque position 𝑘 ; modélise la probabilité conditionnelle que le token en position 𝑘 passe la vérification, à condition que tous les tokens précédents soient acceptés ; architecture légère par projection linéaire + sigmoid
      • Apprentissage supervisé avec le taux analytique d’acceptation par étape 𝑐*𝑘 = 1 − ½‖𝑝𝑑𝑘 − 𝑝𝑡𝑘‖1 (distance de variation totale entre distributions draft et target)
    • Calibration a posteriori — Sequential Temperature Scaling (STS) : l’ordonnancement sensible au matériel requiert des valeurs absolues de probabilité d’acceptation cumulée, mais les confiances neuronales tendent à être surconfiantes ; comme chaque 𝑐𝑖 est une probabilité conditionnelle, factorisation par produit cumulé du préfixe ; recherche en grille 1D de gauche à droite sur un jeu de validation held-out pour minimiser l’ECE ; transformation préservant l’ordre, donc le classement des tokens est conservé
    • Ordonnanceur de préfixes sensible au matériel (Hardware-Aware Prefix Scheduler) : formalise le choix de la longueur de vérification comme un problème de maximisation du débit global ; pour 𝑅 requêtes actives, utilise SPS(𝐵) (table de coûts profilée une seule fois à l’initialisation du moteur) et maximise 𝛩 = 𝜏·SPS(𝐵)
      • Comme la probabilité de survie 𝑎𝑟,𝑗 est monotone non croissante en 𝑗, un tri global et une sélection gloutonne respectent naturellement la dépendance de préfixe à l’intérieur des blocs ; admission incrémentale via consultation de table en 𝑂(1)
      • Le speculative decoding sans perte exige une propriété de non-anticipation (non-anticipating) ; les caractéristiques Markov dépendant des tokens précédemment échantillonnés, une recherche globale a posteriori divulgue l’information 𝑥𝑟,𝑘 et induit un biais de sélection
      • Un mécanisme d’arrêt anticipé (early-stopping) interrompt immédiatement lorsque le débit baisse, forçant les décisions d’admission à ne dépendre que du préfixe traité jusqu’à cette étape ; la garantie d’optimum global n’existe que lorsque l’objectif 𝛩 est unimodal

Entraînement (Training)

  • Échantillonnage aléatoire de nombreuses positions d’ancrage dans les séquences target pour constituer des blocs d’entraînement de 𝛾 tokens
  • Le modèle target reste figé (frozen) pendant tout le processus ; le modèle draft partage et fige la couche d’embedding et le LM head ; seuls le backbone drafter, le bloc séquentiel et la tête de confiance sont mis à jour
  • L’objectif d’entraînement est une somme pondérée de trois termes : perte d’entropie croisée Lce, perte d’alignement de distribution Ltv et perte de confiance Lconf
    • Tous les termes sont pondérés par position avec 𝑤𝑘 = exp(−(𝑘−1)/𝛾), afin d’accentuer les premières positions, qui contribuent davantage à la longueur d’acceptation attendue dans une vérification fondée sur le préfixe
    • Ltv pénalise la distance de variation totale ; le taux d’acceptation par étape étant égal à 1 − ½‖𝑝𝑑 − 𝑝𝑡‖1, minimiser Ltv revient à maximiser le taux d’acceptation attendu
    • Poids par défaut : 𝛼ce = 0.1, 𝛼tv = 0.9, 𝛼conf = 1.0

Expériences — benchmarks offline

  • Configuration

    • Modèles target : Qwen3-{4B, 8B, 14B}, Gemma4-12B / drafters comparés : parallel drafter SOTA DFlash, drafter autorégressif Eagle3
    • Réentraînement complet avec le même framework et les mêmes données ; horizon TTT d’Eagle3 (7) aligné sur la taille de bloc de DFlash et DSpark (7) ; nombre de couches draft : 1 pour Eagle3, 5 pour DSpark et DFlash
    • Données d’entraînement : Open-PerfectBlend, 1,3 million d’échantillons (chat 17,6 %, maths 39,4 %, code 38,9 %, instruction-following 4,1 %) ; seuls les prompts sont utilisés et les réponses sont régénérées par chaque modèle target ; entraînement sur 10 epochs
    • Domaines d’évaluation : maths (GSM8K, MATH500, AIME25), code (MBPP, HumanEval, LiveCodeBench), chat quotidien (MT-Bench, Alpaca, Arena-Hard), température d’échantillonnage 1.0, rapport de la longueur d’acceptation 𝜏 par round

  • Principaux résultats

    • L’évaluation offline désactive l’ordonnanceur de confiance afin d’isoler la seule qualité du draft avec un bloc fixe
    • Sur Qwen3-4B, 8B et 14B, amélioration de la longueur d’acceptation moyenne macro de 30,9 %, 26,7 % et 30,0 % par rapport à Eagle3, et de 16,3 %, 18,4 % et 18,3 % par rapport à DFlash ; gains cohérents aussi sur Gemma4-12B, confirmant la généralisation entre familles de modèles
    • Les tâches structurées ont une longueur d’acceptation plus élevée que le chat ouvert (pour Qwen3-4B : maths 5,57 et code 5,12 vs chat 3,49) ; la variance de prédictibilité des données entraîne un gaspillage avec une longueur de vérification statique, motivant l’ordonnancement par confiance

Analyse expérimentale

  • Pourquoi la génération parallèle dépasse l’autorégression

    • Observation contre-intuitive : les drafters parallèles et semi-autorégressifs produisent une longueur d’acceptation supérieure à celle d’Eagle3 entièrement autorégressif ; analyse via le taux d’acceptation conditionnel par position (dénominateur limité aux cas où toutes les positions précédentes sont acceptées)
    • Avantage de capacité en position 1 : la première position ne dépend que du contexte target ; Eagle3 est contraint à un réseau peu profond à cause d’une latence en 𝑂(𝛾), tandis qu’un drafter parallèle en 𝑂(1) peut utiliser un réseau plus profond ; DFlash démarre plus haut qu’Eagle3 (maths 0,88 vs 0,81, chat 0,72 vs 0,53) ; le rejet du premier token invalidant tout le bloc, cet avantage initial a un effet important sur la longueur d’acceptation finale
    • Limite d’indépendance des positions tardives : aux positions 2–7, Eagle3 exploite la certitude conditionnelle pour se maintenir ou progresser (chat 0,53→0,74), tandis que DFlash baisse fortement (code 0,87→0,78, chat 0,72→0,63), générant des suffixes incohérents du fait des collisions multimodales
    • Atténuation de l’effondrement du suffixe par le semi-autorégressif : DSpark hérite de la forte acceptation initiale du backbone parallèle profond (maths démarrant à 0,93) tout en réprimant l’effondrement tardif grâce à une tête séquentielle légère, conservant un taux d’acceptation conditionnel élevé et stable sur tout le bloc

  • Un peu d’autorégression suffit à produire un grand effet

    • Profondeur du drafter : à taille de bloc 7 fixe, les performances augmentent monotoniquement quand le nombre de couches DSpark passe de 1 à 5 ; le gain marginal est maximal de 1 à 2 couches ; DSpark à 2 couches surpasse DFlash à 5 couches dans tous les domaines, démontrant l’efficacité en paramètres de la tête séquentielle
    • Longueur de proposition : à profondeur 5 fixe, quand la longueur de draft s’étend sur {4,8,12,16}, DSpark dépasse DFlash à chaque longueur ; l’écart s’accroît avec 𝛾 (à 𝛾=7 : maths 16 %, code 15 %, chat 18 % ; à 𝛾=15 : 30 %, 26 %, 22 %) ; la tête RNN n’apporte qu’un léger gain additionnel sur les grandes longueurs, d’où l’adoption de la tête Markov par défaut
    • Surcoût de latence : en moyenne sur un batch de 128 et des longueurs de contexte {512,1024,2048,4096}, la latence du bloc séquentiel est négligeable ; étendre la longueur de draft de 4 à 16 n’ajoute que 0,2 à 1,3 % à la latence totale par round, tout en améliorant la longueur d’acceptation jusqu’à 30 %

  • Rôle de la tête de confiance — vérifier plus intelligemment, pas plus longtemps

    • Diagnostic par balayage d’un seuil statique avec Qwen3-4B : quand le seuil augmente, le filtrage des tokens rejetés améliore le taux d’acceptation, avec l’effet le plus marqué en chat (45,7 %→95,7 %) ; l’effet est plus progressif en maths (76,9 %→92,5 %) et code (67,6 %→92,0 %)
    • Un seuil statique ignore la charge système et est sous-optimal en serving dynamique ; le modèle de confiance possède un fort pouvoir discriminant (ROC-AUC 0,81–0,90) mais est surconfiant (ECE 3–8 %) ; après STS, l’ECE moyen est abaissé à environ 1 %, fournissant des estimations de survie fiables

Déploiement en production

  • Entraînement scalable

    • Déploiement conjoint avec DeepSeek-V4-Flash et Pro preview ; le backbone parallèle est constitué de 3 couches MoE avec mHC et d’une sliding window attention de 128 ; taille maximale de bloc 𝛾=5, tête Markov utilisée ; tête de confiance entraînée end-to-end puis calibrée par STS
    • Communication d’états cachés (Hidden state communication) : au lieu de transmettre les logits sur tout le vocabulaire (𝑉≈10⁵), seuls les états cachés juste avant le LM head sont communiqués, et le LM head est exécuté localement sur le worker draft uniquement aux positions échantillonnées, réduisant la complexité de communication par token à 𝑂(𝑑)
    • Packing de séquences borné par l’ancre (Anchor-bounded sequence packing) : échantillonne un nombre fixe d’ancres draft et packe les blocs de prédiction isolés en batchs denses ; maintient le masquage causal entre multiples séquences indépendantes via des index d’attention au niveau token, tout en évitant l’overhead de padding

  • Application pratique de l’ordonnanceur

    • Deux conflits : l’algorithme suppose une courbe de capacité lisse et unimodale, alors que le SPS(𝐵) réel présente des baisses discrètes en escalier ; l’ordonnancement dynamique des tokens à chaque étape entre en conflit avec le replay continu de CUDA graph et le Zero-Overhead Scheduling (ZOS)
    • Adaptation par ordonnancement asynchrone : comme ZOS exige la taille du batch suivant avant la fin de l’étape courante, la capacité de vérification est approximée à partir des sorties de confiance de deux étapes auparavant ; les candidats de l’étape courante sont triés selon la confiance cumulée la plus récente, tandis que les prédictions passées ne servent qu’à déterminer la longueur de troncature dynamique (𝐾) ; le problème est reformulé en sélection dynamique top-𝐾
    • Suppression de l’arrêt anticipé afin d’activer une recherche globale non contrainte ; comme seule l’histoire d’il y a deux étapes est évaluée, elle reste isolée de la réalisation du token courant 𝑥𝑟,𝑘 et forme une barrière causale, conciliant maximisation du débit physique au-delà des falaises matérielles et préservation exacte de la distribution target

  • Inférence à haut débit et faible latence

    • Le serving de production optimise simultanément la latence par requête et le débit total ; dans ce déploiement, les contraintes de capacité KV-cache et de trafic utilisateur maintiennent la taille de batch effective sous le seuil de saturation GPU, ce qui simplifie les deux objectifs en une forte corrélation plutôt qu’une concurrence
    • La prise en charge de requêtes de longueur variable est le défi ; avec des kernels de décodage à longueur fixe, un traitement naïf entraîne padding, charge déséquilibrée et sous-utilisation GPU ; tous les tokens des requêtes sont aplatis en éléments indépendants, et les dépendances intra-séquence sont transmises via le marker tensor de la sparse attention ; dans DeepSeek-V4, seuls les kernels index-attention et compress sont modifiés pour prendre en charge le routage à longueur variable

  • Performances sur trafic utilisateur réel

    • Comparaison de DSpark-5 (𝛾=5) avec le baseline MTP-1 sur les moteurs de production V4-Flash et Pro ; MTP-1 était une configuration à token unique conservée parce que les drafters multi-tokens statiques (MTP-3/5) dégradaient le débit à forte concurrence, et a été remplacé par DSpark deux semaines après le lancement de DeepSeek-V4-preview
    • V4-Flash : amélioration de 51 % du débit à un SLA de 80 tok/s/user ; à 120 tok/s/user, MTP-1 approche sa limite opérationnelle et DSpark affiche un avantage nominal de 661 % (à interpréter non comme un multiple absolu, mais comme la preuve d’un élargissement de la frontière d’interaction) ; à débit identique, génération par utilisateur accélérée de 60 à 85 %
    • V4-Pro : amélioration de 52 % à 35 tok/s/user ; avantage nominal de 406 % à 50 tok/s/user ; accélération de 57 à 78 % à capacité identique ; globalement, la frontière throughput–interactivity est déplacée vers l’extérieur
    • Comportement d’adaptation à la charge : à concurrence intermédiaire (moins de 200 requêtes pour V4-Flash, moins de 150 pour V4-Pro), l’ordonnanceur étend les 2 tokens statiques de MTP-1 à environ 4–6 tokens par requête, augmentant les tokens acceptés par passe forward ; quand la concurrence sature, il réduit progressivement la longueur de vérification pour élaguer les tokens à faible confiance avant qu’ils ne consomment la capacité de batch

  • Limites

    • L’ordonnanceur de préfixes minimise le gaspillage de vérification target, mais il subsiste un coût de draft fixe lié à la génération initiale du bloc de 𝛾 tokens par le backbone parallèle ; pour les requêtes complexes à taux d’acceptation intrinsèquement faible, ce calcul préalable ne peut pas être récupéré
    • Une amélioration future possible serait un early exiting dans le modèle draft sensible à la difficulté (difficulty-aware early exiting), permettant à ces requêtes de contourner la génération du bloc complet

Conclusion

  • Sur le plan structurel, le paradigme semi-autorégressif combinant un backbone parallèle lourd et une tête séquentielle légère atténue l’effondrement brutal du suffixe des drafters parallèles indépendants
  • Sur le plan système, le choix de la longueur de vérification est formalisé comme un problème de maximisation du débit global, avec un ordonnanceur de préfixes sensible au matériel qui ajuste dynamiquement le budget de vérification à partir de probabilités de survie calibrées et de la charge moteur en temps réel
  • De larges évaluations offline dépassent les baselines SOTA autorégressifs et parallèles ; le déploiement réel sur DeepSeek-V4 démontre sa valeur pratique via le maintien d’une forte concurrence sous charge, l’accélération de la génération par utilisateur et l’élargissement de la frontière de Pareto du serving LLM

À lire aussi

1 commentaires

 
GN⁺ 6 시간 전
Avis sur Hacker News

  • DeepSeek ne se contente pas de repousser les limites : l’entreprise publie aussi d’excellents articles expliquant comment elle a obtenu ces gains de performance.
    Malheureusement, les laboratoires américains ne le font plus vraiment, et il semble que les travaux les plus intéressants en IA viennent aujourd’hui de laboratoires chinois.

    • Google publie encore beaucoup de travaux de recherche sur les architectures de LLM.
      Ils ont introduit le décodage spéculatif pour les LLM en 2022[1], et ont aussi publié cette année du code permettant de faire du décodage spéculatif avec les modèles Gemma 4[2].

      [1] https://arxiv.org/abs/2211.17192

      [2] https://github.com/google-gemma/cookbook/blob/main/docs/mtp/...

    • Les entreprises américaines d’IA doivent répondre à d’énormes investissements ; on dirait donc qu’elles cherchent un moat magique pour justifier leur valorisation.
      Rendre ce genre d’optimisations public réduirait fortement leur avantage concurrentiel.

    • C’est peut-être aussi une ouverture dictée par la nécessité.
      Comme les labos américains ouvrent la voie en première ligne, on peut supposer que DeepSeek publie ce qu’il possède en open source pour niveler le terrain de jeu.

    • DeepSeek est en train de commoditiser les gains de performance sur lesquels les labos américains comptent pour rapporter de l’argent à leurs investisseurs.

    • Il est temps que l’Occident cesse de voir les Chinois uniquement comme « des gens très méchants vivant sous une dictature ».

  • Les modèles Hugging Face sont déjà en ligne, et il semble que le modèle d’origine intègre un module de décodage spéculatif, ce qui est plutôt cool.

    Flash : https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-DSpark

    Pro : https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

    J’ai hâte de voir si cela sera aussi intégré à DwarfStar pour l’inférence locale.
    J’utilise beaucoup le modèle Flash depuis qu’antirez a publié la quantification 2 bits.

    • Y a-t-il une chance que cela soit appliqué aussi à Qwen 27B ?

  • À ce stade, j’ai l’impression que DeepSeek est presque la seule entreprise d’IA qui cherche réellement à innover, plutôt que simplement à viser la première place des benchmarks.
    Des acteurs comme OpenAI, Anthropic ou Google semblent davantage concentrés sur la concurrence entre eux que sur la poursuite de l’innovation.

    • Je pense qu’il faut aussi inclure d’autres laboratoires chinois, comme Moonshot (développeur de Kimi) et Z.ai (développeur de GLM).
      Eux aussi innovent et continuent de partager publiquement leurs recherches.
      Il me semble même que le fondateur de Moonshot a publié sur Twitter une vidéo de 40 minutes expliquant les techniques qui soutiennent Kimi.

    • Beaucoup d’entreprises américaines ont depuis longtemps pour stratégie de retenir les utilisateurs, quels que soient les moyens employés.
      La qualité et l’innovation sont secondaires ; elles cherchent à dominer le marché, enfermer les utilisateurs, puis exercer leur influence sur la régulation et le lobbying pour conserver leur pouvoir.

    • Ces entreprises se concurrencent aussi par l’innovation.
      L’innovation apporte davantage d’utilité aux clients, mais la technologie n’est simplement pas publiée.
      Les secrets industriels sont secrets pour une raison.

      Si DeepSeek semble « la plus innovante », c’est peut-être parce que c’est ce qui est observable de l’extérieur.
      C’est un peu comme conclure que les modèles publiés sont les plus beaux de toute la population simplement parce que tout le monde ne diffuse pas ses photos au public.

    • Les grands labos font déjà ce genre de choses depuis au moins un an.

    • Qwen aussi.

  • J’utilise DeepSeek v4 pro dans Kilo Code depuis un mois, et il est excellent.
    Il est rapide, fiable, dispose d’une grande fenêtre de contexte et coûte vraiment peu cher.
    Ce mois-ci, j’ai consommé 1,5 milliard de tokens pour 40 dollars ; certes, la plupart étaient en cache, mais cela reste bon marché.

    • Dans omp, j’utilise DeepSeek comme agent task et quicktask, et Sonnet pour le reste.
      Mes dépenses en IA ont beaucoup baissé, passant de 40 dollars par jour à 10 dollars par jour.
    • Je serais curieux de savoir quel fournisseur tu as utilisé.
      Sur OpenRouter, j’ai dépensé 40 dollars assez vite.
      Il n’y avait pas beaucoup d’allers-retours dans la conversation, le contexte était d’environ 300 000 tokens et la sortie d’environ 15 000 lignes.
      J’utilisais opencode, mais je ne sais pas vraiment s’il est possible d’afficher le nombre total de tokens.
    • As-tu comparé Kilo à Pi ou OpenCode ?
      Je connais bien les deux, mais je suis toujours à la recherche d’alternatives.
    • Existe-t-il un moyen de voir combien de tokens on a utilisés dans Claude Code Pro ?

  • Est-ce vraiment plus récent ou meilleur que le décodage spéculatif de 2022 ? https://arxiv.org/abs/2211.17192

    • Cet article est cité dans les sections « introduction » et « background » de celui-ci.
      Le nouvel article apporte des améliorations en supprimant plusieurs goulets d’étranglement.
    • Il semble se concentrer sur l’amélioration du modèle de brouillon et de la politique de vérification, afin qu’à l’échelle de DeepSeek la spéculation se traduise par un pur gain de vitesse, et non par un travail de vérification gaspillé.

  • Le timing ne semble pas fortuit.
    On dirait une démonstration contrastant ouverture et forte régulation.

    • Chine = ouverte, États-Unis = forte régulation : quelle drôle de timeline.
      Cela dit, c’est possible parce que cela s’aligne sur les objectifs de Xi.
    • Personne n’a forcé Anthropic à lancer une offensive médiatique dramatisant les risques de ses nouveaux modèles d’IA.
      Franchement, ils ne peuvent s’en prendre qu’à eux-mêmes.

  • Le titre n’est pas terrible.
    Ce n’est pas le titre de l’article, mais la première ligne du résumé.
    Le décodage spéculatif pour l’inférence des LLM a déjà été publié en 2022 : https://arxiv.org/abs/2211.17192

    Cet article semble être une amélioration du décodage spéculatif, mais je ne l’ai pas encore lu.

  • À cause du nom, j’ai d’abord cru que c’était lié à DGX Spark.
    Par coïncidence, il y a eu récemment beaucoup de travaux pour améliorer les performances d’inférence de DGX Spark, et comme MTP apporte 50 à 100 % d’accélération, DSpark devrait aussi être assez utile dans ce but.

  • Cela a probablement été utilisé en production pendant un moment, et c’est sans doute l’une des raisons pour lesquelles ils ont pu fortement baisser les prix il y a un mois.

    • Oui.
      La section 5 traite du déploiement réel.
      La section 5.1 dit : « DSpark draft models are co-deployed with the preview versions of DeepSeek-V4-Flash and DeepSeek-V4-Pro », et la section 5.4 dit : « MTP-1 represents the former production setup, having been superseded by DSpark two weeks following the DeepSeek-V4-preview release ».
    • Lookahead Sparse Attention a probablement aussi joué un grand rôle, car cela réduit fortement l’utilisation mémoire.
    • Bien vu.
      Ils ont baissé les prix de 75 %, ce qui semble correspondre exactement aux gains de vitesse et d’optimisation de l’inférence.

  • On va bientôt entrer dans un monde où il existera une grande variété de petits modèles dédiés au décodage spéculatif, propres à chaque cas d’usage, entreprise, voire individu.

    • Ce serait bien, et j’espère que le matériel ne deviendra pas impossible à obtenir.

    • Oui.
      Ils seront fortement contraints par des garde-fous sophistiqués.

      On va clairement dans cette direction.
      Les énormes modèles qui cherchent à tout dévorer dans le monde souffrent, en comparaison, de rendements décroissants très marqués.

    • On dirait que tu n’as manifestement pas lu les articles récents sur le décodage spéculatif.
      Cela fait déjà un moment que n’importe quel modèle peut être utilisé pour spéculer au bénéfice d’un autre.
      Les problèmes de tokenisation qui empêchaient cela auparavant ont été résolus.