1. A map of efficiency (the short version)

• Each approach shrinks something different: MoE shrinks the compute and weight reads per token, quantization shrinks the bytes per parameter, and distillation and pruning shrink the size of the model itself (with retraining) (our organization).
• MoE "loads everything and uses part": gpt-oss-120b has 116.83B total parameters of which 5.13B are active per token. The official sources say that putting most of the weights (the MoE part, over 90%) in MXFP4 (4.25 bits per parameter) lets it fit on a single 80GB GPUSourced[Ref. 9, 10].
• The accuracy price is conditional: A study that ran more than 500,000 evaluations across the whole Llama-3.1 family reports that FP8 is effectively lossless, well-tuned INT8 loses 1 to 3%, and 4-bit weight-only quantization can rival 8-bitSourced[Ref. 21]. This is a result for one model series and one evaluation setup.

2. Mixture of experts (MoE) — total and active parameters

(1) How it works

MoE splits the feed-forward network (FFN) of each Transformer layer into several "experts", and a router (gate) picks a few of them for each token. Shazeer and colleagues made conditional computation (running only part of the network per input) practical, showed that model capacity can be raised by more than 1000 times with little loss of computational efficiency, and reported an MoE of up to 137 billion parameters applied between stacked LSTM layersSourced[Ref. 1]. Mixtral 8x7B has eight FFN blocks (experts) per layer and picks two per token; the paper says each token has access to 47B parameters but uses only 13B active parameters in inference [Ref. 2].

View original SVG, values and source annotations

(2) Total and active parameters of main models

Fig. 3 gathers the values confirmed in official sources. Even for "active", the way of counting (embeddings, shared experts, output-side matrices) differs by provider. For example, the gpt-oss model card notes that the unembedding is counted toward active and the input embedding is not [Ref. 9]. The "E" in Gemma 4's "E2B" and "E4B" stands for "effective" parameters: each layer has its own small embedding (Per-Layer Embeddings), and the large embedding tables are used only for lookups, so the effective parameter count is much smaller than the total [Ref. 14]Sourced.

All Sourced (papers, official model cards, config.json; checked 15 October 2026). How "active" is counted differs by provider.

(3) How it affects memory and speed

The advantage of MoE is that the compute and weight reads for one token amount to just the active parameters. The DeepSeek-V3 technical report says that it adopts MLA and DeepSeekMoE for efficient inference and economical training, and that pre-training on 14.8 trillion tokens required 2.788 million H800 GPU hours [Ref. 3]. The Qwen3 technical report says that Qwen3's MoE base models can reach comparable performance even with one-tenth of the active parameters of the Qwen2.5 dense base model, with significant advantages in inference and training cost [Ref. 6]Sourced (the developer's evaluation). On the other hand, the amount you must hold in memory is set by the total parameters. The weights of all experts must be placed in GPU memory (or across several GPUs), and gpt-oss-120b fits on a single 80GB GPU because its MoE part is in MXFP4 [Ref. 9]. Also, when the batch grows, different tokens select different experts and the number of experts read in one step increases, so the MoE advantage is not as large as the batch-1 estimate suggests (our commentary; see the estimate in Chapter 7).

3. Knowledge distillation — moving a large model's knowledge into a small one

(1) The principle and a classic example

Hinton and colleagues' distillation develops a way of compressing the knowledge of a large model, or of an ensemble of models, into a single small model that is easier to deploy [Ref. 11]. DistilBERT uses distillation at the pre-training stage and reports reducing the size of BERT by 40% and making it 60% faster while retaining 97% of its language-understanding capabilitySourced[Ref. 12].

(2) How it is used in recent models

• Gemma 2: says it trained the 2B and 9B models with knowledge distillation instead of next-token prediction [Ref. 13].
• Qwen3: uses "strong-to-weak distillation" from large models to lightweight models, and in a comparison on Qwen3-8B reports that on-policy distillation achieved significantly better performance than reinforcement learning with about one-tenth of the GPU hours (the developer's experiment) [Ref. 6].
• Pruning combined with distillation (Minitron): pruning an existing 15B model and retraining it with distillation to get 8B and 4B models needed up to 40 times fewer training tokens than training from scratch and saved 1.8 times the compute cost for the whole model family, the authors report [Ref. 28].

(3) Caution: how licences treat distillation

Distillation uses a teacher model's outputs to build another model, so the teacher's licence or terms of use can reach the resulting student model. For example, DeepSeek-V3's model licence defines "Derivatives of the Model" to include any other model created by transfer of patterns of the model's weights, parameters, activations or output, and requires derivatives to carry the same use-based restrictions (Attachment A) [Ref. 36]. The Llama 3.1 licence requires that if you use the Llama materials or their outputs to create, train, fine-tune or otherwise improve an AI model that is distributed, you include "Llama" at the beginning of that model's name [Ref. 33]. The Gemma Terms of Use (before Gemma 4) state that Outputs are not Model Derivatives [Ref. 34]Sourced. Even for the same "distillation", the conditions imposed on the result differ with the teacher used. If you use the output of a commercial service as the teacher, that service's terms of use must also be checked (this article does not cover individual terms).

4. Quantization — INT8, FP8, FP4 and block-shared scaling

(1) What is quantized

Quantization represents numbers with fewer bits to reduce memory and compute. What is quantized falls into three groups: weights (W), activations (A, the values flowing between layers) and the KV cache. "W8A8" means both weights and activations in 8 bits; "W4A16" means 4-bit weights and 16-bit activations. Kurtic and colleagues use this notation to compare FP8 (W8A8-FP), INT8 (W8A8-INT) and INT4 weight-only (W4A16-INT)Sourced[Ref. 21].

(2) Number formats: bit layouts

A floating-point number consists of a sign, an exponent and a mantissa. The FP8 paper proposes two encodings, E4M3 (4 exponent bits, 3 mantissa bits) and E5M2 (5 exponent bits, 2 mantissa bits), explaining that E5M2 follows IEEE 754 conventions for special values, while E4M3 extends its dynamic range by not representing infinities and having only one mantissa bit pattern for NaN [Ref. 15]. The Microscaling (MX) formats combine one shared scale per block with narrow element types (FP8, FP6, FP4, INT8); in the paper's table, MXFP4 has a block size of 32, an 8-bit E8M0 scale and 4-bit FP4 (E2M1) elements [Ref. 16]. MXFP4 therefore costs 4 + 8/32 = 4.25 bits per element, which agrees with the gpt-oss model card's statement that the MoE weights are quantized to 4.25 bits per parameter [Ref. 9]Sourced.

(3) Quantization methods

• LLM.int8(): computes only the outlier feature dimensions in 16 bits and multiplies more than 99.9% of values in 8 bits, halving inference memory, and reports no performance degradation even for a 175B-parameter model [Ref. 17].
• GPTQ: a one-shot weight-quantization method using approximate second-order information; it reports quantizing a 175B model in about four GPU hours to 3 or 4 bits per weight with negligible accuracy degradation [Ref. 18].
• AWQ: argues that not all weights are equally important and that protecting only 1% of salient weights greatly reduces quantization error, with the salient channels identified from the activation distribution, not from the weights [Ref. 19].
• SmoothQuant: moves activation outliers into the weights to make W8A8 (8-bit weights and activations) quantization possible, reporting up to 1.56 times speedup and 2 times memory reduction with negligible loss of accuracy [Ref. 20].
• Low precision from the training stage: DeepSeek-V3 says it validated FP8 mixed-precision training on an extremely large-scale model for the first time, and distributes only FP8 weights [Ref. 4]. gpt-oss was post-trained with its MoE weights in MXFP4 [Ref. 9]. An NVIDIA paper presents a method for training a 12-billion-parameter model on 10 trillion tokens in the NVFP4 format (the authors' report) [Ref. 23]Sourced.

(4) The accuracy price: what primary sources confirm

Kurtic and colleagues compared FP8, INT8 and INT4 quantization over the whole Llama-3.1 family on academic benchmarks and real-world tasks, in more than 500,000 evaluations. They found that (1) FP8 (W8A8-FP) is effectively lossless at all scales, (2) well-tuned INT8 (W8A8-INT) shows a low accuracy degradation of 1 to 3%, and (3) INT4 weight-only (W4A16-INT) is more competitive than expected, rivaling 8-bit. From their analysis of inference performance in vLLM, they also say that W4A16 is the most cost-efficient for synchronous setups, W8A8 dominates in asynchronous continuous batching, and for mixed workloads the optimum depends on the use caseSourced[Ref. 21]. Dettmers and Zettlemoyer ran more than 35,000 experiments at 3 to 8 bits on BLOOM, OPT, NeoX/Pythia and GPT-2, and report that 4-bit precision was almost universally optimal for total model bits and zero-shot accuracy [Ref. 22]. These are results for particular model series, benchmarks and implementations, and may not hold for other models or tasks (commentary).

(5) Memory for weights: our calculation

The memory taken by weights is "number of parameters × bytes per parameter". We calculated it from nominal parameter counts (total parameters) for each format. The KV cache and activations are not included.

Our calculation (GB = 10⁹ bytes, weights only). Parameter counts are from the official sources [Ref. 2-9]. In practice not all parameters are given the same precision (gpt-oss has only its MoE part in MXFP4 and the rest in BF16). Block scales, embeddings, quantization metadata, the KV cache and activations are not included.

We checked the validity of the calculation on gpt-oss. Table 1 of the model card gives the 120b's MLP (MoE) as 114.71B, attention as 0.96B, embedding and output side as 1.16B, and the checkpoint size as 60.8 GiB [Ref. 9]. With the MoE at 4.25 bits and the rest in BF16 (2 bytes), 114.71B × 4.25/8 + (0.96 + 1.16)B × 2 comes to about 65.2 GB, or about 60.7 GiB, nearly equal to the table's 60.8 GiBOur calculation. In other words, the numbers confirm a configuration in which only the bulk of the weights (the MoE) is put in 4 bits and the rest stays at 16 bits, rather than "everything in 4 bits".

5. Pruning

Pruning removes unimportant weights or structures. It falls broadly into unstructured (zeroing arbitrary weights), structured (removing layers, heads, dimensions and the like as units) and semi-structured (zeroing in a fixed pattern, such as 2:4) (our organization).

• Semi-structured (2:4): NVIDIA's Ampere GPUs have Sparse Tensor Cores that exploit a 2:4 (50%) sparsity pattern for twice the matrix-math throughput, the paper explains. It also notes that research on sparsity has focused on high levels of sparsity, and that maintaining accuracy while achieving significant speedups on modern matrix-math hardware remains a challenge [Ref. 24].
• SparseGPT: prunes large GPT-family models to at least 50% sparsity in one shot with no retraining, and on OPT-175B and BLOOM-176B reaches 60% unstructured sparsity with a negligible increase in perplexity, the authors report [Ref. 25].
• Wanda: removes, per output, the weights with the smallest product of weight magnitude and input activation, needing neither retraining nor weight updates [Ref. 26].
• Structured pruning with retraining (Sheared LLaMA, Minitron): Sheared-LLaMA, which pruned LLaMA2-7B to 1.3B and 2.7B [Ref. 27], and Minitron, which pruned 15B to 8B and 4B and retrained with distillation [Ref. 28], have been reported.

All Sourced (the statements of each paper). Performance figures are for each paper's conditions.

Caution: zeroing 50% of the weights does not by itself make things faster. Unstructured sparsity may not translate into real speedups without dedicated hardware and software support (our commentary; see the statement by Mishra et al. above). A reduction in memory is likewise obtained only if the weights are stored in a sparse format.

6. Small models and the specifications of open-weight models

(1) Why small models: anticipating inference demand

Sardana and colleagues added the cost of inference to the Chinchilla scaling laws of Hoffmann et al. (compute-optimal training) [Ref. 32] and showed that when large inference demand (about 1 billion requests) is expected, one should train a smaller model for longer than Chinchilla-optimal. They also report that model quality keeps improving as tokens per parameter are raised to 10,000 [Ref. 31]. The Llama 3 paper likewise says that its flagship model is of roughly compute-optimal size but that the smaller models are trained much longer than compute-optimal and perform better than compute-optimal models at the same inference budget [Ref. 5]Sourced. The Phi-3 technical report says that phi-3-mini, with 3.8B parameters trained on 3.3 trillion tokens, has performance (the developer's evaluation, including 69% on MMLU) rivaling Mixtral 8x7B and GPT-3.5 while small enough to be deployed on a phone [Ref. 29].

(2) Specifications of open-weight models (checked 15 October 2026)

All Sourced (the statements of each model card, paper, config.json and licence; checked 15 October 2026). The FP8 statement for Llama 3.1 is from the "FP8 Quantization" section of the Llama 3 paper [5] (this article does not cover the quantization details). The figures are specifications and do not show which performs better.

7. Trade-offs among memory, speed and accuracy (our calculation)

(1) Estimating the upper bound of decode speed from weight reads

In decode, which generates text one token at a time, the weights are read from memory for every token, so memory bandwidth sets the upper limit of speed (our commentary; see our explainer on inference optimization and serving). At batch 1 with an assumed memory bandwidth of 3 TB/s, the upper-bound speed = bandwidth / (bytes of weights read per token). For MoE only the active part is read; for gpt-oss-120b we estimated the read volume from the model card's breakdown. The active MoE is 114.71B × 4/128 = about 3.58B (4.25 bits = about 1.90 GB), attention 0.96B (BF16 = 1.92 GB) and the output side about 0.58B (BF16 = 1.16 GB), about 4.98 GB in totalOur calculation (consistent with the model card's 5.13B active).

Our calculation (speed = 3,000 GB/s / weights read). Assumptions: batch 1, 3 TB/s memory bandwidth, weight reads only. The KV cache, activations, communication, overlap of experts within a batch and compute overheads are excluded. Real speed varies greatly with batch size, precision, hardware, input and output length, and software.

(2) Which approach tends to help in which situation (a conditional organization)

The sourced parts are Sourced (each paper). The arrangement of the table and the "conditions and cautions" are our commentary.

8. How to read licence terms

"Open weights" means the weights are published, and the conditions for use, modification and redistribution differ by model. The Open Source Initiative's Open Source AI Definition 1.0 requires, for an open-source AI, sufficiently detailed information about the training data (Data Information), the complete source code to train and run the system (Code) and the model parameters (Parameters), all made available under OSI-approved terms, and says that "Open Source models" and "Open Source weights" must include the data information and code used to derive those parameters [Ref. 38]Sourced. Having published weights (open weights) is therefore different from being open-source AI under the OSI definition. This article does not judge whether any model meets that definition.

All Sourced (licence texts and official pages; checked 15 October 2026). The summaries are our own and are not legal advice. Confirm the exact meaning of the terms in the full licence text and, where needed, with professional advice.

9. Limits, and what could not be confirmed

(1) Comparing model performance

This article does not treat which model performs better. Parameter counts, context lengths and licences are as stated in the official sources (checked 15 October 2026), and we did not individually check each company's latest models or updated versions of these models.

(2) Assumptions of the estimates

The estimates in Chapters 4 and 7 rest on nominal parameter counts and the illustrative assumptions of 3 TB/s memory bandwidth, batch 1 and weight reads only. Real speed changes with batch, parallelism, the KV cache, compute overheads and software. The read volume for gpt-oss's active parameters (about 4.98 GB) is our estimate derived from the model card's breakdown, not a measurement of an implementation.

(3) How general the accuracy losses are

The effects of quantization, pruning and distillation on accuracy are results for each paper's particular models, benchmarks and implementations. We could not confirm a primary source that measured the effect on materials and process work (the materials engineer's view 2 in Chapter 4 includes our inference). The effects of distillation (about one-tenth of the GPU hours for Qwen3, up to 40 times fewer tokens for Minitron) are reports by the developers or authors, and we could not confirm independent replications.

(4) Text of standards and specifications

For ISO/IEC standards we checked only the title, publication date and scope (abstract), not the full text. We could not obtain the original of the OCP Microscaling Formats Specification and confirmed the formats from the table of the MX paper. IEEE P3109 is a project under development, and we did not check its text.

(5) Licences

The summaries of licences in Chapter 8 are general explanations based on the published texts and are not legal advice. We did not check the latest versions of the Llama licence, the licences of other generations, or the full text of each model's usage policy.

10. How to read evaluations and standards

Evaluation of model efficiency can be considered in four parts: how much accuracy is kept (the difference from the original model), speed and throughput, memory and energy, and the statement of specifications and licence. International standards exist for number formats, but we could not confirm an international standard that defines how to evaluate efficiency itself. The table below lists what we could confirm, with a type for each row.

Standard numbers, titles, publication dates and stages were checked on the official ISO, IEEE, NIST, OSI and MLCommons pages (Sourced; checked 15 October 2026). The essentials of benchmarks and frameworks come from each original paper or official page. The arrangement of the table and the "cautions in reading" column are Our calculation (our own organization).

Cautions in reading

• Benchmark values change with the settings and the evaluator. Speed and memory figures change with batch, precision format, input and output length, hardware and software, and MLPerf too must be read with its submission category and system configuration. The figures for accuracy loss are limited to particular model series and evaluation settings.
• Watch for saturation and contamination. The accuracy of quantization and pruning is often argued on small differences in public benchmarks, so check whether such a difference is within the error (Chapter 5 of our explainer on benchmarks and how to read evaluations).
• Read standards and guidelines by whether they recommend or require, and whether they have legal force. IEEE 754 is a published standard, IEEE P3109 is under development, ISO/IEC TRs and TSs are reports and specifications, NIST is a voluntary framework, the OSI definition is an industry body's definition and MLCommons benchmarks are industry benchmarks. None of them decides the merit of a particular efficiency method or model.
• Distinguish declared values from measured values. Statements by a developer such as "fits on a single 80GB GPU" or "several times faster" are declared values. What you measure for memory, speed and accuracy on your own equipment and settings is the measured value.

11. Glossary

12. References (primary sources)

1. Shazeer N. et al. "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", arXiv:1701.06538 (January 2017) — arxiv.org/abs/1701.06538
2. Jiang A. Q. et al. "Mixtral of Experts", arXiv:2401.04088 (January 2024) — arxiv.org/abs/2401.04088
3. DeepSeek-AI "DeepSeek-V3 Technical Report", arXiv:2412.19437 (December 2024; v2 February 2025) — arxiv.org/abs/2412.19437
4. DeepSeek-AI "deepseek-ai/DeepSeek-V3" (official Hugging Face model card: FP8-only weights, licence statements; checked 15 October 2026) — huggingface.co/deepseek-ai/DeepSeek-V3
5. Llama Team (Grattafiori A. et al.) "The Llama 3 Herd of Models", arXiv:2407.21783 (July 2024; v3 November 2024) — arxiv.org/abs/2407.21783
6. Qwen Team (An Yang et al.) "Qwen3 Technical Report", arXiv:2505.09388 (May 2025) — arxiv.org/abs/2505.09388
7. Qwen "Qwen/Qwen3-235B-A22B" (official Hugging Face model card; checked 15 October 2026) — huggingface.co/Qwen/Qwen3-235B-A22B
8. Qwen "Qwen/Qwen3-30B-A3B" (official Hugging Face model card; checked 15 October 2026) — huggingface.co/Qwen/Qwen3-30B-A3B
9. OpenAI "gpt-oss-120b & gpt-oss-20b Model Card", arXiv:2508.10925 (8 August 2025) — arxiv.org/abs/2508.10925
10. OpenAI "openai/gpt-oss-120b" (official Hugging Face model card: MXFP4, 80GB GPU and Apache 2.0 statements; checked 15 October 2026) — huggingface.co/openai/gpt-oss-120b
11. Hinton G. et al. "Distilling the Knowledge in a Neural Network", arXiv:1503.02531 (March 2015) — arxiv.org/abs/1503.02531
12. Sanh V. et al. "DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter", arXiv:1910.01108 (2019; v4 March 2020) — arxiv.org/abs/1910.01108
13. Gemma Team "Gemma 2: Improving Open Language Models at a Practical Size", arXiv:2408.00118 (July 2024; v3 October 2024) — arxiv.org/abs/2408.00118
14. Google DeepMind "Gemma 4 model card" (Google AI for Developers; checked 15 October 2026) — ai.google.dev/gemma/docs/core/model_card_4
15. Micikevicius P. et al. "FP8 Formats for Deep Learning", arXiv:2209.05433 (September 2022) — arxiv.org/abs/2209.05433
16. Rouhani B. D. et al. "Microscaling Data Formats for Deep Learning", arXiv:2310.10537 (October 2023) — arxiv.org/abs/2310.10537
17. Dettmers T. et al. "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale", arXiv:2208.07339 (August 2022) — arxiv.org/abs/2208.07339
18. Frantar E. et al. "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers", arXiv:2210.17323 (October 2022; v2 March 2023) — arxiv.org/abs/2210.17323
19. Lin J. et al. "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration", arXiv:2306.00978 (June 2023) — arxiv.org/abs/2306.00978
20. Xiao G. et al. "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models", arXiv:2211.10438 (November 2022) — arxiv.org/abs/2211.10438
21. Kurtic E. et al. "Give Me BF16 or Give Me Death"? Accuracy-Performance Trade-Offs in LLM Quantization, arXiv:2411.02355 (November 2024) — arxiv.org/abs/2411.02355
22. Dettmers T., Zettlemoyer L. "The case for 4-bit precision: k-bit Inference Scaling Laws", arXiv:2212.09720 (December 2022; v2 February 2023) — arxiv.org/abs/2212.09720
23. NVIDIA "Pretraining Large Language Models with NVFP4", arXiv:2509.25149 (September 2025; v2 March 2026) — arxiv.org/abs/2509.25149
24. Mishra A. et al. "Accelerating Sparse Deep Neural Networks", arXiv:2104.08378 (April 2021) — arxiv.org/abs/2104.08378
25. Frantar E., Alistarh D. "SparseGPT: Massive Language Models Can Be Accurately Pruned in One-Shot", arXiv:2301.00774 (January 2023) — arxiv.org/abs/2301.00774
26. Sun M. et al. "A Simple and Effective Pruning Approach for Large Language Models", arXiv:2306.11695 (June 2023; Wanda) — arxiv.org/abs/2306.11695
27. Xia M. et al. "Sheared LLaMA: Accelerating Language Model Pre-training via Structured Pruning", arXiv:2310.06694 (October 2023) — arxiv.org/abs/2310.06694
28. Muralidharan S. et al. "Compact Language Models via Pruning and Knowledge Distillation", arXiv:2407.14679 (July 2024; v2 November 2024; Minitron) — arxiv.org/abs/2407.14679
29. Abdin M. et al. "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone", arXiv:2404.14219 (April 2024; v4 August 2024) — arxiv.org/abs/2404.14219
30. Microsoft "microsoft/Phi-3-mini-4k-instruct" (official Hugging Face model card and LICENSE (MIT); checked 15 October 2026) — huggingface.co/microsoft/Phi-3-mini-4k-instruct
31. Sardana N. et al. "Beyond Chinchilla-Optimal: Accounting for Inference in Language Model Scaling Laws", arXiv:2401.00448 (December 2023; v3 April 2025) — arxiv.org/abs/2401.00448
32. Hoffmann J. et al. "Training Compute-Optimal Large Language Models", arXiv:2203.15556 (March 2022) — arxiv.org/abs/2203.15556
33. Meta "Llama 3.1 Community License Agreement" (23 July 2024; LICENSE of the llama-models repository) — github.com/meta-llama/llama-models/blob/main/models/llama3_1/LICENSE
34. Google "Gemma Terms of Use" (Google AI for Developers; checked 15 October 2026) — ai.google.dev/gemma/terms
35. Google "Apache License 2.0 | Gemma" (the licence page for Gemma 4; checked 15 October 2026) — ai.google.dev/gemma/apache_2
36. DeepSeek-AI "DeepSeek License Agreement" (LICENSE-MODEL of DeepSeek-V3) — github.com/deepseek-ai/DeepSeek-V3/blob/main/LICENSE-MODEL
37. Apache Software Foundation "Apache License, Version 2.0" — www.apache.org/licenses/LICENSE-2.0
38. Open Source Initiative "The Open Source AI Definition – 1.0" (checked 15 October 2026) — opensource.org/ai/open-source-ai-definition
39. MLCommons "MLPerf Inference: Datacenter" (official page; the page showed V6.1; checked 15 October 2026) — mlcommons.org/benchmarks/inference-datacenter/
40. IEEE "IEEE 754-2019 IEEE Standard for Floating-Point Arithmetic" (published 22 July 2019) — standards.ieee.org/ieee/754/6210/
41. IEEE "P3109 Standard for Arithmetic Formats for Machine Learning" (Active PAR; PAR approved 15 February 2023; checked 15 October 2026) — standards.ieee.org/ieee/3109/11165/
42. ISO/IEC "ISO/IEC TR 17903:2024 Information technology — Artificial intelligence — Overview of machine learning computing devices" (May 2024; technical report) — www.iso.org/standard/85078.html
43. ISO/IEC "ISO/IEC TR 20226:2025 Information technology — Artificial intelligence — Environmental sustainability aspects of AI systems" (July 2025; technical report) — www.iso.org/standard/86177.html
44. ISO/IEC "ISO/IEC TS 42112:2026 Information technology — Artificial intelligence — Guidance on machine learning model training efficiency optimization" (June 2026) — www.iso.org/standard/42112
45. ISO/IEC "ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system" (December 2023) — www.iso.org/standard/81230.html
46. NIST "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", NIST AI 100-1 (January 2023), DOI 10.6028/NIST.AI.100-1 — doi.org/10.6028/NIST.AI.100-1

13. Claim-to-source audit

Last updated: 15 October 2026 (check date). Sources are limited to primary materials: original papers, developers' official model cards, licences and config.json files, and the official pages of MLCommons, IEEE, OSI, ISO and NIST. The full text of the standards is paid and was not checked. Parameter counts, context lengths and licences can change, and we do not guarantee the state after the check date. The summaries of licences are general explanations, not legal advice. The effect of quantization or pruning on accuracy in materials and process work, an international standard defining how to evaluate efficiency, the original OCP MX specification, the text of IEEE P3109, individual performance of each company's latest models, and the full licence texts of other generations could not be confirmed and are not stated. The estimates of speed and memory are rough, based on nominal parameter counts and illustrative assumptions (3 TB/s memory bandwidth, batch of 1), and are not real speeds. Figs. 2 to 4 and 6 are vector drawings; Figs. 1 and 5 are AI-generated concepts (frames with no image placed). None of them shows the inside of a real product or a measurement screen of real equipment.