Inclusion

The database covers AI models, especially models that are notable for advancing the state of the art, or a large impact on the world or the history of the field. Here, we give an overview of how the data have been collected, and define the criteria for inclusion and notability.

Criteria

To be included in the database, an ML model must satisfyall inclusion criteria:

• there must be reliable documentation of its existence and relevance to machine learning;
• the model must include a learning component, it cannot be a non-learned algorithm;
• the model must actually have been trained, it cannot be a theoretical description without experimental results.

Notability

Once added to the database, models are marked as notable if they satisfyany of the following:

• highly cited (over 5000 citations);
• large training cost (over $1,000,000, measured in 2023 USD, or at least 1% the cost of the most expensive model trained to date, whichever is greater);
• significant use (over one million monthly active users);
• state of the art performance (typically on a recognised benchmark, see details below);
• an equivalent level of historical significance,
• notability at least as great as the criteria above, identified at the discretion of Epoch staff.

Where there are many related models, for example several checkpoints along training or several sizes of a given model family, the database preferentially includes the version that used the most compute. Other versions may be included where they are notable in their own right.

State of the art

Identifying whether a model is state-of-the-art can be a more involved process, compared to simply checking citations or the training compute budget. We consider a model to be state of the art if there is good reason to believe that it was the best existing model at the time for a task of genuine interest. The default way to provide evidence for this is state-of-the-art performance on a recognised benchmark.

To be recognised, a benchmark should haveany of the following:

• 100+ citations.
• 10+ submissions in total from 3+ research groups.
• An associated publication in a reputable peer-reviewed academic venue. The publication does not need to focus exclusively on the benchmark; however, the benchmark should be a key result.

At our discretion, we may also identify models as state of the art where no benchmark result exists, but there is convincing evidence that a model truly is state-of-the-art. Eligible sources of evidence here are comparison on a non-benchmark database, a high-quality user preference study, or demonstration of state of the art capabilities. For example, GraphCast is compared against other weather prediction models on a weather database that is not a standalone benchmark. Nevertheless, we take this as convincing evidence that it is state of the art.

Historical significance

Models can be included on the grounds of historical significance if they marked a significant advance in AI history, even if they did not strictly advance the state of the art on any application. For example, many neural network breakthroughs performed worse than other ML techniques, but were directly influential for later AI development. Evidence to support this status may come from citations in later notable models, discussion in reviews or textbooks, or other unambiguous identification as an influential result.

Discretionary identification

Models can be included at the discretion of Epoch staff if they are as notable as the other models identified but not covered by the categories above. For example, we may mark a model as notable if it is on the Pareto frontier of cost-efficiency for an important task despite not having the highest performance on a benchmark.

Search process

This dataset has been collected from a variety of sources: literature reviews, historical accounts of AI development, highly-cited publications from top conferences, high-profile models from leading industry labs, bibliographies of notable papers, pre-existing datasets curating AI papers (seeAcknowledgements), and ad hoc suggestions from contributors.

We monitor news coverage, releases from key AI labs, and benchmarks to identify new models as they are released. This can lead to a lag for new models. Typically, we aim to add the most prominent releases (e.g. GPT-4) within days of release. For less prominent models, reporting lags may extend to months.

Coverage

As of November 28, 2025, the dataset contains 3204 models, of which have compute estimates.

• Coverage is most thorough for language and vision models developed since 2018 (1637 models and 481 models respectively), albeit with a lag for the newest models. More specialized domains, such as audio generation, likely have worse coverage in this period.
• Coverage is fair, but less thorough, for deep learning language and vision models between 2010-2018 (106 models and 133 models respectively). Again, other domains may have worse coverage.
• Coverage is quite sparse for historical models before 2010 (152 models before 2010 compared to 3034 models after), particularly models outside the paradigm of deep learning. Entries here are focused on notable models mentioned in textbooks and reviews, rather than a systematic search across sources.

If you would like to ask any questions about the database, or suggest a model that should be added, contact us atdata@epoch.ai.

Records

The database focuses on information relevant to trends in AI model development. Records in the database have information about three broad areas:

Bibliographic information about the model and its associated publication, for example its title, URL, authors, citations, date, etc.

Training details such as training compute, parameters, dataset size, hardware used for training, etc.

Metadata about the record, such as notes on the above fields with supporting evidence and context, our confidence in the key models, etc.

Fields

We provide a comprehensive guide to the database’s fields below. This includes examples taken from Llama-2 70B, one of the best-documented recent models. If you would like to ask any questions about the database, or request a field that should be added, feel free to contact us atdata@epoch.ai.

Database Updates

This section provides more information about recurring processes in the database: adding new models, updating citation counts, and updating the hosted files by which the dataset can be accessed for analysis.

Adding new models

Entries are added to the dataset near-daily, including both newly-released models and older models newly identified as notable. Typically, most information that can easily be determined from public information is added at the time a model is entered in the database. However, it is common for some information to gradually be entered later. For example, a compute estimate might be omitted at first and only added after we devote further effort to calculating it.

If you would like to ask any questions about the database, or suggest a model that should be added, feel free to contact us atdata@epoch.ai.

Updating citation counts

When models are added to the database, citation counts are recorded for those with academic publications or preprints. At the beginning of each month, citation counts are automatically updated for publications listed in Semantic Scholar. Publications not listed in Semantic Scholar rely on manual entry of citation count.

Updating hosted files

Epoch AI’s database ishosted as a CSV that is synced with the database daily. The easiest way to load the data in scripts is using the CSV URL. If you need the most up-to-date version reflecting unsynced changes, a CSV can be manually generated from thetable view on the website.

Estimation

Some fields within the database require estimation, because they are often not straightforwardly reported within papers or other sources. Here, we detail how estimation works for compute, model size, dataset size, and the metadata on estimate confidence.

Estimating compute

Training compute is one of the most important pieces of information in our dataset, as reflected in its usage across Epoch AI’s research and elsewhere. However, estimating compute can be challenging. Here we outline how compute estimation is performed in the notable models dataset.

Compute is measured in units offloating point operations (FLOP). For older models, sometimes the relevant operations were integer operations - in this case we report these instead. We do not apply any multiplier to adjust for operations potentially being more valuable under different tensor formats or precisions, for example FP16 versus FP32 or BF16. Some sources report compute in multiplications-and-addition operations, fused multiply-adds (FMAs), or similar. We treat one multadd/FMA as being equivalent to two FLOP to match typical reporting of chip performance.

For a given model in the database, training compute is provided as thetotal training compute, including pretraining, and including pretrained base models used as components. Finetuning compute is recorded in its associated column. Finetuning is distinguished by authors’ descriptions of the training as finetuning, or unambiguous use of a pretrained model in a distinct phase of training.

In the simplest case, training compute is directly reported in a paper, and we enter this figure into the database. When compute is not reported, we use two main methods to estimate it:

1. Hardware details and usage.
2. Counting the operations based on model architecture and data.

When there is enough information to count the operations, this is preferred in our dataset, because typically hardware-based estimates require assumptions about utilization, which may reduce the estimates’ accuracy.

Hardware details and usage

Hardware details and usage is a relatively straightforward way to estimate compute, when the necessary details are known:

1. The usage in chip-time, e.g. “trained on a cluster of 128 TPUv3 instances for two days” means 256 chip-days = 128 chips × 2 days. Sometimes this is reported as separate chips and time used, other times this may be reported directly in chip-time. When it is not reported, we may create estimates from publicly-known information, comparison to typical training runs, etc.
2. The type of hardware used, e.g. NVIDIA H100, TPUv3. Ideally, this is reported in the paper. Otherwise, for more speculative estimates, one may have to make assumptions based on institution and year, e.g. that Google would have used TPUs of the corresponding generation in that year.
3. The type of number representation used, e.g. FP32, FP16, BF16. Ideally, this is reported in the paper. When not reported, it can often be guessed. For example, the number representation was typically FP32 for models trained before 2019.

Once these details are known, the corresponding peak FLOP/s performance by hardware and number representation can be found from hardware documentation, or from the tool below. Finally, utilization rates account for real training runs falling significantly short of peak performance due to memory bottlenecks, network latency, etc. Typical utilization rates for large distributed training runs are around 30-50%. When these are not reported, they are estimated by reference to comparable models from a similar time period.

Counting the operations

Counting the number of operations is often useful for older research, where hardware and usage details might be unavailable. The above formula sets out a widely-applicable heuristic for training compute of dense models. This works by first estimating required FLOP for a forward pass, which is approximately twice the number of connections. This can be modified by sparsity such as Mixture-of-Experts: in this case, the heuristic should use the number of connections in the number of active experts.

The forward pass FLOP is then multiplied by three to account for backward passes, as the ratio between forward and backward passes is 1:2 for non-recurrent dense models. Finally, this is multiplied by the number of passes performed on the data - the number of training examples multiplied by the number of epochs the model was trained. For transformer-based language models, this formula is equivalent to the commonly-used heuristic: Compute = 6 × # of parameters × # of training examples × # of epochs.

Sometimes, the FLOP for a forward pass is reported directly in a paper. In this case, this value can be used directly instead of 2 × # of connections. Otherwise, the FLOP for a forward pass are evaluated by summing FLOP over the network’s layers. These are set out in Table 3.

Benchmark performance

When details about model architecture, training data, hardware, and development time are scarce, it may be informative to compare the model’s performance on benchmarks to that of other models. Scaling laws can predict benchmark performance improvements against compute when scaling a given model family (for examplecoding performance for GPT-4 scaling andARC Challenge for Llama-3). When there are differences in model/data/training, benchmark performance is less predictable from compute, but neverthelessremains correlated.

This process of estimating training compute from benchmark performance can be improved by aggregating performance across many benchmarks, especially when several or many models with known training compute have been evaluated on those benchmarks.

The procedure is roughly as follows:

• Collect a dataset of many benchmarks (e.g. MMLU, GPQA, BigCodeBench) and models (e.g. Llama 3, Mistral Large, Nemotron 4) with known training compute and benchmark scores.
• For each benchmark, fit a curve that best matches the benchmark scores of each model as a function of their training compute.The curve-fitting procedure uses sigmoid functions, based on our studyHow Predictable is Language Model Benchmark Performance?
• Using the fitted curves, impute an x-value (training compute) from the y-values (benchmark scores) for models with unknown training compute. This represents the approximate training compute necessary to achieve the benchmark scores demonstrated by those models.
  • The resulting estimates are cross-validated to ensure that the fitted values are reasonable even if some benchmark evaluation datapoints are held out.
• If applicable, combine any other information about the compute resources available to the developers with the evidence from the benchmarks, to obtain overall estimates of the compute used to train the models.
• It may be helpful to constrain fitting to models with the most similar algorithmic efficiency. For example, when using this approach to collect information on leading LLMs from 2024, we constrained fitting to models with algorithmic efficiency similar to, or better than, the Llama 3 family.

This process is demonstrated in a public Colab notebook,Compute Estimation from Benchmark Scores. Because these compute estimates are already based on benchmark performance, they should be excluded from analyses of the relationship between benchmarks and compute. Such compute estimates can be filtered using the Training compute estimation method field.

Estimating model size

Parameter counts are often reported by the model developer, but if parameter count is not stated, it can sometimes be estimated based on provided architectural details. Similar to estimating compute, estimating parameter count requires finding a description of the architecture, i.e. type, number, and configuration of the layers, then calculating the parameters in each layer and summing them. Table 5 lists the parameter counts for different layers. Alternatively, if an architecture implementation is available in code, it can be simpler to load an architecture in code and count the number of parameters.

Estimating power draw

The field “Training power draw (W)” contains the power draw of the hardware used to train the model, measured in watts. This field is filled in when the training hardware type and quantity are known, and is calculated as follows:

where:

From 2009 onwards, PUE decays exponentially at a rate of ln(1.08/1.23)/16 ≈ 0.8% per year.

The value is based on thePublication date of the model.

This formula calculates the power per chip times the number of chips to get the peak power draw of the computing hardware, and then adjusts for the server hardware needed to connect the processors, and the power usage efficiency of the facility containing the hardware.

The server overhead factor represents the power consumption of server hardware that is needed to connect multiple GPUs or TPUs to use them on the same computing task.

The value is derived from theNVIDIA DGX H100 server, comparing the power consumption of the server with GPUs to that of the GPUs alone: 10.2 kW server power consumption / (8 * 700 W H100 TDP) ≈ 1.82.

This server is chosen because it is the most typical hardware, representative of hardware used for modern notable machine learning model training. As of May 2025, the geometric mean server power overhead for hardware used to train models identified in Epoch’s AI models dataset (weighted by number of notable models trained using each hardware type) was 1.79, very similar to the overhead of the DGX H100 server. The H100 also makes up the majority of total training compute of notable models in Epoch’s AI models dataset and the majority of the installed AI cluster compute capacity in Epoch’s AI supercomputers dataset; Hopper chips including the H100 constitute the majority ofNVIDIA AI chip compute stock as of EOY 2024.

Thepower usage efficiency factor is the ratio of energy consumed by a data center facility to the power delivered to computing equipment, and represents the additional energy overhead required to run processors and servers due to cooling and other non-computing power consumption. We select values of 1.23 in 2008 and before, 1.08 in 2025, and exponentially decaying at a rate of ln(1.08/1.23)/16 ≈ 0.8% per year from 2009 onwards, based onGoogle’s datacenter efficiency disclosures. Other hyperscalers,such as Meta, have similar datacenter efficiency. Non-AI datacenters tend to have lower efficiency, but the industry averagefollows a similar trend.

Estimating numerical format

To facilitate data collection, we utilize a LLM-based categorization pipeline. On a validation set of 192 models, the error rate was 4%. Seehere for methodological details.

Estimating confidence

As discussed inRecords, the confidence statuses specify the following bounds as 90% confidence intervals:

• Confident - ±3x (~0.5 orders of magnitude).
• Likely - ±10x (1 order of magnitude).
• Speculative - ±31x ( ~1.5 orders of magnitude).

Confidence applies to the recorded values forTraining compute,Parameters, andTraining dataset size. It describes confidence for themost uncertain of these values, for the ones that have a non-empty entry.

To estimate confidence statuses, we consider which parts of an estimate are uncertain, and how large the uncertainty is.

• If details (compute, model size, and dataset size) are all directly reported, then the value isConfident. There is little room for error.
• If a detail is estimated without any assumptions having to be made, then the value isConfident. For example, if hardware type, quantity, training time, number format, and utilization are all reported, then the ensuing compute estimate is unambiguous.
• When details are ambiguous, and an assumption has to be made, we consider the uncertainty in that assumption.
• For example, it is often necessary to estimate utilization when estimating training compute from hardware details. Given the typical language modeling range is 0.3-0.5, this estimate should fall within theConfident category.
• Further ambiguity may move estimates into theLikely category. For example, MedBERT was trained for one week using one V100 GPU, but the authors do not report the arithmetic precision or usage of tensor cores during training, which could affect the compute usage by a factor of 4x.
• Finally, some estimates are based almost entirely on credible ranges for (unreported) key parameters such as training time and hardware. These typically fall into theSpeculative category. An example of this is GPT-4, where our compute estimate is based on secondhand reporting that lets us roughly estimate training duration and hardware.

Changelog

2024-06-19

The documentation was updated for the launch of the database on Epoch AI’s “Data on AI” webpage.

• Updates particularly affected sections on estimating compute, parameters, and dataset sizes
• The confidence field was updated to be defined in terms of 90% confidence intervals for estimated values.
• The documentation was restructured for clarity.

2025-05-02

Presentation of the dataset was improved in table view. Documentation was clarified for several fields.

• Column order was changed to present parameter count, training compute, and training data near the left of the table, to reduce scrolling.
• The inclusion criterion for the frontier model indicator was clarified.
• The formula for training power draw was updated to account for models trained before modern datacenters.

2025-07-22

Documentation was updated to expand its scope. This documentation now covers all machine learning models recorded by Epoch AI. (Previously, only notable models were documented.)

Downloads

We offer four downloads from the AI Models dataset.Notable AI models are those that meet our notability criteria, and are the subset we recommend for data analysis.Frontier models are models that were in the top 10 of training compute as of the time of their release.Large-scale models are models trained with at least 10²³ floating-point operations.All models shows every model in the dataset, including models that do not qualify for the above categories.

Notable AI Models

CSV, Updated November 26, 2025

Frontier AI Models

CSV, Updated November 28, 2025

Large-scale AI Models

CSV, Updated November 10, 2025

All AI Models

CSV, Updated November 28, 2025

Acknowledgements

We would like to thank the authors of several sources where we have found one or more ML models to include in the database: Stanford CRFM’sfoundation model ecosystem graph,AI Tracker, Stella Biderman’sdirectory of LLMs, Terry Um’srepo of deep learning papers, Alan Thompson’smodels table, the OpenCompassChinese LM leaderboard, theAkronomikon by LightOn AI,Papers With Code, the Metaculus2022 AI Forecasting Database,Hugging Face, andBiology + AI Daily Papers. We would also like to thank the authors ofAI and compute andCompute and Energy Consumption Trends in Deep Learning Inference.

The data have been collected by Epoch AI’s employees and collaborators, including Jaime Sevilla, Pablo Villalobos, Juan Felipe Cerón, Matthew Burtell, Lennart Heim, Amogh B. Nanjajjar, Tilman Rauker, Nuño Sempere, Max Rauker, Anson Ho, Tamay Besiroglu, Marius Hobbhahn, Jean-Stanislas Denain, Owen Dudney, David Atkinson, Ben Cottier, David Owen, Robi Rahman, Carl Guo, Josh You, Nicole Maug, Aidan O’Gara, Bartosz Podkanowicz, Luke Frymire, Natalia Martemianova, Lovis Heindrich, James Sanders, David Atanasov, Veronika Blablova, Amy Ngo, John Croxton, and Yafah Edelman.

This documentation was written by David Owen and Robi Rahman. Material on estimating compute, parameters and dataset sizes was adapted from previous documents by Jaime Sevilla, Lennart Heim, Marius Hobbhahn, Tamay Besiroglu, Anson Ho, Pablo Villalobos, and Robi Rahman.