fix(metax): fall back to Triton cache ops when vllm C extensions are missing

[tengqm]

Problem

When vllm is built with VLLM_TARGET_DEVICE=empty, torch.ops._C_cache_ops is not registered. The MetaX flash attention backend calls vllm._custom_ops.reshape_and_cache_flash which delegates to that C extension — causing AttributeError at runtime:

AttributeError: '_OpNamespace' '_C_cache_ops' object has no attribute 'reshape_and_cache_flash'

Root cause

vllm's _custom_ops.py hardcodes torch.ops._C_cache_ops.reshape_and_cache_flash(...) — a compiled CUDA C extension that doesn't exist in empty builds.

Fix

vllm already ships a pure-Triton implementation (triton_reshape_and_cache_flash) in vllm.v1.attention.ops.triton_reshape_and_cache_flash for platforms missing the compiled extension. This patch monkey-patches _custom_ops to route through the Triton fallback when _C_cache_ops is absent.

The patch only fires when hasattr(torch.ops, '_C_cache_ops') is False — standard vllm wheels with compiled C extensions are completely unaffected.

Pattern

Follows the same pattern as the existing Triton kernel disablement in patches/__init__.py line 30-31.

Testing

Verified on MetaX C550 (MACA 3.7.2.0, torch 2.8.0+metax):

• vllm 0.20.2 built with VLLM_TARGET_DEVICE=empty
• vllm-plugin-FL main branch
• Qwen3-4B eager mode, flash attention — vllm serve starts and inference succeeds

prompt_tokens=9, completion_tokens=32 ✅

[tengqm]

This PR is not ready. Some further investigation is needed.

[tengqm]

Superseded by #333. #319's guard (hasattr(torch.ops, "_C_cache_ops")) is always True since the namespace is lazily auto-created, so the patch never fired; it also routed to vLLM's Triton op, which MetaX C550 disables. #333 registers reshape_and_cache_flash as a flag_gems dispatch op instead. Closing.