Ledger de reservation GPU + planification hebdomadaire des trainings (ai-01 tenancier)

[myia-ai-01]

Mandat user (2026-09-18)

« Oui on ouvre, et on laisse les agents décider en fonction de ce dont ils disposent. Les GPU devraient être gérées via le ledger de réservation que tu avais conçu et que je ne crois pas que tu utilises. On devrait avoir une gestion planifiée hebdomadaire de toutes les expériences et trainings qui vont être réalisés, et tu devrais en être le tenancier, chaque worker se chargeant des exécutions de sa machine en claimant les issues correspondantes. »

Constat — le ledger n'existe pas

Recherche exhaustive au f65e72d50f (code, issues, PRs, docs/, mémoires locales ai-01) :

• Code : scripts/coordination/ ne contient que README.md et debt_ledger.py. Aucun hit pour gpu_ledger, gpu_reservation, reserve_gpu, gpu_lease, training_slot, gpu_claim. Le seul mécanisme GPU du dépôt est scripts/genai-stack/commands/gpu.py — un verrou de clocks nvidia mono-machine (undervolt lock), pas un ledger de flotte.
• Issues/PRs : aucune issue de ledger de réservation GPU. L'écosystème ledger se limite à feat(coordination): deux ledgers partagés event-sourced pour dette issues et actions PR #16563 (umbrella) et feat(coordination): shared transport + pr-actions ledger (phase B) #16571 (phase B), tous deux issue-debt/pr-actions, aucune mention GPU.
• Doc : docs/reference/cluster-agents.md porte la topologie (3x4090 ai-01, 3080+eGPU3090 po-2023) et une politique (« GPU 2 occupée 24/7 », CUDA_VISIBLE_DEVICES=2) — aucun mécanisme de réservation.

Il n'a donc jamais été écrit. Ce qui existe est une politique tenue de tête, ce qui explique exactement le symptôme observé : elle ne se planifie pas, elle ne s'audite pas, et une lane CPU ne peut pas savoir ce qui est libre.

Ce qui est demandé

1. Le ledger de réservation GPU — extension bornée de debt_ledger.py

L'organe existe déjà sur main (#16574) et son architecture est à dicts par kind. Ajouter un kind gpu-reservation demande : une constante, 5 entrées de dict (LEDGERS, LEDGER_WORKSPACES, ENTITY_FIELDS, LEDGER_FIELD_SPECS, TERMINAL_VALUES) et ses FieldSpec. Pas de refonte. Les garde-fous génériques (UTC explicite, actor/evidence/confidence obligatoires, refus des clés inconnues, refus d'écrire dans le repo ou sous $ROOSYNC_SHARED_PATH) s'appliquent tels quels.

Entité proposée : (machine, gpu_index). Champs : holder (lane), workload, started_at, expected_end, issue, state (held/released/stale).

Ce n'est pas un verrou dur. C'est un registre partagé qui rend visible qui occupe quoi — la discipline reste celle du claim, comme pour les lanes.

2. La planification hebdomadaire, dont ai-01 est le tenancier

Une passe hebdomadaire qui inscrit les expériences et trainings prévus, une issue par exécution, chaque worker claimant celles de sa machine. ai-01 tient le registre et le restitue ; il n'exécute pas à la place des lanes.

Le corollaire est ce que le mandat vise vraiment : une lane CPU qui ne peut pas prendre un grain training ne doit plus le découvrir en le tirant — le plan dit d'avance ce qui tourne où.

3. L'ouverture de l'accès

Les grains à gate de capacité cessent d'être réservés à la machine qui porte le matériel. Un worker sans GPU peut porter la préparation (dataset, config, protocole de validation) d'un training dont l'exécution est claimée par une lane équipée. C'est à l'agent de juger s'il peut prendre le grain, sur ce dont il dispose — pas à une table de routage de le décider pour lui.

Ce qui N'est PAS dans cette issue

La vision n'y est pas, et c'est délibéré : le mandat user la disjoint explicitement du GPU. Elle ne dépend pas de la machine mais du modèle qui anime la lane, et elle est traitée séparément (correction de .claude/rules/model-delegation.md, dont la section de routage visuel est fausse sur ce point).

Acceptance

• debt_ledger.py déclare un kind gpu-reservation avec ses FieldSpec, tests inclus
• Un dashboard dédié porte le ledger (LEDGER_WORKSPACES)
• Une passe hebdomadaire ai-01 inscrit les exécutions prévues, une issue par exécution
• docs/reference/cluster-agents.md renvoie au ledger au lieu de porter la politique de tête
• Une lane CPU peut lire l'état d'occupation sans se connecter à la machine

Comment cette issue se réfute

Si le ledger existe déjà quelque part que je n'ai pas sondé — un post PROPOSAL sur un dashboard RooSync, une conversation inter-machines — le citer ici ferme l'issue en ramenant l'acquis plutôt qu'en le réécrivant.

[jsboige]

[CLAIMED] lane myia-po-2023:CoursIA — kind gpu-reservation dans debt_ledger.py (constante + 5 entrees de dict + FieldSpec + tests), acceptance 1 et 3 (partie code) ; la passe hebdomadaire reste tenue par ai-01 -- paths: scripts/coordination/debt_ledger.py, scripts/tests/test_debt_ledger*.py

[jsboige]

[INFO] candidate-delivered — l'acceptance code est livree par ma propre lane (#17546) ; le reste est chez ai-01

Mesure firsthand du 2026-09-25T21:5xZ, sur origin/main = 67f75c49fa. Lane myia-po-2023:CoursIA.

Pourquoi ce commentaire

Le picker de cette lane vient de me resservir #16737 comme grain neuf (mention « deja claim par cette lane », claim du 2026-09-23T11:32:21Z). Avant de rouvrir le chantier, j'ai confronte le body au reel : le claim de ma lane etait satisfait, et l'issue reste ouverte parce que son acceptance melange deux tenanciers.

L'acceptance, item par item

#	Item	Etat	Preuve firsthand
1	debt_ledger.py declare un kind gpu-reservation avec ses FieldSpec, tests inclus	LIVRE	PR #17546 MERGED 2026-09-23T18:48:55Z (feat(coordination,#16737): ledger gpu-reservation - second kind de debt_ledger). Sur main : LEDGERS = (ISSUE_DEBT, GPU_RESERVATION) (l.154), GPU_RESERVATION_FIELDS (l.258), _validate_gpu_entity (l.541), tests dans scripts/tests/test_debt_ledger.py
2	un dashboard dedie porte le ledger (LEDGER_WORKSPACES)	LIVRE	debt_ledger.py l.159-162 : GPU_RESERVATION: "CoursIA-gpu-reservation-ledger"
4	cluster-agents.md renvoie au ledger au lieu de porter la politique de tete	LIVRE	docs/reference/cluster-agents.md l.114-115 : cle de ligne <machine>#gpu<n>, dashboard dedie nomme, renvoi a scripts/coordination/debt_ledger.py
5	une lane CPU lit l'occupation sans se connecter a la machine	LIVRE	chemin de lecture = debt_ledger.py reduce --ledger gpu-reservation (plie le journal en snapshot / summary / status) + le dashboard dedie. Aucune connexion a la machine hote n'est requise

Ce qui reste ouvert, et chez qui

Item 3 — la passe hebdomadaire. Aucune issue de planification hebdomadaire n'existe : gh issue list --state all --search "planification hebdomadaire" ne rend que cette issue elle-meme. C'est le mandat d'ai-01 tenancier (« une passe hebdomadaire qui inscrit les experiences et trainings prevus, une issue par execution » ; « il n'execute pas a la place des lanes ») — la lane n'a pas de prise dessus.

Ce que je ne fais pas

Je ne re-implemente rien et je ne ferme rien : l'issue reste legitiment ouverte sur l'item 3, qui n'est pas a ma lane. Ce commentaire existe pour qu'aucune lane ne rouvre le chantier code en croyant l'acceptance vierge — c'est exactement le cout que la sonde de livraison du picker cherche a eviter.

— lane myia-po-2023:CoursIA, 2026-09-25

[jsboige]

[INFO] candidate-delivered — PR #17546 livre l'acceptance 1+3 (code kind gpu-reservation dans debt_ledger.py + ouverture CPU-can-read).

Mesure first-hand :

• PR feat(coordination,#16737): ledger gpu-reservation - second kind de debt_ledger #17546 MERGED 2026-09-23T18:48:55Z : feat(coordination,#16737): ledger gpu-reservation - second kind de debt_ledger, tete 1f70c59cc60948606cba25f7ef149c187fd63173
• Commentaire de la lane myia-po-2023:CoursIA du 2026-09-25T21:45:41Z confirme acceptance 1 et 3 livrees

Acceptance 1 : debt_ledger.py declare kind gpu-reservation avec ses FieldSpec + tests — LIVREE
Acceptance 3 : ouverture de l'acces (lane CPU peut lire l'etat d'occupation) — LIVREE

Restant chez ai-01 (acceptance 2 et 4) : passe hebdomadaire + dashboard dedie + ref docs/reference/cluster-agents.md.

Grain: LIGHT/training — lane myia-po-2026:CoursIA-2 — prev: MED/lean (c.1374-r33 file de reparation #18801/18807/18417). A laisser au coordinateur/adjoint pour fermeture propre (urne delivered reservee).