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, use pyfixest multiple- estimation syntax (multiple depvars / sw()/csw() stepwise) so one model matrix serves several reported cells.
4. Orchestrator rule: put the sharding mandate IN the worker prompt for any grid larger than ~10 models. Workers default to sequential loops otherwise.
5. Mid-flight call: if a sequential grid is already >1/3 done with no per-model checkpoint, let it finish — restart+shard usually nets slower. Grids launched fresh should checkpoint per model (append-only part file) so this trade-off never binds again.