CollectiveX: NCCL EP v0.2 via nccl-extensions — lift the LL clamp, enable LL rows and B200 EP16

[Oseltamivir]

Stacked on #2786 (cx-measure-fixes) — review only the top commit here; merge after 2786.

Implements the vendor's v0.2 upgrade request.

Packaging. nccl-ep v0.2 ships as the nccl-extensions PyPI wheel, which owns nccl.ep (libnccl_ep.so JIT runtime + bindings); nccl4py stopped bundling nccl/ep at 0.4 and provides only nccl.core. The install spec becomes two pinned wheels — nccl-extensions[cu13]==0.1.0 nccl4py[cu13]==0.5.0 — rather than the vendor's unpinned nccl-extensions[cu13]: the spec string keys the shared cache dir, and nccl-extensions leaves its nccl4py dependency unpinned, so an unpinned spec would let a cache rebuild silently resolve a different tree. The spec change itself re-keys the cache and forces a clean reinstall. The import probe now logs nccl.ep.get_lib_version() / get_lib_path() so a stale or image-shadowing libnccl_ep.so is visible in every run log.

LL clamp lifted, rows enabled. v0.1's LL combine recv pipeline was a port of DeepEP's pre-#642 kernel, missing the shared-memory fence before mbarrier_arrive (bimodal 1-in-5 T=256 corruption on gb300 EP8). The v0.2 wheel physically ships the fence — fence_view_async_shared() before the emptyBarriers arrive in the published wheel's ll_ep.cuh — which was the documented restore condition, so _LL_LADDER_CAP returns to _LL_BUFFER_CAP (256) and ll_backends gains nccl-ep: EP8 on h100/h200/b300, EP8+EP16 on b200/gb200/gb300.

B200 EP16 normal mode enabled — the vendor claims v0.2 fixes the RDMA EP16 GIN fault. h100/h200/b300 EP16 stays unsupported: only the B200 configuration is claimed fixed.

Store hygiene. kernel_generation bumps to nccl-ep-v02-ht-routed / nccl-ep-v02-ll so pre-upgrade rows never pool with the new mover.

No adapter code changes needed: every class and signature the adapter uses (GroupConfig, Group.create/create_handle, dispatch/combine/complete/update, DispatchConfig/CombineConfig/LayoutInfo/Tensor) is unchanged v0.1→v0.2, verified against the published wheel. Still BF16-only — v0.2's FP8 dispatch (DS_FP8E3M4) and experimental NVFP4 combine are separate bring-up.

What only metal can settle (validation sweep to follow on this branch): LL correctness unclamped at T=256, LL EP16, B200 EP16 HT, and HT complete() semantics — v0.2's docstring now describes complete() as LL-staged-only, while under v0.1 the HT combine required it to finish the cross-rank gather; the adapter still calls it unconditionally and the combine oracle will catch any semantic change. Registry enables are claims until that sweep is green.

Local suite: 99 tests pass (7 torch-gated skips).

---

Note

Medium Risk
Changes benchmark dependency pins, sweep coverage, and result discriminators for NCCL EP; metal validation is still pending for unclamped LL and B200 EP16 claims.

Overview
Upgrades CollectiveX NCCL EP to the vendor v0.2 stack shipped as pinned nccl-extensions[cu13] plus nccl4py[cu13], replacing the old single nccl4py install path. Runtime install/probe now logs libnccl_ep version/path so shadowed wheels are visible in logs.

Because v0.2 ships the low-latency combine recv fence that v0.1 lacked, the adapter restores the full decode ladder (_LL_LADDER_CAP = 256) and bumps kernel_generation to nccl-ep-v02-* so results do not mix with pre-upgrade rows.

platform_config.json turns on nccl-ep low-latency cells (EP8 on H100/H200/B300; EP8+EP16 on B200/GB200/GB300) and adds B200 normal-mode EP16 for nccl-ep. README and methodology prose are updated to match; adapter API usage is unchanged and stays BF16-only.

^{Reviewed by Cursor Bugbot for commit a6bbffd. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

I reviewed this PR and didn't find any bugs. Because it lifts a documented correctness clamp (the LL ladder cap) based on unverified vendor claims and enables new low-latency/EP16 rows across several production SKU configs, a human look — including the promised on-metal validation sweep — would still be worthwhile.

What was reviewed: the pip-spec/cache-slug rework in runtime/common.sh and runtime/prepare_backend.sh, including the deliberately unquoted two-spec install line; the ladder-clamp removal and kernel_generation rename in bench/ep_nccl.py alongside the corresponding test rework in tests/test_backends.py; and the platform_config.json changes, which are limited to adding nccl-ep to ll_backends where it was already present in backends. Also checked the new unguarded nccl.ep.get_lib_version()/get_lib_path() probe call in prepare_backend.sh — an exception there would only affect the diagnostic log line, not correctness.

Extended reasoning...

This PR upgrades CollectiveX's NCCL EP adapter from a from-source v0.1 pin to a v0.2 PyPI wheel (nccl-extensions), touching the install/cache pipeline in runtime/common.sh and runtime/prepare_backend.sh, the adapter logic and correctness-clamp constants in bench/ep_nccl.py, the SKU-level enablement table in configs/platform_config.json, and narrative docs. The single commit is well-documented with detailed inline commentary explaining the rationale for each change.

No security-relevant risks stand out: there is no auth, crypto, or permission-boundary code here. The unquoted $COLLX_NCCL_EP_SPEC in the pip install command is intentional word-splitting of two version-pinned pip specs (with a shellcheck disable and a comment explaining why), not attacker-controlled input, so it is not an injection concern.

The correct level of scrutiny here is higher than a typical config tweak: the core change removes a documented safety clamp (_LL_LADDER_CAP returning to _LL_BUFFER_CAP) that was put in place specifically because of an observed 1-in-5 bimodal data-corruption bug in the low-latency combine path. The removal is justified entirely by the vendor's changelog claim that v0.2 ships a missing memory fence, which the PR author explicitly says is unverified pending on-metal validation ("What only metal can settle" section lists LL correctness at T=256, LL EP16, and B200 EP16 as still-open validation items). Enabling this clamp-lifted path across many production SKU configs in platform_config.json before that validation is a design/risk decision that benefits from a second set of human eyes, even though the mechanical code changes (renames, spec swap, test updates) are individually simple and well-reasoned.

Other factors: there is no CODEOWNERS entry for experimental/CollectiveX/, this is the first review pass on this PR (no prior review body or unaddressed third-party objections in the timeline), and local tests reportedly pass (99 tests, 7 skips). The one candidate issue considered (unguarded diagnostic probe call) only affects log output, not runtime correctness, so it does not change the overall assessment.