HP ZGX Fury Launch Puts 748GB of Local AI Memory on Order, but the Software Plan Comes Later

HP has opened orders for ZGX Fury, giving enterprise buyers access to 748GB of coherent memory and up to 20 petaFLOPS of FP4 AI performance.

The HP ZGX Fury launch matters because the machine targets a gap between ordinary workstations and centralized AI infrastructure. It can hold models that overwhelm conventional GPU memory, yet it fits in an office or a 5U rack.

That hardware is available before HP’s broader software proposition is complete. HP is developing a separate platform that combines ZGX Fury with Red Hat AI Factory with NVIDIA. The company has not disclosed when customers can evaluate that integrated environment.

This distinction creates the central tension. Buyers can order the GB300 system now, but they cannot yet judge the finished hardware and software package that HP describes for production edge deployments.

Dell has already shipped a competing GB300 desktop, while NVIDIA offers its own DGX Station platform through multiple manufacturers. HP therefore enters an active market rather than defining an uncontested category.

The decisive question is not whether 748GB looks impressive on a specification sheet. It is whether HP can turn that memory capacity into a manageable, shared platform for sustained enterprise inference.

The HP ZGX Fury Launch Separates Available Hardware From Planned Software

HP has made the ZGX Fury orderable, but its Red Hat-based enterprise platform remains a plan with no public evaluation schedule.

HP announced the change on September 8, 2026, through a release published on September 9. Its edge AI announcement says ZGX Fury is available to order.

The same announcement describes a collaboration among HP, Red Hat, and NVIDIA. The companies intend to combine the workstation with Red Hat AI Factory with NVIDIA for distributed enterprise inference.

These are related developments, but they have different availability states. ZGX Fury is a purchasable hardware product. The integrated platform is still under development.

HP says future customers will evaluate that platform in a sandboxed environment on HP devices. However, timing, locations, eligibility, supported configurations, and access details have not been released.

That unresolved schedule matters because HP is selling more than a large local model box in its corporate messaging. It is proposing a controlled path from experimentation to repeatable production deployments at the edge.

In this context, edge means infrastructure placed near users, machines, applications, or data sources. It does not necessarily mean a small device mounted beside a sensor.

ZGX Fury can operate as a tower or mount in a standard 5U rack. That flexibility places it closer to departmental infrastructure than a personal desktop, despite its workstation form.

The system uses NVIDIA’s GB300 Grace Blackwell Ultra Desktop Superchip. It combines a 72-core Arm-based Grace CPU with a Blackwell Ultra GPU through a coherent memory architecture.

Coherent memory gives the CPU and GPU a shared, consistent view of data. It reduces the need to manage completely separate memory spaces during large AI workloads.

HP lists 496GB of LPDDR5X CPU memory and 252GB of HBM3e GPU memory. Together, they provide the advertised 748GB pool.

The company also lists up to 20 petaFLOPS of FP4 performance. FP4 is a four-bit numerical format designed to reduce model memory and computation requirements during supported AI operations.

These numbers explain why the workstation draws attention. Yet they do not establish application throughput, latency, concurrency, or model quality under real production conditions.

HP’s available hardware therefore creates an immediate procurement option and a later operational promise. Enterprise buyers should evaluate those two propositions separately.

The machine can be assessed against current workloads, operating systems, storage needs, and networking requirements. The planned Red Hat platform requires another test covering orchestration, isolation, updates, governance, and support.

That division is the real news behind the HP ZGX Fury launch. HP has crossed the hardware availability line, while the larger edge AI package remains behind it.

Why 748GB of Unified Memory Changes the Local AI Boundary

The most important ZGX Fury specification is not peak FP4 compute alone; it is the amount of model state one system can keep addressable.

Large AI models place several demands on memory. Their weights must fit somewhere, while inference also needs space for caches, runtime data, and concurrent requests.

Quantization reduces that burden by representing model values with fewer bits. A lower-precision format can shrink memory requirements, although the quality and performance effects depend on the model and implementation.

HP says ZGX Fury can fine-tune models in the 100-billion-parameter class when quantized at FP4. It also claims support for inference with models reaching the trillion-parameter class.

Those are product claims, not universal workload guarantees. Parameter count does not reveal architecture, context length, active parameters, cache requirements, or achievable tokens per second.

Still, the 748GB pool changes what teams can attempt on one node. Many conventional workstation GPUs have enough memory for smaller models but require compromises for much larger ones.

Splitting a model across several discrete GPUs introduces communication and scheduling work. It also requires software that understands how to partition weights and manage data transfers.

A coherent CPU-GPU design offers another route. Less frequently accessed model data can reside in the Grace CPU memory while the GPU works from its faster HBM3e capacity.

The memory regions do not perform identically. HP lists 396GB per second for the LPDDR5X memory and 7.1TB per second for HBM3e.

That difference means coherent does not mean uniformly fast. Performance depends on where data resides, how often the GPU accesses it, and how effectively software manages placement.

NVIDIA describes the same broader concept for its DGX Station platform. The company positions the C2C interconnect as a way to avoid traditional CPU-GPU transfer bottlenecks.

C2C refers to the chip-to-chip link connecting Grace and Blackwell Ultra. The architecture provides a shared address space while preserving the GPU’s dedicated high-bandwidth memory.

This design can simplify workloads that would otherwise span several conventional systems. However, it does not turn slower system memory into HBM3e or erase every data movement penalty.

The distinction becomes important with mixture-of-experts models. These models contain many specialized parameter groups but activate only part of the network for each token.

A large coherent pool can hold more experts locally, reducing dependence on storage or another node. Actual speed still depends on expert routing and memory access patterns.

Long contexts create another pressure point. The key-value cache, which stores attention information from previous tokens, grows as prompts and concurrent sessions become longer.

A model that fits comfortably for one user can consume far more memory under multiple simultaneous requests. HP promotes ZGX Fury as a shared resource, making concurrency tests essential.

Storage also imposes a practical boundary. HP offers configurations with 2TB or 4TB of NVMe storage, selected when the system is ordered.

Large model collections can fill that capacity quickly. Teams may need external or networked storage even when the active model fits inside coherent memory.

The HP ZGX Fury specifications create valuable headroom, especially for private inference, model evaluation, fine-tuning, and agent workloads. They do not remove the need for workload-level measurement.

Buyers should test representative models at their required precision. They should also record latency, throughput, memory placement, context length, concurrency, and sustained thermal behavior.

Without those measurements, 748GB remains capacity rather than a production result. Its value appears when software can use that capacity predictably.

HP Is Competing on Operations, Not Exclusive Access to GB300

GB300 hardware is becoming a shared foundation, so HP must differentiate through deployment, support, and day-to-day administration.

Dell announced in March 2026 that it was the first original equipment manufacturer to ship a desktop based on the GB300 Desktop Superchip. Its GB300 launch describes the same headline ceiling of 748GB and 20 petaFLOPS at FP4.

NVIDIA also lists GB300 personal AI supercomputers from several manufacturers. This market structure limits how long any vendor can rely on the processor and memory total as unique advantages.

The primary competition is therefore not HP against cloud computing in every scenario. It is HP against other ways of operating the same GB300-class local infrastructure.

Dell emphasizes autonomous agents, NVIDIA OpenShell, and an integrated deskside agent platform. HP emphasizes shared local inference, its ZGX tools, and planned integration with Red Hat’s enterprise software.

Both approaches target buyers who need large models near sensitive data. Both also depend heavily on NVIDIA’s processor, networking, libraries, and AI software.

HP includes Ubuntu 24.04 LTS with NVIDIA AI developer tools in its listed configuration. Its Z Runtime command-line interface is intended to pull, serve, and manage models.

HP Z Toolkit adds model testing, experiment tracking, system discovery, synchronization, and export capabilities. HP says it includes open-source frameworks, MLflow, and Ollama support.

These tools address an important usability problem. A large accelerator does not help a development team if model setup, tracking, and deployment remain fragmented.

The workstation also supports multiple users and concurrent workloads. That claim moves the product beyond an individual researcher’s machine and toward a departmental service.

Shared use changes the evaluation criteria. Administrators need authentication, workload isolation, resource allocation, observability, updates, and recovery procedures.

HP says the planned platform will improve GPU utilization through CUDA libraries, scheduling, and multi-GPU orchestration. It also says several workloads can share a system while maintaining isolation and governance.

Those assertions need validation in the final integrated product. A product announcement cannot establish whether policies behave consistently under real workload contention.

The Red Hat component is intended to supply that operational layer. Red Hat AI Factory combines Red Hat AI Enterprise with NVIDIA AI Enterprise across hybrid environments.

Its components cover inference, model management, deployment, observability, and lifecycle controls. OpenShift provides the container orchestration foundation.

That stack can appeal to organizations already operating Red Hat infrastructure. Familiar management patterns can reduce the organizational distance between central IT and AI development teams.

However, the complete platform introduces more software, not less. Organizations must understand licensing, cluster design, identity integration, update responsibilities, and supported configurations.

A standalone ZGX Fury running Ubuntu serves a different operating model. A Red Hat-managed edge fleet adds governance and repeatability, while also creating more components to maintain.

The competitive contest will turn on how well each vendor packages those tradeoffs. Hardware parity makes software integration and service quality more visible.

HP can also connect two ZGX Fury systems through dual QSFP112 ports. Each port supports 400Gbps networking, according to the product specifications.

Connecting nodes expands potential model and workload capacity. It also brings distributed inference considerations back into the system, including communication overhead and failure handling.

ZGX Fury therefore occupies a middle tier. It is much larger than compact local AI systems, but it is not a replacement for rack-scale clusters.

NVIDIA’s data-center DGX GB300 uses 72 Blackwell Ultra GPUs and 36 Grace CPUs. That architecture targets training, post-training, and high-volume inference at a different operational scale.

HP’s proposition is narrower and potentially easier to deploy. One or two nodes can sit close to a research group, factory line, hospital department, or secure development team.

The product wins only if that smaller footprint also produces simpler operations. Otherwise, buyers inherit data-center responsibilities in a workstation-shaped enclosure.

The Red Hat Edge Plan Still Needs Production Evidence

HP’s planned software stack addresses the hardest enterprise questions, but its current announcement leaves the validation details open.

HP identifies latency, privacy, resiliency, data sovereignty, connectivity, and cost as reasons to place inference closer to deployment sites. Each factor can justify local infrastructure.

Manufacturing teams might analyze camera feeds near a production line. Local processing can reduce continuous data transfers and support faster responses to detected defects.

Healthcare or government users might keep sensitive material inside controlled facilities. Remote locations might also need inference when internet access is unavailable or unreliable.

Engineering groups can use the system for local coding agents, model evaluation, and fine-tuning. Teams could share one node instead of maintaining separate high-memory workstations.

These scenarios are credible, but they do not guarantee that ZGX Fury fits every edge location. The system’s power, cooling, physical security, and network requirements still need site-level review.

Liquid cooling and optimized airflow help manage sustained operation. They do not make the machine equivalent to a low-power appliance designed for an unattended industrial cabinet.

The workstation form also creates governance questions. Placing significant AI capacity outside a central data center can distribute operational responsibility across many offices and facilities.

IT teams need consistent methods for patching firmware, validating models, enforcing access rules, rotating credentials, and collecting logs. Locality can improve data control while complicating fleet management.

HP’s Red Hat collaboration directly targets this problem. The companies describe a consistent software foundation spanning local devices, data centers, and cloud environments.

The planned sandbox could be especially valuable. A controlled evaluation environment would let customers test policies and workloads before promoting them into production.

Yet HP has not announced when that sandbox will open. It also has not specified which ZGX Fury configurations, model families, or Red Hat components the initial release will support.

The machine is certified for Red Hat Enterprise Linux. HP calls it the first GB300 AI station with that certification.

Operating-system certification is useful, but it is not equivalent to validation of the complete AI Factory environment. The planned solution still combines additional orchestration, inference, model, and governance layers.

Independent performance evidence is also limited. HP publishes peak compute and model-size claims, but buyers need results for recognizable models and production settings.

Sparse FP4 peak performance cannot be translated directly into user-visible inference speed. Software efficiency, model architecture, batching, context length, and memory traffic all affect output.

Quality is another constraint. Aggressive quantization can reduce memory consumption, but teams must verify that the resulting model remains accurate enough for their use case.

The trillion-parameter statement requires similar caution. Being able to load or run a quantized model does not reveal its response time, concurrency capacity, or operational usefulness.

Organizations should request sustained benchmarks instead of short demonstrations. A production assessment should include warm and cold starts, long prompts, concurrent users, and failure recovery.

Teams should also measure total system utilization. A shared machine brings value when it remains busy enough to justify dedicated ownership without creating long queues.

Local deployment can remove usage-based token charges, as HP notes. It replaces variable consumption with hardware, energy, administration, maintenance, and capacity-planning responsibilities.

Cloud infrastructure remains useful for temporary demand, geographic reach, managed services, and large distributed training. A local node offers different economics rather than automatically better economics.

Hybrid use may become the practical outcome. Sensitive or steady inference can remain local, while burst workloads and large training jobs run elsewhere.

That pattern makes portability important. Models, containers, policies, and monitoring should move without requiring teams to rebuild the entire application for every environment.

Red Hat’s hybrid platform is meant to provide that consistency. The future sandbox must show whether the promise survives contact with actual applications and enterprise controls.

Until then, the hardware deserves one evaluation and the platform roadmap deserves another. Treating them as a finished package would overstate what HP has released.

Local AI Moves From Personal Experiments to Shared Infrastructure

ZGX Fury shows that local AI is becoming a departmental infrastructure decision rather than a personal workstation purchase.

Compact systems such as NVIDIA’s GB10-based machines made local model experimentation more accessible. Their 128GB unified memory capacity supports many development and inference tasks.

GB300-class stations move the ceiling much higher. The additional memory supports larger models, longer contexts, greater concurrency, or less aggressive compression.

That change affects organizational ownership. A system designed for several users needs an administrator, service expectations, access controls, and workload priorities.

Developers will still interact with local tools, command lines, and model endpoints. However, the underlying machine increasingly resembles a small internal AI service.

This evolution explains HP’s emphasis on production inference. The company is not limiting ZGX Fury to model prototyping or occasional research jobs.

Its listed workloads cover development, fine-tuning, inference, and agentic AI. Agentic AI refers to systems that plan and execute multi-step tasks using models, tools, and external data.

Long-running agents can consume more compute than a single chat request. They may also require broad access to company systems, making isolation and auditability important.

Local inference gives organizations greater control over model traffic and sensitive inputs. It does not automatically make an agent safe or trustworthy.

Administrators still need permission boundaries, approval paths, monitoring, and response procedures. These controls belong in the software layer surrounding the model.

The same principle applies to knowledge-intensive engineering work. A large model can analyze local code or documents, but teams still need reliable capture and retrieval practices.

A searchable knowledge base can preserve evaluation findings, configuration choices, and operational lessons across the deployment team.

That documentation becomes more important when several departments share one system. Without it, benchmark methods and configuration decisions can disappear between pilot and production.

HP’s strategy reflects a broader transition from local AI as a privacy feature to local AI as managed infrastructure. The distinction changes both the buyer and the deployment process.

An individual developer can tolerate manual model downloads and occasional restarts. An enterprise service requires predictable updates, measured capacity, defined recovery, and support ownership.

ZGX Fury’s rack option reinforces that interpretation. A 5U deployment sits naturally in a lab, secure equipment room, or departmental server area.

Its tower mode can bring the same resources closer to a team. The physical location should not weaken the operational controls applied to the system.

Buyers should therefore create a workload inventory before ordering. Each workload should include model size, precision, context, concurrency, latency, storage, and data sensitivity.

They should identify which workloads need continuous availability. A shared node can become a single point of failure if critical applications depend on it.

Connecting two systems can add capacity, but redundancy requires software and procedures. A fast link alone does not provide automatic failover.

Teams also need a clear upgrade plan. AI models and runtime stacks change quickly, while dedicated hardware remains a longer-lived asset.

The best use cases will likely involve stable, recurring demand. Variable experiments can still benefit, but they make utilization and capacity harder to predict.

The hardware’s memory capacity offers flexibility during that planning. Teams can test larger open-weight models without immediately assembling a multi-GPU server cluster.

Its limits also need recognition. Large-scale training, global serving, and highly elastic traffic remain better suited to larger infrastructure or cloud services.

ZGX Fury does not erase those categories. It creates a substantial new point between a personal AI computer and a data-center deployment.

Three Signals Will Show Whether HP’s Edge AI Strategy Works

The next evidence must come from software availability, independent workload results, and sustained enterprise adoption rather than another specification announcement.

The first signal is HP’s sandbox schedule for the Red Hat integration. Buyers need dates, supported configurations, access requirements, and a clear path from evaluation to production.

A near-term sandbox with documented workloads would strengthen HP’s claim that ZGX Fury can serve as managed edge infrastructure. Continued silence would widen the gap between available hardware and planned software.

The second signal is independent benchmark coverage. Tests should use identifiable models, stated precision, long contexts, and several concurrent users.

Useful results must separate model loading from steady-state inference. They should report latency, throughput, memory use, power behavior, and performance during sustained runs.

Benchmarks should also compare HBM3e-heavy execution with workloads that spill into Grace CPU memory. That evidence would reveal the practical effect of the coherent architecture.

Strong results would support HP’s argument that one node can replace more complicated experimental setups. Weak memory-sensitive performance would narrow the set of suitable workloads.

The third signal is enterprise deployment evidence. HP should identify customers operating ZGX Fury beyond demonstrations, especially in regulated or intermittently connected environments.

The most meaningful cases will explain what ran locally, why cloud delivery was unsuitable, and how teams managed security and updates. Adoption counts without workload details will reveal less.

Customer evidence should also clarify whether the machine serves one specialist, a development group, or production applications. HP’s shared-infrastructure argument depends on that distinction.

Competitor activity will provide context for all three signals. Dell already claims first shipment, and other NVIDIA partners can offer comparable GB300 foundations.

If competing systems publish stronger benchmarks or mature management stacks first, HP’s hardware availability will not guarantee momentum. Buyers can compare implementations without leaving the GB300 platform.

If HP delivers its Red Hat sandbox quickly, the competitive question changes. The focus would move from component parity to operational consistency across workstation, edge, and data-center environments.

That is the route HP has chosen. It is selling a large-memory node today while asking enterprises to anticipate a broader managed platform tomorrow.

The HP ZGX Fury launch is therefore more consequential than another high-end workstation release. It tests whether local AI can become repeatable enterprise infrastructure at a departmental scale.

The specifications make that test possible. The 748GB coherent pool can accommodate workloads that previously demanded several accelerators or more centralized systems.

The remaining work is less visible. HP, Red Hat, and NVIDIA must show that scheduling, isolation, governance, model management, and support operate as one dependable system.

Enterprise buyers should begin with a measured pilot, not a model-size claim. Choose a real workload, record cloud and local baselines, and test the complete operational cycle.

Can the system meet latency targets during concurrent use? Can administrators patch it without extended disruption? Can policies follow the workload across local and centralized environments?

Those answers will determine whether HP ZGX Fury becomes shared AI infrastructure or an exceptionally capable lab machine. Watch the sandbox, the benchmarks, and the first production deployments.