Versioning / build issues vendoring quack (cutlass/cutedsl pin) for sonic-moe

[sayakpaul]

Context: sonic-moe now hard-requires quack (previously optional alongside its own GEMM backends), so we must vendor it — but that surfaces versioning/build problems.

Problem:

• Current blocker is on the kernel-builder side: latest quack needs a newer cutlass than what's available.
• quack → cutedsl → cutlass; the version is pinned in cute, and nixpkgs keeps resolving an older one (~4.5.0).
• Naive bump is risky since cute/cutedsl frequently change internal APIs.
• Open question: does the build sandbox need cutedsl/cutlass at build time? (cf. how Helion is handled in Add Helion as a supported Python dependency #706)

Ask: make a newer cutlass/cutedsl available to the builder without breaking existing kernels, decide a pin/bump strategy, and wire up build-time deps if needed (analogous to the python-depends mechanism from #706).

Cc: @IlyasMoutawwakil

Related to #715

[danieldk]

Open question: does the build sandbox need cutedsl/cutlass at build time?

Yes, otherwise we cannot run the get_kernel check/hook and we don't know if kernels are actually loadable.

quack → cutedsl → cutlass; the version is pinned in cute, and nixpkgs keeps resolving an older one (~4.5.0).

This is a bit confusing, cutlass is mostly a C++ header library and it is only relevant at build time. Do you mean nvidia-cutlass-dsl?

I think my comment here is relevant: #715 (comment) . I think we should work on making these dependencies kernel(-like) and work on support for kernel dependencies (rather than digging an increasingly deep Python dependencies hole).