📦 WP-193g — perf(ptl): replay shared segmentation features¶
Engineering log · Phase 18 — CUDA graph replay and pipeline throughput
WP-193g — replay common features without joining prediction gradients¶
The segmentation prediction recorder leaves backbone and neck native. An L4 Nsight Systems trace of eight training batches, with prediction and optimizer replay already enabled, attributes 151.230 ms of host dispatch to backbone and 127.376 ms to neck within 1,544.688 ms of batch ranges. These diagnostic ranges account for 18.04% before their backward work; they are not an end-to-end speed claim. The optimizer-step range encloses the forward/backward closure, so its total cannot be interpreted as optimizer-only cost.
The existing capture_network option now accepts segmentation and records these shared features through R43's existing graphed-callable adapter. All three feature levels already feed dense classification. Keeping coefficients, prototypes and semantic predictions outside that recording preserves their independent backward nodes and absent-gradient semantics. The option combines with capture_segment_heads, which records those predictions separately. Native model, assignment, loss, optimizer, schedule and EMA expressions are unchanged.
Single-device CUDA automatic optimisation and a fixed input signature remain required. The default stays off. Accumulation, frozen shared features, altered head topology/dispatch or registered head hooks, overridden or compiled segmentation forwards and the shared recorder's existing unsupported conditions retain native execution. Partial batches do not create additional recordings. Transient recordings are released at fit completion or failure and do not alter checkpoint keys.
Five alternating fresh-process pairs on an isolated NVIDIA L4 g2-standard-8 reduce complete nano segmentation fit time by 18.42% against main b293970, with segmentation prediction replay already enabled:
| Seconds, median (range) | Native shared features | Replayed shared features |
|---|---|---|
| Complete fit | 107.412 (106.764–109.816) | 87.629 (87.043–88.462) |
| Whole process | 112.721 (111.918–115.208) | 92.937 (92.471–93.827) |
Each fit uses 512 public COCO val2017 images for training and 16 disjoint images for validation, the original 80-class annotations, five epochs, batch 4, 640 px and BF16 mixed precision. Both arms enable prepared-image caching, device HSV, epoch prefetch with four persistent workers, segmentation prediction replay, orthogonalization replay and update preparation replay. Mosaic remains active throughout (close_mosaic=0); warmup is one epoch. The timer starts before model, data and trainer construction and includes cache preparation, graph recording, training, EMA, validation and last-checkpoint writes. Imports and output hashing are outside that fit timer; the whole-process row includes them and reduces by 17.55%. Runtime: Python 3.11.14, torch 2.9.1+cu129, Lightning 2.6.6, driver 580.178.04.
Model, optimizer, scheduler and EMA bytes, the 640 per-step loss bytes and validation metrics match within and across the ten fits. Losses, metrics and final model tensors are finite. Median whole-fit peak allocated memory is 1731 → 1511 MiB; peak reserved memory is 5496 → 5702 MiB. These are distinct allocator metrics, with extra reserved graph workspace rather than a capacity claim. The speed claim is limited to this batch-4 workload.
The SHA-256 of the measured UTF-8 bytes of src/lucid_yolo/ptl/module.py at the measured PR-head tree (8ebf10e) is 1800875a7c034e6567ff8848e87b7c96cc091004fc112e1b5734c0f2a1354306, computed with sha256sum src/lucid_yolo/ptl/module.py; later commits change module.py, so the hash does not describe later trees. The existing numerical stage expressions and all 41 restricted model/loss/assignment/optimizer/decode files are unchanged. Earlier measurements without the final head certificate are exploratory and do not supply this result.
A separate single batch-16 screen (three epochs over the same 512 training and 16 validation images) changed complete fit time from 45.828 to 44.498 s, only 2.90%. Model, optimizer, scheduler, EMA, per-step losses and metrics matched. This is an exploratory boundary case, not a repeated batch-16 performance claim; no batch-16 optimization is submitted on that number.
Focused checks pass 53 CPU-only cases with 43 GPU-marked cases deselected, 24 cases on torch 2.9.1 with CUDA available (including ten GPU-marked cases), and 27 cases including doctests on torch 2.4.0+cu124. Older BF16 replay retains native execution. The regressions exercise CPU routing, actual CUDA replay, every prediction and gradient byte, changing mask demand, empty supervision, partial batches, validation/EMA transitions, accumulation fallback and CLI construction. Removing replay deliberately fails the maintained route assertion. The full make gate, accelerator goldens and long-run accuracy were not run for this work and remain unverified; offline CI was green at the PR head 8ebf10e, which says nothing about the merged tree.
No new method constant or numerical assumption is introduced. The basis is this repository's native stage composition, our CUDA profiles and R43's registered runtime API.