État d'avancement et bornes

Où en est le portage — 2026-05-22, NDA J+21/90

Ce qui s'est débloqué entre J+13 et J+21 — et ce qui ne l'est pas

La fenêtre précédente (§ 05 v1, 2026-05-14) listait six bornes. Cinq sur six sont aujourd'hui levées ou re-cadrées par mesure ; une seule subsiste, structurellement, côté Radience.

Bornes levées

1. Validation runtime GPU. Pas sur la cible NVIDIA encore — mais sur la cible Apple Silicon, en mesure end-to-end : MetalRunner produit un manifest avec substrate=gpu, gpu_witness_source=driver_counter, kernel_ns > 0 à chaque launch, et RADIENCE_FORCE_CPU=1 erre par contrat. Le smoke L0 sur piramide.obj atteint 22,9 ms ; l'IQI Sinus à 300M photons s'exécute en 5 min 50 s. La preuve est dans la trace driver, pas dans le PNG.
2. Cross-validation quantitative. Exécutée vs trois témoins : Metal-A vs CPU-reference (golden d'intersection à 2,07e-7), Metal-A vs fixture CUDA W3 indépendante (les quatre sections efficaces gamma — Compton, PE, paire, Rayleigh — certifiées dans \(\varepsilon\) dérivés : max \(|\Delta_{rel}|\) de 4,1e-9 pour PE à 2,67e-6 pour paire), Metal-A vs f_tot.jpg (SSIM structurel veto-only, alignement visuel confirmé).
3. Radiographie IQI Sinus à statistique de production. Run à 300 millions de photons (1,2 milliard d'impacts), grille \(512^{2}\), fenêtre \(\pm35\) cm, 5 min 50 s sur M4 Max. Disque + stries sinusoïdales + bords festonnés reproduits ; comparatif côte-à-côte dans docs/metal-a-payoff/.
4. Bit-exactitude vs similarité statistique. Hypothèse posée § 05 v1 « on ne vise pas la bit-exactitude » — confirmée par mesure : Metal-A est bit-exact sur les fonctions pure (RNG xorshift32, polynomial fits aux constantes verbatim) ; statistiquement indistinguable sur les samplers (un perturbation FMA 1e-6 désynchronise le flux RNG d'un sampler par rejet — comparaison distributionnelle obligatoire, gate G_ks_bonferroni).
5. Robustesse production non prouvée — re-cadré, pas levé. Le portage reste un instrument d'évaluation, pas un produit durci. Mais : nr ≤ 10 est désormais une hard precondition du runner (l'original CUDA accédait params.nr au-delà de la borne du tableau [10] — UB indétectable côté C++, Rust truncate proprement, et le port refuse les configurations qui auraient été UB côté kernel original). Discipline no-fast-math sur les TU de physique. force-cpu à contrat négatif. Ce n'est pas du durcissement produit, c'est de la fidélité au code original avec hygiène Rust ajoutée.

Borne qui subsiste — toujours côté capacité, pas code

Validation NVIDIA bin-à-bin vs baseline OptiX 4. Le port OptiX 9 atteint optixLaunch ; il ne peut être exécuté sur notre côté faute de capacité L4 en Europe (stockout transitoire sur europe-west3 et west4) et du téléchargement manuel du SDK OptiX 9.1 (login NVIDIA non automatisable). Sur la VM radience-optix-dev (g2-standard-8 + nvidia-l4, persistent disk déjà bootstrappé) il suffit en théorie d'un redémarrage — quand la capacité L4 EU se libère. Snapshot conservé pour migration zone si besoin.

Ce n'est plus le seul point de bascule du livrable : la cross-validation sur fixture CUDA dérivée des .cu originaux (W3) compile directement sur n'importe quel host avec un toolchain CUDA — pas besoin d'une carte L4. Elle a certifié les sections efficaces. Le smoke test runtime OptiX 9 reste utile pour deux raisons : (i) confirmer que le pipeline OptiX-9 lui-même tourne (au-delà de optixInit qui est déjà validé), (ii) produire la baseline numérique vs laquelle on comparera bin-à-bin si Radience demande un audit fin. Mais la physique est certifiée par W3, indépendamment.

Trois findings honnêtes surfacés par la certification

Inscrits ici parce qu'ils qualifient le degré de complétude du livrable.

F1 — Corner Seltzer-Berger à E ≥ 50 MeV (hors production)

Sur 226 points comparés vs W3, 220 PASS dans \(\varepsilon\). Les six échecs sont concentrés sur le coin Seltzer-Berger (bremsstrahlung) à x = 0,95 et y = Energy ≥ 50 MeV — un FMA Metal \(\times\) cancellation polynomiale (condition number ~336) qui sort 1e-6 au lieu de 1e-7. \(\varepsilon\) non relâché : la mesure est honnêtement labellée FAIL. Impact production : nul — le spectre gamma plafonne à 10 MeV ; ce coin n'est jamais visité par un run réel. Conservé en file de remédiations (docs/metal-a-oracle-certification/REPORT.md §7).

F2 — Divergence du modèle d'écran côté ancien port CPU

Les gates distributionnels G_ks_bonferroni et G_tail_ks ont FAIL — mais root-causés à W2 (l'ancien port CPU), pas à Metal-A. W2 réinterprète l'écran lanex comme un plan implicite z = -50 ; Metal-A est fidèle au .cu original (pinhole_camera.cu:168 — hit-mesh sous z_screen). Les deux capturent des populations d'événements différentes \(\to\) non distributionnellement comparables. Conclusion structurelle : l'oracle a démasqué un bug de l'ancien port, pas du nouveau. Metal-A est plus fidèle à l'original que ne l'était la version CPU précédente. Remédiation : aligner W2 sur le modèle .cu — file de follow-up identifiée, non bloquante pour la signature.

F4 — Disjonction d'exécution indéterminée (manque le 2ᵉ témoin GPU)

G_oracle_execution_disjoint requiert \(\geq\) 2 témoins GPU disjoints (un par monomère GPU). Monomère B étant rétrogradé en CPU, on n'a qu'un seul leg GPU (Metal-A). La disjonction est néanmoins prouvée séparément par : (i) substrats distincts (metal_a=gpu, cpu_ref=cpu), (ii) contrôle négatif RADIENCE_FORCE_CPU=1 qui erre, (iii) KS inter-leg max p-value = 0,0016 (loin de 1,0 \(\to\) pas de collusion). Le gate ferme correctement quand un second monomère GPU est promu — sa réouverture est conditionnée au re-entry test de backend-advocate-B.

Ce que cette fenêtre a démontré, en deux phrases

La radiographie gamma de Radience tourne sur le GPU du Mac, ~\(34\times\) plus vite que le CPU mono-thread, reproduit la radiographie de référence livrée, et sa physique est numériquement certifiée contre une fixture dérivée des .cu originaux — chaque chiffre porte un témoin d'exécution non-falsifiable, l'absence de témoin étant un échec, pas un résultat.

La fleet qui a produit ce résultat s'est observée elle-même : la délibération de cette itération a diagnostiqué la panne silencieuse précédente (« le backend MLX existait sur l'étiquette, pas dans l'exécution ») en grep indépendant par 10 personas, et a câblé le mensonge GPU comme inreprésentable au niveau du type — pas seulement détectable au niveau du gate.

Prochains jalons — la boucle collaborative

Ce livrable reste une demande de test, pas un rapport final. La géométrie a changé : la boucle collaborative s'attache maintenant à trois points qui dépendent du matériel Radience ou de la baseline historique :

1. Cross-validation NVIDIA bin-à-bin. Quand François / Agustin font tourner le port OptiX 9 sur leur matériel (ou quand notre VM L4 se libère du stockout), compare-runs produit le verdict KS bin-à-bin port-OptiX-9 vs baseline-OptiX-4. La fixture CUDA W3 a déjà certifié les sections efficaces, mais ce smoke run reste utile pour valider le pipeline OptiX 9 lui-même.
2. Alignement W2 sur le modèle d'écran .cu. F2 est une remédiation côté ancien port CPU — elle ferme G_ks_bonferroni et G_tail_ks distributionnellement et confirme la fidélité de Metal-A.
3. Round-trip auteur sur les deux questions irréductibles (budget réservé § 05 v1, non consommé) : (a) le coin Seltzer-Berger E \(\geq\) 50 MeV — l'auteur le visite-t-il jamais en pratique, ou est-il un artefact mathématique ? (b) le modèle d'écran lanex implicite vs explicite — quelle convention était l'intention originale ?

L'estimation de wall-clock pour les deux premiers : quelques heures une fois le toolchain en place ou la baseline cross-référencée. Le troisième point — entretien auteur — est précisément le type d'irréductible que la discipline de budget de round-trip protège. Et cette boucle est le partenariat technique que le NDA invite à évaluer (art. 2.3).