pyfixest-grid-sharding

# pyfixest Grid Sharding ## Problem A regression grid (e.g. 2 measures x 3 FE structures x pooled+per-domain x 3 label variants ~ 70 models) on a 327k-row panel with high-cardinality director FE ran ~55 s/model sequentially — ~65 min wall — on an RTX 5080 machine with `demeaner_backend="cupy64"` on every call. The GPU was NOT the bottleneck. ## Context / Trigger Conditions - Measured signature (verified 2026-07-21, H5 seat-loss rerun): job process at ~1.4 cores CPU (37.7 CPU-min in 27 wall-min), `nvidia-smi` 0% utilization with ~4 GB resident (cupy context loaded, idle), one pyfixest singleton warning per completed model ticking by in the log. - Any orchestration prompt that asks a worker to "rerun every headline cell under variants A/B/C" without specifying execution structure. ## Solution 1. Diagnose before blaming the GPU: check process CPU-minutes vs wall-clock (~1 core => serial CPU-bound) and GPU utilization (near 0% => demeaning is not the constraint). The cupy64 kwarg is still correct; it just cannot fix a CPU-dominated pipeline. 2. Shard the GRID, not the data: split the model list across N OS processes (`--shard i --nshards N` over the model index, one output part-file each, merge step at the end), N ~ cores-4. Models are independent — this is the Execution Style process-sharding pattern applied to regressions. 3. Amortize fixed costs inside a shard: build the panel/interactions ONCE per variant and reuse; where specs share RHS/FE,...