LLMUnity : faire tourner un modèle de langage dans un projet Unity
Create characters in Unity with LLMs!
En bref
- De quoi s’agit-il ?
- LLMUnity est un paquet C# qui relie le moteur Unity à une bibliothèque d'inférence dérivée de llama.cpp, avec un système RAG intégré. Le README annonce une exécution locale sur PC, mobile et VR, mais la documentation publique reste mince sur les coûts réels et les cas limites.
- À qui s’adresse-t-il ?
- LLMUnity convient aux projets Unity qui veulent une inférence locale sans dépendance à une API distante, en acceptant de gérer eux-mêmes les modèles GGUF et la mémoire. Les équipes qui visent un modèle servi à distance, ou qui ne peuvent pas embarquer plusieurs gigaoctets dans leur build, devraient passer leur chemin.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 140 jours.
- En quel langage est-il écrit ?
- Principalement C#, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème concret : un personnage qui répond sans serveur distant
Un PNJ scripté dans Unity ne peut pas improviser. Il débite des lignes écrites à l'avance, et dès que le joueur sort du scénario prévu, la conversation s'arrête. Brancher une API de modèle de langage en ligne règle ce problème mais en crée d'autres : latence réseau, coût par requête, et surtout des données de jeu qui partent chez un tiers. LLMUnity vise ce dernier point en priorité. Le README indique que le paquet "runs locally without internet access. No data never leave your game!", ce qui situe le projet du côté des jeux hors ligne, des applications VR et des contextes où la connexion n'est pas garantie.
Le public visé est précis : des développeurs Unity à l'aise en C#, pas nécessairement en inférence de modèles. Le paquet expose des composants à poser dans une scène, et le README promet un appel en une seule ligne de code. C'est un choix d'ergonomie assumé, au prix d'une couche d'abstraction qui masque les paramètres d'inférence. Pour un prototype de dialogue ou une démo de salon, c'est exactement ce qu'il faut. Pour un moteur de jeu qui doit contrôler finement le budget mémoire et le débit de tokens, la couche devient un obstacle à contourner.
LlamaLib entre Unity et llama.cpp
L'architecture tient en trois étages. Unity héberge les composants C# et la logique de personnage. En dessous, LlamaLib, décrit dans le README comme un backend "built on top of the awesome llama.cpp library and provided as a standalone C++/C# library". Tout en bas, llama.cpp exécute l'inférence. LlamaLib est donc un pont : il expose en C# ce que llama.cpp propose en C++, et Unity consomme ce pont via des appels natifs.
Ce découpage a une conséquence pratique que le README ne détaille pas. LlamaLib est un projet distinct, hébergé dans son propre dépôt. La version de LlamaLib embarquée dans un paquet LLMUnity donné détermine les architectures de modèles supportées et les optimisations disponibles. Le README affirme que l'inférence tourne sur CPU et GPU, avec Nvidia, AMD et Apple Metal cités, et que le paquet est testé sur Unity 2021 LTS, 2022 LTS, 2023 et Unity 6. Ces mentions restent des déclarations du projet, pas des mesures publiées. Aucun chiffre de débit ni de latence n'apparaît dans le matériel fourni, et il faut le dire clairement : la vitesse d'inférence dépendra du modèle choisi, de la quantification et du matériel, trois variables que le README n'encadre pas.
Le système RAG ajoute un quatrième élément. Le README parle d'un "Retrieval-Augmented Generation (RAG) system for semantic search across your data" et précise qu'il repose sur une recherche ANN, c'est-à-dire des plus proches voisins approximatifs. Le principe est classique : on découpe les données du jeu en fragments, on les vectorise, on retrouve les fragments pertinents pour la question du joueur, et on les injecte dans le contexte envoyé au modèle. Ce qui compte ici, c'est l'emplacement de l'index et le coût de sa construction, deux points que la documentation publique ne tranche pas.
Mise en route : paquet, scène, modèle
Le README renvoie à une section Setup et à une section Quick start, sans en recopier le contenu dans l'extrait disponible. Les commandes exactes d'installation ne figurent donc pas dans le matériel que j'ai. Ce que le README confirme, c'est la distribution via l'Asset Store Unity, avec un lien vers la fiche du paquet, et la présence d'un dépôt GitHub pour le code source. Un projet Unity s'installe typiquement par le gestionnaire de paquets ou par import d'un fichier .unitypackage, mais je ne peux pas affirmer laquelle de ces voies le projet recommande.
La gestion des modèles est décrite comme une section à part entière, intitulée "LLM model management". Le README affirme le support de "all major LLM models" et cite llama.cpp comme moteur, ce qui implique le format GGUF, format natif de llama.cpp. Là encore, les clés de configuration précises ne sont pas dans l'extrait. Ce que l'on peut dire sans inventer : un modèle de langage utilisable pèse de plusieurs centaines de mégaoctets à plusieurs gigaoctets selon sa taille et sa quantification, et ce poids se retrouve dans le build final s'il est embarqué. C'est la contrainte de déploiement dominante du projet, bien plus que l'API C# elle-même.
Le README mentionne aussi un "remote server setup", c'est-à-dire la possibilité de pointer vers un serveur distant plutôt que d'exécuter le modèle dans le processus du jeu. Cette option change complètement le profil de l'application : on garde l'API de LLMUnity côté client, mais on renonce à la promesse de fonctionnement hors ligne. Elle est utile pour tester un modèle trop gros pour la machine de développement, à condition d'accepter la dépendance réseau.
Ce que le paquet ne promet pas
Le README ne contient aucune section sur la consommation mémoire, sur le nombre de tokens par seconde atteignable, ni sur le comportement du système RAG quand l'index dépasse une certaine taille. C'est une lacune réelle pour quiconque doit dimensionner un budget. Un modèle de 7 milliards de paramètres quantifié en 4 bits occupe environ 4 Go en mémoire, avant même le contexte et le cache KV, mais ce calcul vient de la pratique générale de llama.cpp et non d'une donnée publiée par LLMUnity. Je le mentionne comme ordre de grandeur, pas comme spécification du projet.
Deuxième angle mort : le multijoueur et la concurrence. Rien dans le matériel fourni n'indique comment le paquet gère plusieurs personnages qui parlent en même temps, ni si une seule instance de modèle sert tous les PNJ ou si chacun en réclame une. Sur un jeu de dialogue à un seul interlocuteur, la question ne se pose pas. Sur une scène de marché avec huit marchands bavards, elle devient centrale.
Troisième limite : la qualité du dialogue dépend entièrement du modèle choisi, et le paquet ne fournit pas de modèle. Le README liste des jeux et projets construits dessus, ce qui montre que le paquet est utilisé en production, mais cette liste ne dit rien du réglage des invites ni des garde-fous. Un personnage de LLM non contraint dérive, sort du rôle et peut produire du contenu inadapté. Le paquet fournit le tuyau, pas la discipline éditoriale.
Face à un client d'API hébergé
L'alternative la plus directe n'est pas un autre paquet Unity, c'est un client HTTP vers une API de modèle hébergée. La différence d'approche est nette. Avec une API distante, le build ne contient aucun poids de modèle, la qualité du modèle peut être relevée sans republier le jeu, et la montée en charge se règle côté serveur. En échange, chaque requête a un coût, la latence dépend de la connexion du joueur, et les échanges sortent de la machine.
LLMUnity prend le chemin inverse : le modèle vit dans le processus du jeu. Le coût marginal d'une requête tombe à zéro et la conversation fonctionne dans un train ou en mode avion. Le prix à payer est fixe et se paie une fois : taille du build, mémoire vive résidente, temps de chargement au démarrage. Pour un jeu vendu à l'unité, ce coût fixe est souvent plus prévisible qu'une facture mensuelle d'inférence. Pour une application web ou un jeu compétitif où le matériel client n'est pas maîtrisé, il devient un risque de support.
Le README cite llama.cpp comme fondation, et c'est en soi un argument de comparaison : tout ce que llama.cpp sait faire en matière de quantification et de backends matériels est accessible par héritage, à condition que la version de LlamaLib embarquée suive. Un projet qui a besoin d'une fonctionnalité récente de llama.cpp devra vérifier que LlamaLib l'a intégrée avant de compter dessus.
Licence et coût de maintenance
Le dépôt est publié sous Apache-2.0, licence permissive qui autorise l'usage commercial et la modification, avec obligation de conserver les mentions de copyright et le texte de licence, et une clause de brevets. Le README annonce le paquet "Free to use for both personal and commercial purposes". Attention toutefois : la licence Apache-2.0 couvre le code de LLMUnity et de LlamaLib, pas les modèles que vous téléchargez. Chaque modèle GGUF a sa propre licence, parfois restrictive sur l'usage commercial. C'est la vérification à faire avant toute mise en vente, et elle ne relève pas de LLMUnity. Je ne donne pas de conseil juridique ici, seulement le périmètre des fichiers concernés.
Sur la maintenance, le rythme des versions récentes est soutenu : v3.0.1 fin janvier 2026, v3.0.2 fin février, v3.0.3 en mars, avec un dernier push sur la branche main en avril 2026. Un rythme de versions mineures tous les mois environ signifie que les correctifs arrivent vite, mais aussi que l'API peut bouger. Un projet qui épingle une version et ne la met à jour qu'entre deux jalons se protège des régressions. Un projet qui suit main en continu doit prévoir du temps de test à chaque montée de version, en particulier si LlamaLib change de version sous-jacente.
Le README renvoie à un tableau de bord de versions à venir et à un serveur Discord pour le support. Il n'existe pas de politique de support à long terme annoncée dans le matériel fourni. Pour un jeu déjà sorti, cela veut dire que la compatibilité avec une future version d'Unity dépendra de la bonne volonté des mainteneurs, pas d'un engagement contractuel.
Conclusion éditoriale
LLMUnity convient aux projets Unity qui veulent une inférence locale sans dépendance à une API distante, en acceptant de gérer eux-mêmes les modèles GGUF et la mémoire. Les équipes qui visent un modèle servi à distance, ou qui ne peuvent pas embarquer plusieurs gigaoctets dans leur build, devraient passer leur chemin. Avant de s'engager, vérifier la taille du binaire LlamaLib pour chaque plateforme cible et le temps de chargement du modèle sur le matériel le plus faible que vous comptez supporter.
Notes de la communauté