LLamaSharp: LLaMA-Inferenz in .NET-Anwendungen über llama.cpp-Backends

Welches Problem LLamaSharp in .NET-Projekten löst

Wer in einer C#-Anwendung ein Sprachmodell lokal ausführen will, steht vor einer Sprachgrenze: Die Inferenz-Engines sind überwiegend in C++ oder Python geschrieben, die Anwendungslogik in .NET. LLamaSharp schließt diese Lücke, indem es llama.cpp als native Bibliothek einbindet und darüber eine C#-API legt. Die README beschreibt die Bibliothek als plattformübergreifend und nennt als Ziel, LLaMA-Modelle und andere Modelle auf dem lokalen Gerät auszuführen, mit effizienter Inferenz auf CPU und GPU. Der Nutzerkreis sind damit .NET-Entwickler, die keine Python-Laufzeit mitschleppen und keine eigene C++-Anbindung schreiben wollen. Dazu passt die Liste der Integrationen im Repository: BotSharp, eine Langchain-Portierung und MaIN.NET werden als eigene Projekte geführt, dazu Beispiele für ASP.NET, Blazor, WPF und Unity. Das sind durchweg Umgebungen, in denen C# bereits die tragende Sprache ist. Der Nutzen liegt also weniger in neuer Inferenztechnik als in der Anbindung: llama.cpp bleibt die Engine, LLamaSharp ist die Fassade davor.

Native Backends als eigentliche Abhängigkeit

LLamaSharp selbst enthält keine Inferenzlogik. Die README formuliert es so, dass die Bibliothek für hohe Leistung mit nativen Bibliotheken interagiert, die aus C++ kompiliert wurden, und nennt diese Backends. Diese Backends werden als separate NuGet-Pakete verteilt: LLamaSharp.Backend.Cpu für reines CPU auf Windows, Linux und Mac sowie Metal auf dem Mac, LLamaSharp.Backend.Cuda11 und LLamaSharp.Backend.Cuda12 für Windows und Linux, und LLamaSharp.Backend.Vulkan für Windows und Linux. Der Datenfluss ist damit zweistufig. Im C#-Prozess laufen die höheren APIs, etwa Chat-Sitzungen und RAG-Unterstützung, während die eigentliche Berechnung im nativen Code stattfindet, der über P/Invoke gebunden wird. Diese Trennung erklärt zwei Eigenschaften, die in der Praxis wichtig sind. Erstens muss das Backend-Paket zur Zielplattform passen, sonst lädt die native Bibliothek nicht. Zweitens bestimmt das Backend-Paket, welche llama.cpp-Version tatsächlich läuft, nicht die LLamaSharp-Version allein. Das Repository enthält deshalb eine Tabelle, die LLamaSharp-Versionen auf llama.cpp-Versionen abbildet. Wer diese Zuordnung ignoriert, kann eine API verwenden, die im installierten Backend noch nicht existiert.

Installation und Modellvorbereitung in der Praxis

Die Einrichtung besteht laut README aus zwei Schritten. Zuerst das Kernpaket, im Beispiel über die Paket-Manager-Konsole: Install-Package LLamaSharp. Danach mindestens ein Backend-Paket, abhängig von der Hardware. Der README betont, dass kein C++ kompiliert werden muss, solange ein veröffentlichtes Backend zum Gerät passt. Fehlt eines, verweist das Projekt auf ein Issue und auf einen Contributing Guide, um selbst zu kompilieren. Das ist ein realer Bruch im Versprechen der einfachen Installation: Auf ungewöhnlicher Hardware oder älteren CUDA-Versionen endet der bequeme Weg. Beim Modell ist das Format entscheidend. LLamaSharp verwendet GGUF-Dateien, die aus PyTorch- (.pth) oder Huggingface- (.bin) Formaten konvertiert werden. Zwei Wege werden genannt: eine bereits konvertierte Datei auf Huggingface suchen, oder selbst mit den Python-Skripten aus der llama.cpp-Anleitung konvertieren. Der README gibt hier einen konkreten Hinweis, der leicht überlesen wird: Beim Herunterladen soll man auf das Veröffentlichungsdatum achten, weil ältere Dateien nur mit älteren LLamaSharp-Versionen funktionieren. Empfohlen werden quantisierte Modelle statt fp16, weil sie den Speicherbedarf deutlich senken und die Generierungsqualität nur leicht beeinflussen. Der Beispielcode im README beginnt mit using LLama, using LLama.Common und using LLama.Sampling, gefolgt von einem modelPath, der auf die GGUF-Datei zeigt.

Wo die Bibliothek an ihre Grenzen stößt

Die wichtigste Einschränkung steckt in der Modellverwaltung. LLamaSharp lädt ein Modell, das der Entwickler bereitstellt. Es gibt in der README keine Aussage über automatisches Herunterladen, Zwischenspeichern oder Versionsauflösung von Modellen. Wer mehrere Modelle parallel oder pro Mandant betreiben will, muss diese Verwaltung selbst bauen, inklusive Speicherverwaltung für den nativen Kontext. Der zweite Punkt ist die Versionskopplung. Weil das Backend die llama.cpp-Version mitbringt, ist ein Upgrade von LLamaSharp nicht unabhängig vom Modell und von der Hardware. Ein neues LLamaSharp-Release kann ein neues Backend-Paket erfordern, und ein neues Backend kann ein älteres GGUF-Modell ausschließen. Die README macht diese Kopplung mit der Versions-Mapping-Tabelle sichtbar, statt sie zu verstecken, aber sie bleibt eine Betriebslast. Drittens: Die README beschreibt keine Leistungsgarantien, keine Benchmarks und keine Angaben dazu, wie viele Token pro Sekunde auf welcher Hardware zu erwarten sind. Wer Kapazitätsplanung braucht, muss selbst messen. Und schließlich ist LLamaSharp kein Server. Das Repository verweist für einen Web-API-Betrieb auf ein externes Projekt, LLamaWorker, das als eigenes Repository geführt wird. Die Bibliothek ist eine Client-Bibliothek, kein Dienst.

Abgrenzung zu llama.cpp direkt und zu Python-Stacks

Die naheliegende Alternative ist llama.cpp ohne .NET-Hülle, also die Nutzung des C++-Projekts direkt oder über dessen mitgelieferten Server. Der Unterschied liegt nicht in der Inferenz, denn beide verwenden dieselbe Engine, sondern im Integrationsaufwand. Bei llama.cpp direkt schreibt man die Anbindung selbst oder betreibt einen separaten Prozess und spricht ihn über HTTP an. Das entkoppelt die Modellversion von der Anwendung, kostet aber einen zusätzlichen Dienst und eine Serialisierungsschicht. LLamaSharp bindet die native Bibliothek in den eigenen Prozess ein, was den Betrieb vereinfacht und die Latenz der Zwischenschicht vermeidet, dafür aber die native Bibliothek an die Laufzeitumgebung der Anwendung koppelt. Eine zweite Alternative sind Python-basierte Stacks, etwa die Kombination aus Transformers und einem Inferenzserver. Deren Vorteil ist die breitere Modellabdeckung und das reifere Ökosystem für Training und Feinabstimmung. Der Preis ist eine zusätzliche Laufzeitumgebung neben .NET. Für ein Team, das ohnehin C# schreibt und nur Inferenz auf einem bereits vorhandenen GGUF-Modell braucht, ist der Wechsel zu Python selten gerechtfertigt. Für ein Team, das Modelle feinabstimmen oder experimentelle Architekturen testen will, ist LLamaSharp das falsche Werkzeug, weil es auf das GGUF-Format und die von llama.cpp unterstützten Architekturen festgelegt ist.

Wartung, Lizenz und Upgrade-Kosten

Das Repository ist nicht archiviert, der letzte Push liegt laut Metadaten bei September 2026, und die Release-Historie zeigt Versionen in kurzen Abständen: v0.26.0 im Februar 2026, v0.27.0 im April 2026, v0.29.0 im August 2026. Diese Kadenz bedeutet, dass die Versionsnummern schneller wandern als in vielen .NET-Bibliotheken. Wer LLamaSharp einsetzt, sollte die Versions-Mapping-Tabelle im Repository als Teil des Upgrades behandeln, nicht als Referenzdokument. Die Lizenz ist MIT, was die Einbindung in kommerzielle Anwendungen erlaubt und Modifikationen zulässt, solange der Lizenztext und der Urheberrechtshinweis beibehalten werden. Wichtig ist die Trennung: Die MIT-Lizenz gilt für LLamaSharp. Die Backend-Pakete enthalten kompilierten Code aus llama.cpp, und die Modelle selbst haben eigene Lizenzen, die je nach Quelle unterschiedlich ausfallen. Wer ein GGUF-Modell von Huggingface bezieht, muss dessen Lizenz separat prüfen. Das ist keine Rechtsberatung, aber der Hinweis gehört zur Planung, weil die Modelllizenz den Einsatz stärker einschränken kann als die Bibliothekslizenz. Die Upgrade-Kosten liegen damit weniger im Code als in der Abstimmung von drei Dingen: LLamaSharp-Version, Backend-Paket und GGUF-Datei.

Für wen sich der Einsatz lohnt und was zuerst zu prüfen ist

Der Fall, in dem LLamaSharp passt, ist eng umrissen: eine bestehende .NET-Anwendung, ein lokales oder On-Premise-Szenario, ein bereits konvertiertes GGUF-Modell und eine Hardware, für die ein Backend-Paket veröffentlicht ist. In dieser Konstellation erspart die Bibliothek die eigene C++-Anbindung und die Verwaltung eines separaten Inferenzprozesses. Der Fall, in dem sie nicht passt, ist ebenso klar: Wenn Modelle zentral verwaltet, versioniert und auf mehrere Instanzen verteilt werden sollen, fehlt dafür in der Bibliothek die Ebene. Wenn das Modell nicht als GGUF vorliegt und auch nicht konvertiert werden soll, ist der Aufwand vorgelagert. Und wenn Feinabstimmung Teil des Vorhabens ist, liegt die Arbeit ohnehin außerhalb dieses Projekts. Vor dem ersten Einsatz sind drei Dinge konkret zu prüfen. Erstens, ob für die Zielplattform ein Backend-Paket existiert, weil sonst der Contributing Guide und eine C++-Toolchain nötig werden. Zweitens, ob die gewählte GGUF-Datei zur LLamaSharp-Version passt, wofür die README ausdrücklich das Veröffentlichungsdatum der Modelldatei als Indikator nennt. Drittens, ob das Modell quantisiert vorliegt, weil die README quantisierte Varianten gegenüber fp16 empfiehlt. Wer diese drei Punkte vor dem Prototyp klärt, vermeidet die häufigste Fehlerquelle: eine Anwendung, die kompiliert, aber das Modell nicht lädt.

Redaktionelles Fazit

LLamaSharp eignet sich für .NET-Teams, die ein bereits vorhandenes GGUF-Modell lokal in eine C#-Anwendung einbetten wollen, ohne C++ selbst zu kompilieren. Wer eine reine Python-Umgebung, einen Server mit mehreren Mandanten oder automatische Modellverwaltung braucht, ist hier falsch. Vor dem ersten produktiven Einsatz sollte man prüfen, ob für die Zielplattform ein passendes Backend-Paket existiert, welche LLamaSharp-Version zur gewählten GGUF-Datei passt und ob das Modell quantisiert vorliegt, weil das laut README den Speicherbedarf deutlich senkt.

Offizielle Quellen

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