On September 28, TrendForce announced that lead times for server CPUs have reached 25–30 weeks. That is well above the 16–20 weeks seen when supply and demand are in balance, and it means CPUs continue to take a long time to procure. TrendForce also mentioned Meta's personal AI agent, Muse, noting that debate has resurfaced over how much AI agents will boost CPU demand.
However, the 16–20 week benchmark is not a figure measured under the same conditions just before Muse launched. TrendForce had already reported supply constraints on general-purpose server CPUs and other components back in April.
What the new 25–30 week figure tells us is that the CPU market is currently tight. It does not tell us how many weeks Muse added to lead times.
Nor can we directly estimate how many physical CPUs Meta will actually buy from the fact that Muse is designed to give each user a dedicated virtual machine (VM).
What Does "25–30 Weeks" Actually Measure?
In TrendForce's September 28 post, the firm explained that it has added server CPUs to its weekly survey, "Weekly Radar."
The current lead time it reported is 25–30 weeks, with 16–20 weeks cited as the level in a "balanced supply-demand market." For companies planning server deployments, this is an important figure: it suggests that going from order to delivery could take nearly half a year.
The published post, however, does not state the CPU models covered, the regions, the number of suppliers surveyed, or the survey period.
It therefore can't be said that a uniform 25–30 week lead time applies to every Intel or AMD server CPU. Naturally, it is also not a figure for PC CPUs.
Companies making actual deployment plans need to check individually with suppliers for lead times on the specific models and quantities they need.
CPU lead time is also not the same as the time until a server built with that CPU is actually running.
If other components such as memory, circuit boards, power supplies, or racks are delayed, server deployment slips even if the CPUs are secured. Conversely, the 25–30 week figure can't simply be applied to projects by companies that have already locked in CPU inventory.
Care is also needed in reading the "16–20 weeks to 25–30 weeks" comparison.
The 16–20 weeks is a baseline assuming a balanced market; it is not described as a measurement taken under the same conditions just before Muse launched on September 8.
The gap between the two figures therefore can't be calculated as the extension in lead times since Muse appeared.
TrendForce's post itself says only that AI agents like Muse are raising interest in server CPU demand. It did not measure that orders from Muse lengthened lead times.
The CPU Shortage Predates Muse
CPU supply constraints had surfaced before Muse appeared.
In its April 15 announcement, TrendForce reported that lead times for key components, including printed circuit boards (PCBs) and CPUs for general-purpose servers, had reached up to about one year.
The explanation was that priority production of components for AI servers was squeezing the supply of ordinary servers.
In its July 9 announcement, it reported that server CPU shortages were delaying system assembly, and that U.S. cloud providers were accumulating inventories of DRAM they had procured earlier.
TrendForce had forecast that CPU supply would gradually improve from the second half of 2026 into 2027, but that is a future outlook, not a statement that the shortage has already been resolved.
| Date | Subject covered by TrendForce | What was announced | Caution when comparing |
|---|---|---|---|
| April 15, 2026 | General-purpose server CPUs, PCBs, etc. | Lead times for key components up to about one year | A maximum across multiple components; conditions differ from the September CPU metric |
| July 9, 2026 | Server CPUs and system assembly | CPU shortage delays assembly; U.S. cloud providers' DRAM inventory rises | No specific CPU lead time given |
| September 28, 2026 | Weekly Radar CPU survey | Currently 25–30 weeks; 16–20 weeks when supply and demand are balanced | Models, regions, survey period, etc. not stated in the post |
The "up to about one year" in April and the "25–30 weeks" in September involve different components and survey conditions. Comparing the two doesn't allow us to conclude that lead times improved or worsened after Muse launched.
What these three data points do show is that the shortage of server components, including CPUs, did not suddenly begin in September. Component procurement was already affected in April, and by July the CPU shortage was delaying server assembly.
A "Dedicated VM" Does Not Mean Dedicated Physical CPUs
According to Meta's September 8 announcement, Muse runs on a per-user dedicated virtual machine, the "Muse Secure VM," and can keep working after the app is closed.
The VM provides a working environment including a browser, and the user's data and credentials for connected services are isolated from other users.
For an AI agent to operate websites or process files, it needs CPU resources to run the browser, OS, and tools, separate from the GPUs that run the AI model itself.
But having a dedicated VM per user does not mean each user monopolizes physical CPU cores.
It is generally possible to run multiple VMs on a single physical server and share CPU processing power among them.
The amount of CPU actually needed depends not only on the total number of registered users. The number of VMs running at the same time, the CPU resources VMs consume while idle, and the spare capacity reserved for short load spikes all matter.
Meta's announcement does not disclose these operational figures or the number of CPUs it is procuring.
In Meta's explanation, at least, "dedicated to the user" describes a design that separates each user's working environment and data. It should be considered separately from any performance guarantee that a person always monopolizes physical computing resources.
DeepSeek's Case: Running 380,000 Sandboxes
Another example shows that virtual environments and physical CPUs don't map one-to-one.
DeepSeek's preprint published on arXiv in September, "DeepSeek Elastic Compute (DSec)", reports on a large-scale sandbox infrastructure used to train and evaluate AI agents.
According to the paper, for about 90% of containers and micro-VMs, average CPU usage was 5% or less of the CPU resources requested in the allocation.
The reason is that the CPUs in the working environment sit nearly idle for long stretches, such as while the AI model is generating its next action.
DSec exploits this load profile by overcommitting, allocating more virtual CPU resources than physically exist.
One large-scale configuration described in the paper had about 160 nodes and about 30,000 CPU cores, and at peak ran more than 380,000 sandboxes simultaneously.
However, DSec is not a study that measured the commercial Muse service.
DSec mainly handles temporary execution environments used for training and evaluating AI agents. Muse's VMs, by contrast, are premised on retaining user data and allowing continued work.
Required memory, isolation methods, VM uptime, and load patterns may differ.
The "5% or less of requested CPU resources" figure from DSec therefore can't be applied directly to Muse's capacity planning. Nor can the 380,000 simultaneous sandboxes be swapped in as Muse's user count.
What can be read from this example is that the number of virtual CPUs or VMs alone does not reveal how many physical CPUs are needed.
What Companies Should Check When Procuring CPUs
In its May analysis, TrendForce explained that the spread of AI agents will increase demand for CPUs that handle task scheduling, data preprocessing, memory management, and similar work.
Even when GPUs handle the large-scale computation of AI models, CPUs around them keep allocating work, processing data, and managing the agents' execution environments.
That is why CPUs can't be ignored in thinking about AI infrastructure.
But such market-wide trends don't allow us to estimate the lead time of a specific CPU product, or the quantity a company like Meta will actually order.
Companies procuring servers need to check not only lead times for each CPU model they need but also whether they can secure other components, such as memory and boards, in the same time frame.
In the DRAM inventory example TrendForce reported in July, servers couldn't be assembled when CPUs were short, even though the memory had been secured first.
In other words, CPU lead time alone doesn't tell you when a finished server will be running.
When multiple components are ordered at different times, the last to arrive determines when assembly can actually start.
And as TrendForce pointed out in April, if chipmakers and component suppliers prioritize products for AI servers, components for general-purpose servers could become even harder to secure.
To judge how much new CPU demand a personal AI agent like Muse will create, you would need the number of continuously active users, the number of concurrently running VMs, how many VMs can be consolidated on a single physical server, and the CPUs Meta adopts and the quantities it actually procures.
What TrendForce's 25–30 week figure shows at this point is that the server CPU procurement environment is tough. There are structural reasons AI agents could push up CPU demand, but this figure alone can't separate out how much Muse contributed to the longer lead times.