Know what a GPU job needs before it takes a reservation.

Needed memory is the training peak buildPlan predicts from the graph: weights, gradients and optimizer state (1.2 x 16 bytes per parameter) plus activations (fitted factors on every layer's output, the intermediates inside each layer, recurrent gate states, the largest tensor's backward copy, and stored attention scores), with 1.15x headroom for allocator fragmentation and the CUDA context. It estimates the training peak under AdamW with bf16 autocast; inference jobs and other optimizers will differ. Six factors fitted on 178 measured runs across 41 architectures, out-of-memory runs included, with the attention-score term only where the run stored scores; held out one architecture at a time, the median error is 7% above 1 GB and it flagged 113 of the 131 times a run did not fit a card; on 25 runs at the edge of a 24 GB card measured after the fit, the median miss is 14%. (every run: https://www.neurarch.com/memory-calibration.html). The score term counts only the attention score matrices eager attention stores for backward; PyTorch SDPA (the Hugging Face default) and flash attention do not keep them, so the plan, like every other plan, leaves that term out unless the CSV's attention column says eager. Token models are sized at the CSV's seq_len, or 2048 tokens (the model's context if shorter) when it is blank. A job with lora_rank is sized with the base frozen in bf16 (2 bytes per parameter) and adapters on every Linear but the head carrying AdamW state. A multi-card job is sized as one model sharded across its cards (FSDP / ZeRO-3 style): the peak at the global batch (per-device batch x cards) against the summed capacity. Plain DDP keeps a full copy on every card, so for a DDP job read the single-card peak at the per-device batch instead. A request is right-sized when it is the smallest capacity that holds the peak or one size up; the right-sized request is the cheapest single card that holds it, and several cards only when no single card does. The not-needed figure assumes the same wall hours: a slower card can lengthen a run, so the figure is reservation capacity paid for and not needed, not a promise about a cheaper run. Every verdict is also checked against the conservative peak, the estimate x 1.43 (held out by architecture, 95% of measured runs of 1 GB or more peaked at or under it): a row whose capacity holds the estimate and not the conservative peak is marked borderline ("measure once"), and an over row that is borderline claims as not needed only what the conservative peak would free.

Prices: on-demand list price per GPU-hour from Modal (modal.com/pricing, verified 2026-08-19), the same table the Neurarch app prices training with. Pass --prices prices.json to use your own rates.

What it does not know

• Data loader memory: pinned host buffers, prefetch queues and worker processes on the GPU host.
• Custom kernels beyond the attention column: fused optimizers, fused losses and other custom ops can add or remove memory it does not see.
• Activation checkpointing, unless the graph declares it: a checkpointed job needs less than this predicts.
• Multi-node communication buffers (NCCL, all-gather and reduce-scatter staging) and pipeline bubbles.
• Throughput: whether the job asked for more cards to finish sooner. This is a memory verdict, not a speed one.
• Inference, evaluation and non-AdamW optimizers: the peak here is training under AdamW.
• Output logits upcast to fp32, and per-token entropy or log-probabilities over a large vocabulary (as TRL computes them): batch x tokens x vocabulary x 4 bytes, which on a 150k-token vocabulary can be several GB on its own.

Derived, not measured: nothing in this report was run. Input: packages/neurarch-cli/examples/jobs.sample.csv, captured 2026-10-18 with neurarch 0.2.0.