Misc. bug: UI doesn't sync with llama-server command-line parameters

[DigitalKO]

Name and Version

$./llama-server --version
version: 6561 (8ba548d)
built with cc (Debian 14.2.0-19) 14.2.0 for x86_64-linux-gnu

Five days ago, I posted this issue in the discussion section (#16103). After further reflection, I believe it's more accurately categorized as a bug rather than an enhancement request.

I've identified two misleading behaviors in Llama.cpp:

1. When loading a model with parameters specified via the command line (using llama-server), these parameters are not reflected in the user interface (UI).
2. When switching to a different model, the UI continues to apply the previous model’s parameters instead of utilizing the command-line settings for the new model.

This behavior leads to a poor user experience, as incorrect parameters are applied, resulting in suboptimal model performance.

Proposed Solution

To address these issues, we could fetch data from the /props endpoint and apply it as the default configuration in the UI.

Below is a basic example demonstrating the intended functionality:

const props = fetch('/props')
  .then((response) => {
    if (!response.ok) {
      throw new Error(`HTTP error! Status: ${response.status}`);
    }
    return response.json();
  })
  .then((props) => {
    console.log(props);
    localStorage.setItem('config', JSON.stringify({
      "apiKey": "",
      "systemMessage": "You are a helpful assistant.",
      "showTokensPerSecond": true,
      "showThoughtInProgress": true,
      "excludeThoughtOnReq": true,
      "pasteLongTextToFileLen": 15500,
      "samplers": "edkypmxt",
      "temperature": props['default_generation_settings']['params']['temperature'],
      "dynatemp_range": 0,
      "dynatemp_exponent": 1,
      "top_k": props['default_generation_settings']['params']['top_k'],
      "top_p": props['default_generation_settings']['params']['top_p'],
      "min_p": props['default_generation_settings']['params']['min_p'],
      "xtc_probability": 0,
      "xtc_threshold": 0.1,
      "typical_p": 1,
      "repeat_last_n": 64,
      "repeat_penalty": 1,
      "presence_penalty": 1.5,
      "frequency_penalty": 0,
      "dry_multiplier": 0,
      "dry_base": 1.75,
      "dry_allowed_length": 2,
      "dry_penalty_last_n": -1,
      "max_tokens": -1,
      "custom": "",
      "pyIntepreterEnabled": false
    }));
  })
  .catch((error) => {
    console.error('Failed to fetch /props:', error);
  });


### Operating systems

Linux

### Which llama.cpp modules do you know to be affected?

llama-server

### Command line

```shell
/llama-server --port 8090 --model ~/Ai/Models/google/unsloth/gemma-3-27b-it-qat-UD-Q5_K_XL.gguf --ctx-size 32768 --n-gpu-layers 64 --prio 3 --temp 1.0 --min-p 0.01 --top-p 0.95 --top-k 64 --presence-penalty 1.0 --jinja --reasoning-format none --flash-attn on --threads 6

Problem description & steps to reproduce

Use these parameters and compare with the UI settings.
--temp 1.0 --min-p 0.01 --top-p 0.95 --top-k 64

First Bad Commit

Since the beginning?

Relevant log output

[openingnow]

related: #16201

[ServeurpersoCom]

I'd argue the cleanest behavior would be: if a sampling field in the WebUI is left empty, the parameter should simply not be sent at all in the JSON request.

That way, the server applies the defaults it was launched with (--temp, --top_p, --top_k, --min_p, etc.), instead of having the UI silently override them with zeroes or hardcoded fallback values.

This would also align perfectly with OpenAI-Compat semantics: omission means “use the server's configured defaults.”

[DigitalKO]

I'd argue the cleanest behavior would be: if a sampling field in the WebUI is left empty, the parameter should simply not be sent at all in the JSON request.

Not sure why the cleanest behavior would be to omit the sampling field. What is the rationale behind?

I would argue that having the parameters sent at all in the JSON request can be useful for testing the behavior of a model with different value. And even if there are unit tests done, to ensure that all data are considered.

[ServeurpersoCom]

I'd argue the cleanest behavior would be: if a sampling field in the WebUI is left empty, the parameter should simply not be sent at all in the JSON request.

Not sure why the cleanest behavior would be to omit the sampling field. What is the rationale behind?

I would argue that having the parameters sent at all in the JSON request can be useful for testing the behavior of a model with different value. And even if there are unit tests done, to ensure that all data are considered.

The important part is the difference between omitting a field and sending a field with a value.

Omitting means "use the server defaults" (the values configured with --temp, --top_p, etc).
Sending a value means "override the defaults with this explicit number", even if that number is 0.

If the WebUI always sends fallback values, it silently overrides the actual server defaults. That is why the cleanest behavior is to simply not send a field when it is left empty. This matches OpenAI-compatible semantics: omission = let the server decide.

This does not prevent the UI from reading /proc to fetch the current values from llama-server, but keep in mind that in a llama-swap scenario the server instance may change frequently.

[DigitalKO]

Sorry, my previous answer was not posted on the correct issue.

[DigitalKO]

I understand your point about the importance of distinguishing between omitting a field and sending a default value.

This is a matter of preference: not sending a field when it's left empty, or sending the value set by the server.

If the WebUI sends the server's current value, it doesn’t necessarily override the actual server defaults, but rather reflects its configuration – and also facilitates easier debugging and testing with explicit values.

Therefore, I’m not convinced we can state that "this is why the cleanest behavior is to simply not send a field when it is left empty."

[allozaur]

I will work on this this week. Also related to #14839 (comment)