CI check: detect orphaned quantization kernels vs. Python registry drift (VPTQ, AQLM, GGUF affected)

[Nakanokensetsu]

Title

CI check: detect orphaned quantization kernels vs. Python registry drift (VPTQ, AQLM, GGUF affected)

Summary

Several fork-specific quantization methods have silently lost their Python-side
registration while their CUDA kernel sources remain in the tree, unreachable and
unbuilt. Found by directly diffing git ls-tree against
aphrodite/model_executor/layers/quantization/__init__.py on v0.24.0:

Method	Kernel source present	Registered in __init__.py	CMakeLists build target
VPTQ	csrc/quantization/vptq/gemm_kernels.cu	❌	❌
AQLM	csrc/quantization/aqlm/gemm_kernels.cu	❌	❌
GGUF	csrc/quantization/gguf/*.cu (multiple files)	❌ (moved to OOT aphrodite-gguf-plugin, which is unpublished)	❌

Root cause (VPTQ case, traced via git history)

• VPTQ was added in quantization: add VPTQ support #1199 (2025-02-19), based on then-unmerged upstream
  vllm-project/vllm#12117.
• It was silently dropped during feat: update aphrodite to 0.20.0 (feat: update aphrodite to 0.20.0 #1628,
  2026-04-24) — a large upstream-sync PR that also restructured
  aphrodite/quantization/ → aphrodite/model_executor/layers/quantization/
  and kernels/ → csrc/. The kernel file moved with the restructure; the
  Python registration (vptq.py, __init__.py entry, _custom_ops.py
  bindings) did not.
• No test caught this: the build still succeeds, --quantization vptq just
  isn't a recognized value.

Upstream vllm-project/vllm does not have this problem — comparing
csrc/quantization/ on main, removed methods (e.g. AQLM, removed in
vllm-project/vllm#22943) have their kernel source deleted in the same PR as
the Python module. The drift is specific to how this fork's sync process
handles fork-only additions during large upstream merges.

Proposed fix

Add a lightweight CI check (a few lines, no runtime cost) that cross-checks
two lists:

1. Subdirectories of csrc/quantization/*/
2. Names registered in aphrodite/model_executor/layers/quantization/__init__.py

Fail CI if either side has an entry the other doesn't (with an explicit
allowlist for methods intentionally kernel-only-not-yet-wired or
registration-only-CPU-fallback, if any exist).

A more structural fix — worth considering separately — is co-locating each
quantization method's Python config, kernel source, and bindings under one
directory (aphrodite/quantization_methods/<name>/{config.py,kernel.cu, bindings.cpp}) instead of two independently-synced trees
(aphrodite/model_executor/layers/quantization/ and csrc/quantization/).
This makes partial deletion during a merge structurally harder: deleting or
keeping the method is an atomic directory operation instead of two
independently-tracked file locations that can silently drift apart, as
happened here. Third-party OOT plugins (e.g. vllm-gguf-plugin,
cnygaard/glq) already use this self-contained layout and don't hit this
failure mode, for the same reason.

Impact

Users relying on release notes / wiki / --quantization <method> docs (which
still list VPTQ, AQLM, GGUF as supported) hit a confusing failure with no
clear signal that the feature was dropped rather than misconfigured on their
end.