ZML/LLMD : et si le « Docker des LLM » était français ?

L'inférence, nouveau goulot d'étranglement

Pendant deux ans, la conversation a tourné autour de la taille des modèles et du coût de leur entraînement. La mise en production a déplacé le curseur. Une fois un modèle en service, ce qui pèse au quotidien, c'est le coût par token servi, la latence perçue par l'utilisateur, et surtout la dépendance à un unique fournisseur de silicium. L'inférence est devenue le poste où se jouent à la fois la facture cloud et la marge de manœuvre stratégique.

C'est là que ZML place son pari : ne pas proposer un énième modèle, mais une couche qui découple le modèle du matériel. La promesse tient en trois mots que l'équipe répète comme une devise : model to metal.¹

Ce qu'est ZML/LLMD

ZML a été fondée à Paris en 2023 par Steeve Morin, ancien VP Engineering de Zenly (rachetée par Snap en 2017). L'équipe compte une vingtaine de personnes et a levé environ 20 millions de dollars, auprès d'un tour où l'on croise 20VC, Kima Ventures (Xavier Niel), Kindred Capital, LocalGlobe et Puzzle Ventures, entre autres.² Le détail qui fait sourire, et qui n'est pas anodin pour notre métaphore : figurent aussi au capital Solomon Hykes, le créateur de Docker, les cofondateurs de Hugging Face Clément Delangue et Julien Chaumond, et Yann LeCun, lauréat du prix Turing, qui soutient publiquement le projet.²

Il faut distinguer deux briques. ZML, le framework de bas niveau, est open source (licence Apache-2.0, écrit à plus de 90 % en Zig). LLMD, le serveur d'inférence construit au-dessus, ne l'est pas : il est gratuit au lancement, le temps pour l'équipe de collecter les usages avant une future monétisation.² Distinction classique, mais qu'il vaut mieux avoir en tête avant de bâtir dessus.

Comment ça marche : model to metal

Le principe est celui d'une pile à quatre étages. En haut, vos modèles (Qwen, Gemma, Mistral, LLaMa) sont chargés en zero-copy via un système de fichiers virtuel, directement depuis Hugging Face, S3 ou GCS, sans étape de téléchargement local. Vient ensuite LLMD, le serveur, qui expose une API compatible OpenAI (donc drop-in pour l'écosystème existant) et embarque les fonctions de serving attendues en production : continuous batching, paged attention, prefix caching, tool calling, métriques Prometheus.¹ Au-dessous, ZML compile le graphe du modèle, en amont et une fois pour toutes, vers un binaire natif hermétique, le tout en Zig et MLIR, sans Python dans le chemin d'exécution. Enfin, ce même binaire s'exécute sur cinq backends : NVIDIA CUDA, AMD ROCm, Google TPU, Intel oneAPI et Apple Metal.

L'élégance de l'approche tient dans un choix : portable, pas nivelé. Plutôt que de réduire tous les accélérateurs à un plus petit dénominateur commun, ZML préserve les chemins d'exécution spécifiques à chaque puce (FlashAttention sur NVIDIA, noyaux AITER sur AMD). Résultat annoncé : des images conteneur très compactes (de l'ordre de 1,7 Go pour CUDA, 280 Mo pour TPU, ~140 Mo pour le build Apple) et un démarrage à froid de l'ordre de une à deux secondes sur un modèle 8B.¹ Ces chiffres restent des annonces éditeur, en attendant des mesures indépendantes.

À noter enfin DFlash, l'accélérateur de décodage spéculatif que LLMD embarque. ZML met en avant un gain « jusqu'à 10× » sur les modèles supportés ; le travail de recherche sous-jacent rapporte plutôt un facteur allant jusqu'à ~6,17× sur Qwen3-8B.⁴ La nuance vaut d'être signalée si vous vous adressez à un public technique.

La démo qui parle : trois lignes

Sur un Mac Apple Silicon, faire tourner un modèle en local tient en deux commandes :

brew install zml/zml/llmd
llmd --model=hf://Qwen/Qwen3.6-27B

Le serveur écoute alors en local, en API compatible OpenAI. On l'interroge comme n'importe quel endpoint OpenAI :

curl localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3_5","messages":[{"role":"user","content":"Bonjour"}]}'

Toute la valeur de la compatibilité OpenAI est là : vos scripts, vos librairies et vos outils se rebranchent sur localhost:8000/v1 sans réécriture. Deux réserves pratiques : la première requête est plus lente (compilation du graphe), et un modèle 27B en BF16 réclame une machine généreuse en mémoire : comptez au moins 64 Go de mémoire unifiée, davantage pour être à l'aise.

Pourquoi cela compte pour nos clients

Au-delà de la prouesse technique, LLMD illustre trois enjeux que nous voyons remonter chez nos clients.

Le premier est économique. Découpler le workload du silicium, c'est se donner le droit de choisir la puce la moins chère ou la plus disponible pour une charge donnée, et donc d'agir directement sur le coût du token servi. C'est le cœur d'une démarche FinOps appliquée à l'IA générative, le même raisonnement que celui du coût par résultat : payer la charge au bon prix, sur le bon matériel.

Le deuxième est la liberté d'architecture. Sortir de la logique « un code par cible matérielle » réduit la dette technique et le coût de migration. Une entreprise qui peut, avec le même conteneur, viser un datacenter TPU aujourd'hui et un parc AMD demain conserve son pouvoir de négociation. C'est, un étage plus bas, la discipline du Design to Exit que nous défendons : payer d'avance la couche qui rend le fournisseur remplaçable, plutôt qu'espérer une réversibilité qu'on n'a pas construite. Nos clients qui ont bâti une couche d'abstraction cloud, comme France Télévisions avec sa plateforme ALIX, connaissent déjà la valeur de ce découplage : LLMD l'étend au niveau de la puce.

Le troisième est la souveraineté. ZML se positionne explicitement comme un facilitateur pour les puces européennes émergentes (Axelera, Kalray, SiPearl, VSORA). La startup a signé, à VivaTech 2026, un partenariat avec Scaleway, le concepteur de puces VSORA et la Région Île-de-France, autour d'une chaîne de valeur souveraine de l'inférence, du silicium jusqu'à son exploitation en production, avec l'intégration de la couche ZML dans le processeur Jotunn8 de VSORA.⁵ Pour un acteur européen, la capacité à ne pas dépendre d'un unique fournisseur de calcul pèse lourd : elle prolonge sur le terrain matériel le débat que nous avons ouvert sur les architectures multi-LLM souveraines et sur le choix multi-cloud contre souverain.

Le verdict, sans complaisance

Soyons clairs sur la maturité. LLMD est une technical preview : non destinée à la production, avec un support de modèles encore en expansion. Surtout, le support des machines locales précises que tout le monde a en tête (un DGX Spark de NVIDIA, un Ryzen AI Max+ 395 d'AMD, un Mac récent) se déduit des backends disponibles, mais n'est ni nommé ni benchmarké par l'éditeur. Le DGX Spark, en particulier (architecture ARM64 + Blackwell), est une cible suffisamment neuve pour que « support CUDA » ne garantisse pas que tout fonctionne d'emblée. À vérifier par vous-même avant toute promesse.

Face à la concurrence, le paysage se lit ainsi : vLLM reste la référence de débit sur GPU serveur, mais son support d'Apple Silicon est communautaire et expérimental ; llama.cpp demeure le roi de l'inférence locale mono-utilisateur. LLMD se situe entre les deux : un vrai serveur (batching, API OpenAI, observabilité) qui, en prime, tourne aussi sur votre poste. « Un vLLM qui s'installe sur un Mac » serait une approximation utile.

Alors, faut-il basculer aujourd'hui ? Non. Faut-il le mettre sous surveillance active ? Absolument. Si l'équipe tient ses promesses de performance, élargit son catalogue de modèles et sort de l'alpha, LLMD pourrait devenir le docker run de l'inférence : un modèle, une commande, n'importe quelle puce. Un candidat sérieux, made in France, à un moment où l'indépendance vis-à-vis du matériel devient un sujet de conseil d'administration.

Points clés

• LLMD découple le modèle du matériel : une seule base de code sert cinq familles de puces (NVIDIA, AMD, Google TPU, Intel oneAPI, Apple Metal), via un binaire natif compilé par ZML en Zig + MLIR.¹
• API compatible OpenAI : scripts, librairies et outils existants se rebranchent sur localhost:8000/v1 sans réécriture, avec continuous batching, prefix caching, tool calling et l'accélérateur DFlash.
• Deux briques, deux licences : ZML (le framework, Apache-2.0, Zig) est open source ; LLMD (le serveur) ne l'est pas, gratuit au lancement le temps de collecter les usages.²
• Une lecture souveraineté : ZML facilite les puces européennes émergentes et intègre sa couche dans le processeur VSORA Jotunn8, au sein d'une chaîne de valeur souveraine avec Scaleway et la Région Île-de-France.⁵
• Maturité à surveiller : c'est une alpha, non destinée à la production ; le support des machines locales précises (DGX Spark, Ryzen AI Max+, Mac récents) se déduit des backends mais n'est pas revendiqué. À tester avant toute promesse.

Chez SFEIR, nous aidons nos clients à évaluer, prototyper et industrialiser leurs choix d'infrastructure d'inférence, du FinOps du token à la stratégie multi-cloud et multi-hardware. Envie d'en discuter ?

Sources

1. ZML, « ZML/LLMD alpha : Model to Metal », zml.ai, 8 juillet 2026 (architecture model to metal, backends NVIDIA/AMD/TPU/Intel/Apple, chargement zero-copy, fonctions de serving, tailles d'images conteneur, démarrage à froid). zml.ai, billet LLMD
2. TechCrunch, « Hot French startup ZML releases free product to speed inference across lots of AI chips », 8 juillet 2026 (fondateur Steeve Morin ex-Zenly, levée d'environ 20 M$, investisseurs 20VC / Kima Ventures / Kindred Capital / LocalGlobe / Puzzle Ventures, business angels Solomon Hykes, Clément Delangue, Julien Chaumond, soutien de Yann LeCun, LLMD non open source et gratuit au lancement). techcrunch.com
3. Steeve Morin, annonce du lancement de ZML/LLMD, X (Twitter), 8 juillet 2026 (cinq architectures livrées d'origine, prise en charge de DFlash, continuous batching, prefix caching). x.com, @steeve
4. « DFlash: Block Diffusion for Flash Speculative Decoding », arXiv:2602.06036, février 2026 (accélération sans perte jusqu'à ~6,17× sur Qwen3-8B par décodage spéculatif à diffusion par blocs). arxiv.org/abs/2602.06036
5. GlobeNewswire, « The Île-de-France Region, Scaleway, VSORA and ZML commit to laying the foundations for the next generation of AI chips in Europe », 18 juin 2026 (partenariat VivaTech 2026, chaîne de valeur souveraine du silicium à l'exploitation cloud, intégration de la couche ZML dans le processeur VSORA Jotunn8). globenewswire.com