SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor

Open-Source-LLM für gutes Deutsch auf dem VPS testen

Welches offene Sprachmodell schreibt auf Ihrem VPS korrektes Deutsch? Ein wiederholbarer Test mit Ollama und Tokenzählung, dazu Lizenzen und Speicherbedarf von Teuken bis Kolibri.

Welches Open-Source-LLM schreibt gutes Deutsch auf dem VPS?

Ein Open-Source-LLM für Deutsch auf dem VPS finden Sie nicht in einer Rangliste, sondern mit einem Test, den Sie selbst wiederholen. Drei feste deutsche Prompts, eine Zählung der Tokens pro deutschem Wort und die Wörter pro Sekunde auf Ihrem eigenen Server ergeben eine Entscheidung, die zu Ihrer Hardware passt. Dazu prüfen Sie für jedes Modell die Lizenz und den RAM-Bedarf, denn beides schließt Kandidaten schneller aus als jede Stilfrage.

Englische Anleitungen fragen meist nur, ob ein Modell „Deutsch kann“. Das reicht nicht. Ein Modell kann flüssig klingen und trotzdem die Kasusendungen falsch setzen, mitten in einer Geschäftsmail vom Sie zum Du wechseln oder „Rechenzentrumsbetreiber“ in drei Wörter zerlegen. Genau diese Fehler sucht der Test.

Dieser Artikel nennt bewusst keine eigenen Tokens pro Sekunde und keine Qualitätsrangliste. Für diese Fassung (Stand 30. Oktober 2026) haben wir die Modelle nicht auf einem VPS gemessen, und fremde Zahlen von einem anderen Prozessor sagen über Ihre vCPUs wenig. Was hier steht, sind die Methode, die Lizenzlage und die Größen aus den Modellkarten. Die Messwerte liefert Ihr Server.

Warum ist Deutsch für ein LLM teurer als Englisch?

Ein Sprachmodell liest keine Wörter, sondern Tokens. Ein Token ist ein Stück Text aus dem Vokabular des Tokenizers, also der Komponente, die Text in Zahlen zerlegt. Häufige englische Wörter sind oft ein einziges Token. Lange deutsche Komposita sind es selten, weil sie im Trainingstext seltener vorkommen und der Tokenizer sie deshalb in Teilstücke schneidet.

Aleph Alpha beschreibt das in einem Blogartikel vom 20. August 2025 über tokenizerfreie Modelle (T-Free) mit einem Beispiel: Das Wort „Bundeskanzler“ werde von herkömmlichen Tokenizern in vier Tokens zerlegt. Das ist die Aussage des Herstellers über klassische Tokenizer, keine Messung an den Modellen in diesem Artikel. Ob es bei Ihrem Kandidaten drei, vier oder ein Token sind, zeigt Ihnen llama-tokenize in einer Sekunde.

Mehr Tokens pro Wort haben zwei Folgen, die Sie direkt spüren. Erstens sinkt die Ausgabegeschwindigkeit in Wörtern, weil das Modell für jedes Token einen eigenen Rechenschritt braucht und ein Wort dann mehrere Schritte kostet. Zweitens füllt derselbe deutsche Text das Kontextfenster schneller, also den Bereich, den das Modell auf einmal sehen kann. Bei einem Modell mit 4096 Tokens Kontext ist das kein Detail, sondern die Grenze für jede längere Zusammenfassung.

Die Kandidaten, geprüft an den Modellkarten

Stand 30. Oktober 2026 haben wir die folgenden Angaben auf den Modellkarten bei Hugging Face, auf den Herstellerseiten und auf ollama.com nachgelesen. Größen auf ollama.com ändern sich, wenn neue Tags erscheinen. Prüfen Sie sie vor dem Download erneut.

Kolibri-1 von Aleph Alpha

Kolibri-1 erschien am 3. Oktober 2026 unter Apache 2.0. Es ist ein Mixture-of-Experts-Modell (MoE), also ein Modell, das pro Token nur einen Teil seiner Gewichte rechnet: 78,1 Milliarden Parameter insgesamt, davon 3,46 Milliarden aktiv pro Token. Die Modellkarte nennt Deutsch und Englisch als Sprachen, ein Vokabular von 128.000 Tokens und einen eigenen Tokenizer mit 4,7 Bytes pro Token für Deutsch und 4,2 für Englisch. Im Launch-Blog spricht Aleph Alpha von einem zweisprachigen Tokenizer mit dem Verfahren UniBPE und nennt 4,90 Bytes pro Token auf deutschem Webtext gegenüber 4,35 für GPT-5. Beides sind Herstellerangaben auf unterschiedlichen Testtexten. Mischen Sie sie nicht.

Für einen VPS ist Kolibri-1 ein Sonderfall. Die offizielle Mindestausstattung auf der Karte ist ein Rechenzentrums-Setup für etwa 78 GB FP8-Gewichte, zum Beispiel zwei A100 mit 80 GB oder eine H200. Die Karte erwähnt GGUF, llama.cpp und Ollama nicht. GGUF-Dateien gibt es nur von der Community, etwa bartowski/Kolibri-1-GGUF, dessen Q4_K_M-Datei rund 49,76 GB groß ist. Bei Ollama haben wir am 30. Oktober 2026 kein offizielles Bibliotheksmodell gefunden, nur Community-Uploads wie robit/kolibri-1. Dessen Seite beschreibt Kolibri als Mixture-of-Experts-Modell von Aleph Alpha mit Fokus auf Deutsch und Englisch, bleibt aber ein Community-Upload. Was ein Betrieb auf einem Server der 64-GB-Klasse bedeutet, steht ausführlich in unserem Artikel was es braucht, Kolibri-1 selbst zu hosten. Wir wiederholen es hier nicht.

Teuken-7B von OpenGPT-X

Teuken-7B ist ein Modell mit 7,45 Milliarden Parametern für alle 24 Amtssprachen der EU, Deutsch eingeschlossen. Die Architektur ist Llama (LlamaForCausalLM), mit 32 Schichten, einem Vokabular von 250.680 Tokens und einem Kontext von 4096. Das Forschungsprojekt OpenGPT-X ist laut Fraunhofer IAIS abgeschlossen.

Für ein deutsches Unternehmen zählt bei Teuken vor allem die Lizenz, und die ist je nach Variante verschieden. Fraunhofer IAIS beschreibt die Aufteilung so: Teuken-7B-instruct-commercial-v0.4 steht unter Apache 2.0 und ist für kommerzielle Nutzung gedacht. Teuken-7B-instruct-v0.6 und die Basisversion v0.6 stehen unter CC BY-NC 4.0, also nur nichtkommerziell. Teuken-7B-instruct-research-v0.4 ist für die Forschung gedacht und trägt auf Hugging Face die Lizenzangabe „other“ mit eigener Lizenzdatei. Fraunhofer schreibt außerdem, dass die Research-Variante in Benchmarks ein bis zwei Prozent besser abschneidet als die kommerzielle. Wer Teuken im Firmenalltag einsetzt, nimmt also die etwas schwächere, aber frei nutzbare commercial-v0.4.

Ein offizielles Ollama-Tag haben wir am 30. Oktober 2026 nicht gefunden. Die Ollama-Suche zeigte damals nur Community-Uploads wie fl0id/teuken-7b-instruct-commercial-v0.4. Auf Hugging Face gibt es Community-GGUFs, zum Beispiel mradermacher/Teuken-7B-instruct-commercial-v0.4-GGUF. Die Q4_K_M-Datei dort ist 5.018.868.512 Bytes groß, also rund 4,7 GiB. Diese Dateien stammen nicht von OpenGPT-X selbst.

LLäMmlein von der Universität Würzburg

LLäMmlein ist eine rein deutsche Modellfamilie der Universität Würzburg (auf Hugging Face unter LSX-UniWue). Die Basismodelle mit 120 Millionen, 1 Milliarde und 7 Milliarden Parametern wurden von Grund auf mit dem deutschen Teil von RedPajama V2 trainiert. Das Paper beschreibt für 120M und 1B einen eigenen deutschen Tokenizer. Für das 7B-Modell nennt die config.json ein Vokabular von 32.064 Tokens, 32 Schichten und 4096 Positionen. Einen eigenen deutschen Tokenizer für 7B nennen die Seiten, die wir geöffnet haben, nicht. Am 30. Oktober 2026 existierte ein Repository LLaMmlein_32B, enthielt aber keine Gewichte.

Die Lizenz macht LLäMmlein für den Firmeneinsatz unbrauchbar. Die Gewichte stehen unter einer „research-only RAIL-M“-Lizenz, die die Nutzung auf akademische oder Forschungszwecke beschränkt. Der Code auf GitHub steht unter Apache 2.0, aber das gilt nicht für die Gewichte. Für eine Abschlussarbeit oder einen Vergleichstest ist das Modell interessant. Für den Kundenchat Ihrer Firma ist es das nicht.

Ein GGUF gibt es: Die Uni stellt LSX-UniWue/LLaMmlein_7B_chat-gguf bereit, mit einer einzigen Datei von 13,48 GB. Das entspricht etwa 2 Bytes pro Parameter, also unquantisierten 16-Bit-Gewichten. Quantisierte Fassungen gibt es von der Community, etwa mradermacher/LLaMmlein_7B_chat-GGUF mit einer Q4_K_M-Datei von 4,08 GB. Auf einer ihrer Modellkarten nannte die Uni am 30. Oktober 2026 die Chat-Versionen Forschungsdemonstrationen. Einen Ollama-Eintrag haben wir am 30. Oktober 2026 nicht gefunden.

Mehrsprachige Vergleichsmodelle für 8 bis 32 GB

Ohne Vergleich wissen Sie nicht, ob ein deutsches Spezialmodell besser ist. Drei mehrsprachige Modelle mit offiziellen Ollama-Einträgen eignen sich als Basis:

  • Gemma 4 (gemma4): offizielle Tags e2b, e4b, 12b, 26b und 31b. In Q4_K_M sind es 4,6, 6,6, 8,0, 18 und 20 GB. Die Hugging-Face-Karte des 12B-Modells nennt Apache 2.0, 256K Kontext und Unterstützung für über 35 Sprachen direkt, vortrainiert auf über 140.
  • Qwen3.8 (qwen3.8): Bei Ollama haben wir nur die Größe 27b gefunden, in Q4_K_M 18 GB. Die Karte nennt Apache 2.0 und 262.144 Tokens Kontext. Eine Aussage zu Sprachen haben wir auf der Karte nicht gefunden. Ob Qwen3.8 gutes Deutsch schreibt, zeigt also erst Ihr Test.
  • Mistral Small 3.2 (mistral-small3.2): 24 Milliarden Parameter, bei Ollama 15 GB mit 128K Kontext. Die Hugging-Face-Karte nennt Apache 2.0 und zählt alle 24 Sprachen in ihren YAML-Metadaten auf, darunter Deutsch (de).

Achten Sie beim Namen Mistral Small auf die Version. Das aktuelle Mistral Small 4 vom 16. März 2026 ist ein MoE-Modell mit 119 Milliarden Parametern. Mistral nennt als Mindestausstattung vier H100, zwei H200 oder eine DGX B200. Es passt in keinen der Tarife hier. Der Ollama-Eintrag mistral-small ohne Zusatz ist dagegen noch Mistral Small 3 mit 24B.

Wie viel RAM braucht welches Modell?

Die Rechnung stammt aus unserem Artikel wie groß ein LLM für Ihren RAM sein darf. Gewichte in Bytes sind Parameter mal Bits pro Gewicht geteilt durch 8. Q4_K_M liegt bei etwa 4,89 Bits pro Gewicht. Dazu kommt der KV-Cache, also der Zwischenspeicher für den bisherigen Kontext. Pro Token kostet er 2 mal Schichten mal KV-Köpfe mal Kopfdimension mal Bytes pro Wert. Rechnen Sie außerdem etwa 1 GiB für die Laufzeit und 2 GiB für das Betriebssystem ein.

Bei Teuken und LLäMmlein zeigt die Rechnung einen Unterschied, den die Dateigröße versteckt. Beide haben 32 Schichten und eine Kopfdimension von 128. Teuken nutzt aber nur 2 KV-Köpfe (num_key_value_heads: 2), LLäMmlein-7B dagegen 32. Bei 16-Bit-Werten ergibt das für Teuken 2 × 32 × 2 × 128 × 2 = 32 KiB pro Token, für LLäMmlein 2 × 32 × 32 × 128 × 2 = 512 KiB pro Token. Bei vollen 4096 Tokens Kontext sind das 128 MiB gegen 2 GiB. Die kleinere Datei braucht im Betrieb also mehr RAM.

So ordnen sich die Kandidaten in Q4_K_M ein:

  • 8-GB-VPS: Gemma 4 e2b mit 4,6 GB. Teuken passt rechnerisch nur ohne Reserve, mit 4,7 GiB Gewichten, 0,1 GiB KV-Cache und 3 GiB für Laufzeit und System.
  • 16-GB-VPS: Teuken mit Luft, LLäMmlein-7B (3,8 GiB Gewichte plus 2 GiB KV-Cache bei 4096 Tokens), Gemma 4 e4b mit 6,6 GB und Gemma 4 12b mit 8,0 GB.
  • 32-GB-VPS: Gemma 4 26b und 31b, Qwen3.8 27b und Mistral Small 3.2.
  • 64-GB-Klasse: Kolibri-1 als Community-GGUF, siehe den verlinkten Kolibri-Artikel.

Für Gemma 4, Qwen3.8 und Mistral haben wir den KV-Cache nicht aus der Konfiguration gerechnet. Laden Sie das Modell und lesen Sie die echte Größe mit ollama ps ab. Sie hängt stark davon ab, welches Kontextfenster Ollama setzt. Wie Sie das steuern, steht in Kontextlänge mit num_ctx einstellen. Wer zwischen Q4 und Q8 schwankt, findet die Abwägung in Q4, Q8 und FP16 im Vergleich.

Die Testumgebung aufsetzen

Der Test läuft auf Ubuntu 24.04 mit Ollama für die Textausgabe und llama.cpp für die Tokenzählung. Installieren Sie zuerst die Werkzeuge:

sudo apt update && sudo apt install -y jq git cmake build-essential
curl -fsSL https://ollama.com/install.sh | sh
ollama --version

ollama --version sollte eine Versionsnummer ausgeben. Notieren Sie sie. Am 30. Oktober 2026 war v0.40.13 die neueste Ollama-Version. Ihre Messwerte gehören immer zu einer Version.

Holen Sie dann die Modelle, die in Ihren RAM passen. Die offiziellen Modelle kommen aus der Ollama-Bibliothek, die Community-GGUFs direkt von Hugging Face. Bei Hugging-Face-Repositories wählt Ollama Q4_K_M, wenn diese Datei vorhanden ist. Mit einem Tag hinter dem Doppelpunkt legen Sie die Quantisierung selbst fest:

ollama pull gemma4:12b
ollama pull mistral-small3.2
ollama pull hf.co/mradermacher/Teuken-7B-instruct-commercial-v0.4-GGUF:Q4_K_M
ollama pull hf.co/mradermacher/LLaMmlein_7B_chat-GGUF:Q4_K_M
ollama list

ollama list sollte jedes Modell mit seiner Größe zeigen. Fehlt ein Modell in der Liste, wurde es nicht vollständig geladen. Wiederholen Sie dann den pull. Ollama wählt die Chatvorlage eines Hugging-Face-GGUF aus den Metadaten der Datei. Liefert ein Community-Modell wirre Antworten, prüfen Sie zuerst die Vorlage. Wie Sie eine eigene setzen, steht in ein GGUF-Modell in Ollama importieren.

Die drei deutschen Testprompts

Legen Sie die Prompts als Dateien an. Feste Dateien sind der Kern des Tests: Nur wenn jedes Modell exakt denselben Text bekommt, sind die Ergebnisse vergleichbar.

mkdir -p ~/de-test && cd ~/de-test

cat > email.txt <<'EOF'
Schreiben Sie eine formelle E-Mail an Frau Dr. Wagner von der Stadtverwaltung Würzburg. Sie bitten um eine Verschiebung des Abgabetermins für den Förderantrag um zwei Wochen, weil ein Gutachten noch fehlt. Bleiben Sie durchgehend beim Sie. Höchstens 150 Wörter.
EOF

cat > zusammenfassung.txt <<'EOF'
Fassen Sie für eine Geschäftsführerin ohne Technikkenntnisse in fünf Sätzen zusammen, warum ein Server nach einem Kernel-Update neu gestartet werden muss und was während des Neustarts mit laufenden Diensten passiert.
EOF

cat > absatz.txt <<'EOF'
Der Rechenzentrumsbetreiber muss nach der Datenschutz-Grundverordnung ein Verzeichnis von Verarbeitungstätigkeiten führen. Die Auftragsverarbeitungsvereinbarung regelt außerdem die Haftungsfreistellung bei Sicherheitsvorfällen. Für die Kündigungsfrist gilt die Rahmenvertragsregelung, sofern keine Einzelvereinbarung getroffen wurde. Die Geschäftsführerin unterzeichnet den Änderungsvertrag nach Prüfung durch die Rechtsabteilung.
EOF

wc -w absatz.txt

wc -w zählt die Wörter im Absatz. Ein Kompositum wie „Auftragsverarbeitungsvereinbarung“ zählt als ein Wort, und genau das wollen Sie messen. Die ersten beiden Dateien sind Aufgaben für das Modell. Die dritte ist der Messtext für die Tokenzählung. Sie können sie zusätzlich als Aufgabe nutzen: Lassen Sie das Modell den Absatz umformulieren und prüfen Sie, ob die Komposita heil bleiben.

Tokens pro deutschem Wort zählen

Es gibt zwei Wege. Der erste nutzt Ollama, weil die Modelle dort ohnehin liegen. Die Ollama-API meldet in der letzten Antwort von /api/generate das Feld prompt_eval_count, laut Dokumentation die Zahl der Tokens im Prompt. Mit raw: true setzt Ollama keine Chatvorlage um den Text, so zählen Sie nur den Absatz. num_predict: 1 bricht die Ausgabe nach einem Token ab, denn hier geht es nur um die Eingabe.

cd ~/de-test
woerter=$(wc -w < absatz.txt)
for m in gemma4:12b mistral-small3.2 \
  hf.co/mradermacher/Teuken-7B-instruct-commercial-v0.4-GGUF:Q4_K_M \
  hf.co/mradermacher/LLaMmlein_7B_chat-GGUF:Q4_K_M; do
  n=$(jq -n --arg m "$m" --rawfile p absatz.txt \
      '{model: $m, prompt: $p, raw: true, stream: false, keep_alive: 0, options: {num_predict: 1}}' \
    | curl -s http://localhost:11434/api/generate -d @- | jq '.prompt_eval_count')
  awk -v m="$m" -v t="$n" -v w="$woerter" 'BEGIN { printf "%s\t%d Tokens\t%.2f Tokens/Wort\n", m, t, t/w }'
done

Jede Zeile sollte einen Modellnamen, eine Tokenzahl und das Verhältnis zeigen. Steht dort 0 Tokens, ist das Modell nicht geladen oder der Name falsch geschrieben. keep_alive: 0 entlädt das Modell nach jedem Aufruf, damit jeder Lauf ohne gecachten Prompt beginnt. Ob das Begin-of-Sequence-Token (BOS) mitzählt, legt die Dokumentation nicht fest. Ein Unterschied von einem Token zwischen zwei Modellen ist deshalb kein Ergebnis.

Der zweite Weg ist llama-tokenize aus llama.cpp. Es lädt nur das Vokabular, nicht die Gewichte, und zeigt Ihnen jedes einzelne Token. Bauen Sie llama.cpp auf einem festen Release. Am 30. Oktober 2026 war das neueste Release b12005. Warum ein fester Build auf einem Server wichtig ist, erklärt llama.cpp-Releases auf dem Server festlegen.

git clone https://github.com/ggml-org/llama.cpp ~/llama.cpp
cd ~/llama.cpp && git checkout b12005
cmake -B build
cmake --build build --config Release -j
./build/bin/llama-tokenize --help 2>&1 | grep -E 'show-count|no-bos|stdin'

Der letzte Befehl sollte die drei Optionen --show-count, --no-bos und --stdin auflisten. Fehlt eine davon, hat Ihr Build andere Optionen, und Sie passen die Befehle unten an. Laden Sie dann das GGUF als Datei und zählen Sie:

cd ~/de-test
curl -L -o teuken-q4km.gguf \
  https://huggingface.co/mradermacher/Teuken-7B-instruct-commercial-v0.4-GGUF/resolve/main/Teuken-7B-instruct-commercial-v0.4.Q4_K_M.gguf
tr -d '\n' < absatz.txt | ~/llama.cpp/build/bin/llama-tokenize \
  -m teuken-q4km.gguf --stdin --no-bos --show-count 2>/dev/null | tail -n 25

Jede Zeile der Ausgabe hat die Form ID -> 'Stück'. Am Ende steht Total number of tokens: mit der Summe. tr -d '\n' entfernt den Zeilenumbruch am Dateiende, denn das Werkzeug liest die Eingabe als rohe Bytes und würde ihn sonst als Token mitzählen. --no-bos lässt das BOS-Token weg, deshalb kann die Zahl leicht unter dem Ollama-Wert liegen. Interessanter als die Summe sind die einzelnen Zeilen: Dort sehen Sie, ob „Auftragsverarbeitungsvereinbarung“ in wenige sinnvolle Teile oder in viele Bruchstücke zerfällt.

Wörter pro Sekunde statt Tokens pro Sekunde

Tokens pro Sekunde sind die Zahl, die Benchmarks melden. Ihre Nutzer lesen aber Wörter. Die Ollama-Dokumentation gibt die Formel für die Geschwindigkeit an: eval_count geteilt durch eval_duration, mal 10^9, weil die Dauer in Nanosekunden gemeldet wird. Teilen Sie das Ergebnis durch Ihre gemessenen Tokens pro Wort, dann haben Sie deutsche Wörter pro Sekunde. Ein Modell mit vielen Tokens pro Wort verliert dabei mehr als eines, dessen Tokenizer Deutsch gut abdeckt.

Noch direkter ist es, die Wörter in der Antwort selbst zu zählen. Das folgende Skript schickt jeden Aufgabenprompt an jedes Modell, speichert die Antwort und gibt beide Raten aus:

cd ~/de-test
for m in gemma4:12b mistral-small3.2 \
  hf.co/mradermacher/Teuken-7B-instruct-commercial-v0.4-GGUF:Q4_K_M; do
  for f in email.txt zusammenfassung.txt; do
    out="$(echo "$m" | tr '/:' '__')-${f%.txt}.json"
    jq -n --arg m "$m" --rawfile p "$f" \
      '{model: $m, prompt: $p, stream: false, options: {temperature: 0, seed: 42, num_predict: 400}}' \
      | curl -s http://localhost:11434/api/generate -d @- > "$out"
    jq -r --arg m "$m" --arg f "$f" '
      (.eval_duration / 1e9) as $s
      | ([.response | splits("\\s+")] | map(select(. != "")) | length) as $w
      | [$m, $f, (.eval_count / $s | . * 10 | round / 10), ($w / $s | . * 10 | round / 10)]
      | @tsv' "$out"
  done
done

Jede Zeile zeigt Modell, Prompt, Tokens pro Sekunde und Wörter pro Sekunde. Die Ladezeit des Modells steckt nicht in diesen Raten, denn eval_duration misst laut Dokumentation nur die Zeit für die Erzeugung der Antwort. temperature: 0 und ein fester seed machen die Antworten wiederholbar, damit Sie bei einem zweiten Lauf denselben Text bewerten. Mehr zu diesen Parametern steht in Temperatur und Sampling in Ollama, die Grundlagen der Geschwindigkeitsmessung in Tokens pro Sekunde eines lokalen LLM messen.

LLäMmlein fehlt in diesem Skript mit Absicht. Wegen der Forschungslizenz gehört es nicht in eine Produktionsentscheidung. Nehmen Sie es dazu, wenn Sie selbst forschen.

Die Antworten auf korrektes Deutsch prüfen

Die Geschwindigkeit messen Skripte. Die Sprache prüfen Sie selbst. Zwei einfache Prüfungen fangen die häufigsten Fehler aber schon automatisch ab:

cd ~/de-test
for j in *-email.json; do
  du=$(jq -r '.response' "$j" | grep -oiwE 'du|dich|dir|dein|deine|deinen|deinem|deiner' | wc -l)
  uml=$(jq -r '.response' "$j" | grep -o '[äöüÄÖÜß]' | wc -l)
  echo "$j  Du-Formen: $du  Umlaute: $uml"
done

In einer formellen E-Mail sollten die Du-Formen bei 0 liegen. Jeder Treffer ist ein Wechsel aus dem Sie, und den bemerkt eine deutsche Empfängerin sofort. Bei den Umlauten ist 0 verdächtig. Ein deutscher Text mit über 100 Wörtern ohne ä, ö, ü oder ß schreibt die Umlaute meist als „ae“ und „ue“ aus. Prüfen Sie dann auch, ob Ihr Terminal UTF-8 nutzt (locale sollte UTF-8 zeigen), damit der Fehler nicht bei Ihnen liegt.

Den Rest lesen Sie. Diese Fragen helfen dabei:

  • Stimmen Kasus und Endungen nach Präpositionen, etwa „wegen des fehlenden Gutachtens“ statt „wegen dem fehlende Gutachten“?
  • Bleiben Komposita zusammen, oder schreibt das Modell „Förder Antrag“ und „Rechenzentrums Betreiber“?
  • Klingt der Text nach deutscher Geschäftskorrespondenz oder nach übersetztem Englisch mit „Ich hoffe, diese E-Mail findet Sie gut“?
  • Hält die Zusammenfassung die Vorgabe von fünf Sätzen ein, und erklärt sie den Neustart ohne Fachjargon?

Vergeben Sie pro Prompt und Modell eine einfache Note von 1 bis 3. Notieren Sie dazu Datum, Ollama-Version, Quantisierung und die gemessenen Raten. Diese Notizen sind Ihre Rangliste, und sie gilt für Ihren Server.

Welches Modell nehmen, Stand 30. Oktober 2026?

Die Lizenz entscheidet zuerst. Für einen kommerziellen Einsatz scheiden LLäMmlein (nur Forschung) und Teuken v0.6 (CC BY-NC 4.0) aus. Übrig bleiben Teuken-7B-instruct-commercial-v0.4, Gemma 4, Qwen3.8, Mistral Small 3.2 und Kolibri-1, alle laut ihren Karten unter Apache 2.0.

Danach entscheidet der RAM. Auf 16 GB testen Sie Teuken commercial-v0.4 gegen Gemma 4 12b. Das ist der interessanteste Vergleich, denn hier tritt ein EU-Modell mit sehr großem Vokabular gegen ein aktuelles mehrsprachiges Modell an, bei ähnlichem Speicherbedarf. Beachten Sie dabei Teukens Kontext von 4096 Tokens. Für lange Dokumente ist Gemma 4 mit 256K schon technisch im Vorteil, egal wie die Sprachnote ausfällt. Auf 32 GB kommen Qwen3.8 27b und Mistral Small 3.2 dazu. Kolibri-1 ist das Modell, für das der Hersteller einen eigenen Tokenizer mit Blick auf Deutsch beschreibt. Es braucht aber die 64-GB-Klasse und läuft auf einem VPS nur als Community-GGUF.

Diese Einordnung beruht auf Lizenzen, Größen und Herstellerangaben vom 30. Oktober 2026. Sie altert, sobald ein neues Modell erscheint. Die Methode altert nicht: Nehmen Sie das neue Modell in die Schleife auf, lassen Sie die drei Prompts laufen und vergleichen Sie mit Ihren alten Notizen. Wenn Sie die Modelle danach für andere Dienste anbieten, beschreibt die Ollama-API und Port 11434, wie Sie den Zugriff absichern.

FAQ

Welches Open-Source-LLM schreibt das beste Deutsch auf einem VPS?

Das hängt von Ihrem RAM und Ihrer Lizenzlage ab, und eine allgemeine Rangliste veraltet mit jedem neuen Modell. Für kommerzielle Nutzung auf 16 GB sind Teuken-7B-instruct-commercial-v0.4 und Gemma 4 12b naheliegende Kandidaten, auf 32 GB kommen Qwen3.8 27b und Mistral Small 3.2 dazu. Lassen Sie dieselben deutschen Prompts auf allen Kandidaten laufen und bewerten Sie Kasus, Komposita und die Sie-Form selbst.

Darf ich Teuken-7B in meiner Firma nutzen?

Laut Fraunhofer IAIS steht nur Teuken-7B-instruct-commercial-v0.4 unter Apache 2.0 und ist für kommerzielle Zwecke gedacht. Teuken-7B-instruct-v0.6 und die Basisversion v0.6 stehen unter CC BY-NC 4.0 und sind damit nichtkommerziell. Die Research-Variante v0.4 hat eine eigene Lizenzdatei und ist für die Forschung gedacht.

Wie zähle ich, wie viele Tokens ein deutsches Wort kostet?

Schicken Sie einen festen deutschen Absatz mit raw: true an die Ollama-API und lesen Sie prompt_eval_count aus der Antwort. Teilen Sie die Zahl durch die Wortzahl aus wc -w. Alternativ zeigt llama-tokenize aus llama.cpp mit --show-count die Summe und jedes einzelne Token, so sehen Sie, wie ein Kompositum zerlegt wird.

Gibt es Kolibri-1 oder LLäMmlein als offizielles Ollama-Modell?

In der Ollama-Suche haben wir am 30. Oktober 2026 für keines der beiden ein offizielles Modell gefunden. Für Kolibri-1 gibt es Community-GGUFs auf Hugging Face, etwa von bartowski, und Community-Uploads bei Ollama wie robit/kolibri-1; ein offizielles Bibliotheksmodell haben wir bei dieser Suche nicht gefunden. LLäMmlein-7B-Chat bietet die Uni Würzburg selbst als 16-Bit-GGUF an, quantisierte Fassungen kommen von der Community. Hugging-Face-GGUFs laden Sie mit ollama pull hf.co/<nutzer>/<repository> direkt.

Warum braucht LLäMmlein mehr RAM als Teuken, obwohl die Datei kleiner ist?

Der KV-Cache wächst mit der Zahl der KV-Köpfe. LLäMmlein-7B hat laut config.json 32 davon, Teuken nur 2. Bei 4096 Tokens Kontext und 16-Bit-Werten sind das etwa 2 GiB gegen 128 MiB, zusätzlich zu den Gewichten. Prüfen Sie den tatsächlichen Verbrauch nach dem Laden mit ollama ps.

War dieser Artikel hilfreich?

#ollama#llama-cpp#self-hosted-llm#german#tokenization#kolibri