UPSTREAM PR #18730: lookahead: fix n_seq_max and kv_unified configuration

[loci-dev]

Mirrored from ggml-org/llama.cpp#18730

Summary

Fixes llama-lookahead configuration issues that have been broken since PR #14482 (July 2025).

Note: This PR depends on #18729 for the batch init fix. Both PRs are needed for lookahead to fully work.

Root Cause

Two lookahead-specific configuration issues:

1. Sequence count (n_seq_max)

PR #14482 changed seq_id validation from LLAMA_MAX_SEQ (large constant) to n_seq_max (context-specific). Lookahead needs W + G + 1 = 31 sequences for parallel Jacobi decoding, but params.n_parallel defaulted to 1.

2. KV unified mode

Batch splitting with "coupled sequences" requires unified KV cache. Lookahead didn't enable this, causing:

split_equal: sequential split is not supported when there are coupled sequences

Fix

// lookahead requires W + G + 1 sequences for parallel Jacobi decoding
params.n_parallel = W + G + 1;

// unified KV cache is required for coupled sequences in batch splitting
params.kv_unified = true;

Bug Timeline

Date	PR	Effect
Nov 2023	#4207	lookahead.cpp created - works
July 2025	#14482	seq_id validation changed - breaks lookahead

Testing

With both this PR and #18729 applied:

encoded    4 tokens in    0.138 seconds
decoded   51 tokens in   71.591 seconds
n_accept  = 13

Dependencies

• Requires #18729 for the batch init fix (params.n_ctx → llama_n_ctx(ctx))

---

Bug history researched with Claude.

[loci-review]

Explore the complete analysis inside the Version Insights

Perfect! I was able to retrieve the summary report for your project. Here's what the analysis shows:

Summary Report for llama.cpp PR #874

Project Information:

• Repository: llama.cpp (owner: auroralabs-loci)
• Pull Request: UPSTREAM PR #18730: lookahead: fix n_seq_max and kv_unified configuration #874
• Comparing versions between base and target

Key Findings:

✅ No significant performance changes detected

The performance analysis comparing the two versions shows that:

• No modified functions exhibited performance changes greater than 2% in response time
• No modified functions exhibited performance changes greater than 2% in throughput time

Conclusion:
The changes introduced in pull request #874 maintain performance stability with minimal to no measurable impact on the llama.cpp binary's performance characteristics. This is a positive result indicating that the code modifications don't introduce performance regressions.

Would you like me to provide more detailed information about specific functions or any other aspect of this comparison?