The Environmental Impact of Generative AI: How Can Reducing It Make You More Efficient?

@misc{mortas2026environmental,
  author = {MORTAS, Félix},
  title = {The Environmental Impact of Generative AI: How Can Reducing It Make You More Efficient?},
  year = {2026},
  url = {https://felixmortas.com/ai-env-impact-knowledge/en/},
  note = {Accessed online; last modified: October 15, 2026}
}

You often hear that a ChatGPT query consumes six times more electricity than a Google search, and that it takes about half a liter of water to generate 10 to 50 answers [1].

But do these figures really reflect reality?

Not so fast! Behind these claims lie approximations and methodological shortcuts that deserve a closer look.

The calculator designed to illustrate this article estimates that this simple message sent to DeepSeek emitted 0.28 g of CO₂ equivalent (gCO₂e) and consumed 0.06 mL of water. That's the equivalent of a light bulb left on for 6 minutes, and 1 drop of water.

Yet the calculator estimates that this far more complex exchange with Claude emitted 7.48 gCO₂e and consumed 2 mL of water. That's the equivalent of a light bulb left on for 3 hours and 53 minutes, and 40 drops of water.

The estimates take into account the chatbot's visible text, the electricity used to run the AI, and the water used to cool the data center. They do not take into account the AI's reasoning, action loops, model training, the manufacturing of the computer hardware and the data center, network usage, or the water consumed to produce the electricity. The overall environmental impact is therefore largely underestimated.

So how do we explain such a difference?

In this article, we will decode what lies behind these figures and understand what really causes the environmental footprint of our conversations with AI to vary. You will also realize that adopting good environmental practices generally leads to more efficient use.

Introduction

In a context of climate change driven by human activities [2], even the Pope is worried about the risks posed by AI [3].

The IEA's "Energy and AI" report published in April 2025 forecasts that global energy demand from data centers will double to about 945 TWh by 2030 — a level comparable to Japan's annual electricity consumption — and is expected to reach about 1,200 TWh by 2035 [4]. The United Nations recently published a report on the environmental impact of AI in terms of carbon emissions and water consumption [5].

Organizations as well as individuals need to keep their environmental footprint in check. Concrete, real-world advice for reducing this impact is needed for both users and developers. But to act effectively, you first need to understand certain aspects of how AI works.

I carried out research on the environmental impact of generative AI for 18 months at AXA, which allowed me to build up a great deal of knowledge on the subject that I now want to share with you.

Through this article, you will understand which factors most influence the environmental impact of AI, how to measure it when possible, and how to reduce it as an end user and as a developer.

You will also discover this calculator, which lets you measure the impact of one of your conversations with a chatbot (ChatGPT, Claude, Gemini, but also Mistral, DeepSeek, etc.). You will also be able to simulate applying certain good practices to that same conversation, and thus see how relevant they are.

This calculator is not intended to compete with existing estimation methods, nor to provide a definitive measurement. Its purpose is to illustrate the effectiveness of the good practices presented in this article.

Factors influencing the environmental impact of generative AI

The main environmental impacts related to the use of AI that we will examine in this article are the following:

• Greenhouse gas (GHG) emissions related to the electricity and other energy sources needed to run the data centers that power AI models;
• Water consumption to cool the IT equipment in data centers.

Other impacts could be considered, but since the subject is still somewhat immature, we will limit ourselves to these two.

The fundamentals: the Large Language Model (LLM)

In a chatbot like ChatGPT, a mechanism generates responses that give the impression of a real conversation. This is the LLM: Large Language Model. It is a generative artificial intelligence model, trained on a very large amount of text in order to learn the characteristics of, and relationships between, words and sentences. Its main goal is to predict, based on the context provided, which words are most likely to come next.

Tokens

LLMs do not process words directly, but tokens. An embedder (a transformation tool) breaks words down into tokens before processing. A useful rule of thumb is to consider that a token generally corresponds to about 4 characters in typical English text. This is equivalent to about three-quarters of a word (so 100 tokens correspond to about 75 words) [6].

Example of tokenization: "Impacting the environment" breaks down into 4 tokens: "Impact / ing / the / environment"

LLM designers use different embedders, which means that the same text can produce a different number of tokens depending on the model.

Tokens can be divided into two categories:

• input tokens (also called: instruction tokens, user tokens, or sent tokens)
• output tokens (also called: generated tokens, assistant tokens, or received tokens).

The more tokens the AI has to process, the more energy it consumes

The number of output tokens is theoretically proportional to total energy consumption.

Example: An exchange that requires processing 10 tokens consumes half as much energy as a request that processes 20 tokens.

Output tokens generally consume more energy than input tokens

Some studies show that processing an exchange with a long sent message (for example, 50,000 tokens) consumes only slightly more energy than short sent messages [7]. This suggests that the consumption of an input token is negligible compared to an output token. In reality, its consumption varies greatly depending on the total length of the message. It can be lower when the message is short, but higher when the message is long. The same is true for output tokens [8] [9].

Simplified model: A request with 1,000 input tokens and 50 output tokens will theoretically consume less energy than a request with 50 input tokens and 1,000 output tokens.

Assuming that most exchanges with a chatbot are long, the consumption of an input token cannot be considered negligible [10].

General rule: the fewer output tokens a request processes, the less energy it will consume. The same goes for input tokens, but generally to a lesser degree than for output tokens.

Reasoning tokens add to output tokens

A reasoning model first produces a planning text that it relies on to build its final response. The tokens generated by the reasoning model are sometimes not visible to the user. A reasoning token consumes as much energy as an output token. They increase the total number of tokens processed by the LLM, and therefore its energy consumption [11].

We therefore understand that the number of tokens processed, particularly output tokens, has a strong impact on the environmental footprint. To measure this impact and quantify its energy, carbon, and water footprint, three key indicators can be tracked:

• GHG emissions, expressed as mass of carbon dioxide equivalent (gCO₂e);
• energy consumption, expressed in watt-hours (Wh);
• water consumption, expressed as volume (L or m³).

These indicators apply to both input tokens and output tokens.

The major role of the data center

A generative AI, like an LLM, is a program run on a computer. It can be your personal machine, but it is generally done in data centers. Running it requires energy, which causes an environmental impact, measured here in gCO₂e/kWh.

The different services for using an LLM, which consume energy, are as follows:

• Hosting in a public data center (Microsoft Azure, Amazon Web Services, Google Cloud Platform): the AI runs on servers in a data center owned by a company (cloud) rather than directly on your computer. These servers are very powerful and make it possible to run AI models that you have downloaded or that you have developed and trained yourself. In this case, you own the AI and choose the cloud provider and the geographic region in which it will run.
• Hosting in your own data center: generally reserved for companies, the principle is similar to the public cloud: you own the AI and decide the location of the machine on which to run it.
• In the data centers of official AI providers like OpenAI, Anthropic (Claude), Google, Mistral AI, Meta, DeepSeek, Z.ai, Moonshot AI, or aggregators like OpenRouter, Vercel, Groq, and MammouthAI. Here, you control nothing about how the AI runs. It may be hosted in a private data center, or with a public cloud provider (in the name of the provider or the aggregator).
• On your computer: some recent, small AIs can run directly on your computer while delivering performance competitive with large proprietary models [12]. You then control 100% of the energy consumption related to its use and can use generative AI offline.

The cost of electricity production by country

Each country produces electricity with a different environmental impact. To generate 1 kWh, a power plant emits GHGs and consumes water.

Some organizations provide the carbon emission factors of each country (in gCO₂e/kWh produced):

• the International Energy Agency (IEA), normally paid but available free of charge on request [13];
• the ADEME, free but uses 2011 IEA data [14];
• Ember Energy, free and uses 2025 data from the IEA, Eurostat, BP, and UN [15];
• Spectrum IEEE, free and by country or type of production [16].

According to Ember Energy, these factors can range from just over 20 (Iceland) to more than 800 gCO₂e/kWh (Mongolia). The location of the servers plays a major role in the environmental impact of AI.

Data centers must be cooled

When servers are in use, the electricity they receive is converted into heat. To keep running properly, the servers in a data center must be kept at an optimal temperature. To remove the heat, data centers use different cooling methods [17], including:

• Direct outside air cooling: Possible in cool-climate regions, this method ventilates outside air to cool the servers. It consumes electricity mainly to power the fans and does not consume water.
• Adiabatic cooling: Hot outside air is ventilated and cooled by spraying fine water droplets that evaporate on contact with it. This method consumes both electricity and water.
• Direct Chip Cooling: Water flows through micro-pipes between the server components to cool them directly. Although the water is not consumed, it must be cooled at some point in the circuit, which often requires energy. In addition, this water can be drawn on by the data center during periods of high demand (for example, for human consumption or agricultural irrigation in summer), which can create competition over usage.

Water consumption can be measured

The WUE (Water Usage Effectiveness) is an indicator measuring the amount of water consumed by data centers [18]. This so-called consumed water is actually evaporated into the atmosphere. Water withdrawn from the environment and returned later is not accounted for in the calculation of this indicator.

Formula: WUE (L/kWh) = Water consumed (L) / Energy consumed by servers (kWh)

WUE depends mainly on the location of the data center and its cooling methods. Those located in arid regions generally have a higher WUE, and therefore use more water during periods of high heat.

Source: Environmental reports

Energy efficiency index: the PUE

The same server consumes the same amount of energy, regardless of its location. However, the energy needed to keep it at an optimal temperature varies with the climate. Thus, more or less energy is needed to cool it depending on its location.

The indicator for measuring the energy efficiency of a data center, particularly for cooling and infrastructure maintenance, is the PUE (Power Usage Effectiveness) [19]. It represents the ratio between:

• the total consumption of the data center;
• the consumption related solely to running the servers.

Formula: PUE = Total data center consumption (kWh) / Data center server consumption (kWh)

Examples of interpretation:

• PUE = 1: ideal. All the energy is used solely to run the servers.
• PUE > 1: in addition to the energy to run the servers, the data center also consumes energy to cool the servers.
• PUE = 2: as much energy is consumed to power the servers as to cool them.
• PUE > 2: very bad. More energy is consumed to cool the servers than to power them.

The global average PUE is 1.54 [20], while Google's is 1.09 [21].

The data center PUE is a key criterion when choosing a cloud provider and a hosting region.

Choosing the AI model to use

Model size

The size of a language model is measured by its number of parameters. The more parameters a model activates during execution, the higher its energy consumption per token. This consumption is directly proportional to the number of parameters.

Example: a model with 100 billion parameters consumes half as much electricity to process a token as a model with 200 billion parameters [22].

This rule does not necessarily apply across all model providers. Indeed, each uses different design methods, which affects the energy consumption of the models [23]. However, it can generally be applied to all models within the same family: GPT-6 models among themselves, Gemini 3 models among themselves, etc. Thus, even if this rule is not universal for comparing all models with one another, it remains a reliable indicator for guiding the choice of a model from the same provider.

Provider transparency: Open-source models display their number of parameters. But the number for models from private providers like OpenAI, Anthropic, or Google is never disclosed. It is nevertheless possible to rank a provider's models by size using their names: luna, lite, small, nano, mini < terra, flash, medium < sol, pro, large, plus, max. Some research attempts to quantify this number of parameters using various innovative methods, such as comparing the volume of stored knowledge [24].

Source: https://01.me/research/ikp/#/calibration#proprietary

It is also possible to estimate the size of proprietary models by comparing their price to that of open models. However, this method is highly uncertain because a price decrease can mean an optimization rather than a decrease in the number of parameters [25].

MoE models only activate the useful parameters

A MoE (Mixture of Experts) model is a type of model that does not use all of its parameters when it runs. This does not make it any less capable; on the contrary, it activates only the parameters needed to generate the response. For example, a MoE model with 300 billion parameters may activate only 30 billion of them, which makes it much less energy-hungry than a dense model with 100 billion parameters [26]. By activating a small number of parameters, MoE models reduce the energy consumption of processing a token.

Inference engines

An LLM's energy consumption during execution is not determined solely by the model itself: it also depends on the inference engine used [27]. An inference engine is, in a way, the software that runs an LLM at the moment you ask it a question. If the LLM were a car engine, the inference engine would be the system that organizes and controls its operation. Some providers optimize their models for certain inference engines [28].

Measuring the Environmental Impact of Generative AI

State of the Art

Today, AI models are made available as open-source or open-weights (downloadable, but with a confidential design process) by private organizations such as Meta, Mistral, Google, DeepSeek, or Alibaba. It is therefore theoretically possible to measure their environmental footprint with certainty.

For example, the ML.ENERGY Leaderboard [29] directly measures the electricity consumption of models using its Zeus tool [30]. This initiative is even cited by OpenAI [31].

However, the most powerful models are currently owned by OpenAI, Google, and Anthropic. These proprietary models are mainly accessible through APIs, which prevent external organizations from directly measuring their energy use. Google estimates that a median Gemini query consumes 0.24 Wh of energy, emits 0.03 gCO₂e, and consumes 0.26 mL (about five drops) of water. The energy impact per query is equivalent to watching television for less than nine seconds [32]. OpenAI's CEO claims that an average ChatGPT query consumes about 0.34 Wh of energy and 0.3 mL (6 drops) of water [33]. However, neither provider specifies the exact number of tokens per prompt, nor the number of parameters of the models used. This lack of transparency makes it impossible to interpret these values rigorously or to compare the impact of models.

Some players try to estimate the environmental impact of closed models by relying on approximations [34]. Independent analyses estimate that a query consumes between 0.3 and 29 Wh [35] [36].

Other nonprofit players have developed estimation methods covering a broad scope, based on estimates for closed models [37] [38] or on real data measured on open models [39].

However, although the professionalism of these organizations is not in question, these estimates must be interpreted with caution because they rely largely on assumptions that are difficult to verify. For example, a study [40] cited 526 times, including in articles from reputable scientific journals such as Nature [41], is based on a quote from a member of Alphabet's (Google's) leadership with no supporting evidence [42].

Tools and Calculators

To help you try to measure the environmental impact of generative AI, tools and calculators have been developed:

My Calculator for the Environmental Impact of Your Conversation with AI

Developed specifically to illustrate the best practices shared in the next chapter of this article, this calculator is designed to be simple to use and accessible to the general public. It is based on a restricted scope of the Ecologits methodology in which some hypothetical values have been replaced with measured values. Additional variables have also been added to highlight the levers for reducing the user's environmental footprint.

Try it right now by copying and pasting a few excerpts from your last conversation with an AI: https://felixmortas.com/ai-inf-calculator

This calculator, like any estimation method, has limitations:

• It does not account for invisible reasoning tokens. A future version could estimate their proportion relative to the number of visible output tokens, depending on the reasoning effort level.
• Conversational agents probably perform multiple processing passes, particularly in loops. The input text may therefore be processed several times. The calculator accounts for neither these loops nor the reprocessing of tokens they involve.
• The energy cost of an output token depends on the number of tokens previously generated. In the calculator, all output tokens are assumed to have the same energy cost [8].

Other Good Tools

• Zeus Project by ML.ENERGY: to directly measure the energy consumed on the machine [30], and the ML.ENERGY Leaderboard to compare the energy consumption of open models [29].
• An open, interlinked data model for building carbon footprint scenarios, improving data quality and transparency by design [43].
• CodeCarbon: a Python library to measure the machine's energy consumption (personal computer or server) in real time [44]. Be careful, as it does not account for code executed through APIs.
• EcoLogits by CodeCarbon: a web calculator and Python library to estimate the carbon footprint of generative AI through APIs, using the token as the unit of measurement [45]. The tool works well in synergy with CodeCarbon.
• Impact'IA by SNCF: a calculator with a broader scope than Ecologits, but with many assumptions that considerably increase the uncertainty [38].
• LLM Perf Leaderboard by Hugging Face: a performance comparator for open models, including energy per generated token [39].
• Other resources such as tools or articles are collected in the GitHub repository [46] of a member of the CodeCarbon organization: https://github.com/samuelrince/awesome-green-ai
• Sometimes, it is impossible to directly measure the energy consumption of machines. However, it is closely tied to the model's execution time [23], which makes it a usable parameter for measuring the environmental impact of a hosted LLM.

Reducing your environmental impact by adopting best practices

In this chapter, you will discover which best practices to adopt to reduce your environmental impact related to AI, and why applying them can even improve your efficiency.

There are best practices suited to two categories of audience:

• The end user: they concern how the AI application is used.
• The AI developer: they influence how the AI application works.

In both cases, these best practices aim to minimize your ecological footprint while optimizing your performance.

Some organizations, such as the UN, also propose reduction levers that will be presented in this chapter [5].

As a chatbot user

Prioritize a search on a search engine

If the answer you expect to your question is simple (for example, the population of a city or the family of a plant), favor a search on a search engine (Google, Ecosia, Bing, Qwant, Brave, DuckDuckGo).

If you have the habit of phrasing your question to your chatbot with keywords to save time, be aware that you can type these keywords directly into your search engine. The answer will be just as fast and available through several sources. Examples: "Largest planet solar system", "speed of light".

Google estimated that an average search on its search engine consumed 0.3 Wh of energy and emitted 0.2 gCO₂e in 2009 [47], but this value is certainly no longer valid. A recent study estimates the new values at 0.03 Wh and 0.02 gCO₂e, which is 10x less than before [48]. For comparison, Mistral AI estimates that a request sent to its Mistral Large 2 model with 400 output tokens emits 1.14 gCO₂e [22].

Warning: In your searches with Google or other engines, the automatic AI search feature (AI Overview) is enabled by default. You must disable it in the settings for this best practice to be valid and choose for yourself when to use AI for your searches.

Use a model with few activated parameters

When using a chatbot, favor the smallest model, with the fewest activated parameters. It is sufficient to perform many tasks accurately [49] [50].

Most AI providers disclose neither the exact name of the model used nor the number of parameters it contains. However, to guide you, be aware that models with names like "flash", "lite", "fast", "nano", "mini", "quick" or "small" are generally the ones that activate the fewest parameters per processed token.

Recommendations for choosing your model based on the task to perform:

• Small: delve deeper into a topic, rephrase or summarize a text, generate a snippet of basic code, classify, extract text.
• Intermediate: plan, design an architecture, generate code within a project, perform non-standardized processing.
• Large: solve a complex problem in mathematics, science or engineering, design a complex architecture, carry out complex planning, analyze voluminous files with contradictory sources.

As you may have gathered: large models are oversized for many use cases.

With GPT-5 models on ChatGPT, you cannot manually choose the model used. A first model, called a "router", automatically determines the size of the model that will process your message. For free users, all requests are sent to the smallest model [51].

To encourage the router to send your message to a particular model, you can include keywords such as: "Answer simply" or "Without reasoning" to use a small model. "Think step by step" or "Reason before answering" to use a more powerful model or reasoning [52].

Reduce the thinking effort

It is recommended to use the reasoning feature only when the answer to your request requires a complex, non-trivial analysis and must be broken down into several steps to guarantee the best possible quality. You can choose whether or not to enable reasoning on the Google, DeepSeek and Mistral chatbots.

Some models, such as GPT or Claude, allow you to set different effort levels. This setting determines the number of reasoning and output tokens it generates. While longer reasoning is often considered to lead to better results, this is not always the case. Performance tends to improve at first as effort increases, before reaching an optimal point and then, in some cases, decreasing beyond that threshold [53]. It is therefore preferable to favor a low to moderate effort level.

Prompt engineering

This section explains the importance of prompt/context engineering: how to provide useful context to the chatbot while eliminating noise (that is, unnecessary information) so that it accomplishes its task accurately and generates a response in the desired format.

According to the main model providers, including OpenAI [54], the optimal structure of a prompt relies on several key elements, notably:

1. Context: Often the longest part, which can be greatly reduced to minimize the number of input tokens and clarify the request.
2. Task: Generally formulated in one sentence.
3. Deliverable: Short, but essential to limit the number of output tokens.

Optimize the context to reduce input tokens

We saw earlier that input tokens also influence the energy consumption of the request [10]. It is therefore recommended to limit the context to reduce the environmental impact, but also to improve the quality of the response.

Optimize the deliverable to reduce output tokens

We saw earlier that the energy impact of tokens generated as output is greater than that of input tokens [7]. It is therefore generally more energy-efficient to lengthen the prompt sent in an attempt to reduce the length of the response.

In most cases, a short and concise response is enough and avoids getting lost in unnecessary explanations.

Examples of instructions to limit the length of the response:

• To correct spelling mistakes in a long text: "Only indicate the corrections to make, without explanations and without copying the entire text."
• To fix code: "Only rewrite the parts to modify without reproducing all of the code. Do not provide explanations."
• To rephrase a paragraph in a text: "Only rewrite the paragraph to modify, without copying the rest of the text."

It is up to you to determine what you need to get the expected response, and nothing more if it is not necessary.

Tip: Some chatbots, such as Claude, let you select the type of response. Favor the "short" or "concise" options.

Conversely, the use of certain action verbs such as "justify," "explain," "analyze" or "recommend" tends to increase the amount of text generated [55].

Stop the generation

If, right from the start of the chatbot's response, you see that it does absolutely not match what you expect, interrupt it immediately by clicking the "Stop" button (generally represented by a filled square ⏹️).

This simple action reduces the number of output tokens generated by avoiding a useless response.

Edit the initial request rather than sending a new message

When the generated response is incomplete, interrupted or unsatisfactory (an element forgotten in the context, an imprecise detail, a part to remove), prefer editing the initial message rather than sending a new one to refine your request.

With each new message sent, the entire conversation history is sent again to the model. This considerably increases the number of input tokens, and therefore the environmental impact. Moreover, an overly long history introduces noise (unnecessary information), reducing the quality of the responses. The more limited and relevant the input tokens are, the better the chatbot's response will be.

Concrete example: If the chatbot's response does not take an important element into account, do not send a new message asking it to start its response over while taking an additional parameter into account. Prefer editing the initial message to integrate this detail. That way, the response will be regenerated with a more complete context, without making the history heavier.

Special case: small corrections If the response is long and requires only a small modification:

• Do not edit the initial prompt: this would regenerate a full response and have a greater impact related to output tokens.
• Ask the chatbot to correct only the relevant part without rewriting everything. Example: "Only correct the third paragraph, without copying the rest of the text."

This best practice requires finding the best compromise between:

• Regenerating a response by editing the initial message, which keeps the context concise but may generate more output tokens;
• Adding a message, which reduces output tokens but increases the amount of input tokens with each new message.

Conversation engineering: create branches

To maintain a minimal and useful context, an effective technique is to create branches in a conversation. Not all the information exchanged with the chatbot is necessarily useful for answering a new request.

If you ask the chatbot to clarify something in its response, but your next message does not need that clarification, it is better to edit the initial question rather than add it to the conversation. This way you can create distinct branches for each topic while limiting the context to the strict minimum.

Concrete example:

1. You ask a chatbot a question on a specific topic.
2. It answers by addressing several points, some of which are unclear to you.
3. You ask it to go deeper on point 1.
4. To then go deeper on point 2, you edit the initial prompt to ask it directly for explanations on that point, rather than asking a new question in the conversation.
5. Finally, if you want to take action based on the initial response, ask it to plan the project by editing the prompt dedicated to point 2, rather than sending a new question.

At this stage, your conversation has 3 branches:

• The first: your initial question on the topic, and a deeper look at point 1 that you had not understood.
• The second: your initial question on the topic, and a deeper look at point 2 that you had not understood.
• The third: your initial question on the topic, and the planning request.

Each branch therefore deals with a specific aspect of the project, making it possible to:

• Keep a single conversation for the whole project.
• Avoid the context being polluted by unnecessary information.
• Save the number of tokens sent to the model.
• Create a hierarchical and specialized prompting method.

Create a new conversation for each new topic

We saw that each new message sent causes the entire conversation history to be sent again to the chatbot. It is therefore preferable to start a new conversation when you want to address a topic unrelated to the previous one [56].

You have two options:

1. Create a new conversation dedicated to the new topic.
2. Edit the first message of the existing conversation to introduce the new topic.

By choosing the second option, you reduce the number of conversations in your history, which helps maintain a clean and organized environment.

You can also reuse a chatbot's response by injecting it into a new conversation dedicated to another task, rather than continuing in the initial discussion. Once again, this approach limits the size of the context.

Delete unnecessary conversations

When you send a message to a chatbot, before even your message history, several elements are included: the developer prompt, the system prompt, contextual information (country, time, language, browser, etc.), as well as a summary of each of your saved conversations [57]. These summaries add context that is not always useful for the chatbot. Delete your old conversations when they are no longer useful to you.

Clear the long-term memory

When you ask a chatbot to remember a piece of information during a conversation, it will systematically be included in new discussions. This is called long-term memory [58]. To optimize it, use the dedicated menu if there is one; otherwise, create a dedicated conversation in which you ask the chatbot to list the information it has memorized, then delete what is no longer relevant.

As a company developing an agent

Prioritize algorithms and classical AI over generative AI

When it is enough, favor less complex technologies. In many cases, simple decision algorithms or classical prediction or classification AI are sufficient.

Use small specialized models

We saw earlier that the number of activated parameters of a model has a significant influence on the environmental impact of processing a token.

Prioritize small, specialized models. This sometimes even yields more accurate results than large generalist models [50] [59] Models already specialized on a task through fine-tuning are made available on Hugging Face. Favor them rather than carrying out new fine-tuning.

Prompt engineering to reduce the number of output tokens

In the same way that the user can limit output tokens, the developer can explicitly specify the expected form of the response in the system prompt. The model takes it into account even before the user's first request, and it systematically reduces the number of output tokens.

Context engineering to reduce the number of input tokens

Many techniques exist to limit the context by keeping only the useful information.

Examples:

• After a conversation of 10 messages, a small model can be called on to summarize the exchanges. This summary can replace the history in subsequent exchanges.
• In a multi-step process, the steps can be broken down so as to provide the model with only the strictly necessary information at each step.

You can devise many other methods to limit the context sent to the model.

Fine-tuning vs Few-shots-examples

For a model to produce an output that matches expectations, it is possible to add examples or to perform fine-tuning. If the agent will not be used intensively*, it is recommended to add examples to the context* (one-shot or few-shots). On the other hand, for massive use, it is preferable to reduce the number of input tokens by using fine-tuning. It lets the model understand the type of response expected without needing to be given examples with every request. However, fine-tuning has a high environmental and financial cost.

Choosing between few-shots and fine-tuning To determine the threshold beyond which fine-tuning becomes more cost-effective, you can:

1. Convert the instructions for the task and the few-shots into tokens.
2. Estimate the cost per request based on this number of tokens.
3. Compare the cumulative cost of all requests with few-shots to the cost of all those without few-shots plus the fixed cost of fine-tuning.

When the total cost of requests without few-shots plus fine-tuning is lower than that of requests with few-shots, opt for fine-tuning.

Host the model in a data center with low energy and water impact

When you decide to host your model yourself with a public cloud provider, you can select a region with a good energy and water score: low emission factor, low PUE and WUE all year round.

Carbon emissions perspective

Referring to the data provided by Ember Energy, preselect a country with a low emission factor such as Iceland, Norway, Switzerland or France.

The main cloud providers list the location of their data centers by region:

• Amazon Web Services: https://aws.amazon.com/fr/about-aws/global-infrastructure/regions_az/
• Microsoft Azure: https://learn.microsoft.com/en-us/azure/reliability/regions-list?tabs=all
• Google Cloud Platform: https://datacenters.google/locations/
• Salesforce: https://help.salesforce.com/s/articleView?id=000396845&type=1
• OVH: https://www.ovhcloud.com/en/datacenter/

Once the region is preselected, take the provider's PUE into account. You can find these values by region for the main cloud providers:

• Amazon Web Services: https://sustainability.aboutamazon.com/products-services/aws-cloud
• Microsoft Azure: https://datacenters.microsoft.com/sustainability/efficiency/
• Google Cloud Platform: https://datacenters.google/efficiency/
• OVH: https://www.ovhcloud.com/sites/default/files/external_files/kpis_fy25.pdf

Water consumption perspective

Check that the preselected region is not at risk of drought. To assess risks related to water availability, the World Resources Institute (WRI) offers a map of regions at high risk of drought: https://www.wri.org/aqueduct/tools.

Finally, look at the WUE. When this indicator is missing, consider the WUE of another provider's region:

• Amazon Web Services: https://sustainability.aboutamazon.com/products-services/aws-cloud/ ;
• Microsoft Azure: https://datacenters.microsoft.com/sustainability/efficiency/ ;
• Google Cloud Platform: link https://services.google.com/fh/files/misc/measuring_the_environmental_impact_of_delivering_ai_at_google_scale.pdf ;
• OVH: https://www.ovhcloud.com/sites/default/files/external_files/kpis_fy25.pdf.

Inference engine

Some providers optimize their models for specific inference engines [28]. The appropriate engine may be indicated in the model card.

Use the cache

The cache feature stores and reuses the attention computations as well as the tokens of a prompt that has already been processed, thus avoiding recomputing everything with each request.

Use cases optimized with the cache:

• Repetition of a large context: for example when you frequently send the same documentation in the context, or the full history of a conversation (the case of a chatbot).
• Autonomous agents: agents making successive calls relying on the same system prompt (base instructions, available tools, guidance examples) and a shared state.
• Code assistants: analysis of a large code repository that is identical with every message.

For a cache to be effective, requests must be close together in time and the prompt prefix (the part to be cached) must be strictly identical from one request to the next. The slightest space or character changed at the beginning of the text will invalidate all or part of the existing cache.

Batch processing

Batch processing consists of sending a large number of requests to be processed simultaneously. This method optimizes model inference and significantly reduces the energy and financial cost [60].

Model providers via API generally offer batch processing at half price compared to standard processing. Although there is no precise data in the literature quantifying this reduction, it can be assumed that the price variation is correlated with that of the energy impact.

Periodically send all requests in a batch if you do not need the model's responses in real time, the volume of requests is large and they are independent of one another.

Recent models

Stay informed about new models because some may offer performance equivalent to that of your current model while having a lower impact, thanks to an optimization or an innovation.

Global overview of LLMs and their performance [61]

For image generation, for example, one study suggests that the choice of model type should take into account the expected output length: autoregressive models (the most widely used) remain preferable for short responses (fewer than 1024 tokens), while diffusion models offer undeniable advantages for longer generation tasks [62].

Be careful: changing models can trigger a new development phase (evaluation, fine-tuning) involving a significant environmental impact. Moreover, optimizing a technology tends rather to increase its overall impact because it becomes inexpensive and is therefore used much more. This is the rebound effect [63].

"Quantization": reducing the precision of calculations reduces energy needs

"Quantizing" a model consists of reducing the precision of its calculations. It goes from floating-point numbers to integers. By reducing the precision of calculations, it is possible, under certain conditions, to reduce the amount of energy consumed by the model [64] [60]. Of course, this reduction in decimals leads to a loss of precision in the calculations. But today, it is possible to use "quantized" models while maintaining very good performance.

Distillation: when the student surpasses the master

One technique for reducing the size of models and, consequently, their impact at runtime, is knowledge distillation. This is the technique that was used to create DeepSeek with a fraction of the energy cost of ChatGPT [65]. It consists of using a very large teacher model to generate data that will then be used to refine the training of another, much smaller model, called the student model. The student model can thus acquire knowledge similar to that of its teacher, while requiring far fewer resources to run [66].

Pruned models (Pruning)

Pruning consists of removing parameters from the model. This technique greatly reduces size, and therefore the cost of running the model, while maintaining good performance [67].

Conclusion

Summary

Before reducing your environmental impact from generative AI, you need to understand the factors that influence it. They can be grouped into 3 categories: the model, its hosting, and the tokens.

Tools exist to measure the impact of open models with precision and certainty. The most powerful proprietary models, such as those from OpenAI, Google, or Anthropic, are black boxes and do not allow a certain measurement to be established. Independent organizations are developing estimation methods based on many unverifiable assumptions, but which can be relied on to obtain orders of magnitude.

The calculator I developed alongside this article lets the end user of a chatbot quantify how much their impact is reduced by adopting good practices: Environmental Impact Calculator for my conversation with the AI

At their level, the three main levers they can pull instantly are:

• prioritizing a traditional web search, by disabling automatic AI searches.
• choosing a small model with low effort, suited to the task at hand
• controlling the amount of tokens processed as input and generated as output.

As a developer, the range of action is broader and touches on concepts that are invisible to the end user.

At every level, it is possible to drastically reduce the environmental impact of your use of AI, while also improving the quality of the responses produced.

Opening

This article is a synthesis of the knowledge I have accumulated over a year and a half of research, as well as my ongoing monitoring of the subject. I would especially like to thank Boris RUF, who shared his knowledge and skills with me throughout this period, while I was working as a Data Scientist at AXA Group Operations. I would also like to thank Céline LESCOP, who gave me the opportunity and the desire to delve deeper into the subject of eco-responsible digital technology by allowing me to take part in the Digital Sustainability program.

If you would like to explore the subject further, train your business and IT teams in good practices, carry out an environmental assessment of your existing tools, or design new tools, please do not hesitate to contact me. I would be delighted to work with your organization to support you in this effort.

Finally, I remain open to your feedback, constructive criticism, and suggestions for improvement, both on the content of this article and on the associated tool.