Sustainability
An overview of the sustainability tracking efforts associated with the CCV AI tools with an exploration of the methodology used to track carbon numbers on our services.
Last updated
Was this helpful?
An overview of the sustainability tracking efforts associated with the CCV AI tools with an exploration of the methodology used to track carbon numbers on our services.
Last updated
Was this helpful?
As AI tools become more prominent in our society, the conversation around the sustainability of AI tools has grown. In order to understand how CCV's AI tools align with Brown's commitments to sustainability, we try to measure the environmental impact of our tools. In the spirit of the Office of Sustainability and Resiliency's Campus as Living Laboratory initiative, we share our environmental impact analysis with the people who use our tools.
The climate impact of each tool is different and requires a bespoke analysis. As such, the rest of this document will explore the methodology used to collect data for the individual tools we've been able to gather data for so far.
This is a living document. We will update this page as our methodology evolves.
The ChatCCV Transcribe tools allow users to get AI transcriptions for uploaded audio files. On the backend, there are two different ways an audio file can be transcribed, both of which require different climate analyses:
Azure Transcription
Whisper (OpenAI) Transcription
For both transcription methods, the digital emissions estimation includes power used to run the models, but does not include network transfer, or web application hosting. The Azure Transcription analysis includes a measure of the embodied carbon of compute hardware used. We are working to add embodied carbon to the Whisper Transcription digital emissions estimate.
The Azure Transcription relies on the Azure AI Speech to Text Service. This is a hosted service. We do not have information on the servers used for model inference; we rely on the carbon emissions reporting of Azure to do our analysis.
All the major public cloud providers have started to expose carbon emissions data. Each public cloud provider varies in their analysis and implementation. In Azure, the carbon emissions data are exposed via the Azure Carbon Optimizer API. Details on the Carbon Optimizer API methodology can be found .
The Azure Carbon Optimizer API allows users to query for carbon emissions numbers on a month-to-month basis. At the beginning of each month, you can query for the amount of carbon emitted for all Azure transcriptions in the previous month. We can also query our database for the total number of seconds transcribed across all Azure transcription jobs in that same month.
This allows us to compute the carbon emission per second of audio transcribed:
Then, by multiplying this value by the duration of a specific job, we can estimate the carbon emitted by that job.
This method can also be applied to estimate the carbon emissions for prospective jobs. When a job is being created, we know the number of seconds of audio in that job and can pass that as the duration value to "Carbon Emitted By Job" equation. This assumes that the rate at which carbon is emitted during a job is mostly the same, month to month. And while there's no guarantee of that, it does give a decent estimate until Azure provides better data.
This method assumes that carbon emissions are distributed equally across all transcription jobs. It is reasonable to assume this, but possible this might not be the case. Unfortunately, the opacity of the carbon reporting from Azure doesn't allow for more granular insight.
Our analysis includes both the power consumed during the transcription process and an estimation of the embodied carbon (carbon emitted during manufacturing, transportation, and disposal of a product) of the underlying compute hardware. Network transfer and web application hosting are not included in this estimate.
For each transcription request using the Whisper model, we initiate a carbon tracking process. This process monitors the energy used by the CPU, GPU and memory during the transcription. Once the transcription is complete, we calculate the total operational carbon emissions based on the recorded energy consumption and the duration of the job.
In addition to the operational emissions, we also estimate the embodied emissions associated with the hardware utilized for the Whisper model. Our estimation of embodied emissions considers the following components:
Memory (RAM and GPU Memory): We estimate the embodied emissions of both system and GPU memory based on industry reports detailing the carbon intensity of memory production.
Processors (CPU and GPU): We utilize die size as a proxy for the complexity and resource intensity of processor manufacturing. We apply factors derived from lifecycle assessments of semiconductor manufacturing to estimate the embodied emissions.
The total embodied carbon for a specific transcription job is then scaled based on the fraction of the server's estimated lifespan (assumed to be 5 years) that the job utilized. This provides a proportional estimate of the embodied carbon attributed to that specific transcription.
The final carbon emission estimate for a Whisper transcription job is the sum of the operational emissions recorded during the transcription and the scaled embodied carbon of the hardware. This total carbon emission value is then associated with the specific transcription job.
It is important to note that while this method provides a more comprehensive estimate by including embodied carbon, it still relies on certain assumptions and industry averages due to the complexities and lack of granular data on the specific hardware and manufacturing processes involved in the cloud infrastructure.
Azure and Whisper carbon emission should not be compared directly. Azure's data, derived from their Carbon Optimizer API, primarily reflects operational emissions, while our Whisper analysis includes both operational and estimated embodied carbon. This difference in scope, along with variations in methodology and data granularity, makes direct comparison difficult, if not impossible.
We're currently working on collecting carbon data for Google Gemini transcriptions.
We're currently working on collecting climate data for LibreChat.
We're currently working on collecting climate data for Ask Oscar.
To calculate the emissions for Whisper transcriptions, we leverage the library in an offline mode. This allows us to directly measure the energy consumption of the computational resources used for each transcription job.
Other Componkents: To account for the embodied carbon of other essential server components like the mainboard and power supply units (which are not explicitly calculated), we apply an additional factor of 20% to the total embodied emissions. suggests that the mainboard and processor combined account for >50% of the total embodied emissions. Therefore, a conservative scaling factor of 20% was applied to estimate the embodied emissions of these other essential parts.