ci: fix numpy/numba, libnvJitLink.so.13, and gr00t AutoProcessor.register on align branch

Three regressions surfaced only on dev/vllm-align in Buildkite build 2520
(26 failing jobs vs 5 on main); ~15 of the 19 align-unique failures trace to these:

1. numpy 2.5 vs numba: Dockerfile.ci pinned numpy==2.2.6 before the flashinfer
   and torch cu130 reinstalls, which resolved numpy back to 2.5 and broke
   'import numba' (needs numpy <= 2.4). Re-pin numpy as the final dependency op.

2. libnvJitLink.so.13 not found: the CUDA-13 JIT linker lives in the
   nvidia-cuda-nvjitlink-cu13 wheel, not /usr/local/cuda (CUDA 12) as the old
   LD_LIBRARY_PATH assumed; bitsandbytes/torch.compile subprocesses could not
   dlopen it (broke Entrypoint L4, a multi-GPU diffusion job, both Quantization
   jobs via hang/timeout). Install the wheel and register its lib dir via ldconfig.

3. transformers >= 5.5 AutoProcessor.register now requires the config class, not a
   model_type string; processing_gr00t_n1d7.py passed "Gr00tN1d7" -> AttributeError
   'str' object has no attribute '__module__' -> pytest collection errors (exit 2).
   Pass Gr00tN1d7Config, matching AutoModel.register in modeling/gr00t_n1d7.py.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docker/Dockerfile.ci

@@ -21,11 +21,10 @@ RUN apt-get update && \
 # The cu130 wheel index lives at /<commit>/cu130/vllm/ but the actual wheel files
 # are stored at the top level /<commit>/<wheel>.
 ENV VLLM_PRECOMPILED_WHEEL_COMMIT=2dfaae752b4db0d43cfc0715c780e33be030d0f1
-# Ensure CUDA library path is in LD_LIBRARY_PATH so bitsandbytes' precompiled
-# C extension can find libnvJitLink.so.13 (CUDA 13.x JIT linker) at import time.
-# The base vLLM image has bitsandbytes pre-installed; without this env var,
-# worker subprocesses fail to load bitsandbytes' C extension, producing
-# OSError tracebacks that pollute CI logs.
+# Keep the base image's CUDA-12 toolkit libs on the loader path. NOTE: this does
+# NOT resolve libnvJitLink.so.13 (that CUDA-13 lib is not in /usr/local/cuda here) —
+# the .so.13 JIT linker is handled separately via ldconfig after the cu130 wheels
+# are installed (see the nvidia-cuda-nvjitlink-cu13 step below).
 ENV LD_LIBRARY_PATH=/usr/local/cuda/targets/x86_64-linux/lib:${LD_LIBRARY_PATH}
 RUN VLLM_WHEEL_URL=$(python3 -c "import urllib.request,re; \
     from urllib.parse import urljoin, quote; \
@@ -43,8 +42,7 @@ RUN uv pip install --system ".[dev]"
 
 RUN uv pip install --system --upgrade \
         "flashinfer-python==0.6.13" \
-        "flashinfer-cubin==0.6.13" \
-        "numpy==2.2.6"
+        "flashinfer-cubin==0.6.13"
 
 RUN uv pip install --system --upgrade \
     "flashinfer-jit-cache==0.6.13" \
@@ -57,6 +55,25 @@ RUN uv pip install --system --force-reinstall \
     "torch==2.11.0" "torchaudio==2.11.0" "torchvision==0.26.0" \
     --torch-backend cu130
 
+# CUDA 13 JIT linker: libnvJitLink.so.13 ships only in the nvidia-cuda-nvjitlink-cu13
+# pip wheel (the v0.24.0 base image's /usr/local/cuda toolkit is CUDA 12, so the
+# LD_LIBRARY_PATH above never resolves the .so.13). The cu130 torch/vllm wheels pull
+# this package into site-packages, but its lib dir is not on the dynamic-loader path,
+# so bitsandbytes / torch.compile worker subprocesses fail to dlopen it. Register the
+# actual lib dir with ldconfig (system-wide, survives subprocess env resets).
+RUN uv pip install --system "nvidia-cuda-nvjitlink-cu13" && \
+    NVJITLINK_LIB="$(find / -name 'libnvJitLink.so.13*' 2>/dev/null | head -1)" && \
+    test -n "$NVJITLINK_LIB" && \
+    dirname "$NVJITLINK_LIB" > /etc/ld.so.conf.d/nvjitlink-cu13.conf && \
+    ldconfig && \
+    echo "Registered ${NVJITLINK_LIB} with ldconfig"
+
+# Re-pin numpy LAST. numba requires numpy <= 2.4, but the flashinfer and torch cu130
+# reinstalls above resolve numpy back up to 2.5, which breaks `import numba` at test
+# time ("Numba needs NumPy 2.4 or less"). This must be the final dependency op so
+# nothing can clobber it again.
+RUN uv pip install --system "numpy==2.2.6"
+
 RUN ln -sf /usr/bin/python3 /usr/bin/python
 
 ENTRYPOINT []

vllm_omni/diffusion/models/gr00t/modeling/processing_gr00t_n1d7.py

@@ -19,6 +19,7 @@ from transformers.utils import cached_file
 from vllm.logger import init_logger
 
 from vllm_omni.diffusion.models.gr00t.configs.embodiment_configs import ModalityConfig
+from vllm_omni.diffusion.models.gr00t.configs.gr00t_n1d7 import Gr00tN1d7Config
 from vllm_omni.diffusion.models.gr00t.dataio.embodiment_tags import EmbodimentTag
 from vllm_omni.diffusion.models.gr00t.dataio.state_action.state_action_processor import StateActionProcessor
 from vllm_omni.diffusion.models.gr00t.dataio.utils import parse_modality_configs, to_json_serializable
@@ -552,4 +553,9 @@ class Gr00tN1d7Processor(ProcessorMixin):
         return cls(**processor_kwargs, transformers_loading_kwargs=transformers_loading_kwargs)
 
 
-AutoProcessor.register("Gr00tN1d7", Gr00tN1d7Processor)
+# transformers >= 5.5 requires the config *class* (not a model_type string) as the
+# first arg to AutoProcessor.register — it does `key.__module__` internally. Passing
+# the string "Gr00tN1d7" raises AttributeError: 'str' object has no attribute
+# '__module__'. Match the AutoModel.register(Gr00tN1d7Config, ...) call in
+# modeling/gr00t_n1d7.py.
+AutoProcessor.register(Gr00tN1d7Config, Gr00tN1d7Processor)