Ollama annonce un nouveau moteur pour les modèles multimodaux

• Ollama commence à prendre en charge les modèles multimodaux (texte + image) grâce à un nouveau moteur
• La prise en charge de divers modèles visuels multimodaux comme Llama 4 Scout et Gemma 3 permet désormais de répondre à des questions combinant images et texte
• Le nouveau moteur apporte une meilleure modularité des modèles, une précision accrue et une gestion efficace de la mémoire
• Grâce à la mise en cache des images et à l’exploitation des métadonnées matérielles, il offre des performances d’inférence rapides et une optimisation du matériel
• D’autres extensions sont prévues, notamment la prise en charge de contextes plus longs, l’appel d’outils et le streaming

---

Prise en charge des modèles multimodaux par Ollama

Avec l’introduction d’un nouveau moteur multimodal, Ollama prend en charge les derniers modèles de vision multimodale capables de traiter conjointement images et texte

Compréhension multimodale globale et raisonnement

Llama 4 Scout

• Ollama prend en charge Llama 4 Scout (109 milliards de paramètres, modèle mixture-of-experts)
• Il est par exemple possible de poser des questions basées sur la localisation dans une image extraite d’une vidéo
  • Ex.) détection de divers éléments visuels comme un bâtiment précis, des éléments d’environnement ou des informations d’arrière-plan
• Il est ensuite possible d’enchaîner naturellement avec différentes questions de suivi
  • Ex.) « Quelle est la distance entre ce bâtiment et Stanford ? », « Quel est le meilleur moyen d’y aller ? » ; le modèle fournit des informations précises
  • Il peut répondre en tenant compte de la situation réelle, avec plusieurs moyens de transport, itinéraires et durées estimées

Gemma 3

• Gemma 3 peut recevoir plusieurs images à la fois et analyser les relations entre elles
  • Ex.) il repère rapidement, dans 4 images, des animaux ou plantes présents en commun, la présence d’une scène donnée ou des situations inhabituelles selon différents critères
  • Exemple plus ludique : en observant un lama et un dauphin en train de boxer, il peut analyser lequel gagnerait en identifiant les caractéristiques et la dynamique de chacun

Reconnaissance et analyse de documents

Qwen 2.5 VL

• Le modèle Qwen 2.5 VL est utilisé pour la reconnaissance de texte (OCR) et l’extraction d’informations textuelles spécifiques dans les images
  • Cas d’usage concrets : extraire les informations d’un chèque ou traduire en anglais des inscriptions verticales chinoises telles que des distiques de printemps

Caractéristiques du moteur multimodal d’Ollama

• Jusqu’à présent, Ollama s’appuyait sur le projet ggml-org/llama.cpp pour prendre en charge les modèles, avec un développement centré sur la facilité d’usage et la portabilité des modèles
• Avec la publication récente de modèles multimodaux par divers laboratoires, Ollama a renforcé son propre moteur afin d’élargir encore la prise en charge des modèles, conformément à son objectif
• Le nouveau moteur traite les modèles multimodaux comme des objets indépendants de premier ordre et favorise davantage la participation des partenaires et de la communauté

Ce que signifie cette évolution du moteur

• Elle améliore la fiabilité et la précision de l’inférence locale d’Ollama et pose les bases du support de nombreux domaines multimodaux à l’avenir (par exemple : voix, génération d’images, génération vidéo, contextes longs, usage amélioré des outils, etc.)

Modularité des modèles

• La « portée d’impact » de chaque modèle est isolée de façon indépendante afin d’améliorer la fiabilité et de permettre aux développeurs d’intégrer facilement de nouveaux modèles
  • Les versions précédentes de ggml/llama.cpp ne prenaient en charge que les modèles textuels ; dans le multimodal, le décodeur de texte et l’encodeur de vision sont séparés et exécutés distinctement
  • Les images doivent être transformées en embeddings par l’algorithme de vision avant d’être transmises au modèle de texte, ce qui permet d’implémenter une logique allégée propre à chaque modèle
  • Dans Ollama, chaque modèle peut séparer ses propres couches de projection d’embeddings conformément à son schéma d’entraînement spécifique
  • Les créateurs de modèles peuvent ainsi se concentrer uniquement sur leur modèle et son entraînement, sans patchs supplémentaires ni conditions complexes
  • Quelques exemples d’architectures de modèles sont disponibles dans le dépôt GitHub d’Ollama

Précision accrue

• Les grandes images peuvent produire un grand nombre de tokens et dépasser la taille de batch
  • Si l’image dépasse le batch, les informations de position peuvent être dégradées
• Lors du traitement des images, Ollama ajoute des métadonnées supplémentaires pour améliorer la précision
  • Il gère avec précision des détails comme l’application ou non de l’attention causale, ainsi que le découpage en batch des embeddings d’image et la gestion des frontières
  • Si les points de découpe sont inadaptés, la qualité de sortie peut se dégrader ; les critères sont ajustés selon les références des articles de recherche propres à chaque modèle
• D’autres outils d’inférence locale implémentent cela chacun à leur manière, mais Ollama garantit la qualité par un traitement fidèle à la conception et à la méthode d’entraînement de chaque modèle

Optimisation de la gestion mémoire

• Mise en cache des images : une image traitée une fois reste stockée en mémoire, ce qui accélère le traitement des prompts suivants. Tant que les limites mémoire ne sont pas atteintes, l’image est conservée
• Prédiction mémoire et optimisation du cache KV : en collaboration avec des fabricants de matériel et des partenaires OS, Ollama identifie précisément les métadonnées matérielles et vise à optimiser l’usage de la mémoire
  • Des validations sont effectuées selon les versions de firmware, et des benchmarks sont menés pour les nouvelles fonctionnalités
• Ollama optimise séparément la causal attention au niveau de chaque modèle et fournit des réglages adaptés individuellement, plutôt qu’au niveau du groupe
  • Exemples :
    • Gemma 3 de Google DeepMind : l’attention à fenêtre glissante n’alloue qu’une partie de la longueur de contexte, tandis que le reste de la mémoire est alloué à l’inférence simultanée, etc.
    • Llama 4 Scout, Maverick, etc. de Meta : prise en charge de la chunked attention, des embeddings rotatifs 2D, etc., avec implémentation de la prise en charge des contextes longs pour les modèles mixture-of-experts
• Pour les modèles dont les couches d’attention ne sont pas entièrement implémentées, le système peut « fonctionner », mais avec un risque de baisse de qualité des sorties et de résultats anormaux à long terme

Prochaines étapes

• Prise en charge de longueurs de contexte plus importantes
• Renforcement des capacités de raisonnement
• Appel d’outils et réponses en streaming
• Extension des fonctions d’usage direct de l’ordinateur

Remerciements

• Organisations et chercheurs ayant contribué au développement des modèles
  • Remerciements à Google DeepMind, Meta Llama, Alibaba Qwen, Mistral, IBM Granite ainsi qu’aux nombreux laboratoires et membres de la communauté ayant contribué au développement de modèles de vision
• GGML
  • La bibliothèque de tenseurs de l’équipe GGML est un élément central du moteur d’inférence d’Ollama. En accédant directement à GGML depuis Go, il est possible de concevoir des graphes d’inférence personnalisés et des architectures de modèles complexes
• Partenaires matériels
  • Remerciements aux partenaires matériels tels que NVIDIA, AMD, Qualcomm, Intel et Microsoft pour leur collaboration à l’amélioration des performances d’inférence sur divers appareils

[GN⁺]

Avis Hacker News

• Surprise en apprenant à ce stade l’annonce d’un nouveau moteur par Ollama, avec le sentiment que le fait que llama.cpp ait enfin intégré une fonctionnalité de vision stable dans la branche principale après de longs efforts porte enfin ses fruits, et l’impression qu’Ollama préparait déjà cette fonctionnalité depuis longtemps ; l’idée aussi que la décision de rompre avec la dépendance initiale à llama.cpp pour avancer de façon indépendante est un choix raisonnable
• Curiosité sur la différence concrète entre la manière dont les deux projets ont ajouté les fonctions multimodales ; le support de LLaVA existe depuis longtemps, donc questionnement sur le fait de savoir si cela nécessitait auparavant un traitement particulier ; attente que l’article en parle, mais confusion face au fait que le multimodal chez Ollama soit présenté comme une nouveauté totalement inédite
• Selon certains, le terme multimodal devrait inclure non seulement le texte et l’image, mais aussi l’audio, et potentiellement la vidéo ; si un modèle ne fait que la génération ou l’analyse d’images, alors « modèle de vision » serait un terme plus exact ; insistance sur la nécessité de distinguer clairement des modèles comme Qwen2.5-Omni et Qwen2.5-VL ; dans ce sens, le nouveau moteur d’Ollama ajouterait surtout un support de la « vision »
• Intérêt pour la gestion des entrées vidéo, avec une question sur la prise en charge éventuelle de la vidéo par Qwen2.5-Omni et Ollama
• Beaucoup de références au « nouveau moteur » d’Ollama, mais envie d’avoir des informations concrètes sur sa mise en œuvre réelle ; comme llama.cpp est lui aussi un projet impressionnant, si Ollama a construit un moteur de remplacement, il y a une attente de voir des exemples de la façon dont cela a été implémenté ; hypothèse selon laquelle la bibliothèque de tenseurs GGML joue un rôle central, avec une architecture où le comportement du modèle (par exemple une implémentation de Gemma3) serait écrit directement en Go via FFI pour exploiter les fonctions de GGML ; impression que ces détails techniques auraient dû être présentés plus explicitement dans le billet officiel
• Ollama a jusque-là eu l’image d’une entreprise critiquée pour son manque de transparence, l’opacité dans l’attribution des contributions et des décisions peu centrées sur les utilisateurs ; surprise, dans ce texte, de voir davantage de crédit accordé aux contributeurs, avec l’hypothèse que les nombreuses critiques des utilisateurs ont conduit à des ajustements
• Aveu que les conventions de nommage en « *llama » dans le monde des LLM sont devenues beaucoup trop confuses, avec une multitude de projets aux noms proches qui entretiennent la confusion
• Partage de la difficulté à suivre le rythme extrêmement rapide des avancées en IA/ML, au point qu’il devient difficile de comprendre ce qui se passe si l’on ne suit pas cela de près ; mention aussi de la préférence pour les noms « mèmes », avec des rappels d’anciennes modes comme les personnages de Sesame Street, la famille de modèles YOLO, et l’idée que même les articles de conférence n’y échappent pas
• En s’écartant un peu du sujet, questionnement sur les raisons pour lesquelles Ollama est mal vu par une partie des utilisateurs, au-delà de la simple injonction à faire tourner llama.cpp directement
• Partage de liens Reddit et GitHub Issues pour montrer qu’Ollama a depuis longtemps un problème de crédit insuffisant envers llama.cpp ; il est même souligné que, dans certains projets, on utilise directement llama.cpp tout en attribuant le mérite à Ollama ; Ollama ne contribue pas directement au projet (sans que ce soit une obligation), mais maintient un fork interne, ce qui permet aux personnes intéressées de récupérer le code par cherry-pick quand elles le souhaitent
• Au-delà des questions de culture, de licence et de FOSS déjà évoquées, expression d’un mécontentement sur la façon de stocker les fichiers : Ollama introduit son propre stockage disque et son propre registre, ce qui complique la réutilisation ; hypothèse selon laquelle l’architecture aurait été pensée à long terme pour une monétisation via une structure propriétaire ; cela pouvait viser, comme Docker, à éviter les doublons de stockage, mais dans les faits cela dégrade surtout l’usage ; au final, cela impose de conserver des fichiers volumineux de plus de 30 Go en double, ce qui transforme un problème mineur en vraie gêne ; une méthode standard compatible avec divers écosystèmes serait préférable, et cette contrainte a conduit certains à cesser d’utiliser Ollama
• Ollama est vu comme une solution pour le monde des LLM comparable à Docker, avec une expérience utilisateur et une syntaxe de fichiers de modèles qui semblent inspirées du Dockerfile ; souvenir qu’aux débuts de Docker, il y avait aussi des débats Docker vs LXC, et que l’innovation apportée à l’expérience utilisateur était parfois sous-estimée ; en revanche, le manque de reconnaissance de longue date envers llama.cpp reste considéré comme problématique, même s’il est ajouté qu’il y a aujourd’hui un peu plus d’ouverture dans l’attribution du crédit
• Mécontentement aussi vis-à-vis du manque de collaboration d’Ollama avec la communauté ; comme il s’agit d’une entreprise financée par du capital-risque, des questions persistent sur son modèle économique ; d’autres alternatives comme llama.cpp, lmstudio ou ramalama permettent de mieux comprendre leur positionnement ; ramalama est cité comme contribuant beaucoup à divers projets open source liés, avec un lien GitHub donné en référence
• Regret qu’Ollama ne reconnaisse pas clairement qu’il ne joue essentiellement qu’un rôle de frontend pour llama.cpp
• Remarque selon laquelle l’exemple d’« traduction verticale de chunlian chinois » présenté par Ollama contient de nombreuses erreurs ; supposition que l’auteur du billet n’est pas réellement sinophone ; analyse détaillée des écarts entre le contenu réel de chaque partie et le résultat produit par Ollama
• Le mainteneur ayant réalisé cet exemple est intervenu directement pour préciser qu’il est chinois, ce qui renforce sa crédibilité ; selon lui, la traduction anglaise elle-même était plutôt correcte ; il souligne qu’il n’a ni caché ni manipulé les erreurs du modèle ou de la démo, et partage l’espoir que la qualité du modèle continue de s’améliorer à long terme
• Intention d’essayer directement, avec une appréciation positive du format de l’article parce qu’il montre immédiatement des exemples pratiques et des détails
• La force d’Ollama était de permettre de lancer immédiatement des modèles avec une simple commande Docker, sans configuration particulière ; mais lorsqu’il faut exploiter des images et des vidéos, des limites techniques apparaissent car Docker n’utilise pas le GPU ; interrogation sur la manière dont Ollama compte maintenir à l’avenir son support de l’intégration Docker, et sur le risque que cette fonction devienne un élément secondaire du projet
• Réponse indiquant que, sur certaines plateformes, il est possible d’utiliser le GPU dans Docker, même si cela demande davantage de configuration, avec nvidia qui fournit une documentation à ce sujet
• Amusement devant le fait que l’exemple sur les indications d’itinéraire à Stanford donnait effectivement une mauvaise information, avec le rappel qu’en Californie, la CA-85 est plus au sud que Palo Alto
• Retour d’expérience positif après presque un an d’usage d’Ollama pour des modèles locaux ; en revanche, les fonctions multimodales comme Llava ont été peu explorées, l’usage étant resté surtout centré sur le texte ; demande de recommandations pour des projets utiles et intéressants construits sur des modèles locaux multimodaux, avec l’envie de trouver des idées de projets personnels