MachineLearning Post Introduces preflight, a PyTorch CLI for Catching Silent Training Failures Before GPUs Burn Time

Built after a costly silent failure

On March 15, 2026, a post in r/MachineLearning introduced preflight, a lightweight CLI for validating PyTorch pipelines before training begins. The author says the tool came out of a very familiar failure mode: a run that did not crash, did not throw errors, but still produced useless results because train and validation data were leaking into one another. After losing three days to that kind of bug, the author built a gate that runs before expensive jobs leave the ground.

The positioning is intentionally narrow. preflight is not described as a full experiment platform or a general data-quality framework. It is a short pre-training checklist that can run locally or in CI, fail fast on fatal problems, and prevent teams from burning GPU hours on jobs that were broken before the first optimization step.

What the tool actually checks

The README lists 10 checks across three severity tiers. Fatal checks include NaN/Inf detection, label leakage, shape mismatch between dataset and model, and gradient checks for dead or exploding paths. Warning-tier checks cover normalization sanity, channel ordering, VRAM estimation, and class imbalance. Informational checks include split sizes and duplicate samples. The default entry point is deliberately small: install preflight-ml, point it at a Python file that exposes a dataloader, and run preflight run --dataloader my_dataloader.py.

That design is pragmatic. The tool exits with code 1 if a fatal check fails, so it can block CI automatically. The repository also documents a GitHub Action, JSON output for machine-readable results, and a .preflight.toml file for thresholds or disabled checks. The project is MIT-licensed and, at crawl time, was tagged as an early v0.1.1 release.

Where it fits in the ML stack

The maintainer explicitly says preflight is not trying to replace pytest, Deepchecks, Great Expectations, or experiment trackers. Instead it fills a smaller gap: situations where the code technically runs, but the training state is already compromised by malformed tensors, mislabeled splits, or a model-input mismatch. That gap is real in day-to-day ML work because many of the most expensive bugs are silent rather than catastrophic.

The roadmap in the README reinforces that focus. Planned features include auto-fix helpers, drift comparison against a baseline, dry-run execution through model and loss, and domain-specific plugins. Even in its early state, the project is a good example of community-built infrastructure that targets operational waste rather than leaderboard scores. That is exactly why the post mattered: it framed model training quality as a preflight discipline instead of a postmortem exercise.

Primary sources: GitHub repository, PyPI package. Community discussion: r/MachineLearning.