# Gateway LLM vs optimiseur de tokens : qui réduit quoi

> Une gateway LLM comme LiteLLM ou Portkey contrôle où partent les requêtes et qui les paie. Un optimiseur de tokens réduit ce que l'agent met dans chaque requête. Deux couches, deux économies.

Source: https://tokenade.net/fr/articles/llm-gateway-vs-token-optimizer · Updated: 2026-10-16

Fait partie du pilier [réduire l'usage des tokens d'un agent IA de code](https://tokenade.net/fr/articles/reduce-ai-coding-agent-token-usage). Cette page compare deux catégories, pas deux produits, parce qu'on achète souvent l'une en espérant obtenir l'autre.

## Gateway LLM vs optimiseur de tokens en une phrase

**Une gateway décide où part une requête et qui la paie ; un optimiseur de tokens décide de sa taille.** LiteLLM et Portkey se placent entre vos applications et les fournisseurs de modèles, à la couche API. Tokenade se place entre votre agent IA et ses outils, sur l'ordinateur où vous travaillez.

Ils ne réduisent donc pas la même chose. Une gateway plafonne, route et attribue la dépense. Un optimiseur baisse le nombre de tokens de chaque tour. Si votre problème est « la facture est trop grosse parce que chaque tour est énorme », seul le second y touche.

Les fonctionnalités des gateways ci-dessous ont été lues dans la documentation officielle de LiteLLM et de Portkey, et dans la documentation gateway de Claude Code chez Anthropic, le 2026-10-15. Le seul chiffre Tokenade de cette page vient du [benchmark THOL](https://tokenade.net/fr/thol) publié, que je maintiens ; [la méthodologie est ici](https://tokenade.net/fr/thol).

## La version courte

| Catégorie | Exemples | Où elle se place | Ce qu'elle réduit | Idéal pour |
|---|---|---|---|---|
| Gateway LLM | LiteLLM, Portkey | Entre le client et l'API du fournisseur | Dépassements, pannes de fournisseur, appels identiques répétés | Équipes, applications, gouvernance |
| Optimiseur de tokens | Tokenade | Entre l'agent et ses outils, en local | Tokens par tour : sorties de commandes, lectures de fichiers, manifestes MCP | Quiconque paie ses agents de code au token |

## Que fait vraiment une gateway LLM ?

**Elle offre une seule API devant de nombreux fournisseurs, plus le contrôle de qui dépense quoi.** LiteLLM se décrit comme une gateway open source qui place plus de 100 LLM derrière une interface compatible OpenAI ([docs LiteLLM](https://docs.litellm.ai/docs/), lu le 2026-10-15). La gateway de Portkey documente une API universelle, des fallbacks, du routage conditionnel, du load balancing et des guardrails ([docs Portkey](https://portkey.ai/docs/product/ai-gateway), lu le 2026-10-15).

L'éventail de fonctionnalités est à peu près le même dans toute la catégorie :

- **Routage et fallbacks.** Basculer le trafic vers un autre fournisseur ou modèle quand l'un tombe ou limite le débit.
- **Budgets et clés.** Les virtual keys de LiteLLM gèrent accès, budgets et limites de débit par équipe ou par utilisateur, avec la dépense suivie par clé, équipe et utilisateur.
- **Cache de réponses.** Renvoyer une réponse stockée au lieu de rappeler le modèle.
- **Logs et observabilité.** Chaque requête enregistrée au même endroit.

La documentation Claude Code d'Anthropic liste la même valeur : identifiants gardés côté serveur, usage attribué par développeur, budgets et limites appliqués en un point, journal d'audit, et changement de fournisseur sans toucher aux postes des développeurs ([docs gateway Claude Code](https://code.claude.com/docs/en/llm-gateway), lu le 2026-10-15).

La documentation de Portkey affiche désormais « Portkey is now Prisma AIRS AI Gateway » : attendez-vous à ce nom dans les discussions d'achat.

## Que fait vraiment un optimiseur de tokens ?

**Il réduit ce que l'agent envoie, avant que la requête soit construite.** Un agent de code dépense l'essentiel de ses tokens à lire : sorties de tests, `git log`, fichiers entiers ouverts pour changer quatre lignes, manifestes d'outils MCP chargés à chaque tour. Un optimiseur intercepte tout cela à la frontière des outils et donne à l'agent une version plus courte.

Tokenade le fait via les hooks natifs des agents que vous utilisez déjà. Il [filtre les sorties de commandes](https://tokenade.net/fr/articles/output-filtering-command-logs), remplace les lectures de fichiers entiers par des lectures structure d'abord et de la semantic search, et diffère les manifestes MCP jusqu'à ce qu'un outil serve vraiment. La compaction tourne sur votre machine, pas sur un serveur intermédiaire.

Sur la campagne THOL publiée, Tokenade réduit de 39 % le coût des longues sessions, par rapport à l'absence d'outil. C'est un chiffre sur la session entière, mesuré sur la facture, pas un ratio de compression par commande.

## Où chacun se place-t-il dans le tuyau ?

**L'optimiseur agit avant que la requête existe ; la gateway agit après.** Suivez un tour d'agent :

1. L'agent lance `pytest` et reçoit 4 000 lignes.
2. **Optimiseur de tokens :** compacte cette sortie aux échecs et au résumé.
3. L'agent assemble la requête : prompt système, historique, résultats d'outils.
4. **Gateway LLM :** vérifie le budget de la clé, choisit un fournisseur, consulte son cache, journalise l'appel, le transmet.
5. Le fournisseur facture les tokens reçus.

La gateway voit la requête de l'étape 4 comme un produit fini. Les fonctions de routage, de budget et de cache documentées par LiteLLM et Portkey transmettent le prompt reçu ; aucune n'est décrite comme réécrivant les résultats d'outils qu'il contient. Si ces 4 000 lignes arrivent à l'étape 4, elles sont facturées, quel que soit le fournisseur choisi.

## Que réduit réellement chacun ?

**Une gateway réduit les dépassements et le gaspillage entre les appels ; un optimiseur réduit la taille de chaque appel.** Côte à côte :

| Poste de coût | Gateway LLM | Optimiseur de tokens |
|---|---|---|
| Sorties de commandes bruyantes dans le contexte | Non | Oui |
| Lectures de fichiers entiers | Non | Oui |
| Manifestes MCP renvoyés à chaque tour | Non | Oui |
| Requêtes identiques répétées | Oui, cache de réponses | Non |
| Dépense qui s'emballe sur une clé ou une équipe | Oui, budgets et limites | Non |
| Modèle cher utilisé pour du travail simple | Oui, si vous écrivez les règles de routage | Non |
| Panne d'un fournisseur | Oui, fallbacks | Non |
| Savoir qui a dépensé quoi | Oui, suivi par clé | Dashboard local des économies seulement |

Les lignes se recoupent à peine. C'est tout l'argument de cette page.

## Pourquoi le cache d'une gateway économise-t-il peu sur du trafic d'agent ?

**Parce que les requêtes d'un agent ne sont presque jamais identiques.** Le cache simple de Portkey ne fait mouche que si le corps de requête entier correspond : messages, modèle, température, chaque paramètre. Sa documentation précise qu'un seul caractère modifié suffit à rater ([docs cache Portkey](https://portkey.ai/docs/product/ai-gateway/cache-simple-and-semantic), lu le 2026-10-15). Le cache de LiteLLM renvoie de même une réponse stockée « quand vous faites deux fois la même requête » ([cache LiteLLM](https://docs.litellm.ai/docs/proxy/caching), lu le 2026-10-15).

Un agent de code ajoute à son historique à chaque tour, donc le tour 12 n'est jamais identique octet pour octet au tour 11. Le cache de réponses à correspondance exacte brille sur des prompts répétés de type FAQ dans un produit, pas sur une transcription d'agent qui grossit. C'est mon raisonnement à partir de la définition des clés de cache, pas une mesure.

Le cache sémantique (mode similarité cosinus de Portkey, backends sémantiques Redis, Valkey ou Qdrant de LiteLLM) assouplit la correspondance. Sur du code, « sens proche » est risqué : deux prompts peuvent être voisins dans l'espace d'embedding et appeler des réponses différentes. Je ne le placerais pas devant un agent qui modifie des fichiers.

Ne confondez ni l'un ni l'autre avec le [prompt caching](https://tokenade.net/fr/articles/prompt-caching-cut-input-cost) côté fournisseur, qui remise un préfixe répété au lieu de sauter l'appel. LiteLLM le documente à part. Une gateway doit transmettre correctement les en-têtes de cache pour qu'il continue de fonctionner.

## Quand une gateway LLM est-elle le bon choix ?

**Quand le problème est le contrôle, pas le volume.**

- Plusieurs développeurs ou services partagent des clés fournisseur, et il vous faut des budgets par personne et un départ géré en révoquant un seul identifiant.
- Vous appelez plusieurs fournisseurs et voulez une seule API avec fallbacks automatiques.
- La conformité exige que chaque requête au modèle soit journalisée au même endroit.
- Votre application envoie des prompts réellement répétés, là où un cache de réponses paie.
- Il vous faut un plafond dur pour qu'[un agent de nuit ne fasse pas exploser la facture](https://tokenade.net/fr/articles/overnight-agent-budget-safety).

Un compromis à connaître avant de faire passer Claude Code par une gateway : la documentation d'Anthropic indique qu'un identifiant de gateway remplace la connexion à l'abonnement claude.ai pour ces requêtes, donc l'usage est facturé au token au propriétaire de la clé transmise. Elle prévient aussi qu'une gateway qui ne transmet pas les nouvelles capacités de Claude Code casse les fonctionnalités correspondantes, et doit donc suivre ses mises à jour.

## Quand un optimiseur de tokens est-il le bon choix ?

**Quand le problème est que chaque tour est trop gros.**

- Vous payez au token, ou vous atteignez sans cesse les limites de votre forfait sur les longues sessions.
- Vos sessions sont des boucles build, tests et refactoring avec beaucoup de sorties d'outils.
- Vous utilisez des serveurs MCP dont les manifestes voyagent à chaque tour.
- Vous êtes seul, et faire tourner et maintenir un serveur proxy est plus d'infrastructure que le problème n'en mérite.
- Vous voulez que la compaction se fasse sur votre machine, avant que quoi que ce soit n'en sorte.

## Faut-il utiliser les deux ?

**Oui, si vous avez besoin à la fois de contrôle et de requêtes plus petites ; ils ne se gênent pas.** L'optimiseur agit dans les appels d'outils de l'agent, la gateway sur l'appel API sortant. L'agent envoie une requête plus petite, et la gateway la route, la budgète, la cache et la journalise comme d'habitude.

La combinaison rend aussi les chiffres de la gateway plus utiles. Le suivi de dépense par clé montrera la baisse après installation de l'optimiseur : une lecture indépendante de l'économie, plus fiable que n'importe quel dashboard d'éditeur, le mien compris. [Mesurer la consommation de tokens d'un agent](https://tokenade.net/fr/articles/measure-agent-token-usage) explique comment la lire.

> Réduisez ce que votre agent envoie avant même la gateway : Tokenade compacte sorties de commandes, lectures de fichiers et manifestes MCP sur votre machine.
>
> Installation: `npm install -g @tokenade/cli && tokenade install && tokenade login` — ou laissez votre agent le faire: https://tokenade.net/install.md

## Ce qui ne change pas assez pour compter

- **« Les deux font économiser. »** Vrai, et inutile pour décider. Demandez-vous quel poste de coût vous attaquez.
- **Les dashboards.** Les deux catégories en ont un. Celui d'une gateway compte ce qui a été dépensé ; celui de Tokenade compte ce qui a été évité. Pour la comptabilité, c'est le premier qu'il vous faut.
- **L'open source.** LiteLLM et la gateway de Portkey sont open source ; Tokenade est propriétaire, avec 7 jours d'essai gratuit. Cela compte pour votre politique d'auto-hébergement, pas pour savoir de quelle couche vous avez besoin.
- **Le choix du modèle.** Une gateway peut router vers des modèles moins chers ; vous pouvez aussi choisir un modèle moins cher dans votre agent. Des règles de routage ne valent que ce que vaut la personne qui les écrit.

## Lequel choisir ?

- **Développeur solo sur Claude Code, Codex ou Cursor :** optimiseur de tokens. Une gateway ajoute de l'infrastructure sans réduire les tours.
- **Équipe qui partage des clés fournisseur :** la gateway d'abord pour les budgets et l'attribution, l'optimiseur sur chaque poste pour le volume.
- **Produit qui appelle des LLM depuis un backend :** gateway. Vos prompts, vous les réduisez dans votre code.
- **Agents qui tournent seuls la nuit :** les deux. Le budget de la gateway comme plafond, l'optimiseur pour l'atteindre plus tard.
- **Vous ne savez pas où partent vos tokens :** mesurez une semaine, puis décidez. [Le prix de Claude Code](https://tokenade.net/fr/articles/claude-code-pricing) explique de quoi la facture est faite.

## FAQ

### LiteLLM est-il un optimiseur de tokens ?

Non. LiteLLM est une gateway : une API pour plus de 100 LLM, avec routage, fallbacks, budgets, suivi de dépense et cache de réponses. Ses fonctionnalités documentées transmettent le prompt reçu. Elle peut baisser la dépense via le cache et le routage, mais elle ne réduit pas les sorties de commandes ni les contenus de fichiers que votre agent a mis dans la requête.

### Un cache sémantique peut-il remplacer un optimiseur de tokens ?

Pas pour des agents de code. Un cache sémantique saute un appel quand un nouveau prompt est assez proche d'un précédent. Les tours d'un agent grossissent sans cesse et demandent souvent des réponses différentes malgré une formulation proche : les hits sont rares, et un mauvais hit coûte cher. Un optimiseur, lui, rend chaque appel plus petit, en cache ou non.

### Une gateway casse-t-elle des fonctionnalités de Claude Code ?

C'est possible. La documentation d'Anthropic prévient qu'une gateway qui ne transmet pas les nouvelles capacités de Claude Code casse les fonctionnalités correspondantes, et qu'un identifiant de gateway remplace la facturation de l'abonnement par une facturation au token. Un optimiseur de tokens passe par les hooks de l'agent lui-même, il n'est donc pas du tout sur le chemin de l'API.

### Où passent mes prompts et mes clés d'API ?

Avec une gateway hébergée, chaque requête — prompts, contexte de code et clé du fournisseur ou identifiant de la gateway — transite par les serveurs de la gateway avant d'atteindre le modèle ; l'auto-hébergement déplace ce passage sur une infrastructure que vous gérez. Tokenade n'ajoute aucun intermédiaire réseau : il compacte sur l'ordinateur où vous travaillez, avant que la requête ne parte, et votre clé reste dans votre agent comme avant.

### Ai-je besoin d'une gateway si j'utilise déjà Tokenade ?

Seulement si vous avez besoin de ce qu'une gateway apporte : clés partagées, budgets par équipe, fallbacks entre fournisseurs ou journal d'audit central. Tokenade réduit les tokens de chaque tour ; il n'applique pas de budgets à l'échelle d'une équipe. Beaucoup d'équipes voudront les deux, et ils s'empilent proprement.

---

**À voir aussi :**

- [Réduire l'usage des tokens d'un agent IA de code](https://tokenade.net/fr/articles/reduce-ai-coding-agent-token-usage) — le pilier, indépendant de l'outil
- [Meilleurs optimiseurs de tokens pour Claude Code](https://tokenade.net/fr/articles/best-claude-code-token-optimizers) — le terrain des optimiseurs, classé
- [Prompt caching : réduire le coût en entrée](https://tokenade.net/fr/articles/prompt-caching-cut-input-cost) — le cache côté fournisseur qu'une gateway ne doit pas casser
- [Filtrer les sorties de commandes](https://tokenade.net/fr/articles/output-filtering-command-logs) — le plus gros poste qu'une gateway ne peut pas toucher
- [Mesurer la consommation de tokens d'un agent](https://tokenade.net/fr/articles/measure-agent-token-usage) — comment vérifier l'un ou l'autre sur votre facture
- [Agents de nuit et sécurité budgétaire](https://tokenade.net/fr/articles/overnight-agent-budget-safety) — là où le plafond dur d'une gateway se justifie