vLLM nightly now requires PyTorch 2.11.0 which is built against
CUDA 13.0. Update the CI base image to match.

Signed-off-by: Samuel Shen <slshen@uchciago.edu>
Co-authored-by: Samuel Shen <slshen@uchciago.edu>

The base image was bumped to nvidia/cuda:13.0.2-devel-ubuntu24.04 in
LMCache#2981, but setup-env.sh installs vLLM from the generic nightly index
(wheels.vllm.ai/nightly/vllm/), which resolves non-deterministically to
either a cu128 or a cu130 torch wheel. When the resolver picks cu128,
torch.utils.cpp_extension._check_cuda_version aborts the LMCache
editable install with:

    RuntimeError: The detected CUDA version (13.0) mismatches the
    version that was used to compile PyTorch (12.8).

LMCache#3055 tried to paper over this at runtime by apt-installing
cuda-compiler-12-8 on mismatch and pointing CUDA_HOME at
/usr/local/cuda-12.8, but cuda-compiler-*-* only ships nvcc -- not the
CUDA math-library dev headers (cusparse.h, cublas.h, etc.). The build
then fails deeper with a cryptic:

    fatal error: cusparse.h: No such file or directory

Every k3 build on dev since 10fd636 (2026-04-16 09:55 UTC) has failed
this way because vLLM nightly happens to be publishing cu128 torch
today. Extending the apt install list is a band-aid; the real fix is
to stop resolving torch non-deterministically.

Pin the install to vLLM's per-CUDA-major cu130 sub-index per the
official vllm.ai install instructions. torch.version.cuda is now
deterministically "13.0" and matches system nvcc 13, so
_check_cuda_version passes with the system toolchain -- no CUDA_HOME
override, no apt install, no HTML scraping.

Also drop the HTML index scraper (no longer needed with the proper
--extra-index-url flags) and replace the runtime alignment block with
a small Python sanity check that fails with a clear message if the
pin ever drifts again, so future breakage surfaces here instead of
inside ninja.

- Unblocks every k3 pipeline on dev.
- Removes ~40 lines of CUDA version-alignment logic.
- Keeps the pandas auto-heal loop from LMCache#3055 (that problem is
  independent of this one).

Signed-off-by: Yihua Cheng <yihua98@uchicago.edu>

…age (#3061)

The base image was bumped to nvidia/cuda:13.0.2-devel-ubuntu24.04 in
#2981, but setup-env.sh installs vLLM from the generic nightly index
(wheels.vllm.ai/nightly/vllm/), which resolves non-deterministically to
either a cu128 or a cu130 torch wheel. When the resolver picks cu128,
torch.utils.cpp_extension._check_cuda_version aborts the LMCache
editable install with:

    RuntimeError: The detected CUDA version (13.0) mismatches the
    version that was used to compile PyTorch (12.8).

#3055 tried to paper over this at runtime by apt-installing
cuda-compiler-12-8 on mismatch and pointing CUDA_HOME at
/usr/local/cuda-12.8, but cuda-compiler-*-* only ships nvcc -- not the
CUDA math-library dev headers (cusparse.h, cublas.h, etc.). The build
then fails deeper with a cryptic:

    fatal error: cusparse.h: No such file or directory

Every k3 build on dev since 10fd636 (2026-04-16 09:55 UTC) has failed
this way because vLLM nightly happens to be publishing cu128 torch
today. Extending the apt install list is a band-aid; the real fix is
to stop resolving torch non-deterministically.

Pin the install to vLLM's per-CUDA-major cu130 sub-index per the
official vllm.ai install instructions. torch.version.cuda is now
deterministically "13.0" and matches system nvcc 13, so
_check_cuda_version passes with the system toolchain -- no CUDA_HOME
override, no apt install, no HTML scraping.

Also drop the HTML index scraper (no longer needed with the proper
--extra-index-url flags) and replace the runtime alignment block with
a small Python sanity check that fails with a clear message if the
pin ever drifts again, so future breakage surfaces here instead of
inside ninja.

- Unblocks every k3 pipeline on dev.
- Removes ~40 lines of CUDA version-alignment logic.
- Keeps the pandas auto-heal loop from #3055 (that problem is
  independent of this one).

Signed-off-by: Yihua Cheng <yihua98@uchicago.edu>