Scaling law is an empirical relationship that approximates how model loss or capability changes as parameters, training data, and compute increase over a measured regime. Power-law fits help allocate scarce accelerator time, choose model and token budgets, forecast diminishing returns, and translate algorithmic goals into memory, interconnect, power, and datacenter demand. Early neural language-model studies, including Kaplan-style analyses, emphasized predictable loss trends with model size, data, and compute. Chinchilla-style compute-optimal results showed that many large models were undertrained and that, under their assumptions, parameters and training tokens should grow together more evenly. Coefficients are empirical and dataset-, architecture-, and regime-dependent. A production definition names the model family and release, parameter and active-parameter scale, vocabulary, context window, data cutoff and provenance, objective, precision, adaptation method, decoding policy, serving stack, target hardware, safety controls, evaluation protocol, and known limitations. Labels such as large, frontier, open, multimodal, efficient, or state of the art are not specifications; results must identify the exact artifact, prompt template, sampling settings, software version, hardware, and measurement date. Specify target loss or capability metric, model family, parameter counting, active versus total parameters, dataset and tokenization, data quality and reuse, compute accounting, optimizer and schedule, context, precision, hardware efficiency, run range, fit form, uncertainty, extrapolation horizon, and date.
Architecture, algorithms, and system integration. A sweep trains multiple model and data sizes under controlled recipes, records loss and consumed compute, fits relationships such as an irreducible floor plus power-law terms, validates held-out residuals, and uses a compute constraint to select candidate parameter and token allocations. Hardware and serving models then test whether the training-optimal point meets deployment goals. A simple one-variable form resembles L(x)=L-infinity+A x^(-alpha), where x may be parameters, tokens, or compute and alpha is fitted. Joint laws include separate model- and data-limited terms. Compute-optimal analysis minimizes predicted loss subject to a training-compute budget; it does not prove the same model is inference-optimal. Parameter, data, compute, transfer, context-length, sparse-expert, post-training, test-time-compute, and inference scaling laws measure different axes. IsoFLOP studies compare runs at similar compute. Capability emergence may look sharp when a smooth underlying probability crosses a discrete metric threshold. A modern AI system spans data collection and governance, filtering and deduplication, tokenization, distributed training, checkpointing, post-training, evaluation, model registry, quantization and compilation, inference schedulers, accelerators, memory and interconnect, retrieval or tools, application policy, observability, and incident response. Decisions at one layer change accuracy, latency, memory traffic, energy, safety, and maintainability elsewhere. Evaluation combines task quality with calibration, robustness, subgroup behavior, contamination resistance, factuality, safety, privacy, memorization, latency to first token, inter-token latency, throughput, concurrency, memory capacity and bandwidth, accelerator utilization, energy per useful output, availability, and cost. Means alone conceal tail behavior, prompt sensitivity, evaluator uncertainty, and failures on rare but consequential cases.
Implementation, compute behavior, and failure modes. Design logarithmically spaced pilots, hold architecture and optimizer rules consistent, account for failed and warmup runs, use high-quality deduplicated data, fit with uncertainty, inspect residuals and regime changes, validate at withheld scales, and update the law when architecture, data, tokenizer, or training recipe changes. Nominal FLOPs differ from delivered accelerator work because utilization, communication, memory bandwidth, sequence length, sparsity, recomputation, failures, and checkpointing matter. Larger runs require HBM, collective bandwidth, storage, network reliability, power delivery, cooling, and long job scheduling at datacenter scale. Extrapolation beyond measured orders of magnitude can be wrong, contaminated evaluation creates false capability trends, low-quality repeated data violates token assumptions, changing recipes confounds scale, total parameters misstate MoE active work, and optimizing training loss can produce a model too expensive to serve. Implementation uses immutable dataset and model manifests, content-addressed artifacts, deterministic preprocessing where feasible, seeded experiments, versioned prompts and templates, staged rollouts, bounded resource use, typed interfaces, admission control, timeouts, retries with budgets, telemetry, and reversible releases. Training and serving must agree on tokenizer files, special-token IDs, chat formatting, position treatment, numerical precision, and stop conditions. Delivered performance depends on tensor shapes, arithmetic intensity, quantization format, kernel fusion, batch and sequence distributions, HBM capacity and bandwidth, cache hierarchy, host memory, accelerator topology, collective communication, PCIe or fabric links, storage, power caps, cooling, and scheduler placement. Peak FLOPS or a single benchmark number cannot predict end-to-end behavior. Common failures include train-test leakage, duplicated or poisoned data, tokenizer drift, checkpoint incompatibility, unstable optimization, catastrophic forgetting, numerical overflow, router collapse, silent truncation, cache exhaustion, latency cliffs, evaluator bias, benchmark gaming, hallucination, unsafe tool calls, privacy leakage, model extraction, dependency compromise, and dashboards that average away the affected users.
Evaluation, governance, and lifecycle controls. Use withheld pilot points, alternative fit forms, bootstrap intervals, residual plots, ablations for data quality and reuse, exact compute accounting, independent reproduction, downstream capability checks, robustness and safety scaling, and sensitivity to hardware utilization and inference constraints. Report fitted exponents and intervals, irreducible loss estimate, residual error, valid range, tokens per parameter, active and total parameters, training FLOPs, achieved utilization, wall time, energy, data reuse, downstream quality, serving memory, latency, throughput, and total lifecycle cost. Scaling forecasts influence large capital and energy commitments; assumptions, uncertainty, data rights, environmental impact, supplier capacity, safety evaluations, stop criteria, and decision ownership must be reviewable rather than hidden behind one curve. Validation combines schema and unit tests, small-run training checks, loss and gradient diagnostics, distributed-failure injection, golden-token tests, reference decoding, numerical comparisons, benchmark suites, adversarial and red-team evaluation, human review with calibrated rubrics, subgroup slices, load and soak testing, hardware profiling, canary deployment, rollback drills, and post-release monitoring. Independent test sets and frozen protocols protect the measurement boundary. Dataset snapshots, licenses and consent, filtering rules, tokenizer assets, source revision, configuration, seeds, optimizer state, checkpoints, adapter lineage, compiler and runtime, container, accelerator firmware, evaluation prompts, judge models, human labels, approvals, model cards, incidents, and deprecation remain linked. Reproducibility is a chain of custody rather than a saved weight file. Owners define data rights, privacy and retention, security classification, acceptable use, safety thresholds, model and supply-chain provenance, access control, secrets, export and regional obligations, environmental reporting, human escalation, vulnerability response, audit evidence, and final release authority. Automated scores inform but do not replace accountability for the deployed system.
| Law or study type | Varied resource | Controlled quantity | Decision supported | Primary caution |
|---|---|---|---|---|
| Parameter scaling | Model size | Data and recipe | Capacity trend | Undertraining confound |
| Data scaling | Training tokens | Model and recipe | Corpus budget | Quality and reuse |
| Compute scaling | Training FLOPs | Optimized allocation | Budget forecast | Accounting and fit range |
| IsoFLOP analysis | Model and data jointly | Similar compute | Compute-optimal mix | Recipe dependence |
| Inference scaling | Test-time compute | Fixed trained model | Latency-quality trade | Serving cost and tails |
<svg viewBox="0 0 760 470" xmlns="http://www.w3.org/2000/svg" font-family="-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,sans-serif">
<rect width="760" height="470" fill="#0d1117" rx="8"/>
<text x="380" y="28" fill="#e6edf3" font-size="21" font-weight="700" text-anchor="middle">Foundation Model Compute Sizing & Cluster Allocation</text>
<text x="380" y="48" fill="#8b98a5" font-size="12" text-anchor="middle">Parameter Count, Training Token Volume, GPU Cluster Sizing (H100/B200), and Training Time Estimation</text>
<g transform="translate(30, 70)">
<rect width="220" height="350" fill="#161b22" stroke="#30363d" stroke-width="1.5" rx="6"/>
<text x="110" y="24" fill="#79c0ff" font-size="13" font-weight="600" text-anchor="middle">1. Model Size Selection</text>
<rect x="20" y="45" width="180" height="120" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="110" y="70" fill="#58a6ff" font-size="11" font-weight="600" text-anchor="middle">Target Deployment</text>
<text x="110" y="90" fill="#8b98a5" font-size="10" text-anchor="middle">Edge / Mobile: 1B - 3B</text>
<text x="110" y="110" fill="#e6edf3" font-size="10" text-anchor="middle">Desktop / Single GPU: 7B - 14B</text>
<text x="110" y="130" fill="#3fb950" font-size="10" font-weight="600" text-anchor="middle">Frontier Multi-GPU: 70B - 405B</text>
<rect x="20" y="190" width="180" height="145" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="110" y="210" fill="#58a6ff" font-size="11" font-weight="600" text-anchor="middle">VRAM Sizing Rules</text>
<text x="110" y="230" fill="#8b98a5" font-size="10" text-anchor="middle">FP16: 2 Bytes / Param</text>
<text x="110" y="250" fill="#8b98a5" font-size="10" text-anchor="middle">INT4: 0.5 Bytes / Param</text>
<text x="110" y="270" fill="#8b98a5" font-size="10" text-anchor="middle">+ KV Cache Overhead</text>
<text x="110" y="310" fill="#3fb950" font-size="10" font-weight="600" text-anchor="middle">Serving Footprint</text>
</g>
<g transform="translate(270, 70)">
<rect width="220" height="350" fill="#161b22" stroke="#30363d" stroke-width="1.5" rx="6"/>
<text x="110" y="24" fill="#79c0ff" font-size="13" font-weight="600" text-anchor="middle">2. Total Training FLOPs</text>
<rect x="20" y="45" width="180" height="120" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="110" y="70" fill="#3fb950" font-size="12" font-weight="600" text-anchor="middle">FLOPs = 6 × N × D</text>
<text x="110" y="95" fill="#8b98a5" font-size="10" text-anchor="middle">Example: 70B on 15T Tokens</text>
<text x="110" y="115" fill="#e6edf3" font-size="11" font-weight="700" text-anchor="middle">C = 6.3 × 10²⁵ FLOPs</text>
<text x="110" y="135" fill="#3fb950" font-size="10" text-anchor="middle">63 ZettaFLOPs</text>
<rect x="20" y="190" width="180" height="145" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="110" y="210" fill="#3fb950" font-size="11" font-weight="600" text-anchor="middle">Model MFU Efficiency</text>
<text x="110" y="230" fill="#8b98a5" font-size="10" text-anchor="middle">MFU = Achieved / Peak</text>
<text x="110" y="250" fill="#8b98a5" font-size="10" text-anchor="middle">Typical MFU: 40% - 55%</text>
<text x="110" y="270" fill="#8b98a5" font-size="10" text-anchor="middle">FlashAttention-3 + FP8</text>
<text x="110" y="310" fill="#3fb950" font-size="10" font-weight="600" text-anchor="middle">Optimized Supercomputing</text>
</g>
<g transform="translate(510, 70)">
<rect width="220" height="350" fill="#161b22" stroke="#30363d" stroke-width="1.5" rx="6"/>
<text x="110" y="24" fill="#79c0ff" font-size="13" font-weight="600" text-anchor="middle">3. Cluster Execution Time</text>
<rect x="20" y="45" width="180" height="120" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="110" y="70" fill="#d2a8ff" font-size="11" font-weight="600" text-anchor="middle">Time = C / (GPUs × TFLOPS × MFU)</text>
<text x="110" y="95" fill="#e6edf3" font-size="10" text-anchor="middle">16,000 H100 GPUs</text>
<text x="110" y="115" fill="#3fb950" font-size="11" font-weight="700" text-anchor="middle">~ 54 Days Pre-Training</text>
<rect x="20" y="190" width="180" height="145" fill="#0d1117" stroke="#30363d" rx="4"/>
<text x="110" y="210" fill="#d2a8ff" font-size="11" font-weight="600" text-anchor="middle">Fault Tolerance</text>
<text x="110" y="230" fill="#8b98a5" font-size="10" text-anchor="middle">Async Checkpointing</text>
<text x="110" y="250" fill="#8b98a5" font-size="10" text-anchor="middle">Automatic Node Failover</text>
<text x="110" y="270" fill="#8b98a5" font-size="10" text-anchor="middle">InfiniBand Fabric Health</text>
<text x="110" y="310" fill="#3fb950" font-size="10" font-weight="600" text-anchor="middle">Continuous Supercomputing</text>
</g>
<text x="380" y="452" fill="#6b7684" font-size="11" text-anchor="middle">Hardware Resource Planning & FLOP Budget Allocation for Next-Generation Foundation Model Clusters</text>
</svg>
Selection and practical application. Use scaling laws for budget allocation and pilot planning, direct ablations for architecture choices, data studies when quality is changing, and end-to-end cost models when inference volume, latency, or energy dominates training-optimal design. Model-roadmap planning, dataset sizing, cluster procurement, experiment triage, sparse-model design, context expansion, post-training budgets, inference optimization, and AI hardware forecasting use scaling laws. A scaling law connects empirical learning curves to data pipelines, model architecture, distributed training, semiconductor supply, datacenter infrastructure, evaluation, serving economics, safety, and business decisions. The useful optimization boundary is the complete model-serving product. Improving loss, benchmark accuracy, tokens per second, compression ratio, or accelerator utilization can move the bottleneck or weaken robustness, fairness, security, recoverability, and user value elsewhere, so qualification follows representative workflows from source data through production outcomes. A production definition names the model family and release, parameter and active-parameter scale, vocabulary, context window, data cutoff and provenance, objective, precision, adaptation method, decoding policy, serving stack, target hardware, safety controls, evaluation protocol, and known limitations. Labels such as large, frontier, open, multimodal, efficient, or state of the art are not specifications; results must identify the exact artifact, prompt template, sampling settings, software version, hardware, and measurement date. Evaluation combines task quality with calibration, robustness, subgroup behavior, contamination resistance, factuality, safety, privacy, memorization, latency to first token, inter-token latency, throughput, concurrency, memory capacity and bandwidth, accelerator utilization, energy per useful output, availability, and cost. Means alone conceal tail behavior, prompt sensitivity, evaluator uncertainty, and failures on rare but consequential cases. CFS connects this topic to semiconductor architecture, implementation, verification, manufacturing, packaging, test, and deployed AI-system tradeoffs across the platform.
Explore 500+ Semiconductor & AI Topics
From EUV lithography to CUDA optimization — search the full knowledge base or chat with our AI assistant.