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

Abierto
#718 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
build-system

Línea de trabajo

Empieza leyendo el enfoque de dependencias en tiempo de build del issue #706 y sigue cómo el pin actual de cute/cutedsl resuelve cutlass en el builder. Determina si se requieren dependencias en tiempo de build para el sandbox; se considera terminado cuando hay disponible un cutlass/cutedsl compatible más reciente sin romper los kernels existentes y la estrategia de pinning está documentada en la configuración de build.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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 #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 https://github.com/huggingface/kernels/issues/715

Lenguaje dominante
Python
Estrellas
783
Forks
143
Merge medio
1 d 17 h
PR fusionados (30 d)
61

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de huggingface/kernels

Todos los issues de huggingface/kernels

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.