In one blink, the fastest trading firms could react 200,000 times. Now that race is moving to the cloud

A human blink takes roughly 100 to 400 milliseconds. A custom hardware trading system can react to a market event in hundreds of nanoseconds. Take the quickest blink and a 500-nanosecond reaction, and you get 200,000 reactions in the time it takes to close and open your eyes.

That is our arithmetic, built on typical ranges rather than any firm's measured speed. But it shows the scale of the race. And on October 12, the exchange at the center of much of that race said its move to the cloud is running ahead of plan.

What CME just said

The CME-Google partnership is not new. What is new is how far it has come.

CME's October 12 release says initial performance testing of Globex in the cloud showed faster round-trip times for trading. It gives no figures. It also says construction of the Aurora Cloud Region and co-location facility is ahead of schedule, with client testing targeted for mid-2027.

Chief executive Terry Duffy said CME will "deliver the first cloud-based solution for ultra-low latency trading sooner than expected," with clients able to access both Google Cloud-managed services and co-location in Aurora in late 2027.

Days earlier, Google detailed its U4 servers, built for this kind of trading.

Six words that matter

The most interesting line is in a CME notice from May. After the migration, it says, cloud access through GLink ULL-Chicago and U4C Bare Metal instances will be competitive with physical co-location "for clients who use traditional compute."

Those last six words set a boundary. CME does not mention FPGAs in that passage, so what follows is our reading: the promise is aimed at firms running software on ordinary processors. Firms running custom hardware are a separate conversation.

The same notice says Aurora co-location will remain the most performant access to Chicago-hosted markets through the end of the migrations in 2028. CME is also evaluating its Customer Hardware Co-location offering and says it will announce a decision on the physical co-location site by the end of 2028.

Lane 1: the race won in silicon

An FPGA is a chip programmed to do one job. Trading logic runs directly in its circuits, with no operating system in the way, which gives it speed and very consistent timing. The cost is expertise, hardware in a co-location facility, and limits on how complex the logic can be.

This lane matters where orders at the same price are filled first come, first served. On most liquid CME futures, being slightly earlier can decide who gets filled.

Lane 2: 120 CPUs, no hypervisor

"Bare metal" means renting a whole physical server with no virtualization layer between your code and the machine. Google's documentation describes U4C as two 60-core processors exposing 120 CPUs, with two dedicated ultra-low-latency network links. Google says market data arrives by hardware-accelerated multicast and supports user-space networking tools such as OpenOnload and DPDK.

One explainer puts tuned software at roughly 1 to 5 microseconds. That is slower than custom hardware, but it leaves room for richer models and faster strategy changes.

Two caveats. Google's blog and documentation publish no latency figures for U4C, and neither mentions FPGAs or customers installing their own hardware. And even in the cloud lane, physics applies: a signal from New Jersey to Aurora takes around 4 milliseconds even at the speed of light, by our estimate, so cross-market data is always somewhat old by the time it arrives.

Same trade, two games

Here is an illustrative scenario, not a real trade or measured timing.

A large order sweeps the offer in the E-mini S&P 500. CME publishes the update. Within hundreds of nanoseconds of the packet arriving, a hardware firm has reacted and is competing for queue position.

A software firm sees the same packet microseconds later. It will not win that race, so it plays a different game: judging whether the move will last, using its own model, and pricing accordingly.

One is trying to be first. The other is trying to be right.

This is a simplification. "Two lanes" is our framing, not an industry standard, and many firms combine them, with hardware on the fast path and software making the harder decisions.

Where AI fits

CME's May notice also describes a Google program for testing hardware accelerators for inference in low-latency trading, with TPU capacity close to the Globex matching engines in Dallas. Google writes of feeding real-time markets directly into AI-driven trading models.

If that becomes practical, the second lane gets more interesting. More compute next to the market favors firms competing on models rather than on nanoseconds.

What we do not know

• How close U4C gets to co-location in production. CME's testing claim has no public numbers.
• What happens to customer hardware co-location after 2028.
• What the full cost comparison looks like between cloud and co-location.

Questions to ask now

1. Does your edge depend on arriving first, or on pricing better?
2. How much of your latency is network, and how much is your own code?
3. What would you test when Aurora opens to clients in mid-2027?
4. Would your strategy survive if the co-location decision goes against your current setup?

Are you racing to be first, or to be right?

References

• CME Group: Cloud Migration Milestones, October 12, 2026
• Google Cloud: U4 compute for ultra-low latency trading, October 8, 2026
• Google Cloud: U4 machine family documentation
• CME Globex Notice 20260525, May 28, 2026
• Inside the FPGA interview at a low-latency trading firm, source for typical latency ranges
• Wikipedia: Blinking, citing blink duration estimates

Latency figures are typical ranges from general industry sources, not CME or Google data. The arithmetic and interpretations are ours. This article is commentary, not investment advice.