Tous les articles
IA & dev

Mirai uzu sur Mac : brancher Spring AI ou LangChain4j sur un LLM local

Par Elouan Laurent

Qu'est-ce que uzu, le moteur d'inférence de Mirai ?

uzu est un moteur d'inférence open source, sous licence MIT, publié par l'organisation GitHub trymirai. Un moteur d'inférence, c'est le logiciel qui fait tourner un modèle déjà entraîné. Celui-ci vise d'abord les appareils Apple, et il peut se lancer en serveur HTTP compatible OpenAI sur 127.0.0.1:8000.

Le README du dépôt trymirai/uzu le résume en une ligne : « A high-performance inference engine for AI models. » Je l'ai relu le 29 octobre 2026. Il annonce la version 0.6.13.

Une précision, car Google mélange tout sur ce nom. Ce uzu n'a rien à voir avec MirAI, l'assistant IA du ministère de l'Intérieur, ni avec le botnet Mirai.

Pour un développeur Java, la partie intéressante est le serveur. Pas de binding Java, mais une API que Spring AI et LangChain4j savent déjà appeler.

Ce que dit le README : bindings, plateformes, conversion des modèles

uzu est écrit en Rust. Le README liste trois bindings (la couche qui expose une bibliothèque Rust à un autre langage) :

  • Swift, via uniffi-rs ;
  • Python, via pyo3 ;
  • TypeScript, via napi-rs.

Java n'y figure pas, ni Kotlin, ni la JVM sous une autre forme.

Côté calcul, trois backends sont listés : metal (l'API graphique d'Apple), webgpu (l'API graphique des navigateurs) et cpu. Le README dit aussi qu'uzu exploite la mémoire unifiée des appareils Apple, cette RAM que le processeur et la puce graphique se partagent.

Les cibles se lisent en deux groupes :

  • Listées sans réserve : macOS sur Apple Silicon (aarch64-apple-darwin), macOS sur Intel (x86_64-apple-darwin), iOS, Mac Catalyst (le portage d'apps iPad sur Mac) et le simulateur iOS.
  • Marquées « in progress » : Windows, Linux et wasm.

Le README ne dit pas si la cible Mac Intel est testée au même niveau que les puces Apple. Je ne m'avancerais pas sur un vieux MacBook Intel.

uzu a son propre format de modèle : le README précise qu'il « uses its own model format ». Pour un modèle qui n'est pas déjà publié dans ce format, le README documente lalamo, l'outil de conversion du même éditeur. L'exemple du README convertit un Llama 3.2 avec uv run lalamo convert.

Lancer le serveur local : un cargo run, pas de binaire documenté

Premier frottement pour un développeur Java : il faut la chaîne Rust. Le README lance le serveur depuis les sources, avec cargo, le gestionnaire de projets Rust. Dans la section Server, aucun binaire précompilé n'est documenté.

Pour une première installation sur un clone du dépôt, le README recommande cargo tools setup. Cette commande installe les dépendances manquantes, dont rustup, uv, pnpm et la chaîne d'outils Metal. Ensuite, la commande du serveur :

cargo run --release -p cli -- server --model trymirai/Qwen3.5-4B-M

Le modèle est chargé au démarrage, et téléchargé d'abord s'il n'est pas déjà sur la machine. Le serveur écoute sur 127.0.0.1:8000. Les options --host et --port changent l'adresse.

Il expose deux endpoints, à la racine et sous /v1 :

  • POST /v1/chat/completions, avec streaming quand la requête porte "stream": true ;
  • GET /v1/models, qui liste le modèle chargé.

Mon premier réflexe serait de lire l'identifiant du modèle avant de toucher au code Java :

curl http://127.0.0.1:8000/v1/models

Je n'ai pas lancé ce serveur. Les commandes sont recopiées du README, pas testées sur ma machine.

Brancher Spring AI ou LangChain4j sur le serveur d'uzu

Comme uzu n'a pas de binding Java, on passe par HTTP. Votre application parle déjà à OpenAI : vous changez l'adresse et le nom du modèle. C'est exactement le branchement détaillé pour un serveur local sous Windows, avec deux valeurs différentes : l'URL de base et l'identifiant du modèle.

Côté Spring AI 2.x, je garde cette configuration dans un profil Spring local, pour ne jamais la livrer en production :

# application-local.properties
spring.ai.openai.base-url=http://127.0.0.1:8000/v1
spring.ai.openai.api-key=
spring.ai.openai.chat.model=<identifiant lu dans /v1/models>

Le /v1 final et la clé vide tiennent au fonctionnement interne de Spring AI 2.0. L'article Windows le détaille, je ne le refais pas ici. Le README d'uzu confirme seulement que ses endpoints existent sous /v1.

Une limite si vous suivez le jalon Spring AI 2.1 et son API Responses. Le README d'uzu ne liste que /v1/chat/completions et /v1/models. Rien n'y indique un endpoint /v1/responses.

Côté LangChain4j 1.22, le module langchain4j-open-ai suffit :

ChatModel model = OpenAiChatModel.builder()
        .baseUrl("http://127.0.0.1:8000/v1")
        .apiKey("not-needed")
        .modelName("trymirai/Qwen3.5-4B-M")
        .build();

String resume = model.chat("Résume ce ticket en trois lignes : ...");

J'ai compilé ce code contre LangChain4j 1.22.0. Je ne l'ai pas exécuté contre uzu.

La clé not-needed est factice. La section Server du README ne parle pas d'authentification, et son exemple curl n'envoie aucune clé. Je n'en déduis rien de plus.

Surtout, je n'ai pas vérifié que les clients OpenAI de Spring AI et de LangChain4j fonctionnent avec ce serveur. « Compatible OpenAI » ne dit pas quelle part de l'API est couverte.

Le README précise lui-même les paramètres honorés : temperature, top_p, top_k et max_tokens. Les appels d'outils et les sorties structurées figurent dans les exemples du SDK. La section Server n'en dit rien.

Les limites : Apple d'abord, version 0.x, aucun chiffre vérifié

Apple d'abord. Aujourd'hui, uzu sert surtout macOS et iOS. Windows et Linux sont « in progress ». Sur un poste Windows, je renverrais vers l'outil décrit dans l'article Llama Windows.

Une version 0.x. La 0.6.13 est une version de jeunesse : son API peut changer d'une release à l'autre. Si vous l'intégrez à un test d'intégration, figez la version et le modèle.

Un format de modèle maison. Le README documente lalamo pour exporter un modèle dans ce format, et son exemple de serveur charge un modèle déjà publié sous trymirai. Un modèle récupéré ailleurs suppose donc une étape de conversion.

Trois frottements Java. Pas de binding, pas de binaire documenté, pas de compatibilité vérifiée avec les clients Java.

Les performances. Le README ne publie aucun chiffre de vitesse. Il fournit une commande bench, sans résultats.

Le seul chiffre que j'ai lu vient de TechCrunch, le 19 février 2026. Le journal présente Mirai comme une startup fondée par des cofondateurs de Reface et de Prisma. Il rapporte que son moteur Rust accélère la génération « jusqu'à 37 % », selon la société.

C'est une déclaration de la société, pas une mesure indépendante. L'article ne donne ni méthode ni point de comparaison, et il ne nomme pas uzu. Je n'ai fait tourner aucun banc de test : je ne le confirme ni ne le contredis.

Mon avis : à essayer sur un Mac, pas encore à parier

Pour un développeur Java sur un Mac Apple Silicon, uzu mérite une heure d'essai. Le serveur compatible OpenAI évite d'écrire une ligne de Rust côté application. Votre code Spring Boot ne change pas : seul le profil local change.

Pour de la production, c'est trop tôt. Une version 0.x, un format de modèle propre à l'éditeur, aucun binding Java et aucun chiffre de performance indépendant. Je n'en ferais pas une dépendance d'un service livré à des clients.

Le test que je ferais, dans cet ordre :

  1. Lancer le serveur avec le modèle d'exemple du README.
  2. Lire son identifiant avec curl http://127.0.0.1:8000/v1/models.
  3. Envoyer un seul appel depuis le profil local de l'application, puis vérifier le streaming.

S'il échoue à l'étape 3, l'écart vient de la compatibilité OpenAI, pas de votre code.

Vous voulez cadrer ce test de LLM local sur votre projet Java / Spring Boot ? Je développe sur cette stack depuis 2015. Réserver un appel découverte de 30 minutes.

À lire ensuite