[pylaterreur]

Overview

Upgrade numba from 0.65.0 to 0.68.1 (llvmlite 0.47.0 -> 0.50.0) for CUDA, CPU, ROCm and XPU. numba 0.65.x is one of the Python 3.15 blockers listed in #60467. On Python 3.13/3.14 it is also the requirement that holds NumPy below 2.5.

Claims

• Removes the numba blocker from [Tracking Feature]: Support vLLM with Python 3.15 #60467. numba 0.65.0 refuses to build on Python 3.15 (Cannot install on Python version 3.15.0; only versions >=3.10,<3.15 are supported), while 0.68.x ships cp315 wheels.
• A fresh install on Python 3.13/3.14 now resolves NumPy 2.5.4 instead of 2.4.6: numba 0.65.x requires numpy<2.5, 0.68.1 allows numpy<2.6. On 3.11/3.12, NumPy stays at 2.3.5 because mistral-common caps it below 2.4 there.
• vLLM's numba kernels (the N-gram proposer and the fused Kimi image preprocessing) behave the same: identical results, N-gram drafts and acceptance metrics, and compile and run times within noise.
• The test lock files change only in numba and llvmlite. The s390x image now builds LLVM 22.1.8 instead of 20.1.8, because llvmlite 0.48+ requires LLVM 22.
• The ppc64le build script keeps installing numba from IBM's DevPI index when it has matching numba and llvmlite wheels. Otherwise it builds LLVM 22.1.8, llvmlite and numba from source; today DevPI has no usable wheels, so it builds from source. The wheels for IBM's index are proposed in Add build scripts for llvmlite v0.50.0 for UBI 10.2 and UBI 9.6 ppc64le/build-scripts#8869 (llvmlite 0.50.0) and Add build scripts for numba 0.68.1 for UBI 10.2 and UBI 9.6 ppc64le/build-scripts#8870 (numba 0.68.1); after they are built and published, the script takes the fast path.

Validation

All runs were on a dedicated 8-core AMD EPYC (Milan) Ubuntu 24.04 VM unless noted. main means df028dff with numba 0.65.0; PR means the same commit plus this change. The branch was later rebased onto 8321d11, and the pip-compile hooks were re-run there: no further changes. (#64302 only changed the ROCm lock's header and its excluded-package list.)

Lock files. Re-running the pip-compile* hook commands (uv 0.11.1, as in .pre-commit-config.yaml) on main gives no diff. On this branch they change only numba and llvmlite in requirements/test/{cuda,cpu,rocm,xpu}.txt. pre-commit run --files <the 14 changed files> passes.

Fresh resolution (no lock preference). Command: uv pip compile requirements/<platform>.txt --python-version X --index-strategy unsafe-best-match, with each platform's --torch-backend and --python-platform: CUDA cu130 and CPU on x86_64 manylinux_2_28, CPU on aarch64 manylinux_2_28 and on macOS 14 arm64, ROCm manylinux_2_35, XPU manylinux_2_39.

Python	numba main → PR	NumPy main → PR	Platforms resolving
3.11	0.65.0 → 0.68.1	2.3.5 → 2.3.5	6/6, both
3.12	0.65.0 → 0.68.1	2.3.5 → 2.3.5	6/6, both
3.13	0.65.0 → 0.68.1	2.4.6 → 2.5.4	6/6, both
3.14	0.65.0 → 0.68.1	2.4.6 → 2.5.4	5/6, both. ROCm also fails on main: mooncake-transfer-engine-rocm has no cp314 wheel (#63965)

vLLM tests on CPU. These used the nightly CPU wheel 0.33.0rc1.dev157+gedad8b03c, whose numba code and tests are identical to df028dff. The 3.12 environments follow docker/Dockerfile.cpu: requirements/cpu.txt, then requirements/test/cpu.txt. The 3.14 environments are fresh resolutions of requirements/cpu.txt.

VLLM_CPU_CI_ENV=1 VLLM_CPU_SIM_MULTI_NUMA=1 VLLM_CPU_ATTN_SPLIT_KV=0 VLLM_CPU_KVCACHE_SPACE=4 \
  python -m pytest -v tests/v1/spec_decode/test_ngram.py tests/renderers/test_warmup.py \
  tests/models/multimodal/processing/test_kimi_k3.py
# the numba N-gram proposer runs on the V1 runner
VLLM_USE_V2_MODEL_RUNNER=0 VLLM_CPU_KVCACHE_SPACE=4 python -m pytest -v -s \
  "tests/v1/e2e/test_cpu_spec_decode.py::test_ngram_spec_decode_matches_baseline"

Env	numba / llvmlite / NumPy	Unit tests	E2E N-gram (Qwen3-0.6B)
3.12, CI locks, main	0.65.0 / 0.47.0 / 2.2.6	32 passed	passed; 74/90 drafts accepted, mean acceptance length 3.47
3.12, CI locks, PR	0.68.1 / 0.50.0 / 2.2.6	32 passed	passed; 74/90 drafts accepted, mean acceptance length 3.47
3.14, fresh, main	0.65.0 / 0.47.0 / 2.4.6	32 passed	not run
3.14, fresh, PR	0.68.1 / 0.50.0 / 2.5.4	32 passed	not run

test_kimi_k3.py::test_fused_image_processor_matches_hf compares the numba _write_fused_patches kernel (parallel=True, cache=True) with the HF processor. librosa 0.10.2.post1, the only other numba user in the test locks, gives identical outputs on both versions.

Kernel differential checks. The vLLM kernels are copied verbatim from the source into a standalone module, so they can run without vLLM. The checks compare batch_propose_numba and _find_longest_matched_ngram_and_propose_tokens with their .py_func on random inputs: 1500 single cases, and 40 batches at 1/2/4/8 threads. They compare _write_fused_patches with a NumPy reference on 200 cases, including non-contiguous frames and a uint8 LUT.

Python	0.65.0	0.68.1
3.11.16, 3.12.14, 3.13.15, 3.14.7 (x86_64)	0 mismatches with the omp, workqueue and default layers	0 mismatches with the omp, workqueue and default layers
3.12, 3.14 (aarch64, Neoverse-N1)	0 mismatches	0 mismatches
3.15.0rc2 (x86_64)	does not install	0 mismatches

• JIT cache (cache=True): each version reuses its own cache. A cache written by 0.65.0 is ignored and rebuilt by 0.68.1, and vice versa, with correct output both ways.
• Threading layer: the default is omp on both versions; under numba_workqueue_threading_layer() it is workqueue on both.
• Warnings: both versions emit the same NumbaPendingDeprecationWarning (reflected list) and nothing else.

Timing. Medians of 7 interleaved runs per version, each a fresh process with an empty cache.

	0.65.0	0.68.1
First-call compile: _find_longest... / batch_propose_numba / _write_fused_patches	0.398 / 0.550 / 0.399 s	0.414 / 0.539 / 0.394 s
batch_propose_numba, 128 req × 4096 tokens, 1 thread	0.668 ms	0.670 ms
batch_propose_numba, 16 req × 32768 tokens, 1 thread	0.598 ms	0.602 ms
_write_fused_patches, 1022×1022 image, 1 thread (9 runs × 60 reps)	61.4 ms	59.4 ms
_write_fused_patches, 1022×1022 image, 8 threads, workqueue (9 runs × 60 reps)	12.5 ms (min 11.7)	12.7 ms (min 11.7)

s390x image. I built docker build --target numba-builder -f docker/Dockerfile.s390x . from this branch on x86_64 with one local change: LLVM_TARGETS_TO_BUILD="SystemZ;X86", so that the result can run on that host. LLVM 22.1.8 builds; the stage produces llvmlite-0.50.0 and numba-0.68.1 wheels (llvm_version_info == (22, 1, 8)). Inside the image, the kernel checks show 0 mismatches, and numba.runtests on test_dispatcher, test_caching, test_threadsafety, test_lists and test_parfors_caching reports 222 tests OK (7 skipped).

ppc64le build script. No Power hardware was used. The new Numba section of docker/build_vllm_ppc64le.sh was run on x86_64 inside ubi9/ubi-minimal:9.8, the base of Dockerfile.ppc64le. It ran after the script's own prelude, system packages, venv, build tools, compiler environment and DevPI helpers.

Changes for the x86_64 runs only:

• The CentOS Stream ppc64le protobuf RPMs and the packages missing from UBI x86_64 (protobuf numactl-devel openmpi openmpi-devel) are skipped.
• The sections unrelated to numba (Rust, OpenCV, torch*, xgrammar, final install) are skipped.
• IBM_DEVPI_URL points at a local index.
• LLVM is built for PowerPC;X86 so the result runs on the host.

Stand-in for DevPI	Branch taken	Result
local index with numba 0.68.1 + llvmlite 0.50.0 (cp312 wheels)	DevPI	Both wheels installed, no build; the venv gains only these two packages
local index with numba 0.68.1 only	source build	Branch chosen (that run stops at the LLVM download on purpose)
empty index	source build	LLVM 22.1.8, llvmlite 0.50.0 and numba 0.68.1 built and installed (21 min for the whole 8-core run, including package installs and tests). python -m llvmlite.tests: 393 OK, 23 skipped. numba test_dispatcher, test_caching, test_threadsafety, test_lists, test_parfors_caching: 222 OK, 7 skipped. Kernel checks: 0 mismatches. libllvmlite.so has no shared LLVM dependency. The venv gains only llvmlite and numba, and PATH, LLVM_CONFIG and CMAKE_PREFIX_PATH are unchanged after the section

Toolchain the script provides at that point: GCC 14.2.1 (gcc-toolset-14), CMake 4.4.4 (pip, in the venv), Ninja 1.10.2, Python 3.12.15, NumPy 2.3.5. LLVM 22 needs GCC ≥ 7.4 and CMake ≥ 3.20. xz is not present after the script's package installs, so the source path installs tar xz first.

Not covered.

• No GPU runs. numba is only used on the host, but CUDA, ROCm and XPU were checked by resolution only.
• No real s390x or ppc64le hardware. Both source builds were run on x86_64 with an added X86 LLVM target.
• No model evals. The change does not affect outputs: the N-gram drafts and acceptance counts are identical.
• CI coverage: requirements-only changes do not trigger the CPU-Spec Decode Tests job (tests/v1/spec_decode/test_ngram.py) or the Kimi processor tests, so the runs above stand in for them.

Details

Changes between 0.65.0 and 0.68.1 that matter to vLLM. vLLM uses:

• @njit(parallel=True) with prange and a reflected list argument (N-gram proposer);
• @njit(parallel=True, cache=True) (fused Kimi preprocessing);
• numba.config.THREADING_LAYER and the workqueue layer (vllm/utils/jit_monitor.py);
• get_num_threads and set_num_threads.

The 0.66.0, 0.67.0, 0.68.0 and 0.68.1 release notes deprecate or remove none of these APIs. Reflected lists still only warn. The relevant upstream changes:

• llvmlite 0.48+ is built on LLVM 22 (numba 0.66.0). Only source builds are affected: docker/Dockerfile.s390x and the s390x install docs. UBI 9 still ships LLVM 21 (llvm-21.1.8-2.el9), so LLVM 22 is still built from source.
• NumPy 2.5 support came in 0.67.0, Python 3.15 wheels in 0.68.0.
• The cache index now stamps sources by content hash instead of mtime (0.68.0). Old caches are rebuilt, as shown above.
• Linux x86_64 wheels are now manylinux_2_28. torch==2.14.0 already requires manylinux_2_28, so the glibc floor does not move.
• NUMBA_ENABLE_SYS_MONITORING=1 (opt-in) is broken on Python ≥ 3.14.4 in 0.65.0 and works in 0.68.1. On 3.14.7, cProfile saw 0 of 100 jitted calls with 0.65.0 and 100 of 100 with 0.68.1.

Platforms.

• TPU: requirements/tpu.txt does not list numba (tpu-inference==0.32.0 pins numba==0.62.1), so it is unchanged.
• s390x: Dockerfile.s390x builds LLVM, llvmlite and numba from source; their versions move together in this PR.
• ppc64le: docker/build_vllm_ppc64le.sh keeps installing numba from IBM's DevPI index when it has both numba==0.68.1 and llvmlite==0.50.0 wheels for the interpreter in use (checked with the script's is_available_on_devpi). Otherwise it builds LLVM 22.1.8, llvmlite 0.50.0 and numba 0.68.1 from source and installs the two wheels. LLVM uses the PowerPC target and the same CMake flags as Dockerfile.s390x. The build runs in a subshell, so the script's LLVM 15 PATH/LLVM_CONFIG stay as they are for everything else, and the LLVM tree is deleted afterwards (llvmlite links LLVM statically). Today DevPI has no usable wheels for UBI 9 (glibc 2.34): it lists numba up to 0.65.1 and llvmlite up to 0.49.0, and its numba 0.67.0 wheels are manylinux_2_39. So the Power build currently takes the source path, which adds an LLVM build to the image build time. That path was validated on x86_64 only; see Validation.

Not a duplicate. No open or closed PR or issue targets numba 0.66, 0.67 or 0.68. Earlier numba bumps landed in #15692, #16376 and #34770 (0.65.0). #34764 was closed as included in #34770. Dependabot group PRs that included numba 0.67.0 (e.g. #58081) were closed unmerged. #36981 (riscv64 markers) edits the same requirements/cpu.txt line, so whichever PR lands second needs a trivial rebase.

Search commands and results (2026-10-28)

$ gh pr list --repo vllm-project/vllm --state open --search "numba"
#38326 [Bugfix] Fix N-gram proposer JIT warmup that never triggers compilation
#60924 [Experimental][CPU][MRV2] Run Model Runner V2 on CPU without Triton (custom sampler class + triton to numba transpilation)
#61995 [CPU][MRv2] Enable MRv2 for non-triton CPU backends
#36981 feat(riscv64): platform-gate dependencies without riscv64 wheels
#59123 [Misc] Use multithreading to accelerate server memcpy.
#61457 [Quantization] Enable per-layer fused shared expert selection
#38397 feat: Added Dockerfile for ppc64le CUDA build
#51349 [MM][1/n] Paged shared memory storage for mm tensor ipc.
#62512 [Perf] Overlap FlashInfer sampler JIT with model initialization
#57752 [Don't merge][Experiment] Move MediaIO decode to MM preprocessing
(none of them changes the numba version; #36981 adds a riscv64 marker to the 0.65.0 pin)

$ gh pr list --repo vllm-project/vllm --state all --search "numba in:title"
#60924 [OPEN] [Experimental][CPU][MRV2] Run Model Runner V2 on CPU without Triton (...)
#62493 [CLOSED] [Bugfix][Spec Decode] Preserve Torch threads during Numba initialization
#59296 [CLOSED] [Bugfix] Fall back to uncached numba JIT when no cache dir is writable
#23139 [CLOSED] [TPU] Add numba dependency to tpu requirements.
#33171 [CLOSED] [Bugfix] Upgrade Numba to fix segfault on CUDA drivers version 580
#34764 [CLOSED] [Build] Update numba version to 0.63.1.
#29328 [MERGED] [Model Runner V2] Change Numba AoT to JIT
#23124 [CLOSED] [Optimization] Use Numba to optimize input preparation [1/N]
#19433 [CLOSED] Fixed power build by building numba from source
#16881 [CLOSED] [Perf] Optimize MRoPR position preparing performance with numba
#16376 [MERGED] Update Numba to 0.61.2
#15692 [MERGED] Use numba 0.61 for python 3.10+ to support numpy>=2
#14199 [MERGED] Moved numba from common requirements to cuda/rocm specific requirements
#13365 [MERGED] [V1][Spec Decode] Optimize N-gram matching with Numba
#3962 [MERGED] [Bugfix][ROCm] Add numba to Dockerfile.rocm

$ gh issue list --repo vllm-project/vllm --state all --search "numba in:title"
#62482 [CLOSED] [Bug]: First ngram proposal can overwrite Torch thread limit during Numba OpenMP initialization
#59250 [CLOSED] [Bug]: Kimi-K3 warmup imports Kimi code for every model; startup crashes as non-root / read-only (numba "no locator available")
#29310 [CLOSED] [Bug][GPU Model Runner v2] Segfault in forked process with @numba.jit() eager compilation
#6497 [CLOSED] (numba install failure from outlines)

$ gh search prs/issues --repo vllm-project/vllm "numba 0.66" | "numba 0.67" | "numba 0.68" | "llvmlite 0.50" | "bump numba"
(no results)

$ gh search prs --repo vllm-project/vllm "upgrade numba" / "update numba"
#33171 [closed], #34764 [closed], #34770 [merged], #16376 [merged], #22443 [merged], #38326 [open], ... (none for 0.66+)

I also checked every open PR created since 2026-07-28 that touches requirements/ or the s390x/ppc64le build files (17 PRs). None changes the numba or llvmlite versions. #64241 rewrites the same lock lines with hashes, and #63373 (draft) deletes the V1 N-gram proposer.

MRV1 note. The numba N-gram proposer is used by the V1 runner. MRV2 uses the Triton NgramGPUSpeculator, so the numba proposer is still used on CPUs without triton-cpu and when the V1 runner is selected. #63373 (draft) deletes it, but numba stays a dependency for the fused Kimi preprocessing, so this upgrade is independent of that PR.

AI assistance. AI assistance (Claude Code) was used to research the numba/llvmlite changes, edit the requirements and the s390x build, and run the validation above.

---

Pull Request Checklist

• I used vLLM's /pr-checklist skill. (Mandatory for agents, optional for humans).

• AI assistance was used during the creation of this PR.

• Design Fit: Minimizes impact on core components, reuses existing functionality, and justifies added complexity.

• Testing and Validation: Validates the change and ensures any added tests are meaningful and reliable, with CI coverage or documented CI resource constraints and validation performed outside CI.

• Code Quality and Style: Keeps code and comments clear and concise, and updates relevant documentation and examples.

• Pull Request Contents: Includes a brief summary and relevant links, supports claims with evidence, explains root causes and implementation trade-offs, and follows the contributing guide.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

PRs do not trigger a full CI run by default. Reviewers with write access and configured trusted contributors can comment /ci run for upstream CI or /amd-ci run for AMD CI only whenever CI signals are needed.

Once the PR is approved or has the ready label, the PR author can also use the corresponding /ci run, /ci retry, and /ci cancel commands, or their /amd-ci variants. New commits do not start upstream CI automatically.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

Agent Guidelines

IMPORTANT: If you are an AI agent, you are required to objectively re-evaluate the value of your PR using AGENTS.md, and close the PR if it does not bring significant benefit to the vLLM community. Failure to do so may result in an immediate ban.

🚀

[mergify]

Documentation preview: https://vllm--64366.org.readthedocs.build/en/64366/

[pylaterreur]

Hi, first PR in this repo, bumping deps. Let me know if you need more :)