Describe the bug

In eager mode, SimpleCPUOffloadScheduler can miss the final full KV block of a request when that block is computed in the same scheduler step where the request finishes.

The store planner only considers blocks whose KV data has been confirmed computed before the current scheduler step. The code already documents this edge case in vllm/v1/simple_kv_offload/manager.py:

# Only considers blocks whose KV data has been **confirmed computed** by
# the GPU. This means blocks from the current step are NOT stored until the
# next step. If a request finishes in the same step as its last full block,
# that block may be missed. (TODO: flush on finish.)

When the request finishes in that same step, request_finished() clears the eager store tracking state before a later scheduler step can observe and offload the newly completed block.

Impact

A later request that extends the same prompt can get a shorter CPU KV cache hit than expected. The final full block of the prior request is recomputed instead of being loaded from CPU offload.

This affects the SimpleCPUOffloadScheduler / SimpleCPUOffloadConnector path, not the older weight offload path.

Why this happens

The scheduler builds connector metadata before it advances request.num_computed_tokens for the current step:

1. Scheduler.schedule() calls connector.build_connector_meta(scheduler_output).
2. Only after that, _update_after_schedule() increments request.num_computed_tokens by the scheduled token count.
3. The model executes and the request may finish.
4. _free_request() calls the connector's request_finished() path.
5. SimpleCPUOffloadScheduler.request_finished() only defers cleanup for already in-flight stores. It does not flush the final block that became complete during the just-executed step.

So the current-step final block is visible too late for build_connector_meta(), and cleanup happens before the next opportunity to store it.

Minimal reproduction

This can be reproduced with the existing helpers in tests/v1/simple_kv_offload/test_scheduler.py:

1. Create an eager SimpleCPUOffloadScheduler.
2. Schedule a two-block request.
3. Store block 1 normally after it is confirmed computed.
4. Allocate block 2, but leave it unconfirmed when build_connector_meta() runs, matching the real scheduler order where connector metadata is built before _update_after_schedule().
5. Simulate _update_after_schedule() advancing num_computed_tokens so the second block is now complete.
6. Finish the request.
7. Submit an extended prompt whose prefix includes the original two-block request plus an extra block.

Observed result:

missed_final_store_event -1
missed_final_store_gpu_blocks []
extended_prompt_hit_tokens_after_miss 16

The second block was not scheduled for store, so the extended prompt only gets one block of CPU cache hit.

For comparison, if the second block is already confirmed before build_connector_meta() runs, it is stored and the extended prompt can hit both blocks:

stored_second_store_event 1
stored_second_store_gpu_blocks [3]
extended_prompt_hit_tokens_when_second_cached 32

Expected behavior

When a request finishes after computing a final full block, eager simple KV offload should either flush/store that final block before cleanup or preserve enough state to store it safely after the step completes.

Related work / not duplicates

I checked open issues and PRs for SimpleCPUOffloadScheduler, simple kv offload missed block, eager offload last block, and flush on finish kv offload.

Related but different:

• #39702: TOCTOU crash in update_state_after_alloc()
• #41289: deduplicating in-flight CPU offload stores across scheduler steps
• #39860: KV event support
• #19854: general KV cache offloading RFC