Inférence au-delà du texte : Ajustement des VLM, des embeddings, de la parole, de l’image et de la vidéo
Chaque modalité présente ses propres goulots d’étranglement. Découvrez comment ajuster les VLM, les embedders, l’ASR, le TTS, ainsi que les générateurs d’images et de vidéos en utilisant la bonne gestion par lots, des noyaux adaptés, du cache et de la quantification.
Accélérer un modèle de langage basé uniquement sur du texte est un problème suffisamment résolu pour que les gens considèrent ses astuces comme universelles. Ce n’est pas le cas. Une fois qu’un produit réel est mis sur le marché, la génération de texte devient une étape parmi plusieurs autres, et chaque étape présente son propre goulot d’étranglement. Une méthode de mise en tune qui double la vitesse de traitement des LLM peut s’avérer inutile pour un modèle d’embedding, tandis que la génération d’images ou de vidéos soulève ses propres problèmes de calcul et d’attention. Vous rencontrerez ici des modèles vision-langage, des générateurs d’embeddings, des systèmes ASR et TTS, ainsi que des générateurs d’images et de vidéos, en partant de deux schémas d’exécution de base avant d’examiner les métriques, les choix matériels, le cache, la quantification, le lotage et les compromis de qualité pour chacun d’eux. Le fil conducteur : l’ingénierie des inférences dépend de la charge de travail.
Pourquoi une approche unique échoue
Les applications réelles enchaînent des modèles entre eux. Un assistant vocal peut prendre de l’audio, effectuer une reconnaissance vocale, raisonner sur le texte obtenu, puis synthétiser de la parole. Un système de documents peut faire passer un PDF par du OCR, un modèle de vision et des embeddings avant la récupération des données, puis par un LLM. Un outil vidéo peut passer d’un texte à une séquence générée grâce à un débruitage itératif, pour finalement décoder le média.
Chaque étape présente son propre profil de coût, ce qui fait que l’élément à optimiser varie en fonction de cela. Ce qui rend un modèle linguistique autoregressif rapide ne peut pas être simplement appliqué à un processus lié à des images ou des vidéos.
Deux schémas couvrent la plupart des cas
Presque tous les systèmes génératifs suivent l’un de deux modèles.
Le premier est la génération autoregressive. Le modèle produit une sortie étape par étape, chaque token étant conditionné par ce qui a été généré précédemment :
Input
↓
Token 1
↓
Token 2
↓
Token 3
↓
...
C’est le cycle bien connu des LLM. Les modèles vision-langage, les systèmes d’embedding basés sur des architectures de modèles linguistiques, les décodeurs ASR ainsi que de nombreux modèles TTS peuvent s’inspirer à grande échelle des principes d’exécution des transformateurs.
Le deuxième est le débruitage itératif, l’approche par diffusion, où un point de départ bruité est affiné étape après étape :
Random / noisy latent
↓
Step 1
↓
Step 2
↓
Step 3
↓
...
↓
Final image/video
La génération d’images et de vidéos se situe principalement dans ce domaine.
Cela est important car on ne peut pas utiliser une seule définition de latence, de débit ou d’efficacité pour tous ces cas. Pour un chatbot, le temps nécessaire pour obtenir le premier token est souvent l’indicateur clé. Pour la synthèse vocale, ce qui compte, c’est le temps nécessaire pour obtenir le premier son significatif. Pour les tâches de transcription longues, le facteur temps réel a tendance à dominer. Pour la génération d’images, réduire les étapes de suppression du bruit peut être plus efficace que de diminuer la latence du noyau. Pour les vidéos, l’attention et des tenseurs énormes peuvent engloutir toute la charge de travail.
Les modèles vision-langage transforment les images en tokens
Image / Video
│
▼
Vision Encoder
│
▼
Visual Tokens
│
▼
Language Model
│
▼
Text Response
La conséquence intéressante est qu’une image allonge la séquence d’entrée. Une seule image en haute résolution peut contribuer à l’ordre de mille tokens visuels. Plus de détails visuels signifie plus de tokens, ce qui entraîne davantage de contexte et un cache KV plus volumineux.
Ainsi, ajuster un VLM ressemble beaucoup à l’ajustement d’un LLM à long contexte. On peut recourir à des caches KV quantisés, à une décodage spéculatif, au stockage en préfixe, au parallélisme des tenseurs, au transfert du cache vers un autre dispositif, ou encore à la séparation de l’opération de préremplissage de celle de décodage. La réutilisation des préfixes est particulièrement avantageuse pour les images répétées et les conversations à plusieurs tours, et à mesure que les entrées s’allongent, la gestion de la mémoire devient de plus en plus importante.
La compréhension des vidéos devient rapidement coûteuse
Les images coûtent de l’argent. La vidéo multiplie ce coût. À 24 images par seconde, même une courte séquence génère un nombre énorme de tokens visuels. Une séquence en haute définition d’une durée de quatre secondes pourrait, en principe, atteindre 100 000 tokens d’entrée avant toute compression pratique.
Cela fait de la compression un compromis entre qualité et vitesse. Vous pouvez réduire la résolution, le taux de rafraîchissement, le nombre d’images ou le nombre de tokens visuels, mais chaque réduction entraîne la perte d’informations. Évitez donc de vous demander comment accélérer l’inference vidéo. Demandez plutôt quelle est la plus petite représentation visuelle qui satisfait encore aux exigences de qualité de l’application. Telle est la véritable mentalité en ingénierie d’inference : ajuster la charge de travail, et non seulement le noyau.
Les modèles omnimodaux ne sont pas toujours la solution
L’industrie se dirige vers des modèles capables d’accepter et de générer plusieurs modalités en même temps :
Text ─────┐
Image ────┤
Audio ────┼──► Omni Model ──► Text / Audio / Image
Video ────┘
Cela semble idéal, mais la généralité a un prix. Un modèle OCR dédié peut surpasser les capacités d’OCR intégrées à un grand VLM, et un modèle de reconnaissance vocale conçu spécifiquement peut fonctionner plus efficacement qu’un modèle multimodal généraliste. Les systèmes de production ont donc tendance à se transformer en chaînes d’opérations gérées par des spécialistes :
┌──► OCR
PDF/Image ───┤
├──► Vision Model
└──► Embedding Model
│
▼
LLM
La règle d’ingénierie qui s’applique est de rendre chaque composant indépendamment optimisable et scalable.
Les modèles d’incorporation nécessitent un débit élevé
Les modèles d’incorporation diffèrent fondamentalement des LLM génératifs. Ils transforment le contenu en un vecteur de taille fixe :
Document / Image
↓
Embedding Model
↓
[0.12, -0.43, 0.87, ...]
Ces vecteurs alimentent le RAG, la recherche sémantique, les recommandations, la mémoire des agents et la récupération de documents. Ce qui importe le plus, c’est la nature du travail à effectuer, et deux types de travaux se distinguent fortement.
L’incorporation en masse en est un exemple, comme l’insertion de dix millions de documents dans une base de données vectorielle :
10 million documents
↓
Embedding pipeline
↓
Vector database
Là, le débit et le coût l’emportent. La recherche en ligne est l’autre approche, où une requête de l’utilisateur est intégrée et recherchée immédiatement :
User query
↓
Embedding
↓
Vector search
Là, les millisecondes font la différence. Lorsque les deux critères sont suffisamment importants, des déploiements séparés ont souvent l’avantage, car chacun peut être optimisé en fonction de son propre objectif.
Dimensionnalité et compatibilité
Les embeddings ajoutent un autre paramètre à prendre en compte entre qualité et vitesse : la taille du vecteur. Les vecteurs peuvent contenir des centaines ou des milliers de valeurs. Plus ils sont grands, plus ils stockent d’informations, mais cela augmente les coûts de stockage, de récupération et de calcul de similarité. Certaines méthodes d’embedding modernes prennent en charge une dimensionnalité effective variable, conçue précisément pour tenir compte de cet équilibre.
Il existe également une idée reçue courante. Deux vecteurs de même longueur ne sont pas automatiquement comparables, car chaque modèle d’embedding crée son propre espace sémantique. Changer de modèle n’est pas équivalent à remplacer une API par une autre. Il faut généralement repenser tout le système de récupération en fonction du nouveau modèle.
Le traitement par lots est le principal levier pour les embeddings
Contrairement à la décodage auto-régressif, les modèles d’incorporation traitent les tokens principalement en parallèle, ce qui change la stratégie. Le cache de préfixes ainsi que la désagrégation entre préremplissage et décodage ne jouent pas un rôle central ici. Il convient de se concentrer sur de grands lots, une tokenisation rapide, la mise en file d’attente, l’échelle horizontale, des noyaux optimisés et la quantification. Les modèles d’incorporation peuvent gérer des lots bien plus importants que ceux des modèles génératifs, parfois des dizaines ou des centaines d’entrées en même temps.
Une architecture de production judicieuse place une file d’attente et un gestionnaire de lots devant plusieurs réplicas :
Requests
↓
Queue
↓
Batch Manager
↓
GPU Replica 1
GPU Replica 2
GPU Replica 3
GPU Replica 4
Pour les embeddings à grande échelle, une GPU par réplique étendue horizontalement est souvent préférable à une configuration complexe de modélisation parallèle utilisant plusieurs GPU.
Reconnaissance vocale : le décodeur domine
La ASR convertit l’audio en texte. Un flux de travail typique comprend un prétraitement, un encodeur puis un décodeur :
Audio
↓
Audio preprocessing
↓
Encoder
↓
Autoregressive Decoder
↓
Transcript
ASR n’est pas un LLM, mais son décodeur agit comme tel et consomme la majeure partie du temps d’inférence. Cela rend les optimisations de type LLM particulièrement efficaces. Pour la transcription en temps réel, le débit brut n’est pas l’objectif principal ; le système doit donner l’impression d’être instantané, avec un objectif raisonnable d’environ 200 ms pour un bloc audio en direct.
La diffusion transforme l’expérience
L’un des plus grands gains apportés par ASR ne nécessite aucun changement de modèle, seulement une conception différente du service. Plutôt que le schéma de téléchargement, d’attente et de réception :
Upload audio
↓
Wait
↓
Receive transcript
Passer à un flux continu :
Continuous Audio
↓
VAD
↓
Audio Chunks
↓
ASR GPU
↓
Streaming Transcript
Un WebSocket maintient le flux ouvert tandis qu’un modèle de détection d’activité vocale identifie les segments contenant du son significatif. La leçon à retenir est que les performances de l’inférence ne sont pas toujours un problème lié au temps d’exécution. Parfois, l’orchestration apporte les meilleurs résultats.
Les enregistrements longs nécessitent le parallélisme
Les fichiers longs sont différents des dictées interactives. Au lieu de les traiter dans l’ordre :
Chunk 1 → Chunk 2 → Chunk 3 → Chunk 4
vous pouvez créer un pipeline parallèle :
┌──► GPU 1 ──► Chunk 1
Audio → VAD ─────┼──► GPU 2 ──► Chunk 2
├──► GPU 3 ──► Chunk 3
└──► GPU 4 ──► Chunk 4
↓
Stitch by time
Vous perdez une partie de la réutilisation du contexte séquentiel, mais vous gagnez en efficacité considérable. Le facteur temps réel est une métrique utile pour la transcription de longs textes, et le traitement parallèle en blocs convient aux tâches à fort débit. Pour protéger la qualité, ajoutez un traitement post-traitement qui détecte les répétitions suspectes et relance uniquement les blocs problématiques.
TTS : plus de tokens par seconde n’est pas l’objectif
La conversion texte en parole fonctionne dans la direction opposée à l’ASR :
Text
↓
TTS Model
↓
Audio Tokens
↓
Audio Decoder
↓
Waveform
Les modèles TTS modernes utilisent souvent des architectures similaires à celles des LLM, ce qui fait que les noyaux optimisés, le regroupement de données et l’inférence à faible précision proviennent du fonctionnement des LLM. Cependant, la métrique diffère de manière subtile : générer 500 tokens audio par seconde n’est pas mieux que 100 si le décodeur audio a besoin d’un résultat uniquement en temps réel. Une fois que la génération est à jour avec le rythme en temps réel, la question devient de savoir combien d’utilisateurs simultanés une GPU peut gérer. Il s’agit alors d’optimiser en fonction des exigences du produit, et non des chiffres de référence.
Génération d’images : abandonnez les habitudes liées aux LLM
Les générateurs d’images sont principalement des outils de suppression du bruit itératifs, et non des générateurs qui écrivent token par token :
Noise
↓
Denoising Step 1
↓
Denoising Step 2
↓
...
↓
Image
Contrairement à la décodage des LLM, cette tâche est généralement limitée par les capacités de calcul, ce qui fait que la bande passante mémoire n’est plus le principal obstacle. L’ensemble d’outils se concentre alors sur la sélection des noyaux, leur fusion, une attention efficace, l’optimisation des opérations GEMM, la compilation avec Torch, l’utilisation d’une précision inférieure et une réduction des opérations de débruitage.
Les noyaux sont très importants
Les noyaux d’attention revêtent une importance particulière dans la génération d’images. En fonction de l’architecture et de l’implémentation de la GPU, on peut évaluer des options optimisées telles que FlashAttention, DeepGEMM, CuTe et CUTLASS. Les opérations de normalisation comme RMSNorm constituent également de bons candidats pour la fusion.
La leçon la plus importante est que le meilleur moteur d’inférence dépend à la fois du travail à effectuer et du matériel utilisé. PyTorch offre de la flexibilité, des implémentations spécialisées fournissent des noyaux optimisés, et la compilation permet de fusionner les opérations en un parcours spécifique à la GPU. La bonne solution provient de l’évaluation de votre modèle réel sur votre matériel réel.
Un astuce efficace pour la diffusion
Les modèles de diffusion effectuent de nombreuses étapes : les premières établissent la structure générale tandis que les suivantes affinent les détails. Cela ouvre une opportunité : réduire les opérations coûteuses de guidage effectuées dans les étapes ultérieures. Une approche consiste à omettre le guidage sans classeur vers la fin du processus tout en conservant le même nombre d’étapes. Dans un exemple avec 50 étapes, le nombre de passes du modèle passe de 100 à 80, sans pour autant que la qualité ne soit généralement affectée.
Le tour particulier importe moins que le principe. Chaque itération ne contribue pas de manière égale au résultat final, et l’optimisation des inférences peut exploiter cet déséquilibre.
La génération de vidéos est une autre échelle
La génération de vidéos correspond à la génération d’images avec une dimension temporelle supplémentaire. Là où le latent d’une image est :
Height × Width
Une vidéo latente devient :
Height × Width × Time
Cela rend le problème de calcul bien plus complexe. La vidéo est limitée par les capacités de calcul, et les systèmes occupent souvent des nœuds entiers dotés de plusieurs GPU avec de très petits volumes de lots, voire un seul élément par lot, car tous les GPU collaborent pour traiter une seule séquence.
Cela crée une distinction nette par rapport à la génération de texte. Avec le texte, un volume de lot plus important peut améliorer le débit de traitement. Avec la vidéo, le regroupement en lots est peu utile, car une seule génération peut déjà consommer la majeure partie des ressources de calcul. Ainsi, le moyen le plus rapide d’obtenir des vidéos moins coûteuses est souvent l’utilisation d’un modèle plus rapide.
L’attention domine dans la vidéo
Dans la génération de vidéo, l’attention peut absorber une grande partie des ressources de calcul, soit entre 70 et 80 pour cent dans certaines tâches. Cela modifie les priorités : au lieu de quantifier principalement les poids, les ingénieurs se concentrent sur les noyaux d’attention, la quantification de l’attention, le cache, le parallélisme contextuel et l’exécution parallèle au niveau du GPU.
Le cache pour la vidéo fonctionne différemment
La génération de vidéos ne fait pas appel à l’approche de cache KV auto-régressif. Au lieu de cela, les systèmes réutilisent des parties des calculs précédents de deux manières principales. Le cache par étapes temporelles réutilise les résultats des étapes de débruitage sélectionnées. Le cache Transformer réutilise les états cachés et saute certaines opérations au sein du modèle Transformer. Ces deux méthodes peuvent apporter d’importantes améliorations de vitesse, mais elles peuvent également dégrader sérieusement la qualité en fonction de l’algorithme. Par conséquent, considérez chaque optimisation comme un cycle :
Optimization
↓
Speed ↑
↓
Quality ?
↓
Evaluate
↓
Production
N’imaginez jamais qu’une optimisation de mise en cache soit sûre simplement parce que la vidéo semble toujours correcte.
La quantification suit le goulot d’étranglement
Pour les LLM, la quantification vise généralement les grandes couches linéaires et leurs poids, car l’inférence des LLM est souvent limitée par la bande passante mémoire. La génération de vidéos est quant à elle limitée par les capacités de calcul, en particulier pour l’attention, ce qui fait de celle-ci une cible attrayante pour la quantification. Cependant, l’attention est également très sensible aux erreurs numériques.
Deux options s’offrent à vous : vous pouvez quantifier par blocs en utilisant des formats de micro-échelle tels que MXFP8, ou vous pouvez quantifier de manière sélective en variant la précision à chaque étape :
Early steps → FP16
Middle steps → Lower precision
Late steps → Lower precision
ou par couche :
Input layer → FP16
Hidden layers → Lower precision
Output layer → FP16
Préservez la précision là où le modèle est fragile, et optimisez intensément là où ce n’est pas le cas.
Aucune optimisation universelle n’existe
Entre ces différentes modalités, les stratégies gagnantes ne se ressemblent pas du tout :
| Modality | Dominant Concern | High-Value Techniques |
| ---------------- | --------------------------- | ----------------------------------------------------- |
| VLM | Long visual context | KV optimization, caching, parallelism |
| Embeddings | High request volume | Batching, queueing, horizontal scaling |
| ASR | Decoder latency | Optimized decoder, streaming, parallel chunks |
| TTS | Real-time concurrency | Streaming, batching, efficient decoding |
| Image generation | Compute | Kernel fusion, compilation, fewer expensive passes |
| Video generation | Massive compute + attention | Attention kernels, caching, quantization, parallelism |
C’est pourquoi l’ingénierie des inférences est plus proche du travail sur les systèmes que de la simple accélération d’un LLM.
Points clés
- L’inférence multimodale dépend de la charge de travail. La meilleure architecture suit le modèle d’exécution ainsi que les exigences du produit.
- Les modèles autoregressifs et de diffusion présentent des goulots d’étranglement fondamentalement différents.
- Les VLM convertissent les entrées visuelles en contexte supplémentaire, ce qui rend l’optimisation du cache KV et celle du contexte long encore plus importantes.
- Les systèmes d’embeddings sont principalement confrontés à des problèmes de traitement par lots et de débit, plutôt qu’à des retards de décodage.
- Les améliorations en ASR proviennent principalement de l’orchestration et du streaming, et non seulement de noyaux plus rapides.
- Pour la TTS, une fois que la génération dépasse le temps réel, l’optimisation devient une question liée au nombre d’utilisateurs simultanés.
- La génération d’images est limitée par les ressources de calcul, ce qui rend essentiels les noyaux, la fusion, la compilation et la réduction des étapes de débruitage.
Où cela mène
Les produits d’IA deviennent par défaut multimodaux. Le texte, les images, l’audio, la vidéo et les embeddings sont de plus en plus intégrés dans la même application, ce qui transforme la tâche de simplement ajuster un modèle en ajustant toute une chaîne de traitement. La question à se poser n’est plus de savoir quelle technique d’optimisation utiliser, mais plutôt où se situe le goulot d’étranglement dans ce travail spécifique et quel compromis on peut prendre en toute sécurité pour le résoudre.
Cette mentalité s’applique aussi bien à une seule carte graphique utilisée pour un modèle d’incorporation qu’à un cluster multi-cartes graphiques générant des vidéos en temps réel. Il faut connaître la charge de travail, identifier les goulots d’étranglement, tester les compromis auxquels on est prêt à consentir, et ajuster l’ensemble du système plutôt que seulement le modèle.