Greenference

What is Greenference?

Greenference is a French company, Greenference SAS, building European AI inference infrastructure around one idea: compute should sit close to both European users and renewable generation, rather than being placed wherever capacity happens to be cheapest.

It is worth being precise about what that means today and what it means later, because the two are different and the distinction is the honest part of the story.

Greenference at a glance

Training is an event, inference is not

AI is usually discussed as a software problem. Better models, faster GPUs, lower token prices. It is quietly becoming an energy problem as well, and the part that consumes energy is no longer the part most people talk about.

Training a model is an event. It is enormous, it is expensive, and then it is over. Inference is not an event. Every chatbot reply, every retrieval query, every agent step and every generated image is a request that has to be served, and that keeps happening for as long as the product exists. As AI moves from experimentation into production, the electricity bill stops tracking research and starts tracking usage.

Energy as a routing dimension

Multi-provider AI began with one question: which model gives the best result. Then came cheaper, then faster, then which one satisfies data residency.

Energy is a plausible next axis, because not every request needs the same infrastructure. A latency-sensitive request needs a GPU close to the user. A nightly batch job does not, and could in principle run where and when clean power is available. A regulated workload has to stay inside a jurisdiction whatever else is true.

Once you can express those differences in a request rather than in a procurement cycle, orchestration stops being model selection and becomes an infrastructure decision.

What runs today, and what is being built

Today

Inference is served from European data centres on rented infrastructure. Its signed data processing agreement commits to processing inside the European Union only: a machine whose location cannot be established is not used, and if no EU capacity is available, the request fails rather than being served elsewhere. Greenference also publishes a data processing agreement, a zero data retention policy and a Customer Data Bill of Rights, all available on its legal pages. That documentation is more explicit than most providers of any size put in writing.

Being built

The longer-term plan is a network of modular, off-grid sites, which Greenference calls Sunverters: 200 kW containers powered by on-site solar and battery storage, scaling to 1 MW per site, with inference scheduled around each site's solar peak. Greenference describes this as concept stage, with no site deployed yet and a proof of concept as the first step.

Infrastructure takes time to build. The reason it is worth talking about now is that the constraint it addresses is already here, and the placement decisions being made today are what the sites will plug into.

Greenference models on Eden AI

All twelve are open-weight models, from the DeepSeek, GLM, Qwen, Gemma and gpt-oss families. Nothing proprietary, so anything you build on one of them can move to another host if you need it to.

Current pricing sits in the Eden AI catalogue rather than here, because it changes. GET https://api.edenai.run/v3/models is public and needs no key.

Greenference pros and cons

When should you choose Greenference?

Choose Greenference if:

You have a class of traffic where the infrastructure matters as much as the model. Batch jobs, scheduled processing and anything that does not have a user waiting are the obvious candidates.

You want European processing backed by a document rather than a claim. The DPA and the retention policy are published and can be read before you commit to anything.

Open weights are a requirement. All twelve models are open, so you are not locked to this provider by your own choice of model.

Consider another provider if:

You need very large burst capacity from day one. Greenference serves from rented capacity that it expands as demand grows.

You need a frontier proprietary model. That is not what this provider is for.

You need the renewable sites today rather than on the roadmap. They are at concept stage, and until they are deployed the energy argument is about where compute is placed.

Why use Greenference through Eden AI?

Energy-aware routing only becomes real when you can apply it to one class of traffic at a time rather than to your whole stack at once. Because the provider is one field in the request, a team can send a specific workload to Greenference without moving anything else.

That matters more here than usual. Energy-aware routing is something you adopt one workload at a time, starting with the traffic where it costs you nothing to try. Sending a nightly batch is a string change.

Where to start

Look at your traffic before you look at providers. Separate what is genuinely latency-bound from what only runs on a schedule, because the second group is almost always larger than teams expect, and it is the part where where and when the compute happens is negotiable.

The next constraint on AI may not be finding a better model. It may be finding enough clean electricity to run the one you already have.

Frequently asked questions about Greenference on Eden AI