Note to JUDGES: Our presentation slides are available in the "Try it out" links below.
Inspiration
We love AI and use tools like ChatGPT and Gemini daily. But as we dove deeper into our major, we stumbled upon a shocking statistic: a single AI query can consume significantly more energy than a standard Google search.
While the world focuses on the carbon footprint of training, the hidden cost of inference (daily usage) is silent and growing. We calculated the disparity:
$$E_{AI_Query} \approx 10 \text{ to } 25 \times E_{Google_Search}$$
Every time we ask a simple question, we burn energy equivalent to powering an LED bulb for several minutes. We realized that developers and users have zero visibility into this cost. We built Eco-Query to solve this: first by making the invisible cost visible, and next by automating the solution through intelligent routing.
What it does
Eco-Query is currently a powerful AI Energy Auditor with a concrete roadmap to become a fully automated Green Router.
1. Current Functionality (The Prototype):
- Complexity Analysis: It analyzes the user's prompt in real-time using a heuristic algorithm to detect complexity factors (e.g., reasoning requirements or multimodal needs).
- Energy Prediction: It utilizes a machine learning model to predict specific usage: $$\text{Total Energy} (kWh) = f(\text{Token Count}, \text{Model Size}, \text{Complexity})$$
- Real-World Context: It translates abstract carbon numbers into relatable metrics, like "smartphone charges" or "km driven by car," to drive user awareness immediately.
2. The Vision (The Goal): The system is designed to feed these prediction metrics into a Reinforcement Learning (RL) Agent that will dynamically allocate the prompt to the greenest available data center.
How we built it
We built the core estimation engine using Python and Flask.
- The Prediction Engine: We implemented a custom Random Forest Regressor using
scikit-learn. This engine analyzes features like prompt length, token count, and keyword complexity to output a precise "Energy Result" (e.g., $0.55 Wh$). - Synthetic Data Generation: Since proprietary energy data is scarce, we built a simulation engine to generate a synthetic dataset based on research papers regarding GPU energy consumption per token. This allowed us to train our model effectively.
- The Logic: We developed a complexity scoring algorithm (scaled 1-10). If a query requires "Reasoning," our model applies a penalty factor to the energy calculation: $$E_{final} = E_{base} \times (1 + \text{ComplexityPenalty})$$
- The Frontend: We built a clean interface using HTML/CSS that allows users to test prompts and visualize the "Real-World Equivalents" of their AI usage immediately.
Challenges we ran into
- Data Scarcity: There is no public API that outputs the exact wattage of a specific prompt. Generating a realistic synthetic dataset to train our Random Forest model was our biggest technical hurdle.
- Defining "Complexity": Teaching a machine that "Explain quantum entanglement" (short but hard) is more energy-intensive than "Write a long story about a cat" (long but easy) was difficult. We solved this by implementing semantic keyword analysis in our backend logic.
Accomplishments that we're proud of
- Functional Prototype: We successfully built the "AI Prompt Energy Tester" as seen in our project images. It works! You can type a prompt and instantly see the carbon impact.
- Granular Metrics: We aren't just guessing; our system differentiates between model sizes (e.g., 13GB vs 70GB) and complexity levels, giving a nuanced energy report.
- The Foundation: We have successfully built the "Sensor" layer (Prediction). This is the critical first step required to build the "Actuator" layer (Routing).
What we learned
- The "Inference" Problem: We learned that inference actually accounts for the majority of an AI's lifecycle carbon footprint, often outweighing training costs over time.
- Full Stack Integration: We learned how to connect a machine learning model (backend) to a web API (frontend) and handle real HTTP requests.
- Collaboration: We successfully managed our code using Git and GitHub, learning to handle branches and merges as a team.
What's next for Eco-Query
This is our major goal. Now that we can accurately predict the cost, we are moving to Allocation.
- RL-Based Data Center Allocation: We are building a Reinforcement Learning agent that takes the energy prediction from our current tool and decides where to run the query.
- Grid-Aware Routing: The RL agent will optimize for Carbon Intensity ($gCO_2eq/kWh$). If the energy grid in a specific region is currently powered by coal, but another region is powered by wind, our system will route the request to the cleaner data center.
- Closing the Loop: We aim to transform Eco-Query from a "Tester" that shows you the cost, into a "Router" that automatically saves the energy for you.
Log in or sign up for Devpost to join the conversation.