Représentation stylisée d'un pipeline de traitement de données où un module d'encodage alimente un module de modèle de langage.

vLLM supporte les entrées multimédias en métadonnées pour DeepSeek V4.1

Le moteur d’inférence vLLM a intégré la prise en charge des entrées multimédias en mode métadonnées pour le modèle DeepSeek V4.1 Flash. Cette fonctionnalité, ajoutée via une pull request sur le dépôt GitHub, permet de découpler les étapes d’encodage, de préremplissage et de décodage (EPD) dans les architectures de service multimodales.

En substance, au lieu de transmettre le fichier image ou audio brut à l’instance de langage, le système transfère les embeddings générés par l’encodeur, accompagnés de métadonnées précises décrivant la structure de l’entrée. Cela évite au consommateur de devoir retraiter l’intégralité du média, une opération qui peut être très coûteuse en ressources.

Ce mécanisme d’encodage découplé est essentiel pour gérer des charges de travail hétérogènes. Si une charge est très gourmande en capacité d’encodage mais demande peu de génération de jetons, les opérateurs peuvent ajuster indépendamment le nombre d’instances d’encodeur par rapport à celles du préremplissage/décodage. Selon le blog de vLLM, cette séparation permet une adaptation fine des ressources.

Ingénieurs travaillant sur des écrans affichant des schémas de flux de données complexes dans un bureau moderne.

Le transfert d’embeddings sans re-traitement

La distinction entre envoyer le média brut et envoyer les métadonnées est nette. Dans une implémentation EPD standard, l’encodeur prépare les embeddings, mais le consommateur doit souvent décoder, redimensionner ou normaliser le média pour retrouver le bon agencement d’entrée. Avec le mode métadonnées, l’encodeur publie déjà l’information structurelle nécessaire – comme les grilles d’images ou les longueurs de placeholders – que le modèle utilise directement.

Les sources précisent que cela ne signifie pas que l’encodeur ne s’exécute pas deux fois ; la duplication se situe au niveau du traitement du média. Cependant, en fournissant cette métadonnée, on s’assure que le consommateur n’aura pas à refaire le travail déjà accompli. Cette approche s’étend aux images, aux vidéos et aux fichiers audio pris en charge par le framework.

Au-delà de l’image : les évolutions du système

Bien que la prise en charge des entrées d’image en métadonnées soit mise en avant pour DeepSeek V4.1, le support EPD couvre également la gestion des données audio et vidéo. L’équipe a intégré des mécanismes pour transférer les états et les identités originales lorsque le traitement ne peut être entièrement ramené au mode métadonnées. D’autres avancées dans le dépôt vLLM montrent l’intégration de fonctionnalités comme le support de graphe CUDA pour DeepSeek V4.1 Flash et des améliorations sur la gestion des états récurrents dans des architectures hybrides.

On observe aussi des ajouts connexes qui affinent les capacités du système. Des travaux récents ont porté sur la généralisation des constructeurs de points de contrôle Mamba et sur l’amélioration de la façon dont les métadonnées de sparsité sont traitées lors de l’attention. L’EPD est une optimisation de l’architecture de déploiement, mais ces ajouts montrent que le cœur de la performance des modèles est aussi travaillé.

Il faut surveiller la maturité de l’implémentation de ce contrat métadonnée. Une bonne intégration exige que le format de métadonnée soit parfaitement cohérent avec ce qui est transmis par l’encodeur et ce que le modèle attend, afin d’éviter toute incohérence entre l’identité de l’entrée et ses représentations encodées.

Sources