Training Compute-Optimal Large Language Models
Anonymous Author(s)
AfﬁliationAddress email
Abstract
We investigate the optimal model size and number of tokens for training a Transformer language model under a given compute budget.
We ﬁnd that current largelanguage models are signiﬁcantly undertrained, a consequence of the recent focuson scaling language models whilst keeping the amount of training data constant.
By training over 400 language models ranging from 70 million to over 16 billionparameters on 5 to 500 billion tokens, we ﬁnd that for compute-optimal training,the model size and the number of training tokens should be scaled equally: forevery doubling of model size the number of training tokens should also be doubled.
We test this hypothesis by training a predicted compute-optimal model, Chinchilla , that uses the same compute budget as Gopher but with 70B parameters and4 ⇥ more more data.
Chinchilla uniformly and signiﬁcantly outperforms Gopher(280B), GPT-3 (175B), Jurassic-1 (178B), and Megatron-Turing NLG (530B) ona large range of downstream evaluation tasks.
This also means that Chinchillauses substantially less compute for ﬁne-tuning and inference, greatly facilitatingdownstream usage.
As a highlight, Chinchilla reaches a state-of-the-art averageaccuracy of 67.5% on the MMLU benchmark, greater than a 7% improvement over
Gopher .
Introduction
A series of Large Language Models (LLMs) have recently been introduced [7, 31, 39, 50, 53], with thelargest dense language models now having over 500 billion parameters.
These large autoregressivetransformers [54] have demonstrated impressive performance on many tasks using a variety ofevaluation protocols: zero-shot generalization, few-shot training and as a basis for ﬁne-tuning.
Thecompute and energy cost for training large language models is substantial [39, 53] and rises withincreasing model size.
In practice, the allocated training compute budget is often known in advance:practitioners have access to a certain number of accelerators for a given period of time.
Since itis typically only feasible to train these large models once, accurately estimating the best modelhyperparameters for a given compute budget is critical [52].
Kaplan et al.
[24] showed that there is a power law relationship between the number of parametersin an autoregressive language model (LM) and its performance (measured in evaluation perplexity).
One notable conclusion in [24] is that large models should not be trained to their lowest possible lossto be compute optimal; they argue that model size should grow faster than the size of the trainingset for a given increase of computational budget.
As a result, the ﬁeld has been training larger andlarger models while keeping the size of the training set to approximately 300 billion tokens, expectingperformance improvements (Table 1).
While we ﬁnd that there is effectively a trade-off betweenmodel size and training set size, we estimate that large models should be trained for many more be substantially smaller currently
Figure we the with the predicted optimal plotted the optimal
Chinchilla outperforms Gopher and the other large models (see Section 4.2)
[Table]
training tokens than recommended by [24].
Speciﬁcally, given a 10 ⇥ increase computational budgetwe ﬁnd that model size and the number of training tokens should be scaled in equal proportions.
In this work, we revisit the question: Given a ﬁxed FLOPs budget, 1 how should one trade-off modelsize and the number of training tokens?
To answer this question, we model the ﬁnal pre-trainingloss 2 L ( N, D ) as a function of the number of model parameters N , and the number of trainingtokens, D .
Since the computational budget C is a deterministic function FLOPs ( N, D ) of the numberof seen training tokens and model parameters, we are interested in minimizing L under the constraint
FLOPs ( N, D ) = C :
[Equation]
The functions N opt ( C ) , and D opt ( C ) describe the optimal allocation of a computational budget C .
We empirically estimate these functions based on the losses of over 400 models, ranging from under70 M to over 16 B parameters, and trained on 5 B to over 400 B tokens – with each model conﬁgurationtrained for several different training horizons.
Our approach leads to considerably different resultsthan that of [24].
We highlight our results in Figure 1 and how our approaches differ in Section 2.
Based on our estimated compute-optimal frontier, we predict that for the compute budget used totrain Gopher , an optimal model should be 4 times smaller, while being training on 4 times moretokens.
We verify this by training a more compute-optimal 70B model, called Chinchilla , on 1.4trillion tokens.
Not only does Chinchilla outperform its much larger counterpart, Gopher , but its reduced model size reduces inference cost considerably and greatly facilitates downstream uses onsmaller hardware.
The energy cost of a large language model is amortized through its usage forinference and ﬁne-tuning.
The beneﬁts of a more optimally trained smaller model, therefore, extendbeyond the immediate beneﬁts of its improved performance.
Related Work
Large language models.
A variety of large language models have been introduced in the last fewyears.
These include both dense transformer models [7, 31, 50, 39, 53] and mixture-of-expert (MoE)models [12, 13, 61].
The largest dense transformers have passed 500 billion parameters [50, 9].
Thedrive to train larger and larger models is clear—so far increasing the size of language models has beenresponsible for improving the state-of-the-art in many language modelling tasks.
Nonetheless, largelanguage models face several challenges, including their overwhelming computational requirements(the cost of training and inference increase with model size) [39, 53] and the need for acquiring morehigh-quality training data.
In fact, in this work we ﬁnd that larger, high quality datasets will play a keyrole in any further scaling of language models.
Concurrent to our work, a 540 billion parameter modeltrained on 768 billion tokens was released– PaLM [9].
While this model outperforms Chinchilla , ituses approximately 5 ⇥ the compute and is nearly 8 ⇥ larger, making it more difﬁcult to use.
Modelling the scaling behavior.
Understanding the scaling behaviour of language models and theirtransfer properties has been important in the development of recent large models [24, 19].
Kaplanet al.
[24] ﬁrst showed a predictable relationship between model size and loss over many orders ofmagnitude.
The authors investigate the question of choosing the optimal model size to train for agiven compute budget.
Similar to us, they address this question by training various models.
Ourwork differs from Kaplan et al.
[24] in several important ways.
First, the authors use a ﬁxed numberof training tokens and learning rate schedule for all models; this prevents them from modelling theimpact of these hyperparameters on the loss.
In contrast, we ﬁnd that setting the learning rate scheduleto approximately match the number of training tokens results in the best ﬁnal loss regardless of modelsize—see Figure A1.
For a ﬁxed learning rate cosine schedule to 130B tokens, the intermediate lossestimates (for D 0 << 130 B) are therefore overestimates of the loss of a model trained with a schedulelength matching D 0 .
Using these intermediate losses results in underestimating the effectivenessof training models on less data than 130B tokens, and eventually contributes to the conclusion thatmodel size should increase faster than training data size as compute budget increases.
In contrast, ouranalysis predicts that both quantities should scale at roughly the same rate.
Secondly, we includemodels with up to 16B parameters, as we observe that there is slight curvature in the FLOP-lossfrontier (see Appendix E)—in fact, the majority of the models used in our analysis have more than500 million parameters, in contrast the majority of runs in [24] are signiﬁcantly smaller—many beingless than 100M parameters.
Clark et al.
[10] speciﬁcally looked in to the scaling properties of Mixtureof Expert language models, showing that the scaling with number of experts diminishes as the modelsize increases—their approach models the loss as a function of two variables: the model size andthe number of experts.
However, the analysis is done with a ﬁxed number of tokens, potentiallyunderestimating the improvements of branching.
Estimating hyperparameters for large models.
The model size and the number of training tokensare not the only two parameters to chose when selecting a language model and a procedure to trainit.
Other important factors include learning rate, learning rate schedule, batch size, optimiser, andwidth-to-depth ratio.
In this work, we focus on model size and the number of training steps, andwe rely on existing work and provided experimental heuristics to determine the other necessaryhyperparameters.
Yang et al.
[58] investigates how to choose a variety of these parameters for trainingan autoregressive transformer, including the learning rate and batch size.
McCandlish et al.
[34] ﬁndsonly a weak dependence between optimal batch size and model size.
Shallue et al.
[48], Zhang et al.[60] suggest that using larger batch-sizes than those we use is possible.
Levine et al.
[29] investigatesthe optimal depth-to-width ratio for a variety of standard model sizes.
We use slightly less deepmodels than proposed as this translates to better wall-clock performance on our hardware.
Improved model architectures.
Recently, various promising alternatives to traditional densetransformers have been proposed.
For example, through the use of conditional computation large
MoE models like the 1.7 trillion parameter Switch transformer [13], the 1.2 Trillion parameter GLaM model [12], and others [1, 61] are able to provide a large effective model size despite using relativelyfewer training and inference FLOPs.
However, for very large models the computational beneﬁts ofrouted models seems to diminish [10].
An orthogonal approach to improving language models isto augment transformers with explicit retrieval mechanisms, as done by [5, 16, 30].
This approacheffectively increases the number of data tokens seen during training (by a factor of ⇠ 10 in [5]).
Thissuggests that the performance of language models may be more dependant on the size of the trainingdata than previously thought.
Estimating the optimal parameter/training tokens allocation
We present three different approaches to answer the question driving our research:
Given a ﬁxed
FLOPs budget, how should one trade-off model size and the number of training tokens?
In all threecases we start by training a range of models varying both model size and the number of trainingtokens and use the resulting training curves to ﬁt an empirical estimator of how they should scale.
Weassume a power-law relationship between compute and model size as done in [10, 24], though futurework may want to include potential curvature in this relationship for large model sizes.
The resultingpredictions are similar for all three methods and suggest that parameter count and number of trainingtokens should be increased equally with more compute —with proportions reported in Table 2.
Thisis in clear contrast to previous work on this topic and warrants further investigation.
3.1 Approach 1: Fix model sizes and vary number of training tokens
In our ﬁrst approach we vary the number of training steps for a ﬁxed family of models (rangingfrom 70M to over 10B parameters), training each model for 4 different number of training sequences.
From these runs, we are able to directly extract an estimate of the minimum loss achieved for a givennumber of training FLOPs.
Training details for this approach can be found in Appendix D.
For each parameter count N we train 4 different models: each uses a different horizon (measured innumber of training tokens) over which we decay the learning rate by a factor of 10 ⇥ ; the range ofhorizons varies by a factor of 16 ⇥ for each parameter count.
We smooth and linearly interpolate eachtraining loss curve.
From this, we obtain a continuous mapping from FLOP count to training loss foreach run.
We then determine which run achieves the lowest loss for each FLOP count.
Using theseinterpolants, we obtain a mapping from FLOP count C to the most efﬁcient choice of model size N optand number of training tokens D opt such that FLOPs ( N opt , D opt ) =
C .
We apply this mapping ontologarithmically spaced values of C and obtain many empirical triplets ( C i , N opt,i , D opt,i ) i .
Finally,we ﬁt power laws to these empirical data, estimating a and b such that N opt / C a and D opt / C b .
We ﬁnd that a = 0 .
50 and b = 0 .
50 —as summarized in Table 2.
We perform a simple experiment forearly validating our analysis: given a budget of 10 21 FLOPs, we compare the performance of training a model with a size recommended by our analysis to training a model with a size suggested by theanalysis of [24]—using the model size we predict has a clear advantage (Section D.4).
3.2 Approach 2: IsoFLOP proﬁles
In our second approach we vary the model size for a ﬁxed set of 9 different training FLOP counts(ranging from 6 ⇥ 10 18 to 3 ⇥ 10 21 FLOPs), and consider the ﬁnal training loss for each point.
Thisdiffers from the ﬁrst approach that considers points ( N i , D i , L i ) i along the entire training runs; thedata points are here scarcer but more representative of the performance of a fully trained model.
For each FLOP budget, we plot the ﬁnal loss (after smoothing) against the parameter count in Figure 3(left).
In all cases, we ensure that we have trained a diverse enough set of model sizes to see a clearminimum in the loss.
We ﬁt a parabola to each IsoFLOPs curve to directly estimate at what modelsize the minimum loss is achieved (Figure 3 (left)).
As with the previous approach, we then ﬁt apower law between FLOPs and loss-optimal model size and number of training tokens, shown in
Figure 3 (center, right).
Again, we ﬁt exponents of the form N opt / C a and D opt / C b and we ﬁndthat a = 0 .
49 and b = 0 .
51 —as summarized in Table 2.
3.3 Approach 3: Fitting a parametric loss function
Lastly, we model all ﬁnal losses from experiments in Approach 1 & 2 as a parametric function ofmodel parameter count and the number of seen tokens.
Following a classical risk decomposition (see
Section D.2)
, we propose the following functional form
[Equation]
The ﬁrst term captures the loss for an ideal generative process on the data distribution, and shouldcorrespond to the entropy of natural text.
The second term captures the fact that a perfectly trainedtransformer with N parameters underperforms the ideal generative process.
The ﬁnal term capturesthe fact that the transformer is not trained to convergence, as we only make a ﬁnite number ofoptimisation steps, on a sample of the dataset distribution.
Model ﬁtting.
To estimate ( A, B, E, ↵ ,  ) , we minimize the Huber loss [20] between the predictedand observed log loss using the L-BFGS algorithm [37]:
[Equation]
We account for possible local minima by selecting the best ﬁt from a grid of initialisations.
The
Huber loss (  = 10  3 ) is robust to outliers, which we ﬁnd important for good predictive performanceover held-out data points.
Section D.2 details the ﬁtting procedure and the loss decomposition.
Approach
[Table]
1. Minimum over training curves
[Table]
2. IsoFLOP proﬁles
[Table]
3. Parametric modelling of the loss
[Table]
Kaplan et al.
[Table] [Table]
Efﬁcient frontier.
We approximate the functions N opt and D opt by minimizing the parametricloss ˆ L under the constraint FLOPs ( N, D ) ⇡ 6 ND [24].
The resulting N opt and D opt balancethe two terms in Equation (3) that depend on model size and data.
By construction, they have apower-law form.
We show contours of the ﬁtted function ˆ L in Figure 4 (left), and the closed-formefﬁcient computational frontier in blue.
From this approach, we ﬁnd that a = 0 .
46 and b = 0 .
54 —assummarized in Table 2.
3.4 Optimal model scaling
We ﬁnd that the three approaches, despite using different ﬁtting methodologies and different trainedmodels, yield comparable predictions for the optimal scaling in parameters and tokens with FLOPs(shown in Table 2).
All three approaches suggest that as compute budget increases, model size andthe amount of training data should be increased in approximately equal proportions.
The ﬁrst andsecond approaches yield very similar predictions for optimal model sizes, as shown in Figure 1 and
Figure A3.
The third approach predicts even smaller models being optimal at larger compute budgets.
We note that the observed points ( L, N, D ) for low training FLOPs ( C  1 e 21 ) have larger residualsk L
ˆ L ( N, D ) k 2 2 than points with higher computational budgets.
The ﬁtted model places increasedweight on the points with more FLOPs—automatically considering the low-computational budgetpoints as outliers due to the Huber loss.
As a consequence of the empirically observed negativecurvature in the frontier C !
N opt (see Appendix E), this results in predicting a lower N opt than thetwo other approaches.
In Table A3 we show the estimated number of FLOPs and tokens that would ensure that a model of agiven size lies on the compute-optimal frontier.
Our ﬁndings suggests that the current generation oflarge language models are considerably over-sized, given their respective compute budgets, as shownin Figure 1.
Furthermore, the amount of training data that is projected to be needed is far beyondwhat is currently used to train large models, and underscores the importance of dataset collectionin addition to engineering improvements that allow for model scale.
While there is signiﬁcantuncertainty extrapolating out many orders of magnitude, our analysis clearly suggests that given thetraining compute budget for many current LLMs, smaller models should have been trained on moretokens to achieve the most performant model.
In Appendix C, we reproduce the IsoFLOP analysis ontwo additional datasets: C4 [41] and GitHub code [39].
In both cases we reach the similar conclusionthat model size and number of training tokens should be scaled in equal proportions.
Chinchilla
Based on our analysis in Section 3, the optimal model size for the Gopher compute budget issomewhere between 40 and 70 billion parameters.
We test this hypothesis by training a model on thelarger end of this range—70B parameters—for 1.4T tokens, due to both dataset and computationalefﬁciency considerations.
In this section we compare this model, which we call Chinchilla , to Gopherand other LLMs.
Both Chinchilla and Gopher have been trained for the same number of FLOPsbut differ in the size of the model and the number of training tokens.
While pre-training a largelanguage model has a considerable compute cost, downstream ﬁne-tuning and inference also makeup substantial compute usage [39].
Due to being 4 ⇥ smaller than Gopher , both the memory footprintand inference cost of Chinchilla are also smaller.
4.1 Model and training details
The full set of hyperparameters used to train Chinchilla are given in Table 3.
Chinchilla uses the samemodel architecture and training setup as Gopher with the exception of the differences listed below.
• We train Chinchilla on MassiveText (the same dataset as Gopher ) but use a slightly different
subset distribution (Table A1) to account for the increased number of training tokens.
[Table]
• We use AdamW [33] for Chinchilla rather than Adam [25] as this improves the language
modelling loss and the downstream task performance after ﬁnetuning.
• We train Chinchilla with a slightly modiﬁed SentencePiece [26] tokenizer that does notapply NFKC normalisation.
The vocabulary is very similar– 94.15% of tokens are the sameas those used for training Gopher .
We ﬁnd that this particularly helps with the representationof mathematics and chemistry, for example.
• Whilst the forward and backward pass are computed in bfloat16 , we store a float
copy of the weights in the distributed optimiser state [43].
See Lessons Learned from [39]
for additional details.
In Appendix G we show the impact of the various optimiser related changes between Chinchillaand Gopher .
All models in this analysis have been trained on TPUv3/TPUv
[23] with JAX [6] and
Haiku [18].
We include a Chinchilla model card [36] in Table A13.
[Table]
[Table] [Table]
4.2 Results
We perform an extensive evaluation of Chinchilla , comparing against various large language models.
We evaluate on a large subset of the tasks presented in [39], shown in Table A6.
As the focus of thiswork is on optimal model scaling, we included a large representative subset
[Table]
and introduce a few newevaluations to allow for better comparison to other existing large models.
The evaluation details forall tasks are the same as described in [39].
Language modelling.
Chinchilla signiﬁcantly outperforms Gopher on all evaluation subsets of The
Pile [14], as shown in Figure A8.
Compared to Jurassic-1 (178B) [31], Chinchilla is more performanton all but two subsets– dm_mathematics and ubuntu_irc – see Table A7 for a raw bits-per-bytecomparison.
On Wikitext103 [35], Chinchilla reaches 7.16 perplexity compared to 7.75 for Gopher .
MMLU.
The Massive Multitask Language Understanding (MMLU) benchmark [17] consists of arange of exam-like questions on academic subjects.
In Table A8, we report Chinchilla ’s average 5shot performance on MMLU (the full breakdown of results is shown in Table A9).
On this benchmark,
Chinchilla signiﬁcantly outperforms Gopher despite being much smaller, with an average accuracyof 67.6% (improving upon Gopher by 7.6%).
Remarkably, Chinchilla even outperforms the expertforecast for June 2023 of 63.4% accuracy (see Table A8)
Furthermore, Chinchilla achievesgreater than 90% accuracy on 4 different individual tasks– high_school_gov_and_politics,international_law, sociology , and us_foreign_policy .
To our knowledge, no other modelhas achieved greater than 90% accuracy on a subset.
In Figure A9, we show a comparison to Gopherbroken down by task.
Reading comprehension.
On the ﬁnal word prediction dataset LAMBADA [38], Chinchilla achieves77.4% accuracy, compared to 74.5% accuracy from Gopher and 76.6% from MT-NLG 530B (see
Table 4).
On RACE-h and RACE-m [28], Chinchilla greatly outperforms Gopher , improving accuracyby more than 10% in both cases—see Table 4.
BIG-bench.
We analysed Chinchilla on the same set of BIG-bench tasks [3] reported in [39].
Similarto what we observed in MMLU, Chinchilla outperforms Gopher on the vast majority of tasks (see
Figure A10).
We ﬁnd that Chinchilla improves the average performance by 10.7%, reaching anaccuracy of 65.1% versus 54.4% for Gopher .
Full accuracy results can be found in Table A10.
Common sense.
We evaluate Chinchilla on various common sense benchmarks: PIQA [4], SIQA[47], Winogrande [46], HellaSwag [59], and BoolQ [11].
We ﬁnd that Chinchilla outperforms both
Gopher and GPT-3 on all tasks and outperforms MT-NLG 530B on all but one task—see Table 5.
On TruthfulQA [32], Chinchilla reaches 43.6%, 58.5%, and 66.7% accuracy with 0-shot, 5-shot,and 10-shot respectively.
In comparison, Gopher achieved only 29.5% 0-shot and 43.7% 10-shotaccuracy.
In stark contrast with the ﬁndings of [32], the large improvements (14.1% in 0-shotaccuracy) achieved by Chinchilla suggest that better modelling of the pre-training data alone can leadto substantial improvements on this benchmark.
Closed-book question answering.
Results on closed-book question answering benchmarks arereported in Table A11.
On the Natural Questions dataset [27], Chinchilla achieves new closed-book
SOTA accuracies: 31.5% 5-shot and 35.5% 64-shot, compared to 21% and 28% respectively, for
Gopher .
On TriviaQA [22] we show results for both the ﬁltered (previously used in retrieval and openbook work) and unﬁltered set (previously used in large language model evaluations).
In both cases,
Chinchilla substantially out performs Gopher .
On the ﬁltered version, Chinchilla lags behind theopen book SOTA [21] by 7.9%.
On the unﬁltered set, Chinchilla outperforms GPT-3 (see Table A11).
Discussion & Conclusion
The trend so far in large language model training has been to increase the model size, often withoutincreasing the number of training tokens.
The largest dense transformer, MT-NLG 530B, is nowover 3 ⇥ larger than GPT-3’s 170 billion parameters from just two years ago.
However, this model,as well as the majority of existing large models, have all been trained for a comparable numberof tokens—around 300 billion.
While the desire to train these mega-models has led to substantialengineering innovation, we hypothesize that the race to train larger and larger models is resulting inmodels that are substantially underperforming compared to what could be achieved with the samecompute budget.
We propose three predictive approaches towards optimally setting model size and training duration,based on the outcome of over 400 training runs.
All three approaches predict that Gopher issubstantially over-sized and estimate that for the same compute budget a smaller model trained onmore data will perform better.
We directly test this hypothesis by training Chinchilla , a 70B parametermodel, and show that it outperforms Gopher and even larger models on nearly every measuredevaluation task.
Whilst our method allows us to make predictions on how to scale large models when given additionalcompute, there are several limitations.
Due to the cost of training large models, we only have twocomparable training runs at large scale ( Chinchilla and Gopher ), and we do not have additionaltests at intermediate scales.
Furthermore, we assume that the efﬁcient computational frontier canbe described by a power-law relationship between the compute budget, model size, and number oftraining tokens.
However, we observe some concavity in log ( N opt ) at high compute budgets (see
Appendix E).
This suggests that we may still be overestimating the optimal size of large models.
Finally, the training runs for our analysis have all been trained on less than an epoch of data; futurework may consider the multiple epoch regime.
Despite these limitations, the comparison of Chinchillato Gopher validates our performance predictions, that have thus enabled training a better (and morelightweight) model at the same compute budget.
Though there has been signiﬁcant recent work allowing larger and larger models to be trained, ouranalysis suggests an increased focus on dataset scaling is needed.
Speculatively, we expect thatscaling to larger and larger datasets is only beneﬁcial when the data is high-quality.
This calls forresponsibly collecting larger datasets with a high focus on dataset quality.
Larger datasets will requireextra care to ensure train-test set overlap is properly accounted for, both in the language modellingloss but also with downstream tasks.
Finally, training for trillions of tokens introduces many ethicaland privacy concerns.
Large datasets scraped from the web will contain toxic language, biases, andprivate information.
With even larger datasets being used, the quantity (if not the frequency) of suchinformation increases, which makes dataset introspection all the more important.
Chinchilla doessuffer from bias and toxicity but interestingly it seems less affected than Gopher (see Appendix I)..
Better understanding how performance of large language models and toxicity interact is an importantfuture research question.
While we have applied our methodology towards the training of auto-regressive language models, weexpect that there is a similar trade-off between model size and the amount of data in other modalities.
As training large models is very expensive, choosing the optimal model size and training stepsbeforehand is essential.
The methods we propose are easy to reproduce in new settings.
Checklist
The checklist follows the references.
Please read the checklist guidelines carefully for information onhow to answer these questions.
For each question, change the default [TODO] to [Yes] , [No] , or[N/A] .
You are strongly encouraged to include a justiﬁcation to your answer , either by referencingthe appropriate section of your paper or providing a brief inline description.
For example:
• Did you include the license to the code and datasets?
[No] The code and the data are
proprietary.
Please do not modify the questions and only use the provided macros for your answers.
Note that the
Checklist section does not count towards the page limit.
In your paper, please delete this instructionsblock and only keep the Checklist section heading above along with the questions/answers below.
For all authors...
(a) Do the main claims made in the abstract and introduction accurately reﬂect the paper’s
contributions and scope?
[Yes] The claims in the abstract describe the work clearly.
(b) Did you describe the limitations of your work?
[Yes] We address limitations of our
work.
(c)
Did you discuss any potential negative societal impacts of your work?
[Yes] We have adiscussion both in a model card and in Appendix I.
(d) Have you
read the ethics review guidelines and ensured that your paper conforms tothem
[Yes
If you are including theoretical results...
(a) Did you state the full set of assumptions of all theoretical results?
[N/A] Results are
not theoretical.
b) Did you include complete proofs of all theoretical results?
[N/A] Results are not
theoretical/no proofs.
If you ran experiments...
a) Did you include the code, data, and instructions needed to reproduce the main ex-
perimental
results (either in the supplemental material or as a URL)?
[No] The code
and the data are proprietary.
However, for the scaling methodology we provide clear
instructions
on how to reproduce the results.
b) Did you specify all the training details (e.g., data
splits,
hyperparameters, how they
were
chosen)?
[Yes] We provided all training details and hyperparameters.
c
) Did
you
report error bars (
e
.g.
with
respect to the random seed after running experiments multiple times)
[No] Due
to the cost of training large models,
we
do
not havemultiple runs.
However, the clear & predictable trends suggest the noise is very small.(d)
Did you include the total amount of compute and the type of resources used (e.
g
.,type of GPUs, internal cluster, or cloud provider)
Yes
] All experiments are ran on
TPUv3/
TPUv
and this is stated in the text.4.
If you are using existing assets (e.g., code, data, models) or curating/releasing new assets...(
a)
If your work uses existing assets, did you cite the creators?
[Yes] We cite the preexistingwork for all data/models that we use.
b) Did
you
mention
the license of the assets?
[Yes] We use the same data as in Rae et al.[39] which uses a proprietary dataset.
We also show results with an open source dataset–
C4 Raffel et al.
c) Did you include any new assets either in the
supplemental material
or as a
URL
[N/A]
We
do not introduce new
assets.
(d) Did you discuss whether and how consent was obtained from people whose data you’re
using/curating?
[Yes]
(e) Did you discuss whether the data you are using/curating contains personally identiﬁable
information or offensive content?
[Yes] We include a model card which includes this
information.
If you used crowdsourcing or conducted research with human subjects...
(a) Did you include the full text of instructions given to participants and screenshots, if
applicable?
[N/A]
There was no human subjects or crowd sourcing in this work.
(b) Did you describe any potential participant risks, with links to Institutional Review
Board (IRB) approvals, if applicable?
[N/A]
There was no human subjects or crowd
sourcing in this work.
(c) Did you include the estimated hourly wage paid to participants and the total amount
spent on participant compensation?
[N/A]
There was no human subjects or crowd
sourcing in this work.