Prise en charge omni-modale par vLLM : Exécution de modèles multimodaux avec vLLM

vLLM omni n’est pas un produit distinct. Il s’agit d’un raccourci désignant l’utilisation de vLLM — le moteur d’inférence LLM à haut débit — pour servir des modèles omni-modaux modèles omni-modaux, c’est-à-dire des modèles capables d’accepter du texte, des images, de l’audio et de la vidéo au sein d’une même conversation. En pratique, cela signifie presque toujours la série Qwen2.5-Omni d’Alibaba, bien que la pile multimodale de vLLM prenne également en charge les modèles vision-seule ou audio-seule via la même API.

Ce guide explique ce que signifie « omni » dans le contexte de vLLM, quels modèles sont pris en charge, comment les installer et les déployer, à quoi ressemble le format des requêtes, ainsi que les limites actuelles.

Ce que signifie « Omni » dans le contexte de vLLM

Le sous-système multimodal de vLLM classe les modèles selon les modalités acceptées en entrée. Les catégories pertinentes sont les suivantes :

Les modèles omni-modaux partagent une même architecture linguistique centrale, complétée par des encodeurs spécialisés pour chaque modalité (un ViT pour les images et les images fixes vidéo, un encodeur audio dérivé d’architectures de type Whisper, etc.). La tâche de vLLM consiste à planifier ces encodeurs, mettre en cache leurs sorties et les entrelacer avec le flux de jetons textuels dans le cache KV afin de maintenir un débit élevé.

La génération côté sortie dans vLLM est textuelle. Si vous souhaitez exploiter la fonctionnalité native de synthèse vocale (speech synthesis) prise en charge par Qwen2.5-Omni, vous devez actuellement utiliser l’implémentation de référence fournie par les auteurs du modèle — vLLM vous fournira la transcription textuelle, mais pas le signal audio brut. C’est le point le plus important à comprendre avant de choisir vLLM pour une charge de travail omni.

Modèles omni-modaux pris en charge

La liste officielle figure dans la documentation vLLM, sous la rubrique Modèles pris en charge → Modèles de langage multimodaux. À titre de référence stable, les familles suivantes bénéficient depuis longtemps d’un support natif :

• Qwen2.5-Omni (3B, 7B) — le modèle « omni » canonique, acceptant texte + image + audio + vidéo en entrée et produisant du texte en sortie.
• MiniCPM-o 2.6 — modèle omni de classe 8B développé par OpenBMB.
• Qwen2-VL / Qwen2.5-VL — modèles vision + vidéo uniquement, souvent regroupés avec les workflows « omni ».
• Qwen2-Audio — version audio uniquement, complémentaire.

Comme la prise en charge des modèles est ajoutée à chaque version, consultez systématiquement la documentation actuelle et la fiche technique du modèle pour connaître la version minimale de vLLM requise. Tenter de déployer un nouveau modèle omni sur une ancienne version de vLLM constitue le mode d’échec le plus fréquent. Parcourez une liste à jour des Base de données de modèles si vous êtes encore en phase de choix.

Exigences matérielles

Les modèles omni-modaux sont plus lourds que leurs homologues texte-seul à nombre de paramètres équivalent, car ils intègrent des encodeurs supplémentaires et parce que les entrées vision/audio génèrent un grand nombre de jetons après tokenisation. Une seule image à sa résolution native peut générer de 1 000 à 4 000 jetons ; une minute d’audio, plusieurs centaines.

Il s'agit de fourchettes pratiques, pas des minimums indiqués dans les fiches techniques. Pour obtenir une valeur exacte correspondant à votre longueur de contexte et à votre taille de lot, intégrez le modèle dans le Calculateur de VRAM ou consultez le Référence des besoins en VRAM. Si vous n'avez pas encore choisi de matériel, le meilleures GPU pour les LLM locaux guide présente les compromis associés aux gammes 24 Go, 48 Go et multi-GPU.

Installation

vLLM est conçu en priorité pour Linux. Windows n'est pas officiellement pris en charge ; utilisez WSL2 ou un conteneur Linux. macOS propose une version CPU uniquement, capable techniquement de charger de petits modèles, mais totalement inadaptée au déploiement en production de modèles omni-modaux.

Linux (recommandé)

Configuration requise : une carte graphique compatible CUDA (capacité de calcul 7.0 ou supérieure), pilotes CUDA 12.x, Python 3.9 à 3.12.

# Créez un environnement isolé
python -m venv vllm-env
source vllm-env/bin/activate

# Installez vLLM (cela installe automatiquement une version compatible de PyTorch)
pip install vllm

# Dépendances supplémentaires couramment nécessaires pour les modèles omni
pip install librosa soundfile decord

vllm --version

Le librosa, soundfile, et decord gèrent respectivement le décodage audio et l'extraction de trames vidéo. Certains modèles omni les intègrent automatiquement via trust_remote_code; leur installation préalable évite les échecs lors de la première requête.

Windows (via WSL2)

Installez WSL2 avec une distribution Ubuntu 22.04 ou 24.04, puis installez le pilote NVIDIA sous Windows (WSL utilise directement ce pilote Windows). Ensuite, suivez les étapes d'installation Linux à l'intérieur de WSL. N'installez pas de pilote NVIDIA Linux séparé dans WSL — cela rendrait CUDA inopérant.

macOS

macOS ne prend pas en charge CUDA, et vLLM ne cible pas Metal. Pour l'inférence multimodale locale sur Apple Silicon, privilégiez plutôt LM Studio ou des runtimes basés sur MLX. vLLM n'est pas adapté à cet usage.

Déploiement d’un modèle omni

Lancez un serveur compatible OpenAI :

vllm serve Qwen/Qwen2.5-Omni-7B 
  --trust-remote-code 
  --dtype bfloat16 
  --max-model-len 32768 
  --limit-mm-per-prompt image=4,audio=2,video=1 
  --port 8000

Paramètres clés :

• --trust-remote-code est requis car les modèles omni embarquent du code de prétraitement personnalisé dans leurs dépôts Hugging Face.
• --limit-mm-per-prompt limite le nombre d'éléments par modalité autorisés dans chaque requête. Augmenter ces valeurs accroît le budget d'entrées multimodales, mais augmente aussi la pression sur la VRAM.
• --max-model-len doit être défini explicitement. Les jetons visuels et audio sont comptabilisés dans cette limite.
• --tensor-parallel-size N répartit le modèle sur N GPU si une seule carte est insuffisante.

Envoi de requêtes multimodales

vLLM expose l'API OpenAI Chat Completions. Les parties multimodales suivent la convention du tableau « content » d'OpenAI :

curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "Qwen/Qwen2.5-Omni-7B",
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "Décrivez ce que vous voyez et entendez."},
        {"type": "image_url", "image_url": {"url": "https://example.com/scene.jpg"}},
        {"type": "audio_url", "audio_url": {"url": "https://example.com/clip.wav"}}
      ]
    }]
  }'

Le client Python est identique à celui d'OpenAI :

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-Omni-7B",
    messages=[{"role": "user", "content": [
        {"type": "text", "text": "Transcrivez et résumez."},
        {"type": "audio_url", "audio_url": {"url": "file:///data/meeting.wav"}},
    ]}],
)
print(resp.choices[0].message.content)

URL de données (data:image/png;base64,...) et chemins locaux file:// sont tous deux pris en charge ; l'ensemble exact des schémas acceptés s'est élargi au fil des versions, aussi consultez la documentation correspondant à votre version si un schéma échoue.

Remarques sur les performances

• Le préremplissage domine. Encoder un extrait audio d'une minute ou une image en 720p sollicite fortement le processeur ou le GPU, et intervient avant la génération du premier jeton. Le regroupement (batching) améliore le débit, mais pas la latence par requête.
• Pression sur le cache KV. Une seule image peut ajouter des milliers de jetons au cache. Réduisez --max-model-len ou abaissez --limit-mm-per-prompt si vous rencontrez des erreurs de mémoire insuffisante (OOM) sous charge.
• Quantification. Les variantes AWQ et GPTQ 4 bits de Qwen2.5-Omni-7B tiennent sur une carte de 16 Go et perdent relativement peu de qualité sur les tâches de compréhension visuelle et audio. Leur disponibilité dépend des contributions communautaires sur Hugging Face.
• Préremplissage fragmenté (activé par défaut dans les versions récentes) atténue la latence lors du mélange de requêtes multimodales et de requêtes textuelles uniquement.

Quand utiliser vLLM omni plutôt que des alternatives

Si vous hésitez encore à auto-héberger, faites les calculs avec le Calculateur de seuil de rentabilité entre hébergement local et utilisation d’une API. Les charges de travail omni-modales orientent la réponse, car le nombre de jetons par requête est nettement plus élevé que pour le texte seul, ce qui rend la tarification à l’usage de l’API plus coûteuse par session.

Questions fréquemment posées

vLLM prend-il en charge la sortie vocale de Qwen2.5-Omni ?

Non. vLLM gère la génération de texte à partir du cœur linguistique du modèle. La tête optionnelle de décodage audio, qui produit les réponses parlées dans l’implémentation de référence de Qwen2.5-Omni, n’est pas intégrée à vLLM. Vous obtenez la réponse textuelle du modèle, et vous devrez effectuer une étape TTS distincte ou utiliser le code d’inférence d’origine pour synthétiser la parole.

Puis-je exécuter des modèles omni vLLM sur une carte de 24 Go comme une RTX 4090 ?

Oui, pour les variantes 3B et 7B, notamment en bf16 avec un contexte modéré, ou confortablement avec une quantification AWQ/GPTQ pour des contextes plus longs. Vous devrez ajuster --max-model-len et --limit-mm-per-prompt pour rester sous la limite mémoire. Vérifiez à l’aide du Calculateur de VRAM avant de vous engager.

Pourquoi ma requête échoue-t-elle avec une erreur « trust_remote_code » ?

Les modèles omni-modaux intègrent des préprocesseurs Python personnalisés dans leurs dépôts Hugging Face. vLLM n’exécute pas ce code à moins que vous ne passiez l’option --trust-remote-code au démarrage du serveur. N’activez cette option que pour les dépôts de modèles auxquels vous faites confiance.

Comment envoyer une vidéo à un point de terminaison vLLM omni ?

Utilisez une partie de contenu avec "type": "video_url" pointant vers une URL accessible ou un fichier local. vLLM échantillonne les images à l’aide de decord; le nombre exact d’images et la stratégie d’échantillonnage sont spécifiques au modèle et documentés sur la fiche technique du modèle. Les vidéos consomment rapidement des jetons : gardez donc les extraits courts et définissez l’option --limit-mm-per-prompt video=1 sauf si vous disposez de suffisamment de VRAM.

Existe-t-il une image Docker pour vLLM omni ?

L’image officielle vllm/vllm-openai sur Docker Hub prend nativement en charge les modèles multimodaux, quelle que soit la version de vLLM indiquée dans son tag. Préférez un tag spécifique plutôt que la dernière afin d’éviter toute dérive involontaire vers une version incompatible avec votre modèle omni.

Ollama peut-il exécuter ces modèles omni à la place ?

Ollama prend en charge certains modèles vision-langue, mais sa couverture omni-modale accuse un retard sur celle de vLLM, et les entrées audio/vidéo sont limitées ou absentes pour la plupart des modèles. Pour un flux de travail sur poste de travail, consultez la Meilleurs modèles locaux pour Ollama et le Liste des modèles Ollama afin de connaître les modèles actuellement disponibles ; pour bénéficier de l’ensemble des fonctionnalités omni sur un serveur, privilégiez vLLM.