DeepWiki selbst gehostet: deepwiki-open mit lokalem Modell für Ihre privaten Repositories

Ein Code-Wiki aus den eigenen Repositories, auf der eigenen GPU

Ein selbst gehostetes DeepWiki liest ein privates Repository, erzeugt daraus automatisch eine Code-Dokumentation als Wiki mit Architekturseiten und Diagrammen und beantwortet Fragen zur Codebasis, alles auf einem Server in Ihrem Netz. Das unabhängige quelloffene Projekt deepwiki-open (MIT) leistet das mit einem lokalen LLM über Ollama oder einen OpenAI-kompatiblen Server wie vLLM. Eine Workstation mit einer NVIDIA RTX PRO 5000 Blackwell 72 GB betreibt das Embedding-Modell und ein 30B-Coding-Modell für eine Entwicklungsabteilung.

Das ursprüngliche DeepWiki stammt von Cognition. Seine Dokumentation beschreibt eine kostenlose Version für öffentliche GitHub-Repositories auf deepwiki.com, während Wikis für die Repositories, die ein Team verbindet, in der Devin-App entstehen; Wikis der Stufen Medium und High werden über die Nutzung des Teams abgerechnet. Eine selbst gehostete oder On-Premises-Variante nennt die Seite nicht. Unternehmen, die Code nicht an einen Cloud-Dienst senden dürfen, nutzen daher einen der quelloffenen Nachbauten unten.

Im Grundsatz arbeiten die Werkzeuge gleich. Sie klonen das Repository, zerlegen den Code in Abschnitte, wandeln jeden Abschnitt mit einem Embedding-Modell in einen Vektor um, planen eine Seitenstruktur und schreiben jede Seite mit einem Sprachmodell, das die passendsten Abschnitte sieht; deepwiki-open erzeugt seine Diagramme als Mermaid-Code. Derselbe Index bedient dann einen Chat über das Repository. Das hilft beim Einarbeiten neuer Entwickler, beim Dokumentieren von Code, dessen Autoren gegangen sind, und bei der Übergabe eines Projekts von einem Dienstleister. Für interaktive Hilfe beim Programmieren siehe unseren Leitfaden zum privaten Coding-Assistenten; diese Seite handelt von Dokumentation.

deepwiki-open im Oktober 2026

deepwiki-open wird von AsyncFuncAI unter der MIT-Lizenz veröffentlicht und zeigt auf GitHub 18.300 Sterne. Die Commit-Historie läuft weiter: Die neuesten Commits stammen vom 28. Oktober 2026 (eine Korrektur an DeepResearch) und vom 23. Oktober 2026 (angehobene Mindestversionen von Abhängigkeiten wegen Sicherheitshinweisen), und im September 2026 kamen ein LiteLLM-Docker-Profil und eine Opt-in-Einstellung zum Speichern von Prompts und Antworten in den Spend-Logs von LiteLLM hinzu. Die englische README ist auf eine kurze Beschreibung und einen Link mit dem Titel „Deepwiki-Open 2.0 (Grok Wiki is now live)“ gekürzt. Grok-Wiki ist ein anderes Produkt: Seine Website beschreibt „a local-first desktop workspace“, bietet einen macOS-Download an und leitet Modellaufrufe über Kommandozeilen-Agenten wie Codex CLI oder Claude Code. Der selbst gehostete Server liegt weiterhin im Repository, mit Dockerfiles, Konfigurationsdateien und der Ollama-Anleitung, und die übersetzten READMEs, etwa die französische, enthalten die vollständige Einrichtungsanleitung.

Die Anleitung beschreibt ein Next.js-Frontend auf Port 3000 und eine API auf Port 8001, gestartet mit docker-compose up oder dem Image ghcr.io/asyncfuncai/deepwiki-open:latest. Die Daten liegen dauerhaft in ~/.adalflow, das in den Container eingebunden wird: geklonte Repositories in repos/, Embeddings und Indizes in databases/, erzeugte Seiten in wikicache/. Die Compose-Datei begrenzt den Container auf 6 GB Speicher. Private Repositories werden mit einem Personal Access Token erreicht, das in der Oberfläche eingetragen wird; die Anleitung beschreibt das für GitHub und GitLab und nennt Bitbucket als unterstützten Host. Selbst betriebene GitLab- oder Bitbucket-Instanzen erwähnt sie nicht; die Ollama-Anleitung zeigt, wie ein lokaler Checkout unter /app/local-repos eingebunden wird, und das funktioniert mit jedem Git-Server, von dem Sie klonen können.

Code lokal halten, indem Sie beide Modellrollen umstellen

deepwiki-open nutzt zwei Modelle, und seine Voreinstellungen schicken beide Aufgaben in die Cloud. In generator.json ist Google mit gemini-2.5-flash der Standardanbieter, in embedder.json ist text-embedding-3-small von OpenAI der Standard-Embedder. Laut README ist für Embeddings ein OpenAI-Schlüssel nötig, außer im Ollama-Modus. Ein Unternehmen, dessen Code im eigenen Netz bleiben soll, muss beide Rollen umstellen.

Der dokumentierte Weg ist Ollama. Die Ollama-Anleitung lädt nomic-embed-text für den Index und qwen3:1.7b für die Seiten, und der Eintrag embedder_ollama ersetzt den OpenAI-Embedder. Die Generator-Datei nennt drei Ollama-Modelle mit ihrem Kontext: qwen3:1.7b und qwen3:8b mit num_ctx 32.000 und llama3:8b mit 8.000. Jedes geladene Modell lässt sich dort eintragen, und ein größeres schreibt bessere Seiten; die Anleitung selbst hält fest: „Local models may not match the quality of the latest cloud models“. Der zweite Weg ist ein OpenAI-kompatibler Server: OPENAI_BASE_URL richtet den OpenAI-Anbieter auf Ihren vLLM-Endpunkt, und die README beschreibt eine eigene Embedder-Datei für OpenAI-kompatible Embedding-Dienste.

Die Retrieval-Einstellungen in embedder.json erklären die Last. Der Textsplitter schneidet nach Wörtern in Abschnitte zu 350 mit einer Überlappung von 100, sodass alle 250 Wörter ein neuer Abschnitt beginnt, und jede Suche liefert die 20 besten Abschnitte. Eine Anfrage, die auf einer solchen Suche beruht, trägt damit nach unserer Rechnung etwa 7.000 Wörter Code und Text, dazu die Anweisungen; wie viele Token das sind, hängt von Sprache und Code ab, wie unser Artikel zu Token pro Wort erklärt. Ein Kontext von 32K Token ist das sinnvolle Minimum.

Der Dateifilter in repo.json ist so wichtig wie die Modelle. Standardmäßig überspringt er Verzeichnisse namens docs, Lock-Dateien, Konfigurationsdateien wie .env und pyproject.toml, CI-Dateien und Binärdateien und liest eine feste Liste von Code- und Dokumentendungen: Python, JavaScript und TypeScript, Java, C und C++, Go, Rust, PHP, Swift, C#, HTML und CSS sowie Markdown, Text, JSON und YAML. Kotlin- oder COBOL-Dateien etwa stehen nicht in der Standardliste; gleichen Sie sie daher vor dem ersten Lauf mit Ihren Sprachen ab.

Sie können die Workstation allein bestellen, die Einrichtung von Ollama oder vLLM, nomic-embed-text, einem Coding-Modell und deepwiki-open allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

OpenDeepWiki und andere DeepWiki-Alternativen

OpenDeepWiki von AIDotNet ist ein zweiter quelloffener Nachbau unter der MIT-Lizenz, mit 3.600 Sternen. Seine README beschreibt ein Backend auf ASP.NET Core mit .NET 10, ein Next.js-Frontend, SQLite oder PostgreSQL und Importe aus Git-URLs, ZIP-Archiven oder freigegebenen lokalen Verzeichnissen. KI-Anbieter und Modelle werden in seiner Admin-Konsole verwaltet; in compose.yaml wird das Hauptmodell mit ENDPOINT und dem Anfragetyp OpenAI eingestellt, und dort tragen Sie einen OpenAI-kompatiblen Server wie vLLM ein (prüfen Sie das im Pilotbetrieb), während OPENAI_BASE_URL und die Ollama-Einstellungen zur optionalen Erweiterung Graphify gehören. Es hat Benutzerkonten mit JWT, Rollen, Abteilungen und API-Schlüsseln, die die Dokumentation von deepwiki-open nicht beschreibt, sowie MCP-Endpunkte je Repository unter /api/mcp. Die README veröffentlicht die voreingestellten Administrator-Zugangsdaten und fordert selbst, JWT-Secret und Admin-Passwort vor jedem echten Einsatz zu ändern.

Teams, die bereits eine interne KI-Suche über Confluence oder SharePoint betreiben, nehmen die Repositories vielleicht lieber dort auf; unser Artikel zu Onyx als selbst gehosteter KI-Suche behandelt diesen Weg. Ein Wiki-Generator unterscheidet sich darin, dass er je Repository strukturierte Seiten schreibt, die ein neuer Entwickler der Reihe nach liest.

Welche GPU ein selbst gehostetes DeepWiki braucht

Für ein kleines Team passen beide Modelle auf eine Karte. nomic-embed-text v1.5 hat 137 Millionen Parameter, ist in der Bibliothek von Ollama 274 MB groß und steht unter Apache 2.0; seine Modellkarte auf Hugging Face nennt eine Sequenzlänge von 8.192. Den Rest belegt das Generierungsmodell. Wir dimensionieren nach unserer Nutzer-pro-Karte-Regel: 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB je Karte und abzüglich der Gewichte beider Modelle, geteilt durch den Cache je Anfrage. Das lässt 18,5 GiB auf einer RTX PRO 4000 mit 24 GB, 40,0 GiB auf der RTX PRO 5000 48 GB, 61,5 GiB auf der Version mit 72 GB und 83,0 GiB auf einer RTX PRO 6000 mit 96 GB.

Gleichzeitige Anfragen zu 32K Token nach unserer Nutzer-pro-Karte-Regel, neben nomic-embed-text (274 MB), BF16-Cache (FP8-Cache in Klammern; gpt-oss-20b nur mit BF16-Cache). Gewichte von Hugging Face, gelesen am 30. Oktober 2026: gpt-oss-20b 13,76 GB, Qwen3-Coder-30B-A3B FP8 31,2 GB. Cache je 32K: 0,75 GiB (gpt-oss-20b), 3 GiB (Coder-30B-A3B), nach unserer Rechnung aus der jeweiligen config.json.

gpt-oss-20b ist ein 21B-Modell mit 3,6B aktiven Parametern unter Apache 2.0, das laut der Modellkarte von OpenAI dank MXFP4 „within 16GB of memory“ läuft. Es schreibt lesbare Seiten und passt auf die kleinste Karte. Qwen3-Coder-30B-A3B (30,5B, 3,3B aktiv, Apache 2.0) ist ein für Code trainiertes Modell und braucht die Karte mit 48 oder 72 GB; auf der 48-GB-Version ist der Platz für Anfragen knapp, daher ist die 72-GB-Karte die komfortable mittlere Stufe, wie unser Vergleich der RTX PRO 5000 mit 48 GB und 72 GB darlegt. Beide Versionen der RTX PRO 5000 sind Karten mit 300 W; eine Workstation mit einer davon nimmt nach unserer Schätzung etwa 0,75 kW an der Steckdose auf (300 W plus ein Prozessor der 350-W-Klasse, dazu 15 Prozent für den Rest).

Wie lange der erste Durchlauf über ein Repository dauert, hängt von der Größe des Repositorys ab, von der Zahl der Seiten im Wiki, von der Länge jeder Seite und davon, wie viele Anfragen das Werkzeug gleichzeitig sendet. deepwiki-open veröffentlicht keine Durchsatzwerte. Der nächstliegende veröffentlichte Wert ist NVIDIAs Tabelle für maximalen Durchsatz, in der eine RTX PRO 6000 Server Edition mit Qwen3-30B-A3B in FP4 bei Prompts von 8.192 Token 1.914 und bei Prompts von 32.768 Token 374 Ausgabe-Token pro Sekunde erzeugt, mit allen Anfragen gleichzeitig in der Warteschlange; ein Werkzeug, das eine Seite nach der anderen schreibt, erreicht weit weniger. Der Embedding-Durchlauf ist im Vergleich klein: Ein Repository mit zwei Millionen Wörtern Code ergibt nach unserer Rechnung etwa 8.000 Abschnitte, jeder einmal je vollständigem Index eingebettet.

Das Wiki aktuell und richtig halten

Ein erzeugtes Wiki altert mit jedem Merge. deepwiki-open speichert erzeugte Seiten in wikicache/ und dokumentiert keine Aktualisierung je Merge. Richten Sie die Neuerzeugung daher als zeitgesteuerten Job außerhalb der Arbeitszeit ein, und testen Sie, wie Ihre Version sie auslöst. Nächtlich genügt den meisten Teams; ein Repository mitten in einem großen Refactoring braucht sie eher nach jedem Release. Auf einem Server, den sich das Wiki mit dem Coding-Assistenten teilt, füllen diese Läufe die Stunden, in denen die Agenten der Entwickler ruhen, wie in unserem Artikel zur LLM-Batch-Inferenz. Planen Sie einen solchen gemeinsamen Server, fragen Sie uns, welche Karten beide Aufgaben tragen.

Die Seiten sind Entwürfe, und ein Sprachmodell kann eine Architektur beschreiben, die es nicht gibt. Kennzeichnen Sie das Wiki als erzeugt, geben Sie jedem Repository einen Verantwortlichen, der die Übersichtsseiten nach dem ersten Lauf liest, und lassen Sie handgeschriebene Architekturentscheidungen dort, wo sie sind.

Zugriffsschutz für Wiki und Modellserver

Ein Wiki aus einem privaten Repository enthält dasselbe Wissen wie das Repository, und jeder, der das Wiki öffnen kann, liest es. deepwiki-open hat einen gemeinsamen Schutz, einen Autorisierungscode über DEEPWIKI_AUTH_MODE und DEEPWIKI_AUTH_CODE, und seine README warnt, dass dieser Code die Erzeugung nicht vollständig verhindert, wenn die API-Endpunkte direkt erreicht werden. Die Compose-Datei veröffentlicht die Ports 3000 und 8001 auf dem Host. Stellen Sie den Server hinter einen Reverse Proxy mit Ihrer Firmenanmeldung, halten Sie Port 8001 aus dem Netz heraus und betreiben Sie für Repositories mit unterschiedlichen Lesern getrennte Instanzen, oder nutzen Sie OpenDeepWiki mit seinen Rollen. Die Zugriffstoken für den Git-Server sollten nur lesen dürfen und einem Dienstkonto gehören.

Der Modellserver braucht dieselbe Sorgfalt: Ollama ab Version 0.35.0 und vLLM nur auf einer internen Adresse, wie unser Artikel zum Absichern eines GPU-Servers erklärt. Eine Offline-Installation, bei der Modelle und Images ohne Internetzugang ins Haus kommen, folgt unserem Leitfaden zum Air-Gapped-LLM-Server.

Wir richten Wiki, Modelle und den Zugriffsschutz davor auf Ihrem System ein; nennen Sie uns, wie viele Repositories dokumentiert werden sollen und wer sie lesen soll, und wir schlagen die Konfiguration für Ihre Aufgaben und Ihr Budget vor.

FAQ