Local Studio: lokale Modelle im Unternehmen betreiben

Direkte Antwort

Local Studio ist eine Bedienoberfläche für selbst gehostete Sprachmodelle. Sie bündelt vLLM, SGLang, llama.cpp und MLX hinter einer einzigen OpenAI-kompatiblen Schnittstelle, zeigt an, was die Hardware gerade tut, und bringt eine Agenten-Umgebung mit. Apache-2.0-Lizenz, rund 1.500 Sterne auf GitHub, läuft auf macOS mit Apple Silicon und auf Linux.

Für eine einzelne Person, die abends ein Modell ausprobiert, ist das überdimensioniert. Ollama ist dafür schneller startklar.

Interessant wird es eine Ebene höher: wenn nicht eine Person, sondern eine Abteilung mit dem Modell arbeitet — und wenn die Dokumente, die dabei durchlaufen, das Haus nicht verlassen dürfen. Genau dort hört der Werkzeugkasten für Einzelnutzer auf.

Was Local Studio anders macht

Der Kern ist unspektakulär und genau deshalb nützlich: eine Schnittstelle für vier Inferenz-Engines.

Wer lokal arbeitet, landet früher oder später bei mehr als einem Backend. llama.cpp ist genügsam und läuft überall. MLX ist auf Apple Silicon schneller. vLLM und SGLang sind gebaut, um viele Anfragen gleichzeitig zu bedienen, brauchen dafür aber NVIDIA-Hardware. Die Wahl hängt an Modell, Maschine und Lastprofil und ändert sich über die Zeit.

Ohne eine Zwischenschicht bedeutet jeder Wechsel: andere Kommandozeile, andere Konfiguration, andere API. Anwendungen, die darauf aufsetzen, müssen angefasst werden.

Mit der Zwischenschicht bleibt die Schnittstelle gleich. Die eigene Anwendung spricht weiter OpenAI-kompatibel, während darunter die Engine getauscht wird. Das klingt nach einer Kleinigkeit und ist in der Praxis der Unterschied, ob ein Wechsel eine Konfigurationsänderung ist oder ein Projekt.

Dazu kommen die Dinge, die im Betrieb fehlen, sobald mehr als eine Person zugreift: sichtbarer Zustand von GPU und Laufzeit, Agenten-Sitzungen an derselben Stelle wie das Modell, und eine Proxy-API, hinter der sich das alles versammelt.

Wenn die Dokumente das Haus nicht verlassen dürfen

Hier liegt der eigentliche Anwendungsfall, und er ist in Deutschland schärfer als in den meisten Märkten.

Die übliche Erzählung über lokale Modelle dreht sich um Kosten oder um Unabhängigkeit von Anbietern. Beides stimmt. Für einen erheblichen Teil der deutschen Wirtschaft ist aber ein drittes Argument das ausschlaggebende: Es gibt Unterlagen, bei denen die Weitergabe an Dritte nicht eine Abwägung ist, sondern ein Problem.

Und die Rechnung dahinter ist bodenständiger, als sie klingt. Ein Rechner mit 128 GB Unified Memory kostet ungefähr so viel wie ein Monat Beratung. Er trägt ein Modell der Klasse 27B bis 32B, bedient damit eine kleine Abteilung, steht im Serverschrank und wird nachts gesichert. Für die meisten Häuser, um die es hier geht, ist das die realistischere Antwort als ein Rechenzentrumsprojekt — und deutlich realistischer als die Hoffnung, dass niemand die vertraulichen Dokumente in ein Cloud-Fenster kopiert.

Berufsgeheimnisträger

Rechtsanwälte, Steuerberater, Ärzte, Psychotherapeuten und einige weitere Berufe unterliegen § 203 StGB. Die unbefugte Offenbarung eines anvertrauten Geheimnisses ist dort nicht als Ordnungswidrigkeit geregelt, sondern als Straftat. Das ist ein anderer Hebel als ein Bußgeldrisiko.

Der Gesetzgeber hat 2017 eine Neuregelung geschaffen, die die Mitwirkung Dritter an der Berufsausübung ausdrücklich ermöglicht — IT-Dienstleister eingeschlossen. Cloud-Nutzung ist also nicht per se verboten. Sie ist an Bedingungen geknüpft: Die mitwirkenden Personen müssen zur Verschwiegenheit verpflichtet werden, und der Berufsgeheimnisträger bleibt in der Verantwortung, sorgfältig auszuwählen.

Ein lokal betriebenes Modell umgeht diese Schicht nicht — sie entfällt. Wo keine Daten an einen Dritten gehen, gibt es keinen Dritten zu verpflichten und keine Auswahl zu begründen. Das ist kein juristischer Trick, sondern schlicht ein einfacherer Sachverhalt.

Was hier steht, ist eine Einordnung und keine Rechtsberatung. Die Prüfung im Einzelfall gehört zu jemandem mit Zulassung.

Besondere Kategorien nach Artikel 9

Gesundheitsdaten, biometrische Daten und einige weitere Kategorien stehen nach Artikel 9 DSGVO unter einem grundsätzlichen Verarbeitungsverbot mit Ausnahmen. Die Anforderungen liegen spürbar über denen gewöhnlicher personenbezogener Daten.

Für eine Praxis, die Befunde zusammenfassen oder Arztbriefe vorformulieren lassen will, heißt das: Der Weg über einen Cloud-Dienst ist nicht unmöglich, aber er erzeugt Dokumentations- und Prüfaufwand, der in keinem Verhältnis zum Nutzen steht. Ein Modell, das auf dem Rechner im Nebenraum läuft, verlagert die Frage von „unter welchen Bedingungen dürfen wir übermitteln” zu „wer im Haus darf zugreifen” — und das ist eine Frage, die jede Praxis ohnehin schon beantwortet hat.

Konstruktionsdaten und Betriebsgeheimnisse

Der dritte Fall hat mit Personenbezug nichts zu tun und wird deshalb oft übersehen.

Ein Ingenieurbüro mit Konstruktionsdaten, ein Maschinenbauer mit Fertigungsparametern, eine Kanzlei mitten in einer Transaktion: Hier greift keine DSGVO und kein § 203, sondern schlicht wirtschaftliche Existenz. Die Frage ist nicht, ob eine Übermittlung zulässig wäre, sondern ob man sie will — und ob man dem eigenen Kunden erklären möchte, dass seine Zeichnungen zur Verarbeitung an einen Dienstleister außerhalb der EU gegangen sind.

Erfahrungsgemäß ist das der Fall, bei dem die Entscheidung am schnellsten fällt. Es braucht keine Rechtsprüfung, um zu erkennen, dass man bestimmte Dateien nicht hochlädt.

Was tatsächlich erfüllt sein muss

Lokal allein ist noch keine Compliance. Nüchtern betrachtet gehören dazu:

• Zugriffskontrolle im Haus. Wer darf welches Modell mit welchen Dokumenten benutzen? Ein lokal laufendes Modell ohne Zugriffsbeschränkung ist kein Fortschritt, sondern eine neue offene Tür.
• Protokollierung. Nachvollziehbar, wer wann was verarbeitet hat — genau die Anforderung, die auch für jedes andere Verfahren gilt.
• Löschkonzept. Auch lokale Systeme halten Kontexte, Protokolle und Zwischenstände vor.
• Verzeichnis von Verarbeitungstätigkeiten. Ein lokales Modell fällt nicht heraus, nur weil kein Dienstleister beteiligt ist.
• Die Erkenntnis, dass das Modell irren kann. Ein falsch zusammengefasster Befund ist lokal genauso falsch wie in der Cloud.

Was lokal wegfällt, ist der schwierigste Teil: Auftragsverarbeitung, Drittstaatentransfer und die Frage, was ein Anbieter mit den Eingaben tut. Was bleibt, ist gewöhnliche IT-Sorgfalt. Die DSGVO-Einordnung auf dieser Site geht darauf im Detail ein.

Zugriff vom Handy

Zu Local Studio gehört ein zweites Projekt: Litter, im App Store als KittyLitter, ein nativer Client für iOS und Android unter GPLv3. Er findet Agenten im lokalen Netz automatisch, verbindet sich per SSH auf entfernte Maschinen oder über eine Peer-to-Peer-Kopplung. Für die gemeinsame Nutzung mit Local Studio braucht es Version 2.9.0 auf der einen und 1.6.0 auf der anderen Seite.

Der Reiz liegt auf der Hand: das Modell steht im Büro, die Anfrage kommt vom Handy, und die Daten bleiben trotzdem im Haus.

Ein Hinweis, der auf dieser Site nicht fehlen darf: Litter ist kein Datenschutz-Werkzeug an sich. Die App ist ein Client für Coding-Agenten und unterstützt neben OpenCode und Pi auch Codex und Claude — beides Cloud-Dienste. Wer sie damit koppelt, hat dieselbe Datenlage wie bei jedem anderen Cloud-Zugriff, nur auf einem kleineren Bildschirm.

Zum lokalen Werkzeug wird die App erst durch das, was dahintersteht. Die Kombination trägt, die App allein trägt keine Aussage über Datenhoheit. Das ist derselbe Gedanke wie beim Cloud-Tag in der Ollama-Library: Ein Werkzeug, das aussieht wie lokal, ist deshalb noch nicht lokal.

Wo die Grenzen liegen

Drei Punkte, die man vor der Entscheidung kennen sollte.

Kein Windows. Unterstützt sind macOS mit Apple Silicon und Linux. Für vLLM unter Linux kommen NVIDIA-Treiber und CUDA dazu. In vielen Büros ist das der Punkt, an dem die Sache endet — dann bleiben LM Studio oder Ollama, die beide unter Windows laufen.

Es ist Infrastruktur, kein Programm zum Doppelklicken. Vorausgesetzt werden Bun, Node.js, npm, Python und Git. Die macOS-Fassung wird zwar signiert und notarisiert ausgeliefert und aktualisiert sich selbst, aber der Betrieb bleibt eine Aufgabe für jemanden, der Server bedienen kann.

Es löst die Modellfrage nicht. Local Studio bedient Modelle, es macht sie nicht besser. Welches Modell in den vorhandenen Speicher passt, beantwortet der Hardware-Rechner; wie schnell es dort läuft, die Rechnung unter große Modelle lokal betreiben; und für eine bestimmte Karte steht es im GPU-Katalog.

Einordnung gegen Ollama und LM Studio

	Ollama	LM Studio	Local Studio
Gedacht für	Kommandozeile, Skripte	Einzelnutzer mit Oberfläche	Betrieb für mehrere Nutzer
Plattformen	Mac, Windows, Linux	Mac, Windows, Linux	Mac (Apple Silicon), Linux
Engines	llama.cpp	llama.cpp, MLX	vLLM, SGLang, llama.cpp, MLX
Einstieg	Minuten	Minuten	Stunden
Lizenz	MIT	proprietär, kostenlos	Apache 2.0

Die Reihenfolge ist keine Rangliste, sondern eine Reihenfolge. Die allermeisten fangen bei Ollama an und sollten das auch. Local Studio wird interessant, wenn drei Dinge zusammenkommen: mehrere Nutzer, mehr als eine Engine und ein Grund, warum die Daten im Haus bleiben müssen. Fehlt einer der drei, ist der einfachere Weg der bessere.

Nächster Schritt

Wenn du prüfst, ob das für dein Haus infrage kommt, ist die Reihenfolge diese: erst die Frage klären, welche Dokumente überhaupt betroffen sind, dann die Modellgröße daraus ableiten, dann die Hardware. Nicht umgekehrt — die häufigste Fehlentscheidung ist eine Maschine, die für ein Modell gekauft wurde, das die Aufgabe gar nicht braucht.

Der Hardware-Guide deckt die Beschaffungsseite ab, Cloud gegen lokal die wirtschaftliche Abwägung. Und wenn an der Entscheidung ein Budget und eine Aufsichtspflicht hängen, ist Beratung der günstigere Weg als ein Fehlkauf.