ML Drift : le moteur GPU on-device open source de Google, et quand il bat les généralistes

ML Drift est le moteur d'inférence GPU on-device que Google a ouvert : c'est la même technologie qui fait tourner les modèles dans Chrome, YouTube, Photos et Meet, et vous pouvez maintenant l'utiliser sur votre propre GPU, sous licence Apache 2.0.

Pensez à la différence entre un moteur de Formule 1 et le moteur d'une voiture de tous les jours. Ollama et llama.cpp sont le moteur de tous les jours : polyvalents, fiables, capables de faire tourner presque n'importe quel modèle presque partout. ML Drift est le moteur de F1 : conçu pour un contexte précis — le GPU d'un smartphone, d'un navigateur, d'un device edge — où chaque kilobyte de mémoire et chaque milliseconde de latence comptent.

Qu'est-ce que ML Drift

ML Drift est un moteur de calcul GPU cross-platform, open source sous licence Apache 2.0. Développé par l'équipe Google en charge de l'IA on-device, il est positionné comme le successeur du délégué GPU de TensorFlow Lite : ce délégué ne recevra plus de nouvelles fonctionnalités, et ML Drift est la voie officielle pour l'inférence on-device sur GPU.

Il s'intègre à LiteRT, le toolkit de Google pour l'IA on-device (l'évolution de TensorFlow Lite), et fonctionne sur pratiquement toutes les plateformes dotées d'un GPU :

Plateforme	Backend
Android	OpenCL
iOS, iPadOS, macOS	Metal
Navigateur	WebGPU (via Dawn)
Windows et Linux	via Dawn — early preview
GPU legacy	OpenGL ES 3.1+

Sous le capot

Quatre choix techniques expliquent la différence avec les moteurs généralistes :

1. Virtualisation des tenseurs. ML Drift abstrait les tenseurs du modèle : au lieu de compiler chaque opération pour chaque GPU, le moteur mappe les tenseurs sur une vue virtuelle que les backends exécutent nativement. Résultat : moins de code spécialisé par plateforme et des modèles qui se comportent plus pareil d'un device à l'autre.

2. Tenseurs 5D. Les modèles de vision (YOLO 11n, MobileViT v2, Swin v2 dans les exemples du repo) travaillent sur des tenseurs à 5 dimensions ; ML Drift les gère nativement, là où les moteurs pensés pour les LLM les traitent souvent en morceaux.

3. KV cache stage-aware. Pour les modèles génératifs, le prefill et le decode ont des profils de mémoire différents : le prefill est lourd sur les données d'entrée, le decode tourne à faible intensité. ML Drift gère les deux stages avec des stratégies de cache séparées, au lieu d'une stratégie unique à compromis.

4. Précisions multiples. FP16, INT8 et INT4 : le même modèle peut tourner à trois niveaux de quantisation selon la VRAM disponible et la qualité recherchée.

ML Drift, Ollama, llama.cpp : qui gagne où

Ils ne sont pas concurrents : ils travaillent à des niveaux différents.

	ML Drift	Ollama	llama.cpp
Ce que c'est	moteur GPU on-device	runtime LLM généraliste	engine LLM généraliste
Où il excelle	latence et mémoire sur device	simplicité : une commande pour tout	polyvalence matériel et modèles
Formats	FP16 / INT8 / INT4	GGUF (via llama.cpp)	GGUF, F16
Cas d'usage type	petits modèles sur mobile et dans le navigateur	modèle conversationnel sur le desktop	benchmarks et n'importe quel GPU

Quand ML Drift bat les généralistes : quand la contrainte est la mémoire ou la latence sur un device. Quand vous avez besoin de faire tourner un modèle de 24 à 70B sur desktop, ou d'utiliser tout l'écosystème GGUF, vous restez sur Ollama et llama.cpp. Pour comprendre comment fonctionnent les deux engines généralistes, partez de Ollama vs llama.cpp : sous le capot.

Les chiffres de la sortie

Les chiffres que Google rapporte dans l'annonce, tous sur du matériel en production :

• Gemma : jusqu'à 12 % d'overhead de mémoire en moins par rapport au délégué legacy
• YouTube Shorts : jusqu'à 40 % de latence de frame en moins (Android et iOS)
• Google Photos : jusqu'à 2 secondes de gain par rapport au délégué précédent
• Adobe Lightroom et Photoshop : jusqu'à 30 % de traitement on-device plus rapide
• Snap : 30 % de latence de modèle en moins

Le dépôt revendique un ordre de grandeur par rapport aux moteurs d'inférence GPU open source existants — chiffre du projet, à prendre comme tel jusqu'à ce que des benchmarks indépendants arrivent. La technologie est documentée dans le paper technique arXiv 2505.00232.

Et les limites ?

• Desktop en early preview. Windows et Linux tournent via Dawn : le support existe, mais Google le déclare en phase initiale.
• Modèles on-device. Les benchmarks montrent la famille Gemma : ML Drift est calibré pour les modèles qui tiennent sur un device, pas pour remplacer un cluster. Ce n'est pas un vLLM.
• Pas d'écosystème GGUF. Avec FP16/INT8/INT4, vous n'emportez pas la bibliothèque de modèles quantisés que vous utilisez avec Ollama : la sélection de modèles est plus étroite.
• Le délégué TFLite GPU n'évolue plus. Si vous avez des applications basées dessus, la migration vers ML Drift/LiteRT est la voie que Google recommande.

L'essayer

Le dépôt est le point de départ : il contient des exemples avec tenseurs 5D (YOLO 11n, MobileViT v2, Swin v2), le framework pour les opérations custom et un SKILL.md pensé pour faire travailler un agent IA sur le code du moteur. L'intégration dans les applications passe par LiteRT ; dans le navigateur, par WebGPU via Dawn. Si ça ne marche pas : vérifiez que votre GPU expose un backend supporté (OpenCL, Metal, WebGPU) et que le modèle est converti dans l'un des formats de précision supportés — ce sont les deux points où les portages échouent le plus souvent. Si vous voulez arracher de la vitesse à l'inférence sans changer de matériel, regardez Décodage spéculatif et MTP : la vitesse sans compromis.

Sources

• Annonce officielle : ML Drift, next-gen GPU AI/ML inference at the edge
• Dépôt google-ai-edge/ml-drift
• Paper technique : arXiv 2505.00232

En résumé

ML Drift est le moteur GPU on-device de Google, open source Apache 2.0, successeur du délégué GPU de TFLite : tenseurs virtualisés, KV cache séparée pour prefill et decode, FP16/INT8/INT4. Les chiffres de production sont réels — jusqu'à 40 % de latence en moins sur YouTube, 30 % sur Adobe et Snap — et le point fort est le device, pas le datacenter. Desktop en early preview, écosystème de modèles plus étroit que GGUF, et ce n'est pas un substitut à Ollama, llama.cpp ou vLLM : c'est une autre machine, faite pour un autre travail.

Article généré par IA