ITADN

[Bug] flashinfer-cubin wheels missing on PyPI for >=0.6.14 — version check breaks every vLLM >= 0.27 on DGX Spark (GB10/aarch64)

#4781Openskbotoc1-web 创建于 1 天前
needs-triage
S
skbotoc1-webcommented
### Summary `flashinfer-cubin` on PyPI stops at **0.6.13**, while `flashinfer-python` has shipped **0.6.16.post3 / 0.6.17** — and none of the newer `flashinfer-python` wheels declare any dependency on `flashinfer-cubin`. The runtime version check then hard-fails on ARM64 (DGX Spark / GB10, sm_121a), because a matching cubin wheel is never published. This breaks every vLLM >= 0.27 install on GB10. ### Environment - Hardware: NVIDIA DGX Spark, GB10, compute capability **12.1a** (`sm_121a`), aarch64 - OS: Ubuntu 24.04 (ARM64) - Python: 3.11 (aarch64) - Packages: - `flashinfer-python==0.6.16.post3` (pinned by `vllm==0.27.x` / `0.28.0`) - `flashinfer-cubin` — only **0.6.13** is available on PyPI - vLLM: 0.25.1 works (flashinfer-python 0.6.13 + flashinfer-cubin 0.6.13, consistent); 0.27.1 / 0.28.0 crash-loop ### Problem 1. PyPI release inventory (verified 2026-08-27): - `pip index versions flashinfer-cubin` → newest is **0.6.13** - `pip index versions flashinfer-python` → ships up to **0.6.17** (incl. 0.6.16.post3, 0.6.16.post4) 2. The `flashinfer-python` wheel for 0.6.16.post3 (and 0.6.17) is a `py3-none-any` pure-python wrapper whose METADATA declares **no** `Requires-Dist` on `flashinfer-cubin`: ``` Requires-Dist: apache-tvm-ffi!=0.1.8,!=0.1.8.post0,<0.2,>=0.1.6 Requires-Dist: click Requires-Dist: cuda-python>=12.0 ... (no flashinfer-cubin dependency) ``` 3. At runtime, the version check refuses to start when the two packages are out of sync (even when `flashinfer-cubin 0.6.13` is installed manually): ``` RuntimeError: flashinfer-cubin version (0.6.13) does not match flashinfer version (0.6.16.post3). Please install the same version of both packages. Set FLASHINFER_DISABLE_VERSION_CHECK=1 to bypass this check. ``` Since no `flashinfer-cubin >= 0.6.14` wheel exists on PyPI, **there is no combination that can pass this check** on an ARM64 pip install. Consequence: `vllm serve` on DGX Spark enters a crash loop immediately after upgrading vLLM to >= 0.27 (EngineCore re-init every ~60s). Verified live on 2026-08-27: vllm 0.25.1 + flashinfer 0.6.13 = stable ~28 tok/s; vllm 0.28.0 = crash loop. ### Expected behavior Either of the following would fix it: - Publish matching `flashinfer-cubin` wheels for 0.6.14 … 0.6.17 on PyPI, **or** - Declare the correct dependency (`flashinfer-cubin==<same version>`) in `flashinfer-python` wheels so pip installs a consistent pair (this also documents the requirement), **or** - Document the intended install path for ARM64/GB10 (e.g. "source-JIT only, cubin wheels are not published for aarch64"). ### Impact - Every `vllm>=0.27` pip installation on DGX Spark / GB10 is broken out of the box. The only working route to newer vLLM on GB10 is NVIDIA/community Docker images that build FlashInfer from source — pip users cannot upgrade. - Affects aarch64 pip users generally, not just DGX Spark. ### Related - https://github.com/flashinfer-ai/flashinfer/issues/3170 (DGX Spark SM121 support audit — broad coverage, this packaging gap is not listed)
0 条评论