OllamaSharp: .NET-Bindings für die Ollama-API, mit Microsofts Segen

Welche Lücke OllamaSharp schließt und für wen

Ollama selbst ist ein Dienst, der über HTTP auf localhost oder einem entfernten Rechner läuft. Aus .NET heraus bedeutet das ohne Hilfsbibliothek: HttpClient aufsetzen, JSON-Ressourcen serialisieren, Streaming-Antworten zeilenweise zerlegen, Fehlerfälle pro Endpunkt behandeln. OllamaSharp nimmt diese Arbeit ab und bildet laut README jeden Endpunkt der Ollama-API als awaitable Methode ab. Die Zielgruppe sind damit .NET-Entwickler, die ein lokales Modell in eine bestehende Anwendung einbinden wollen, ohne den HTTP-Layer selbst zu schreiben. Der Anspruch der Bibliothek ist ausdrücklich Breite, nicht Minimalismus: Chats, Embeddings, Modellauflistung, pull, push, copy, delete, show und embed gehören zum Umfang. Wer nur einen einzelnen Textdurchlauf gegen ein Modell schicken will, trägt hier mehr Oberfläche mit, als die Aufgabe verlangt.

Der Client als dünne Schicht über dem HTTP-Endpunkt

Das zentrale Objekt ist OllamaApiClient. Der Konstruktor nimmt eine Uri entgegen, im Beispiel http://localhost:11434, dazu optional einen Modellnamen. Der ausgewählte Modellname wird als Eigenschaft SelectedModel gespeichert und gilt für die folgenden Operationen. Diese Schicht ist bewusst dünn: Methoden wie ListLocalModelsAsync oder PullModelAsync entsprechen direkt den HTTP-Aufrufen, und wer die API von Ollama kennt, erkennt sie ohne Umweg wieder. Streaming ist kein Sonderfall, sondern die Grundform. GenerateAsync liefert ein IAsyncEnumerable, PullModelAsync ebenso, und jeder Zwischenstand lässt sich sofort verarbeiten. Ein Detail, das in der Praxis zählt: PullModelAsync gibt Statusobjekte mit Percent und Status zurück, sodass ein Fortschrittsbalken ohne zusätzliche Verdrahtung möglich ist. Die Chat-Klasse setzt darüber eine Zustandsschicht: Sie verfolgt laut README die vollständige Nachrichtenhistorie inklusive Tool-Aufrufen und deren Ergebnissen über mehrere Runden und stellt sie über die Eigenschaft Messages bereit.

Einbindung in Microsoft.Extensions.AI als eigentliche Designentscheidung

Der interessanteste Teil des Projekts ist nicht die Endpunktabdeckung, sondern die Rolle als Microsoft.Extensions.AI-Implementierung. OllamaApiClient implementiert IChatClient für die Inferenz und IEmbeddingGenerator<string, Embedding<float>> für Embeddings. Wer den Client als IChatClient verwendet, kann ihn in einer Fabrikmethode gegen einen OpenAIChatClient austauschen, ohne den aufrufenden Code anzufassen. Das ist der Punkt, an dem sich die Bibliothek von einem reinen API-Wrapper unterscheidet. Die Kehrseite: Man wählt zwischen zwei Oberflächen. Die IOllamaApiClient-Sicht bietet alles, was Ollama kann, etwa Modellverwaltung und Fortschrittsmeldungen. Die IChatClient-Sicht bietet Portabilität, aber nur den gemeinsamen Nenner der Anbieter. Diese Entscheidung fällt man sinnvollerweise einmal am Anfang, weil sie die Konstruktorüberladung und die verfügbaren Methoden festlegt.

Erste Schritte: Konstruktor, Streaming, Chat-Schleife

Die Einrichtung besteht aus zwei Zeilen. Zuerst wird die Adresse des Ollama-Dienstes als Uri angelegt und an den Konstruktor übergeben, danach wird SelectedModel auf einen vorhandenen Modellnamen gesetzt. Ein Aufruf von ListLocalModelsAsync zeigt, welche Modelle lokal bereitstehen. Für einen einzelnen, kontextfreien Durchlauf ist GenerateAsync gedacht, das auf den Endpunkt /api/generate abbildet; das README nennt es ausdrücklich für Single-Turn-Aufgaben ohne Kontext. Für Dialoge ist die Chat-Klasse der empfohlene Weg, weil sie die Historie selbst fortschreibt. Das Muster ist eine Schleife, die Eingaben liest und die Antwort über SendAsync tokenweise ausgibt. Für Umgebungen mit Native AOT gibt es einen eigenen Pfad: Statt der Standard-Serialisierung wird ein JsonSerializerContext mit den eigenen Typen über das JsonSerializable-Attribut deklariert und über die statische Fabrikmethode an den Konstruktor übergeben. Ohne diesen Schritt greift die reflektionsbasierte Serialisierung, die unter AOT nicht trägt. Für Cloud-Modelle, im README als Ollama Turbo bezeichnet, wird ein HttpClient mit BaseAddress konfiguriert und der API-Schlüssel als DefaultRequestHeaders-Eintrag hinterlegt.

Werkzeuge, Bilder, Denkmodus: was die Chat-Klasse zusätzlich trägt

Die Tool-Unterstützung ist der Teil, der über eine HTTP-Hülle deutlich hinausgeht. Das README spricht von einer Tool-Engine mit Source Generators und verweist auf einen eigenen Dokumentationsabschnitt. Source Generators bedeuten, dass ein Teil des Aufrufcodes zur Kompilierzeit entsteht statt zur Laufzeit über Reflektion, was sich mit dem Native-AOT-Pfad sauber verbindet. Daneben nennt das README Vision-Modelle für Bilder, strukturierte JSON-Ausgabe und einen Denkmodus für Reasoning-Modelle. Der gemeinsame Nenner dieser Funktionen ist, dass sie in der Chat-Klasse sitzen und nicht in den freien Methoden, weil sie den Nachrichtenverlauf betreffen. Wer diese Fähigkeiten braucht, sollte also von vornherein die Chat-Klasse verwenden und nicht nachträglich von GenerateAsync umsteigen, weil sonst die Historienverwaltung selbst gebaut werden muss.

Wo die Bibliothek nicht passt

Zwei Grenzen sind aus dem Material direkt ableitbar. Erstens ist OllamaSharp ein Client, kein Server und keine Modelllaufzeit. Ohne erreichbaren Ollama-Dienst tut die Bibliothek nichts; sie bringt Ollama nicht mit. Zweitens hängt die API-Abdeckung an einem Upstream, der sich bewegt. Die Release-Liste zeigt drei Veröffentlichungen innerhalb eines Tages, was auf eine enge Taktung an der Ollama-API hindeutet. Für Teams mit festen Freigabefenstern bedeutet das, dass eine aktualisierte Ollama-Installation und eine ältere Paketversion auseinanderlaufen können. Wer gegen einen entfernten, OpenAI-kompatiblen Endpunkt arbeitet und keine Modellverwaltung, kein Pull mit Fortschritt und keine lokalen Modelle braucht, ist mit einem schlankeren Client besser bedient, weil er dann die Hälfte der Oberfläche nur als Abhängigkeit mitführt. Das Material enthält keine Angaben zu Fehlerbehandlung, Timeouts oder Wiederholungsversuchen, sodass sich dazu keine Aussage treffen lässt.

Alternative: Microsoft.Extensions.AI als Abstraktion statt als Bindung

Die naheliegende Alternative ist der umgekehrte Weg: Statt OllamaSharp direkt zu verwenden, programmiert man gegen IChatClient aus Microsoft.Extensions.AI und wählt den Anbieter erst bei der Erzeugung. Der Unterschied liegt nicht in der Funktion, sondern in der Kopplung. Mit OllamaSharp als IOllamaApiClient bekommt man die vollständige Ollama-Oberfläche, inklusive Modellverwaltung und Fortschrittsmeldungen beim Pull, ist aber an Ollama gebunden. Mit IChatClient bekommt man eine austauschbare Schnittstelle, verliert aber alles, was Ollama-spezifisch ist, weil die Abstraktion nur den gemeinsamen Nenner abbildet. Das README zeigt die Fabrikmethode, die je nach Argument entweder einen OllamaApiClient oder einen OpenAIChatClient zurückgibt. Diese Entscheidung ist keine Geschmacksfrage, sondern eine Architekturfrage: Wer Modellverwaltung in der Anwendung braucht, kann die Abstraktion nicht als alleinige Schnittstelle verwenden.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Das Projekt steht unter MIT-Lizenz. Das ist eine permissive Lizenz: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Lizenztext und der Urheberrechtshinweis beibehalten werden. Das README enthält keine zusätzlichen Bedingungen, Hinweise auf Contributor-Lizenzvereinbarungen oder Angaben zu Markenrechten Dritter; das ist keine Rechtsberatung, sondern nur die Beschreibung dessen, was im Material steht. Wartungskosten entstehen weniger durch die Lizenz als durch die Versionskopplung. Wer die Bibliothek einsetzt, übernimmt die Aufgabe, Paketversion und Ollama-Installation im Gleichschritt zu halten, weil neue Endpunkte und Parameter auf der Serverseite ein Update des Clients erforderlich machen können. Vor dem ersten Einsatz ist zu klären, welche Ollama-Version im Zielsystem läuft, ob Native AOT zum Einsatz kommt und damit ein eigener JsonSerializerContext nötig wird, und ob der Code gegen IOllamaApiClient oder gegen IChatClient geschrieben wird. Die letzte Frage bestimmt die Konstruktorüberladung und den Umfang der verfügbaren Methoden.

Redaktionelles Fazit

Wer Ollama aus .NET anspricht und dabei alle Endpunkte inklusive pull, push, create und embed braucht, ist hier richtig; wer nur einen einzelnen Chat-Aufruf gegen einen entfernten OpenAI-kompatiblen Endpunkt braucht, fährt mit einem schlankeren Client günstiger. Vor dem Einstieg sollte man prüfen, welchen Stand der eigenen Ollama-Installation die gewählte Paketversion erwartet, und ob man die Abstraktion über Microsoft.Extensions.AI oder die volle IOllamaApiClient-Oberfläche benötigt, weil das die Signatur des Konstruktors und die Menge der verfügbaren Methoden bestimmt.

Offizielle Quellen

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