UPSTREAM PR #16784: webui: auto-refresh /props on inference start to resync model metadata

[DajanaV]

Mirrored from ggml-org/llama.cpp#16784

• Add no-cache headers to /props and /slots

• Throttle slot checks to 30s

• Prevent concurrent fetches with promise guard

• Trigger refresh from chat streaming for legacy and ModelSelector

• Show dynamic serverWarning when using cached data

• Updated assistant message bubbles to show each message's stored model when available,
  falling back to the current server model only when the per-message value is missing

• When the model selector is disabled, now fetches /props and prioritizes that model name
  over chunk metadata, then persists it with the streamed message so legacy mode properly
  reflects the backend configuration

Cmdline used on legacy (Raspberry Pi 5) :

/root/llama.cpp/build/bin/llama-server \
 -m /root/ia/models/mradermacher/OLMoE-1B-7B-0125-Instruct-i1-GGUF/OLMoE-1B-7B-0125-Instruct.i1-Q6_K.gguf \
 -ctk q8_0 -ctv q8_0 -fa on \
 --jinja --ctx-size 8192 --mlock --port 8081

/root/llama.cpp/build/bin/llama-server \
 -m /root/ia/models/mradermacher/OLMoE-1B-7B-0125-SFT-i1-GGUF/OLMoE-1B-7B-0125-SFT.i1-Q6_K.gguf \
 -ctk q8_0 -ctv q8_0 -fa on \
 --jinja --ctx-size 8192 --mlock --port 8081

/root/llama.cpp/build/bin/llama-server \
 -m /root/ia/models/mradermacher/Qwen3-30B-A3B-Instruct-2507-i1-GGUF/Qwen3-30B-A3B-Instruct-2507.i1-Q4_K_M.gguf \
 --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0 \
 -ctk q8_0 -ctv q8_0 -fa on \
 --jinja --ctx-size 4096 --port 8081

Fixes ggml-org/llama.cpp#16771

EDIT : I've recorded a video that specifically targets the original issue.
Testing video, Raspberry Pi 5 + master branch + this PR :

CmdLineSwap-RaspberryPi5.mp4

And another one to show there's no regression when the model selector is enabled,
also demonstrating the multimodal function updates:

NonReg-FullSetup.mp4

[loci-agentic-ai]

Access the complete analysis in the LOCI Dashboard

Based on my analysis of the performance data for project 2621b8c0-b5ce-11f0-b333-453f42058aa1 comparing version 69466bd6-9a46-44f0-aa6c-d9f4f4737e08 against base version 8306f911-f47a-4005-9b4c-b62b55eeb2e9, here's the comprehensive performance summary:

LLaMA.cpp Performance Analysis Summary

Critical Function Performance Changes

Response Time Degradation

• Function: deallocate in llama-model-loader.cpp
• Binary: build.bin.libllama.so
• Change: +0.033% (56 ns vs 56 ns base)
• Status: No code modifications detected between versions

Throughput and Bottleneck Degradation

• Function: _Construct (std::vector constructor)
• Binary: build.bin.libllama.so
• Throughput Change: +0.050% (23 ns vs 23 ns base)
• Bottleneck Change: +0.109% (11 ns vs 11 ns base)
• Status: No code modifications detected between versions

KPI Impact Analysis

1. Tokens Per Second Impact

Status: No measurable impact on inference throughput

Critical Functions Analysis:

• llama_decode(): No performance changes detected
• llama_encode(): No performance changes detected
• llama_tokenize(): No performance changes detected
• llama_detokenize(): No performance changes detected

Assessment: The observed degradations are in memory management functions (deallocate, _Construct) rather than core inference functions. Based on the reference that 2ms slower llama_decode results in 7% fewer tokens/second, the current 0.018ns degradation in unrelated functions will not impact tokens per second performance.

2. Power Consumption Impact

Binary-Level Analysis:

• build.bin.libllama.so: -0.0% change (306,978 nJ vs 306,978 nJ base)
• build.bin.libggml-base.so: 0.0% change
• build.bin.libggml-cpu.so: 0.0% change
• build.bin.libggml.so: 0.0% change

Assessment: No measurable power consumption changes across all binaries.

3. Quantization Efficiency

Critical Functions Analysis:

• llama_model_quantize(): No performance changes detected
• ggml_quantize_free(): No performance changes detected
• Quantization format handling: No changes detected

Assessment: No impact on quantization efficiency.

4. Memory Usage Impact

Affected Functions:

• deallocate function: +0.033% response time degradation
• _Construct (vector): +0.050% throughput, +0.109% bottleneck degradation

Memory Management Functions:

• llama_memory_clear(): No changes detected
• llama_memory_seq_rm(): No changes detected
• llama_memory_seq_cp(): No changes detected
• ggml_gallocr_new(): No changes detected
• ggml_tallocr_alloc(): No changes detected

Assessment: Minor degradation in standard library memory allocation functions, but core LLaMA memory management functions remain unaffected.

5. Batch Processing Impact

Critical Functions Analysis:

• llama_batch_init(): No performance changes detected
• llama_batch_get_one(): No performance changes detected
• llama_batch_free(): No performance changes detected
• llama_decode() (batch processing): No performance changes detected

Assessment: No impact on batch processing efficiency.

Root Cause Analysis

Assembly Code Investigation: The deallocate function shows identical assembly code between versions, indicating the performance difference stems from environmental factors rather than code changes.

Control Flow Analysis: No structural changes detected in any critical functions. The CFGs for affected functions are identical between versions.

Action Items

Immediate Actions

1. Build Environment Consistency: Verify compiler version, optimization flags (-O2, -O3), and link-time optimization (LTO) settings are identical between builds
2. Binary Layout Verification: Check for differences in section alignment or memory layout that could affect cache behavior
3. Measurement Validation: The 0.033% degradation falls within typical profiling variance margins

Code-Focused Optimizations

1. Size Calculation Optimization in deallocate: The current 7-instruction sequence for size calculation (size * 88) could be optimized to 2 instructions using direct multiplication
2. Vector Constructor: Consider alternatives to std::vector<bool> if bit-packing overhead becomes significant in hot paths

Build System Recommendations

1. Compiler Flag Alignment: Ensure consistent optimization flags across build environments
2. Link-Time Optimization: Verify LTO configuration consistency
3. Profile-Guided Optimization: Consider PGO for performance-critical builds

Conclusion

The observed performance changes are minimal (all under 0.11%) and appear to be measurement variance rather than functional regressions. No critical inference functions show degradation, and power consumption remains unchanged. The core LLaMA.cpp inference pipeline maintains its performance characteristics with no impact on tokens per second, quantization efficiency, or batch processing capabilities.