apache-tvm-ffi>=0.1.11,<0.2
click
# cuda-python + nccl-extensions: runtime deps for the moe_ep EP transport
# backends (default since the EP install became opt-out; CUDA-13 wheels only
# — see build_backend.py). NCCL-EP is the released nccl-extensions wheel
# (`nccl.ep` API + bundled libnccl_ep.so); no in-tree NCCL build.
#
# nccl.ep MOVED: it used to ship inside nccl4py, but the EP/M2N libraries were
# split out to https://github.com/NVIDIA/nccl-extensions and nccl4py 0.4.1
# dropped `nccl/ep` entirely. Depending on nccl4py alone therefore resolves to
# a wheel with no nccl.ep at all. Both distributions install into the shared
# `nccl` namespace package: nccl4py owns nccl/core + nccl/bindings (we still
# need `nccl.core.Communicator`, and nccl-extensions pulls it in transitively),
# nccl-extensions owns nccl/ep + nccl/m2n + nccl/_extensions. The explicit
# nccl4py>=0.4.1 floor is a *conflict* guard, not a feature floor: nccl4py
# 0.3.1 still shipped its own nccl/ep into that same namespace directory, so
# co-installing it with nccl-extensions overwrites files and yields an
# ambiguous nccl.ep.
#
# The nccl-extensions cu12/cu13 extras are deliberately NOT used here: they
# pin nvidia-nccl-cuXX==2.30.7 exactly, which trips the torch-eviction problem
# described below. Plain `nccl-extensions` pulls no nvidia-nccl wheel.
#
# nvidia-nccl-cu13 is deliberately NOT a base dep: torch's cu13 wheels pin it
# EXACTLY (e.g. ==2.29.7), so any floor here (>=2.30.7 for B200 EP) makes the
# resolver evict torch — on aarch64 it backtracks all the way to the CPU-only
# torch 2.10.0 wheel. torch supplies libnccl; the >=2.30.7 B200 floor is
# enforced at runtime in flashinfer/moe_ep/core/validation/common.py, and the
# build hook installs the newer wheel --no-deps on source installs
# (build_backend.py).
#
# The same base-deps-must-not-force-a-CUDA-major rule applies to cuda-python:
# a >=13.0 floor bulldozes CUDA-12 environments (pip reports e.g.
# "nvshmem4py-cu12 requires cuda-python<=12.9" and then re-resolves torch to
# the cu13 default build, whose cuda-toolkit[cudart] dep drops libcudart.so.13
# next to the env's libcudart.so.12 — cudnn-frontend's cuda-pathfinder loader
# then aborts with "Multiple libcudart libraries found"). With a >=12.0 floor
# a cu12 env keeps cuda-python 12.x (moe_ep is CUDA-13-only and its runtime
# validator raises a clear error there), while cu13 envs resolve 13.x and get
# the full nccl.ep stack.
cuda-python>=12.0
cuda-tile>=1.4.0
einops
nccl-extensions>=0.1.0
nccl4py>=0.4.1
ninja
numpy
nvidia-cudnn-frontend>=1.29.0
nvidia-cutlass-dsl>=4.6.2a0
nvidia-ml-py
packaging>=24.2
requests
tabulate
torch
tqdm
