[Fix] data race in req_to_token pool

[cctry]

Motivation

The chunked prefill requests will free its slot in req_to_token_pool and get allocated again when preparing for its next prefill batch.

As a result, if a prefill batch contains multiple requests and req_to_token_pool is at capacity. The write for matched kv indices for another request will overwrite the slot of the chunked requests which is being read in forward stream

Example

Prepare & Launch prefill batch N:     
    req A (first half) --> idx 1  
    
model runner reads idx 1
  
Prepare batch N+1: 
    req A (second half) --> idx 2
    req B --> idx 1

scheduler writes req B's matched indices to idx 1

Modifications

1. alloc(reqs: list[Req]) - Now takes request list, sets req.req_pool_idx directly, reuses slot if already set. cc @hnyls2002
2. Separate free() with free_mamba_cache(req, ...) in HybridReqToTokenPool - Only frees mamba state, not req slot cc @hanming-lu @yizhang2077
3. release_kv_cache() - Now calls free(req) at end; handles early mamba-only free case
4. Removed free() in process_prefill_chunk and cache_finished_req

Accuracy Tests

Benchmarking and Profiling

Checklist

• Format your code according to the Format code with pre-commit.
• Add unit tests according to the Run and add unit tests.
• Update documentation according to Write documentations.
• Provide accuracy and speed benchmark results according to Test the accuracy and Benchmark the speed.
• Follow the SGLang code style guidance.
• Work with maintainers to merge your PR. See the PR Merge Process

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[cctry]

/tag-run-ci-label

[Henrry-CHEN]

so if a prefill batch contain 2 or more request or request chunk, the accuracy of the mamba state for these req is not right?

[cctry]

Mamba state is correct but full attention can be wrong

[ClawSeven]

Hi @cctry,
I have a question regarding the described race conditions. If we disable overlap scheduling, could there still be other write race conditions?

[ClawSeven]

@cctry, Oh, I see. Since the kernel is launched asynchronously, even with overlap scheduling disabled, there could still be a race condition between write_cache_indices and the backend reading the KV caches.
Thank you for the fix—the PR not only resolves the chunked prefill issue but also addresses a potential problem in dLLM.