UPSTREAM PR #16933: server: add minimax-m2 reasoning format override for MiniMax-M2 compatibility

[DajanaV]

Mirrored from ggml-org/llama.cpp#16933

Description

MiniMax-M2 models require the complete <think>...</think> block including tags to be present in the context for proper reasoning. This PR adds a minimal reasoning format override that injects a synthetic opening <think> tag while keeping all reasoning content inline, ensuring compatibility with existing clients without modifying the current parsing behavior.
This approach is equivalent to reasoning_format=none but with synthetic prefix injection. When set via --reasoning-format minimax-m2 at server startup, it overrides client API requests that specify reasoning_format=auto, allowing the model to receive the full reasoning block it needs while remaining compatible with all OpenAI-compatible clients.

Changes

• Add COMMON_REASONING_FORMAT_MINIMAX_M2 enum value to common_reasoning_format
• Implement minimax-m2 format parsing that bypasses reasoning extraction
• Inject synthetic <think>\n chunk before first generated token when minimax-m2 is active
• Track injection state with minimax_reasoning_prefix_injected and minimax_reasoning_prefix_streamed slot flags
• Prepend <think>\n to generated_text for final response and chat parsing
• Prevent client reasoning_format=auto from overriding server CLI setting
• Add minimax-m2 to CLI help, README.md, and code documentation
• Handle LLAMA_TOKEN_NULL in send_partial_response to skip token recording
• Update process_token to preserve delta_to_send for streaming correctness
• Defer synthetic prefix injection until first generated token for better UX

Testing

Tested with MiniMax-M2-230B model using --reasoning-format minimax-m2 flag on stock Svelte UI.

[loci-review]

Access the complete analysis in the LOCI Dashboard

Performance Analysis Summary: PR #45 MiniMax-M2 Reasoning Format

Critical Function Analysis

Core Inference Functions

All critical inference functions show no measurable performance impact:

• llama_decode: 49,003,916 ns (baseline: 49,003,848 ns) - No change
• llama_encode: 12,329,226 ns (baseline: 12,329,209 ns) - No change
• llama_tokenize: 834,827 ns (baseline: 834,829 ns) - No change
• llama_model_quantize: 6,891,692 ns (baseline: 6,891,727 ns) - No change
• llama_batch_init: 257 ns (baseline: 257 ns) - No change
• llama_memory_clear: 49 ns (baseline: 49 ns) - No change

Key Finding: None of the core inference functions were modified or show performance degradation.

Performance Impact Analysis by KPI

1. Tokens Per Second

Impact: No measurable impact on inference throughput

• Core inference functions (llama_decode, llama_encode, llama_tokenize) show no performance changes
• Changes are isolated to server-side chat parsing and streaming logic
• The MiniMax-M2 feature operates at the application layer without affecting token processing pipelines

2. Power Consumption

Impact: Negligible change across all binaries

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

Analysis: Power consumption remains stable as core computational functions are unaffected.

3. Quantization Efficiency

Impact: No impact

• llama_model_quantize function shows no performance changes
• Quantization logic remains unchanged
• MiniMax-M2 feature operates independently of model quantization

4. Memory Usage

Impact: Minimal increase in server memory usage

• Affected Areas: Chat parsing and streaming buffers
• New Allocations: Synthetic <think> tag injection requires temporary string allocations
• Per-Slot Overhead: Two additional boolean flags per server slot
• Core Memory Systems: KV cache and model memory management unaffected

5. Batch Processing

Impact: No impact

• llama_batch_init and related batch functions show no changes
• Batch processing logic operates independently of chat formatting
• Token batching efficiency preserved

Root Cause Analysis

The observed performance degradations (PLT stub functions showing +0.043% to +0.113% increases) stem from:

Dynamic Linking Overhead

• Additional code paths in server module increase binary size
• Modified symbol table layout affects PLT resolution efficiency
• String manipulation functions add to the dynamic symbol table

String Processing Overhead

• text_to_parse.insert(0, "<think>\n") operations in chat parsing
• Additional conditional branches in parsing hot paths
• Memory allocation patterns for synthetic content injection

Action Items

Code Optimization

• String Operations: Replace insert(0, ...) with more efficient string building patterns
• Conditional Logic: Consolidate reasoning format checks into switch statements
• Memory Management: Use string views or pre-allocated buffers for synthetic content

Build Optimization

• Symbol Ordering: Optimize linker script to improve symbol locality
• Static Linking: Consider static linking for frequently used string functions
• Profile-Guided Optimization: Enable PGO to optimize new code paths

Architecture Improvements

• Strategy Pattern: Implement reasoning format handlers as separate classes
• Lazy Evaluation: Defer synthetic prefix operations until required
• Buffer Pooling: Use pre-allocated buffers for chat parsing operations

Conclusion

The MiniMax-M2 feature implementation introduces minimal performance overhead isolated to server-side chat processing. Core inference performance remains unaffected, ensuring no impact on tokens per second throughput. The observed degradations in PLT functions reflect dynamic linking overhead from additional code paths rather than algorithmic inefficiencies in critical inference functions.