Sampling-Einstellungen

Sampling ist der letzte Zentimeter der Inferenz: Das Model bewertet jedes Token im Vokabular, und Ihre Einstellungen entscheiden, wie aus dieser Verteilung ein Token wird. Die Regler interagieren, also zählt die Reihenfolge der Operationen mehr als jeder einzelne Wert.

Die Pipeline, der Reihe nach

Die meisten Engines wenden Sampler ungefähr in dieser Reihenfolge an:

• Logits — rohe Scores, einer pro Vokabular-Token (50k–150k Einträge).
• Wiederholungs-Strafen — kürzlich gesehene Tokens bekommen ihre Logits nach unten gedrückt.
• Temperatur — Logits durch T geteilt, alles schärfend oder einebnend.
• top_k — harte Kappe: nur die k besten Tokens überleben.
• top_p — Nucleus: die kleinste Top-Menge, die p der Wahrscheinlichkeitsmasse abdeckt.
• min_p — relativer Boden: Tokens unter min_p × P(Top-Token) fallen lassen.
• Samplen — ein Token aus dem Rest wählen, anhängen, wiederholen.

Ein früh angewandter Filter verändert, was jeder spätere Filter sieht. Behalten Sie das beim Stapeln im Kopf.

Temperatur

Die Temperatur T teilt die Logits vor dem Softmax. Niedrigeres T schärft die Verteilung Richtung Top-Token; höheres T einebnet sie Richtung Gleichverteilung. Konkret: Logits [5.0, 3.0, 1.0] über drei Tokens.

Bei T → 0 kollabiert das zu Greedy: immer Argmax, voll deterministisch.

Nutzen Sie Temperatur 0 (oder 0,000001, wo eine Engine 0 verweigert) für Extraktion, Klassifikation und alles, was Durchlauf für Durchlauf reproduzierbar sein soll. Chat will 0,6–0,8; kreatives Schreiben verträgt 0,9–1,2.

top_k: eine harte Kappe

Behalten Sie nur die k wahrscheinlichsten Tokens und samplen Sie unter ihnen. top_k 40 macht Token 41 und darunter unmöglich, egal was kommt.

Es ist ein grobes Werkzeug. k=40 ist geräumig nach „The capital of France is“ und absurd verschwenderisch an Positionen seltener Tokens, an denen nur zwei Kandidaten zählen. Üblicher Default: 40. Deaktivieren Sie es (0 oder -1, je nach Engine), wenn Sie min_p nutzen.

top_p: der Nucleus

Nach Wahrscheinlichkeit sortieren, die kleinste Menge behalten, deren kumulierte Wahrscheinlichkeit p erreicht, renormalisieren, samplen.

Durchgerechnet: Wahrscheinlichkeiten [0.867, 0.117, 0.016] mit top_p 0.9. Das Top-Token allein deckt 0,867 < 0,9; das Hinzufügen des zweiten erreicht 0,984 ≥ 0,9. Sie samplen aus zwei Tokens, renormalisiert auf [0.88, 0.12].

Die Kandidatenmenge schrumpft automatisch, wenn das Model sicher ist, und wächst, wenn es unsicher ist. Typischer Bereich: 0,9–0,95.

min_p: der lokale Favorit

Behalten Sie nur Tokens, deren Wahrscheinlichkeit mindestens min_p × P(Top-Token) ist. Der Boden ist skalierungsrelativ:

• Model zu 99% sicher → Boden = 0,05 × 0,99 ≈ 0,05: Nur echte Anwärter überleben.
• Top-Token bei 30% → Boden = 0,05 × 0,30 = 0,015: Vielfalt überlebt.

Das tötet die klassischen top_k/top_p-Fehlschläge — das Über-Beschneiden einer sicheren Verteilung, das Unter-Beschneiden einer flachen — und min_p lässt sich sicher mit hoher Temperatur kombinieren. Das Rezept „kreativ, aber kohärent“: Temperatur 1,0–1,5, min_p 0,05–0,1. Übliche lokale Einstellung: min_p 0.05 mit top_k und top_p aus.

repeat_penalty (llama.cpp-Familie)

Bevor die Temperatur angewandt wird, werden die Logits von Tokens, die im aktuellen Kontext erschienen, durch die Penalty geteilt. Werte unter 1,0 verstärken die Wiederholung stattdessen. Vernünftiger Bereich: 1,0–1,1.

Nebenwirkungen sind real, denn Code und Daten wiederholen Tokens absichtlich:

• Bezeichner wiederholen sich legitimerweise: count innerhalb von counter.count.
• JSON-Keys und schließende Klammern wiederholen sich in jedem Objekt eines Arrays.
• Penalty 1,2+ bricht Code und JSON (verlorene Klammern, „korrigierte“ Anführungszeichen), lange bevor sie Prosaschleifen repariert.

Moderne Instruct-Modelle brauchen selten mehr als 1,05. Für Code und strukturierte Ausgabe ist 1,0 eine legitime Wahl.

frequency- und presence-penalty (API-Stil)

OpenAI-kompatible APIs legen frequency_penalty (wächst mit jeder Wiederholung) und presence_penalty (flache Strafe für jedes schon gesehene Token) frei, wo llama.cpp repeat_penalty nutzt. Gleiche Absicht, andere Mathematik. Nicht jede lokale Engine ehrt beide — prüfen Sie, was Ihre implementiert, bevor Sie sie übereinanderstapeln: Engine-Regler.

Sampler in die Ecke stapeln

Temperatur 0,1 + top_k 10 + top_p 0,5 + min_p 0,2 + repeat_penalty 1,3, zusammen angewandt, können jedes Kandidaten-Token maskieren. Symptome: NaN-Logprob-Warnungen, leere Generierungen, „Sampling lieferte null Kandidaten“-Abbrüche.

Das ist kein kaputtes Model — es ist eine leere Kandidatenmenge. Lockern Sie den Stapel, einen Regler nach dem anderen. Volle Triage: Fehlerbehebung.

Presets, die funktionieren

Die Chat-Zeile als llama.cpp-Flags:

llama-server -m model.gguf --temp 0.7 --top-p 0.95 --min-p 0.05 --repeat-penalty 1.05

Ändern Sie eine Sache nach der anderen

Behandeln Sie die Presets als Startpunkte, nicht als Gesetze. Bewegen Sie Temperatur und top_p zusammen und die Ausgabe bessert sich, haben Sie nichts darüber gelernt, welcher Regler es war.

1. Legen Sie einen Testsatz fest: 5–10 Prompts, die abdecken, worum es Ihnen geht.
2. Speichern Sie die Ausgaben pro Konfiguration; diffen Sie sie Seite an Seite.
3. Ändern Sie pro Lauf genau einen Regler.
4. Speichern Sie den Gewinner als benanntes Preset — jede Engine und UI speichert sie.

Wie diese Regler auf Engine-Flags und API-Felder abbilden: Engine-Regler.

Verwandt: Engine-Regler · Prompting · Strukturierte Ausgabe · Fehlerbehebung