Repository navigation
Versioning / build issues vendoring quack (cutlass/cutedsl pin) for sonic-moe #718
Description
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).
Related to #715
Activity
danieldk commentedon Jul 17, 2026
Yes, otherwise we cannot run the
get_kernelcheck/hook and we don't know if kernels are actually loadable.This is a bit confusing,
cutlassis mostly a C++ header library and it is only relevant at build time. Do you meannvidia-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).