Les modèles vidéo et multimodaux à poids ouverts cassent les prix du haut de gamme, mais la traçabilité reste en retard

L'argument du coût pour les modèles ouverts

Pour les acheteurs, c'est d'abord une question de dépenses. Une équipe payait autrefois le prix fort pour chaque tâche. Elle peut désormais réserver le modèle coûteux au dixième le plus difficile. Le reste tourne sur des poids qu'elle télécharge. Les petits modèles multimodaux tournent aussi sur les appareils, pas seulement dans le cloud d'un fournisseur. Cela réduit la latence et les mouvements de données. La pile moins chère ne règle pas la traçabilité. Des poids ouverts se copient, se renomment et se font passer pour autre chose sans effort. Aucune norme de vérification commune n'existe. Les régulateurs et les plateformes n'ont toujours aucun moyen simple de rattacher une sortie à un modèle précis.

Le hic, c'est le dixième qui reste sur le modèle de pointe. Il faut encore décider quelles tâches y ont droit. Une mauvaise décision coûte moins cher à prendre qu'à corriger.

La vidéo et les embeddings sont les deux bouts d'un même basculement. Des capacités autrefois réservées à une API arrivent désormais sous forme de poids.

Pika a publié H3 Flex le 29 octobre. C'est un modèle de génération vidéo à poids ouverts destiné aux créateurs professionnels, aux développeurs et aux chercheurs. L'entreprise a entraîné MiniMax H3 pour produire une vidéo en six étapes au lieu de 50. Elle a ensuite affiné le modèle pour la qualité visuelle et le contrôle créatif. Les adaptateurs du modèle sont sur Hugging Face. Le code d'inférence est sur GitHub. Pika présente le modèle comme un outil d'itération, pas de génération en un seul coup. C'est là que les secondes gagnées s'accumulent.

Pika ouvre la génération vidéo

Pika H3 Flex gère la génération texte-vers-vidéo, image-vers-vidéo et à partir de références.

Les créateurs peuvent fournir jusqu'à 12 fichiers de référence, images, vidéos et audio. Dans l'exemple de Pika, une image fixe un personnage. Une photographie définit l'environnement. Un clip montre le mouvement de caméra voulu. Un fichier audio porte le son. La sortie native est en 480p et 768p. Les services hébergés de Pika l'étendent à 1 080p, 2 000p et 4 000p. La vidéo générée porte un audio stéréo synchronisé. L'API hébergée expose cinq pistes audio distinctes.

Pika affirme qu'un clip de 15 secondes en 768p avec audio demande environ sept secondes de calcul du transformer dans un benchmark contrôlé. C'est du temps de calcul, pas un temps de bout en bout. Le traitement des références, le décodage, la surcharge du service et la finition en plus haute résolution allongent tous l'attente.

Moins d'étapes raccourcissent la boucle entre deux essais. Les créateurs peuvent tester des prompts, des mouvements de caméra et des personnages avec moins d'attente entre les itérations.

Des modèles multimodaux plus petits arrivent sur les appareils

L'équipe EmbeddingGemma de Google a pris le chemin inverse, celui de la taille. Son EmbeddingGemma 2, à 744 000 000 de paramètres, encode texte, images, audio, vidéo et leurs combinaisons dans un seul espace d'embedding de 768 dimensions. Le budget se répartit entre un socle texte de 271 000 000 de paramètres, un encodeur vision de 167 000 000 et un encodeur audio de 305 000 000. Les chiffres sur appareil viennent d'un Pixel 11 Pro. La variante texte seule Q4_C quantifiée culmine à 191 Mo sur cet appareil. La pile multimodale complète occupe 567 Mo. La recherche audio native atteint 69,54 MRR@10. À comparer aux 50,95 de la pipeline EG1 ASR-plus-texte antérieure de Google. L'article affirme que le modèle dépasse des systèmes spécialisés et des modèles deux à douze fois plus gros sur les benchmarks multimodaux.

Le Matryoshka Representation Learning permet aux appelants de tronquer l'embedding à 128 dimensions. Les entreprises qui ne font que du texte peuvent ignorer les autres tours.

La taille achète la portabilité, pas le raisonnement. Les scores publiés portent sur la recherche d'information, pas sur des tests de génération.

La vérification et la sécurité restent en retard sur les sorties

Anthropic construit un système open source. Il prouvera quel modèle a produit une sortie.

Un billet de blog publié le 3 novembre présente ce système, FlashProve. Il obligerait les laboratoires à publier une empreinte de chaque modèle. Les laboratoires pourraient ensuite faire correspondre cette empreinte aux sorties et la vérifier cryptographiquement. Les empreintes ne révèlent pas les poids du modèle. Les laboratoires commerciaux pourraient les publier sans céder leur actif le plus précieux. Anthropic a publié la spécification et le code fonctionnel sur GitHub. Elle a aussi indiqué qu'aucun déploiement du système n'était prévu chez Anthropic ni dans un autre laboratoire.

Une étude de l'Université de Hong Kong chiffre l'écart de sécurité. Seedance 2.0 Pro de ByteDance arrive en tête du classement de qualité visuelle de l'étude avec 3,84 sur 5. Veo 3.1 de Google DeepMind obtient 3,47. Sora 2 Pro d'OpenAI obtient 3,27. Seedance mène aussi sur la cohérence visuelle, le réalisme physique, la qualité esthétique et le respect des consignes. Seedance fait moins bien sur la sécurité. La même étude le place sixième sur 11 modèles pour le blocage de contenus nuisibles. Zhenhui Jack Jiang a dirigé la recherche. Il est professeur d'innovation et de gestion de l'information à l'école de commerce de l'université.

Anthropic décrit le travail FlashProve comme un progrès intermédiaire. Elle invite d'autres à s'en emparer et à l'améliorer. Aucun laboratoire ne s'est engagé à publier des empreintes. Aucune date de déploiement n'existe.