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

オープン
#718 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
38/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python
領域
build-system

調査の方向性

まず issue #706 のビルド時依存関係のアプローチを読み、現在の cute/cutedsl の pin が builder で cutlass をどのように解決するかを追跡します。sandbox にビルド時依存関係が必要かどうかを判断します。既存のカーネルを壊すことなく、互換性のあるより新しい cutlass/cutedsl が利用可能で、pinning 戦略がビルド構成に文書化されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
Python
スター
783
フォーク
143
平均マージ
1日 10時間
マージ済み PR(30日)
57

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

huggingface/kernels のほかの issue

huggingface/kernels の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。