How Machnet Closes the Bare-Metal Gap on Commodity Cloud VMs

Every conversation about low-latency workloads ends the same way. The customer asks for predictable performance, the sales rep leads the customer to bare metal, and the customer signs. Both parties understand that a conventional cloud VM can’t keep up with a dedicated server when every microsecond counts.

A group of researchers from academia and two major vendors have now added a wrinkle to that conversation.

The project is called Machnet, and Microsoft has released the code on GitHub under an open-source license. The underlying research paper was published in the proceedings of ASPLOS 2026, the premier systems conference, held in Pittsburgh in March.

The resulting performance metrics are the part hosting people will care about. On a completely ordinary 8-vCPU Azure VM (a server SKU that a customer could actually order with a credit card this afternoon), Machnet achieved 750,000 requests per second for small data transfers with a worst-case round-trip latency of 61 microseconds.

That is not quite the performance achieved with a colocated cage by a hedge fund. But it represents access to the performance range that has traditionally been reserved for bare-metal pricing.

Explanations for the premium paid for bare metal are primarily associated with network performance rather than with raw compute. Every packet transmitted or received by a cloud VM must traverse the slow path of the operating system, resulting in CPU overhead and tail latency.

For most workloads, users don't notice. For systems that require real-time performance — such as trading platforms, real-time auction engines, multiplayer game servers, and ad-tech applications — those microseconds are essentially the entire product.

The industry developed a workaround. Dedicated servers and specialized configurations for high-performance computing eliminate the slow path of the operating system and provide more direct access to the network hardware.

This approach is effective, but expensive, and it requires the customer to obtain full access to a physical machine when what they actually needed was faster network performance.

The Machnet team of researchers from Columbia, Cambridge, Politecnico di Milano, NVIDIA, and Microsoft aimed to bring the same level of performance to ordinary cloud VMs. Their self-imposed restriction is the interesting part of the effort.

They avoided the use of all the special networking capabilities available on top-tier setups but not exposed by major cloud providers to their commodity customers. Whatever Machnet does, it does it using the plain, generic virtual network interfaces that AWS, Azure, and GCP provide to all customers.

Machnet runs as a small background helper process on the VM. Applications send and receive data by handing messages to that helper instead of going through the normal operating-system route, and the helper shuttles data in and out using a shared chunk of memory.

The helper itself is built on DPDK, an open-source toolkit hosts have used for years to speed up networking on dedicated hardware. The end result is something close to bare-metal speed on the same hardware the cloud provider was already going to rent the customer anyway.

That description glosses over several years of academic work, but for hosting purposes the architecture isn't the point. The point is that a piece of software, distributed for free, claims to deliver performance for which hosts have been charging a premium. And it has been tested on the three largest cloud providers.

Bare metal remains one of the few lines of hosting that haven't been completely converted to commodity status. Margins remain acceptable, and the customer base continues to include large numbers of accounts that cannot tolerate the performance characteristics associated with a shared computing environment.

Prices for bare-metal service have held up despite extensive price reductions for all other lines of service offered by the three major cloud providers.

Kostis Kaffes, a Columbia CS professor and Machnet co-author, told me he draws that line in two specific places. Machnet on a commodity VM, he said, fits "workloads that need low-latency, high-performance networking but do not require the absolute hardware limits of the NIC."

Bare metal still wins, in his view, for workloads requiring "extremely low, single-digit-microsecond latency," and for workloads that combine low latency with very high throughput — say, 100 Gbps — "because that typically requires zero-copy data movement and direct hardware support that commodity VMs cannot expose cleanly today."

Machnet doesn't represent the end of that story. There remain applications for which a dedicated machine is genuinely necessary, including applications with highly specialized network requirements, applications that cannot risk a noisy neighbor under any circumstances, and applications regulated in ways that require physical isolation.

Those customers aren't switching to a commodity VM with a clever userspace stack, no matter how good the latency numbers look.

But the bracket of workloads for which bare metal was a forced choice has gotten narrower. Game backends. Some real-time auction configurations. The fast-but-not-ultra-fast end of fintech. Those customers may soon ask, in their next renewal cycle, whether they really need the bare-metal SKU, or whether a Machnet-equipped VM at a third of the price would meet their objectives just as well.

The honest catch is that nothing about Machnet is plug-and-play. The system is open-source, the code is available on GitHub, and the licensing terms are liberal. But to actually make use of it, each application must be reimplemented against the Machnet programming interface rather than the conventional interface that underlies nearly every piece of production software today.

The Machnet authors tested the system on three applications they reimplemented from scratch: a web server, a key-value store, and a fault-tolerance system. None of them were off-the-shelf software.

The broader environment of production software doesn't speak Machnet's language at this time. Until that changes, customers can't simply flip a switch on their existing configuration to get the benefits.

Kaffes told me the biggest practical barrier is integration with mainstream stacks. "Machnet asks developers to use a different programming model than conventional sockets or RPC stacks," he said, "so broader adoption would require making that model feel native inside existing frameworks."

The fix he envisions isn't another systems interface for applications to consciously port to — it's packaging Machnet-like APIs "as a drop-in path for common stacks."

Still, the publication itself is the contribution that matters in the long run. The proof of concept is solid, the source code is public, the numbers are good, and a credible group of researchers has formally put the work on the record.

That tends to be how disruption arrives in this industry: quietly, in academic proceedings, several years before it influences the actual procurement conversations it eventually changes.