min_p
Min-p sampling
A sampling method that cuts candidates relative to the top token's probability: anything below p_max × min_p is discarded.
Top-k keeps a fixed number of candidates and top-p looks at cumulative probability. min_p moves the cutoff with the model's confidence at that step:
threshold = min_p × p_max
p_max is the probability of the most likely token. Every candidate
below the threshold is removed; sampling happens among the rest.
- Confident model (p_max = 0.9, min_p = 0.1) → threshold 0.09 → only a few candidates survive, the junk tail is gone.
- Uncertain model (p_max = 0.2) → threshold drops to 0.02 → many plausible candidates survive, diversity is preserved.
The method was introduced in 2024 in "Turning Up the Heat: Min-p Sampling for Creative and Coherent LLM Outputs" (Nguyen et al., arXiv 2407.01082). The paper reports gains in both quality and diversity, especially at high temperature where top-p struggles (GPQA, GSM8K, AlpacaEval Creative Writing; Mistral and Llama 3, 1B-123B).
Defaults (as of October 2026):
| Engine | Parameter | Default |
|---|---|---|
| Ollama | min_p | 0.0 (off) |
| llama.cpp | --min-p / min_p | 0.05 |
| vLLM | min_p | 0.0 (off) |
| OpenAI API | none | — |
llama.cpp's default sampler order is penalties → DRY → top-n-sigma → top-k → typical-p → top-p → min-p → XTC → temperature. So the min_p threshold is computed on the distribution before temperature is applied.
A competition with a "relative to the winner" cutoff. If the winner scores 90 and the cutoff is 10%, anyone under 9 is out. If the winner only scores 20 (everyone is close), the cutoff drops to 2 and many people make the final. A fixed "top 40" rule (top-k) can't tell the difference.
The model is completing "For breakfast I ate ___", with min_p = 0.1:
| Candidate | Probability | Threshold (0.1 × 0.55) | Result |
|---|---|---|---|
| eggs | 0.55 | 0.055 | kept |
| cheese | 0.25 | 0.055 | kept |
| toast | 0.12 | 0.055 | kept |
| pancakes | 0.06 | 0.055 | kept |
| screws | 0.01 | 0.055 | dropped |
Tail junk like "screws" can't be picked even if you raise the temperature, because it was removed before temperature runs.
To turn it on in Ollama: send "min_p": 0.05 in the request or add
PARAMETER min_p 0.05 to the Modelfile. In llama.cpp it is already on
at 0.05.
curl http://localhost:11434/api/generate -d '{
"model": "llama3.2",
"prompt": "Write a short poem about a lighthouse.",
"options": {
"min_p": 0.1,
"top_p": 1.0,
"temperature": 1.2
}
}'# New install (llama.app): llama serve
# Older binary name: llama-server
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF \
--min-p 0.1 \
--top-p 1.0 \
--top-k 0 \
--temp 1.2
# top-p 1.0 and top-k 0 = off; only min-p trims the tail- Creative writing, brainstorming — use high temperature without the gibberish
- When top-p feels too narrow on some steps and too wide on others
- On Ollama with tail problems — the default is 0.0, i.e. off
- When you want one simple knob (top-p 1.0, top-k 0, min_p 0.05-0.1)
- Deterministic output (temperature 0) — the top token is chosen anyway, min_p does nothing
- OpenAI API — the parameter doesn't exist
- Code, JSON, classification and other single-answer tasks — low temperature is the cleaner fix
Different defaults across engines
The same model runs with min_p 0.05 in llama.cpp and 0.0 in Ollama. Part of the 'fine in llama.cpp, rambling in Ollama' gap can come from this. When comparing, set the sampling options explicitly on both.
Setting min_p too high
Values like 0.3-0.5 leave a single candidate on most steps; output drifts toward greedy decoding and can fall into repetition loops. Start low if you want variety.
Stacking it on top-p and top-k
In llama.cpp, top-k (40) and top-p (0.95) are on by default and run before min-p. To actually see min-p's effect, turn the others off: --top-k 0 --top-p 1.0.