Des chercheurs de NTU apprennent à une IA à zapper la vidéo : jusqu'à 59 % de jetons économisés

Des chercheurs du College of Computing and Data Science de l'Université technologique de Nanyang (Singapour) ont résolu un problème qui freine les « modèles omni » — des systèmes d'IA capables de traiter simultanément texte, audio, images et vidéo — dans leur quête de rapidité et d'économie. Des modèles comme Qwen2.5-Omni et Qwen3-Omni affichent de solides performances précisément parce qu'ils fusionnent des données issues de sources variées pour construire une compréhension globale de la situation. Mais cette puissance a un prix : le traitement vidéo coûte plusieurs fois plus que celui du texte et du son, et en pratique, la vidéo s'avère souvent totalement superflue pour obtenir la bonne réponse.

Pourquoi la vidéo est un luxe coûteux et pas toujours nécessaire

Sur le benchmark WorldSense (des tests de compréhension de situations combinant audio et vidéo), les auteurs ont mesuré qu'une requête texte+audio occupe en moyenne environ 3000 jetons d'entrée, contre près de 40 000 jetons si l'on y ajoute la vidéo — soit plus de 13 fois plus. Or, pour certaines questions, la vidéo est réellement indispensable (par exemple, « de quelle couleur est la porte » ne peut se résoudre sans image), tandis que pour d'autres, elle ne fait que nuire. Dans un exemple cité, Qwen2.5-Omni répondait correctement avec l'audio seul, mais se trompait dès que la vidéo était ajoutée à la requête — la modalité supplémentaire détournait le modèle de la bonne piste.

Comment fonctionne la sélection des modalités adaptée à chaque requête

Plutôt que de réentraîner le modèle omni lui-même ou de compresser les jetons vidéo, les auteurs proposent de placer en amont du modèle un « routeur » léger. Celui-ci n'examine que le texte de la question — via les embeddings du modèle BGE-M3 — et décide, avant même le lancement du modèle principal, si le texte et l'audio (TA) suffisent ou s'il faut aussi mobiliser la vidéo (TAV).

Ce routeur n'est pas entraîné sur une classification classique, mais sur une tâche sensible au coût de l'erreur : pour chaque exemple d'entraînement, on calcule quelle option (TA ou TAV) offrirait le meilleur équilibre entre précision et coût, et cette option devient la réponse correcte attendue du routeur. Par ailleurs, les requêtes pour lesquelles une erreur de sélection de modalité coûte particulièrement cher — qu'elle dégrade fortement la précision ou qu'elle alourdisse considérablement l'inférence — reçoivent un poids plus élevé pendant l'entraînement. Le routeur apprend ainsi à déterminer quand la vidéo est nécessaire en se concentrant précisément sur les cas où cela compte le plus.

Résultats concrets

Les tests ont été menés sur le benchmark WorldSense avec deux modèles — Qwen2.5-Omni-7B et Qwen3-Omni — et le coût de chaque requête a été mesuré selon trois critères : le nombre de jetons d'entrée, la latence de réponse et le coût monétaire (selon les tarifs des jetons par modalité).

• Pour Qwen2.5-Omni, le routeur « sensible au coût » proposé atteint une précision comparable au mode « toutes modalités systématiquement » (TAV), mais ne consomme qu'environ 41 % des jetons d'entrée, 39 % du temps de réponse et 61 % du coût monétaire de ce mode complet.
• Cela représente une économie de près de 59 % sur les jetons, 61 % sur le temps et 39 % sur les coûts, tout en préservant la précision initiale.
• Les auteurs ont comparé leur méthode à plusieurs alternatives : une sélection aléatoire de modalité, un « juge » basé sur Gemini 2.5 Pro qui décide, à partir du texte de la question, si la vidéo est nécessaire, ainsi que des approches en cascade — où le modèle répond d'abord avec le texte et l'audio, puis fait appel à la vidéo en cas de faible confiance dans sa réponse. Sur les trois métriques de coût, le classificateur sensible au coût proposé a obtenu le meilleur rapport précision/prix face à toutes ces alternatives.
• La méthode Estimate-Then-Predict (qui estime séparément la qualité et le coût de chaque configuration de modalités) a également surpassé les approches en cascade, mais reste inférieure à l'approche principale proposée.

Ce que cela signifie pour les ingénieurs

La conclusion pratique est claire : si vous développez un produit basé sur des modèles omni (analyse vidéo, modération de contenu, assistants équipés de caméra), il n'est pas nécessaire d'inclure systématiquement la vidéo dans chaque requête. Un classificateur simple et peu coûteux, basé sur le texte de la requête, suffit à déterminer quand la vidéo est réellement utile — ce qui peut permettre d'économiser plus de la moitié du budget d'inférence sans sacrifier la qualité des réponses. Cette approche est particulièrement précieuse pour les services à forte charge, où chaque jeton et chaque milliseconde de latence supplémentaires pèsent directement sur la facture d'inférence.