A DPU, or data processing unit, is the third programmable processor that has quietly appeared inside modern servers, alongside the CPU and the GPU. In its more familiar guise it is a SmartNIC: a network card with its own cores, memory and operating system that does work the host CPU used to do. If you have read that NVIDIA BlueField or AMD Pensando cards can run your networking, storage and security in hardware, and wondered what that actually means for a server you might buy, this is the plain-English version. We will cover what a DPU is, why offloading work off the host matters, how isolation changes the security story, and what vSphere DPU support means in practice.
A NIC that is really a tiny server
A traditional network card moves packets between the wire and the host and lets the CPU do everything else. A DPU adds a general-purpose processor, typically multi-core Arm, with its own RAM, on-board accelerators and a Linux-based operating system, all on the PCIe card. That makes it a small, self-contained computer that happens to sit on the network path. NVIDIA BlueField, AMD Pensando and Intel IPU products all follow this pattern; the umbrella term SmartNIC is often used interchangeably with DPU, though a DPU is the higher-capability end of that range.
The point is not raw speed for its own sake. It is location. Because the DPU sits between the host and the network, it can inspect, transform and route every packet, terminate storage and security protocols, and present clean, virtual devices to the host, all without the host CPU ever touching that work. The card becomes an infrastructure control point rather than a dumb pipe.
Offload: giving the host CPU its cores back
On a busy virtualisation or cloud host, a surprising share of CPU cycles never runs a single customer workload. They are spent on the virtual switch, encryption, overlay networking (VXLAN or Geneve), storage protocols such as NVMe over Fabrics, and packet processing. This is sometimes called the infrastructure tax: cores you bought to run applications are instead running the plumbing.
A DPU offloads that plumbing onto its own processor. The virtual switch, firewall rules, encryption and storage initiation move to the card, freeing host cores to do what you actually pay to licence them for. On a host running per-core-licensed software, recovering even a handful of cores per node has a direct cost angle, not just a performance one, which is why offload sits alongside the core-count discipline we describe in how to spec a server in 2026.
- •Virtual switching and overlay networking (VXLAN / Geneve) run on the DPU, not the host
- •Line-rate encryption and TLS/IPsec offload move off host cores
- •Storage protocols (NVMe-oF, virtio-blk) are terminated on the card
- •Host cores are returned to revenue or licensed workloads
Isolation: a security boundary the host cannot see past
Offload is the headline, but isolation is arguably the bigger shift. When the virtual switch, firewall and storage stack run on the host, they share the same operating system, memory and trust domain as the workloads. A compromise of the host can, in principle, reach the infrastructure services running beside it.
A DPU moves those services onto a separate processor with its own operating system, isolated from the host by the PCIe boundary. Security policy, micro-segmentation and telemetry run in a domain the host workloads cannot reach or tamper with, even if the host itself is compromised. This is the model hyperscalers have used for years to enforce tenant isolation, and it is now available in mainstream enterprise hardware. The card itself is a network device, so it is selected and sized like one, which is why it belongs in the conversation alongside conventional network cards.
vSphere DPU: what VMware actually does with it
VMware vSphere supports DPUs through a capability originally launched as Project Monterey and now shipped as vSphere Distributed Services Engine. The idea is direct: install a supported DPU (BlueField or Pensando) in a certified host, and ESXi runs a second, slimmed-down instance of itself on the DPU. The NSX networking and security data plane, the distributed firewall and the virtual switching then execute on the card rather than on the host.
The benefits are the two themes above made concrete. Host CPU previously consumed by NSX is returned to virtual machines, improving consolidation density. The networking and security plane is isolated from the workload domain, hardening it against a compromised guest or host. For teams already standardising on NSX, it is an incremental hardware change with an outsized effect on both efficiency and security posture. We factor DPU support into builds when it fits the platform, as part of our wider server configuration service.
Do you need one yet?
For a single general-purpose server, almost certainly not; a conventional NIC is the right answer and a DPU is cost and complexity you will not use. DPUs earn their place at scale and where the infrastructure tax is real: large virtualisation or VDI estates, multi-tenant or service-provider platforms, software-defined storage clusters, and AI or HPC fabrics where host CPUs would otherwise drown in network and storage handling.
The honest framing is that a DPU is an infrastructure investment, not a per-server upgrade. It pays off when you are running enough nodes that recovered cores, lower power and a stronger isolation boundary add up across the fleet. If you are weighing it, the decision is the same one we apply to any component: does it change the economics or the risk profile of the whole estate, which we work through with customers in server configuration.