Open-Source KI-Ökosystem 2026

Die Landkarte für KI-Infrastruktur-Entscheidungen.

Das Open-Source-KI-Ökosystem ist 2026 erwachsen geworden. Modelle, die Frontier-Performance erreichen. Tools, die in Produktion laufen. Eine Infrastruktur, die Souveränität ermöglicht — wenn man die richtigen Entscheidungen trifft.

Diese Seite gibt einen strukturierten Überblick: 6 Layer des OS-KI-Stacks, die wichtigsten Tools und Modelle pro Layer, und die Entscheidungskriterien, die Führungskräfte gerade abwägen. Keine vollständige Tool-Liste — sondern eine Landkarte, um die richtigen Fragen zu stellen.

Auf einen Blick

Der OS-KI-Stack hat sechs Schichten, die zusammen ein produktionsreifes System ergeben. Vier Modellfamilien dominieren 2026. Hier die schnelle Orientierung — klick dich zu dem, was dich interessiert.

Wann Open Source — und wann lieber nicht?

Das ist die Frage, die mich gerade am meisten beschäftigt. Open-Source-KI klingt nach der souveränen Wahl — aber der Betriebskosten, die Performance-Einbußen und der Aufwand für Security werden oft unterschätzt. Ich versuche mir ein Bild zu machen, wo die echten Trade-offs liegen.

🔓

Open Source hat aufgeholt

Der Gap zu Frontier-Modellen ist auf 6–9 Monate geschrumpft. DeepSeek V4 und Llama 4 erledigen die meisten Produktions-Workloads — zu deutlich geringeren Token-Kosten. Aber: der Betriebsaufwand ist real.

🌍

Souveränität vs. Vendor-Lock-in

Jeder API-Anbieter ist ein Vendor. Aber auch ein selbst gehosteter OS-Stack bindet an Personal, Know-how und Infrastruktur. Verschiebt Open Source die Abhängigkeit — oder hebt es sie auf? Meine These: beides.

📋

EU AI Act als Katalysator

Seit April 2026 in Kraft. OS-Tools ermöglichen Compliance selbst zu erfüllen — statt auf Anbieter-Versprechen zu vertrauen. Aber: wer hat schon Erfahrung mit Compli-AI oder Guardrails in Produktion? Ich kenne kaum jemanden.

Die 6 Layer des OS-KI-Stacks

Jeder Layer beantwortet eine konkrete Entscheidungsfrage — und hat Tools, die OS-Betrieb ermöglichen oder verhindern.

Layer 1Data & Residency

Souveränität beginnt bei den Daten. Welche Daten dürfen das Kontrollperimeter verlassen? Mit Open-Source-Backends liegt die Kontrolle über Embedding, Speicher und Retrieval vollständig im eigenen Haus.

Entscheidungsfrage: Läuft der gesamte Datenpfad (Embedding → Speicher → Retrieval) auf eigener Infrastruktur?

Qdrant

Vektordatenbank · ⭐ 23000 · Apache 2.0
  • +Vollständig in Rust — performant und speicherschonend
  • +Self-hosted oder managed — hybrider Betrieb
  • +Beste EU-Option (deutsches Unternehmen)
🔗 Vergleich↔ Alternativen: Chroma, Milvus, pgvector🇪🇺 Höchste — deutsches Unternehmen, DSGVO-konform

ChromaDB

Vektordatenbank · ⭐ 18000 · Apache 2.0
  • +Einfachste API (pip install → loslegen)
  • +Embedding-Funktionen eingebaut
  • +Embedded Mode für Entwicklung, Server für Produktion
  • Weniger skalierbar als Qdrant bei >10M Vektoren
↔ Alternativen: Qdrant, Weaviate, Milvus

Milvus

Vektorplattform · ⭐ 33000 · Apache 2.0
  • +Höchste Skalierbarkeit (Milliarden Vektoren)
  • +Kubernetes-nativ, cloud-agnostisch
  • +GPU-beschleunigte Indizierung
  • Chinesisches Projekt — geopolitischer Faktor
  • Komplexer Betrieb (braucht Kafka, MinIO, etc.)
🔗 Vergleich↔ Alternativen: Qdrant, Weaviate, pgvector

Hugging Face Transformers

Framework · ⭐ 142000 · Apache 2.0
  • +De-facto-Standard für Modell-Zugriff
  • +>100k Modelle im Hub — größte OS-Modell-Bibliothek
  • +13M Nutzer (2026) — exponentielles Wachstum
  • Nicht für Production-Inference optimiert (vLLM dafür)

llama.cpp

Inference (lokal) · ⭐ 11000 · MIT
  • +Läuft auf CPU + GPU — keine teure Hardware nötig
  • +Quantisierung (GGUF) eingebaut
  • +OpenAI-kompatibler Server
  • Langsamer als vLLM auf GPU-Clustern
  • Kein Continuous Batching
↔ Alternativen: vLLM, Ollama
Layer 2Inference

Der Souveränitätskipppunkt: Wo läuft der Modell-Request? Inference-Entscheidungen bestimmen, ob Ihre Daten eine Organisationseinheit, ein Rechenzentrum oder eine Jurisdiktion verlassen. Open-Source-Inference-Engines erlauben Self-Hosting auf eigener Hardware.

Entscheidungsfrage: Kann der Modell-Request vollständig auf eigener Hardware oder auf von Ihnen kontrollierter Infrastruktur ausgeführt werden?

vLLM

Inference Engine · ⭐ 79000 · Apache 2.0
  • +Produktionsstandard 2026 — PagedAttention, Continuous Batching
  • +Breiteste Hardware-Unterstützung (NVIDIA, AMD, Intel, AWS Inferentia)
  • +OpenAI-kompatible API — Drop-in-Replacement
  • +Amazon Rufus (250M Kunden), LinkedIn, Roblox (4B Tokens/Woche)
  • Komplexeres Setup als Ollama
📊 8,033 tok/s auf NVIDIA Blackwell (NVFP4)🔗 Vergleich↔ Alternativen: Ollama, SGLang, TGI

Ollama

Inference (lokal) · ⭐ 95000 · MIT
  • +Einfachste Dev-Erfahrung (Docker-ähnliches UX)
  • +Breiteste Modellunterstützung (vorgefertigte Configs)
  • +Riesige Community — Standard für lokale Entwicklung
  • Nicht für Multi-GPU-Produktion optimiert
  • Kein Continuous Batching
📊 Deutlich langsamer als vLLM/SGLang auf GPU↔ Alternativen: vLLM, llama.cpp

SGLang

Inference Engine · ⭐ 13000 · Apache 2.0
  • +Schnellste Engine auf spezifischen Workloads (Benchmark-Sieger)
  • +Structured Output (JSON Mode, Guidance) nativ integriert
  • +RadixAttention für KV-Cache-Management
  • Kleineres Ökosystem als vLLM
  • Neuere Engine — weniger Production-Bewährung
📊 +29% Durchsatz bei Shared Context Prefix, +17% bei GPTQ-INT4 vs vLLM↔ Alternativen: vLLM, TGI

Dynamo (AI Dynamo)

Orchestrierung · ⭐ 4000 · Apache 2.0
  • +Orchestrierungs-Layer über vLLM/SGLang/TensorRT-LLM
  • +Disaggregated Serving (Prefill + Decode getrennt)
  • +Multi-Tier KV-Caching, Multi-Node
  • Neu — weniger Production-Bewährung
↔ Alternativen: llm-d, vLLM (cluster)

LocalAI

Inference (lokal) · ⭐ 31000 · MIT
  • +OpenAI-API-kompatibel
  • +Unterstützt Bilder, Audio, Embeddings — nicht nur Text
  • +Docker-Deployment, einfach
  • Weniger Performance als vLLM (CPU-first)
↔ Alternativen: Ollama
Layer 3Post-Training

Wo Differenzierung entsteht. Open-Source-Modelle sind Commodity. Der Wettbewerbsvorteil liegt im Fine-Tuning auf eigene Daten. Die Frameworks dafür sind 2026 ausgereift und decken jedes Skill-Level ab.

Entscheidungsfrage: Können Sie Modelle auf Ihre spezifischen Domänen- und Qualitätsanforderungen nachtrainieren — ohne Abhängigkeit von externen API-Anbietern?

Unsloth

Fine-Tuning · ⭐ 54000 · Apache 2.0
  • +2x schnelleres Training, 70% weniger VRAM als HF-Baseline
  • +Einfachste Installation (pip install)
  • +Beste Wahl für Single-GPU / Consumer-Hardware
  • Free Tier = Single-GPU only
  • Multi-GPU nur in Pro-Version
🔗 Vergleich↔ Alternativen: Axolotl, LLaMA-Factory, TRL

LLaMA-Factory

Fine-Tuning · ⭐ 68400 · Apache 2.0
  • +Breiteste Modellunterstützung (100+ Architekturen)
  • +Web UI für Nicht-Developer
  • +Unterstützt DoRA, GaLore, LoRA+, QLoRA
  • China-basiertes Projekt (Tsinghua)
  • Weniger optimiert als Unsloth für Single-GPU
↔ Alternativen: Unsloth, Axolotl, TRL

Axolotl

Fine-Tuning · ⭐ 11400 · Apache 2.0
  • +Beste Wahl für Multi-GPU-Cluster (FSDP, DeepSpeed)
  • +YAML-Konfiguration, reproduzierbare Pipelines
  • +Vollständige RLHF-Pipeline (SFT, DPO, PPO, GRPO)
  • Steilere Lernkurve (Docker empfohlen)
  • Kein GUI
↔ Alternativen: Unsloth, LLaMA-Factory, TRL

Hugging Face TRL

RLHF-Toolkit · ⭐ 17600 · Apache 2.0
  • +Meistgenutztes Open-Source-RLHF-Toolkit
  • +Nahltose HF-Integration (Datasets, Model Hub, Accelerate)
  • +Unterstützt: SFT, DPO, KTO, IPO, ORPO, PPO, GRPO
  • Weniger optimiert als Unsloth
🔗 Vergleich↔ Alternativen: Unsloth, Axolotl, OpenRLHF
Layer 4Evaluation

Qualitätskontrolle im eigenen Haus. In einer OS-Welt müssen Sie nicht dem Versprechen eines API-Anbieters vertrauen — Sie können selbst messen, ob ein Modell Ihre Anforderungen erfüllt. Eval-Frameworks machen das reproduzierbar und CI-fähig.

Entscheidungsfrage: Können Sie mit eigenen, reproduzierbaren Tests prüfen, ob ein Modell Ihre Qualitätsanforderungen erfüllt — unabhängig von externen Benchmarks?

LM Evaluation Harness

Benchmark-Framework · ⭐ 10000 · MIT
  • +De-facto-Standard für reproduzierbare LLM-Evals
  • +60+ standardisierte Benchmarks integriert
  • +380+ Contributors — breiteste Community-Basis
  • Kein GUI — reine CLI
  • Benchmark-Overfitting-Risiko
↔ Alternativen: DeepEval, RAGAS, Lighteval

DeepEval

Eval-Framework · ⭐ 16200 · Apache 2.0
  • +Einfachste API (pytest-ähnlich)
  • +14+ Metriken: Halluzination, Relevanz, Toxizität
  • +CI/CD-Integration (GitHub Actions)
  • +LLM-Judges + Code-based Assertions
  • Stärker auf RAG/Agent-Evals als Modell-Benchmarks
🔗 Vergleich↔ Alternativen: LM Eval Harness, RAGAS, Promptfoo

RAGAS

RAG-Eval · ⭐ 10000 · Apache 2.0
  • +Spezialisiert auf RAG-Evaluation
  • +Metriken: Context Precision, Faithfulness, Answer Relevancy
  • +Keine Ground-Truth-Daten nötig (referenzlos)
  • Nur für RAG-Workloads
↔ Alternativen: DeepEval, TruLens

Lighteval (HF)

Eval-Framework · ⭐ 2400 · MIT
  • +Leichtgewichtig, schnelle Iteration
  • +HF-nativ (Model Hub, Datasets)
  • +Multi-Backend (vLLM, TGI, Transformers)
  • Kleinere Community
↔ Alternativen: LM Eval Harness, DeepEval
Layer 5Compliance & Audit

Prüfbarkeit, Traceability, Regulierung. Mit OS-Tools können Sie Guardrails, Input/Output-Scannen und Audit-Logs selbst definieren — statt sich auf das Compliance-Versprechen eines Anbieters zu verlassen. Besonders relevant mit dem EU AI Act (seit April 2026 in Kraft).

Entscheidungsfrage: Können Sie Output-Validierung, Input-Security und Audit-Trails unabhängig von Ihrem LLM-Anbieter betreiben?

Guardrails AI

Output-Validierung · ⭐ 7000 · Apache 2.0
  • +Strukturierte Output-Validierung (JSON-Schema, Pydantic)
  • +Vorgefertigte Guardrails (Halluzination, Toxizität, PII)
  • +Framework-agnostisch
  • Erhöht Latenz (jeder Output wird validiert)
↔ Alternativen: LLM Guard, NVIDIA NeMo Guardrails

LLM Guard

Input/Output-Security · ⭐ 2000 · Apache 2.0
  • +Input + Output Scanning (PII, Prompt Injection, Secrets)
  • +Leichtgewichtig, als Middleware einsetzbar
  • +Cloud-agnostisch
↔ Alternativen: Guardrails AI

Compli-AI

Compliance-as-Code · ⭐ 0 · OS
  • +Automatisiert EU AI Act Annex IV Technical Docs
  • +CI/CD-Integration (GitHub Actions)
  • +Declarative Compliance State Files
  • Sehr jung (2026) — noch keine Production-Bewährung
↔ Alternativen: AegisAI, Compass
Layer 6Operations

Der Day-One-Plan. Ein OS-KI-Stack ist kein Projekt — es ist ein Betriebsmodell. Die Plattform-Entscheidung (RAG-Framework, MLOps, Agent-Orchestrierung) bestimmt, wie schnell Sie neue Modelle einspielen, Audit-Anfragen beantworten und bei Anbieterwechseln umschwenken können.

Entscheidungsfrage: Ist Ihre Betriebsplattform so gewählt, dass Sie Frontier-Modelle gegen OS-Modelle austauschen können — ohne die Anwendungslogik neu schreiben zu müssen?

Haystack (deepset)

Pipeline-Framework · ⭐ 19000 · Apache 2.0
  • +Serialisierbare, testbare, auditierbare Pipelines
  • +Europäisches Unternehmen (Berlin) — DSGVO-konform
  • +Stärkste Wahl für regulierte Umfelder
🔗 Vergleich↔ Alternativen: LangChain, LlamaIndex🇪🇺 Höchste — deutsches Unternehmen, ideal für Compliance

LangChain

Agent-Framework · ⭐ 105000 · MIT
  • +Größtes Ökosystem für LLM-Anwendungen
  • +LangGraph: Stateful Agent Orchestrierung
  • +LangSmith: Observability + Tracing
  • Hohe Abstraktion — Debugging teils schwierig
  • 260M Funding — Vendor-Risk durch VC-Druck
↔ Alternativen: LlamaIndex, Haystack, DSPy

LlamaIndex

RAG-Framework · ⭐ 42000 · MIT
  • +Schnellster Weg zu RAG-Pipelines
  • +100+ Data-Connectors
  • +Geringerer Overhead als LangChain
  • Weniger stark bei Multi-Step Agents
↔ Alternativen: LangChain, Haystack

MLflow

MLOps-Plattform · ⭐ 22000 · Apache 2.0
  • +Standard für Experiment Tracking + Model Registry
  • +LLM-Observability nativ
  • +Minimales Setup
↔ Alternativen: Kubeflow, ZenML

DSPy

LLM-Compiler · ⭐ 23000 · MIT
  • +Programmiert LLMs statt zu prompten
  • +Automatische Prompt-Optimierung
  • +Wissenschaftlich fundiert (Stanford NLP)
  • Anderes Paradigma — Lernkurve
↔ Alternativen: LangChain, LlamaIndex

Communities & Plattformen: Wo das Ökosystem lebt

Die Tools und Modelle kennen — das ist der eine Teil. Zu wissen, wo die Community diskutiert, benchmarkt und Erfahrungen teilt — das ist der andere. Diese Plattformen sind der beste Kompass in der OS-Landschaft.

Hugging Face

Modell-Hub, Datasets, Spaces

Der zentrale Marktplatz des OS-KI-Ökosystems: >100k Modelle, >50k Datasets, >200k Spaces (Demo-Apps). 13 Millionen Nutzer (2026). Jedes hier aufgeführte Tool ist auf Hugging Face auffindbar — Modelle, Evaluationsergebnisse, Community-Bewertungen.

→ Mehr erfahren

Chatbot Arena

LMSYS Live-ELO-Rating

Der unabhängigste Modell-Vergleich: ELO-Rating basierend auf >2M menschlichen Bewertungen. Zeigt wo OS-Modelle wirklich stehen — nicht nur Benchmarks, sondern subjektive Qualität. DeepSeek V4, Claude 4, GPT-5, Llama 4 — alle im Direktvergleich.

Open LLM Leaderboard

Standard-Benchmarks auf HF

Der de-facto-Standard für reproduzierbare Modell-Benchmarks (MMLU, GSM8K, HumanEval, IFEval). Jedes neue OS-Modell wird hier automatisch getestet — das schafft Vergleichbarkeit über Anbieter hinweg.

Reddit r/LocalLLaMA

Community-Hub für lokale Modelle

400.000+ Mitglieder. Die zentrale Anlaufstelle für Erfahrungsberichte zu OS-Modellen auf Consumer-Hardware: Welches Modell läuft auf einer RTX 4090? Welche Quantisierung ist empfehlenswert? Welche neuen Fine-Tunes sind brauchbar? Tägliche Updates.

Projekt-Discords

vLLM, LangChain, Unsloth, Ollama u.a.

Jedes größere OS-Projekt hat einen aktiven Discord-Server. Das sind die Orte, wo echte Betriebserfahrung geteilt wird: Fehler, Workarounds, Konfigurationen. Oft hilfreicher als GitHub Issues oder Doku.

→ Mehr erfahren

Papers with Code

State-of-the-Art-Tracking

Zeigt für jede ML-Aufgabe, welches Modell aktuell State-of-the-Art ist — und ob es Open Source ist. Gut um den Gap zwischen OS und Frontier über konkrete Tasks zu verstehen.

Foundation Models: Die 4 relevantesten OS-Familien

Die Wahl des Foundation Models bestimmt, was in allen darüberliegenden Layern möglich ist. Vier Familien dominieren 2026 — jede mit eigenem Profil.

Meta Llama 4 Scout / Maverick

Llama 4 Community License

Stärken

  • +Beste OS-Ökosystem-Integration (HF, vLLM, Ollama)
  • +Scout: 10M Token Kontext (größtes Produktionsmodell)
  • +Maverick: 128 Experts MoE, stark auf Reasoning
  • +Sicherste Wahl für kommerzielle Nutzung

Zu bedenken

  • Community License mit Auflagen (Abgaben ab 700M MAUs)
  • Meta als US-Konzern — geopolitisches Risiko
📊 Scout: MMLU 89.1% · Maverick: MMLU 91.8%

Standard-Wahl — wenn Ökosystem und Tooling-Support priorisiert werden

Stärken

  • +Bestes Reasoning pro Dollar (37B aktiv von 671B)
  • +MMLU 94.2% — Spitzenreiter
  • +MIT-Lizenz ab V4 — voll kommerziell nutzbar
  • +Distilled Varianten auf Consumer-Hardware

Zu bedenken

  • China-basiert — DSGVO-Prüfung nötig
  • Trainingsdaten-Provenance nicht voll offen
  • Vendor-Risk bei geopolitischen Eskalationen
📊 MMLU 94.2% (V3) · V4-Pro: +5–8% auf Reasoning

Wenn maximale Reasoning-Performance pro Euro zählt — mit Prüfaufwand

Stärken

  • +Bester Allrounder und multilinguale Abdeckung
  • +Apache 2.0 — sauberste OS-Lizenz
  • +Breites Größenspektrum (0.8B bis 397B-A17B)

Zu bedenken

  • China-basiert (Alibaba)
  • Dokumentation teils nur auf Chinesisch
📊 Qwen 3.5 397B-A17B: MMLU 93.5%

Für multilinguale Workloads und Apache-2.0-Kompatibilität

Stärken

  • +Europäisches Unternehmen (Frankreich)
  • +675B Dense Flagship + 119B Small
  • +Stark auf EU-Regulierungskonformität ausgelegt
  • +Gute Tooling-Integration (vLLM, Ollama)

Zu bedenken

  • Kleineres Ökosystem als Llama
  • License teils restriktiver als Apache 2.0
📊 Large 3: MMLU 92.1% · Small: MMLU 88.3%

Bevorzugte Wahl wenn europäische Souveränität priorisiert wird

Die Abwägung: Was spricht für was?

Keine pauschale Antwort — aber diese Kriterien helfen, die richtige Frage zu stellen. Ich bin gespannt auf eure Erfahrungen: Wo stimmt ihr zu, wo widersprecht ihr?

» OS spricht, wenn

  • → Daten die eigene Infrastruktur nicht verlassen dürfen
  • → Wiederholbare, vorhersagbare Workloads
  • → Compliance selbst in der Hand liegen muss
  • → Langfristige Planungssicherheit gewünscht ist

» Frontier spricht, wenn

  • → Maximale Reasoning-Qualität den Unterschied macht
  • → Es um einmalige, komplexe Analysen geht
  • → Schnelle Iteration ohne Betriebsaufwand zählt
  • → Die Datenlage unkritisch ist

» Hybrid ist oft der klügste Weg

  • → OS als Default für 80% der Workloads
  • → Frontier als Fallback für schwierige Fälle
  • → Routing-Layer zwischen beiden (OpenRouter o.ä.)
  • → Exit-Strategie definieren, bevor man sich bindet

Fehlt eine Perspektive? Schreib mir — ich ergänze die Seite regelmäßig.

Vergleichsquellen und Benchmarks

Die Tool-Landschaft bewegt sich schnell. Diese externen Quellen werden regelmäßig aktualisiert und bieten aktuelle Vergleichsdaten.

Diese Landkarte lebt von euren Erfahrungen

Ich habe die Struktur und die Tools recherchiert — aber die wirklich wichtigen Fragen beantworten die, die damit arbeiten. Nutzt jemand von euch bereits DeepSeek V4 in Produktion? Wer hat Erfahrung mit Haystack vs LangChain? Was unterschätze ich gerade?

Datenbasis: Diese Seite basiert auf einer strukturierten Recherche zu 37 OS-Tools und Modellen. Die zugrundeliegende Knowledge Base (AI-Org KB) hält die konzeptionelle Struktur — die Tool-Liste wird separat geführt und quartalsweise aktualisiert.

Quellen: GitHub-Repositories, Chatbot Arena Leaderboard, Open LLM Leaderboard, sowie Vergleichsartikel und Benchmarks (alle verlinkt).

Stand: 2026-06-15 · Nächste Aktualisierung: 2026-09-15

Kein Anspruch auf Vollständigkeit. Die Tool-Landschaft entwickelt sich schnell. Fehlt ein wichtiges Tool oder eine Perspektive? Schreib mir — ich ergänze die Seite regelmäßig.