Planificateur de Budget de Tokens

À propos du Planificateur de Budget de Tokens

Les longs prompts sont silencieusement tronqués, les pipelines de génération augmentée par récupération échouent en cours de route, et la facture du modèle explose — presque toujours parce que le budget n'a jamais été planifié. Ce planificateur vous donne une estimation sans clé API, entièrement dans le navigateur, du nombre de tokens que votre texte consommera sur Claude Opus/Sonnet, Claude 1M, GPT-4o, GPT-5/o3, Gemini 2.x, Llama 3.1, Mistral Large ou toute limite personnalisée, puis découpe le texte en blocs sûrs avec une fenêtre de chevauchement configurable.

Réservez des tokens pour la réponse, le system prompt et les schémas d'outils, puis choisissez la découpe par paragraphe, phrase ou caractères. Chaque bloc se copie individuellement pour des pipelines de récupération, du résumé par lot ou des conversations séquentielles.

Quelle est la précision de l'estimation par rapport au vrai tokenizer d'Anthropic, OpenAI ou Google ?

Notre estimation est une heuristique de planification, généralement à 5-15 % près du vrai compte pour la prose anglaise, 10-20 % pour le code source et 15-25 % pour les langues CJK. Nous évitons délibérément de charger des bibliothèques de tokenisation (tiktoken, anthropic-tokenizer, gemini tokenizer) car elles ajoutent 2-15 Mo de WASM et certaines requièrent des appels serveur. L'estimateur applique la règle bien documentée 1 token ≈ 4 caractères anglais ≈ 0,75 mot, affinée par type : les caractères CJK font généralement 1 token chacun (~1,5 chars/token), le code a plus de ponctuation (~3,5 chars/token), et le markdown/mixte combine les deux. Pour la facturation exacte utilisez le tokenizer du fournisseur ; pour vérifier si un document de 240k tokens tient dans une fenêtre de 200k, cet outil donne la bonne réponse.

Pourquoi découper avec chevauchement plutôt qu'aux frontières de paragraphes ?

Sans chevauchement, une question ou un fait mentionné à la fin du bloc 1 n'a pas de réponse visible dans le bloc 2 même si la réponse est dans le corps du bloc 2, car le modèle dans le bloc 2 n'a pas le contexte de la question. Un chevauchement de 5-15 % (par défaut 10 %) répète la fin du bloc N comme tête du N+1, préservant les coréférences, les arguments en cours, les éléments de liste et en-têtes de tableau. Pour du RAG pur, 10 % suffit ; pour du résumé juridique ou scientifique multi-paragraphes, montez à 20-25 % ; pour du chat court ou de l'extraction de FAQ indépendantes, descendez à 0 %.

Que mettre dans 'réservé pour la sortie' et pourquoi est-ce important ?

Toute API LLM moderne consomme entrée + sortie dans la même fenêtre de contexte. Si votre modèle a 200 000 tokens et que vous en mettez 199 000 dans le prompt, le modèle ne peut générer que 1 000 avant troncature — souvent au milieu d'une phrase. Réservez au moins max_tokens (la valeur passée à l'appel API) plus une marge. Valeurs pratiques : 4 096 pour chat normal, 8 192 pour résumé long, 16 384-32 768 pour génération de code, 64 000+ pour modèles de raisonnement comme o3/o1 qui consomment beaucoup de tokens de réflexion cachés. L'extended thinking de Claude et le thinking mode de Gemini gaspillent aussi du budget invisiblement — augmentez la réserve de 30-50 % si vous les activez.

Les system prompts, schémas de fonctions et fichiers uploadés comptent-ils dans la limite de contexte ?

Oui — chaque entrée que reçoit l'API compte dans la même fenêtre totale. Un stack d'agent typique brûle 2 000-8 000 tokens avant la requête utilisateur : system prompt 500-2 000, schémas d'outils/fonctions (chaque schéma JSON fait 50-300 tokens, les agents exposent 5-20 outils = 1 000-6 000 tokens), plus les PDF/images convertis en texte. Renseignez honnêtement 'system prompt tokens' et 'tokens outils' — si le planificateur affiche 195k disponibles sur 200k, c'est le vrai budget après surcharge de l'agent.

Quand choisir Claude 1M, Gemini 2.x 1M ou découper sur un modèle plus petit ?

Les modèles 1M semblent magiques mais ont trois coûts réels : (1) latence — premier token de 30-90 secondes à 800k+ d'entrée ; (2) prix — les tokens d'entrée sont facturés même quand le modèle n'en regarde qu'une fraction ; (3) dégradation du rappel — la plupart des modèles 1M perdent en précision après ~400k tokens, surtout pour récupérer du milieu de document ('lost in the middle'). Règle : document complet sous 150k tokens — utilisez un modèle standard 200k. 150k-500k avec raisonnement long — utilisez 1M natif. 500k+ ou charges récurrentes en prod — découpez et utilisez un modèle plus petit avec récupération.

Comment utiliser les blocs pour RAG ou résumé par lot ?

Trois patterns courants. (1) Map-reduce : envoyez chaque bloc séparément avec le même prompt ('résume cette section'), collectez les sorties, faites un second passage de fusion. (2) Récupération augmentée : embeddez chaque bloc avec un modèle d'embeddings (text-embedding-3-small, voyage-3, gemini-embedding), stockez dans une base vectorielle (Qdrant, pgvector, Pinecone), récupérez top-K à la requête. Pour les embeddings, gardez des blocs de 200-800 tokens — bien plus petits ; ajustez 'fenêtre de contexte' à la limite du modèle d'embeddings (8192 OpenAI, 32k Voyage). (3) Conversation séquentielle : nourrissez les blocs un par un en dialogue multi-tours, en demandant au modèle de mémoriser les faits clés.

Pourquoi les estimations CJK et code diffèrent-elles de l'anglais ?

Les tokenizers BPE et SentencePiece découpent les sous-chaînes fréquentes en tokens uniques. En anglais, 'the', 'and', 'tion' font un token, mais les mots rares se découpent en 2-4 tokens, soit ~4 caractères/token. Les textes chinois, japonais et coréens sont majoritairement des caractères individuels — les tokenizers d'Anthropic, OpenAI et Google mappent la plupart des caractères CJK à 1 token, donnant ~1,5 chars/token. Le code source est rempli de ponctuation à un caractère ({}, [], (), ;, :, .) et d'identifiants courts qui consomment chacun un token, plus l'indentation — ~3,5 chars/token. Utilisez 'mixte' pour le markdown, les fichiers JSON ou l'écriture technique mêlant prose et code.

L'outil fonctionne-t-il hors-ligne et mon prompt est-il envoyé quelque part ?

Entièrement hors-ligne après chargement de la page. Toute l'estimation, la découpe et le calcul de chevauchement tournent dans votre navigateur en JavaScript pur — pas d'appel API, pas de télémétrie, pas d'upload. Vous pouvez couper le réseau, l'outil continue. Nous avons choisi l'estimation heuristique précisément pour ne jamais envoyer votre prompt à un tokenizer distant. Pour du contenu sensible (contrats juridiques, dossiers médicaux, code source, documents internes), cet outil est sûr. La seule donnée qui sort du navigateur est l'analytique de visite standard si vous ne l'avez pas désactivée dans les paramètres de confidentialité.