Vllm Metax Registry Upgrade

vLLM-MetaX Registry Upgrade

Maintain the full contract from plugin activation to the selected implementation. A registered class name, matching signature, or upstream support declaration does not establish that the installed MetaX implementation supports the same behavior.

Scope and environment

• Apply to requested adaptations in vllm_metax/registry/, including quantization configurations, CustomOps and linear kernels. Inspect directly related oracles, experts, wrappers and callers outside that directory as necessary. Edit them only when needed for the authorized adaptation; do not expand into unrelated changes.
• For sparse indexers registered here, cover registration, constructor compatibility, dtype dispatch and wrapper contracts. Standalone attention algorithm, cache-index or numerical kernel work belongs to the attention workflow. Monkey patches belong to the patch workflow. Do not automatically invoke either skill, impose patch headers, or write registry findings into vllm_metax/patch/AUDIT.md.
• Keep review-only requests read-only. Identify the subject: staged snapshot, working tree, installed package or specified revision. Preserve user changes and do not stage, commit, reinstall packages or edit upstream/site-packages without authorization. For staged validation, export the index and prove that imports use that snapshot; unstaged files must not silently supply missing staged dependencies.
• Read applicable repository instructions.
• Read and apply vllm-metax-upgrade-common before compatibility decisions. It owns environment/source discovery, the shared read-only probe, one-time target confirmation and verification evidence rules. Reuse the same established environment record across upgrade skills; do not ask again for an unchanged mapping. Keep the domain-specific workflow below.

Trace registration and dispatch

Inventory every requested registration, including inactive/conditional entries and aggregate import files. Record the registry key or target, activation path, effective class/callable, upstream counterpart, MetaX difference, decision and evidence.

Trace the actual chain:

plugin entry point -> package imports -> decorator/table mutation
-> config lookup or CustomOp/platform dispatch -> selected method
-> backend oracle -> experts/prepare-finalize -> wrapper -> installed kernel

• Exercise fresh-process plugin startup as well as direct module imports. One missing symbol in an eagerly imported quantization module can break every registration. A partially populated registry after an exception is not successful startup.
• Resolve aliases, lazy exports, module redirects, duplicate keys and import ordering. Verify the effective lookup result and caller binding, not only decorator presence.
• Check exact platform keys (including OOT), dtype/capability predicates and explicit backend overrides. Preserve other platforms' entries and explicit user choices.
• For overridden classes, inspect the current MRO and inherited methods. A copied constructor's super() may now call a parent with a different signature. Bypassing that parent requires initializing all state consumed by inherited allocation, loading, quant-config and execution methods.
• Check actual factory signatures and return contracts. Follow the selected class's module/source through kernel invocation. A MetaX-named oracle can still return upstream experts and bypass MCOPLIB, local tuning or communication adaptations, which could lead to potential errors.
• Distinguish shared and separately defined enums. Matching member names or values do not make members of different Enum classes interchangeable in backend dispatch.