Add 9 new Green AI patterns to the catalogue

[russelltrow]

Summary

This PR contributes 9 new green software patterns focused on AI and ML workloads, authored by Naveen Balani. The patterns cover the full AI lifecycle — from development decisions through to runtime operations — and are structured according to the GSF pattern template.

New patterns

Development

• right-sized-energy-efficient-ai-models.md — Select and optimize AI models appropriately sized for the task to reduce compute, memory, and energy consumption during training and inference.
• data-handling/optimize-data-storage-ai-training.md — Use efficient storage formats, compression, and indexing strategies for AI datasets and embeddings to reduce storage footprint, data transfer, and retrieval compute.
• pre-trained-transfer-learning.md — Fine-tune existing pre-trained models instead of training from scratch to dramatically reduce the compute, energy, and time required for model development.
• select-efficient-ml-frameworks-inference-runtimes.md — Choose ML frameworks and inference runtimes that best match your hardware and workload to reduce compute overhead and improve energy efficiency across training and production inference.
• optimize-agent-orchestration-reduce-model-calls.md — Design agentic AI workflows to minimise redundant model invocations and unnecessary compute through caching, conditional logic, and efficient orchestration patterns.

Architecture

• system-topology/run-ai-models-edge.md — Deploy AI inference on edge devices or local infrastructure to reduce data transfer, network energy use, and reliance on centralised cloud compute.
• system-topology/efficient-hardware-ai-workloads.md — Match AI workloads to the most energy-efficient hardware accelerator or instance type to improve utilisation and reduce energy consumption per inference or training run.
• system-topology/on-demand-execution-ai-agent-workloads.md — Trigger AI and agent workloads only when needed using serverless or event-driven platforms to eliminate idle compute and reduce unnecessary energy consumption.

Operations

• operations/carbon-aware-ai-scheduling.md — Reduce the carbon impact of AI workloads by running them in cloud regions with lower grid carbon intensity and scheduling deferrable jobs during periods of high renewable energy availability.

Pattern structure

Each pattern follows the standard GSF template and includes:

• ## Description — problem context and motivation
• ## Solution — actionable guidance
• ## SCI Impact — mapping to the E, I, M, and R factors of the SCI equation
• ## Cost Impact — compute, infrastructure, and trade-off considerations
• ## Assumptions — preconditions for the pattern to apply
• ## Considerations — trade-offs and caveats
• ## References — citations and further reading

All patterns include a description field in YAML front matter for catalogue indexing, and personas are aligned to the official GSF persona list.

Note on patterns 4A and 4B

The ML frameworks and agent orchestration patterns were originally scoped as a single pattern. Following a review with Naveen Balani, they were split into two focused patterns — one covering execution engine selection (4A) and one covering workflow design for agentic systems (4B) — as the two decisions are made by different personas at different points in development.

Test plan

• Review YAML front matter is valid for all 9 files
• Confirm section order matches GSF template: Description → Solution → SCI Impact → Cost Impact → Assumptions → Considerations → References
• Verify patterns render correctly in the Docusaurus site
• Confirm lifecycle category assignments (Development / Architecture / Operations) are correct for each pattern
• Confirm all personas are drawn from the official GSF persona list
• Review SCI Impact mappings for accuracy against the SCI specification

🤖 Generated with Claude Code

[russelltrow]

@LiyaMath @franziska-warncke @navveenb here are the new AI patterns on the staging website:

https://russelltrow.github.io/gsf-patterns/personas/ai-ml-engineer/

[caxenie]

I would also add that the orchestration is critical here. The suggested selection should not happen manually but should depend on a characterisation of the system heterogeneity.

I believe we can refine this here by looking at middleware systems that do the workload balacing, dispatching, and monitoring in closed-loop.

[navveenb]

Excellent suggestion. We'll explicitly mention that orchestration layers can act as closed-loop resource controllers, continuously adjusting allocations based on workload requirements, utilization, and efficiency objectives to avoid over-provisioning.

[caxenie]

Here can become more fine-grained, basically saying that we can define time scales for each task to be executed on CPU / GPU / TPU or accelerators by offering a "catalogue" of possible solutions for the needed time scales.

[navveenb]

Agreed, made the changes

[caxenie]

Let us build a catalogue for accelerator integration. We need to discuss here at the orchestration level (middleware) to enable the monitoring workload dispatching, with judiciously allocated resources.

[navveenb]

Great suggestion, updated the principle.

[caxenie]

I would complete "problem/workload-specific preprocessing"

[navveenb]

Agreed

[caxenie]

I guess the formula changes here as we have edge and cloud measurements. Shall we split the contributions? We might, of course, run into the problem of having the cloud "absorb" the edge values.

[navveenb]

The SCI formula should work. However, in hybrid edge-cloud architectures, energy, carbon intensity, and embodied emissions should be measured across all participating components, including edge devices, networking, and centralized infrastructure, and aggregated when calculating SCI

[caxenie]

I would also add the availability of the edge devices. Dependent on the network connection type, the edge device availability and responsiveness would also play a role

[navveenb]

Great point, added

[caxenie]

I would add the edge device to the cost impact. We can definitely use vonNeumann machines with low price and high energy need, or in-memory compute non-vonNeumann machine with a higher price (relatively) and ultra-low power consumption.

[navveenb]

Added.

[caxenie]

In my experience, I have also made tradeoffs between the pre-processing costs on the near-data edge device and the actual ML model, which comes anyway quantised / compressed for inference.

[navveenb]

Excellent point. Preprocessing itself consumes compute resources and should be evaluated alongside model execution when designing edge architectures.

[caxenie]

This is an open question: how to quantify/predict workloads and dispatch the workload smartly between cloud and edge. We need to define metrics also for the partitioning.

[navveenb]

Good point, i will extend the considerations section to highlight the need for metrics and evaluation criteria when deciding how workloads should be distributed

[caxenie]

Would smart methods for serialization/deserialization also play a role here? Especially when talking about cloud-edge distribution?

[navveenb]

Great suggestion. Will expand the solution section to include serialization efficiency as an important consideration.

[caxenie]

Here the conversion tools might also introduce costs

[navveenb]

Good point, added

[caxenie]

Yes, this included harmonising the event processing concepts eventually. There are lessons learned from stream processing and especially for AI models serving could benefit.

[navveenb]

Good point, will broaden the guidance to acknowledge that streaming and event-driven processing patterns can reduce unnecessary computation and improve responsiveness.

[caxenie]

In my experience the state profiling is not that efficient. We need good calibration with deployed workflows, especially when considering the cloud-edge continuum

[navveenb]

Agreed, will modify the wording to reflect this

[caxenie]

In this case, we need mechanisms as in feedback control systems. Here, we would have a controller fed with max resources, values of continuously monitored resource consumption, and the capacity to orchestrate the execution of agents in an event-based manner. Imagine that continuous monitoring would be costly, I would say event-based reactive control, basically, the system would react to relevant changes in the metrics. There is so much potential here!

[navveenb]

Great suggestion. Closed-loop monitoring and event-driven adaptation can help optimize agent execution while avoiding the overhead of continuous monitoring. Will incorporate this as a consideration for advanced orchestration scenarios.

[caxenie]

Here would be hard to find a diverse spectrum of domain-specific models, and then, to train them, we need more data and resources. This domain-specific validation would also have a price.

[navveenb]

Great point. Domain-specific pre-trained models may not always be available, and adapting or validating them for specialized domains can require additional data, compute, and evaluation effort. We'll expand the considerations section to reflect these trade-offs.

[caxenie]

This might come as a measure competing with the re-use of larger models and retraining. Model choice is also a decision not always available to all teams bringing AI into production. Offering a model zoo is typically good, but choosing is still a problem. A problem/model catalogue would be great.

[navveenb]

Good point, will clarify this

[caxenie]

Especially hard in edge deployment. The estimated values have some variance with respect to the deployed values on the hardware.

[navveenb]

Agreed, will add this.

[caxenie]

This is problem-dependent and taps into more parameters of the problem: deployment hardware type and resources (i.e., DSP, GPU, NPU) available, type of data, and pre-processing. For instance, one can use for temporal data both feedforward and recurrent models, with the latter being more resource-efficient (i.e., fewer parameters) but harder to build.

[navveenb]

Excellent point. Model suitability depends not only on task complexity but also on deployment hardware, data characteristics, preprocessing requirements, and operational constraints. Will incorporate these factors into the considerations section.

[caxenie]

This should be a must! More work to be done here, but I would argue the overhead is needed to enable all the other cost savings.

[navveenb]

Agreed, added the trade-off

[caxenie]

Acceptable thresholds are problem specific.

[navveenb]

Good point. Performance thresholds vary by application and should be defined according to business and functional requirements.

[caxenie]

There is always a trade off

[navveenb]

Agreed.

[caxenie]

This monitoring comes with overhead but can be integrated into the previously defined event-based platform to handle resource allocation, as profiling is the core of the lifecyle.

[navveenb]

Yes, will add that monitoring approaches should balance observability benefits with resource consumption.

[caxenie]

A very important point here is that the community tries to unfold a harmonised and interoperable framework APIs, so that one can deploy the same model on various backends. This approach of streamlining model deployment to specialised hardware happens already (see from the neuromorphic accelerators community, the SNNtorch and the Neuromorphic Intermediate Representation). This would open the stage for truly heterogeneous systems with large benefits in performance and sustainability, once a workload orchestrator is in place.

See: https://neuroir.org/ and https://snntorch.readthedocs.io/en/latest/

[navveenb]

Good point, will extend the pattern to highlight the importance of interoperable runtimes and portable model representations.

[caxenie]

Here, the community starts opening the way for new systems. For example, a heterogeneous orchestrator is the one from https://klepsydra.com/.
Efficient workload dispatching, monitoring, and balancing on heterogeneous edge systems.

[navveenb]

We will acknowledge that framework choices may influence workload portability and orchestration across diverse hardware platforms.

[caxenie]

Here, backwards compatibility and the option to also "retrofit" existing hardware in large heterogeneous systems is still an open problems. Imagine we have existing systems which could deliver more performance in a more efficient way, but back compatibility and runtime dependencies create friction.

[navveenb]

Great point, will add this consideration to ensure organizations evaluate migration friction and retrofit opportunities.