At the OCP Global Summit on October 12, 2026, Intel announced detailed specifications for its D-series AI inference GPU and a new rack design built around Xeon processors. The vision is that GPUs handle AI model inference while CPUs support data processing and the execution of external tools, and Intel is now fleshing it out in both hardware and open-source software. The GPU, previewed in 2025, has moved to the customer-sampling stage, and options for building AI inference environments in existing data centers are widening.
However, the speed at which an AI model generates text is not the same as the time it takes an AI agent to complete an entire task. To evaluate Intel's proposal properly, you need to look beyond the division of labor between CPUs and GPUs and also consider delays across the whole process, such as data retrieval, data transfer, and waiting for responses from external services.
Breaking down an AI agent's workload shows why CPUs matter
In the official announcement, Nicolas Dubé, corporate vice president in charge of systems in Intel's data center group, described the goal as sending "every prompt to the right place." The idea is to choose the right computing resources for the AI capabilities a company needs, and to optimize costs.
This involves two different decisions. One is which AI model should handle a task. The other is which processor should handle each step as an AI agent works through a job. Optimizing only the choice of model will not shorten the overall time for a task if the steps before and after it are slow.
Consider, for example, an AI agent that searches internal company policies to answer employee questions. This is a hypothetical example to illustrate the mechanism. After a question is received, relevant documents must be searched and access permissions checked. After the model generates an answer, the result must be recorded in a business system. GPUs, which excel at the inference computation of AI models, and CPUs, which handle search and external tool calls, are asked to play different roles.
Intel also emphasizes this division of labor in its explanation of its software strategy. CPUs take on data preparation and transfer, asynchronous request handling, and management of external tool execution. When a model decides on its next action and calls an external service, it may be unable to move on to the next inference step until that service responds.
The value of strengthening CPUs in such an environment is not only in taking over work from GPUs. It also lies in keeping data preparation and tool execution running smoothly, reducing the time GPUs sit idle waiting for work.
That said, if the bottleneck lies in the network or an external service, adding CPU capacity alone will not solve the problem. What matters is not the standalone performance of GPUs or CPUs, but measuring the whole agent workflow to understand where the time is going.
A 350W air-cooled GPU and Xeon racks with more than 46,000 cores
The D-series, whose details Intel has now disclosed, is the AI inference GPU previously known by the code name "Crescent Island."
In its October 2025 announcement, Intel outlined a plan to use the Xe3P architecture with 160GB of LPDDR5X memory and to begin customer sampling in the second half of 2026. This latest announcement states explicitly that sampling is already under way, meaning development has progressed to the stage of customer evaluation.
The main specifications now disclosed are FP8 performance of 1.3 PFLOPS, memory bandwidth of 1.5TB/s, and a maximum power consumption of 350W. It uses a standard PCIe card form factor with air cooling, a design intended to be easy to deploy in existing data center facilities.
Memory capacity is 160GB on Intel's own card, and up to 480GB on ODM cards designed by partner companies. However, 480GB is the maximum expected for partner cards and will not be installed on every D-series product.
Large memory capacity makes it easier to handle large AI models and long contexts. On the other hand, the 350W power rating of the GPU alone does not tell you power efficiency in real workloads. You also need to consider the power consumption of the entire server, including the CPU and memory, along with the time taken to complete the work.
Although this disclosure clarifies where the D-series sits in the lineup, it has not reached the point where pricing or actual inference performance can be compared against competing products.
For Xeon-based systems, meanwhile, Intel showed even larger configurations. Many of the rack designs Intel developed with partners use the Open Rack v3 (ORv3) standard. In some Xeon 6+ configurations, the rack holds more than 46,000 CPU cores, and total rack power consumption reaches 133.45kW.
The concept is to concentrate general-purpose compute at high density in order to run many AI agents in parallel.
However, a 350W air-cooled GPU card and a 133.45kW CPU rack differ greatly in system scale and in what is being measured for power. The facility and power-supply requirements also differ between adding D-series cards to existing servers and newly deploying high-density Xeon racks.
Intel's stated policy of "running the right workload in the right place" does not mean every AI system can be run using only small air-cooled facilities. It presupposes choosing an appropriate configuration for the use case and the scale of processing.
How far along is the open-source Agent Toolkit?
Intel is building out not only hardware but also a software foundation for deploying AI agents in enterprise systems. At present, however, availability varies by product and feature.
Organizing the October 12 official announcement and the official README for the "AI for Enterprise Agent Toolkit" as of October 14 gives the following picture.
| Item | Publicly stated availability | Points to note when adopting |
|---|---|---|
| Intel GPU D-series | Customer samples being provided | Does not mean general sales or volume shipments have begun |
| AI for Enterprise Agent Toolkit | Optimized for Xeon and ready to deploy | Performance in real workloads needs separate verification |
| The Toolkit's Intel GPU support | Designed with expanded GPU support in mind | Not a guarantee that all features work on the D-series |
| Connecting to GPUs and cloud AI models | Connection targets can be added through a common interface | API connections to external models differ from optimizations for a specific GPU |
This table organizes the support status described in public materials and is not the result of compatibility testing on actual hardware. In particular, being able to call an AI model running on an external GPU is different from having the entire system, including the D-series, verified to work.
Companies would evaluate the Agent Toolkit's features on their existing Xeon environments while checking GPU-side support case by case.
So what does this Toolkit actually provide?
According to the README published on GitHub, it uses LiteLLM as its API gateway, handling authentication, access control, and request routing in one place. It can also select the inference destination for an AI model based on the task, leaving complex reasoning to GPUs or the cloud while combining it with processing suited to Xeon.
It also includes features for connecting to external tools and a mechanism for running code generated by AI agents in an isolated environment. It uses Redis and PostgreSQL for state management, tracks processing through tools such as Langfuse, supports operation on Kubernetes, and adopts a flexible architecture in which implementations of each function can be swapped.
These features support connection to enterprise systems and operational management, which cannot be achieved simply by running an AI model.
However, just because the inference destination can be switched flexibly does not mean the optimal model will always be chosen automatically. Answer quality and processing speed differ by model, and there is also the question of how much internal data can be sent outside the company.
For that reason, a feature being listed in the README should be considered separately from whether it can meet the quality and security requirements of real operations. After confirming what the published software can do, it is important to clarify the conditions that need to be tested in your own environment.
AI infrastructure is being judged less on raw inference speed and more on how much work gets done
What Intel emphasizes is not the performance of an individual CPU or GPU, but a metric of how much work AI agents can actually complete.
In an opinion piece dated August 20, 2026, the company set out an approach of evaluating how much AI agent work an entire rack can complete while maintaining the required response time and answer quality.
This means measuring not just CPU core counts or single-request inference speed, but how much work can be completed stably as the number of concurrently running AI agents increases. For the high-density Xeon racks announced this time, only an evaluation under such conditions will reveal real-world processing capability.
Intel has also indicated it plans to report rack throughput using traces of actual AI agent runs, with p99 latency targets set.
p99 latency is the time within which 99% of requests complete when processing times are sorted from shortest to longest. Even if average response time is short, extreme delays in some requests can disrupt the overall workflow.
At present, though, it is necessary to distinguish between a policy on measurement methods and actual measured results showing that Intel has outperformed competing products under the same conditions.
Splitting inference also carries a communication cost
Intel's software strategy also covers configurations in which the inference process of an AI model itself is divided across multiple systems.
For example, "prefill," which processes the input prompt and context, and "decode," which generates tokens one after another, can be run on different systems.
These two processes require different compute performance and memory bandwidth. By allocating them to the computing resources best suited to each, it may be possible to improve equipment utilization in large-scale inference environments.
However, splitting the work also creates new burdens.
When prefill and decode run on separate systems, the "KV cache," which holds the intermediate state of inference, must be transferred between them. If this data transfer takes time, or if requests concentrate on some servers, the benefits of dividing the work could be lost.
In other words, not only when routing between AI models but also when splitting the processing inside a model, communication performance and state management determine the throughput of the whole system.
What should you use as the basis for comparing Intel's AI platform?
Companies evaluating Intel's new AI infrastructure should first set up conditions close to their real workloads and compare systems with answer quality and acceptable latency held constant.
Concretely, that means using the same AI models and input conditions, increasing the number of concurrent agents, and measuring how many jobs are completed within a given time along with response times. It is important to record separately the time spent on model inference and the time spent waiting for external tools or data retrieval.
Measuring the power consumption of the entire server, not just the CPU and GPU, would also make it easier to compare power efficiency against throughput.
Such evaluation makes it possible to judge whether to add GPUs, strengthen CPUs, or improve network or external-service response times to raise performance.
Going forward, in addition to the general availability date and pricing of the D-series and the state of software support, results from performance measurements under unified conditions will be important. Once that information is available, Intel's proposal can be compared on both deployment cost and real-world workload throughput.
Intel's aim is not simply to supply high-performance GPUs or high-density CPU racks. It is to raise efficiency across the whole system, from model inference to data processing and external tool execution.
To judge whether that strategy succeeds, we need to see whether companies can complete more work while maintaining the same answer quality and response times.