Skill de Mise à Jour de la Version de FlashInfer

Automatise la mise à jour de la version du package flashinfer-python dans TensorRT-LLM.

Quand l'utiliser

• L'utilisateur demande de mettre à jour / bumper / upgrader flashinfer
• Maintenance de routine des dépendances pour flashinfer-python

Prérequis

Étape 0a : Déterminer le Nom d'Utilisateur GitHub

Interroger gh pour obtenir le login de l'utilisateur authentifié :

GITHUB_USERNAME=$(gh api user --jq .login)
echo "$GITHUB_USERNAME"

Si cela échoue, gh n'est pas authentifié — résoudre l'étape 0c d'abord, puis réessayer. En secours, dériver le nom d'utilisateur à partir du remote de la fork :

GITHUB_USERNAME=$(git remote -v | grep -E 'github\.com/[^/]+/TensorRT-LLM' \
  | head -1 | sed -E 's|.*github\.com[:/]([^/]+)/TensorRT-LLM.*|\1|')

Si aucune des deux approches ne fonctionne, demander à l'utilisateur via AskUserQuestion.

Étape 0b : Vérifier le Remote de la Fork

Vérifier qu'un remote git pointant vers la fork TensorRT-LLM de l'utilisateur existe :

git remote -v | grep -E 'github\.com/${GITHUB_USERNAME}/TensorRT-LLM'

Si aucun remote de fork n'est trouvé, arrêter et notifier l'utilisateur :

Aucun remote de fork GitHub détecté. Une fork de NVIDIA/TensorRT-LLM est requise pour pousser les branches et créer des PRs.

1. Forker le repo à https://github.com/NVIDIA/TensorRT-LLM/fork
2. L'ajouter comme remote git :

   git remote add fork https://github.com/<GITHUB_USERNAME>/TensorRT-LLM.git

3. Relancer ce skill.

Étape 0c : Vérifier que gh CLI Est Authentifié

Ce skill utilise GitHub CLI (gh) pour pousser les branches et ouvrir des PRs. Confirmer qu'il est installé et authentifié :

gh auth status

Attendu : Logged in to github.com avec au moins la portée repo. repo couvre la poussée vers la fork de l'utilisateur et l'ouverture de PRs sur NVIDIA/TensorRT-LLM, donc aucun PAT à grain fin séparé n'est nécessaire.

Si gh signale « not logged in », instruire l'utilisateur :

gh auth login

Choisir : GitHub.com → HTTPS → s'authentifier via un navigateur web (ou coller un PAT avec portée repo).

Note sur GH_CONFIG_DIR : Si l'utilisateur maintient plusieurs comptes gh (par ex. un compte personnel et un compte séparé pour le travail NVIDIA/TensorRT-LLM), il peut pointer gh vers un répertoire de config non-défaut. Vérifier CLAUDE.local.md / AGENTS.md ou l'environnement pour GH_CONFIG_DIR ; si pas clair, demander à l'utilisateur. Lorsque défini, préfixer chaque invocation gh : GH_CONFIG_DIR=<path> gh ....

Ne pas procéder au workflow de mise à niveau jusqu'à ce que gh auth status soit clean et que le remote de la fork (étape 0b) soit confirmé.

Workflow

Exécuter ces étapes dans l'ordre. Utiliser AskUserQuestion pour les choix de l'utilisateur et WebFetch / GitHub API pour les données de release.

Étape 1 : Récupérer les Releases Disponibles depuis GitHub

Récupérer la liste des releases depuis https://github.com/flashinfer-ai/flashinfer/releases.

Utiliser WebFetch avec l'URL https://github.com/flashinfer-ai/flashinfer/releases et extraire tous les noms de tags et dates des releases. Collecter à la fois les releases stables (par ex., v0.6.7) et les tags pré-release / nightly (par ex., v0.7.0.dev20260401).

Alternativement, utiliser l'API GitHub via curl :

curl -s "https://api.github.com/repos/flashinfer-ai/flashinfer/releases?per_page=30" \
  | python3 -c "
import json, sys
releases = json.load(sys.stdin)
for r in releases:
    tag = r['tag_name']
    pre = ' (pre-release)' if r['prerelease'] else ' (stable)'
    date = r['published_at'][:10]
    print(f'{tag}  {date}{pre}')
"

Étape 2 : Vérifier la Version Actuelle

Lire la version épinglée actuelle depuis requirements.txt :

grep flashinfer-python requirements.txt

Format attendu : flashinfer-python==X.Y.Z

Étape 3 : Poser les Préférences à l'Utilisateur

Poser à l'utilisateur trois questions en utilisant AskUserQuestion :

1. « Préférer une dernière version nightly release ? »

   • Options : « Oui, montrer les releases nightly/dev » | « Non, releases stables uniquement (Recommandé) »
   • Cela filtre la liste des releases affichée dans la question suivante.

2. « Quelle version de flashinfer-python voulez-vous upgrader ? »

   • Présenter jusqu'à 4 versions plus récentes que la version actuelle (filtrées par la préférence nightly ci-dessus), avec la plus récente comme option recommandée.
   • Si la version actuelle est déjà la plus récente, informer l'utilisateur et arrêter.

3. « Mettre aussi à jour security_scanning/poetry.lock ? »

   • Options : « Non, ignorer le lockfile (Recommandé) » | « Oui, mettre à jour version + hashes »
   • Par défaut : Non. Le lockfile est généralement régénéré par les mainteneurs séparément ; l'éditer ici peut produire des diffs de hash superficiels et des valeurs metadata.content-hash obsolètes.
   • Si l'utilisateur répond Oui, suivre la sous-section « Mise à jour des hashes security_scanning/poetry.lock » ci-dessous ; sinon l'ignorer entièrement (ne pas toucher security_scanning/poetry.lock).

Étape 4 : Mettre à Jour Toutes les Références de Version

Après que l'utilisateur sélectionne une version cible, mettre à jour ces fichiers :

Mise à jour des hashes security_scanning/poetry.lock

Effectuer cette sous-section seulement si l'utilisateur a répondu Oui à la question 3 de l'étape 3. Sinon l'ignorer entièrement.

Le fichier poetry.lock contient des hashes SHA256 pour la wheel et la sdist. Les récupérer depuis PyPI :

curl -s "https://pypi.org/pypi/flashinfer-python/NEW_VERSION/json" \
  | python3 -c "
import json, sys
data = json.load(sys.stdin)
for f in data['urls']:
    print(f'{f[\"filename\"]}  sha256:{f[\"digests\"][\"sha256\"]}')
"

Remplacer l'ancien bloc files = [...] sous [[package]] name = "flashinfer-python" par les nouveaux noms de fichiers et hashes. Mettre aussi à jour la section [package.dependencies] si la nouvelle version a des dépendances différentes (vérifier requires_dist du JSON PyPI).

Important : Après édition manuelle de security_scanning/pyproject.toml et security_scanning/poetry.lock, le metadata.content-hash du lockfile devient obsolète. Le régénérer en exécutant :

cd security_scanning && poetry lock --no-update && cd ..

Cela rafraîchit le hash sans changer les autres versions de packages. Si poetry est disponible, vous pouvez alternativement utiliser poetry add flashinfer-python@NEW_VERSION dans le répertoire security_scanning/ pour mettre à jour à la fois pyproject.toml et poetry.lock automatiquement (y compris le content-hash).

Gestion spéciale des versions nightly / dev

Si l'utilisateur sélectionne une version nightly/dev (par ex., 0.7.0.dev20260401) :

• Le package PyPI peut ne pas exister — vérifier d'abord avec curl -s "https://pypi.org/pypi/flashinfer-python/VERSION/json".
• S'il n'est pas sur PyPI, les hashes security_scanning/poetry.lock ne peuvent pas être mis à jour. Avertir l'utilisateur et laisser un commentaire # TODO: update hashes when published to PyPI.
• Le requirements.txt peut épingler une installation git à la place : flashinfer-python @ git+https://github.com/flashinfer-ai/flashinfer.git@TAG#egg=flashinfer-python Demander à l'utilisateur quelle approche il préfère (épingle PyPI vs épingle git).

Étape 5 : Vérifier la Compatibilité de Version

Après la mise à jour, vérifier si un code a une logique gatée par version qui doit être ajustée :

grep -rn 'flashinfer.*__version__\|flashinfer.*version' \
  tensorrt_llm/ --include="*.py"

Emplacements connus avec des vérifications de version :

• tensorrt_llm/_torch/speculative/interface.py — flashinfer.__version__ >= "0.6.4"

Si la nouvelle version est toujours >= la version gatée, aucune modification requise. Sinon, signaler à l'utilisateur.

Étape 6 : Résumé

Afficher un résumé de tous les changements effectués :

• Ancienne version → Nouvelle version
• Fichiers modifiés (avec numéros de ligne)
• Avertissements quelconques (par ex., les hashes poetry.lock n'ont pas pu être mis à jour pour nightly)
• Rappeler à l'utilisateur de exécuter pip install -r requirements.txt pour tester localement
• Rappeler à l'utilisateur de exécuter les tests unitaires pertinents :

  pytest tests/unittest/_torch/flashinfer/ -v
  pytest tests/unittest/_torch/attention/test_flashinfer_attention.py -v

Étape 7 : Commit, Push et Créer une PR

Après la mise à jour et la vérification de tous les fichiers :

Si l'utilisateur a opté contre la mise à jour poetry.lock à la question 3 de l'étape 3, supprimer security_scanning/poetry.lock des commandes git stash, git add et du message de commit dans les snippets ci-dessous.

7a. Créer une nouvelle branche depuis upstream main

# Supprimer security_scanning/poetry.lock de cette liste si l'utilisateur a opté contre.
git stash push -m "flashinfer-upgrade-wip" -- requirements.txt security_scanning/pyproject.toml security_scanning/poetry.lock ATTRIBUTIONS-Python.md
git checkout main
git pull --rebase https://github.com/NVIDIA/TensorRT-LLM.git main
git checkout -b ${GITHUB_USERNAME}/update_flashinfer_${NEW_VERSION}
git stash pop

Où GITHUB_USERNAME provient du remote de la fork (par ex., yihwang-nv) et NEW_VERSION est la version sélectionnée (par ex., 0.6.7.post3).

7b. Commit avec signature DCO

# Supprimer security_scanning/poetry.lock de la liste `git add` et du corps du commit
# si l'utilisateur a opté contre.
git add requirements.txt security_scanning/pyproject.toml security_scanning/poetry.lock ATTRIBUTIONS-Python.md
git commit -s -m "[None][chore] Update flashinfer-python from OLD to NEW

Bump flashinfer-python dependency to the latest stable release.
Updated version pins in requirements.txt, security_scanning/pyproject.toml,
security_scanning/poetry.lock (if updated), and ATTRIBUTIONS-Python.md."

7c. Pousser la branche vers la fork de l'utilisateur

Identifier le remote de la fork (de l'étape 0b — généralement nommé fork), puis pousser :

FORK_REMOTE=fork   # ajuster si l'utilisateur a nommé son remote de fork différemment
BRANCH="${GITHUB_USERNAME}/update_flashinfer_${NEW_VERSION}"
git push -u "${FORK_REMOTE}" "${BRANCH}"

Si la poussée est rejetée pour des raisons d'auth, confirmer que gh auth status affiche la portée repo — gh installe un git credential helper qui réutilise son token pour les poussées HTTPS. Les utilisateurs sur un répertoire de config non-défaut doivent exporter GH_CONFIG_DIR dans le même shell.

7d. Ouvrir la PR sur NVIDIA/TensorRT-LLM

gh pr create \
  --repo NVIDIA/TensorRT-LLM \
  --base main \
  --head "${GITHUB_USERNAME}:${BRANCH}" \
  --title "[None][chore] Update flashinfer-python from ${OLD_VERSION} to ${NEW_VERSION}" \
  --body "$(cat <<EOF
## Summary
- Bump flashinfer-python from ${OLD_VERSION} to ${NEW_VERSION} (latest stable)
- Updated version pins in requirements.txt, security_scanning/pyproject.toml, and ATTRIBUTIONS-Python.md (and security_scanning/poetry.lock if the user opted in)

## Test plan
- [ ] pip install -r requirements.txt installs successfully
- [ ] pytest tests/unittest/_torch/flashinfer/ -v
- [ ] pytest tests/unittest/_torch/attention/test_flashinfer_attention.py -v
- [ ] CI pre-merge passes
EOF
)"

gh pr create affiche la nouvelle URL de la PR en cas de succès. La rapporter à l'utilisateur.

Référence des Fichiers

Tous les fichiers qui contiennent des épingles de version flashinfer-python :

Notes

• Le setup.py a un commentaire sur les URLs d'installation git+https — aucune épingle de version à mettre à jour là.
• Le .pre-commit-config.yaml et pyproject.toml référencent des fichiers source flashinfer, pas des versions — aucun changement requis.
• Le sous-module flashinfer/ (s'il existe) est séparé du package PyPI flashinfer-python.