L'IA dans votre bibliothèque photo, et pourquoi nous l'avons déplacée sur nos propres GPU

Quand vous cherchez « chien dans la neige » dans votre bibliothèque photo et que la bonne image apparaît, quelque chose a déjà lu cette photo pour vous. Personne ne l’a étiquetée. Un modèle de machine learning a regardé les pixels, déterminé ce qui se trouvait dans le cadre, et enregistré cette compréhension pour que vous puissiez la retrouver plus tard. Nous avons récemment déplacé ce travail des CPU vers nos propres GPU (graphics processing units, processeurs graphiques). Cet article explique ce que fait réellement l’IA, et pourquoi le matériel qui la fait tourner compte.

Les modèles qui rendent cela possible ne sont pas les nôtres. Ils proviennent du projet open source Immich sur lequel PixelUnion est construit. Ce qui est à nous, c’est l’endroit où ils tournent : sur du matériel que nous possédons et exploitons nous-mêmes, sur le sol européen, pas dans un cloud d’IA tiers. Les modèles lisent vos photos, et pour nous, il est important qu’ils le fassent dans nos propres racks et nulle part ailleurs.

Il y a une distinction à établir avant d’aller plus loin, car c’est celle qui compte le plus pour votre vie privée. Utiliser un modèle n’est pas la même chose que l’entraîner. L’entraînement est le processus coûteux et unique par lequel un modèle apprend à partir de millions d’images d’exemple, et il est réalisé par les auteurs du modèle bien avant qu’il ne nous parvienne. Ce que nous faisons, c’est de l’inférence : nous prenons un modèle fini, déjà entraîné, et faisons passer votre photo une seule fois pour obtenir un résultat, comme vous passez un document dans un scanner. Vos photos ne servent jamais à apprendre quoi que ce soit aux modèles. Elles ne sont pas ajoutées à un jeu d’entraînement, elles n’améliorent pas un modèle partagé, et rien de ce qui les concerne ne part rendre une future version plus intelligente. Le modèle regarde votre photo, fournit sa réponse, et l’oublie.

Trois tâches, une astuce commune : rendre les pixels consultables

Immich fait tourner son IA dans un service séparé, le conteneur immich-machine-learning, documenté dans le README machine learning du projet. Il accomplit trois tâches, et chacune résout un problème différent :

• La recherche intelligente transforme une photo en quelque chose que vous pouvez chercher en langage courant, à l’aide d’un modèle CLIP.
• La reconnaissance faciale trouve les visages et détermine ceux qui appartiennent à la même personne, à l’aide d’un pack de modèles comme buffalo_l.
• L’OCR lit le texte qui apparaît dans vos photos, à l’aide d’un modèle PP-OCRv5.

Il vaut la peine d’être précis ici, car « trois modèles » est une simplification. Deux de ces tâches sont en réalité une paire de modèles qui travaillent en séquence, et chaque tâche peut être remplacée par un autre modèle. La reconnaissance faciale exécute un modèle de détection suivi d’un modèle de reconnaissance, et buffalo_l est un ensemble qui contient les deux. Immich propose aussi des alternatives comme antelopev2, buffalo_m et buffalo_s. L’OCR fonctionne de la même façon, un modèle pour trouver le texte et un autre pour le lire. Et CLIP lui-même est une paire d’encodeurs, un pour les images et un pour le texte, avec de nombreuses variantes interchangeables. Il n’y a aucun modèle de détection d’objets distinct : reconnaître qu’une photo contient un chien ou une plage est géré par CLIP, pas par un modèle d’étiquetage dédié.

Ce qui compte pour les comprendre, c’est que les trois tâches partagent une même astuce sous-jacente. Comprenons donc cette astuce d’abord. Ensuite, les différences prennent tout leur sens.

CLIP : chercher par le sens, pas par les étiquettes

L’ancienne recherche photo reposait sur les noms de fichiers et les étiquettes manuelles. Si vous n’aviez pas tapé « plage » dans une légende, chercher « plage » ne trouvait rien. CLIP, un modèle publié à l’origine par OpenAI (article ici), lève cette limite. Il regarde le contenu réel d’une image.

Voici la partie qui déroute, expliquée simplement. CLIP ne stocke pas de liste de mots pour chaque photo. Il convertit chaque photo en un vecteur : une longue liste de nombres, quelques centaines, qui décrivent ensemble le sens de l’image. Une photo d’un husky dans la neige fraîche et une photo d’un autre chien dans la neige aboutissent à des listes de nombres similaires, parce qu’elles signifient des choses similaires. Cette liste s’appelle un embedding.

Ce qu’est réellement la recherche vectorielle

Une fois que chaque photo de votre bibliothèque est un vecteur, nous stockons tous ces vecteurs dans une base de données. La recherche se déroule ainsi :

1. Vous tapez « chien dans la neige ».
2. Le même modèle transforme vos mots en un vecteur, dans le même système de nombres que les photos.
3. La base de données compare votre vecteur de recherche aux vecteurs de photos stockés et mesure à quel point chacun est proche.
4. Les correspondances les plus proches reviennent en premier.

« Proche » est ici une question de mathématiques. Chaque vecteur est un point dans l’espace, et le système mesure la distance entre votre requête et chaque photo. Dans sa forme la plus simple, c’est du brute force : vérifier la distance à chaque photo, une par une, trier selon la plus proche. À aucun moment il n’y a de correspondance d’étiquettes ni de recherche par mot-clé dans ce processus. Une photo sans légende, sans nom de fichier et sans description ressort quand même, parce que son sens vit dans les nombres.

Cette comparaison en force brute est la version honnête, et pour une bibliothèque normale elle fonctionne bien. Elle nomme aussi le coût. Comparer une requête à des millions de vecteurs, un par un, devient lent. À grande échelle, on passe à des index plus intelligents, la recherche approximative des plus proches voisins, qui sautent la plupart des comparaisons et trouvent quand même les bons résultats. L’approche nécessaire dépend de la taille de la bibliothèque, mais le principe reste le même : tout convertir en vecteurs, puis trouver les plus proches.

Encore une chose qui compte en Europe. Le modèle CLIP par défaut gère bien l’anglais et mal les autres langues. Il existe des variantes multilingues, et Immich vous permet de les remplacer, comme le décrit son guide de sélection de modèle. Le compromis est réel : les meilleurs modèles multilingues sont plus grands et ont besoin de plus de mémoire pour tourner. Cette pression sur la mémoire est l’une des raisons pour lesquelles le choix du matériel commence à compter, nous y venons.

buffalo_l : retrouver la même personne à travers vos photos

La reconnaissance faciale dans Immich utilise buffalo_l, un pack de modèles du projet InsightFace, hébergé pour Immich sur Hugging Face. Il fonctionne en deux étapes, et les deux valent la peine d’être comprises, car on suppose souvent qu’il fait quelque chose qu’il ne fait pas.

La première étape est la détection. Le modèle balaie l’image et détermine où sont les visages. Pensez au carré de mise au point qu’un appareil dessine autour d’un visage, sauf que le modèle le fait après coup, sur chaque photo. Le résultat est un ensemble de cadres : voici un visage, en voici un autre.

La deuxième étape est la reconnaissance. Pour chaque visage trouvé, le modèle produit un vecteur, la même idée que CLIP mais réglée pour les visages. Vous pouvez le voir comme une empreinte numérique de ce visage. Deux photos de la même personne, sous une lumière différente et sous des angles différents, produisent des vecteurs qui se situent près l’un de l’autre. Deux personnes différentes se situent loin l’une de l’autre.

C’est tout le mécanisme derrière « personnes » dans votre bibliothèque. Nous ne cherchons pas votre visage dans une base de données externe, et rien ne porte de nom tant que vous ne choisissez pas d’étiqueter une personne vous-même. Le modèle mesure la géométrie d’un visage et la transforme en nombres, puis regroupe les nombres qui sont proches. Le guide sur les clusters de visages d’Immich décrit comment ce regroupement peut être ajusté. Les empreintes restent dans notre système, sur notre matériel. Elles ne sont jamais le produit.

PP-OCRv5 : lire le texte à l’intérieur de vos images

La plus récente des trois est l’OCR, la reconnaissance optique de caractères, ajoutée dans Immich version 2.2. Elle utilise PP-OCRv5, un modèle du projet PaddleOCR de Baidu. L’OCR est ce qui vous permet de chercher des mots qui apparaissent dans une photo : un panneau de rue, une devanture de magasin, un tableau blanc, l’étiquette d’une bouteille.

Cela fonctionne aussi en deux étapes, et la division reflète la reconnaissance faciale.

D’abord, elle détecte le texte. Le modèle trouve les zones de l’image qui contiennent de l’écriture et dessine des cadres autour, de la même façon que le modèle de visages encadre les visages. Une photo de rue peut avoir du texte à cinq endroits : un panneau, une plaque d’immatriculation, une affiche, un menu, un bus. Chacun devient un cadre.

Ensuite, elle lit. Pour chaque cadre, un second modèle détermine quels caractères sont réellement présents et les transforme en texte réel, lisible par la machine. Ce texte va dans l’index de recherche, de sorte que vous pouvez plus tard chercher « pizzeria » et trouver la photo de la devanture du restaurant, même si vous n’avez jamais tapé de légende.

Le compromis est un de ces détails typiquement « Marc » qui mérite d’être signalé : l’OCR est bon pour le texte imprimé net dans les écritures prises en charge, et bien plus faible pour l’écriture manuscrite ou les polices très stylisées. Immich prend officiellement en charge l’anglais, le chinois et le japonais, les langues à écriture latine fonctionnant généralement avec une précision un peu moindre, comme abordé dans le fil de discussion sur les langues OCR du projet. C’est une fonctionnalité réellement utile, pas magique.

Pourquoi tout cela tourne bien mieux sur un GPU

Chaque modèle ci-dessus effectue au fond le même type de calcul : d’énormes quantités de petites multiplications et additions, organisées en calcul matriciel. Transformer une photo en vecteur, ce sont des millions de ces opérations. Ce seul fait explique toute l’histoire du matériel.

Un CPU a un petit nombre de cœurs très performants, une poignée à quelques dizaines. Chaque cœur est flexible et rapide, et traite les tâches en grande partie en séquence. Cette conception est excellente pour le travail varié et ramifié qu’un serveur effectue toute la journée. Elle est mal adaptée à faire la même multiplication simple quelques millions de fois d’affilée.

Un GPU est l’inverse. Il a des milliers de cœurs plus simples, conçus pour exécuter la même opération à la fois sur d’énormes lots de nombres, en parallèle. Les cartes graphiques ont été conçues pour colorer des millions de pixels simultanément, et il se trouve que l’inférence de machine learning est le même type de problème : les mêmes maths, répétées sur beaucoup de données. Ainsi, au lieu que les millions d’opérations d’une photo s’écoulent vague après vague à travers quelques cœurs de CPU, elles se répartissent ensemble sur des milliers de cœurs de GPU.

Le résultat n’est pas une petite amélioration, c’est un ordre de grandeur de vitesse différent pour cette charge de travail précise. Immich propose exactement cela dans sa documentation sur l’accélération matérielle, qui permet au service de machine learning de tourner sur CUDA, ROCm ou OpenVINO plutôt que sur le CPU. Les retours de la communauté donnent une idée de l’échelle. Sur CPU, la recherche intelligente est systématiquement la plus lente des tâches de machine learning, les utilisateurs la décrivant comme le goulot d’étranglement lors de l’indexation d’une grande bibliothèque. Sur du matériel GPU modeste, un compte rendu documente l’embedding d’environ 300 000 photos en moins d’une nuit. Ce sont des chiffres externes issus des installations d’autres personnes, pas les nôtres, mais la direction est partout cohérente : le GPU résorbe l’arriéré en une fraction du temps.

Les cartes que nous avons choisies sont d’anciennes cartes graphiques grand public, pas de nouveaux accélérateurs de centre de données. C’est un choix délibéré, et il s’accompagne de compromis qui méritent d’être nommés. Une telle carte possède encore des milliers de cœurs parallèles et assez de mémoire embarquée pour contenir ces modèles confortablement, et c’est tout ce dont cette charge de travail a besoin. Les modèles ne sont pas grands selon les standards actuels. CLIP est le plus lourd des trois, tandis que les modèles de visage et d’OCR sont relativement légers. Réutiliser du matériel ancien mais performant maintient du bon silicium en service au lieu de le mettre sur une étagère, et cela garde toute la chaîne sur des équipements qui nous appartiennent entièrement.

Il y a un coût réel de l’autre côté de la balance, et prétendre le contraire serait malhonnête. Un GPU tire plus de courant en charge qu’un CPU au repos, et faire tourner son propre matériel signifie que nous assumons la maintenance, les pilotes et l’électricité. Nous pensons que c’est le bon compromis. Par photo traitée, le GPU fait le travail avec une bien meilleure efficacité, et cela signifie que l’IA qui lit vos souvenirs tourne sur des machines que nous contrôlons, sous le droit européen, plutôt que d’être expédiée vers le cloud de quelqu’un d’autre pour être traitée.

Pour l’instant, nous faisons tourner les modèles par défaut d’Immich, les mêmes que tout utilisateur d’Immich obtient d’origine. La raison pour laquelle cette étape matérielle va au-delà de la vitesse, c’est la marge. Les modèles plus grands ont généralement besoin de plus de puissance de calcul et de plus de mémoire pour tourner à un rythme utilisable, précisément ce qu’un CPU ne pouvait pas fournir. Avec nos propres GPU en place, faire tourner une variante CLIP plus grande pour une recherche plus fine, ou un modèle de visage plus lourd pour un meilleur regroupement, devient une option pratique plutôt qu’une impossibilité. Nous ne faisons ici aucune promesse sur des modèles précis. Le point, c’est que cette étape ouvre la porte, et de meilleurs résultats pour nos clients sont la raison de la franchir.

Il y a un piège avec le passage à un modèle plus grand, et il vaut mieux être franc à ce sujet. Un modèle différent produit des vecteurs différents. Les nombres qu’un modèle CLIP attribue à une photo ne signifient rien pour un autre modèle CLIP, vous ne pouvez donc pas mélanger l’ancien et le nouveau. Si un jour nous passons à un modèle plus grand, nous devrions recalculer les embeddings de chaque photo dans la bibliothèque de chaque utilisateur à partir de zéro, sur nos propres GPU. Pour une grande base d’utilisateurs, c’est une quantité de calcul énorme, et c’est exactement le genre de tâche qui est sans espoir sur des CPU et simplement importante sur des GPU. Cette étape nous rapproche d’être prêts pour cela, mais nous n’y sommes pas encore. Quand nous y serons, cela méritera son propre article.

Pourquoi nous le faisons nous-mêmes

Aucun de ces modèles n’est exotique, et aucun n’est secret. C’est la nature du fait de bâtir sur de l’open source : vous pouvez lire exactement ce que font CLIP, buffalo_l et PP-OCRv5, et nous aussi. La décision qui façonne réellement votre vie privée n’est pas quel modèle tourne, mais où il tourne et qui l’exploite.

Nous les faisons tourner sur nos propres GPU, dans notre propre environnement, sur le sol européen. Vos photos sont lues par des machines dont nous sommes responsables, et les vecteurs et empreintes issus de ce processus restent chez nous et ne sont jamais vendus. C’est la part que Big Tech ne vous offrira pas, car pour eux, la lecture de vos photos est le modèle économique, pas une fonctionnalité.

Pour être clair sur où nous en sommes : c’est une première étape, pas le tableau achevé. Les modèles de machine learning tournent désormais sur nos propres GPU, mais toute notre plateforme ne tourne pas encore sur du matériel qui nous appartient. Nous construisons une infrastructure auto-exploitée pièce par pièce, et l’IA qui lit vos photos était un point de départ délibéré, parce que c’est la partie la plus sensible. Nous préférons vous dire exactement ce qui tourne où aujourd’hui plutôt que de laisser entendre que nous sommes plus avancés que nous le sommes. Attendez-vous à ce que nous développions cela dans de futurs articles à mesure qu’une plus grande part de la pile migre vers notre propre matériel.

Si vous voulez une bibliothèque photo dotée d’une recherche aussi performante, sans confier les données sous-jacentes à une entreprise qui les monétise, c’est exactement ce que nous construisons.

Découvrez ce que nous proposons →

Une note sur les images : les infographies de cet article ont été générées avec l’IA. Nous pensons qu’elles méritent leur place, car elles rendent ces idées plus faciles à se représenter.