Sustainability Model Cards
- Sustainability Model Cards are structured documentation artifacts that extend model cards to include sustainability metrics like energy use, carbon emissions, and water consumption.
- They employ a domain-specific language to standardize and automate sustainability reporting across training, inference, and platform infrastructure.
- This approach bridges transparent model reporting with software quality assessments and lifecycle analysis, promoting sustainable AI deployment.
Sustainability Model Cards are structured documentation artifacts that extend the model card paradigm to the sustainability properties of AI and software systems. In the most explicit formulation, they are defined as an extension of classic Model Cards focused on sustainability aspects of AI/ML models and backed by a Domain-Specific Language (DSL) that specifies metadata, training, inference, platform, and metrics such as energy consumption, carbon emissions, and water consumption (Jouneaux et al., 25 Jul 2025). Their emergence reflects two converging lines of work: model reporting for transparency, intended use, evaluation, and caveats (Mitchell et al., 2018), and software sustainability research that treats sustainability as a quality characteristic expressed through energy consumption, resource optimization, and long-term endurance or “Perdurability” (Calero et al., 2013).
1. Origins in model reporting and Green AI
Model cards were introduced as short documents accompanying trained machine learning models that provide benchmarked evaluation, disclose intended use and out-of-scope uses, describe evaluation procedures, and surface caveats and ethical considerations (Mitchell et al., 2018). Their original emphasis was not environmental sustainability but transparent model reporting, especially through contextualization, factors affecting performance, disaggregated evaluation, and lifecycle-aware versioning. This reporting structure created a natural substrate for sustainability documentation because it already organized model information into sections such as Model Details, Intended Use, Factors, Metrics, Evaluation Data, Training Data, Quantitative Analyses, Ethical Considerations, and Caveats and Recommendations (Mitchell et al., 2018).
The immediate motivation for Sustainability Model Cards was a documentation gap. “Towards Sustainability Model Cards” argues that existing Model Cards, Dataset Cards, and related formats do not natively model energy use, carbon footprint, or hardware- and region-dependent sustainability information, and that current sustainability disclosures are not standardized, not easily machine-readable, and not readily usable for model selection, deployment optimization, or certification and SLA checking (Jouneaux et al., 25 Jul 2025). In parallel, large-scale evidence from Hugging Face shows that environmental impact is the least documented model-card section: only 2.0% of 32,111 cards include it overall, rising to 9.0% in the top 100 models; 84.8% of those environmental impact sections are automatically generated, with 58.5% mentioning AutoNLP and 26.3% mentioning AutoTrain (Liang et al., 2024). This combination of conceptual insufficiency and weak documentation practice established the practical rationale for a dedicated sustainability-oriented card.
2. Conceptual foundations in software quality and sustainability assessment
One intellectual precursor comes from software quality modeling. “Towards a Software Product Sustainability Model” treats software sustainability as part of software product quality rather than a separate concern, explicitly relating it to non-functional requirements and proposing that ISO/IEC 25010 be extended with a ninth characteristic, “Sustainability,” with three subcharacteristics: Energy Consumption, Resource Optimization, and Perdurability (Calero et al., 2013). The paper distinguishes short-term sustainability in operation—minimum energy use and optimized use of other resources—from long-term sustainability over the product lifecycle, where Perdurability is defined as the degree to which a software product can be modified, adapted and reused in order to perform specified functions under specified conditions for a long period of time (Calero et al., 2013). A plausible implication is that Sustainability Model Cards can document both operational impacts and long-term lifecycle qualities when they are used for software-intensive systems rather than only for trained ML models.
A second precursor is architecture-centered sustainability modeling. The Sustainability Assessment Framework (SAF) treats sustainability as a software quality property represented through quality attributes grouped into Technical, Economic, Social, and Environmental dimensions, and it adds a time dimension through immediate, enabling, and systemic impacts (Lago et al., 2024). Related work on the Sustainability Impact Score defines sustainability through quality attributes mapped across Economic, Environmental, Social, and Technical dimensions, with direct, enabling, and systemic impacts, and quantifies trade-offs between dimensions by combining impact signs with risk- and importance-based prioritization (Fatima et al., 28 Jan 2025). These frameworks are not themselves model cards, but they provide a vocabulary of dimensions, trade-offs, and temporal effects that can be summarized within a card.
A third strand broadens sustainability beyond environmental efficiency. The ESG Digital and Green Index organizes assessment into Environmental ceiling, Social floor, Governance, and Transverse or Global sustainability, with indicator categories such as climate change, natural resources, pollution and disruption of natural cycles, biodiversity and ecosystems, health and well-being, education, security, and governance mechanisms (Thelisson et al., 2023). By contrast, the current Sustainability Model Card DSL is explicitly centered on environmental sustainability—energy, carbon, water, and infrastructure context—while social and economic sustainability are identified mainly as future extensions (Jouneaux et al., 25 Jul 2025). This difference in scope is central to the current state of the field.
3. Canonical structure and covered dimensions
The current canonical Sustainability Model Card proposal is organized around four main sections: Metadata, Training, Inference, and Platform (Jouneaux et al., 25 Jul 2025). These sections expose both direct computational impact and infrastructural context: model identity, training-phase energy/carbon/water, per-task inference energy/carbon/water, and platform-level information such as hardware, provider, region, energy mix, and carbon offset credit (Jouneaux et al., 25 Jul 2025).
| Section | Representative fields | Purpose |
|---|---|---|
| Metadata | name, version, model_type, provider, license | identify the model |
| Training | hour_duration, energy_consumption, carbon_emissions, water_consumption, platform | describe training impact |
| Inference | inference_type, average energy/carbon/water, platform, timestamp | describe per-task usage impact |
| Platform | hardware, provider, region, energy_mix, carbon_offset_credit | contextualize measurements |
The dimensions covered are explicitly environmental. Training and inference each carry Energy Consumption, Carbon Emissions, Water Consumption, a timestamp, and a platform reference; platform descriptions include hardware, cloud provider, region, energy mix with source ratios and carbon intensities, and carbon offset credits (Jouneaux et al., 25 Jul 2025). The DSL therefore separates training totals from inference-task averages and makes the infrastructural context first-class rather than incidental.
This structure also aligns with the older model card template. Classic model cards specify Model Details, Intended Use, Factors, Metrics, Evaluation Data, Training Data, Quantitative Analyses, Ethical Considerations, and Caveats and Recommendations (Mitchell et al., 2018). “Towards Sustainability Model Cards” proposes that sustainability information can be exported as an extended version of the well-known Model Cards initiative, and it sketches combined cards in which standard sections such as Model Details, Intended Use, Metrics/Performance, and Ethical Considerations are complemented with sections such as Energy and Resource Profile, Environmental Impact, and Sustainable Deployment Recommendations (Jouneaux et al., 25 Jul 2025). This suggests a layered documentation form rather than a wholesale replacement of conventional model reporting.
4. Formalization through a domain-specific language
A defining feature of the 2025 proposal is its formalization as a metamodel plus YAML-based DSL (Jouneaux et al., 25 Jul 2025). The root concept is SustainabilityModelCard, composed of MetaData, Training, and Inference, with references to Platform and EnergySource instances. The key abstract concept is Computation, representing any computation with environmental impact; its two concrete subclasses are Training and Task. Every Computation has energy_consumption, carbon_emissions, water_consumption, a timestamp, and a platform (Jouneaux et al., 25 Jul 2025).
The remaining classes define the sustainability context. Training adds hour_duration. Task adds inference_type, chosen from a predefined list aligned with AI Energy Score categories such as TextGeneration. Platform includes name, hardware, provider, region, carbon_offset_credit, and an energy_mix expressed through EnergyMix associations to EnergySource instances; EnergySource includes name, type, co2_per_kWh, and unit. Metric classes—EnergyConsumption, CarbonEmissions, and WaterConsumption—all have value and unit (Jouneaux et al., 25 Jul 2025).
The concrete syntax is YAML. Class instances are encoded as snake_case keys with mappings as values; compositions are nested mappings; multiplicity greater than one is represented by sequences; and associations are referenced by the associated object’s name attribute (Jouneaux et al., 25 Jul 2025). The representative YAML example in the paper describes an LLM version 1.0.0 on a platform named “Infrastructure,” with hardware GTX 1080 Ti, provider Microsoft Azure, region West Europe, carbon offset credit 100.0 as PERCENTAGE, and an energy source Azure EU-W of type Fossil with 0.57 kgCO2eq/kWh. The training record specifies 100.0 hours, 25.0 kWh, 14.25 kgCO2eq, and 57.5 L; the TextGeneration inference task specifies 12.3 Wh, 7.12 gCO2eq, and 0.02 L (Jouneaux et al., 25 Jul 2025).
The formalization is intended to support validation and automation. The open-source Python implementation parses YAML, validates required units and controlled vocabularies, checks that percentage values lie within [0,1], and transforms the YAML into metamodel instances (Jouneaux et al., 25 Jul 2025). The same paper identifies concrete automation goals: search and filter models by sustainability criteria, compare and rank models for equivalent tasks, support SLA checking, and optimize deployments by choosing platforms or regions with lower co2_per_kWh (Jouneaux et al., 25 Jul 2025). In this sense, Sustainability Model Cards are not merely narrative reports; they are designed as machine-checkable artifacts.
5. Measurement, metrics, and evaluation logic
The Sustainability Model Card DSL stores sustainability values rather than introducing a new measurement science. The paper explicitly states that it does not prescribe a specific measurement pipeline and focuses on representation rather than new measurement techniques (Jouneaux et al., 25 Jul 2025). Nevertheless, the stored quantities support derived calculations. The paper notes that one may read total training energy directly from training.energy_consumption.value, inference energy per workload from task.energy_consumption.value, and emission intensity as a ratio of emissions to energy when units are compatible (Jouneaux et al., 25 Jul 2025).
Broader model-card literature offers a natural metric vocabulary for sustainability extensions. In the section on “Metrics,” classic model cards already require explicit performance measures, decision thresholds, and approaches to uncertainty and variability (Mitchell et al., 2018). The sustainability adaptation proposed there adds examples such as training energy , inference energy , and carbon emissions computed as
where is energy in kWh and is carbon intensity in (Mitchell et al., 2018). Those extensions also recommend disaggregating sustainability metrics by hardware type, deployment region, and usage pattern, mirroring the disaggregated analysis that model cards originally used for fairness and subgroup performance (Mitchell et al., 2018).
The quality-model tradition supplies another evaluative logic. The software sustainability model built on ISO/IEC 25010 does not define concrete numeric metrics or equations, but it explicitly states that the sustainability characteristic should enable the definition of measures and indicators that can be used to evaluate, detect weaknesses, or improve software sustainability (Calero et al., 2013). It also treats sustainability as a non-functional requirement and suggests that energy and resource requirements, along with long-term requirements for modifiability, adaptability, and reusability, be specified and evaluated like other quality attributes (Calero et al., 2013). This suggests that Sustainability Model Cards can function both as disclosure artifacts and as requirement-traceability artifacts when integrated into engineering workflows.
6. Practice, adoption, limitations, and future directions
Actual practice remains sparse relative to the conceptual ambition. On Hugging Face, 32,111 of 74,970 models had model cards as of 1 October 2022, representing 44.2% of repositories but 90.5% of total download traffic; yet Environmental Impact remained the least-filled section, at 2.0% overall, 3.7% among the top 1,000 cards, and 9.0% among the top 100 (Liang et al., 2024). When present, environmental sections were short—about 68 words on average in the top 1,000—and predominantly template-driven rather than bespoke (Liang et al., 2024). The same study found a significant positive temporal trend for Environmental Impact fill rates, with , and an intervention in which detailed model cards were added to 42 popular models showed a moderate positive effect on downloads in one batch: the treatment group increased average weekly downloads by 29.0%, with a 95% confidence interval of [10.6%, 47.5%] and a significant difference-in-difference interaction at (Liang et al., 2024). These results do not isolate sustainability content, but they indicate that richer documentation is compatible with deployment practice and community uptake.
The current Sustainability Model Card proposal also has explicit limitations. Its DSL is intentionally minimal and does not yet include dataset-related sustainability information, hyperparameters, batch sizes, hardware utilization metrics, or detailed breakdowns such as pre-training versus fine-tuning (Jouneaux et al., 25 Jul 2025). It does not resolve the underlying challenge of accurately estimating energy, emissions, and water consumption across heterogeneous hardware and cloud providers, and it focuses on training and inference rather than data collection and curation, hardware manufacturing, or disposal impacts (Jouneaux et al., 25 Jul 2025). Social and economic sustainability are acknowledged chiefly as future work, including tighter integration with ethical constraints and classic model cards, user studies on how sustainability data affects model selection, and further MLOps integration for automatic model selection, deployment optimization, and SLA enforcement (Jouneaux et al., 25 Jul 2025).
A common misconception is that Sustainability Model Cards are equivalent to a single environmental-impact field. The literature points in the opposite direction. Classic model cards were conceived as one transparency tool among many, to be complemented by datasheets, audits, adversarial testing, and feedback mechanisms (Mitchell et al., 2018). Sustainability-oriented work further suggests that cards can expose not only energy, carbon, and water, but also platform context, lifecycle assumptions, deployment conditions, and potentially broader ESG-oriented concerns when combined with other sustainability assessment frameworks (Thelisson et al., 2023). Another misconception is that the field is already standardized because some platforms display CO₂ estimates. The empirical evidence shows that current environmental documentation is still rare, short, and largely auto-generated, while the formal DSL work remains an initial proposal rather than an established standard (Liang et al., 2024).
Sustainability Model Cards therefore occupy a transitional space between reporting template, quality model, and machine-readable compliance artifact. Their distinctive contribution is to make sustainability a first-class documentation target at the model level, with explicit links to training, inference, platform, and measurable environmental impacts (Jouneaux et al., 25 Jul 2025). Their broader significance lies in connecting model reporting with software quality, lifecycle assessment, and automated governance infrastructures—a connection that is conceptually mature enough to structure documentation, but still methodologically open in its metrics, scope, and standardization.