Intel’s New AI GPU Has 480GB of Memory. Why No HBM?

Imagine an AI server with a graphics processor carrying 480 gigabytes of memory on a single card. A model that previously needed several accelerators might now fit on one. There could even be room for long conversations and multiple users at the same time.

Intel is building toward that idea with its GPU D-series, formerly known as Crescent Island. At the Open Compute Project Global Summit in October 2026, the company detailed an accelerator with up to 480 GB of LPDDR5X memory and a 350-watt power envelope.

The surprising decision is the memory itself. Many high-performance data-center accelerators rely on high-bandwidth memory, or HBM. Intel’s new design instead uses LPDDR5X, a memory technology also associated with power-efficient computing devices.

Why choose a different kind of memory for a GPU built to run large AI models? The answer starts with a distinction that matters more than the biggest number on a specification sheet: how much data fits is not the same as how quickly it moves.

What Intel actually announced

The new Intel GPU D-series is intended for AI inference: running a trained model to answer prompts, process documents, serve applications and generate tokens.

Intel’s design centers on the Xe3P architecture, large onboard memory, low-precision matrix computation and deployment in air-cooled servers.

The October announcement provided four notable specifications.

Intel says the architecture can support models with up to 300 billion parameters on one card, and larger configurations across multiple GPUs. That claim needs the same qualification as any model-sizing statement: precision, software overhead and available runtime memory determine what can actually be deployed.

According to Intel, customer sampling is underway. The public specification is useful for understanding the design, but there is not yet a complete, independently verified performance picture across production inference workloads.

The difference between memory capacity and memory bandwidth

Think of the accelerator’s memory as the place where a model’s working data resides. Capacity determines how much can stay there. Bandwidth determines how quickly data can be delivered to the computing hardware.

The two properties are related, but one does not replace the other. A large memory pool can hold more information without necessarily delivering it faster.

That distinction explains much of Intel’s decision.

HBM concentrates bandwidth near the processor

High-bandwidth memory uses stacked memory technology with very wide connections and advanced packaging close to the processor. Its purpose is to supply enormous volumes of data to a hungry accelerator with high energy efficiency per transferred bit.

LPDDR5X takes a different approach. It is designed for power-efficient memory operation and can be deployed in high-capacity configurations.

Using LPDDR5X does not mean installing ordinary removable laptop memory modules into a GPU. Onboard memory still requires a carefully engineered package, board, signal layout and memory controller.

Intel’s choice emphasizes the total capacity available to an inference workload within a particular power and server-design envelope.

The comparison makes the trade-off visible. Intel’s announced card has more memory capacity per accelerator than these particular HBM-based GPUs, but a lower published peak memory bandwidth.

That does not establish which GPU will be faster for an actual model. Peak bandwidth is a hardware capability, while application performance depends on kernels, batching, model architecture, precision and software.

A large model that cannot fit on one accelerator creates a different problem from a smaller model that fits easily but needs very high bandwidth.

Can a 480GB GPU really run a 300B model?

Memory calculations reveal both the opportunity and the limitation.

A model’s weights occupy memory according to the number of stored parameters and the number of bytes used to represent each. The simplest approximation ignores metadata and runtime state.

A 300B dense model represented with suitable eight-bit weights could, in principle, leave capacity for additional runtime state on a 480GB accelerator. The same model’s raw BF16 weights would exceed that capacity.

Actual deployment is more complicated. Operators need compatible model formats, supported kernels, enough usable memory and sufficient throughput.

A mixture-of-experts model adds another subtlety. Only some experts may perform computation for a particular token, but inactive weights can still need to remain resident in memory.

Our earlier explanation of why total and active parameters are different in MoE models explores exactly that distinction.

The KV cache changes the calculation

During inference, a transformer may retain key and value information from previously processed tokens. This KV cache helps avoid repeating work during autoregressive generation.

Its size depends on model architecture, context length, cache precision, caching strategy and how many requests are active.

When many users share one accelerator, their active contexts compete for the same memory pool as the model and other runtime allocations.

This is why additional capacity can be useful even when the weights of a model already fit.

More available memory may allow longer contexts, more simultaneous requests or less frequent preemption. But it does not guarantee lower latency if compute or memory bandwidth becomes saturated.

For a related failure mode, see why a model can fit in VRAM and still run out of memory when its context grows.

Where does the data move when this GPU runs an AI model?

Large memory capacity is only valuable when the software can keep the right data in the right place.

In a typical model-loading path, stored model files are read from SSD or networked storage into host memory and then transferred over a system interconnect such as PCIe to accelerator memory.

Once resident, model weights and runtime tensors are accessed by the accelerator’s computing hardware. The generated output eventually returns through the serving system to the application.

Keeping more model data on one accelerator can reduce the need to partition a model across multiple GPUs in some deployments.

That may reduce inter-device communication, but only if the software supports the model efficiently on the single card. It also concentrates the work on that accelerator’s available compute and memory bandwidth.

A GPU with more memory is therefore not automatically a faster GPU. Sometimes capacity makes a workload possible. Sometimes bandwidth determines how fast it runs.

Why a bigger memory pool can help one workload and slow another

Inference is not one uniform computational operation. Large language models typically process the existing prompt and then generate output tokens progressively.

Prefill: processing the input

During prefill, the system processes the input tokens and creates the required attention state.

Large prompt-processing batches can demand substantial compute throughput. Their efficiency also depends on kernels, memory access and scheduling.

Decode: producing the answer

During autoregressive decode, new tokens are generated step by step.

At small batch sizes, repeatedly accessing model weights can make bandwidth especially important. With more concurrent requests, compute utilization and other constraints can become increasingly significant.

Long contexts add another memory pressure through attention state and cache management.

This also explains why one tokens-per-second benchmark cannot capture the whole experience of a shared AI service.

Operators need to know time to first token, inter-token latency, completed requests, active concurrency and tail-latency behavior.

A card optimized for hosting large models and many active contexts may be attractive even if another accelerator achieves a higher result in a narrower benchmark.

Why 350 watts and air cooling matter

The other important number in Intel’s announcement is the 350 W power envelope.

The company is targeting a conventional PCIe accelerator form factor with air cooling rather than requiring a custom liquid-cooled rack.

For an operator, that changes the deployment conversation. A standard server can offer a different integration path from a tightly coupled, high-power accelerator baseboard.

But the distinction has limits. A 350 W GPU does not make the entire server a 350 W system. CPUs, RAM, network interfaces, drives, cooling fans and power-conversion losses also consume electricity.

Moreover, the published power envelope is not a measured estimate of how much energy the device needs to complete a real workload.

A slower accelerator may draw less instantaneous power but require more time to finish a job. A faster accelerator may draw more power while processing more requests.

Meaningful efficiency comparisons therefore need completed work, energy and service quality measured together.

Our investigation of a 135 kW liquid-cooled AI rack shows what happens when compute density creates a much larger cooling and power-delivery challenge.

What Intel’s specification sheet still cannot tell us

The hardware concept is clear. The real-world comparison remains open.

Intel’s published figures establish intended capacity, peak bandwidth, compute capability and board-power characteristics.

They do not establish what the card will deliver for every large language model, every serving engine or every concurrency level.

Software maturity is another practical consideration. An accelerator may offer excellent hardware specifications but still need tuned kernels, reliable quantization support, model-specific implementations and a stable serving stack.

Intel positions the D-series within its Xe software ecosystem and has identified open frameworks as part of its deployment strategy.

Framework compatibility should still be checked against the actual card, driver version, precision format and model being deployed.

What an operator should compare

Imagine testing one large model on a memory-rich LPDDR5X accelerator and a competing HBM-based configuration.

The comparison must use equivalent workloads, quality settings, request distributions and latency targets.

It should also measure the full server rather than treating the accelerator’s board rating as its actual energy cost.

The experiment that would test Intel’s memory bet

A useful first-party investigation would compare a model that already fits comfortably within an HBM accelerator against a larger model or context configuration that benefits from the D-series capacity.

That distinction matters. Testing only a small model would favor a different set of constraints from testing a large model with many active sessions.

Sources and reporting notes

Specifications are taken from official vendor documentation. Product capacities and theoretical peak bandwidth are not independent performance measurements. The model-memory examples are arithmetic estimates, and no first-party Intel GPU benchmark was conducted for this article.

1. Intel — Accelerates Open Infrastructure for the Agentic AI Era . October 12, 2026. Product announcement and GPU D-series specifications.
2. Intel — GPU D-series / D270 . Official product overview, memory, form factor and workload positioning.
3. NVIDIA — HGX AI Factory Components . Official H200 memory capacity and bandwidth specifications.
4. AMD — Instinct MI355X . Official capacity, bandwidth and board-power specifications.
5. vLLM — Optimization and Tuning . KV cache management, preemption, chunked prefill and inference scheduling behavior.