Lokale LLM-Inferenz: vLLM, llama.cpp, Ollama, TensorRT-LLM im Vergleich

Lokale KI ist 2026 kein Bastelprojekt mehr, aber sie ist auch kein gelöstes Problem. Die meisten Diskussionen drehen sich um Modellnamen: welches Qwen, welches Llama, welches DeepSeek. In schwächeren Setups scheitert am Ende oft der Serving-Stack drumherum. Wer einen 70B-Parameter-Klassiker auf einer Workstation mit dem falschen Framework betreibt, verliert je nach Konfiguration entweder Latenz, Throughput, Kontextlänge oder die OpenAI-kompatible Schnittstelle, an der die eigenen Agents hängen. Dieser Artikel ist die dritte Folge der lokalen KI-Serie nach dem Quantisierungs-DeepDive und dem NVFP4-Blackwell-Stück. Die Modellseite ist damit grob abgesteckt. Jetzt geht es um den Stack, der das Modell trägt.

Vier Frameworks dominieren die Praxis: vLLM, llama.cpp, Ollama und TensorRT-LLM. Sie wirken in Tutorials austauschbar, sind es aber nicht. Sie verfolgen unterschiedliche Annahmen darüber, was lokale Inferenz eigentlich sein soll: ein produktiver API-Endpunkt, ein portables CPU-Werkzeug, ein bequemes Desktop-Erlebnis oder ein bis aufs Bit getrimmter NVIDIA-Pfad. Diese Annahmen prägen alles: das Modellformat, die Quantisierungsunterstützung, den Batching-Modus, die Latenzkurve und letztlich den Betriebsaufwand. Wer die Annahmen ignoriert, baut sich entweder einen Hochleistungs-Server für einen einzigen Nutzer oder eine Bequemlichkeitslösung für eine Last, die sie nie tragen kann.

Die These: Serving entscheidet, nicht das Modell

Drei Beobachtungen aus realen Setups stützen die zentrale These dieses Artikels.

Erstens: zwei identische Modelle, einmal über vLLM und einmal über Ollama bedient, liefern bei gleicher Quantisierung unter Last sehr unterschiedliche Antwortzeiten. Entscheidend ist hier die Frage, wie Anfragen gebündelt, der KV-Cache verwaltet und Tokens gestreamt werden. Zweitens: die OpenAI-kompatible Schnittstelle, ohne die Agent-Frameworks wie LangChain, LlamaIndex oder selbstgebaute Tool-Caller kaum funktionieren, ist nicht überall gleich vollständig. Tool-Calling, strukturierte Outputs und Streaming sind die Stellen, an denen viele lokale Setups still brechen. Drittens: die laufenden Kosten lokaler KI entstehen vor allem aus Engineering-Zeit für Updates, Modellwechsel und Quantisierungsexperimente; Strom und GPU-Abschreibung sind nur ein Teil der Rechnung. Die Wahl des Frameworks ist eine Wette darauf, wo dieser Aufwand landet.

Daraus folgt: der lokale Stack lässt sich nicht über ein generisches Tool-Ranking lösen. Wer "das beste Framework" sucht, stellt die falsche Anforderung. Sinnvoll ist ein Entscheidungsrahmen, der Hardware-Ziel, Lastprofil, Modellgrösse, gewünschte API-Oberfläche und Betriebskultur gegeneinander hält. Genau das versucht dieser Artikel.

vLLM: der produktive API-Server

vLLM ist 2026 das De-facto-Rückgrat für produktive lokale Inferenz auf NVIDIA-Hardware, sobald mehr als ein Nutzer den Endpunkt anfasst. Die Bibliothek wurde aus einem konkreten Schmerz heraus gebaut: klassische Transformer-Inferenz verschwendet GPU-Speicher und Compute, weil KV-Cache und Batching naiv implementiert sind. PagedAttention adressiert das, indem der KV-Cache wie virtueller Speicher in Seiten organisiert wird, was die Speicherauslastung dramatisch verbessert. Continuous Batching erlaubt es, neue Anfragen in laufende Generierungen einzuschleusen, statt auf das langsamste Token im Batch zu warten. Das Resultat: deutlich höherer Throughput bei vergleichbarer Tail-Latenz, wenn die Last echt parallel ist.

Drei Eigenschaften machen vLLM zur Standardwahl für API-orientierte Setups. Erstens: der OpenAI-kompatible Server mit vllm serve deckt Chat-Completion, Completion und Embeddings ab und unterstützt Streaming sowie Tool-Calling für die Modelle, die das eigene Format mitbringen. Zweitens: die Quantisierungsabdeckung. FP8, INT8, GPTQ, AWQ, SqueezeLLM, BitsAndBytes, GGUF-Loader für Konvertierung und, auf Blackwell-Hardware, NVFP4. Wer den Quantisierungs-Artikel gelesen hat, weiss: nicht jedes Backend ist für jeden Anwendungsfall gleich gut, aber die Auswahl ist breit genug, um Use Cases differenziert zu adressieren. Drittens: verteilte Inferenz. Tensor-Parallelism über mehrere GPUs, Pipeline-Parallelism über Knoten, Data- und Expert-Parallelism für MoE-Modelle. Das ist relevant, sobald ein 70B-Modell quantisiert nicht mehr auf eine Karte passt oder ein DeepSeek-V3-artiges Mixture-of-Experts produktiv betrieben werden soll.

Die Kehrseite ist Komplexität. vLLM hat Modellkompatibilitätsdetails, die in der Praxis Zeit kosten: ein Modell muss von der eingesetzten Version unterstützt sein, manche Quantisierungsvarianten brauchen spezifische Kernels, und Auto-Prefix-Caching ist nicht in jedem Workload ein Gewinn. Wer mit gemischten Modelltypen experimentiert, verbringt Stunden mit Versionspinning, CUDA-Inkompatibilitäten und Wheel-Builds. Die Studie aus der Quantisierungs-Recherche basiert nicht zufällig auf vLLM 0.6.4.post1, also einer fest gewählten Version. Reproduzierbarkeit ist hier eine eigene Disziplin.

Praxisregel: vLLM ist die richtige Wahl, sobald der lokale Endpunkt von mehr als zwei Personen, einem Agent-Schwarm oder einem nachgelagerten System gleichzeitig angesprochen wird, und sobald die Hardware NVIDIA-basiert ist. Für einen einzelnen Entwickler am MacBook ist es Overkill.

llama.cpp: der portable Boden der lokalen KI

llama.cpp ist die Bibliothek, ohne die ein grosser Teil der lokalen KI-Welt überhaupt nicht laufen würde. Das Projekt, mittlerweile unter der ggml-org-Organisation, ist eine in C/C++ geschriebene Inferenz-Engine mit einem zentralen Designziel: LLMs sollen überall laufen, auf CPU, Apple Silicon via Metal, NVIDIA via CUDA, AMD via ROCm, sogar auf älteren Konfigurationen. Das GGUF-Format, das aus dem Projekt hervorgegangen ist, ist heute der Lingua-franca-Container für quantisierte Modelle. Wer ein Modell auf Hugging Face in GGUF findet, kann es mit hoher Wahrscheinlichkeit irgendwo lokal starten.

Die technische Anatomie ist konsequent. Eine kompakte Codebase, Prebuilt Binaries für Linux, macOS und Windows, ein eingebauter REST-Server (llama-server), eine schlanke WebUI, Integration in den Hugging-Face-Cache, FIM-Completions für Editor-Plugins in VS Code und Vim. Die K-Quants (Q4_K_M, Q5_K_M, Q6_K usw.) sind ein etabliertes Vokabular geworden, mit dem die Community Modelle in vorhersehbaren Qualitätsstufen austauscht. Der jüngere MXFP4-Support, der in Kooperation mit NVIDIA für GPT-OSS implementiert wurde, zeigt, dass das Projekt sich auch in Richtung neuer 4-Bit-Formate öffnet.

Die Stärken sind eindeutig: maximale Portabilität, niedriger Speicherhunger bei aggressiver Quantisierung, kein Python-Tax. Auf Apple Silicon mit Metal ist llama.cpp oft das schnellste, was lokal verfügbar ist, gerade für 7B- bis 13B-Modelle in einem Single-User-Szenario. Die Schwächen werden sichtbar, sobald die Last steigt. Continuous Batching ist nicht so ausgereift wie in vLLM, der KV-Cache-Management-Apparat ist schlanker, und für echte Multi-User-Serving-Szenarien fehlt die operative Tiefe. Wer einen Dutzend gleichzeitiger Agents an einen llama-Server hängt, sieht im Profiling, dass die Tail-Latenzen unangenehm werden.

Die OpenAI-kompatible API existiert, ist aber pragmatischer angelegt als bei vLLM oder TensorRT-LLM. Tool-Calling ist je nach Modell und Version mehr oder weniger vollständig. Wer komplexe Agent-Workflows mit JSON-Schemas, parallelen Tool-Calls und strikten Strukturen plant, sollte vorher prüfen, ob die Modell-Template-Implementation das mitträgt.

Praxisregel: llama.cpp ist der Boden, auf dem lokale KI für Einzelnutzer, Edge-Geräte, Apple-Maschinen und CPU-Setups steht. Für produktive Multi-User-API-Server ist es nicht die erste Wahl, wohl aber häufig die zweite, wenn Portabilität wichtiger ist als maximaler Throughput.

Ollama: das Packaging, nicht die Engine

Ollama wird in Diskussionen oft so behandelt, als wäre es eine eigene Inferenz-Engine. Das ist es nicht. Ollama ist eine Abstraktions- und Packaging-Schicht, die unter der Haube auf llama.cpp basiert, dazu eine eigene Modellbibliothek, ein bequemes CLI, eine REST-API mit OpenAI-Kompatibilität und Integration in Werkzeuge wie Claude Code, Codex oder eigene Wrapper bietet. Wer ein Modell mit ollama pull herunterlädt und mit ollama run startet, sieht den Komfort sofort: kein Bauen, kein Konfigurieren, kein manuelles Quantisierungswählen.

Genau das ist der entscheidende Punkt. Ollama trifft Entscheidungen, die andere Frameworks dem Nutzer überlassen. Welche Quantisierung kommt mit dem Default-Tag? Welches Kontextfenster ist voreingestellt? Wie wird der KV-Cache geführt? Diese Defaults sind für Einsteiger ein Geschenk. Für produktive Setups sind sie eine Gefahr. Wer mit ollama run qwen3:8b startet, bekommt nicht automatisch die Quantisierung, die für den eigenen Use Case optimal ist, und nicht zwingend das Kontextfenster, das die eigene Anwendung braucht. Der Ollama-auf-Mac-Mini-Artikel zeigt, dass die Modellwahl bewusst sein muss, nicht der Default.

Ollama eignet sich aus drei Gründen sehr gut für bestimmte Szenarien. Erstens: bequemes Onboarding für Entwickler, die einen lokalen Modell-Endpunkt brauchen, ohne sich mit Kernel-Versionen zu beschäftigen. Zweitens: Integration in agentische Tools, die einen OpenAI-kompatiblen lokalen Endpunkt erwarten und am Loopback-Port 11434 finden. Drittens: Modellwechsel als Operation, also das schnelle Umschalten zwischen mehreren Modellen auf derselben Maschine, was bei manueller Verwaltung aufwendiger wäre.

Die Schwächen liegen in der Tiefe. Wer Quantisierung detailliert kontrollieren, eigene K-Quants laden oder spezifische Tensor-Splits über mehrere GPUs vornehmen will, fährt mit llama.cpp direkt besser. Wer Multi-User-Last mit echtem Continuous Batching braucht, fährt mit vLLM besser. Und wer extreme NVIDIA-Performance will, fährt mit TensorRT-LLM besser. Ollama ist die richtige Wahl in einer ganz bestimmten Schnittmenge: Single-User oder kleines Team, Entwicklungsumgebung, Modellwechsel-Häufigkeit hoch, Performance-Disziplin niedrig.

TensorRT-LLM: NVIDIA bis aufs Bit

TensorRT-LLM ist die Antwort auf eine spezifische Frage: was passiert, wenn jede Latenz-Millisekunde und jeder GPU-Zyklus zählen, und wenn die Hardware NVIDIA ist, idealerweise mit aktueller Architektur wie Hopper oder Blackwell? Die Bibliothek ist tief in den NVIDIA-Stack eingebettet, nutzt CUDA-Kernel, die für spezifische Architekturen optimiert sind, und kompiliert Modelle zu Engines, die auf der Zielhardware sehr schnell laufen. Das trtllm-serve-Frontend bietet eine OpenAI-kompatible API, vergleichbar in der Oberfläche mit vLLM, aber mit anderen Annahmen über den Build-Prozess.

Der kritische Unterschied liegt im Modell-Lifecycle. Bei vLLM lädt der Server ein Hugging-Face-Modell und beginnt zu antworten. Bei TensorRT-LLM wird das Modell vorab zu einer TensorRT-Engine kompiliert, mit spezifischen Parametern für Batchgrösse, Sequenzlänge und Quantisierung. Diese Engine läuft dann extrem schnell, ist aber an die Build-Konfiguration gebunden. Wer Modellvarianten oft wechselt oder mit Batch- und Sequenzlängen experimentiert, zahlt diesen Build-Aufwand wiederholt. Wer ein stabiles Workload-Profil hat, bekommt dafür Performance, die andere Frameworks nicht erreichen.

NVFP4 auf Blackwell ist der aktuelle Höhepunkt dieser Linie. Wie im Blackwell-NVFP4-Artikel ausgeführt, ist NVFP4 ein hardwareseitig unterstütztes 4-Bit-Format, das auf den Blackwell-Tensor-Cores nahe an FP8-Qualität bei deutlich höherem Throughput läuft. TensorRT-LLM ist derzeit der schnellste Pfad, dieses Format produktiv auszunutzen. Auf DGX-Spark-Hardware, für die NVIDIA explizit TRT-LLM-Pfade dokumentiert, ist das relevant: hier verschiebt sich das Verhältnis zwischen Modellgrösse und nutzbarer Geschwindigkeit messbar.

Die operative Realität ist anspruchsvoll. CPU-Affinity, NUMA-Awareness, CUDA-Versionspinning, korrekte Driver-Builds, Engine-Recompilation nach Modellupdates. Das ist eine Disziplin für stabile Lastprofile mit echtem Performance-Vorteil, kein Setup für eine Bastelmaschine im Heimbüro. Die Modellabdeckung ist breit, aber nicht so spontan wie bei vLLM oder llama.cpp; manche neue Modellfamilie braucht offizielle TRT-LLM-Modellrezepte, bevor sie sauber läuft.

Praxisregel: TensorRT-LLM ist die richtige Wahl, wenn drei Bedingungen gleichzeitig erfüllt sind. NVIDIA-Hardware der aktuellen oder vorherigen Generation, stabiles Workload-Profil mit hoher Last, und Bereitschaft zur Build-Disziplin. Wer eines davon nicht hat, ist mit vLLM ehrlicher bedient.

Open WebUI und LM Studio sind keine Vergleichskategorie

In Diskussionen tauchen oft Open WebUI und LM Studio als "Alternativen zu vLLM" auf. Das ist eine Kategoriefehlleitung. Open WebUI ist eine UI- und Workflow-Schicht mit RAG-Integration, Modellverwaltung, Berechtigungen und Frontend für mehrere Backends. LM Studio ist eine Desktop-App, die unter der Haube llama.cpp nutzt und einen lokalen Endpunkt anbietet. Beide sind nützlich, ersetzen aber keine Serving-Engine. Sie sitzen darüber oder daneben.

Die saubere Architektur sieht so aus: unten eine Serving-Engine (vLLM, llama.cpp, Ollama, TensorRT-LLM), darüber bei Bedarf eine UI- oder Workflow-Schicht (Open WebUI, LM Studio, Continue, LangChain). Wer diese Schichten mischt, baut entweder Redundanz oder verliert Klarheit darüber, wo Performance, Quantisierung und Stabilität herkommen. Im praktischen Stack ist die UI austauschbar. Die Engine ist es nicht, ohne die laufenden Agents anzupassen.

Betriebsrisiken

Einige Fehlentscheidungen wiederholen sich in Setups, die in Produktion scheitern oder unterperformen.

Das erste ist Tool-Wahl nach Tutorial-Popularität. Jeder zweite YouTube-Walkthrough zeigt Ollama, weil es schnell zu demonstrieren ist. Daraus wird abgeleitet, Ollama sei der richtige Stack für die eigene Produktion. Das ist eine Verwechslung von Demo-Tauglichkeit und Betriebsreife. Ollama ist exzellent für Entwicklung und Demos. Für eine Anwendung, die zehn gleichzeitige Tool-Calling-Agents bedient, ist vLLM nüchtern der richtigere Stack, weil Continuous Batching und KV-Cache-Management das Lastprofil sauberer abbilden.

Das zweite ist Quantisierung im Default-Modus. Wer einen Stack wählt, ohne über die voreingestellte Quantisierung nachzudenken, übernimmt eine Designentscheidung, die im Quantisierungsstück detailliert kritisiert wurde. Der Long-Context-Benchmark in der zitierten Arbeit zeigt, dass BNB-NF4 fast sieben Prozentpunkte verlieren kann, GPTQ-INT4 etwa 2,7 Punkte, AWQ-INT4 etwa 1,8 Punkte, während FP8 unter 0,3 Punkte bleibt. Wer Defaults akzeptiert, akzeptiert diese Differenz blind. Das ist im Test selten ein Problem, in der Produktion oft.

Das dritte ist OpenAI-API-Kompatibilität als Annahme. Ein lokaler Endpunkt, der /v1/chat/completions beantwortet, ist nicht automatisch ein vollwertiger Ersatz. Tool-Calling, parallele Tool-Calls, JSON-Schemas, Logit-Bias, strukturierte Outputs, Streaming-Verhalten und Token-Probabilities sind in jedem Framework leicht unterschiedlich implementiert. Wer eine produktive Agent-Pipeline ohne Integrationstests vom OpenAI-Cloud-Endpunkt auf den lokalen Server schwenkt, findet die Inkonsistenzen erst in der Praxis. Das Risiko ist hoch, weil viele dieser Inkonsistenzen still scheitern: das Tool wird nicht gerufen, das Format ist anders, der Agent läuft trotzdem weiter, aber liefert schlechtere Resultate.

Das vierte ist die Kategoriefehlinterpretation von UI-Schichten. Ein Team, das Open WebUI installiert und denkt, damit sei der Serving-Stack gelöst, übersieht, dass die Performance-Frage erst bei der dahinterliegenden Engine entschieden wird. Open WebUI ist eine Nutzungsoberfläche, kein Inferenz-Backend. Das gleiche gilt für LM Studio in Setups, die mehr als einen Nutzer bedienen sollen.

Systemisch verbindet diese Risiken ein Muster: lokale KI wird oft mit der Energie behandelt, die früher in SaaS-Konfigurationen floss, also als Plug-and-Play. Lokal aber heisst, dass die Architekturarbeit nicht ausgelagert ist. Wer keinen Stack-Verantwortlichen hat, der Modell, Quantisierung, Engine, Hardware und Workload zusammen denkt, bekommt entweder ein Spielzeug oder ein kostspieliges Halbprodukt.

Folgen über 12 bis 24 Monate

Zwei nicht offensichtliche Folgen werden die nächsten 12 bis 24 Monate prägen, wenn die aktuelle Marktdynamik anhält.

Die erste betrifft das Engineering-Profil von Teams, die lokale KI ernsthaft betreiben. Heute ist der typische lokale-KI-Engineer ein Generalist, der zwischen Modellauswahl, Quantisierung und Stack-Konfiguration wechselt. In den nächsten zwei Jahren wird diese Rolle in zwei Profile zerfallen: ein Inference-Operator, der Engines, Treiber, Quantisierung und Performance-Profiling verantwortet, und ein Application-Engineer, der Agent-Logik, Tool-Calling und Workflows baut. Der Grund liegt in der wachsenden Komplexität: NVFP4-Engines auf Blackwell, MXFP4 auf llama.cpp, vLLM-Tensor-Parallelism über mehrere Karten, TensorRT-LLM-Builds für stabile Workloads. Das ist keine Nebenbei-Arbeit mehr. Teams, die diese Differenzierung nicht ziehen, werden entweder Inferenz unterdimensionieren oder Anwendungsentwicklung verlangsamen.

Die zweite betrifft die Konsolidierung der OpenAI-Schnittstelle. Aktuell behandeln vLLM, llama.cpp, Ollama, TensorRT-LLM und mehrere Cloud-Anbieter die OpenAI-API als Quasi-Standard. Mit der Verbreitung von Tool-Calling-spezifischen Erweiterungen, MCP-getriebenen Agent-Architekturen, wie im MCP-Artikel ausgeführt, und neuen Schnittstellen für strukturierte Outputs wird diese Quasi-Standardisierung fragiler. Wer heute einen lokalen Stack baut, muss damit rechnen, dass die OpenAI-Kompatibilität in zwei Jahren nicht mehr die strategische Versicherung ist, die sie heute scheint. Stacks, die mehrere Schnittstellenformate sauber abbilden können, werden Vorteile haben. Stacks, die hart an einer API-Version kleben, werden Migrationskosten verursachen.

Eine dritte, leisere Folge: lokale Inferenz wird stärker als heute in Compliance- und Datenschutzdiskussionen verschoben. Solange Cloud-LLMs die Erwartungen an Datenresidenz, Auditierbarkeit und Modell-Lineage nicht vollständig erfüllen, wird der Druck zugunsten lokaler oder hybrider Architekturen steigen. Das verändert die Anforderungen an den Stack: Logging, Telemetrie, deterministische Reproduzierbarkeit und Modellsignaturen werden wichtiger. vLLM und TensorRT-LLM mit ihrer Server-Orientierung sind hier strukturell besser positioniert als Desktop-Tools.

Entscheidungsrahmen: welcher Stack, wann

Statt eines Tool-Rankings empfiehlt sich ein Entscheidungsrahmen entlang von vier Achsen.

Achse eins: Hardware. Apple Silicon und CPU-only führen zwingend zu llama.cpp oder, mit Komfort, zu Ollama. NVIDIA-Workstation mit einer Karte erlaubt vLLM oder Ollama, je nach Last. NVIDIA-Server mit mehreren Karten oder DGX-Spark führt zu vLLM oder TensorRT-LLM. AMD-Hardware ist eine Welt für sich, in der llama.cpp am tragfähigsten ist, vLLM zunehmend auch.

Achse zwei: Last. Single-User oder kleines Team mit einstelligen Concurrent-Requests: Ollama oder llama.cpp. Zweistellige Concurrent-Requests mit echter Agent-Last: vLLM. Sehr hohe Last mit stabilem Workload-Profil auf NVIDIA: TensorRT-LLM.

Achse drei: API-Tiefe. Wer nur Chat-Completions braucht, hat überall sauberen Boden. Wer Tool-Calling, strukturierte Outputs und parallele Calls braucht, sollte vLLM oder TensorRT-LLM mit dem konkret eingesetzten Modell vorab testen. Llama.cpp und Ollama sind hier modell- und versionsabhängig.

Achse vier: Betriebskultur. Wer keinen Inference-Operator hat, sollte nicht TensorRT-LLM wählen. Wer experimentiert und Modelle wöchentlich wechselt, sollte nicht TensorRT-LLM wählen. Wer einen stabilen, performanten Endpunkt mit ein bis zwei Modellen über Monate fahren will und NVIDIA-Hardware der aktuellen Generation hat, sollte genau das tun.

Aus diesen Achsen ergibt sich eine knappe Praxisempfehlung. Mac und kleine Maschine: Ollama oder direkt llama.cpp. NVIDIA-Workstation oder kleiner Server mit produktiver API-Last: vLLM. Blackwell-Hardware oder DGX-Klasse mit Maximalanforderung: TensorRT-LLM für die Engines, oft mit vLLM als Fallback während der Build-Phase. Über allem eine UI-Schicht wie Open WebUI nur dann, wenn die Nutzerseite das wirklich braucht.

Privacy und Netzwerk-Exposure

Ein Aspekt, der in Vergleichen oft unter den Tisch fällt, ist das Expositions-Profil der Frameworks. Alle vier öffnen lokale Endpunkte: vLLM standardmässig auf einem TCP-Port, llama.cpp via llama-server, Ollama auf Port 11434, TensorRT-LLM via trtllm-serve. Privacy entsteht nicht automatisch, weil die Inferenz lokal läuft. Wer den Endpunkt versehentlich auf 0.0.0.0 statt 127.0.0.1 bindet, hat einen offenen LLM-Server im Netz, je nach Konfiguration ohne Authentifizierung. Ollama ist in Default-Setups besonders bequem, was die Versuchung erhöht, Defaults nicht zu prüfen.

Strategisch bleibt der Punkt, der im DGX-Spark-Praxisartikel ausgearbeitet wurde: lokale Inferenz ist als Datenstrategie nur dann sauber, wenn der Stack das Privacy-Versprechen technisch hält. Das beginnt bei Bind-Adressen und endet bei Logging, Audit-Trails und der Frage, welche Telemetrie der Stack überhaupt sendet. Ollama und LM Studio haben in der Vergangenheit Telemetrie-Fragen ausgelöst, die in produktiven Umgebungen geprüft werden müssen. vLLM und llama.cpp sind hier neutraler, weil sie als Bibliotheken näher am eigenen Code sitzen.

Schluss: Stack als strategische Entscheidung

Lokale KI ist 2026 ein Spektrum, kein Setup. Das Spektrum reicht vom Single-User-Mac mit Ollama bis zur Blackwell-Maschine mit TensorRT-LLM-Engines. Wer die Wahl als Tool-Frage behandelt, wird die nächste Modellgeneration nicht ohne Schmerzen integrieren. Wer sie als Architekturfrage behandelt, baut einen Stack, der Modellwechsel, Quantisierungsexperimente und Lastveränderungen übersteht.

Die vier Frameworks sind Werkzeuge mit klaren Spezialisierungen. vLLM ist der produktive API-Server für NVIDIA-Last. llama.cpp ist der portable Boden für CPU, Apple und kleine Setups. Ollama ist die Komfortschicht für Entwicklung und einfache Endpunkte. TensorRT-LLM ist die Performance-Spitze für stabile Workloads auf aktueller NVIDIA-Hardware. Die strategische Aufgabe heisst: das passende Werkzeug wählen und dann konsequent betreiben.