Jede Online-Übersetzung hat einen Preis, den man auf der Rechnung nicht sieht. Der Text, den du übersetzen willst, wandert zu einem Server. Google Translate, DeepL, ChatGPT — sie alle schicken deinen Text in ein Rechenzentrum, verlangen einen Account oder einen API-Key und rechnen pro Zeichen oder pro Anfrage ab. Für einen kurzen Satz ist das egal. Für einen Vertrag, einen Befund oder eine interne E-Mail nicht.
Es geht auch anders. Ein Übersetzungsmodell läuft auch vollständig in deinem Browser. Kein Cloud-Dienst, kein API-Key, kein Server. Der Text verlässt dein Gerät nicht.
Genau das verspricht lite-translator, ein Hobby-Projekt, dessen Ankündigung in der r/FOSS-Community aufgetaucht ist 1. Die Bibliothek soll über Transformers.js übersetzen, ONNX-Modelle in einen Web Worker laden und lokal arbeiten, wahlweise mit WebGPU-Beschleunigung oder mit WASM-Fallback. Ob genau dieses Paket dauerhaft im npm-Registry bleibt, ist zweitrangig: Unter dem angekündigten Namen ist es dort nicht auffindbar. Die Technik dahinter ist dokumentiert und reproduzierbar, und genau darum geht es hier.
Du bekommst ein funktionierendes Minimal-Setup, die Entscheidung WebGPU gegen WASM, reale Downloadgrößen für OPUS-MT und NLLB, einen Test, mit dem du prüfst, ob wirklich nichts den Browser verlässt, und Kriterien, wann lokal im Browser die richtige Wahl ist.
Kurzantwort
Maschinelle Übersetzung komplett im Browser: ohne Cloud, ohne API-Key. So richtest du Transformers.js, Web Worker und OPUS-MT lokal selbst ein. Kurz gesagt: lokales LLM betreiben ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.
Was „lokal im Browser" konkret bedeutet
„Lokal im Browser" heißt: Das Modell wird einmal aus dem Hugging-Face-Hub heruntergeladen und danach auf deinem Gerät ausgeführt. Der eigentliche Übersetzungsschritt findet in JavaScript statt, nicht auf einem fremden Server. Nach dem ersten Laden funktioniert die Übersetzung ohne Netzwerkverbindung, weil das Modell im Browser-Cache liegt 7.
Dafür verantwortlich ist Transformers.js, eine JavaScript-Bibliothek von Hugging Face. Sie führt ONNX-Modelle direkt im Browser aus, über ONNX Runtime Web, das wahlweise auf der GPU (WebGPU) oder der CPU (WebAssembly, kurz WASM) rechnet 2, 3. Die Bibliothek ist die JavaScript-Schwester der bekannten Python-Bibliothek transformers und installiert sich als npm-Paket @huggingface/transformers 2.
Der entscheidende Unterschied zu klassischen Übersetzungsdiensten ist die Datenhoheit. Da die Inferenz im Browser läuft, verlässt kein Text das Gerät. Es gibt keinen Anbieter, der deine Sätze speichert, und keinen API-Key, der gestohlen oder ausgereizt werden kann 7. Das ist derselbe Grundgedanke wie beim Betrieb eines lokalen KI-Modells auf dem eigenen Rechner. Der Unterschied: Hier ist nicht einmal ein Server nötig, sondern nur ein Browser mit etwas Rechenleistung.
So läuft die Übersetzung technisch ab
Der Ablauf ist einfach, aber die Teile greifen präzise ineinander. Die Kernidee: Das Modell läuft in einem Web Worker, also in einem eigenen Thread, damit die Oberfläche nicht einfriert 2.
Beim ersten Aufruf lädt Transformers.js die Modell-Dateien herunter. Für ein ONNX-Übersetzungsmodell sind das typischerweise drei Dateien plus Konfiguration: encoder_model.onnx, decoder_model.onnx und decoder_model_merged.onnx, dazu Tokenizer-Dateien 7. Diese Dateien landen im IndexedDB-Speicher des Browsers und werden bei späteren Aufrufen direkt von dort gelesen 7.
Die eigentliche Übersetzung läuft als Pipeline. Die Bibliothek stellt dafür eine Funktion bereit, die das Modell lädt und Anfragen entgegennimmt. Ein Modell wird in einem Worker nur einmal geladen und dann für alle weiteren Anfragen wiederverwendet. Das spart Zeit, weil Download und Initialisierung nur einmal passieren 2.
Als Modellfamilie kommt hier häufig OPUS-MT zum Einsatz, eine Sammlung offener neuronaler Übersetzungsmodelle des Helsinki-NLP-Projekts 5. Die Modelle basieren auf dem Marian-NMT-Framework, nutzen SentencePiece zur Tokenisierung und stehen unter der CC-BY-4.0-Lizenz 5. Für mehrsprachige Übersetzung in 200 Sprachen gibt es außerdem Metas NLLB-Modell, das ebenfalls als ONNX-Variante im Hub liegt 2, 9.
WebGPU oder WASM: die Beschleunigungsfrage
WebGPU ist ein Web-Standard für beschleunigtes Rechnen und Rendering. Die API erlaubt es Webseiten, die GPU des Systems direkt für rechenintensive Aufgaben zu nutzen, und gilt als Nachfolger von WebGL 3. Für maschinelles Lernen ist das relevant, weil eine GPU die Matrix-Operationen eines Modells deutlich schneller ausführt als die CPU.
Transformers.js kann beide Wege: WebGPU für die GPU, WASM für die CPU. Die Wahl fällt über das device-Argument der Pipeline, zusammen mit einem dtype, das die numerische Genauigkeit festlegt 3, 4. Ein GPU-Setup sieht zum Beispiel so aus:
const translator = await pipeline('translation', 'Xenova/opus-mt-en-de', {
device: 'webgpu',
dtype: 'fp16',
});
In der Praxis ist die Beschleunigung aber keine reine Performance-Frage. Für OPUS-MT-Modelle gibt es dokumentierte Schwierigkeiten mit WebGPU: In einem bekannten Issue berichten Entwickler, dass bestimmte OPUS-MT- und Multilingual-Modelle unter WebGPU Fehler oder leere Ausgaben liefern können 10. Ganz sauber gelöst ist das dort nicht; in der Praxis wird dann auf WASM ausgewichen. Genau dafür bietet lite-translator laut Ankündigung einen automatischen WASM-Fallback 1.
Die WebGPU-Beschleunigung ist also ein Bonus, kein Versprechen. Für kleine Modelle und kurze Texte reicht WASM oft aus; für große Modelle und lange Texte wird der GPU-Unterschied spürbar. Vorher prüfen, nicht blind beschleunigen.
Minimal-Setup: der Übersetzer in zehn Minuten
Der schnellste Weg ist ein einzelnes Sprachpaar mit einem OPUS-MT-Modell. Voraussetzung: ein Node-Projekt oder eine Vite-App und das Paket.
npm i @huggingface/transformers
Der Übersetzer läuft in einem Worker. Eine minimale worker.js sieht so aus:
import { pipeline } from '@huggingface/transformers';
let translator = null;
self.addEventListener('message', async (event) => {
if (!translator) {
translator = await pipeline('translation', 'Xenova/opus-mt-en-de');
}
const output = await translator(event.data);
const [first] = output;
self.postMessage(first.translation_text);
});
Im Haupt-Thread startest du den Worker und schickst Text:
const worker = new Worker(new URL('./worker.js', import.meta.url), { type: 'module' });
worker.onmessage = (e) => console.log(e.data);
worker.postMessage('Good morning');
Das war es. Beim ersten Aufruf lädt der Worker das Modell, danach übersetzt er lokal.
Für mehrsprachige Übersetzung nimmst du stattdessen NLLB und übergibst Quell- und Zielsprache. Das offizielle Hugging-Face-Tutorial zeigt genau dieses Muster mit dem Modell Xenova/nllb-200-distilled-600M, inklusive Ladebalken und Streaming-Ausgabe über einen TextStreamer 2. Wichtig dort: Das Modell ist über 1 GB groß, deshalb laden die Autoren es erst, wenn der Nutzer auf den Übersetzen-Knopf klickt, und halten es im Worker 2.
Wer mit Vite baut, sollte zusätzlich das Worker-Format auf ES-Module setzen und Transformers.js vom Optimizer ausschließen, damit das Bundling nicht in seltsame Lade-Fehler läuft. Die erwähnte Community-Referenz nutzt Vite als Bundler-Option; die konkrete Optimizer-Ausnahme ist Standard-Praxis bei Transformers.js in Vite-Projekten 7.
Test: läuft die Übersetzung wirklich lokal?
Die Behauptung „kein Text verlässt das Gerät" lässt sich in zwei Minuten selbst prüfen. So gehst du vor.
Öffne die Entwicklertools im Browser und wechsle auf den Netzwerk-Tab. Lade die Seite mit dem Übersetzer neu. Du siehst jetzt die Abrufe der Modell-Dateien vom Hugging-Face-Hub oder einem CDN. Das ist der einmalige Download.
Warte, bis das Modell geladen ist, und übersetze dann einen Satz. Beobachte den Netzwerk-Tab dabei. Es dürfen keine neuen Anfragen an einen Server erscheinen. Läuft alles korrekt, passiert die Übersetzung komplett im Worker, ohne einen einzigen ausgehenden Request 7.
Zur Gegenprobe kannst du die Seite in den Offline-Modus schalten, nachdem das Modell einmal geladen wurde, und erneut übersetzen. Funktioniert es weiter, ist das Modell tatsächlich im lokalen Cache und nicht auf einen Server angewiesen 7. Der Cache liegt dabei in IndexedDB, wo du ihn unter „Application" im DevTools-Bereich auch direkt siehst 7.
Modelle und Downloadgrößen
Die Downloadgröße entscheidet, ob sich der Ansatz für deine Seite lohnt. Konkrete Zahlen aus dem Hugging-Face-Hub:
Für Xenova/opus-mt-en-de (Englisch-Deutsch) liegt der Encoder unkomprimiert bei rund 196 MB, die int8-quantisierte Variante bei etwa 49 MB 8. Zum Encoder kommt der Decoder: Ein vollständiges OPUS-MT-Modell für ein Sprachpaar liegt damit bei rund 420 MB in voller Auflösung (Encoder plus gemergter Decoder) beziehungsweise rund 105 MB in der int8-Quantisierung 8.
Xenova/nllb-200-distilled-600M ist eine andere Größenordnung: Der Encoder kommt unkomprimiert auf rund 1,66 GB, die quantisierte Version auf etwa 419 MB 9. Das deckt sich mit der Angabe im offiziellen Tutorial, das von über 1 GB spricht 2.
Quantisierung ist hier der Hebel. Die int8-Varianten sind laut einer Referenz-Implementierung rund vier- bis fünfmal kleiner und deutlich schneller im Browser 7. Dazu kommen q4- und fp16-Varianten, die Transformers.js über das dtype-Argument wählt 4.
Bei den Lizenzen lohnt ein genauer Blick, weil er die Einsatzmöglichkeiten begrenzt. OPUS-MT-Modelle stehen unter CC-BY 4.0 und sind damit auch kommerziell nutzbar, solange die Namensnennung stimmt 5. NLLB-200 steht dagegen unter CC-BY-NC-4.0 und erlaubt keine kommerzielle Nutzung 9. Wer die Übersetzung in ein Produkt einbaut, muss das unterscheiden.
Zur Einordnung der Abdeckung: Das OPUS-MT-Dashboard führt über 2.300 Modelle mit 4.560 Sprachrichtungen in 294 Sprachen 6. Es gibt also für viele, aber längst nicht für alle Sprachpaare ein passendes Modell. Die Faustregel für die Modellwahl: ein Sprachpaar und möglichst klein heißt OPUS-MT; viele Sprachen und genug Geduld beim Laden heißt NLLB.
Fehlerbehebung: wenn die Übersetzung nicht läuft
Die häufigsten Probleme haben klare Ursachen.
Der Worker liefert nichts oder die Seite friert ein. Dann läuft das Modell wahrscheinlich im Haupt-Thread statt im Worker. Das Laden und Ausführen gehört zwingend in den Worker; andernfalls blockiert der große Download die Oberfläche 2.
Die Ausgabe ist leer, obwohl das Modell lädt. Bei OPUS-MT- und Multilingual-Modellen unter WebGPU ist das ein bekanntes Muster. Setze das device der Pipeline explizit auf wasm, um den WebGPU-Pfad zu umgehen — auch wenn der Wechsel nicht in jedem Fall hilft, ist er der übliche erste Schritt 10.
Der erste Aufruf dauert sehr lange. Das ist der Modell-Download, kein Fehler. Ein Fortschritts-Callback in der Pipeline zeigt an, welche Datei gerade lädt 2, 7. Nach dem ersten Laden kommen die Dateien aus IndexedDB 7.
Das Modell passt nicht in den Speicher. Dann ist es für den Browser zu groß. Nimm eine quantisierte Variante oder ein kleineres OPUS-MT-Modell statt des 600M-NLLB 7, 8.
Die Sprachrichtung fehlt. OPUS-MT-Modelle sind an ein Paar gebunden, etwa Englisch-Deutsch. Für andere Richtungen brauchst du ein anderes Modell; einen Überblick liefert das Dashboard 6.
Browser, eigener Server oder Cloud-API
Die Frage ist nie nur technisch, sondern eine Kosten- und Vertrauensrechnung. Drei Wege stehen zur Wahl.
Der lokale Browser-Übersetzer kostet dich keinen Server und keine API-Nutzung. Der Preis sind der einmalige Download pro Nutzer, die begrenzte Modellgröße und die Tatsache, dass jeder Browser das Modell selbst rechnet 2, 7. Das lohnt sich für Anwendungen mit wenigen Nutzern, klaren Sprachpaaren und hohem Datenschutzbedarf, etwa ein internes Tool oder eine Übersetzung direkt in einer lokalen Anwendung.
Ein eigener Server ist die nächste Stufe, im Kern das, was viele unter „ein lokales LLM betreiben" verstehen. Ein Übersetzungsmodell läuft dort zentral auf eigener Hardware, mehrere Nutzer teilen sich ein Modell, und größere Modelle sind machbar. Wer KI selbst hosten will, um volle Kontrolle über Daten und Kosten zu haben, landet früher oder später hier. Die Hardware reicht vom kleinen Mini-PC für ein einzelnes Übersetzungsmodell bis zum GPU-Rechner für große Sprachmodelle; die laufenden Kosten sind Strom und Wartung statt pro Anfrage. Dafür musst du den Dienst betreiben, Updates einspielen und den Zugriff absichern. Der Unterschied zum Browser-Ansatz: Der Text verlässt zwar das Endgerät, bleibt aber in deiner eigenen Infrastruktur statt bei einem Anbieter.
Die Cloud-API bleibt die Qualitätsspitze und die einfachste Integration. Große Modelle, alle Sprachrichtungen, keine lokalen Ressourcen. Dafür zahlst du pro Anfrage, und der Text liegt beim Anbieter. Wer ein lokales LLM betreiben will, um Datenhoheit und Kosten zu kontrollieren, macht mit dem Browser-Ansatz einen ersten, sehr kleinen Schritt in diese Richtung, ohne Hardware und ohne Wartung.
Wichtig für die Erwartung: Ein Übersetzungsmodell ist keine ChatGPT-Alternative. Es übersetzt Text zwischen Sprachen, mehr nicht. Es schreibt keine Texte, beantwortet keine Fragen und führt keinen Dialog. Wer eine lokale Chat-Alternative sucht, braucht ein größeres Sprachmodell und damit fast zwingend einen Server statt des Browsers.
Entscheidend bleibt die Abwägung aus drei Kriterien: Wer darf den Text sehen, wie viele Nutzer teilen sich die Kosten, und wie gut muss die Übersetzung sein. Der Browser gewinnt bei der ersten Frage und verliert bei den beiden anderen gegenüber Server oder Cloud.
FAQ
Ist das dasselbe wie ein lokales LLM betreiben? Verwandt, aber nicht identisch. Übersetzungsmodelle wie OPUS-MT sind kompakte, auf eine Aufgabe trainierte Modelle. Ein großes Sprachmodell für Textgenerierung ist etwas anderes. Gemeinsam ist beiden: Das Modell läuft auf deiner Hardware und braucht keinen Cloud-Anbieter 5.
Brauche ich dafür eine GPU? Nein. Über WASM läuft die Übersetzung auf der CPU. WebGPU beschleunigt optional, ist aber für OPUS-MT-Modelle nicht immer stabil verfügbar 10.
Verlässt mein Text wirklich nie den Browser? Nach dem einmaligen Modell-Download nicht mehr. Die Inferenz passiert lokal, und die Anwendung funktioniert offline 7. Was die konkrete Bibliothek oder Webseite darüber hinaus sendet, ist eine Frage der jeweiligen Implementierung, nicht der Technik.
Wie groß ist der Download beim ersten Besuch? Für ein einzelnes OPUS-MT-Sprachpaar rund 420 MB in voller Auflösung, mit int8-Quantisierung rund 105 MB 8. NLLB-200 liegt über 1 GB 2, 9.
Kann ich das kommerziell nutzen? Mit OPUS-MT unter CC-BY 4.0 ja, mit Namensnennung 5. NLLB-200 ist nur nicht-kommerziell lizenziert (CC-BY-NC-4.0) 9.
Welche Sprachrichtungen gibt es? Das OPUS-MT-Dashboard listet über 2.300 Modelle und 4.560 Sprachrichtungen 6. Für seltene Paare kann das passende Modell fehlen.
Warum hängt die Seite beim ersten Laden? Der Modell-Download läuft. Ein Fortschritts-Callback macht das sichtbar, und der Worker verhindert, dass die Oberfläche blockiert 2.
Was ist der Unterschied zwischen OPUS-MT und NLLB? OPUS-MT sind kleine Modelle für meist ein Sprachpaar. NLLB-200 ist ein großes, mehrsprachiges Modell für viele Richtungen auf einmal, dafür deutlich größer 5, 9.
Funktioniert das auch ohne Internet? Ja, nach dem ersten Laden. Das Modell liegt dann im Browser-Cache und wird lokal ausgeführt 7.
Muss ich einen API-Key hinterlegen? Nein. Der Ansatz braucht weder Account noch API-Key; die Modelle kommen frei aus dem Hugging-Face-Hub 2, 7.
Für wen sich der lokale Übersetzer lohnt
Der lokale Übersetzer im Browser ist kein Ersatz für DeepL oder eine gute Cloud-API. Er ist die Antwort auf ein spezifisches Problem: Übersetzung, die den Text nicht aus der Hand gibt.
Wer ein internes Tool baut, kurze Texte zwischen festen Sprachen übersetzt oder schlicht keinen API-Key und keinen Server verwalten will, bekommt hier einen funktionierenden Weg mit überschaubarem Aufwand. Der Preis sind der Download pro Nutzer, die begrenzte Modellgröße und eine Übersetzungsqualität, die hinter den großen kommerziellen Systemen zurückbleibt. OPUS-MT selbst weist darauf hin, dass die automatischen Testwerte auf kurzen, einfachen Sätzen beruhen und in der Praxis zu optimistisch ausfallen können 5.
Für alles, was Qualität an erster Stelle braucht oder von vielen Nutzern gleichzeitig genutzt wird, sind ein eigener Server oder die Cloud die bessere Wahl. Für den Rest gilt: Der einfachste Weg, ein Übersetzungsmodell lokal zu betreiben, ist der Browser. Wer später ein größeres lokales LLM betreiben will, nimmt denselben Gedanken mit und verlagert nur den Ort der Ausführung vom Browser auf einen eigenen Rechner.
Passende Produktrecherchen
Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:
- USB-C-Sticks für lokale Smartphone-Backups recherchieren
- Mini-PCs für Homelab und Security-Lab vergleichen
- Raspberry Pi und Mini-PCs vergleichen
- LiFePO4-Speicher für Balkonkraftwerke ansehen
- GL.iNet Router für Testnetze und Reise-VPNs ansehen
Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.
Quellen
[1] Reddit r/FOSS: „Side Project lite-translator — 100% browser-local translation, no cloud, no API keys"
[2] Hugging Face Docs: Building a React application (Transformers.js-Übersetzungs-Tutorial)
[3] Hugging Face Docs: Running models on WebGPU
[4] Hugging Face Docs: Using quantized models (dtypes)
[5] Helsinki-NLP/Opus-MT (GitHub)
[6] Tiedemann et al.: „The OPUS-MT Dashboard" (ACL 2023 Demo)
[7] harisnae/multilingual-translator-offline (GitHub)
[8] Hugging Face Modell: Xenova/opus-mt-en-de
[9] Hugging Face Modell: Xenova/nllb-200-distilled-600M
[10] Transformers.js Issue #841: „Support opus-mt-mul-en translation in WebGPU"
Weiterführende Artikel
- Datenlecks erkennen: So findest du heraus, wo deine Daten abfließen
- KI-Tools in der Praxis: Open-Source Voice Changer für Linux: Stimme anonymisieren mit lokalen Modellen
- Lokales Sprachmodell produktiv nutzen: Vom Ollama-Demo zur eigenen Open-LLM-App
- KI-Tools in der Praxis: Voice PE Realtime — Sprachsteuerung, die endlich funktioniert
- KI-Tools Praxis: Bye bye Alexa & Google — Mein Homelab-Setup
Transparenzhinweis
Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.