Throughput en IA : Comprendre le Débit des API et Maximiser vos Tokens par Seconde
Qu’est-ce que le throughput exactement ?
Le throughput est une métrique de capacité, pas de vitesse individuelle. La distinction avec la latence est fondamentale : la latence mesure le temps qu’une requête individuelle met à être traitée, le throughput mesure combien de requêtes le système peut traiter en parallèle.
Pour reprendre l’analogie routière : la latence est la vitesse d’une voiture sur l’autoroute, le throughput est le débit de véhicules par heure. Une autoroute à 6 voies a un throughput supérieur à une route à 2 voies, même si chaque voiture roule à la même vitesse.
En production, le throughput détermine la scalabilité de votre application. Un chatbot servant 1000 utilisateurs simultanés a besoin d’un throughput bien supérieur à un outil d’analyse interne utilisé par 5 personnes, même si les deux utilisent le même modèle avec la même latence.
Les différentes mesures du throughput
Tokens par seconde (tok/s)
La mesure la plus granulaire. Elle peut être exprimée pour un utilisateur individuel (combien de tokens le modèle génère par seconde pour ma requête) ou pour le système entier (combien de tokens le cluster génère par seconde toutes requêtes confondues). Les deux valeurs sont très différentes : un utilisateur individuel voit 50-100 tok/s, mais le cluster de GPUs du fournisseur traite des millions de tokens par seconde au total.
Requêtes par minute (RPM)
C’est la mesure utilisée par les rate limits. Elle indique combien d’appels API vous pouvez effectuer par minute. Attention : le RPM ne tient pas compte de la taille des requêtes. 500 RPM de requêtes courtes (100 tokens) et 500 RPM de requêtes longues (100K tokens) consomment des ressources radicalement différentes, c’est pourquoi les fournisseurs combinent RPM et TPM (Tokens Per Minute).
Tokens par minute (TPM)
Le volume total de tokens (input + output) que vous pouvez consommer par minute. C’est souvent le goulot d’étranglement réel. Si votre rate limit est de 200K TPM et que chaque requête consomme 4000 tokens en moyenne, vous êtes plafonné à ~50 requêtes effectives par minute, indépendamment de votre RPM.
Throughput des principaux modèles (mars 2026)
Le throughput par utilisateur (vitesse de génération) varie selon les modèles. Ces valeurs sont des ordres de grandeur mesurés dans des conditions normales :
| Modèle | Vitesse de génération | Caractéristique |
|---|---|---|
| Claude Haiku 4.5 | ~100-150 tok/s | Le plus rapide de sa catégorie de qualité |
| Gemini 3 Flash | ~80-120 tok/s | Optimisé pour le débit |
| Gemini 3.1 Flash-Lite | ~120-180 tok/s | Ultra-rapide, lancé le 3 mars 2026 |
| Mistral Large 3 | ~60-90 tok/s | MoE : rapide malgré 675B params |
| Claude Sonnet 4.6 | ~60-100 tok/s | Bon compromis qualité/vitesse |
| GPT-5.4 | ~50-80 tok/s | Variable selon la charge |
| Claude Opus 4.6 | ~40-60 tok/s | Fast Mode : ~100-150 tok/s (6x le prix) |
| Gemini 3.1 Pro | ~50-80 tok/s | Variable selon le mode |
| Grok 4.1 Fast | ~80-120 tok/s | Version optimisée pour la vitesse |
Note sur l’architecture MoE : les modèles Mixture of Experts (Mistral Large 3, DeepSeek V3.2) offrent un throughput supérieur à leur taille le laisserait penser, car seule une fraction des paramètres est activée par requête (~40B actifs sur 675B pour Mistral Large 3). C’est un avantage architectural significatif pour le débit.
Facteurs qui influencent le throughput
Taille du modèle
Plus un modèle de langage est grand (en nombre de paramètres actifs), plus chaque token nécessite de calcul, et plus le throughput par utilisateur diminue. C’est pourquoi Claude Haiku 4.5 (petit et rapide) a un throughput 2-3x supérieur à Claude Opus 4.6 (grand et puissant). Les architectures MoE atténuent ce compromis en activant seulement un sous-ensemble de paramètres.
Infrastructure GPU
Le throughput du système dépend directement du nombre et du type de GPUs déployés par le fournisseur. Les GPU de dernière génération (Nvidia H100, H200, B200) offrent un throughput de tokens significativement supérieur aux générations précédentes, grâce à plus de mémoire (permettant de servir plus d’utilisateurs en parallèle) et une puissance de calcul accrue.
Le batching d’inférence
Les fournisseurs d’API ne traitent pas les requêtes une par une. Ils regroupent plusieurs requêtes (« batch ») sur le même GPU pour maximiser l’utilisation des ressources. Des techniques comme le « continuous batching » et le « PagedAttention » (vLLM) permettent de servir des dizaines de requêtes simultanément sur un même GPU, augmentant le throughput système sans dégrader la latence individuelle.
La quantification
Réduire la précision des poids du modèle (de 16 bits à 8 bits ou 4 bits) diminue la mémoire nécessaire et accélère le calcul. En local, la quantification permet d’exécuter des modèles plus gros sur des GPUs plus petits. Les fournisseurs d’API utilisent aussi des techniques de quantification optimisées (FP8, comme chez DeepSeek) pour maximiser le throughput sans perte de qualité perceptible.
Comment maximiser le throughput de votre application
Parallélisez vos requêtes
Si vous avez 100 documents à résumer, envoyez 10-20 requêtes en parallèle au lieu de les traiter séquentiellement. Respectez vos rate limits (RPM et TPM), mais exploitez-les au maximum. En Python, utilisez asyncio ou concurrent.futures pour gérer les appels parallèles.
Utilisez la Batch API
Pour les traitements en masse non urgents, la Batch API d’OpenAI et d’Anthropic offre un throughput bien supérieur aux appels temps réel. Vous soumettez un fichier de requêtes, et les résultats arrivent sous 24 heures. Le coût est réduit d’environ 50%, et les rate limits sont nettement plus élevés que ceux de l’API synchrone.
Choisissez le bon modèle
Si votre priorité est le throughput (traitement en masse, chatbot à fort trafic), privilégiez les modèles rapides : Claude Haiku 4.5, Gemini 3 Flash, Gemini 3.1 Flash-Lite, ou Grok 4.1 Fast. Réservez les modèles lourds (Opus, GPT-5.4) aux tâches qui nécessitent la qualité maximale.
Activez le prompt caching
Le prompt caching réduit le temps de prefill des requêtes partageant un préfixe commun, ce qui libère des ressources GPU et augmente le throughput effectif du système. Chez Anthropic, le cache read coûte ~0,1x le prix de base. Si 80% de vos requêtes partagent le même system prompt de 5000 tokens, le caching économise des millions de tokens de prefill par jour.
Throughput en exécution locale
Si vous exécutez un modèle en local via Ollama ou un autre runtime, le throughput dépend entièrement de votre matériel :
| GPU | VRAM | Throughput typique (7B, Q4) |
|---|---|---|
| Nvidia RTX 4090 | 24 Go | ~80-120 tok/s |
| Nvidia RTX 4080 | 16 Go | ~50-80 tok/s |
| Apple M3 Max | 48 Go unifiée | ~30-60 tok/s |
| Apple M2 Pro | 16-32 Go | ~15-30 tok/s |
Pour les gros modèles (70B+), le throughput chute rapidement si la VRAM est insuffisante et que le modèle doit être « offloadé » partiellement sur le CPU. Mistral Large 3 en quantification Q4 nécessite environ 48 Go de VRAM pour un throughput acceptable.
Throughput et coût : le vrai calcul
Le throughput a un impact direct sur vos coûts d’infrastructure. Un modèle avec un throughput 2x supérieur peut traiter le même volume de travail avec 2x moins de GPU (en self-hosting) ou en restant dans un tier de rate limit inférieur (en API). Comparer les modèles uniquement sur le prix par token est trompeur : intégrez toujours le throughput dans votre calcul de coût total.
Exemple concret : pour traiter 1 million de requêtes par jour (chacune ~500 tokens output), vous avez besoin d’un throughput système d’environ 350K tokens par minute. Avec Claude Haiku 4.5 à ~100 tok/s, quelques instances suffisent. Avec Claude Opus 4.6 à ~40 tok/s, il faut 2,5x plus de capacité (et un modèle 5x plus cher par token). Le surcoût total peut être de 10-15x pour Opus vs Haiku sur ce type de workload.
Questions fréquentes sur le throughput en IA
Quelle est la différence entre throughput et latence ?
La latence mesure le temps d’une requête individuelle (combien de secondes pour obtenir la réponse). Le throughput mesure le débit du système (combien de requêtes ou tokens par seconde). Un système peut avoir une latence élevée mais un throughput élevé s’il traite beaucoup de requêtes en parallèle. Les deux métriques sont complémentaires et doivent être optimisées ensemble.
Comment mesurer le throughput d’une API IA ?
Envoyez des requêtes parallèles croissantes et mesurez le nombre de tokens générés par seconde au total. Augmentez progressivement le parallélisme jusqu’à atteindre vos rate limits ou observer une dégradation de la latence. Des outils comme locust, k6, ou wrk permettent d’automatiser les tests de charge. Mesurez sur plusieurs heures pour capturer les variations liées à la charge du fournisseur.
Pourquoi le throughput de DeepSeek varie-t-il autant ?
DeepSeek propose des tarifs très bas (~$0,28/1M tokens input) qui attirent un volume massif d’utilisateurs. Leur infrastructure, bien que performante, est moins élastique que celle d’OpenAI ou Google. Le throughput peut chuter significativement aux heures de pointe (surtout entre 9h et 18h heure de Pékin). La solution : utilisez l’API pendant les heures creuses ou passez par un fournisseur d’hébergement tiers (Together AI, Fireworks) qui déploie DeepSeek V3.2 sur sa propre infrastructure.
La Batch API offre-t-elle un meilleur throughput ?
Oui. La Batch API (disponible chez OpenAI et Anthropic) permet d’envoyer des milliers de requêtes en une seule soumission, avec des rate limits bien supérieurs à l’API synchrone. Le compromis : les résultats arrivent sous 24 heures au lieu du temps réel. Pour les traitements en masse (classification de données, résumés de documents, génération de contenu), c’est le meilleur moyen de maximiser le throughput tout en réduisant le coût de ~50%.
Quel modèle offre le meilleur ratio throughput/qualité ?
Claude Sonnet 4.6 est souvent considéré comme le meilleur compromis entre throughput (~60-100 tok/s), qualité de réponse, et coût ($3/$15 par 1M tokens sans surcoût long contexte). Pour les workloads axés uniquement sur le débit, Claude Haiku 4.5 et Gemini 3.1 Flash-Lite dominent. Pour le throughput maximum en local, les modèles quantifiés 7-14B (Mistral Small, Llama) tournent à plus de 100 tok/s sur un GPU grand public.