[Bugfix][Frontend] Clear the P0 multimodal cache through the renderer

[ZenAlexa]

Purpose

Failure

AsyncOmni.reset_mm_cache() leaves the frontend P0 multimodal cache populated across sleep and cache-clearing pause flows. EngineCore clears the receiver cache, so a later hash-only multimodal request can omit data the receiver now needs and finish empty.

Reproduction

The added CPU regression installs a renderer cache-clear spy and calls AsyncOmni.reset_mm_cache(). On main, it fails with:

Expected clear_mm_cache_async to have been awaited once. Awaited 0 times.

Root cause and fix

InputProcessor exposes the cache through its renderer; the previous code probes a nonexistent input_processor.mm_processor_cache attribute. This change calls renderer.clear_mm_cache_async(), preserving serialization with concurrent multimodal processing and matching vLLM's frontend cache-clear path.

EngineCore reset forwarding is tracked in #6766. This change owns the P0 frontend cache path used directly by sleep() and pause_generation(clear_cache=True).

Fixes #6972.

Test Plan

vLLM Version: v0.28.0 (2cf0a6915ce544dc493a0990f2ea38d81601128a)

vLLM-Omni Commit: ec22c7ac06ad1d344dbfcf6aaf8b641113bf87a5

pytest -q \
  tests/entrypoints/test_async_omni_pause_sleep_routing.py \
  tests/entrypoints/test_async_omni.py \
  -m "core_model and cpu" -o addopts=""

Test Result

33 passed, 2 deselected, 16 warnings in 1.03s

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vllm-omni-review-bot]

This PR appears to belong to: docs/design/module/entrypoints.md.

Module owners: @alex-jw-brooks @linyueqian @NickCao

@ZenAlexa, please review your own changes and leave a short self-review comment describing what you checked. PRs without author self-review may not be assigned a reviewer.

Please take a look when you have a chance. If you would like an automated review, mention @vllm-omni-review-bot in a comment.

[vllm-omni-review-bot]

Omni ReviewBot triage note

Automated triage of commit d4531d1023e5 produced:

• Priority: high. Prompt maintainer attention is suggested.

These are automated triage suggestions only — the final decision belongs to the maintainers.

[ZenAlexa]

Self-review: traced sleep() and pause_generation() through InputProcessor.renderer and the serialized BaseRenderer cache clear. The new regression fails on main with Awaited 0 times, and the affected CPU modules complete with 33 passed / 2 deselected. The change is scoped to the P0 frontend cache; #6766 continues to own EngineCore reset forwarding.

[ZenAlexa]

Updated the L1 regression to use the repository's mocker convention and retain BaseRenderer / InputProcessor autospecs. Applied to main@ea14b04e, the regression fails with Expected clear_mm_cache_async to have been awaited once. Awaited 0 times.; the branch passes the affected CPU modules with 33 passed, 2 deselected.

[knlnguyen1802]

This PR is ok for me. @SamitHuang Please help to take a look.

[linyueqian]

Good catch, and the fix is right. reset_mm_cache was not clearing anything: it read mm_processor_cache off the InputProcessor, which has no such attribute or property. Upstream keeps the cache on the renderer and InputProcessor reaches it through self.renderer.mm_processor_cache, so the getattr returned None every time and the method took its debug-log early return on every call. The whole P0 clear was dead, which is exactly the hash-only follow-up symptom the docstring was written to prevent.

Routing through renderer.clear_mm_cache_async() is also better than restoring the old sequence would have been. Upstream serializes that call on the multimodal executor specifically to avoid racing concurrent process_inputs on the cache, so the previous plan of calling a bare clear() from the request path would have fixed the no-op and introduced a race in its place.

Dropping the self.engine.input_processor fallback loses nothing, which is worth stating since removing a fallback usually deserves suspicion. __init__ assigns self.input_processor = self.engine.input_processor, so the two names are the same object and the fallback could only ever have produced the same None. Likewise the getattr(self, ...) defensiveness is unnecessary now that the attribute is set unconditionally in __init__.

The test asserts the routing rather than the mechanism, which is the durable choice here: it autospecs BaseRenderer and InputProcessor and checks clear_mm_cache_async is awaited once. That would have failed against the old code and it keeps passing if upstream changes what clear_mm_cache does internally.

No findings. Validation: static review at d4531d10 of both files against their merge base, plus the upstream definitions of BaseRenderer.clear_mm_cache, clear_mm_cache_async, mm_processor_cache and InputProcessor to confirm the attribute was genuinely absent rather than merely renamed. I did not execute the branch.