feat(lora): prefix cache adapter isolation (PR 3/3)

[cchh05]

Summary

Adds LoRA-aware isolation to xllm's prefix cache so that requests to different LoRA adapters (and base) do not cross-contaminate cached KV blocks.

Problem

When --enable_lora and --enable_prefix_cache are both enabled, requests with identical prompts served by different adapters produce the same block-level hash (because hashing keys on token ids alone). The prefix cache then hands adapter B's request the KV blocks cached under adapter A. The result is silent semantic corruption — the output still looks like valid natural language, but the attention computation used adapter A's KV values instead of recomputing with adapter B's LoRA delta applied.

Solution

Introduce a thread-local g_prefix_cache_adapter_id used by xxh3_128bits_hash to seed the first block hash of a chain:

• BlockManagerPool::allocate_shared and cache set the TLS before calling into CompositeBlockManager, then reset it to 0 after the call.
• xxh3_128bits_hash reads the TLS when pre_hash_value == nullptr (first block). If the id is non-zero, the id bytes are prepended to the token-id buffer before hashing, so identical prompts across adapters diverge at block 0.
• When the id is 0 (base model, no LoRA), hashing is byte-identical to the pre-patch baseline. Base-only services see no behavioral change.

Depends on

#2015 — needs Sequence::adapter_id() on the request path.

Files changed (3 files, +52 lines)

• `xllm/core/framework/prefix_cache/block_hasher.h` — declaration of `set_prefix_cache_adapter_id`
• `xllm/core/framework/prefix_cache/block_hasher.cpp` — TLS variable + setter + adapter_id-seeded hashing path
• `xllm/core/framework/block/block_manager_pool.cpp` — set/reset around the three prefix-cache entry points (`allocate_shared`, `cache(Sequence*)`, `cache(Sequence*, size_t)`)

Verification

Ascend NPU 910 · Qwen3-32B TP=4 · 4 adapters (Qwen3-32B base + deepnews r=32 + uncensored r=32 + dummy r=8) · identical 500-token prompt · 2 rounds each:

Test	Result
R1 == R2 sha256 identical for all 4 models	✅ PASS
Base != deepnews / uncensored sha256	✅ PASS
3 unique sha256 across base/deepnews/uncensored	✅ PASS
dummy (r=8) sha256 == base	expected — very-low-rank delta too weak to change argmax at temperature=0

Under stress (60 requests × concurrency=4, shared 400-token prefix): 60/60 ok, service stable.

Base-only safety

The only code path that behaves differently is inside xxh3_128bits_hash when the TLS is non-zero. In base-only deployments (no LoRA, --enable_lora=false), sequence->adapter_id() is always 0, so the TLS is always set to 0 → the else-branch runs → hashing is byte-identical to pre-patch.

Test plan

• Unit-level correctness: R1 == R2 sha256 identical across 4 adapters (see Verification)
• Cross-adapter isolation: 3 unique sha256
• Stress test: 60 requests × concurrency=4, no crash
• Add prefix cache unit test with adapter isolation assertion (follow-up)
• Add `--enable_lora_prefix_cache_isolation` CLI kill-switch for canary rollback (follow-up)

🤖 Generated with Claude Code