Mercedes-AMG PETRONAS F1 Team turns race-day pressure into speed with Microsoft Azure

The call that can win or lose a race

A dozen laps remain in a Formula 1 race and a storm is rolling in. The car is running at the front but the soft tires have minimal grip. One person on the pit wall has seconds to make the call that decides the race: pit now for fresh tires or stay out and trust the call.

That is Joey McMillan, Lead Race Strategist, Mercedes-AMG PETRONAS F1 Team. He doesn’t drive the car, and he didn’t build it; his job is to read the race as it unfolds and choose the moment while every rival makes the same bet against him.

What makes it hard is a rule that has nothing to do with driving. Every Formula 1 team races under the same budget cap, a rule that limits teams to roughly $215M per season, rewarding smarter innovation over bigger budgets. No team can spend its way to a better answer. The edge belongs to whoever does more with less and decides fastest, and the right technology can bring the decision speed necessary to win.

That one problem, more performance without more money, shows up everywhere: on the pit wall, where countless outcomes are weighed in the time it takes to drive a lap, on the car itself, where engineers seek insight without added weight, and across the business, where every investment must earn its place under the cost cap. 

Less hardware. More insight.

Every physical sensor on a Formula 1 car must justify more than the data it captures. It adds mass, wiring, complexity, and another trade-off for a team trying to protect lap time under a hard cost ceiling. As Michael Taylor, IT Director, Mercedes-AMG PETRONAS F1 Team, puts it, “Sensors carry weight, and weight, unfortunately, is a lap time penalty.” So the team asked a sharper question: which readings could be gathered from data the car already produces, instead of measured by another part bolted to the chassis?

The answer took shape in software. The Mercedes-AMG PETRONAS F1 Team used Azure Kubernetes Service (AKS) to help develop a virtual sensor: a model that reconstructs a sensor reading from data the car already generates, rather than requiring additional hardware. By modeling those readings from existing telemetry streams, the team can reduce the need for physical sensors while still giving engineers the insight they need. The proof of concept is complete, and the team is now working toward production deployment.

The team trains and serves the virtual sensor models on AKS graphics processing units (GPUs). The solution draws on Azure and Microsoft SQL Server support for the storage and management of telemetry and operational data.

For a team that has measured everything the same way for years, this is a genuine departure. It runs against the grain of the sport where a bigger sensor count is treated as proof of how much a car can measure. Here, the best sensor is the one you never fit: the data captured, hardware reduced.

Compute at race speed, cost at business speed

Back on the pit wall, every variable branches McMillan’s decision into another set of what-ifs: a rival pits early, the weather turns, a crash bunches the field. The more scenarios he can run before the moment passes, the better the call. The question is, how much compute can the team bring to two hours of racing on Sunday, for the lowest cost?

Previous simulations ran on an on-premises high-performance computing (HPC) cluster with fixed capacity. The team paid for that capacity year-round but needed it most during race weekends. The team uses Azure Batch and high-performance computing (HPC) infrastructure on Azure to scale race-weekend simulations, accessing large amounts of compute on demand without maintaining dedicated capacity year-round.

Today, the team runs up to 10 million race strategy simulations during a race weekend, with roughly 75 percent executed live as conditions evolve on track. The strategists receive telemetry, GPS, lap times, sector times, competitor data, and model outputs simultaneously. All this leads to quicker decision-making, which could provide the edge they need.

David Cadywould, Head of Enterprise Technology, Mercedes-AMG PETRONAS F1 Team, says, “If we need to flex up when it’s a race weekend, we can do that in Azure. It does the number crunching quicker, and then we can turn it down for cost saving after the race.” 

The software behind the strategy

Behind the virtual sensors and race simulations sits the software the team writes to run them. More than 150 engineers across strategy, performance, aerodynamics, and applied science use GitHub Copilot in their daily work, which the team credits with speeding up how it codes and prepares for a race. One developer estimated that GitHub Copilot saved roughly three months of effort building a new interface.

One set of numbers, wherever the team lands

The savings from optimizing compute for race weekends and from replacing sensors with software all land in the same place: the cost cap. Watching that cap by the hour runs on Microsoft Power BI. Finance, aerodynamics, manufacturing, and materials all decide from one shared view instead of rival spreadsheets, and one live copy travels with the team between the UK factory and the circuit on Microsoft 365. Natisha Kali-Rai, Financial Regulation Manager, Mercedes-AMG PETRONAS F1 Team, tracks spend against forecast there: “We use Power BI reporting so that we can surface exactly what we’ve spent year to date against all financial forecasting models to understand where we are tracking against the cost cap.” That shared view gives the team real-time visibility into cost-cap spend, manufacturing efficiency, computational fluid dynamics (CFD) allocation, and inventory, helping it avoid late-stage surprises and weigh future car-development spend against the budget in the moment, instead of reconciling the numbers after the fact.

The machine narrows it down; the human makes the call

The team’s single problem has two answers. One is physical: a lighter car, because measurements once carried as hardware now run as software. The other is operational: a faster, better-informed call, because the compute behind it is scaled for the race and released after. Neither buys a bigger budget; both turn what the team already has into lap time. 

As McMillan frames it, “The tools interpret huge amounts of data in a way a human brain couldn’t, but the ultimate decision still sits with the human.”

The lesson extends beyond Formula 1. Any organization facing unpredictable spikes in demand must balance performance against cost. Rather than maintain peak infrastructure year-round, the Mercedes-AMG PETRONAS F1 Team uses Azure to scale resources when they are needed most and scale them back when demand subsides.

And the work points forward: virtual sensors moving toward production, Azure Batch now embedded in race-weekend burst compute, and a team continuing to turn existing data and elastic infrastructure into faster, better-informed decisions. The question isn’t what the Mercedes-AMG PETRONAS F1 Team proved last season, but what it builds next.

Discover more about the Mercedes-AMG PETRONAS F1 Team on Facebook, Instagram, LinkedIn, X, and YouTube.