Alles lokal – der Aufbau eines Offline-KI-Workspaces

 (instavm.io)
6 Punkte von GN⁺ 2025-08-09 | 2 Kommentare | Auf WhatsApp teilen
  • Lokale LLM-Ausführung und Code-Sandbox werden genutzt, um einen KI-Workspace ohne Cloud-Abhängigkeit aufzubauen.
  • Ollama für die lokale LLM-Ausführung, Apple Container für die Codeausführung in einer isolierten VM und Playwright für Automatisierung sowie Internetzugriff über einen Headless-Browser.
  • Das UI basiert auf assistant-ui und implementiert Modellauswahl-Dropdown mit ai-sdk-Integration sowie eine sichere Codeausführungsumgebung über MCP (Model Context Protocol).
  • In einer per MCP angebundenen Coderunner-VM werden Jupyter-Server und Browser ausgeführt, sodass Diagrammerstellung, Bild-/Videobearbeitung, Installation von GitHub-Tools und Websuche in einer Datenschutzschutzumgebung möglich sind.
  • Aktuell ist es nur für Apple Silicon geeignet, und zukünftige Aufgaben sind UI-Verbesserung, Browser-Umgehung zur Bot-Erkennung und Ausbau des Tool-Managements.

Anforderungen und Hintergrund

  • Ziel: alles lokal ausführen, ohne Cloud- oder Remote-Code-Ausführung.
  • Bestehende LLM-Chat-Apps (z. B. ChatGPT, Claude) bieten Cloud-LLM-Chat, Cloud-/lokale Codeausführung und Internetzugriff.
  • Mit dem Anstieg von Open-Source-LLMs stellte sich die Frage, ob all diese Funktionen vollständig lokal umgesetzt werden können.
  • Ein reines lokales LLM reicht nicht aus; Code sollte in einer isolierten Umgebung laufen und auch Browser-Zugriff auf Inhalte ist notwendig.

Idee und Konzeption

  • Das LLM vollständig in der lokalen Umgebung ausführen.
  • Leichte VM (virtuelle Maschine): Codeausführung nur dort verarbeiten, um das Host-System zu schützen.
  • Headless Browser ergänzen, um Automatisierung sowie Suche nach neuen Informationen und Tools zu ermöglichen.
  • Einen vollständig lokalen, datenschutzzentrierten Workflow aufbauen, von der KI-Idee bis zur Codeausführung.
  • Vielfältige Aufgaben wie Bild- oder Videobearbeitung lokal erledigen, ohne Daten an externe Dienste zu senden.

Technologiestack

  • LLM: Ollama (lokale Modelle und Unterstützung einiger externer Modelle)
  • UI: assistant-ui + ai-sdk (Erweiterung der Modellauswahl)
  • VM-Laufzeitumgebung: Apple container (liefert eine isolierte VM-Umgebung)
  • Orchestrierung: instavm/coderunner (MCP-Anbindung eines Jupyter-Servers)
  • Browser-Automatisierung: Playwright (als MCP-Tool bereitgestellt)

Mac-App-Versuche und Umstieg

  • Der Versuch, eine native Mac-App mit a0.dev zu bauen, scheiterte an iOS-Fokus.
  • Ein Ansatz mit Electron + NextJS wurde ebenfalls versucht, aber wegen der Komplexität verworfen.
  • Letztlich wurde auf eine lokale webbasierte assistant-ui umgestellt.

Assistant-UI-Anpassung

  • Zwar wurde erwartet, dass ein Modell-Auswahl-Dropdown verschiedene LLMs unterstützt, aber die Funktionalität war begrenzt.
  • Nach dem Studium von Beispielen wurde die Auswahl mehrerer Modelle direkt über ai-sdk umgesetzt.
  • Zu Beginn wurden auch Cloud-Modelle wie OpenAI/Anthropic unterstützt, mit einer schrittweisen Strategie zur Migration auf lokal.

Tool-calling und Modellunterstützungsprobleme

  • Es wurden Modelle benötigt, die Tool-calling unterstützen; bei einigen wie Ollama ist das in der Praxis nicht gegeben.
  • In offiziellen Dokumenten ist Tool-Unterstützung oft angegeben, doch die tatsächliche Implementierung ist häufig unzureichend.
  • Durch die rasche Entwicklung im Open-Source-Ökosystem schwanken sowohl der Tool-Support als auch die Tokenpreise stark.

Containerbasierte isolierte Codeausführung

  • Mit Apples Container-Werkzeug, das pro Container im Vergleich zu Docker eine vollständig isolierte VM-Umgebung bereitstellt, kann KI-generierter Code sicherer ausgeführt werden.
  • In der VM wird ein Jupyter-Server bereitgestellt, der über das Model Context Protocol (MCP) exponiert wird, damit verschiedene Tools (Claude Desktop, Gemini CLI usw.) sofort nutzbar sind.
  • Der coderunner-MCP-Servercode wurde veröffentlicht und zeigt Integrationsbeispiele mit externen Tools.
  • Das Apple Container-Tool ist noch instabil, sodass bei Build-/Imageproblemen wiederholte Neustarts nötig sind.
  • Bei echten Video-Editing-Tests wurde das Zusammenspiel von UI + LLM + Coderunner erfolgreich validiert.

Headless-Browser-Integration

  • Innerhalb des Containers wurde ein auf Playwright basierender Headless-Browser bereitgestellt und als MCP-Tool exponiert.
  • Erwartete Einsatzmöglichkeiten: Entdeckung neuer Tools/Informationen, Suche nach GitHub-Nutzung, Automatisierung von Recherchen.
  • Der Basis-Workflow ist abgeschlossen: Kombination aus lokalem LLM + Sandbox-Codeausführung + Headless-Browser.

Mögliche Aufgabenbeispiele

  • Forschung und Zusammenfassung zu spezifischen Themen
  • Erstellung und Darstellung von CSV-Charts per natürlicher Sprache
  • Videobearbeitung mit ffmpeg (z. B. Teilen schneiden)
  • Bildgröße ändern, Zuschneiden, Formatumwandlung
  • Installation von GitHub-Tools innerhalb des Containers
  • Web-Crawling und -Zusammenfassung mit Headless-Browser

Datei-Volume-Mount und Isolation

  • Der Host-Pfad ~/.coderunner/assets wird auf den Containerpfad /app/uploads gemountet, Dateien werden in einem sicheren Freigabebereich abgelegt.
  • Ausgeführter Code kann nicht direkt auf das Host-System zugreifen, wodurch die Sicherheit erhöht wird.

Grenzen und nächste Schritte

  • Funktioniert nur in Apple-Silicon-Umgebungen; macOS 26 ist optional.
  • UI-Verbesserungen sind nötig, etwa Tool-Management und Output-Streaming.
  • Der Headless-Browser wird auf einigen Seiten wegen Bot-Erkennung blockiert.

Fazit

  • Dieses Projekt ist mehr als nur ein Experiment und hat Rechenhoheit sowie Datenschutz zum Fokus.
  • Es bietet die Möglichkeit, Daten sicher auf der eigenen lokalen Maschine zu verarbeiten, ohne Abhängigkeit von Cloud- oder Remoteservern.
  • Das beste LLM kann in großen Clouds bleiben, das Ziel ist jedoch die Weiterentwicklung lokaler KI-Tools, die persönliche Privatsphäre schützen.
  • Die Open-Source-coderunner-ui ist auf GitHub verfügbar; Feedback und Kollaboration sind willkommen.

Relevante Ressourcen

Verwandte Beiträge

2 Kommentare

 
wedding 2025-08-11

Ich stimme der Meinung auf HN zu, dass es eher einem reinen Hobby näherkommt. Auch wenn man es hier und da aufpoliert, kann man nicht dieselbe Bequemlichkeit und Geschwindigkeit wie bei einem kommerziellen Produkt erreichen.
 
GN⁺ 2025-08-09
Hacker News Kommentar

  • Ich liebe diesen Idealismus eigentlich immer, aber wenn ich die Modellqualität, auf die ich Zugriff habe, und die laufenden Kosten für On-Demand-Nutzung in der Cloud einrechne, ist das eher ein nettes Hobby als eine echte Strategie. Da die Hardware immer schneller veraltet, verliere ich auch mit gebrauchter Hardware den Wert extrem schnell, sodass eine Investition in Hardware kaum zu rechtfertigen ist. Dazu kommt, dass die Performance der lokal laufenden Gewichte ebenfalls deutlich schlechter ist, daher lohnt es sich im Moment nicht. Ich hoffe, dass sich das irgendwann ändert, und freue mich darauf, in lokale Inferenz-Stacks zu investieren, sobald gute Gewichte veröffentlicht werden. Bis dahin bleibt einem nur, teure, schnell entwertete Assets zu „parken“.

  • Ich finde das aktuelle lokale LLM-Ökosystem wirklich spannend und beobachte gern, was die Leute damit machen. Aber jedes Mal, wenn ich ein lokales LLM auf meinem MacBook Pro mit riesigem RAM selbst starte, spüre ich den Abstand zu Frontier-Modellen (aktuellen SaaS-LLMs) sehr deutlich. Für rund 20 $ im Monat zahlt man nur pro Token und kann dafür zahlreiche Hochleistungsmodelle nutzen, doch in Tempo und Qualität liegt lokal nach wie vor ein großer Abstand. In Benchmark-Charts wird diese Lücke kaum sichtbar, doch praktisch empfinde ich Frontier-Modelle als deutlich besser. Auch bei Modellen von OpenAI oder Anthropic wirken diese manchmal langsam und fehleranfällig – lokal verstärkt sich das. Für Hobby- oder Experimentierzwecke, bei denen Datenschutz wichtig ist, ist das lokal vielleicht gut, für mich persönlich wäre es aber besser, bis echte Hardware wie ein MacBook der nächsten Generation mit 128 GB RAM erscheint, zu warten.

  • Ich glaube, dass Modelle hinter APIs mit der Zeit schlechter werden, sobald sie anfangen, Geld mit den Ausgaben zu verdienen. Ich sehe das als Frage der Zeit.

  • Ich frage mich, wie gut das Argument trägt, dass „sich Hardware so schnell verändert, dass selbst gebraucht gekaufte Geräte sofort an Wert verlieren“. Je nach Fall kann ein Modell auch mit nicht maximaler Specs weiterlaufen. Letztlich ist das die klassische opex-vs-capex-Debatte: Finanztechnisch ist Cloud vorteilhaft nur in wirklich wenigen Fällen, etwa wenn man Infrastruktur blitzschnell hochfahren muss und die Nachfrageschätzung unsicher ist. Für LLMs trifft das nach meiner Erfahrung kaum zu. Der OP meint, er habe rund 600 $ investiert, was ungefähr einem Drei-Monats-Preis auf EC2 entspricht. Daraus frage ich mich, ob die Zahlen die Argumentation tatsächlich stützen.

  • Auch ich erwarte einen Wandel. Ich nutze Dinge wie Claude Code zunehmend in meiner Arbeit und möchte meinen Coding-Alltag nicht vollständig auf ein Unternehmen stützen. Tariflimits, API-Kosten, monatlich 100–200 $ und die Sorge, dass all meine Daten von einem KI-Unternehmen gesammelt oder überwacht werden könnten, spielen ebenfalls eine große Rolle. Ich nutze im Smart-Home nur Geräte, die lokal gesteuert werden; wenn externer Zugriff nötig ist, richte ich die Software selbst ein, damit sie auf meinem eigenen Server läuft. Wenn ein Anbieter plötzlich abschaltet, Preise erhöht oder meine Daten nutzt, möchte ich mich nicht darauf verlassen. Aber im Moment habe ich weder Motivation noch Geld, noch die nötige Wartungskompetenz, um ein LLM lokal oder auf einem VPS zu betreiben. Ich bin mit den 20 $ monatlich bei Anthropic zufrieden, und die aktuell verfügbaren Open-Modelle bleiben weit hinter SaaS-Modellen auf Frontier-Niveau zurück. Ich hoffe trotzdem, dass sich das irgendwann ändert.

  • Ich glaube, dass sich die Lage nicht verändern wird. Selbst wenn es in zwei Jahren eine lokale Option auf GPT-5-Niveau gibt, wird es auf der Cloud-Seite womöglich noch deutlich bessere Alternativen geben – so dass man genau vor dieselben Fragen gestellt ist.

  • Ich halte diesen Fokus auf eine lokale, sandbox-artige Ausführungsschicht für ein wichtiges Puzzleteil auf dem Weg zu einem privaten KI-Workspace. Das coderunner-Tool wirkt extrem nützlich. Eine weitere Aufgabe ist die „Knowledge Layer“, in der KI persönliche Daten wie E-Mails, Notizen und Dateien erkennt. Bei RAG kann das Speichern mehrjähriger E-Mails sehr schnell über 50 GB in der Vektordatenbank liegen. (Nur zur Einordnung: Ich war bei einem Team in Berkeley, das genau an diesem Problem gearbeitet hat.) Wir haben mit LEANN einen Vektorindex gebaut, der nicht einmal die Embeddings selbst speichert und so den Speicherbedarf um rund 97 % senkt. So wird das vollständige lokale Indexieren des gesamten digitalen Lebens tatsächlich möglich. Eine Kombination aus solch einem ultraleichten Wissensindex und einem lokalen Ausführungs-Engine fühlt sich wie der Weg zu einem echten „lokalen Jarvis“ an. Code: https://github.com/yichuan-w/LEANN
    Paper: https://arxiv.org/abs/2405.08051

  • Für 2025 finde ich 50 GB als Bedarf für RAG auf Basis einiger Jahre an E-Mails eher moderat.

  • Danke für den Hinweis zu LEANN. Ich bin besonders interessiert daran, RAG als Wissensschicht für LLM-Agenten, Pipelines oder Ausführungs-Engines zu nutzen. Mich interessiert, ob man große Codebasen mit einem LLM verknüpfen kann; es macht die Hürden geringer zu experimentieren, dass es bereits eine RAG-Lösung gibt, die mit Claude Code integriert ist. Ich würde gerne wissen, ob jemand hier schon mit einer Kombination aus RAG und LLM an einem großen Codebestand arbeiten durfte. Als Frontend-Modell (LM) möchte ich zunächst über Cloud starten und es selbst testen. Referenz: https://github.com/yichuan-w/LEANN/blob/main/packages/leann-mcp/README.md

  • Ich kenne Embedding- und Vektorspeicherstrukturen fast gar nicht. Ich bin gespannt, ob es auch in Cloud-Embeddings Projekte gibt, die so etwas wie ein „pruned graph“ nutzen.

  • Dass ein Index größer als die Originaldaten ist, wirkt für mich seltsam. Normalerweise stelle ich mir Indizes als effizientere Struktur für schnellen Zugriff vor; so starkem Wachstum fühlt es sich komisch an.

  • Ein Grund, warum sogar das „beste LLM“ nicht immer so flüssig hilft, ist, dass diese Modelle Stufen überspringen, plattformspezifische Eigenheiten ignorieren und sogar Probleme durch Halluzinationen weiter verschärfen können. Das zeigt deutlich, dass es an Trainingsdaten für native App-Entwicklung fehlt. Es gibt kaum lange Blog- oder Medium-Artikel zur nativen App-Gestaltung, und Open-Source-Desktop-App-Projekte sind im Vergleich zu Mobile/Web sehr selten. In den 1990ern hat Microsoft professionelle Autoren engagiert und exzellente Bücher zur Windows-Programmierung veröffentlicht (z. B. von Charles Petzold), doch diese spezialisierte Industrie ist heute fast verschwunden. Genau deshalb werde ich erwarten, dass diese Lücken in den Trainingsdaten künftig größer werden. Das spiegelt sich auch in der gesamten Software-Engineering-Welt wider: Wer native Desktop-Apps baut, ist zu wenige an der Zahl, und aus Karriereperspektive ist das oft ein „dead end“.
    In den 1990ern war ein Windows-Desktop-Entwickler noch ein Job mit bürgerlichem Auskommen und hohen Hürden (C/C++ war hart, das Lernen der Windows API schwierig, Microsoft investierte massiv in Ausbildung), aber die Situation hat sich stark verändert. Außer bei OS-Anbietern wie Microsoft, Apple oder wenigen Legacy-Firmen wie Adobe und Autodesk ist die Nachfrage nach Desktop-Apps heute extrem gering.

  • Abseits von High-Performance-Computing (HPC) braucht man für Desktop-Apps oft keinen separaten Ansatz, weil der Browser faktisch die universellste Virtual-Machine-Rolle übernimmt.

  • Ich habe die Ollama-macOS-App testweise ausprobiert und bemerkt, dass sie nach dem Start sofort versuchte, auf eine Google-Domain zuzugreifen. Das macht es schwer, dem Versprechen vollständiger Privatsphäre zu glauben. https://imgur.com/a/7wVHnBA

  • Das liegt einfach am automatischen Update-Check. https://github.com/ollama/ollama/blob/main/docs/faq.md

  • Solche Netzwerkaufrufe wirken gerade wegen der Möglichkeit eines Audits vertrauenswürdiger. Es ist völlig beherrschbar, wenn man bei jedem Update automatisch die Netzwerkaufrufe trackt.

  • Dasselbe habe ich bei den VSCode-Plugins cline und copilot gesehen. Als ich die Einstellungen auf nur lokales Ollama gesetzt und ausgehende Verbindungen blockiert habe, funktionierte das Ganze nicht mehr. Selbst mit deaktivierter Telemetrie versucht cline weiterhin, extern zu kommunizieren – sehr enttäuschend.

  • Ich denke erstaunlich oft über genau diese Themen nach. Mir wird klar, dass Privacy mit sehr vielen Reibungsverlusten und Schwierigkeiten einhergeht.

  • Ich glaube nicht, dass dieser Beitrag wirklich dabei hilft oder konkrete Lösungen liefert.

  • Ich bevorzuge lokal immer noch, vor allem, weil die KI-Inferenz meistens langsam ist oder lokal kaum Unterschiede bringt. Nachdem ich kürzlich Cerebras (und auch Groq, von dem ich gehört habe) getestet habe und Geschwindigkeiten um 1000 Token/Sekunde gesehen habe, haben sich meine Geduldsgrenzen beim Warten komplett verschoben. Cerebras gibt an, keine Daten zu speichern, und ich würde mich freuen, wenn ich darauf vertrauen könnte, dass es keine Sponsoring-Beziehung gibt (eigentlich hätte ich sogar gerne eine). Ich halte den Service für wirklich gut. Trotzdem wünsche ich mir noch einen echten, signifikanten Fortschritt bei der Geschwindigkeit. Die Diffusionsmodell-Architektur fühlt sich besonders schnell an.

  • Ich glaube, die Grenze liegt jetzt eher an der Hardware als an der Software. Um ein brauchbares LLM lokal zu betreiben, braucht man mindestens Hardware für etwa 2000 $ (z. B. Strix Halo, AI Max 395). Ich hoffe, dass es deutlich einfacher wird, wenn Strix Halo noch einige Upgrades bekommt.

  • Solche Änderungen passieren wirklich schnell. https://simonwillison.net/2025/Jul/29/space-invaders/

  • Selbst wenn man Hardware in dieser Preisklasse besitzt, ist die Schwelle für ein „brauchbares“ System selbst für mich unscharf. Damit die Technik wirklich nützlich ist, braucht man eine Art sofortiges, fast magisches Erlebnis. Sobald man auf langsame, unscharfe Ergebnisse stößt und dauerhaft am Setup schrauben muss, ist fast der gesamte Wert weg. Lokale Modelle haben sich enorm verbessert, aber aus Sicht der Coding-Performance reichen sie noch nicht an Claude heran. Ich habe die neuesten Qwen- und GLM-Modelle auf OpenRouter direkt mit cline getestet und sie ungefähr auf Niveau von Claude 3.0 eingeordnet. Benchmarks spiegeln die Realität meiner Meinung nach schlecht wider.

  • Die Produkt- und Blog-Kommunikation wirkt etwas verwirrend. Auf der Website wird dargestellt, dass man eine VM in der Cloud hochfährt (ähnlich wie mit Firecracker), im Blog-Artikel erscheint es aber eher so, als würde auf dem Mac eine lokale VM laufen. Ich habe die erstere Version gebaut und würde gern die zweite mit dem neuen gpt-oss-Projekt ausprobieren.

  • Hinweis an den OP: der Link https://github.com/assistant-ui/assistant-ui funktioniert nicht.

  • Es ist ein wirklich cooles und gut durchdachtes Projekt. Ich baue etwas Ähnliches, und der Kern ist es, einen einfachen Wechsel zwischen Cloud und vollständig lokaler Umgebung mit einem Tastendruck zu ermöglichen. Alle Daten/Settings/Prompts werden ausschließlich lokal gespeichert, und API-Aufrufe werden ohne Umweg über unseren Server direkt zu den Providern geroutet. Derzeit läuft die komplett lokale Inferenz im Browser über mlc-llm (Qwen3-1.7b funktioniert dort sehr gut). https://hypersonic.chat/