fix(launcher): use pinned CPU-only Torch on Linux - #487

Symptôme

W2-5 / H3 : le launcher force PyPI pour les dépendances ML alors que le lock du dépôt impose Torch CPU sur Linux. Cette divergence peut résoudre des dépendances CUDA inutiles. PR empilée sur #486.

Cause racine

Pip ne fournit pas la sélection d'index par paquet du explicit=true de uv. Ajouter un extra-index permettrait à d'autres dépendances de chercher sur les deux sources. Les anciens stamps ML n'incluent pas Torch et peuvent considérer une ancienne installation comme complète.

Changement

Le jeu ML Linux inclut torch==2.13.0+cpu du lock. Seul ce wheel est téléchargé sur l'index CPU officiel, avec --no-deps --only-binary=:all: --require-hashes et les 22 hashes Linux de l'export. Le wheel local participe ensuite à la résolution PyPI des autres paquets, avec contraintes de base et CPU. Échec de téléchargement/hash : arrêt explicite, aucun retour à Torch PyPI.

Le stamp Linux change ; une réparation échouée ne reçoit pas de succès, même si les anciens modules restent importables. Le rollback par entrée et le scratch de récupération sont conservés. Configuration pip externe désactivée et overrides de sources/fichiers de contraintes retirés. Les pins/source macOS et Windows restent inchangés ; aucun dossier nvidia-* installé n'est supprimé.

Sources : requirements/setup.txt, uv.lock, pyproject.toml ; index explicites uv, pip download, sources pip sans priorité, désactivation config pip.

Preuve

Base exacte 1292984d804e2e1f44afa4de75dc43eb22803730. Treize tests ciblés passent en 0,060 s : source/flags/hashes, réparation partielle, macOS, configuration héritée, absence de wheel/hash erroné, rollback et stamps. La réconciliation des pins avec le lock reste exécutable sur toutes les versions Python prises en charge.

Résolution Linux réelle terminée code 0 dans l'image officielle python:3.14-slim-bookworm@sha256:416f0db2a2b561945630cef9877a7ea0581b27449eb9fd9df42f03e1b74b5b63, plateforme Linux ARM64, Python 3.14.7, pip 26.2.1. Commande extraite du runbook, architecture linux/arm64, dépôt monté en lecture seule :

bash /private/tmp/cortex-green-w2-5-linux.sh

Pip --dry-run --ignore-installed --report résout 48 distributions, dont torch-2.13.0+cpu-cp314-cp314-manylinux_2_28_aarch64.whl, zéro paquet nvidia-*. SHA256 du wheel : ca021f9eb2f8345c83fa03e3a04587308afb8df71bd472670b3ece00df58621c, vérifié dans les hashes du lock. Le rapport donne une source file:// pour ce wheel préalablement téléchargé sur l'index CPU ; les 47 autres sources sont PyPI/files.pythonhosted.org.

Aucune dépendance installée et aucun modèle chargé. Le staging du wheel est retiré en fin de résolution ; le conteneur est supprimé, le conteneur utilisateur préexistant harness-mongo reste intact. Charge hôte 4,16 / 10 cœurs, disque 60 GiB avant/après. La première tentative s'arrêtait avant le lancement faute de partage /private/tmp par Colima ; la seconde a utilisé un chemin partagé. Le runbook permet ce choix explicite.

Rapports archivés sous /private/tmp/cortex-green-w2-5-linux.kCuwf8/ : resolution.log, pip-report.json, cpu-source.json, source-provenance.json, container.id. Le manifeste conserve le chemin original de collecte et les SHA des cinq fichiers runtime ; aucun rebase ni changement de ces sources depuis la résolution.

bash /private/tmp/cortex-green-unit-isolated.sh tests_py.scripts.test_launcher_torch_cpu tests_py.scripts.test_launcher_torch_cpu_pins tests_py.scripts.test_launcher_torch_cpu_stamps
bash /private/tmp/cortex-green-local-gates.sh w2-5 tests_py/scripts/

Gates finaux : Ruff check/format (1 449 fichiers), craftsmanship et Pyright sans erreur ; scripts : 882 réussis, 5 ignorés, 348 sous-tests en 12,29 s ; suite complète : 7 697 réussis, 221 ignorés, 361 sous-tests en 155,06 s. PostgreSQL volontairement inaccessible dans ce gate SQLite isolé. Sortie du driver : 0 ; charge initiale 4,78 / 10 cœurs ; disque 60 GiB avant/après. Journal : /private/tmp/cortex-green-w2-5-gates.log.

SHA final : 8c72db7700c44911bb535efd237ea4ead390af89. CI 34047249647 verte ; builds Docker filtrés conformément à W1-4.

Conformité

Deux helpers stdlib nouveaux de 106/90 lignes, fonctions sous 40 lignes/quatre paramètres. launcher_deps_install passe de 300 à 238 lignes ; pip_install fait désormais 35 lignes, son entrée baseline obsolète est retirée. Aucun ajout baseline, aucune couche métier ou DB touchée. Un seul travail lourd local à la fois.

Candidats issues

Les autres transitives ML suivent toujours la résolution PyPI existante : cette PR ne prétend pas transformer tout le bootstrap en installation entièrement hash-pinnée. La preuve porte sur la résolution ARM64 Linux, pas sur une inférence réelle ni un gain énergétique. Les installations CUDA historiques ne sont pas purgées. Aucun ticket créé.

Runbook

docs/runbooks/linux-cpu-bootstrap.md fournit la résolution Linux reproductible sans installation. Adapter explicitement l'architecture et un dossier partagé avec Docker si nécessaire. Les nouvelles installations/réparations Linux utilisent CPU ; aucune opération de maintenance de production requise.