📦 WP-199b — reduce CUDA pose loss dispatch¶
Engineering log · Phase 18 — CUDA graph replay and pipeline throughput
WP-199b — one opt-in pose loss execution path¶
capture_loss, off by default, also accepts pose. Its unrotated detection objective uses the existing recording, and the current assignments feed the native point gathers. During training, a certified native RLE flow scores the two branches' selected rows together. Visibility selection precedes arithmetic, the split uses the selected point count, and each branch retains its own mean and alpha weight. The density expressions, shared parameters and optimizer remain the existing ones.
The flow has six row-independent coupling conditioners, each with three linear calls. Batching reduces those forward calls from 36 to 18. Source and runtime identities, hooks and compiled modules are checked before pairing; altered scoring, custom densities and validation retain their native calls. Different branch input dtypes/devices and tensor subclasses also keep separate calls, preserving each branch's logarithm precision. Existing detection recorder guards and fit cleanup stay in force for the detection objective; they do not gate the density batching, which keys on the option being active for the fit and so continues after the recorder retires, under a customized criterion and under the BF16 fallback for torch older than 2.9. Laplace-only pose keeps its native point objective.
This is not a byte-identical training option. Changing the batch can change matrix-kernel selection and the order of parameter-gradient sums. CPU double comparisons establish the separate branch objective and derivatives; CUDA comparisons measure the rounding difference. Default execution is unchanged. Long-run convergence and acceptance accuracy remain unverified.
Initial profiles on an L4 identified host dispatch rather than a dominant device kernel: median kernel duration was about 1.4 microseconds, and the eager detection loss and RLE forward scopes together occupied about 15% of the instrumented step window before backward. Those initial diagnostic runs used the module's 0.34-depth example, not the registry nano model, and are not a nano throughput result. Detection-loss replay alone reduced the exploratory fit by 4.54%; density batching alone by 7.54%. Neither was sufficient alone. Complete-fit validation uses registered nano (depth 0.50), batch 4, 640 px and BF16 on one L4 with Torch 2.9.1+cu129, five epochs over 384 public COCO person images and 32 disjoint validation images. Both arms enable the existing applicable training options. Five alternating fresh-process pairs include model/trainer and cache setup, graph recording, training, EMA, validation and checkpoints. Native median (range) is 100.586 (99.890–101.894) s; pose loss execution is 87.058 (86.201–87.297) s: 13.45% less complete-fit time. Whole-process medians are 106.025 and 92.389 s. Peak reserved CUDA memory rose from 1404 to 1496 MiB on the measured arms; as with the timing, the submitted tree has no memory measurement. The native arm is main at 0c84549. The commit of the pose loss execution arm is not recorded and is pending the contributor. The submitted tree builds on 22d8df4 (pose prediction-stem replay, WP-193f) and main has since gained 5756ea0 (segmentation replay); neither that tree nor the merged one has been re-measured, so the percentage is a result for the measured arms only. One complete batch-16 pair measured 48.357 to 46.338 s (4.18% less time), below the investigation's 8% target, so the repeated claim stays at batch 4. Same-weight public COCO samples have equal forward loss values but up to 1.45% relative gradient L2 difference in BF16; the five-epoch terminal training losses are 38.89 and 42.14, but which arm ended at which value is not recorded and is pending the contributor, so the accuracy effect cannot be read from them; short-run throughput does not establish accuracy preservation.
Focused regression tests cover separate visible means, asymmetric and empty subsets, non-finite unlabelled annotations, gradient agreement, an executable 36-to-18 call count, altered dispatch, real automatic CUDA training and composition with the existing pose network replay (capture_network). The tests proving this are tests/losses/test_rle_pair.py::test_pair_keeps_separate_visible_means_and_gradients, tests/losses/test_rle_pair.py::test_pair_halves_native_linear_calls, tests/losses/test_rle_pair.py::test_pair_certificate_refuses_altered_dispatch, tests/ptl/test_pose_loss_execution.py::test_pose_host_execution_keeps_loss_and_gradient_values, tests/ptl/test_pose_loss_execution.py::test_pose_custom_scoring_keeps_native_dispatch, tests/ptl/test_pose_loss_execution.py::test_pose_cuda_execution_keeps_objective_and_gradient_direction and tests/ptl/test_pose_loss_execution.py::test_pose_cuda_execution_composes_with_network_replay. The full development gate, aggregate offline coverage and accelerator goldens remain unverified. This work package stays open.