Votre facture d'inférence dépend désormais de la quantité de texte que le modèle copie
llama.cpp a accéléré le drafting par recherche dans le prompt. Résultat : une latence qui varie selon le contenu de la charge de travail, et pas seulement selon le nombre de tokens, ce que le modèle de tarification de personne ne prend en compte.
Le token le moins cher est celui que vous ne calculez jamais
Une modification fusionnée dans llama.cpp (le moteur d'inférence C++ qui fait tourner des modèles locaux sur des portables, des Mac, des Raspberry Pi et une bonne partie du matériel déployé sur site) accélère sensiblement le prompt lookup drafting, en particulier sur les contextes longs. La correction n'a rien de spectaculaire : on remplace le balayage brutal de la fenêtre de contexte par une structure indexée qui trouve les correspondances en temps à peu près constant, quelle que soit la quantité de texte déjà présente dans le tampon. La conséquence, elle, est loin d'être anodine. Sur les charges de travail où la sortie recoupe fortement l'entrée (modifications de code, réécritures de documents, réponses fondées sur de la récupération, extraction structurée), le moteur peut désormais émettre plusieurs tokens pour le prix d'un seul, et il le fait sur des contextes de 100 000 tokens, là où l'ancien balayage absorbait les gains qu'il produisait.
Comment un modèle rédige ses propres brouillons
La génération de texte est séquentielle. Le modèle produit un token, le réinjecte, produit le suivant. Chaque étape exige de relire en mémoire l'intégralité des poids du modèle : une session mono-utilisateur est donc limitée non par le calcul, mais par la bande passante mémoire. Le matériel reste, pour l'essentiel, inactif, en attente.
Le décodage spéculatif exploite cette inactivité. Un modèle « brouillon » peu coûteux devine les prochains tokens ; le vrai modèle les vérifie ensuite tous en une seule passe avant, pour un coût à peine supérieur à celui de la vérification d'un seul token. Les suppositions qui correspondent à ce que le grand modèle aurait produit sont conservées. Les autres sont écartées et la génération reprend normalement. Point essentiel : la sortie est mathématiquement identique à celle obtenue sans brouillon. C'est une astuce de vitesse, pas une approximation.
Le prompt lookup decoding, introduit par Apoorv Saxena en 2023, supprime complètement le modèle brouillon. Au lieu d'un petit réseau de neurones qui devine, le moteur cherche dans le contexte existant les derniers tokens qu'il vient de générer et, s'il retrouve cette même séquence plus tôt dans le prompt, il propose ce qui la suivait. Demandez à un modèle de corriger une ligne dans un fichier de 400 lignes : il reproduira les 399 autres mot pour mot ; la réponse figure déjà dans l'entrée. La technique d'origine annonçait des accélérations de 2 à 4 fois sur les tâches ancrées dans l'entrée, sans mémoire supplémentaire et sans second modèle à charger.
Le piège, c'est que la recherche de correspondances consomme du temps CPU, et que l'implémentation naïve re-balayait tout le contexte à chaque token. À 4 000 tokens, c'est négligeable. À 128 000 tokens, sur les mêmes cœurs que ceux qui font l'inférence, c'est une taxe assez lourde pour annuler le bénéfice. L'indexation du contexte corrige ce déséquilibre.
Qui voit ses prix discrètement réévalués
Les déploiements locaux et en périphérie en profitent le plus. Le prompt lookup n'a pas besoin de modèle brouillon, ce qui est exactement ce qu'il faut sur un appareil doté de 16 Go de mémoire unifiée et sans place pour un second jeu de poids. Les outils de codage agentiques qui réécrivent des fichiers, les outils de résumé sur l'appareil et tout ce qui fait du RAG sur un corpus fixe obtiennent un changement d'échelle sur les charges qu'ils exécutent réellement.
Les éditeurs qui vendent des modèles brouillons sont plus exposés qu'ils ne le pensent. Un brouillon de 1 milliard de paramètres réglé pour une cible de 70 milliards est un vrai produit, adossé à un vrai travail d'ingénierie. Pour les charges riches en copie, il est désormais en concurrence avec une simple recherche de chaînes.
Les responsables de la planification de capacité ont un nouveau problème. Le nombre de tokens par seconde cesse d'être une propriété de votre matériel pour devenir une propriété de votre trafic. Un benchmark exécuté sur des prompts de conversation sous-estimera fortement le débit sur l'édition de documents, et des règles d'autoscaling calées sur des moyennes s'emballeront dès que le mélange changera.
Les équipes de sécurité ne l'ont pas encore remarqué. Le taux d'acceptation dépend du contenu de la requête. Autrement dit, le temps de réponse est désormais corrélé à la part de la sortie qui a été copiée depuis l'entrée : un canal auxiliaire qui s'ajoute aux fuites de timing des tokens déjà démontrées par des chercheurs contre les réponses en streaming. Si votre modèle de menace inclut un observateur sur le réseau, la génération à débit variable constitue un signal nouveau dont vous ne disposiez pas auparavant.
Les questions à vous poser
- Quand votre fournisseur d'inférence annonce un nombre de tokens par seconde, quelle charge de travail a produit ce chiffre, et accepte-t-il de vous garantir un plancher pour un prompt sans aucun passage réutilisable ?
- Votre SLO mesure-t-il uniquement le temps jusqu'au premier token et le débit moyen, ou prend-il en compte le p99 pour les requêtes les moins favorables à la copie que vous servez réellement ?
- Si vous avez acheté ou entraîné un modèle brouillon, quelle fraction de votre trafic est ancrée dans l'entrée, et quelqu'un a-t-il comparé le drafting par lookup à ce trafic sur vos prompts ?
- Un observateur externe peut-il chronométrer vos réponses en streaming, et quelqu'un a-t-il évalué ce que la variation du taux d'acceptation révèle sur le contenu des requêtes ?
- Qui, dans votre équipe, vérifie que la sortie spéculative est identique bit à bit à la sortie non spéculative après chaque mise à jour du moteur ?
Ce qu'il faut surveiller ensuite
Le signal à guetter, c'est de savoir si les fournisseurs d'API hébergées adoptent cette technique et le disent. Le prompt lookup brille avec une taille de lot de un et se dégrade à mesure que le batching sature le matériel : un grand fournisseur a donc moins d'incitations que vous. Si l'un d'eux se met à proposer une tarification dépendante du contenu, ou un point d'accès de « réécriture ancrée » facturé moins cher que la génération standard, ce sera le signe que l'économie a quitté le modèle au token que tout le monde budgétise aujourd'hui.
- 1Activez le prompt lookup decoding (options `--draft-*` / lookup) dans llama.cpp pour les tâches riches en copie comme les modifications de code, les réécritures et les réponses RAG, où les tokens proposés sont le plus souvent validés.
- 2Passez à une version de llama.cpp dotée du lookup de n-grammes indexé avant d'exécuter des contextes de plus de 50 000 tokens : l'ancien balayage brutal ralentissait à mesure que le tampon grossissait.
- 3Mesurez le nombre de tokens par seconde avec et sans drafting sur vos prompts réels : la génération libre, avec peu de recoupement avec l'entrée, gagne peu et peut même tourner plus lentement.
Ready to implement AI in your business?
Our team builds the AI systems you just read about. Start with a free 30-minute discovery meeting.
