Ollama 0.40.11 Praxisbeispiel: Lokale LLMs unter Windows ausführen

Ollama 0.40.11 bietet Windows-Nutzern eine Desktop-Chat-Anwendung und eine lokale Modelllaufzeitumgebung für andere Software. Ollama hat seine ursprüngliche Kommandozeilenschnittstelle erweitert und bietet nun eine durchsuchbare Modellauswahl, Bildanhänge und Links zu Codierungstools. Einige für Tests benötigte Steuerelemente sind weiterhin in PowerShell und Modellkonfigurationsdateien implementiert.

Wir installierten Ollama auf unserem HP Z4 Rack G5 mit Windows 11 Pro für Workstations, 128 GB RAM und einer NVIDIA RTX 5000 Ada Generation GPU. Mit unseren vorhandenen Jan V3.5 4B und Jan V2 VL High GGUFs testeten wir die Generierungsgeschwindigkeit, den Chat, die Bildverarbeitung, die Online-Suche und die lokale API. Ollama führte unsere lokalen Modelle problemlos aus, allerdings mussten wir für den Import der GGUFs und die Erfassung der Leistungsdaten den Desktop-Chat verlassen. Es ist die dritte Anwendung unserer lokalen LLM-Serie nach Jan und Open WebUI , und die Ergebnisse fließen in unsere Seite „Beste lokale LLM-Tools“ ein.

Prüfsystem

Komponente	Konfiguration
Betriebssystem	Windows 11 Pro für Arbeitsstationen
CPU	Intel Xeon w5-2465X, 16 Kerne
Memory	128GB
GPU	NVIDIA RTX 5000 Ada-Generation
VRAM	32 GB (32,760 MiB gemeldet)
NVIDIA-Treiber	597.06
CUDA-Kompatibilität	13.2 (gemeldet von nvidia-smi)
Ollama	0.40.11
Inferenzlaufzeit	Ollama llama.cpp Runner (Build-Nummer nicht aufgezeichnet)

Ollama installieren und erste Schritte

Die Installation von Ollama auf unserer Windows-Workstation war eine willkommene Abwechslung zu den Einrichtungsproblemen, die wir bei anderen Anwendungen dieser Reihe hatten. Wir luden den Standard-Windows-Installer herunter, starteten die Anwendung und mussten weder eine separate Inferenz-Runtime installieren noch CUDA-Pakete suchen. Ein kurzer PowerShell-Check bestätigte, dass Ollama 0.40.11 lief und der lokale Dienst bereits unter http://127.0.0.1:11434 erreichbar war.

Nach dem Begrüßungsbildschirm öffnete sich Ollama mit einer vertrauten Chat-Oberfläche. In der linken Seitenleiste waren die letzten Unterhaltungen, Apps und Einstellungen zu finden. Das Nachrichtenfeld enthielt die Schaltfläche für Anhänge, die Websuche und die Modellauswahl. Wir konnten sofort mit unseren importierten lokalen Modellen chatten, ohne ein Konto erstellen zu müssen. Als wir später im Test die Websuche aktivieren wollten, wurden wir jedoch zur Anmeldung aufgefordert.

Modelle durchsuchen und hinzufügen

Die Modellauswahl bei Ollama ist recht einfach gehalten: Über ein Dropdown-Menü werden sowohl installierte als auch zum Download verfügbare Modelle angezeigt. Neben unseren importierten Jan-Modellen und Qwen3-VL sahen wir auch verschiedene Cloud-basierte Optionen, die durch ein kleines Wolkensymbol gekennzeichnet waren. Es gibt außerdem ein Suchfeld für weitere Modelle. Allerdings hätten wir uns hier mehr Informationen gewünscht, beispielsweise zu Modellgrößen, Quantisierung und Hardwareanforderungen. Jan stellt diese Details in seinem Modell-Hub bereit, während Ollama die meisten dieser Informationen nicht in der Haupt-Chat-Oberfläche anzeigt.

Die Integration unserer beiden Benchmark-Modelle in Ollama gestaltete sich aufwendiger, da wir dieselben GGUF-Dateien wie in unseren vorherigen Tests verwenden wollten, um die Leistungstests so vergleichbar wie möglich zu halten. Obwohl Ollama das direkte Herunterladen von Modellen über die Desktop-Oberfläche ermöglicht, fanden wir keine Option zum Importieren bereits auf der Workstation gespeicherter GGUF-Dateien. Daher mussten wir PowerShell verwenden und für jedes Modell eine Modelldatei erstellen, die auf die vorhandene GGUF-Datei verwies und die in unseren früheren Tests verwendeten Abtastparameter enthielt. Anschließend verwendeten wir die ollama create Befehl zum Hinzufügen der Modelle zur Ollama-Modellbibliothek.

Beide Importe funktionierten problemlos, wobei Jan V3.5 als angezeigt wurde. jan-v35-sr und Jan V2 VL High as jan-v2-srWir haben außerdem Qwen3-VL 4B direkt über Ollama für einen separaten Bildanalysetest heruntergeladen.

Nach dem Import der Modelle überprüften wir, wie Ollama sie identifizierte und ob ihre Einstellungen korrekt übernommen wurden. Jan V2 VL High wurde als Qwen3-VL-Modell mit 8.2 Milliarden Parametern und Q4_K_M-Quantisierung erkannt, was unserer Originaldatei entsprach. Jan V3.5 bildete die Ausnahme, da das importierte GGUF-Modell den Namen trug. Jan-v3.5-4B-Q4_K_XL.ggufOllama meldete jedoch die Quantisierung als Q4_K_M. Wir haben die Originaldatei unverändert gelassen; der wahrscheinliche Grund dafür ist, dass Q4_K_XL die dynamische Quantisierung von Unsloth ist, die größtenteils aus Q4_K_M-Ebenen besteht, und die Metadaten der Datei diesen Basistyp angeben.

Modelleinstellungen und GPU-Nutzung

Die Einstellungsseite von Ollama umfasst Cloud-Zugriff, automatische Updates, Netzwerkzugriff, einen Pfad zum Modellspeicher und einen Schieberegler für die Kontextlänge, der bei unserer ersten Überprüfung 32 Token anzeigte. Unsere Leistungstests forderten explizit 8,192 Token über die API an, daher basieren die unten stehenden Benchmark-Ergebnisse auf diesem Kontext und nicht auf dem Standardwert der Desktop-Version.

Da Ollama über seine Desktop-Oberfläche nicht denselben Umfang an Modellkonfigurationsmöglichkeiten wie Jan bietet, haben wir die meisten Anpassungen über Modelldateien und API-Anfragen vorgenommen. Um vergleichbare Benchmarks zu gewährleisten, verwendeten wir dieselben Einstellungen wie in unseren vorherigen Tests: Temperatur 0.8, Top K 40, Top P 0.95, Min P 0.05 und eine Wiederholungsstrafe von 1.0. Wir haben außerdem eine Batchgröße von 2,048 angefordert, konnten aber nicht unabhängig überprüfen, ob Ollama diese während der Generierung angewendet hat.

Die GPU-Konfiguration war ebenfalls anders, da es keine Desktop-Einstellung gab, die den 100 GPU-Ebenen entsprach, die wir im Januar verwendet hatten. Ollama übernahm das GPU-Offloading automatisch, und eine kurze Überprüfung mit ollama ps bestätigte, dass beide importierten Modelle vollständig mit der RTX 5000 Ada liefen.

Wir haben diesen Bericht mit den Messwerten von NVIDIA verglichen. Jan V3.5 erhöhte die VRAM-Zuweisung nach dem Laden um mehrere Gigabyte, und eine Live-Messung erreichte während der Generierung eine GPU-Auslastung von 93 Prozent. Auch Jan V2 meldete eine vollständige GPU-Auslastung und zeigte in unserem Diagnoselauf 96 Prozent. Zumindest auf dieser Workstation war es nicht nötig, eine separate CUDA-Variante oder GPU-Layer-Konfiguration zu verwenden, um eine beschleunigte Generierung zu erreichen.

Lokale Erzeugungsleistung

Für die Generationstests verwendeten wir dieselbe Aufforderung wie in unserem veröffentlichten Praxistest vom Januar : „Erklären Sie RAID 5 und RAID 6 jemandem, der sein erstes NAS zusammenbaut. Beschreiben Sie die wichtigsten Vor- und Nachteile beider Varianten in etwa 400 Wörtern.“ Wir deaktivierten die Websuche, legten den Kontext auf 8,192 Token fest und fügten jeder API-Anfrage nur diese eine Benutzernachricht hinzu. Wir verwarfen eine Aufwärmantwort pro Modell und erfassten anschließend drei Messläufe.

Beide Modelle absolvierten alle drei Testläufe fehlerfrei, und die GPU-Auslastung blieb während der gesamten Testphase hoch. Ollama benötigte keine zusätzliche CUDA-Konfiguration oder manuelle Anpassungen der GPU-Ebene, um beide Modelle mit voller GPU-Beschleunigung auszuführen. Dies war bei Open WebUI nicht der Fall, da wir dort die CUDA-Laufzeit-DLLs manuell hinzufügen mussten.

Modell	Quantisierung	Ausgabetoken	Dekodierungsgeschwindigkeit	GPU-Speicher
Jan V3.5 4B	Q4_K_XL-Datei*	529	145.48 Zeichen/s	5,082 MiB
Jan V2 VL High	Q4_K_M	1,696	92.87 Zeichen/s	7,124 MiB

Hinweis: Die Werte für Ausgabetokenanzahl, Dekodierungsgeschwindigkeit und GPU-Speicherverbrauch sind Medianwerte aus drei Messläufen nach einem verworfenen Aufwärmlauf. Der GPU-Speicherverbrauch entspricht dem Median der maximalen GPU-Speichernutzung während jedes Messlaufs.

*Der Dateiname Jan V3.5 GGUF kennzeichnet Q4_K_XL, während die Modellinformationen von Ollama Q4_K_M angeben; siehe die obigen Importhinweise.

Jan V3.5 erreichte in den Messläufen 145.48, 145.73 und 145.44 Token/Sek., während Jan V2 92.87, 92.22 und 92.97 Token/Sek. verzeichnete. Die Werte beider Datensätze blieben von Lauf zu Lauf nahezu konstant, und die gemessenen Spitzenwerte der GPU-Speicherauslastung blieben innerhalb der jeweiligen Datensätze unverändert. Jan V2 erzeugte deutlich mehr gemeldete Ausgabetoken, die offenbar auch logische Schlussfolgerungen umfassten. Daher lassen sich die Gesamtzahlen nicht direkt mit der sichtbaren Antwortlänge vergleichen.

Auf derselben Workstation und mit denselben Modelldateien erzielten wir die bisher schnellsten Ergebnisse dieser Reihe. Jan V3.5 dekodierte 18 Prozent schneller als Jan selbst (123 Token/Sek.) und 26 Prozent schneller als Open WebUI Desktop (115.32 Token/Sek.). Jan V2 lag 13 Prozent vor Jan (82 Token/Sek.) und 24 Prozent vor Open WebUI (75.06 Token/Sek.). Jede Anwendung verwendet ihren eigenen llama.cpp-Build und verwaltet die GPU-Auslastung auf ihre eigene Weise. Der Vergleich spiegelt daher das gesamte Paket wider, nicht nur das Modell.

Wir haben keine Medianwerte für die Verarbeitung von Anfragen veröffentlicht, da wiederholte Anfragen zu sehr kurzen Antwortzeiten führten, die möglicherweise durch Caching beeinflusst wurden. Auch die Laufzeiteinstellungen können nicht in jeder Hinsicht identisch sein: Jan stellte GPU-Layer direkt bereit, während Ollama die Auslagerung automatisch verwaltete.

Nutzung von Ollama für den lokalen Chat

Nach der Installation der Modelle wählten wir im Dropdown-Menü Jan V3.5 oder Jan V2 aus und gaben die RAID-Eingabeaufforderung ein. Die Antworten wurden mit Überschriften und Listen angezeigt, während die letzten Konversationen in der Seitenleiste verblieben. Da Ollama weder die Generierungsrate noch die Tokenanzahl unter den Antworten anzeigte, ermittelten wir diese Werte über die API.

Die Verwaltung von Konversationen in Ollama war recht einfach: Ein Rechtsklick auf eine frühere Konversation öffnete Optionen zum Umbenennen oder Löschen, und unter „Weitere Tools“ fand sich die Option „Teilen“. Wir konnten auch bereits gesendete Nachrichten bearbeiten, allerdings gab es für die Antworten des Modells nicht so viele Optionen. Die einzige Schaltfläche, die wir fanden, war „Kopieren“, die unter jeder Antwort sichtbar bleibt, selbst wenn man nicht mit der Maus darüberfährt. Wir konnten keine Möglichkeit finden, eine Antwort neu zu generieren oder ihre Generierungsstatistik im Chatfenster einzusehen, zumindest nicht in der von uns getesteten Version.

Ollama bietet auch einen Bereich mit Apps und Programmierassistenten, darunter Codex CLI, Claude Code, OpenCode und Cline. Wir wollten die Funktionsweise dieser Integrationen testen und klickten daher auf Codex CLI, um die Einrichtung zu überprüfen. Ollama öffnete kein Konfigurationsfenster, sondern kopierte einen Startbefehl in die Zwischenablage und forderte uns auf, diesen in ein Terminal einzufügen. Wir haben die Installation nicht vollständig abgeschlossen und Codex nicht ausgeführt, aber es gab uns einen besseren Einblick, wie Ollama lokale Modelle mit externen Anwendungen verbindet.

Websuche

Ollama platziert im Chat neben der Anhangsauswahl eine Globus-Schaltfläche. Beim Anklicken dieser Schaltfläche erschien jedoch die Meldung, dass für die Websuche ein Ollama-Konto erforderlich ist. Nach der Registrierung für ein kostenloses Konto und der Aktivierung der Funktion verwendeten wir unsere bestehende Testfrage, die nach der aktuellsten stabilen Open WebUI-Version vom 15. Oktober 2026 mit Quellenangabe fragte.

Beim Testen der Web-Suchfunktion von Ollama stießen wir auf ein weiteres Problem: Die Anwendung versuchte, Ergebnisse abzurufen, gab aber stattdessen die Fehlermeldung „Such-API-Fehler (Status 402)“ zurück. Der HTTP-Code 402 bedeutet, dass eine Zahlung erforderlich ist, was darauf hindeutet, dass für den Suchdienst ein kostenpflichtiges Abonnement benötigt wird, obwohl Ollama dies nicht erwähnte. Das Modell legte nahe, dass das Problem mit den Kontopreisen oder Nutzungslimits zusammenhängen könnte, wir konnten die genaue Ursache jedoch nicht ermitteln. Da unsere lokalen Modelle einwandfrei funktionierten, beschlossen wir, keine weitere Zeit mit der Fehlersuche im Suchdienst zu verbringen. Es war dennoch enttäuschend, dass wir den gleichen Web-Suchtest, den wir mit den anderen Anwendungen dieser Reihe durchgeführt hatten, nicht abschließen konnten.

Multimodale Eingabe

Unser erster Bildtest erfolgte mit demselben Jan V2 VL High GGUF, der bereits in Jan mit einem separaten Projektor funktioniert hatte. Ollama akzeptierte die Sprachmodelldatei, jedoch wurde die zugehörige mmproj-Datei beim Import nicht zugeordnet. Beim Versuch, den NVIDIA-Screenshot an eine Jan V2-Konversation anzuhängen, zeigte die Desktop-Anwendung die Meldung „Dieses Modell unterstützt keine Bilder“ an, bevor wir die Anfrage absenden konnten.

Anschließend testeten wir Qwen3-VL 4B, heruntergeladen über Ollama, mit derselben Eingabeaufforderung für GPU-Modell, Treiberversion, VRAM, Auslastung, Temperatur und Leistungsaufnahme. Dieses Modell akzeptierte den Screenshot und lieferte die korrekten sechs Werte: RTX 5000 Ada Generation, Treiber 597.06, 32,760 MiB, 0 % Auslastung, 39 °C und 40 W. Die Ergebnisse waren jedoch nicht durchgehend fehlerfrei, da kurzzeitig eine falsche Auslastung von 8 % angezeigt wurde, bevor dieser Wert in der abschließenden Zusammenfassung korrigiert wurde.

In Ollama konnten wir, anders als bei anderen Anwendungen, kein Bild direkt aus dem Windows-Snipping-Tool in das Chatfenster einfügen. Stattdessen mussten wir den Screenshot zuerst speichern und ihn dann über die Schaltfläche „+“ neben dem Nachrichtenfeld hochladen. Das funktionierte problemlos, und das Qwen3-VL-Modell von Ollama analysierte das Bild erfolgreich. Unser importiertes Jan-V2-Modell konnte denselben Anhang nicht verarbeiten, was die Wiederholung des ursprünglichen multimodalen Tests erschwerte.

Lokaler API-Server

Die lokale API von Ollama war sofort nach dem Start des Windows-Dienstes verfügbar, ohne dass ein separater Server von der Desktop-Oberfläche gestartet werden musste. Eine Anfrage an http://127.0.0.1:11434/v1/models Wir haben unsere installierten Jan V3.5- und Qwen3-VL-Modelle zurückgeschickt und eine Anfrage gestellt an /v1/chat/completions Die Verwendung von Jan V3.5 generierte eine Ein-Satz-Erklärung von RAID 6.

Die Antwort verwendete eine etwas ungenaue Formulierung bezüglich der RAID-6-Parität, was auf ein Problem mit der Modellausgabe und nicht auf einen API-Fehler zurückzuführen war. Der funktionierende Endpunkt ermöglichte es uns, lokale Modelle direkt über PowerShell abzufragen, ohne den Desktop-Chat zu verwenden.

Was schief gelaufen ist

Das größte Problem war die Bildverarbeitung unseres importierten Jan V2 VL High-Modells. Der Import der GGUF-Datei und die Ausführung von Texteingaben mit voller GPU-Beschleunigung verliefen problemlos. Schwierigkeiten traten jedoch auf, als wir versuchten, unseren NVIDIA-Screenshot anzuhängen. Ollama teilte uns mit, dass das Modell keine Bilder unterstützt, da der separate Vision Projector, den Jan V2 benötigt, in unserem Import fehlte. Wir konnten den Bildanalysetest dennoch mit Ollamas Qwen3-VL-Download durchführen, der einwandfrei funktionierte. Dies zeigte, dass Ollama Bilder verarbeiten kann. Die Verwendung unseres bestehenden Jan V2-Modells gestaltete sich jedoch deutlich schwieriger als der Import der GGUF-Datei.

Um die Websuche nutzen zu können, mussten wir zunächst ein Ollama-Konto erstellen. Nach der Anmeldung und dem Absenden unserer Testfrage erhielten wir einen HTTP-402-Fehler und keine Suchergebnisse. Wir konnten die Fehlerursache nicht ermitteln und sahen keinen Sinn darin, die Kontoeinstellungen zu ändern oder verschiedene Tarife auszuprobieren, ohne zu wissen, ob dies Abhilfe schaffen würde.

Uns fiel auch auf, wie oft wir für Aufgaben wie den Import unserer bestehenden Modelle, die Anpassung ihrer Einstellungen und die Erfassung von Leistungsdaten zu PowerShell zurückkehren mussten. Die Desktop-Anwendung war zwar für die alltägliche Kommunikation einfach zu bedienen, bot aber nicht denselben Kontrollumfang wie Jans Benutzeroberfläche. Abgesehen von diesen Problemen bereitete uns Ollama während der Tests kaum Schwierigkeiten: Beide Modelle ließen sich erfolgreich importieren, alle sechs Benchmark-Läufe wurden abgeschlossen und die lokale API funktionierte wie erwartet.

Fazit

Unsere Tests mit Ollama 0.40.11 verliefen im Allgemeinen gut, insbesondere die Ausführung lokaler Modelle auf der RTX 5000 Ada. Beide importierten GGUFs funktionierten mit voller GPU-Beschleunigung ohne zusätzliche CUDA-Konfiguration. Die Leistung war in dieser Reihe führend: Jan V3.5 erreichte einen Median von 145.48 Token/Sek., Jan V2 VL High 92.87 Token/Sek. – die schnellsten Ergebnisse der Reihe und 13 bis 18 Prozent besser als Jan auf derselben Workstation. Nach der Konfiguration gab es keine Probleme beim Wechsel zwischen der Desktop-Chat-Oberfläche und der lokalen API, und alle Benchmark-Läufe wurden problemlos abgeschlossen.

Obwohl uns die einfache Bedienung von Ollama für den alltäglichen Chat gefiel, hätten wir uns mehr Kontrolle über die einzelnen Modelle in der Desktop-Anwendung gewünscht. Die Notwendigkeit, PowerShell zu verwenden und Modelldateien zum Importieren unserer bestehenden GGUFs zu erstellen, bedeutete einige zusätzliche Schritte, insbesondere im Vergleich zu Jan, wo die meisten Einstellungen direkt in der Benutzeroberfläche verfügbar sind. Dies wird Nutzer, die bereits Erfahrung mit der Ausführung lokaler Modelle haben, nicht unbedingt stören, aber Einsteiger, die alles über eine grafische Oberfläche verwalten möchten, könnten Ollama als zu eingeschränkt empfinden. Wir stießen außerdem auf einige Probleme mit der Websuche und unserem importierten Bildverarbeitungsmodell, die jedoch die normale Textgenerierung nicht beeinträchtigten.

Was uns an Ollama besonders gefiel, war die einfache Möglichkeit, lokale Modelle anderen Anwendungen bereitzustellen, ohne dass wir einen separaten Server konfigurieren mussten. Der Desktop-Chat ist intuitiv bedienbar, und die lokale API sowie die Unterstützung externer Codierungswerkzeuge ermöglichen weit mehr als nur die Kommunikation mit lokalen Modellen. Wir würden uns zwar noch verbesserte Steuerungsmöglichkeiten für die Modellverwaltung in der Desktop-Oberfläche wünschen, aber Ollama lief auf unserer Workstation einwandfrei und bot uns eine zuverlässige Möglichkeit, unsere beiden Testmodelle mit GPU-Beschleunigung auszuführen.

Rangliste: Ollama hält den Titel „Beste lokale LLM-Laufzeitumgebung“ auf unserer Seite „Beste lokale LLM-Tools“ , wo diese Ergebnisse nun neben unseren Jan- und Open-WebUI-Zahlen zu finden sind.