Compute Cast

Inspiration

password to run benchmark is: hackathon300

As a researcher who has trained deep learning models on shared servers, I’ve often started a job with more questions than answers: Will it fit in GPU memory? How long will training take? Could my job interfere with someone else’s work?

I understood my models, but GPU optimization felt unfamiliar. Figuring out the right configuration often meant trial and error, and moving to cloud compute introduced another concern: how much would that experimentation cost?

I built Compute Cast to make those decisions easier. The goal is to help people understand their compute needs before committing to a full training run—and understand the changes that could make their training more efficient.

What it does

Compute Cast helps users estimate GPU memory requirements and training runtime for supported PyTorch model configurations, with the broader goal of combining estimates, benchmarks, and cloud pricing to support cost planning.

The experience centers on exploring tradeoffs. Users provide model and training information, select hardware, and investigate how configuration changes affect estimated resource requirements. Suggested optimizations are intended to be highlighted and explained, helping users understand what changes, why it matters, and what tradeoffs to consider.

Unlike a one-time AI code review, Compute Cast is designed around an interactive comparison: adjust a supported setting, inspect the estimated impact, and make a more informed decision.

The initial estimator focuses on a specific single-GPU GPT-2 training setup. Its analytical estimates are currently uncalibrated, making benchmarking an important next step toward reliable predictions.

How we built it

I built Compute Cast through a combination of hands-on coding, Claude Code assistance, and iterative human review.

The work involved translating model and training configurations into resource estimates, developing the application interface, and connecting the frontend to the backend. I also explored Docker, cloud-based LLM services, and Nebius integration.

An important design choice was to start with a narrowly supported training configuration. That made it possible to examine the estimation assumptions carefully before expanding to more architectures and execution strategies.

Challenges we ran into

The biggest challenge was understanding what it actually takes to estimate training resource usage. Parameter count is only part of the picture: memory also depends on gradients, optimizer states, activations, temporary buffers, and implementation details. Runtime introduces further uncertainty because theoretical GPU performance does not directly translate into training speed.

Another challenge was deciding what to ask users. The application needs enough information to produce a meaningful estimate without turning the experience into a long, confusing configuration form. That meant thinking carefully about which values could be extracted, which needed user input, and which assumptions should be visible.

Connecting the backend to the frontend was also a learning curve. Integrating Nebius added practical questions about authentication, launching compute, and controlling charges during development.

Accomplishments that we're proud of

My experience is primarily in Python and backend development, so building toward a complete web application pushed me beyond familiar territory.

I’m proud of turning a problem from my own research experience into a working analytical prototype and a clear product direction. Along the way, I gained experience with frontend development, Docker, and cloud-based services.

I’m also proud of the emphasis on explanation. The goal is to give users more than a number: it is to help them understand where resource usage comes from and how their decisions affect it.

What we learned

Building Compute Cast taught me how the pieces of a web application fit together, from user inputs and frontend interactions to backend calculations and returned results.

I also developed a deeper understanding of GPU memory and training performance. A useful estimator needs explicit assumptions, a clearly defined scope, and validation against real measurements. Communicating those limits is part of making the tool useful.

Working with AI coding tools reinforced the value of iterative review: generating code is one step, while checking its assumptions, behavior, and integration remains essential.

What's next for Compute Cast

The immediate priority is to benchmark the estimator against real training runs, refine its assumptions, and make comparisons between predicted and measured results easy to understand.

From there, I want to:

• Support more model architectures and training methods, including fine-tuning and additional precision and memory-saving options.
• Expand cloud integrations, including AWS, and improve hardware and cost comparisons.
• Add more advanced optimization strategies, such as data and pipeline parallelism, with explanations of when each approach is appropriate. Explore MIG partitioning for supported hardware and shared workloads.
• Improve recommendations, helping users choose configurations based on their memory limits, budget, or deadline, with citations for specialized methods.
• Build a local CLI companion that can inspect relevant model, training, environment, and deployment files, collect dataset statistics, and optionally run short profiling jobs. This richer context could reduce manual input and improve estimates.

The long-term goal is to make compute planning an understandable part of the research workflow—helping people spend less time troubleshooting resource limits and more time experimenting.

Built With

• github
• nebius
• python
• pytoch
• react
• render
• tailwind