Skip to content

Cast Kumo feature routes before ensemble assembly and shuffling - #1365

Draft
RBendias wants to merge 1 commit into
RBendias-patch-1from
agent/pr797-early-feature-casts
Draft

RBendias wants to merge 1 commit into
RBendias-patch-1from
agent/pr797-early-feature-casts

Conversation

@RBendias

Copy link
Copy Markdown
Collaborator

Summary

Apply Kumo's existing Float32 feature-output policy at the numerical and categorical route exits instead of after concatenation, shuffle, and selection. The isolated E16 comparisons save about 4–10 ms per fit-plus-query cycle and 51–75 MB of peak allocated GPU memory on the two measured shapes.

Description of the change

Based directly on #797 (6426421904), independently of the Cast no-op PR. Move the conversion into the recipe rather than adding precision policy to generic Processors or ensemble execution.

All learned numerical calculations and random sign fitting remain at their original precision; numerical casting occurs after FlipSign. Casting before sign generation would change seeded CUDA Bernoulli outcomes and is deliberately not done. Assembly and downstream column operations now consume narrower numerical values.

This changes private recipe module/state keys; strict loading of an older already-fitted recipe checkpoint is not guaranteed. Fresh-fit output behavior is checked against the unchanged current-#797 reference.

Validation

Actual Kumo preprocessing recipe, no model inference: 89% numerical / 10% categorical / 1% text columns, effective E16, N training rows and N separate query rows. Baseline 6426421904, candidate e646ace71; identical frozen fixtures and fresh baseline parity references. L4 / EPYC 7R13, four CPU threads, PyTorch 2.14.0+cu130, Python 3.11.15.

Four fresh-process AB/BA pairs per shape, two warmups and 21 chronological repetitions; inference mode, CUDA synchronization, normal GC with no observer. Time includes RecipeExecution.fit_transform plus query transform, but excludes input transfer/tensorization, recipe construction, generator setup and inference. Previous returned outputs remain alive until replacement, matching the existing benchmark boundary.

Shape / E16 Median total before→after, ms p95 total before→after, ms Median paired time change Peak GPU allocated before→after, MB
10,000×500 720.57→710.16 770.45→745.01 −1.48% 2,105.59→2,054.91 (−2.41%)
50,000×100 414.29→409.82 464.06→448.49 −1.41% 2,064.10→1,988.78 (−3.65%)

Reported times are medians of process statistics; percentage changes are medians of paired changes, not pooled quantiles. Total-median pair ranges: −1.64…−0.16% and −2.84…+0.13%, respectively. CPU RSS peaks are effectively unchanged (~1.86 GB). GPU memory means PyTorch allocated, not reserved; RSS is sampled every 2 ms.

Counterevidence: 50k query p95 increases 99.91→102.55 ms (paired +1.81%, mixed pair signs). First-call totals are 1,892.32→1,898.94 ms for 10k and 1,626.27→1,597.24 ms for 50k, also with mixed pair signs. This is a small warm improvement, not a universal cold-start/tail win or a newly rerun full benchmark matrix.

All 16 timing processes passed output parity and effective-E16 checks; two additional baseline-reference processes also completed. Across 402 monitor samples no foreign GPU process or monitor error was observed; 1-Hz polling cannot rule out all transient interference. No speedup from the larger historical architecture experiment is attributed to this three-line recipe change.

@copy-pr-bot

copy-pr-bot Bot commented Nov 12, 2026

Copy link
Copy Markdown

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants