ISO/IEC TR 17903:2024 Information technology — Artificial intelligence — Overview of machine learning computing devices
https://www.iso.org/standard/85078.html

3 Terms and definitions

3.1 artificial intelligence computing, AI computing
processing that leverages infrastructures to enable the set of methods or automated entities that together build, optimize and apply an AI model
3.2 machine learning computing, ML computing
processing that leverages infrastructures to train and execute ML models
3.3 infrastructure
hardware and software environment to support computer system and software design, development, and modification
Note 1 to entry: Network facilities can be also infrastructure working with hardware and software. [SOURCE:ISO/IEC/IEEE 12207:2017,[1] 3.1.25, modified: note 1 to entry is added.]
3.4 computing device
functional unit (3.6) that can perform substantial computations, including numerous arithmetic operations and logic operations with or without human intervention
Note 1 to entry: A computing device can consist of a stand-alone unit (3.7), or several interconnected units. It can also be a device that provides a specific set of functions, such as a phone or a personal organizer, or more general functions such as a laptop or desktop computer.
Note 2 to entry: A computing device contains at least one unit (3.7). [SOURCE:ISO/IEC 19770-5:2015,[2] 3.6, modified: note 2 to entry is replaced.]
3.5 hardware
all or part of the physical components of an information processing system
EXAMPLE:Computers, peripheral devices.
[SOURCE:ISO/IEC 2382:2015,[3] 2121277, modified: removed note to entry 2 and 3]
3.6 functional unit
entity of hardware or software, or both, capable of accomplishing a specified purpose
Note 1 to entry: In IEC 50 (191), the more general term item is used in place of functional unit. An item may sometimes include people.[SOURCE:ISO/IEC 2382:2015, 2123022, modified: removed notes 2 and 3 to entry.]
3.7 unit
lowest level of hardware assembly for which acceptance and qualification tests are required [SOURCE:ISO 24917:2020,[4] 3.4]
3.8 service
kind of application which encapsulates one or more computing modules and can be accessed through a specified interface [SOURCE:ISO/IEC 19763-5:2015,[5] 3.1.18]
3.9 artificial intelligence computing device
AI computing device
computing device (3.4) that can be specifically used for accelerating some or all of artificial intelligence computing
Note 1 to entry: An artificial intelligence computing device often contains and works with specific enabling software.
3.10 machine learning computing device, ML computing device
computing device (3.4) that can be specifically used for accelerating machine learning computing
Note 1 to entry: A machine learning computing device often contains and works with specific enabling software.
Note 2 to entry: Machine learning computing device is a subset of AI computing device (3.9).
EXAMPLE:A neural network process unit and its associated enabling software.
3.11 performance
measurable result
Note 1 to entry: Performance can relate either to quantitative or qualitative findings.
Note 2 to entry: Performance can relate to the management of activities, processes, products (including services), systems or organizations. [SOURCE:ISO/IEC 27000:2018,[6] 3.52]
3.12 effectiveness
extent to which planned activities are realized and planned results are achieved
[SOURCE:ISO/IEC 33001:2015,[7] 3.1.3]
3.13 efficiency
resources expended in relation to the accuracy and completeness with which users achieve goals [SOURCE:ISO/IEC 25063:2014,[8] 3.4]
3.14 datatype
set of distinct values, characterized by properties of those values and by operations on those values [SOURCE:ISO/IEC 11404:2007,[9] 3.12]
3.15 operator
mathematical or logical symbol that represents an action to be performed in an operation, or a symbol representing the name of a function [SOURCE:ISO/IEC/IEEE 24765:2017,[12] 3.2716, modified — 3.2716.3 and 3.2716.4 are combined.]
3.16 schedule
methods for controlling the timing of the execution of an activity within or represented by a managed object [SOURCE:ISO/IEC 10164-15:2002,[33] 3.1.27]
3.17 topology
structure of the communication paths between the medium attachment points [SOURCE:ISO/IEC 14543-2-1:2006,[48] 3.2.30]
3.18 stream
sequence of representations of jobs or parts of jobs to be performed, as submitted to an operating system [SOURCE:ISO/IEC 2382:2015,[3] 2122886]
3.19 computing
actions performed or approaches implemented by a system, aiming at processing specific kinds of data or providing solutions to certain tasks
Note 1 to entry: Computing can also be a system providing functionalities or characteristics.
3.20 heterogeneous computing
system that uses more than one kind of processor or cores [SOURCE:ISO/IEC 30145-3:2020, 3.1.5]
3.21 distributed computing
spreading of computation and data across a number of computers connected by a network [SOURCE:ISO/IEC/IEEE 24765:2017,[12] 3.1240]
3.22 quantum computing
use of quantum phenomena for computational purposes [SOURCE:ISO/TS 80004-12:2016, 6.5]
3.23 cloud computing
paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on-demand
Note 1 to entry: Examples of resources include servers, operating systems, networks, software, applications and storage equipment. [SOURCE:ISO/IEC 22123-1:2021, 3.2.1]
3.24 inter-cloud computing
paradigm for enabling the interworking between two or more cloud service providers [SOURCE:ISO/IEC 22123-1:2021, 3.12.1]
3.25 edge computing
distributed computing in which processing and storage takes place at or near the edge, where the nearness is defined by the system's requirements [SOURCE:ISO/IEC TR 23188:2020, 3.1.3]
3.26 processing
run of an algorithm, treatment on data or a sequence of them performed by AI systems
3.27 buffer
device or storage area used to store data temporarily to compensate for differences in rates of data flow, time of occurrence of events, or amounts of data that can be handled by the devices or processes involved in the transfer or use of the data[SOURCE:ISO/IEC/IEEE 24765:2017,[12] 3.430.1]
3.28 cache
temporary storage in computer memory, to improve operations by having frequently used data readily available for retrieval [SOURCE:ISO/IEC/IEEE 24765:2017,[12] 3.452.1]

Bibliography

ChatGPT

About ISO/IEC TR 17903:2024 Information technology — Artificial intelligence — Overview of machine learning computing devices https://qiita.com/kaizen_nagoya/items/975c330fd00d3a2a677e, Please explain the purpose and achievements of the standard, as well as any omissions and challenges, from the three perspectives of those who build AI, those who use it, and other third parties.

Purpose & Achievements
Purpose
As per the ISO/IEC website, the TR is described thus:
“This document surveys machine learning (ML) computing devices, including the following: — ML computing device terminology and characteristics; — existing approaches to the setting and use of characteristics for optimizing ML computing device performance. The information provided in this document is relevant for organizations of all types and sizes.”
ISO+1
So its high-level aims are:
To establish a shared vocabulary / terminology around ML computing devices (hardware + enabling software) in the context of AI/ML.
Qiita+1
To catalogue / characterise the attributes (characteristics) of ML computing devices — e.g., datatypes, memory access, scheduling, topology, streams, buffers, caches, data exchange, etc.
スタンダーズオーストラリアストア+1
To summarise existing approaches for optimising performance of ML computing devices (i.e., how hardware + enabling software trade-offs are handled, resource management, scheduling, heterogeneous computing, etc.)
cdn.standards.iteh.ai+1
To act as a generic, organisation-agnostic resource (for all sizes/types of organisations) for understanding what “ML computing device” means and what to look out for.
Evs+1
Achievements
From what we can glean:
Terminology consolidation — The TR defines ML computing device, AI computing device, infrastructure, functional unit, etc. (e.g., clauses 3.1–3.11) in the Qiita article.
Qiita
This helps reduce ambiguity when people talk about “accelerators”, “ML operators”, “heterogeneous computing”, “edge computing”, etc.
Mapping of characteristics — Section 6 in the TR (according to the summary) sets out characteristics (datatypes, operators, memory access/ addressing mechanisms, scheduling, topology, streams, buffering, cache, data exchange) each with “general” and “effectiveness/efficiency” sub-clauses.
スタンダーズオーストラリアストア+1
This gives practitioners a checklist of device characteristics to consider or compare.
Performance-optimisation approaches — The TR includes section 7 (Approaches and measures for performance optimisation) which covers e.g., computing resource-level, enabling software-level, and measures.
スタンダーズオーストラリアストア
For organisations designing or procuring ML computing devices, this helps highlight what “good” looks like in terms of efficiency and resource usage.
Bridging hardware/software gap — While many standards focus either on ML algorithmic aspects, system architecture, or software frameworks, this TR explicitly addresses the device (hardware + enabling software) dimension of ML — which is relatively under-covered. For builders/manufacturers of accelerators, or users provisioning ML infrastructure, this helps align language.
Supporting ecosystem of AI standards — The TR sits among a family of ISO/IEC AI standards (e.g., terminology, frameworks, data quality, risk management) and helps fill the gap of “computing device” view in the AI chain. As noted in the Qiita article, the TR is among newer ones in the 2023-2025 time-frame.
IEC
From the perspective of each stakeholder group, the above achievements mean:
Builders/manufacturers: A clearer target of what to deliver (device characteristics, efficiency measures), a form of benchmark vocabulary to communicate with users.
Users/deployers: Better ability to compare devices (via characteristics), make more informed procurement decisions, understand what to expect from device performance.
Third parties (auditors/regulators/standard-adopters): More standardised language to evaluate claims from manufacturers, more clarity about what “ML computing device performance” means, potential basis for auditing or procurement specifications.
Omissions & Challenges
Despite its contributions, there are also omissions, limitations and open challenges. I’ll discuss them and link them to the stakeholder perspectives.
For Builders / Manufacturers
Omissions / Challenges
Lack of prescriptive metrics or thresholds — The TR surveys characteristics and optimisation approaches, but it does not define fixed performance thresholds, normative benchmarks, or detailed test methods (at least as it appears). It is a Technical Report not a full Standard, and is represented as “surveying” rather than “requiring”.
ISO +1
For builders wanting “what is minimally acceptable” or “what do I have to certify against”, this may be less helpful.
Rapidly evolving hardware/software space — ML accelerators, heterogenous computing, specialised AI chips, edge devices, memory architectures, software frameworks (e.g., ML compilers) are evolving very fast. A snapshot survey may quickly become out-of-date. Builders will need to track evolution and the TR may not keep pace with future novel architectures (e.g., neuromorphic, photonic, quantum-ML). Indeed the TR mentions quantum computing and heterogeneous computing definitions.
Qiita
Implementation specificity missing — The TR describes “characteristics” and “existing approaches”, but may not provide deep guidance on how to implement or validate them in device design – e.g., actual micro-architecture trade-offs, manufacturing cost, power/thermal constraints, end-to-end ML training/inference use-cases. That means builders still must rely on proprietary or domain-specific know-how.
Ecosystem interdependencies — The performance of ML computing devices is heavily influenced by software frameworks (compilers, runtimes), model architectures, data movement, system integration, and end-to-end workflows. The TR touches on enabling software but may not deeply address the full system stack or integration issues (e.g., how device characteristics map to ML model accuracy, latency, energy efficiency in real workflows). Builders must still navigate system‐level complexity.
Emerging concerns like sustainability, lifecycle, supply chain — While the TR addresses “efficiency” and resource use, it may not comprehensively cover environmental/sustainability metrics (e.g., carbon footprint of device manufacturing/operation across life-cycle), or supply-chain traceability of specialised accelerators, which are growing concerns.
Implications
Builders may use the TR as a framing document, but cannot treat it as a full specification for product certification.
Risk of “bibliographic compliance” (saying “we follow TR 17903”) without deeper internal technical validation.
Device vendors may diverge in interpretations of the “characteristics” and “optimisation approaches”, leading to inconsistent implementation.
For Users / Deployers
Omissions / Challenges
Gap between device-spec and system outcome — Users may see device characteristics (datatype support, memory access, topology) but the TR may not clearly translate these into system-level outcomes they care about: e.g., how many images/second, training/inference latency for their model, cost/performance for their workload, energy usage in their environment. Thus procurement decisions still require significant internal benchmarking and workload profiling.
Workload and domain specificity — ML workloads vary widely (computer vision, NLP, reinforcement learning, edge IoT, federated learning). The TR offers general device characteristics, but users will still need to map those to their specific models and domains. The TR may not provide domain-specific guidance on which device features matter most.
Integration and end-to-end systems — Device alone is one piece; the user must consider data pipelines, model training, inference, model updates, edge vs cloud, system deployment, lifecycle. The TR touches the computing device but may not fully address deployment environment or operational concerns (e.g., model drift, updating hardware, edge deployment constraints).
Obsolescence and upgrade path — As hardware evolves fast, users may struggle to know when/how to upgrade, and how device characteristics future-proof their deployment. The TR being a survey means it may not give strategic guidance.
Cost, procurement, vendor claims — Users still face challenges parsing vendor claims, benchmarking results, vendor lock-in, and cost trade-offs (capital expenditure, operational expenditure, energy costs). The TR provides characteristic lists but not cost/benefit frameworks.
Transparency and comparability — Although device characteristics are defined, vendors may not publish consistent metrics; there may still be lack of standardised benchmarking, and thus still difficulties for users to compare apples-to-apples.
Implications
Users should treat the TR as a useful reference/checklist but still perform independent benchmarking and domain-specific evaluation.
They should ask vendors for metrics aligned to the characteristics in the TR (e.g., datatype support, memory access mechanisms, scheduling, etc.).
Users should pair device metrics with workload-specific measures (latency, throughput, power, cost) and not rely solely on vendor spec sheets.
For Third Parties (Auditors / Regulators / Standard-Adopters)
Omissions / Challenges
Non-normative nature — As a “Technical Report” (TR) rather than a normative “Standard” (IS), the document may not establish mandatory requirements. For auditors or regulators seeking enforceable compliance, this may limit its role. It provides useful guidance but not necessarily binding measures.
Lack of test/benchmark method detail — For auditing/compliance, one often needs standardised test protocols, measurement methods, traceability. The TR seems to survey existing approaches rather than set a standard test suite. That means third parties may still need to develop or rely on additional standards for measurement, benchmarking, certification.
Rapid technological change and heterogeneity — Third parties evaluating devices in an ecosystem with diverse hardware/software stacks may find that the TR’s generality leaves many grey areas (e.g., what exactly qualifies as “heterogeneous computing”, how to assess “effectiveness/efficiency” of memory access across different vendor architectures). It may permit broad interpretation which challenges comparability across audits.
Context beyond device — For regulators or standard-adopters concerned with AI trustworthiness, safety, fairness, transparency, supply chain, environmental impact, etc., the TR focuses on computing device characteristics and optimisation for ML performance — which is only one dimension of the broader AI systems ecosystem. Third parties may need to reference other standards to cover those aspects (e.g., data quality, risk management, lifecycle governance).
Global alignment / regionalisation issues — As device manufacturing and supply chains are global, third parties may struggle with regional differences in regulation, terminologies, or proprietary vendor claims. The TR helps unify terminology but enforcement across multiple geographies may still be uneven.
Implications
Auditors and regulators can use the TR as an informative reference to shape checklists and evaluation frameworks, but may need to incorporate additional normative standards and detailed measurement protocols.
Standard-adopters (companies adopting standards proactively) can align their hardware procurement spec and vendor contracts with the vocabulary and characteristics in the TR, but must still build their own internal compliance/verification approaches.
Summary Table
Here’s a summary table pulling the three perspectives together:
Stakeholder Achievements / Benefits Omissions / Challenges
Builders/Manufacturers Shared vocabulary; clearer device characteristic checklist; highlighting performance-optimisation approaches; bridging hardware/software gap. No prescriptive metrics; fast-moving hardware/software means risk of obsolescence; limited implementation detail; full system integration not covered; sustainability/supply-chain concerns less emphasised.
Users/Deployers Helps compare devices; improves procurement language; aids in understanding device features and trade-offs. Device spec ↔ real workload gap; domain-specific mappings needed; integration & lifecycle concerns; upgrade path unclear; cost/benefit analyses still needed; vendor claims still variable.
Third Parties (Auditors/Regulators) Useful reference for checklists and vocabulary; helps structure evaluation of devices; aids standard-adoption frameworks. Non-normative nature (TR not full standard); lacks measurement/test protocols; broadness leads to ambiguity; doesn’t cover full AI system issues (safety, fairness, data, lifecycle); global/regional enforcement issues.
Additional Considerations from the Qiita Article
The Qiita article by Dr. Kiyoshi Ogawa (kaizen_nagoya) highlights some further points (in somewhat Japanese-engineering context) worthy of mention:
It underlines that the TR clarifies that a machine-learning computing device (ML computing device) is a subset of AI computing device. For example: “A computing device (3.4) that can be specifically used for accelerating machine learning computing”.
Qiita
The article also emphasises the TR’s breakdown of “characteristics” (Section 6) and the classification of “effectiveness” vs “efficiency” in each characteristic (e.g., memory access & addressing mechanisms: general + effectiveness/efficiency) which is helpful for comparing devices in design or procurement.
Qiita
It draws attention to the fact that the TR is quite short (≈25 pages) and high-level, meaning it is an overview rather than an in-depth engineering manual. This matches the “survey” nature of the document.
The article suggests that for many engineers or architects working on ML accelerators or device selection, the TR helps get common language but emphasises that deeper vendor/benchmark information will still be needed in practice.
Concluding Thoughts
In summary: ISO/IEC TR 17903:2024 is a welcome addition to the AI standards ecosystem. It provides a much-needed treatment of the “computing device” layer of ML systems, offering a vocabulary and characteristic framework that helps builders, users and third parties better articulate and assess ML hardware/software. However, it is by design a survey/overview document, and thus cannot substitute for detailed device specification standards, measurement/test frameworks, or system-level deployment guidance. Stakeholders will benefit if they use it as a reference layer, paired with domain-specific evaluation, vendor benchmarking, and complementary standards (e.g., for data quality, risk management, AI system lifecycle).
If you like, I can check specific sections of the TR (e.g., Section 6 and 7) and map them to real-world device selection or ML system procurement — would you like me to do that?

Ref.

ISO IEC Artificial intelligence Standards
https://qiita.com/kaizen_nagoya/items/1d1ffe4ac8e1dc67501f

大規模言語モデル講座基礎編 2025 Autumn　敗因を勝因に
https://qiita.com/kaizen_nagoya/items/34ffd2b0c47a5f3665d9

MCP入門〜面倒なことはAIエージェントにやらせよう〜 by からあげを聞きながら
https://qiita.com/kaizen_nagoya/items/54b648c838fae8d57e38

MCP入門〜面倒なことはAIエージェントにやらせよう〜 by からあげを聞きながら、補足と反論 by ChatGPT
https://qiita.com/kaizen_nagoya/items/0939d58d31666562090c

C言語を習得する３つの方法
https://qiita.com/kaizen_nagoya/items/84cab0888c193bba429b

Views上位６４記事　20250617現在
https://qiita.com/kaizen_nagoya/items/26dbbd04cf18b7742972

C言語(C++)が必要な人、必要ない人　with ChatGPT
https://qiita.com/kaizen_nagoya/items/a074cb8cd292d8d94bd4

C言語を習得する３つの方法　with ChatGPT
https://qiita.com/kaizen_nagoya/items/4a3518a18fa49f46787f

＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
This article is an individual impression based on my individual experience. It has nothing to do with the organization or business to which I currently belong.
Este artículo es una impresión personal basada en mi experiencia personal. No tiene nada que ver con la organización o empresa a la que pertenezco actualmente.

文書履歴(document history)

ver. 0.01 初稿　20251016

最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.

Muchas gracias por leer hasta la última oración.

Por favor, haz clic en el ícono Me gusta 💚 y sígueme para tener una vida feliz.