How Uber Engineered AI into Production at 15 Million Predictions a Second

At peak, Uber’s machine learning platform serves more than 15 million real-time predictions a second. Uber reported that figure in October 2025. Eighteen months earlier, the same platform reported 10 million.

Nine years before that, Uber’s engineers described a company where models were trained on laptops, every team built its own serving path, and almost nothing reached production reliably.

The throughput is what shows. The decisions underneath it are what transfer.

Those decisions produced narrower results that Uber publishes with the denominator attached:

• Average invoice handling time fell 70% in the finance workflow that uses GenAI extraction
• Uber Eats cut search latency in half
• Training-serving mismatch on affected ranking features fell from more than 10% to 0%

None of these is one program. Uber reports them as separate initiatives with separate owners and dates. Read together, they show a company that made AI useful by rebuilding the systems around it: one route to production, data that can be trusted, and automation that stops where a reviewer should start.

The Problem: A Company That Could Predict Faster Than It Could Ship

In 2017 Uber published the reasoning behind Michelangelo, its machine learning platform. Before it existed, there was no system for building and deploying models reliably at scale. Data scientists used whatever tools they preferred, from R to custom one-off systems. Engineers wrote bespoke serving containers for each project. Nothing was shared, and nothing was reused.

Scale made the gap expensive. By 2024 Uber ran one of the largest Hadoop installations in the world, more than an exabyte across two regions, and its batch platform served more than 500,000 Presto queries a day for over 10,000 internal users.

The data existed. The problems sat in the path between data and a decision:

• No shared route to production: every model needed its own pipeline, serving code, and monitoring.
• Fragile change: in 2021 a bad feature-metadata update caused a production serving incident.
• Stale data: scheduled Spark batches left data-lake tables hours behind the events they described.
• Training-serving skew: training pipelines used “en-US” while serving sent “en”. Mismatch on key features exceeded 10%.
• Manual work at the edges: supplier invoices were keyed by hand, and CI ran between 3.4 and 5.4 builds for every change that landed.

Uber had the data and the models. What it lacked was a way for a model to reach production, stay correct once there, and change a real workflow. So it built that path first, then measured each use case on its own terms.

What Uber Delivered

Uber’s engineering blog is unusually detailed. Read in date order, the posts form one dependency chain rather than a portfolio of pilots.

Seven capabilities came out of that sequence. Each depends on the one below it.

How Uber Built It

Six stages. In each one Uber had a cheaper or safer option. The decision it made instead is the part worth copying.

Stage 1: Build one route to production, then decide who owns it

The harder decision came a year later, when Uber set out who owns what:

• Product teams own the models they run in production
• The platform team owns Michelangelo itself, the workflow and tools
• Specialist teams in NLP, vision, and forecasting join product teams for weeks or quarters
• Research teams never own production code

By May 2024 that one platform carried about 400 active projects, 5,000+ models, 20,000+ training jobs a month, and 20,000+ shared features. These are adoption figures, not returns.

Stage 2: Make the data dependable before making the models smarter

Three data problems, three teams, three years. Uber reports them separately, and so does this article.

Safe change. Palette is Uber’s feature store, the catalog of inputs models read. After a bad metadata update broke serving in 2021, Uber rebuilt it with server-side validation, incremental updates, and rollback. A change now reaches production in 15 minutes, not an hour-plus (January 2024).

Freshness. IngestionNext replaced nightly Spark batches with Kafka and Flink streaming into Apache Hudi, the table format Uber created in 2016. Tables are now minutes behind events, not hours, on 25% less compute (December 2025).

Consistency. Training and serving computed features differently, so models learned from data production never saw. The fix: log the exact features each model consumed and train on those logs. On the search and ranking models that got it, mismatch fell from over 10% to 0% (September 2026).

Above all three: shadow testing. A new model sees live traffic and logs its answers without serving them. By October 2025 it covered 75% of critical use cases, with auto-rollback when errors or latency spike. Regressions surface in hours, not days.

Stage 3: Optimize the marketplace, not the match

Matching a rider to the nearest driver is the obvious objective. Uber decided it was the wrong one: the best match now can leave drivers idle an hour later.

Its July 2025 answer is a learned value function, a model that prices what each driver position will be worth later and feeds that into matching. Completed trips count as reward. Idle time counts as zero.

Tested with switchback experiments, which flip the policy on and off over time across the whole marketplace: driver earnings up 0.52%, rider cancellations down 2.2%. Both relative, with no published duration or confidence interval.

Traffic followed the same logic. DeepETT, May 2026, forecasts traffic on 100 million road segments, 2 million forecasts a second. In a global A/B test, long-trip arrival accuracy improved 6% and navigation defects fell 2.73%. The $100 million a year Uber also cites is an estimate, tabled as one below.

Stage 4: Remove work from the path the customer sees

Uber Eats search was measured by API response time. In September 2026 the team called that the wrong number: the API can get faster while the user still waits for the screen.

The new metric is above-the-fold completion, the time from query to a fully drawn first screen. Then the team cut work along that path instead of tuning the model at the end of it: paginate and render concurrently (200+ ms), drop retrieval paths that rarely returned results (120 ms, no conversion loss), fetch ranking and display data separately (100+ ms).

Overall, search latency was cut in half. The parts do not sum to that, because paths overlap. AI appeared only as an engineering tool, in a measure-fix-validate loop. The result came from architecture, not a better model.

Stage 5: Put GenAI inside a bounded workflow with a reviewer

Supplier invoices arrive as PDFs in every layout imaginable. TextSense, Uber’s document-processing platform, extracts the fields with OCR and AI models. Business rules check them, a human reviews them beside the original PDF, and only then does the invoice reach the ERP for payment.

The model is one step in five. That is why the results keep their units.

Ninety percent accuracy does not mean 90% of invoices were right end to end, or that no human touched them. Full automation for reliable suppliers was a next step, not a result.

Uber also publishes where GenAI failed. Migrating 600,000+ JUnit 4 tests (Java unit tests) with generative AI did not work. OpenRewrite, a rule-based rewriting tool, migrated 75,000+ test classes in 4 months, with AI kept for debugging.

Stage 6: Point prediction and feedback at the delivery pipeline itself

Uber then turned the same methods on its own engineering.

Continuous integration. SubmitQueue, Uber’s merge queue, used to run speculative builds for every ordering of pending changes. The redesign predicts each build’s duration with an NGBoost model, runs only the builds likely to be needed, and lets small changes skip ahead.

Over 21 weeks, CI resource use fell 53% and P95 wait fell 37%. Neither is a dollar figure.

Code review. uReview, Uber’s AI reviewer, grades and filters its own comments before a developer sees them. Developers rated 75% useful and acted on 65%+. Median turnaround: 4 minutes.

Governed access for agents. The GenAI Gateway is the single door to LLMs, tracking usage and sensitive data at 16 million queries a month. The MCP Gateway is the single door from AI agents to internal tools, via the Model Context Protocol, across 800+ servers. Every tool starts disabled until its owner switches it on.

Uber’s software factory report attributes 70%+ of pull requests to AI agents, with cost per 1,000 model requests down 34% from peak. Uber does not define “attributed,” so read it as agent-assisted work. On the Q1 2026 earnings call, Uber’s CEO put fully autonomous code at about 10%, human-reviewed before commit.

Business Outcomes in Numbers

Uber reports results per system, with the scope stated. Each figure below stays attached to the workflow it measured.

A 0.52% change in driver earnings reads as small. Across almost 9 million people earning on the platform, it is not.

What is an estimate or a count, not a result

Uber draws most of these distinctions itself. An enterprise reading the case should keep them.

Conclusion

Uber’s AI story is usually reduced to one throughput number. The number is the output of a chain of choices. Uber chose to:

• Build one route to production before building many models
• Let product teams own models, and the platform team own the platform
• Make validation, rollback, and shadow traffic platform features
• Train on the features production actually saw
• Optimize the marketplace, not the immediate match
• Change the metric before changing the architecture
• Keep a reviewer inside every GenAI workflow, and drop GenAI where a plain tool did the job
• Point prediction at its own delivery pipeline

Each decision produced what the next one needed. That is why Uber’s results arrive with their denominators attached.

The transferable lesson is the order. A platform first, then data that can be trusted, then models inside a workflow with a human checkpoint, then the delivery pipeline itself.

The same sequence underpins legacy modernization programs that hold up over years.

Which layer is missing today? And will the next AI investment land on something that can carry it?