Roleplay LLM Settings: Tune One Variable at a Time

To tune roleplay LLM settings, save a fixed chat snapshot and change one control at a time from the exact model’s documented baseline. Compare several separate continuations before keeping a change. One appealing reply is too little evidence to choose a setting.

This guide assumes you already have a model. Start with choosing a small roleplay model if that decision is still open. The distinction between LM Studio and a dedicated companion app is a separate question. Here, the model and character stay put. The procedure below is proposed advice based on sampling documentation, not a hands-on benchmark.

A useful comparison keeps the model and scene fixed

The short version: Record enough detail to restore the same baseline before each parameter trial.

Make a comparison note before generating anything:

• Save the exact checkpoint, quantization, app and backend versions, chat template, and thinking mode.
• Copy the character card, greeting, scene prompt, and history. Set a fixed output cap.
• Record every active sampler and penalty, including penalty range and sampler order where available. Save the seed if your backend exposes one.

Sampler order belongs in that note: llama.cpp explicitly supports an ordered sampler list.[4] Do not assume every app exposes every control. Mark an unavailable field as unavailable rather than guessing its value.

Choose what you want to preserve. For this comparison, judge whether the character answers the scene, keeps a plausible voice, leaves the player’s actions to the player, and avoids redundant gestures.

Restore the recorded baseline before each new trial. If you change temperature, then adjust top-p on top of it, you are comparing a combined change. Changing the model at the same time prevents a useful same-model comparison.

Temperature changes variety, not the character’s identity

The short version: Try a small temperature change relative to the documented baseline, then judge the writing rather than its surprise value.

Temperature affects token selection. SillyTavern describes lower temperature as favoring higher-probability tokens, while higher temperature gives less likely tokens a better chance.[2] Neither description promises a more faithful character.

If you want less predictable wording, test a small increase while leaving everything else fixed. Reject it if the character starts ignoring the question or choosing actions for the player. If you try a decrease, check whether dialogue becomes repetitive instead of assuming predictability means consistency.

Lower is not an anti-loop guarantee. The original Qwen3-4B card specifically warns against greedy decoding in thinking mode because it can degrade performance and produce endless repetition.[3] Respect that model-specific caution rather than treating the lowest possible randomness as the safest choice.

Top-p limits the token choices that remain available

The short version: Top-p is a cumulative-probability cutoff, so test it separately from temperature and other filters.

Top-p, also called nucleus sampling, keeps the highest-probability token choices needed to reach its probability threshold.[2] A value of 0.80 does not mean keeping 80 percent of the vocabulary. The cutoff concerns the combined probability of the retained choices, not their share of the dictionary.[2]

For a top-p trial, restore baseline temperature first. Hold top-k and min-p fixed too. Log their existing values even if you are not testing them; SillyTavern warns that an excessively high min-p can worsen repetition.[2]

Temperature changes token probabilities and top-p filters the available choices, so their effects can interact.[2] A controlled comparison helps you interpret a change under your recorded conditions. It does not establish an ideal top-p for every scene.

Repeat penalty can remove useful words along with repeated ones

The short version: Separate penalty strength from lookback range, and preserve the exact parameter name.

LM Studio’s documented chat API describes repeat_penalty as a penalty for repeating token sequences: 1 is neutral, and higher values discourage repetition.[1] Treat it as an intervention on reused tokens, not a guarantee that a character will stop repeating a narrative beat.

Strength and range answer different questions. Strength concerns how much to penalize; range concerns how much recent token history to consider.[1][2] SillyTavern warns that an excessive repetition-penalty range can damage responses because common words get penalized.[2] That warning does not establish a universal maximum for penalty strength.

llama.cpp documents repeat_penalty, presence_penalty, and frequency_penalty as separate controls.[4] Do not assume their numbers are interchangeable or that every backend scores repetition identically. The Qwen3-4B-GGUF recommendation discussed below names presence penalty specifically.[6] Copying that number into repeat penalty would change the wrong parameter.

When reviewing a penalty trial, check ordinary language as well as repeated gestures. Reject awkward wording even if it removes the phrase you were trying to avoid.

The model card beats a universal roleplay preset

The short version: Read the recommendation for your exact model, mode, and format before borrowing any numbers.

Model-specific example, not a roleplay preset: the original Qwen3-4B card recommends these different sampling settings for its two modes.[3]

Mode	Temperature	Top-p	Top-k	Min-p
Thinking	0.6	0.95	20	0
Non-thinking	0.7	0.8	20	0

The official Qwen3-4B-GGUF card additionally recommends presence_penalty=1.5 for quantized models. It warns that a higher presence penalty may cause language mixing and slightly reduce performance.[6] This is not repeat_penalty=1.5.

These are publisher recommendations for one model, with explicit mode and format distinctions. They are not measurements from this article or a ranking of roleplay models. Do not transfer them to Qwen3.5 or a community fine-tune on the strength of a shared family name.

Use the applicable card to establish your starting point, then record any backend-specific differences. A screenshot of someone else’s settings cannot replace those details.

A small worksheet makes the trade-offs visible

The short version: Compare several continuations from the same snapshot, leave room for failures, and restore the baseline when a change costs too much.

Fictional worksheet. The scene and numbers below are illustrative; no model was run and no results were measured. This is not a preset recommendation.

Mira is repairing an observatory door during a storm. The player asks, “The red wire is live. What should we check before touching it?” The player controls their own actions. Keep the character card, greeting, prompt, and clean history identical.

Replace A with your exact model’s supported baseline and choose admissible small changes. Keep unshown controls fixed, including presence and frequency penalties, penalty range, sampler order, thinking mode, and output cap.

For each condition, record the seed if available. Note whether Mira answers the wire question, preserves player control, keeps her voice, repeats a phrase or gesture, and gives the scene a concrete next step. Leave the published observation cells empty; fill your own after generating several separate continuations from the saved snapshot.

A seed helps pair conditions, but it is not a portable promise of identical output. llama.cpp warns that cache_prompt can produce nondeterministic results because different batch sizes can produce different logits, depending on the backend.[4] Log cache or batch changes as confounders.

If the existing chat already loops, diagnose a repetition loop first rather than adding more sampler changes. Keep whichever trial best meets your written priorities, including the unchanged baseline if nothing improves. Save the rejected trade-offs alongside it. For app compatibility rather than sampler tuning, consult the Local Waifu system requirements.

Sources

[1] https://lmstudio.ai/docs/developer/rest/chat [2] https://docs.sillytavern.app/usage/common-settings [3] https://huggingface.co/Qwen/Qwen3-4B [4] https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md [6] https://huggingface.co/Qwen/Qwen3-4B-GGUF

Questions people ask

Back to the blog