LLamaSharp : exécuter un LLM dans une application .NET sans quitter le processus

Le problème concret : pas de pont .NET vers llama.cpp

llama.cpp est écrit en C++ et expose une API en C. Une application C# ne peut pas l'appeler directement sans écrire une couche d'interopérabilité P/Invoke, gérer le marshaling des chaînes, les pointeurs de contexte et le cycle de vie des ressources non managées. LLamaSharp fournit cette couche. Le README le formule ainsi : la bibliothèque est « based on llama.cpp », et l'inférence est présentée comme efficace sur CPU comme sur GPU. Le public visé est donc l'équipe qui développe une application .NET (console, WPF, Blazor, ASP.NET, Unity via un projet tiers) et qui veut exécuter un modèle sur la machine de l'utilisateur, sans dépendre d'une API distante. Les topics du dépôt ciblent explicitement le chatbot, le multi-modal avec LLaVA, et l'intégration à Semantic Kernel. Une intégration LangChain est également listée, développée dans un dépôt séparé.

Deux paquets par projet : LLamaSharp et un backend natif

L'architecture repose sur une séparation nette. Le paquet LLamaSharp contient le code managé, c'est-à-dire les API de haut niveau, la gestion de session, l'échantillonnage et le support RAG mentionné en introduction. Les paquets backend contiennent les binaires natifs compilés depuis C++. Le README insiste sur ce point : « You don't need to compile any c++, just install the backend packages. » Cette séparation a une conséquence directe sur le déploiement. Vous ne référencez pas un paquet unique, mais au minimum deux, et le second dépend du matériel cible. Les backends publiés couvrent Windows, Linux et Mac, avec les variantes suivantes : LLamaSharp.Backend.Cpu pour le CPU pur sur les trois systèmes, avec en plus le support Metal sur Mac ; LLamaSharp.Backend.Cuda11 et LLamaSharp.Backend.Cuda12 pour Windows et Linux ; LLamaSharp.Backend.Vulkan pour Windows et Linux. Le README précise que si aucun backend publié ne correspond à votre appareil, il faut ouvrir une issue, ou compiler soi-même en suivant le guide de contribution. C'est un point de friction réel : la matrice de compatibilité entre système, architecture et accélérateur n'est pas exhaustive, et elle est maintenue à la main par les contributeurs.

Le format GGUF comme point d'entrée obligatoire

LLamaSharp ne charge pas les poids au format PyTorch (.pth) ni au format Hugging Face (.bin). Le README est catégorique : la bibliothèque utilise un fichier au format GGUF, convertible depuis ces deux formats. Deux voies s'offrent à vous. La première consiste à chercher sur Hugging Face le nom du modèle suivi de « gguf ». Le README avertit explicitement sur ce point : il faut faire attention à la date de publication des fichiers, car certains fichiers anciens ne fonctionnent qu'avec des versions anciennes de LLamaSharp. La seconde voie est la conversion locale via les scripts Python documentés dans la section « Prepare and quantize » du README de llama.cpp. Le README recommande généralement de télécharger des modèles quantifiés plutôt que du fp16, au motif que la quantification réduit nettement la mémoire nécessaire avec un impact limité sur la qualité de génération. Cette recommandation n'est pas neutre : elle déplace le choix de la quantification vers l'utilisateur, qui doit arbitrer entre taille du fichier et fidélité de sortie sans que la bibliothèque ne fournisse d'outil de mesure.

Mise en route : les commandes telles quelles

L'installation passe par NuGet. Le README donne la commande suivante : `PM> Install-Package LLamaSharp`. Il faut ensuite ajouter un backend, par exemple `Install-Package LLamaSharp.Backend.Cpu` pour un usage CPU, ou la variante CUDA 12 si vous disposez d'un GPU NVIDIA. Côté code, l'exemple de session de chat du README commence par trois directives `using` : `using LLama;`, `using LLama.Common;` et `using LLama.Sampling;`. La variable `modelPath` est déclarée en `string` et le README invite à remplacer la valeur par le chemin de votre fichier. Le fait que l'échantillonnage dispose de son propre espace de noms, `LLama.Sampling`, indique que la stratégie de décodage est configurable séparément de la session. La documentation complète, l'API reference et un guide de démarrage rapide sont hébergés sur le site du projet, et un tutoriel dédié existe pour `NativeLibraryConfig`, la classe qui contrôle le chargement de la bibliothèque native. Ce dernier point est celui qui mérite le plus d'attention : quand le backend ne se charge pas, c'est là que se règle le problème.

Le suivi des versions de llama.cpp est le vrai coût

Le README contient une section intitulée « Map of LLamaSharp and llama.cpp versions ». Sa seule existence signale la contrainte principale du projet : LLamaSharp n'est pas un moteur d'inférence autonome, c'est une enveloppe autour d'un projet C++ qui évolue vite, y compris dans ses formats et ses API. Un fichier GGUF produit pour une version récente de llama.cpp peut ne pas se charger dans un LLamaSharp plus ancien, et inversement. Les publications récentes du dépôt (v0.26.0, v0.27.0, v0.29.0) montrent un rythme soutenu, mais ce rythme est dicté par l'amont, pas par les besoins des utilisateurs .NET. Concrètement, une mise à jour de LLamaSharp peut vous obliger à re-télécharger ou re-convertir vos modèles, et une mise à jour de vos modèles peut vous obliger à monter de version côté paquet. La licence MIT du projet est permissive et n'impose pas de contrainte sur votre code propriétaire, mais elle ne dit rien des binaires natifs embarqués dans les paquets backend, dont les conditions dépendent des composants compilés. Ce n'est pas un avis juridique : faites vérifier la chaîne de licences des backends que vous distribuez si vous les embarquez dans un produit.

Quand LLamaSharp n'est pas le bon outil

Le cas d'usage mal servi est celui du service partagé. Si plusieurs applications, écrites dans des langages différents, doivent interroger le même modèle sur une même machine, embarquer LLamaSharp dans chacune d'elles duplique les binaires natifs et la mémoire du modèle. Un serveur d'inférence exposant une API HTTP serait plus adapté, et le README liste d'ailleurs LLamaWorker, un projet tiers qui présente une API web de type OpenAI avec support du function calling. Deuxième cas défavorable : le matériel non couvert. Le README renvoie à l'ouverture d'une issue si aucun backend publié ne correspond, ce qui signifie que vous dépendez de la bonne volonté des mainteneurs ou de votre capacité à compiler du C++. Troisième cas : un besoin de modèles non supportés par llama.cpp. LLamaSharp ne peut charger que ce que llama.cpp sait charger, la couche C# n'élargit pas le périmètre. Enfin, si votre contrainte principale est la latence sur GPU haut de gamme avec des fonctionnalités de serving avancées (batching continu, pagination du cache KV exposée à l'appelant), un binding de bibliothèque n'offre pas le même niveau de contrôle qu'un serveur dédié.

Alternatives et différence d'approche

Pour rester dans l'écosystème .NET, Semantic Kernel est une alternative de nature différente : c'est un framework d'orchestration qui abstrait plusieurs fournisseurs de modèles, locaux ou distants, avec des concepts de plugins et de fonctions. LLamaSharp, lui, est un connecteur bas niveau vers un moteur précis. Le README mentionne Semantic Kernel parmi les topics et liste des intégrations (BotSharp, LangChain, MaIN.NET) développées dans leurs propres dépôts, ce qui suggère une complémentarité plutôt qu'une concurrence : Semantic Kernel pour la composition, LLamaSharp pour l'exécution locale. Si votre besoin est d'écrire du code qui parle directement à un modèle sans couche d'abstraction, LLamaSharp est plus direct. Si votre besoin est de changer de fournisseur sans réécrire vos appels, la couche d'orchestration apporte quelque chose que LLamaSharp ne cherche pas à apporter. Le choix se fait donc sur le degré d'abstraction souhaité, pas sur une supériorité de l'un sur l'autre.

Conclusion éditoriale

LLamaSharp convient aux équipes .NET qui veulent une inférence locale sans service externe et qui acceptent d'aligner la version du paquet sur celle de llama.cpp qu'il embarque. Il ne convient pas si vous avez besoin d'un serveur d'inférence partagé entre plusieurs langages, ou si votre matériel n'est couvert par aucun backend publié. Avant de vous engager, vérifiez la table de correspondance entre versions LLamaSharp et llama.cpp dans la documentation, puis contrôlez que le fichier GGUF que vous comptez utiliser a été publié à une date compatible avec la version du paquet que vous installez.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. SciSharp/LLamaSharp on GitHub