Ollama vs. vLLM vs. LM Studio: Bester Weg, LLMs lokal auszuführen (2026)?
Vergleichen Sie die besten Tools für das lokale Hosten von LLMs im Jahr 2026. Reife der API, Hardware-Support, Tool-Calling und reale Anwendungsfälle.
Das lokale Ausführen von LLMs ist nun auch für Entwickler, Startups und sogar Enterprise-Teams praktikabel.
Doch die Wahl des richtigen Tools – Ollama, vLLM, LM Studio, LocalAI oder andere – hängt von Ihren Zielen ab:
- Entwickeln Sie eine API-gestützte App?
- Betreiben Sie einen privaten Offline-Assistenten?
- Bedienen Sie Produktions-Verkehr mit hoher Durchsatzrate?
- Testen Sie Modelle auf Consumer-GPUs?
Dieser Leitfaden vergleicht 12+ lokale LLM-Hosting-Tools hinsichtlich:
- API-Reife
- Tool-/Function-Calling
- Hardware- & GPU-Unterstützung
- Kompatibilität der Modellformate (GGUF, Safetensors, GPTQ, AWQ)
- Produktionsreife
- Benutzerfreundlichkeit
Wenn Sie die kurze Antwort wollen, starten Sie hier 👇
Kurzer Vergleich: Ollama vs. vLLM vs. LM Studio & mehr
Die folgende Tabelle fasst die wichtigsten Unterschiede zwischen Ollama, vLLM, LM Studio, LocalAI und anderen lokalen LLM-Deployment-Tools zusammen.
| Tool | Beste für | API-Reife | Tool Calling | GUI | Dateiformate | GPU-Unterstützung | Open Source |
|---|---|---|---|---|---|---|---|
| Ollama | Entwickler, API-Integration | ⭐⭐⭐⭐⭐ Stabil | ❌ Begrenzt | 3rd party | GGUF | NVIDIA, AMD, Apple | ✅ Ja |
| LocalAI | Multimodale KI, Flexibilität | ⭐⭐⭐⭐⭐ Stabil | ✅ Voll | Web UI | GGUF, PyTorch, GPTQ, AWQ, Safetensors | NVIDIA, AMD, Apple | ✅ Ja |
| Jan | Datenschutz, Einfachheit | ⭐⭐⭐ Beta | ❌ Begrenzt | ✅ Desktop | GGUF | NVIDIA, AMD, Apple | ✅ Ja |
| LM Studio | Anfänger, Hardware mit geringen Spezifikationen | ⭐⭐⭐⭐⭐ Stabil | ⚠️ Experimentell | ✅ Desktop | GGUF, Safetensors | NVIDIA, AMD (Vulkan), Apple, Intel (Vulkan) | ❌ Nein |
| vLLM | Produktion, hoher Durchsatz | ⭐⭐⭐⭐⭐ Produktion | ✅ Voll | ❌ Nur API | PyTorch, Safetensors, GPTQ, AWQ | NVIDIA, AMD | ✅ Ja |
| TGI | HF-Modelle, metriklastiges Serving | ⭐⭐⭐⭐ Stabil (Wartung) | ⚠️ Variiert | ❌ Nur API | Safetensors, HF-Quantisierung | NVIDIA (Multi-GPU) | ✅ Ja |
| SGLang | HF-Modelle, Durchsatz, natives /generate | ⭐⭐⭐⭐⭐ Produktion | ✅ Voll | ❌ Nur API | PyTorch, Safetensors, HF | NVIDIA, AMD | ✅ Ja |
| Docker Model Runner | Container-Workflows | ⭐⭐⭐ Alpha/Beta | ⚠️ Begrenzt | Docker Desktop | GGUF (abhängig) | NVIDIA, AMD | Teilweise |
| Lemonade | AMD NPU-Hardware | ⭐⭐⭐ In Entwicklung | ✅ Voll (MCP) | ✅ Web/CLI | GGUF, ONNX | AMD Ryzen AI (NPU) | ✅ Ja |
| Msty | Multi-Modell-Verwaltung | ⭐⭐⭐⭐ Stabil | ⚠️ Über Backends | ✅ Desktop | Über Backends | Über Backends | ❌ Nein |
| Backyard AI | Charakter-/Rollenspiel | ⭐⭐⭐ Stabil | ❌ Begrenzt | ✅ Desktop | GGUF | NVIDIA, AMD, Apple | ❌ Nein |
| Sanctum | Mobile Datensicherheit | ⭐⭐⭐ Stabil | ❌ Begrenzt | ✅ Mobile/Desktop | Optimierte Modelle | Mobile GPUs | ❌ Nein |
| RecurseChat | Terminal-Nutzer | ⭐⭐⭐ Stabil | ⚠️ Über Backends | ❌ Terminal | Über Backends | Über Backends | ✅ Ja |
| node-llama-cpp | JavaScript/Node.js-Entwickler | ⭐⭐⭐⭐ Stabil | ⚠️ Manuell | ❌ Bibliothek | GGUF | NVIDIA, AMD, Apple | ✅ Ja |
Diese Tools ermöglichen es Ihnen, große Sprachmodelle lokal auszuführen, ohne auf Cloud-APIs wie OpenAI oder Anthropic angewiesen zu sein. Ob Sie einen produktionsreifen Inferenzserver aufbauen, mit RAG-Pipelines experimentieren oder einen privaten Offline-Assistenten betreiben – die Wahl der richtigen lokalen LLM-Hosting-Lösung beeinflusst Leistung, Hardwareanforderungen und API-Flexibilität.
Welches lokale LLM-Tool sollten Sie wählen?
Hier sind praktische Empfehlungen basierend auf realen Use Cases.
Schnelle Empfehlungen:
- Anfänger: LM Studio oder Jan
- Entwickler: Ollama oder node-llama-cpp
- Produktion: vLLM
- Produktion (Hugging Face Serving + Prometheus): TGI
- Produktion (Hugging Face + OpenAI API und natives
/generate): SGLang - Multimodal: LocalAI
- AMD Ryzen AI PCs: Lemonade
- Fokus auf Datenschutz: Jan oder Sanctum
- Power-User: Msty
Für einen umfassenderen Vergleich, einschließlich Cloud-APIs und Infrastruktur-Trade-offs, siehe unseren detaillierten Leitfaden zu LLM-Hosting: lokal vs. self-hosted vs. Cloud-Deployment.
Speziell bei AMD-GPUs ist die oben genannte Tool-Wahl nur die halbe Entscheidung – jeder dieser Engines muss auch einen Compute-Backend (ROCm oder Vulkan) auswählen, und diese Wahl ist unabhängig davon, welches Tool Sie am Ende nutzen. Siehe ROCm vs. Vulkan für AMD Local LLM Hosting für die Engine-übergreifende Aufschlüsselung.
Wenn Ihre Favoritenliste sich bereits auf Ollama vs. direktes llama.cpp eingedengt hat, verdient dieses Paar einen eigenen tiefgehenden Vergleich statt der oben genannten Zusammenfassung – siehe llama.cpp vs. Ollama in 2026 für GPU-Platzierung, KV-Cache-Steuerung, API-Unterschiede und konkrete Migrationsauslöser.
Ollama: Beste für Entwickler & OpenAI-kompatible APIs
Ollama hat sich als eines der beliebtesten Tools für das lokale LLM-Deployment etabliert, insbesondere unter Entwicklern, die seine Kommandozeilenschnittstelle und Effizienz schätzen. Aufbauend auf llama.cpp liefert es eine exzellente Token-pro-Sekunde-Durchsatzrate mit intelligenter Speicherverwaltung und effizienter GPU-Beschleunigung für NVIDIA (CUDA), Apple Silicon (Metal) und AMD (ROCm) GPUs.
Schlüssel-Funktionen: Einfache Modellverwaltung mit Befehlen wie ollama run llama3.2, OpenAI-kompatible API für den drop-in-Ersatz von Cloud-Diensten, umfassende Modellbibliothek mit Unterstützung für Llama, Mistral, Gemma, Phi, Qwen und andere, Fähigkeit zu strukturierten Ausgabedaten und Erstellung eigener Modelle über Modelfiles.
API-Reife: Sehr ausgereift mit stabilen OpenAI-kompatiblen Endpunkten, einschließlich /v1/chat/completions, /v1/embeddings und /v1/models. Unterstützt vollständiges Streaming via Server-Sent Events, Vision-API für multimodale Modelle, verfügt jedoch über keine native Unterstützung für Function Calling. Das Verständnis davon, wie Ollama parallele Anfragen behandelt, ist für einen optimalen Betrieb entscheidend, insbesondere bei der Bearbeitung mehrerer gleichzeitiger Benutzer.
Dateiformat-Unterstützung: Primär GGUF-Format mit allen Quantisierungsebenen (Q2_K bis Q8_0). Automatische Konvertierung von Hugging Face-Modellen ist durch die Erstellung von Modelfiles verfügbar. Für effizientes Speicher-Management müssen Sie möglicherweise Ollama-Modelle auf eine andere Festplatte oder in einen anderen Ordner verschieben.
Tool Calling Unterstützung: Ollama hat offiziell die Tool-Calling-Funktionalität hinzugefügt, die es Modellen ermöglicht, mit externen Funktionen und APIs zu interagieren. Die Implementierung folgt einem strukturierten Ansatz, bei dem Modelle entscheiden können, wann Tools aufgerufen werden sollen und wie die zurückgegebenen Daten verwendet werden sollen. Tool Calling ist über die API von Ollama verfügbar und funktioniert mit Modellen, die spezifisch für Function Calling trainiert wurden, wie Mistral, Llama 3.1, Llama 3.2 und Qwen2.5. Allerdings unterstützt die API von Ollama Stand 2024 noch kein Streaming von Tool-Calls oder den tool_choice-Parameter, die in der OpenAI-API verfügbar sind. Das bedeutet, Sie können ein bestimmtes Tool nicht dazu zwingen, aufgerufen zu werden, oder Tool-Call-Antworten im Streaming-Modus erhalten. Trotz dieser Einschränkungen ist das Tool Calling von Ollama für viele Use Cases produktionsreif und integriert sich gut mit Frameworks wie Spring AI und LangChain. Die Funktion stellt eine signifikante Verbesserung gegenüber dem vorherigen Prompt-Engineering-Ansatz dar.
Wann wählen: Ideal für Entwickler, die CLI-Schnittstellen und Automatisierung bevorzugen, eine zuverlässige API-Integration für Anwendungen benötigen, Open-Source-Transparenz schätzen und eine effiziente Ressourcennutzung wünschen. Hervorragend für den Bau von Anwendungen, die eine nahtlose Migration von OpenAI erfordern. Für eine umfassende Referenz zu Befehlen und Konfigurationen, siehe das Ollama-Spickzettel. Wenn Sie bewerten, ob Sie von Ollama zu vLLM für Produktions-Workloads wechseln sollten, siehe Ollama zu vLLM: Wann migrieren.
Wenn Sie Ollama speziell mit Doccers nativer Container-Ansatz vergleichen, siehe unsere detaillierte Aufschlüsselung von Docker Model Runner vs. Ollama. Dieser Leitfaden konzentriert sich auf Docker-Integration, GPU-Konfiguration, Leistungs-Trade-offs und Unterschiede bei der Produktions-Deployment.
Dieses schöne Bild wurde generiert von AI Modell Flux 1 dev.
LocalAI: OpenAI-kompatibler lokaler LLM-Server mit Multimodal-Unterstützung
LocalAI positioniert sich als umfassende KI-Stack, die über reine Textgenerierung hinausgeht und multimodale KI-Anwendungen unterstützt, einschließlich Text-, Bild- und Audiogenerierung.
Schlüssel-Funktionen: Umfassender KI-Stack einschließlich LocalAI Core (Text-, Bild-, Audio-, Vision-APIs), LocalAGI für autonome Agenten, LocalRecall für semantische Suche, P2P-verteilt Inferenz-Fähigkeiten und beschränkte Grammatiken für strukturierte Ausgaben.
API-Reife: Sehr ausgereift als vollständiger OpenAI-Drop-in-Ersatz, der alle OpenAI-Endpunkte plus zusätzliche Funktionen unterstützt. Enthalten ist vollständige Streaming-Unterstützung, natives Function Calling via OpenAI-kompatibler Tools-API, Bildgenerierung und -verarbeitung, Audiokurzerfassung (Whisper), Text-zu-Sprache, konfigurierbare Rate-Begrenzung und integrierte API-Key-Authentifizierung. LocalAI excelt bei Aufgaben wie der Konvertierung von HTML-Inhalten in Markdown mit LLM dank seiner vielseitigen API-Unterstützung.
Dateiformat-Unterstützung: Am vielseitigsten mit Unterstützung für GGUF, GGML, Safetensors, PyTorch, GPTQ und AWQ Formate. Mehrere Backends einschließlich llama.cpp, vLLM, Transformers, ExLlama und ExLlama2.
Tool Calling Unterstützung: LocalAI bietet umfassende OpenAI-kompatible Function-Calling-Unterstützung mit seinem erweiterten KI-Stack. Die LocalAGI-Komponente ermöglicht speziell autonome Agenten mit robusten Tool-Calling-Fähigkeiten. Die Implementierung von LocalAI unterstützt die vollständige OpenAI Tools-API, einschließlich Funktionsdefinitionen, Parameterschemata und sowohl einzelne als auch parallele Funktionsaufrufe. Die Plattform funktioniert über mehrere Backends (llama.cpp, vLLM, Transformers) und hält die Kompatibilität mit dem OpenAI-API-Standard, was Migrationen unkompliziert macht. LocalAI unterstützt fortschrittliche Funktionen wie beschränkte Grammatiken für zuverlässigere strukturierte Ausgaben und hat experimentelle Unterstützung für das Model Context Protocol (MCP). Die Tool-Calling-Implementierung ist ausgereift und produktionsreif und funktioniert besonders gut mit für Function Calling optimierten Modellen wie Hermes 2 Pro, Functionary und aktuellen Llama-Modellen. Der Ansatz von LocalAI für Tool Calling ist eine seiner stärksten Funktionen und bietet Flexibilität, ohne Kompatibilität zu opfern.
Wann wählen: Beste für Benutzer, die multimodale KI-Fähigkeiten über Text hinaus benötigen, maximale Flexibilität bei der Modellwahl, OpenAI-API-Kompatibilität für bestehende Anwendungen und erweiterte Funktionen wie semantische Suche und autonome Agenten. Funktioniert effizient sogar ohne dedizierte GPUs. Um loszulegen, deckt der LocalAI QuickStart die Docker-Installation, Model-Gallery-Setup, CLI-Flags und API-Nutzung Ende-zu-Ende ab.
Jan: Beste datenschutzorientierte Offline-App für lokale LLMs
Jan geht einen anderen Ansatz ein, indem er den Fokus auf den Datenschutz des Benutzers und Einfachheit legt, anstatt auf erweiterte Funktionen, mit einem 100% offline Design, das keine Telemetrie und keine Cloud-Abhängigkeiten enthält.
Schlüssel-Funktionen: ChatGPT-ähnliche vertraute Konversationsschnittstelle, sauberer Model Hub mit Modellen, die als „schnell“, „ausgewogen“ oder „hohe Qualität“ gekennzeichnet sind, Konversationsverwaltung mit Import/Export-Fähigkeiten, minimale Konfiguration mit out-of-box-Funktionalität, llama.cpp Backend, GGUF-Format-Unterstützung, automatische Hardware-Erkennung und ein Erweiterungssystem für Community-Plugins.
API-Reife: Beta-Stufe mit OpenAI-kompatibler API, die grundlegende Endpunkte offenlegt. Unterstützt Streaming-Antworten und Embeddings via llama.cpp Backend, hat aber begrenzte Tool-Calling-Unterstützung und eine experimentelle Vision-API. Nicht für Multi-User-Szenarien oder Rate-Begrenzung konzipiert.
Dateiformat-Unterstützung: GGUF-Modelle, kompatibel mit dem llama.cpp Engine, unterstützt alle standardmäßigen GGUF-Quantisierungsebenen mit einfacher Drag-and-Drop-Dateiverwaltung.
Tool Calling Unterstützung: Jan hat derzeit begrenzte Tool-Calling-Fähigkeiten in seinen stabilen Releases. Als auf Datenschutz ausgerichteter persönlicher KI-Assistent priorisiert Jan Einfachheit gegenüber erweiterten Agentenfunktionen. Während die zugrunde liegende llama.cpp Engine theoretisch Tool-Calling-Muster unterstützt, legt die API-Implementierung von Jan keine vollständigen OpenAI-kompatiblen Function-Calling-Endpunkte offen. Benutzer, die Tool Calling benötigen, müssten manuelle Prompt-Engineering-Ansätze implementieren oder auf zukünftige Updates warten. Die Entwicklungs-Roadmap deutet darauf hin, dass Verbesserungen der Tool-Unterstützung geplant sind, aber der aktuelle Fokus bleibt auf der Bereitstellung einer zuverlässigen, offline-first Chat-Erfahrung. Für Produktionsanwendungen, die robustes Function Calling erfordern, sollten Sie stattdessen LocalAI, Ollama oder vLLM in Betracht ziehen. Jan ist am besten für konversationelle KI-Use Cases geeignet, anstatt für komplexe autonome Agenten-Workflows, die Tool-Orchestrierung erfordern.
Wann wählen: Perfekt für Benutzer, die Datenschutz und Offline-Betrieb priorisieren, eine einfache Konfigurations-Erfahrung ohne Einstellungen wünschen, GUI gegenüber CLI bevorzugen und eine lokale ChatGPT-Alternative für den persönlichen Gebrauch benötigen.
LM Studio: Lokales LLM-Hosting für Integrierte GPUs & Apple Silicon
LM Studio hat seinen Ruf als das zugänglichste Tool für das lokale LLM-Deployment erworben, insbesondere für Benutzer ohne technischen Hintergrund.
Schlüssel-Funktionen: Polierte GUI mit schöner intuitiver Schnittstelle, Modellbrowser für einfache Suche und Download von Hugging Face, Leistungsvergleich mit visuellen Indikatoren für Modellgeschwindigkeit und -qualität, sofortige Chat-Schnittstelle zum Testen, benutzerfreundliche Regler für Parameteranpassungen, automatische Hardware-Erkennung und -optimierung, Vulkan Offloading für integrierte Intel/AMD GPUs, intelligente Speicherverwaltung, exzellente Apple Silicon-Optimierung, lokaler API-Server mit OpenAI-kompatiblen Endpunkten und Modell-Aufteilung, um größere Modelle über GPU und RAM hinweg auszuführen.
API-Reife: Sehr ausgereift und stabil mit OpenAI-kompatibler API. Unterstützt vollständiges Streaming, Embeddings-API, experimentelles Function Calling für kompatible Modelle und begrenzte multimodale Unterstützung. Fokussiert auf Einbenutzerszenarien ohne integrierte Rate-Begrenzung oder Authentifizierung.
Dateiformat-Unterstützung: GGUF (llama.cpp kompatibel) und Hugging Face Safetensors Formate. Integrierter Konverter für einige Modelle und kann aufgeteilte GGUF-Modelle ausführen.
Tool Calling Unterstützung: LM Studio hat in jüngeren Versionen (v0.2.9+) experimentelle Tool-Calling-Unterstützung implementiert, die dem OpenAI Function-Calling-API-Format folgt. Die Funktion ermöglicht Modellen, die auf Function Calling trainiert wurden (insbesondere Hermes 2 Pro, Llama 3.1 und Functionary), externe Tools über den lokalen API-Server aufzurufen. Allerdings sollte Tool Calling in LM Studio als Beta-Qualität betrachtet werden – es funktioniert zuverlässig für Test- und Entwicklungszwecke, kann aber in der Produktion auf Randfälle stoßen. Die GUI macht es einfach, Funktions-Schemata zu definieren und Tool-Calls interaktiv zu testen, was für das Prototyping von Agenten-Workflows wertvoll ist. Die Modellkompatibilität variiert stark, wobei einige Modelle ein besseres Tool-Calling-Verhalten zeigen als andere. LM Studio unterstützt kein Streaming von Tool-Calls oder erweiterte Funktionen wie parallele Funktionsaufrufe. Für ernsthafte Agenten-Entwicklung, verwenden Sie LM Studio für lokale Tests und Prototyping, und deployen Sie dann zu vLLM oder LocalAI für Produktionszuverlässigkeit.
Wann wählen: Ideal für Anfänger im lokalen LLM-Deployment, Benutzer, die grafische Schnittstellen Kommandozeilentools vorziehen, diejenigen, die gute Leistung auf Hardware mit geringeren Spezifikationen benötigen (insbesondere mit integrierten GPUs) und jeden, der eine polierte professionelle Benutzererfahrung wünscht. Auf Maschinen ohne dedizierte GPUs übertrifft LM Studio oft Ollama aufgrund der Vulkan-Offloading-Fähigkeiten. Viele Benutzer verbessern ihre LM Studio-Erfahrung mit Open-Source Chat UIs für lokale Ollama-Instanzen, die auch mit der OpenAI-kompatiblen API von LM Studio funktionieren.
vLLM: Produktionsreifes lokales LLM-Serving mit hohem Durchsatz
vLLM ist speziell für hochleistungs-, produktionsreifes LLM-Inferenz entwickelt, mit seiner innovativen PagedAttention-Technologie, die Speicherfragmentation um 50 % oder mehr reduziert und den Durchsatz für parallele Anfragen um 2-4x erhöht.
Schlüssel-Funktionen: PagedAttention für optimierte Speicherverwaltung, kontinuierliches Batching für effiziente Verarbeitung mehrerer Anfragen, verteilte Inferenz mit Tensor-Parallelismus über mehrere GPUs, Token-für-Token-Streaming-Unterstützung, Hochdurchsatz-Optimierung für die Bedienung vieler Benutzer, Unterstützung für beliebte Architekturen (Llama, Mistral, Qwen, Phi, Gemma), Vision-Sprachmodelle (LLaVA, Qwen-VL), OpenAI-kompatible API, Kubernetes-Unterstützung für Container-Orchestrierung und integrierte Metriken für Performance-Tracking.
API-Reife: Produktionsreif mit sehr ausgereifter OpenAI-kompatibler API. Volle Unterstützung für Streaming, Embeddings, Tool-/Function-Calling mit paralleler Aufruffähigkeit, Vision-Sprachmodell-Unterstützung, produktionsreifer Rate-Begrenzung und Token-basierter Authentifizierung. Optimiert für Hochdurchsatz- und Batch-Anfragen.
Dateiformat-Unterstützung: PyTorch und Safetensors (primär), GPTQ und AWQ-Quantisierung, native Unterstützung für den Hugging Face Model Hub. Unterstützt GGUF nicht nativ (erfordert Konvertierung).
Tool Calling Unterstützung: vLLM bietet produktionsreifes, voll funktionsfähiges Tool Calling, das zu 100 % mit OpenAIs Function-Calling-API kompatibel ist. Es implementiert die vollständige Spezifikation, einschließlich paralleler Funktionsaufrufe (wobei Modelle mehrere Tools gleichzeitig aufrufen können), den tool_choice-Parameter zur Steuerung der Tool-Auswahl und Streaming-Unterstützung für Tool-Calls. Der PagedAttention-Mechanismus von vLLM hält den hohen Durchsatz aufrecht, sogar während komplexer mehrstufiger Tool-Calling-Sequenzen, was es ideal für autonome Agentensysteme macht, die mehrere Benutzer gleichzeitig bedienen. Die Implementierung funktioniert hervorragend mit für Function Calling optimierten Modellen wie Llama 3.1, Llama 3.3, Qwen2.5-Instruct, Mistral Large und Hermes 2 Pro. vLLM behandelt Tool Calling auf der API-Ebene mit automatischer JSON-Schema-Validierung für Funktionsparameter, was Fehler reduziert und Zuverlässigkeit verbessert. Für Produktions-Deployments, die unternehmensweites Tool-Orchestrierung erfordern, ist vLLM der Goldstandard und bietet sowohl die höchste Leistung als auch das vollständigste Funktionspaket unter den lokalen LLM-Hosting-Lösungen.
Wann wählen: Beste für produktionsreife Leistung und Zuverlässigkeit, hohe gleichzeitige Anfragenaufbereitung, Multi-GPU-Deployment-Fähigkeiten und LLM-Serving im Unternehmensmaßstab. Bei dem Vergleich von NVIDIA GPU-Spezifikationen für Eignung in KI, bevorzugen die Anforderungen von vLLM moderne GPUs (A100, H100, RTX 4090) mit hoher VRAM-Kapazität für optimale Leistung. vLLM excelt auch beim Erhalten strukturierter Ausgaben von LLMs mit seiner nativen Tool-Calling-Unterstützung. Für einen praktischen Migrationsleitfaden von Ollama zu vLLM, siehe Ollama zu vLLM: Wann migrieren.
TGI (Text Generation Inference): Hugging Face Serving mit starker Observability
Text Generation Inference (TGI) ist der Stack von Hugging Face zum Serven von Transformers-Modellen über HTTP: ein Router plus Modell-Worker, kontinuierliches Batching, Token-Streaming, tensor-parallel Multi-GPU-Sharding und eine Prometheus /metrics-Oberfläche, die Queueing, Latenz und Batch-Verhalten trackt. Es legt auch eine OpenAI-stilisierte Messages API offen, sodass viele Clients mit minimalen Änderungen auf TGI zeigen können.
Wichtiger Trade-off im Jahr 2026: Upstream TGI befindet sich im Wartungsmodus (archiviert nur lesbar). Das ist eine Einschränkung bei neuen Funktionen, kann aber operationell attraktiv sein, wenn Sie eine stabile Serving-Oberfläche wünschen, während Modelle und Prompts sich ändern.
Wann wählen: Sie standardisieren auf Hugging Face Hub Gewichte und Formate, Sie wünschen Erstklassige Metriken und ein lang bewährtes Serving-Layout, und Sie sind mit dem Upstream im Wartungsmodus einverstanden, solange die Runtime vorhersehbar bleibt.
Praktischer Leitfaden: TGI - Text Generation Inference - Installation, Konfiguration, Fehlerbehebung
SGLang: Hochdurchsatz-Hugging Face Serving (OpenAI API + natives /generate)
SGLang zielt auf die gleiche „dedizierte GPU-Server“-Ebene wie vLLM, mit OpenAI-kompatiblen HTTP-APIs, einem nativen /generate-Pfad für nicht-Chat-Workloads, YAML und CLI Serverkonfiguration und einem offline Engine, wenn Sie Batch- oder in-Prozess-Inferenz benötigen. Installationspfade enthalten typischerweise uv, pip oder Docker, was Teams passt, die bereits auf Hugging Face Model IDs und PyTorch-Gewichte standardisieren.
Wann wählen: Sie wünschen Hochdurchsatz-Serving auf HF-Modellen, Sie mögen es, beide OpenAI-artige Clients und SGLangs eigene Generationsoberfläche zu haben, und Sie vergleichen Alternativen zu vLLM auf Multi-GPU oder schweren Ein-Knoten-Setups.
Praktischer Leitfaden: SGLang QuickStart: Installation, Konfiguration und Serven von LLMs via OpenAI API
Docker Model Runner: Containerisiertes lokales LLM-Deployment für DevOps
Docker Model Runner ist Docker’s relativ neuer Eintritt in das lokale LLM-Deployment, der die Containerisierungsstärken von Docker mit nativer Integration nutzt, Docker Compose-Unterstützung für einfache Multi-Container-Deployments, vereinfachtes Volume-Management für Modell-Speicher und -Caching und container-native Service-Erkennung.
Schlüssel-Funktionen: Vor-konfigurierte Container mit bereit zu verwendenden Modellbildern, feingranulare CPU- und GPU-Ressourcen-Zuweisung, reduzierte Konfigurationskomplexität und GUI-Verwaltung über Docker Desktop.
API-Reife: Alpha/Beta-Stufe mit sich entwickelnden APIs. Container-native Schnittstellen, wobei die zugrunde liegende Engine bestimmte Fähigkeiten bestimmt (meistens basierend auf GGUF/Ollama).
Dateiformat-Unterstützung: Container-verpackte Modelle, wobei das Format von der zugrunde liegenden Engine abhängt (typischerweise GGUF). Standardisierung ist noch in Entwicklung.
Tool Calling Unterstützung: Die Tool-Calling-Fähigkeiten von Docker Model Runner werden von seiner zugrunde liegenden Inferenz-Engine (typischerweise Ollama) geerbt. Eine recente praktische Bewertung durch Docker offenbarte erhebliche Herausforderungen mit lokalem Modell-Tool-Calling, einschließlich übermäßigen Aufrufs (Modelle, die Tools unnötig aufrufen), falscher Tool-Auswahl und Schwierigkeiten beim korrekten Umgang mit Tool-Antworten. Während Docker Model Runner Tool Calling über seine OpenAI-kompatible API unterstützt, wenn angemessene Modelle verwendet werden, variiert die Zuverlässigkeit stark je nach spezifischem Modell und Konfiguration. Die Containerisierungsschicht fügt keine Tool-Calling-Funktionen hinzu – sie bietet einfach einen standardisierten Deployment-Wrapper. Für produktionelle Agentensysteme, die robustes Tool Calling erfordern, ist es effektiver, vLLM oder LocalAI direkt zu containerisieren, anstatt Model Runner zu verwenden. Die Stärke von Docker Model Runner liegt in der Vereinfachung des Deployments und der Ressourcenverwaltung, nicht in verbesserten KI-Fähigkeiten. Die Tool-Calling-Erfahrung wird nur so gut sein wie die Unterstützung des zugrunde liegenden Modells und der Engine.
Wann wählen: Ideal für Benutzer, die Docker bereits umfangreich in Workflows einsetzen, nahtlose Container-Orchestrierung benötigen, Doccers Ökosystem und Tooling schätzen und vereinfachte Deployment-Pipelines wünschen. Für eine detaillierte Analyse der Unterschiede, siehe Docker Model Runner vs. Ollama Vergleich, der untersucht, wann man welche Lösung für Ihren spezifischen Use Case wählt.
Lemonade: AMD Ryzen AI-optimierter lokaler LLM-Server mit MCP-Unterstützung
Lemonade repräsentiert einen neuen Ansatz für das lokale LLM-Hosting, speziell optimiert für AMD-Hardware mit NPU (Neural Processing Unit) Beschleunigung, die AMD Ryzen AI-Fähigkeiten nutzt.
Schlüssel-Funktionen: NPU-Beschleunigung für effiziente Inferenz auf Ryzen AI-Prozessoren, hybride Ausführung, die NPU, iGPU und CPU für optimale Leistung kombiniert, erstklassige Model Context Protocol (MCP) Integration für Tool Calling, OpenAI-kompatible Standard-API, schlankes Design mit minimalem Ressourcen-Overhead, Unterstützung für autonome Agenten mit Tool-Zugriffsfähigkeiten, mehrere Schnittstellen einschließlich Web UI, CLI und SDK sowie hardware-spezifische Optimierungen für AMD Ryzen AI (7040/8040 Serie oder neuer).
API-Reife: In Entwicklung, aber schnell fortschreitend mit OpenAI-kompatiblen Endpunkten und Cutting-Edge MCP-basierte Tool-Calling-Unterstützung. Die sprachunabhängige Schnittstelle vereinfacht die Integration über Programmiersprachen hinweg.
Dateiformat-Unterstützung: GGUF (primär) und ONNX mit NPU-optimierten Formaten. Unterstützt gängige Quantisierungsebenen (Q4, Q5, Q8).
Tool Calling Unterstützung: Lemonade bietet Cutting-Edge Tool Calling durch seine erstklassige Model Context Protocol (MCP) Unterstützung, was eine signifikante Evolution über traditionelles OpenAI-stilisiertes Function Calling hinaus darstellt. MCP ist ein offener Standard, der von Anthropic für natürlichere und kontextbewusstere Tool-Integration entwickelt wurde, der LLMs erlaubt, ein besseres Bewusstsein für verfügbare Tools und ihre Zwecke während von Konversationen aufrechtzuerhalten. Lemonades MCP-Implementierung ermöglicht Interaktionen mit verschiedenen Tools, einschließlich Websuche, Dateisystemoperationen, Speichersystemen und Custom-Integrationen – alles mit AMD NPU-Beschleunigung für Effizienz. Der MCP-Ansatz bietet Vorteile gegenüber traditionellem Function Calling: bessere Tool-Entdeckbarkeit, verbessertes Kontextmanagement über Multi-Turn-Konversationen hinweg und standardisierte Tool-Definitionen, die über verschiedene Modelle hinweg funktionieren. Während MCP noch aufkommt (von Claude übernommen, jetzt auf lokale Deployments ausbreitend), Lemonades frühe Implementierung positioniert es als Leader für Agentensysteme der nächsten Generation. Am besten geeignet für AMD Ryzen AI Hardware, wo NPU-Offloading 2-3x Effizienzgewinne für Tool-lastige Agenten-Workflows bietet.
Wann wählen: Perfekt für Benutzer mit AMD Ryzen AI Hardware, diejenigen, die autonome Agenten aufbauen, jeden, der effiziente NPU-Beschleunigung benötigt, und Entwickler, die Cutting-Edge MCP-Unterstützung wünschen. Kann 2-3x bessere Tokens/Watt im Vergleich zu nur-CPU-Inferenz auf AMD Ryzen AI Systemen erreichen.
Msty: Multi-Modell lokaler LLM-Manager für Power-User
Msty konzentriert sich auf nahtlose Verwaltung mehrerer LLM-Anbieter und Modelle mit einer einheitlichen Schnittstelle für mehrere Backends, die mit Ollama, OpenAI, Anthropic und anderen arbeiten.
Schlüssel-Funktionen: Anbieter-agnostische Architektur, schnelles Modell-Schalten, erweiterte Konversationsverwaltung mit Verzweigung und Forking, integrierte Prompt-Bibliothek, Fähigkeit, lokale und Cloud-Modelle in einer Schnittstelle zu mischen, Antworten von mehreren Modellen nebeneinander zu vergleichen und plattformübergreifende Unterstützung für Windows, macOS und Linux.
API-Reife: Stabil für die Verbindung zu bestehenden Installationen. Kein separater Server erforderlich, da es die Funktionalität anderer Tools wie Ollama und LocalAI erweitert.
Dateiformat-Unterstützung: Hängt von den verbundenen Backends ab (typischerweise GGUF via Ollama/LocalAI).
Tool Calling Unterstützung: Msty’s Tool-Calling-Fähigkeiten werden von seinen verbundenen Backends geerbt. Wenn Sie sich mit Ollama verbinden, stoßen Sie auf seine Einschränkungen (kein natives Tool Calling). Wenn Sie LocalAI oder OpenAI Backends verwenden, erhalten Sie deren volle Tool-Calling-Funktionen. Msty fügt selbst keine Tool-Calling-Funktionalität hinzu, sondern fungiert eher als einheitliche Schnittstelle für mehrere Anbieter. Das kann tatsächlich vorteilhaft sein – Sie können denselben Agenten-Workflow gegen verschiedene Backends (lokales Ollama vs. LocalAI vs. Cloud OpenAI) testen, um Leistung und Zuverlässigkeit zu vergleichen. Msty’s Konversationsverwaltungsfunktionen sind besonders nützlich für das Debugging komplexer Tool-Calling-Sequenzen, da Sie Konversationen an Entscheidungspunkten forken und vergleichen können, wie verschiedene Modelle dieselben Tool-Aufrufe behandeln. Für Entwickler, die Multi-Modell-Agentensysteme bauen, bietet Msty eine bequeme Möglichkeit zu bewerten, welches Backend die beste Tool-Calling-Leistung für spezifische Use Cases bietet.
Wann wählen: Ideal für Power-User, die mehrere Modelle verwalten, diejenigen, die Modellausgaben vergleichen, Benutzer mit komplexen Konversations-Workflows und hybride lokale/Cloud-Setups. Kein eigenständiger Server, sondern eher eine fortschrittliche Frontend für bestehende LLM-Deployments.
Backyard AI: Datenschutz-Fokussiertes Rollenspiel & Kreative Schreibung LLM
Backyard AI spezialisiert sich auf Charakter-basierte Konversationen und Rollenspielszenarien mit detaillierter Charaktererstellung, Persönlichkeitsdefinition, mehrfacher Charakterumschaltung, langfristiges Konversationsspeicher und lokal-first datenschutzfokussierte Verarbeitung.
Schlüssel-Funktionen: Charaktererstellung mit detaillierten KI-Persönlichkeitsprofilen, mehrere Charakter-Personas, Speichersystem für langfristige Konversationen, benutzerfreundliche Schnittstelle, zugänglich für nicht-technische Benutzer, aufgebaut auf llama.cpp mit GGUF-Modell-Unterstützung und plattformübergreifende Verfügbarkeit (Windows, macOS, Linux).
API-Reife: Stabil für GUI-Nutzung, aber begrenzte API-Zugriffe. Hauptsächlich auf die grafische Benutzererfahrung fokussiert, anstatt auf programmatische Integration.
Dateiformat-Unterstützung: GGUF-Modelle mit Unterstützung für die meisten beliebten Chat-Modelle.
Tool Calling Unterstützung: Backyard AI bietet keine Tool-Calling- oder Function-Calling-Fähigkeiten. Es ist spezialisiert für Charakter-basierte Konversationen und Rollenspielszenarien, in denen Tool-Integration irrelevant ist. Die Anwendung konzentriert sich auf die Aufrechterhaltung der Charakterkonsistenz, das Management langfristigen Speichers und die Erstellung immersiver Konversationserlebnisse, anstatt Funktionen auszuführen oder mit externen Systemen zu interagieren. Für Benutzer, die nach Charakter-basierter KI-Interaktion suchen, ist das Fehlen von Tool Calling keine Einschränkung – es erlaubt dem System, sich vollständig auf natürlichen Dialog zu optimieren. Wenn Sie KI-Charaktere benötigen, die auch Tools nutzen können (wie ein rollenspielender Assistent, der echtes Wetter prüfen oder Informationen suchen kann), müssten Sie eine andere Plattform wie LocalAI verwenden oder eine Custom-Lösung bauen, die Charakterkarten mit Tool-Calling-fähigen Modellen kombiniert.
Wann wählen: Beste für kreatives Schreiben und Rollenspiel, Charakter-basierte Anwendungen, Benutzer, die personalisierte KI-Personas wünschen, und Gaming- und Unterhaltungs-Use Cases. Nicht für allgemeinzweckige Entwicklung oder API-Integration konzipiert.
Sanctum: Private On-Device LLM für iOS & Android
Sanctum AI betont Datenschutz mit offline-first mobilen und Desktop-Anwendungen, die echten Offline-Betrieb ohne Internetverbindung, End-to-End-Verschlüsselung für Konversationssynchronisation, On-Device-Verarbeitung mit aller Inferenz, die lokal stattfindet, und plattformübergreifende verschlüsselte Synchronisation bieten.
Schlüssel-Funktionen: Mobile Unterstützung für iOS und Android (selten im LLM-Bereich), aggressive Modell-Optimierung für Mobilgeräte, optionale verschlüsselte Cloud-Synchronisation, Familienfreigabe-Unterstützung, optimierte kleinere Modelle (1B-7B Parameter), Custom-Quantisierung für Mobile und vor-verpackte Modell-Bundles.
API-Reife: Stabil für den vorgesehenen mobilen Gebrauch, aber mit begrenzten API-Zugriffen. Für Endbenutzer-Anwendungen konzipiert, anstatt für Entwickler-Integration.
Dateiformat-Unterstützung: Optimierte kleinere Modellformate mit Custom-Quantisierung für mobile Plattformen.
Tool Calling Unterstützung: Sanctum unterstützt keine Tool-Calling- oder Function-Calling-Fähigkeiten in seiner aktuellen Implementierung. Als Mobile-first-Anwendung, die sich auf Datenschutz und Offline-Betrieb konzentriert, priorisiert Sanctum Einfachheit und Ressourceneffizienz über erweiterte Funktionen wie Agenten-Workflows. Die kleineren Modelle (1B-7B Parameter), die es ausführt, sind im Allgemeinen nicht gut geeignet für zuverlässiges Tool Calling, selbst wenn die Infrastruktur es unterstützen würde. Sanctums Value Proposition ist die Bereitstellung privater, on-device KI-Chat für den alltäglichen Gebrauch – E-Mails lesen, Nachrichten entwerfen, Fragen beantworten – anstatt komplexe autonome Aufgaben. Für mobile Benutzer, die Tool-Calling-Fähigkeiten benötigen, machen die Architektur-Einschränkungen mobiler Hardware dies zu einer unrealistischen Erwartung. Cloud-basierte Lösungen oder Desktop-Anwendungen mit größeren Modellen bleiben für agentenbasierte Workflows erforderlich, die Tool-Integration erfordern.
Wann wählen: Perfekt für mobilen LLM-Zugang, datenschutzbewusste Benutzer, Multi-Device-Szenarien und KI-Assistenz unterwegs. Begrenzt auf kleinere Modelle aufgrund mobiler Hardware-Einschränkungen und weniger geeignet für komplexe Aufgaben, die größere Modelle erfordern.
RecurseChat: Terminal-basierte lokale LLM-Schnittstelle für Entwickler
RecurseChat ist eine terminalbasierte Chat-Schnittstelle für Entwickler, die in der Kommandozeile leben, und bietet tastaturgesteuerte Interaktion mit Vi/Emacs-Keybindings.
Schlüssel-Funktionen: Terminal-native Operation, Multi-Backend-Unterstützung (Ollama, OpenAI, Anthropic), Syntax-Highlighting für Code-Blöcke, Sitzungsverwaltung zum Speichern und Wiederherstellen von Konversationen, skriptbare CLI-Befehle für Automatisierung, in Rust geschrieben für schnelle und effiziente Operation, minimale Abhängigkeiten, funktioniert über SSH und ist tmux/screen freundlich.
API-Reife: Stabil, verwendet bestehende Backend-APIs (Ollama, OpenAI, etc.) anstatt einen eigenen Server bereitzustellen.
Dateiformat-Unterstützung: Hängt vom verwendeten Backend ab (typischerweise GGUF via Ollama).
Tool Calling Unterstützung: RecurseChat’s Tool-Calling-Unterstützung hängt davon ab, welches Backend Sie verbinden. Mit Ollama Backends erben Sie Ollamas Einschränkungen. Mit OpenAI oder Anthropic Backends erhalten Sie deren volle Function-Calling-Fähigkeiten. RecurseChat selbst implementiert kein Tool Calling, sondern bietet eine Terminal-Schnittstelle, die es bequem macht, Agenten-Workflows zu debuggen und zu testen. Das Syntax-Highlighting für JSON macht es einfach, Funktionsaufruf-Parameter und -Antworten zu inspizieren. Für Entwickler, die Kommandozeilen-Agentensysteme bauen oder Tool Calling in Remote-Umgebungen über SSH testen, bietet RecurseChat eine leichte Schnittstelle ohne den Overhead einer GUI. Seine skriptbare Natur erlaubt auch die Automatisierung von Agenten-Test-Szenarien über Shell-Skripte, was es wertvoll für CI/CD-Pipelines macht, die das Tool-Calling-Verhalten über verschiedene Modelle und Backends hinweg validieren müssen.
Wann wählen: Ideal für Entwickler, die Terminal-Schnittstellen bevorzugen, Remote-Server-Zugriff über SSH, Scripting- und Automatisierungsbedürfnisse und Integration mit Terminal-Workflows. Kein eigenständiger Server, sondern ein fortgeschrittener Terminal-Client.
node-llama-cpp: Lokale LLMs in Node.js & TypeScript Anwendungen ausführen
node-llama-cpp bringt llama.cpp in das Node.js-Ökosystem mit nativen Node.js-Bindings, die direkte llama.cpp-Integration und vollständige TypeScript-Unterstützung mit vollständigen Tydefinitionen bereitstellen.
Schlüssel-Funktionen: Token-für-Token-Streaming-Generierung, Text-Embeddings-Generierung, programmatische Modellverwaltung zum Downloaden und Verwalten von Modellen, integrierte Chat-Template-Verarbeitung, native Bindings, die nahezu native llama.cpp-Leistung in der Node.js-Umgebung bieten, konzipiert für den Bau von Node.js/JavaScript-Anwendungen mit LLMs, Electron-Apps mit lokaler KI, Backend-Dienste und serverless Funktionen mit gebündelten Modellen.
API-Reife: Stabil und ausgereift mit umfassenden TypeScript-Definitionen und gut dokumentierter API für JavaScript-Entwickler.
Dateiformat-Unterstützung: GGUF-Format via llama.cpp mit Unterstützung für alle standardmäßigen Quantisierungsebenen.
Tool Calling Unterstützung: node-llama-cpp erfordert manuelle Implementierung von Tool Calling durch Prompt Engineering und Ausgabe-Parsing. Im Gegensatz zu API-basierten Lösungen mit nativem Function Calling müssen Sie den gesamten Tool-Calling-Workflow in Ihrem JavaScript-Code bearbeiten: Definition von Tool-Schemata, Einspeisung in Prompts, Parsen von Modellantworten für Funktionsaufrufe, Ausführung der Tools und Rückführung der Ergebnisse an das Modell. Während dies Ihnen volle Kontrolle und Flexibilität gibt, ist es erheblich mehr Arbeit als die Verwendung der eingebaute Unterstützung von vLLM oder LocalAI. node-llama-cpp ist am besten für Entwickler geeignet, die Custom-Agenten-Logik in JavaScript bauen wollen und feingranulare Kontrolle über den Tool-Calling-Prozess benötigen. Die TypeScript-Unterstützung macht es einfacher, typsichere Tool-Schnittstellen zu definieren. Erwägen Sie, es mit Bibliotheken wie LangChain.js zu verwenden, um den Tool-Calling-Boilerplate zu abstrahieren, während die Vorteile der lokalen Inferenz beibehalten werden.
Wann wählen: Perfekt für JavaScript/TypeScript-Entwickler, Electron-Desktop-Anwendungen, Node.js-Backend-Dienste und schnelle Prototyp-Entwicklung. Bietet programmatische Kontrolle anstelle eines eigenständigen Servers.
Fazit
Die Wahl des richtigen lokalen LLM-Deployment-Tools hängt von Ihren spezifischen Anforderungen ab:
Primäre Empfehlungen:
- Anfänger: Beginnen Sie mit LM Studio für exzellente UI und Benutzerfreundlichkeit, oder Jan für datenschutz-first Einfachheit
- Entwickler: Wählen Sie Ollama für API-Integration und Flexibilität, oder node-llama-cpp für JavaScript/Node.js Projekte
- Datenschutz-Enthusiasten: Verwenden Sie Jan oder Sanctum für Offline-Erfahrung mit optionaler mobiler Unterstützung
- Multimodale Bedürfnisse: Wählen Sie LocalAI für umfassende KI-Fähigkeiten über Text hinaus
- Produktions-Deployments: Deployen Sie vLLM für Hochleistungs-Serving mit Enterprise-Funktionen
- Container-Workflows: Erwägen Sie Docker Model Runner für Ökosystem-Integration
- AMD Ryzen AI Hardware: Lemonade nutzt NPU/iGPU für exzellente Leistung
- Power-User: Msty für die Verwaltung mehrerer Modelle und Anbieter
- Kreatives Schreiben: Backyard AI für Charakter-basierte Konversationen
- Terminal-Enthusiasten: RecurseChat für Kommandozeilen-Workflows
- Autonome Agenten: vLLM oder Lemonade für robustes Function Calling und MCP-Unterstützung
Wichtige Entscheidungsfaktoren: API-Reife (vLLM, Ollama und LM Studio bieten die stabilsten APIs), Tool Calling (vLLM und Lemonade bieten das beste Function Calling), Dateiformat-Unterstützung (LocalAI unterstützt die breiteste Palette), Hardware-Optimierung (LM Studio excelt auf integrierten GPUs, Lemonade auf AMD NPUs) und Modellvielfalt (Ollama und LocalAI bieten die breiteste Modellauswahl).
Das lokale LLM-Ökosystem reift schnell weiter, wobei 2025 bedeutende Fortschritte in der API-Standardisierung (OpenAI-Kompatibilität über alle wichtigen Tools hinweg), Tool Calling (MCP-Protokoll-Adoption, die autonome Agenten ermöglicht), Formatflexibilität (bessere Konvertierungswerkzeuge und Quantisierungsmethoden), Hardware-Unterstützung (NPU-Beschleunigung, verbesserte integrierte GPU-Nutzung) und spezialisierte Anwendungen (Mobile, Terminal, Charakter-basierte Schnittstellen) bringt.
Ob Sie sich um Datensicherheit Sorgen machen, API-Kosten senken möchten, Offline-Fähigkeiten benötigen oder produktionsreife Leistung erfordern – lokales LLM-Deployment war noch nie zugänglicher oder leistungsfähiger. Das frühe Auswahl eines Stacks aus dieser Liste hält Ihre Fine-Tuning-Daten, Evaluation-Harnesses und Tool-Schemata auch in Formaten, die Sie kontrollieren – das Gegenmittel zur Daten-Gravitation, die KI-Workflows zu einem einzelnen Anbieter zieht, je länger Sie nur API-basiert bleiben. Die in diesem Leitfaden vorgestellten Tools repräsentieren die Spitze der lokalen KI-Deployment, jedes löst spezifische Probleme für verschiedene Nutzergruppen. Um zu sehen, wie diese lokalen Optionen neben Cloud-APIs und anderen Self-Hosted-Setups passen, prüfen Sie unseren Leitfaden LLM-Hosting: Lokal, Self-Hosted & Cloud Infrastruktur im Vergleich.
Externe Referenzen
- Local Tiny Agents: MCP Agents auf Ryzen AI mit Lemonade Server
- node-llama-cpp GitHub Repository
- vLLM Dokumentation
- LocalAI Dokumentation
- Jan AI Offizielle Website
- LM Studio Offizielle Website
- Msty App
- Backyard AI
- Sanctum AI
- RecurseChat GitHub
- Produktionsreife lokale LLM-Inferenz auf Apple Silicon: Eine vergleichende Studie von MLX, MLC-LLM, Ollama, llama.cpp und PyTorch MPS
- Freisetzung einer Welle von LLM-Apps auf Ryzen AI durch Lemonade Server