Provide estimates for AI models

[jnioche]

AWS provides access to AI models via https://aws.amazon.com/bedrock/
This is then billed and part of the CURs, we should be able to integrate existing approaches to provide estimates.

[jnioche]

https://ecologits.ai/ can be a starting point

see also

Boavizta BoAmps
https://huggingface.co/spaces/boavizta/BoAmps_report_creation

and https://tailpipe.ai/methodology/calculating-the-carbon-emissions-of-llm-usage-tailpipes-methodology/
which is based on How Hungry is AI? (Jegham et al., 2025).

[dpol1]

Hey @jnioche,

I find this issue incredibly interesting not just from an architectural perspective, but from an ethical one as well. Out of personal curiosity, I spent this weeks obsessively searching answers, and I ended up mapping out a possible implementation.

I think EcoLogits might be the most pragmatic starting point for SPRUCE right now.

Here is why: EcoLogits already calculates emissions per generated token ($gCO_2e/token$) for major models. This maps perfectly to the AWS CUR data, which logs the exact model used (e.g., anthropic.claude-v2 in product/modelId) and the number of tokens (lineItem/UsageAmount).

Since EcoLogits is a Python library and SPRUCE is Java, we obviously can't use it directly. However, we could use an approach very similar to what is already done in BoaviztAPIstatic: we could extract the EcoLogits coefficients into a static JSON or CSV file bundled with SPRUCE.

Then, we could build a new EnrichmentModule (e.g., ecologits.LLMInference) that simply:

1. Filters for Bedrock usage in the CUR.
2. Matches the model ID with our static dictionary.
3. Multiplies the tokens by the coefficient to populate OPERATIONAL_EMISSIONS and EMBODIED_EMISSIONS.

BoAmps is also a great candidate since SPRUCE already integrates with Boavizta, but it seems a bit younger for programmatic extraction right now. Tailpipe's methodology is solid, but EcoLogits seems to have the most "ready-to-use" open data.

Just sharing my opinion from this research! Let me know what you think of this approach. I'm not trying to hijack the issue, but if you think this is the right path, I'd be more than happy to help extract the data, draft the Java module, or work on a PR together!

[jnioche]

hi @dpol1

Thanks, by all means, feel free to have a go at writing a PR for this. The overall approach above is correct, I would possibly look at the pricing_unit which should have a value like 1K tokens to check that we are not missing anything.

There is an API planned for Ecologits, whether it will give what you need or not is uncertain. There are parts of the calculations we still want to control like PUE, carbon intensity etc...
Some of the energy estimates will have to be taken with a pinch of salt, see mlco2/ecologits#210

The static files sounds like the correct approach. Whether we need to reimplement the logic from Ecologits or not depends on what you find, e.g. can it take input tokens as input etc...

I would use Ecologits and https://huggingface.co/spaces/genai-impact/ecologits-calculator first to get a sense of what the results look like and what we can use from their code.

Thanks again

[dpol1]

Moorning @jnioche,

I completely agree. To keep SPRUCE in control of the grid intensity and PUE, we shouldn't extract the final $gCO_2e$ from EcoLogits. Instead, the static file should provide the Base Energy (kWh) and Embodied Emissions per token.

I was thinking of starting with a static JSON structure like this:

{
  "anthropic.claude-v2": {
    "energy_kwh_per_1k_input_tokens": 0.00015,
    "energy_kwh_per_1k_output_tokens": 0.00080,
    "embodied_co2e_g_per_1k_tokens": 0.005
  }
}

Is that reasonable for you? Let me know :)

[jnioche]

Sounds good. Maybe try to keep the CUR specific part separate from the core logic so that the latter can be reused when we look at Azure or GCP

[dpol1]

Hey @jnioche, quick question before I go further — for the package structure, I was thinking of creating com.digitalpebble.spruce.modules.ecologits to stay consistent with the existing boavizta and ccf packages. But since you mentioned keeping the core logic reusable for Azure/GCP, would you prefer something more generic like com.digitalpebble.spruce.modules.llm instead? Just want to make sure I'm heading in the right direction before structuring the classes

[jnioche]

Hey @jnioche, quick question before I go further — for the package structure, I was thinking of creating com.digitalpebble.spruce.modules.ecologits to stay consistent with the existing boavizta and ccf packages. But since you mentioned keeping the core logic reusable for Azure/GCP, would you prefer something more generic like com.digitalpebble.spruce.modules.llm instead? Just want to make sure I'm heading in the right direction before structuring the classes

I would have it all in com.digitalpebble.spruce.modules.ecologits for now, for consistency with the other modules.
What I had in mind was to have the core logic in one class and a separate class for its use with CURs.

Later on we would split them into the following packages:

• com.digitalpebble.spruce.modules.ecologits: with the core code
• com.digitalpebble.spruce.modules.ecologits.aws : with the AWS specific code
• com.digitalpebble.spruce.modules.ecologits.azure: ....

Makes sense?