2026.09.22 | 9K | Agents | Meta FAIR Engineer on Muse

Meta硬件专家

纪要总结

Meta Muse智能体基础设施专家访谈纪要

1. 专家背景与Muse项目定位

a) 专家是否直接参与Meta Muse智能体项目？

• 专家为Meta FAIR Labs（基础人工智能研究实验室）首席研究工程师。

• 专家是Muse部分产品线约50名工程师之一，直接参与开源及闭源版本开发。

• Muse基础设施主要涉及CPU、GPU、内存、存储、网络及数据中心建设。

2. 智能体工作负载下的CPU选型

a) 不同类型的智能体工作负载应如何选择CPU？

• 浏览器、沙箱及代码执行

1. 更看重核心密度，单插槽通常需要64至128个物理核心。

1. 每台主机可运行50至200个相互隔离的智能体环境。

1. 工作负载并行度较高，核心数量、缓存和内存容量较为关键。

• 文档解析和预处理

1. 更看重内存带宽及内存容量。

1. 每个节点通常需要8至12个DDR5通道，以及512GB至1.5TB内存。

1. 此类流程往往先触及内存带宽瓶颈，而非算术吞吐能力上限。

• 智能体编排

1. 需要平衡核心数量与单线程性能。

1. Python运行时、调度器、序列化和RPC处理均对延迟较敏感。

1. 即使CPU整体利用率只有50%至70%，单线程瓶颈仍可能影响服务时延。

• CPU到GPU服务节点

1. 应优先考虑PCIe带宽、NUMA拓扑和网络I/O，而非单纯追求最大核心数。

1. 典型配置为2颗64至96核心CPU支持8个加速器，并配备400至800GB/s网络带宽。

b) Muse是否必须采购高端CPU？

• Muse仍以服务器级CPU为主，但不会无差别采购最高端SKU。

• 只有当高端SKU能够明显提高任务吞吐量、并发能力或GPU利用率时，才具备经济性。

• 典型选型如下：

1. 浏览器沙箱执行采用96至128核心的高密度服务器SKU。

1. 解析和ETL可采用具备更多内存通道、更大缓存及更强I/O能力的高端SKU。

1. 轻负载编排层采用32至64核心的较低价SKU，避免配置浪费。

• 经济性判断的核心是，高端CPU能否降低每项任务的CPU时间或提高安全并发能力：

1. 如果15,000美元CPU相比8,000美元CPU仅多完成5%的任务，不适合大规模部署。

1. 如果内存带宽密集型任务吞吐量提高30%至40%，高端CPU则具备较强经济性。

c) 高端CPU是否能够降低总体成本？

• 仅在部分场景成立，关键目标是提高单位服务器的工作负载密度。

• 同级配置升级中，高端服务器CPU价格可能高出30%至60%，但有效吞吐量可提高50%至100%。

• 是否节省成本需要综合考量：

1. 服务等级协议（SLA）。

1. GPU利用率。

1. 机架密度。

1. 每项已完成任务的总成本。

• 工作负载规模大本身并不足以证明必须采用高端CPU。

d) 哪些场景必须采用高端服务器CPU？

• 当低端SKU形成无法通过增加普通服务器经济解决的硬性瓶颈时，高端CPU是必要选择。

• 主要场景包括：

1. 高并发浏览器、代码及容器沙箱。

1. 同时具有大内存、高I/O和低延迟要求的智能体执行。

1. 为高价值GPU提供预处理、词元化、网络和编排支持。

• 典型需求可能达到：

1. 96至128个CPU核心。

1. 500GB/s以上聚合内存带宽。

1. 512GB至1TB内存。

1. 足够的PCIe和网络带宽。

• 如果一台8 GPU服务器搭载价值20万至40万美元的加速器，为节省5,000至10,000美元降低CPU配置，却导致GPU闲置5%至10%，总体上并不经济。

• 高端CPU本质上是对昂贵GPU容量的利用率保障。

e) 必须使用高端CPU的具体案例有哪些？

• 文档密集型智能体

1. 单项任务接收300页PDF及50个附件。

1. 同时执行PDF解码、OCR准备、HTML转换、分块、嵌入准备和压缩。

1. 当并发任务达到50至100个时，96个以上核心及高内存带宽的重要性高于标称时钟频率。

• 高密度代码沙箱

1. 单台机器运行100至250个相互隔离的Python、JavaScript或容器沙箱。

1. 每个活跃任务平均占用0.5个核心，峰值可能达到2至4个核心。

1. 32核心通用服务器难以在高并发条件下高效运行。

3. 高端服务器CPU渗透率与价格

a) 智能体场景中高端CPU占比将如何变化？

• 各类工作负载的高端CPU渗透率预计如下：

• 专家观察到的长期合理区间为60%至65%，并不意味着所有智能体CPU都会高端化。

b) 常规与高端服务器CPU的ASP分别是多少？

• 常规服务器CPU：

1. 面向超大规模客户的单颗ASP为4,000至5,000美元。

1. 通常配置32至64个核心。

• 高端服务器CPU：

1. 单颗ASP为9,500至11,500美元。

1. 通常配置96至192个核心，并具备更高带宽及更大缓存。

• 最高规格及专用CPU：

1. 单颗ASP为14,000至16,000美元以上。

1. 主要用于加速器主机及最高密度工作负载。

• 建模中通常采用主流CPU 5,000美元、高端CPU 10,000美元，即高端产品ASP约为主流产品的2倍。

• 此处与“高端SKU成本高30%至60%”并不完全矛盾：前者是主流与高端产品组合的平均ASP比较，后者更多指同类平台中的配置升级幅度。

c) 不同CPU价格分别对应多少核心？

• 原始记录中“高端高核心数产品的单颗GPU ASP”应为“CPU ASP”。

4. PC CPU与服务器CPU的适用边界

a) 消费级PC CPU能否运行智能体任务？

• 可以运行浏览器智能体、Python沙箱、文档解析器及本地编码智能体。

• 桌面CPU通常配置8至24个核心和64至192GB内存，足以支持单用户或轻量级任务。

• 对于API及工具调用、供应商通话、VoIP编排、1至2个浏览器会话、电子邮件、网页抓取和轻量文档解析，实际只需占用1至2个CPU核心。

• 一颗8至16核消费级CPU可以同时支持多个此类智能体。

b) 为什么消费级CPU不适合超大规模智能体服务？

• “不经济”主要针对超大规模生产集群，而非单用户场景。

• 当云端服务需要支持10万个并发智能体时，服务器CPU更具优势，原因包括：

1. 单插槽可提供64至192个以上核心。

1. 支持数百GB至TB级ECC内存。

1. 具备更多内存通道及PCIe资源。

1. 提供更高可靠性、可用性和可维护性能力。

• 结论是：PC CPU能够支持基础智能体功能，但在用户规模和并发量较大时不具备经济性。

5. x86与ARM架构选择

a) Muse当前CPU架构如何分配？

• 当前CPU容量约为：

1. x86占71%。

1. ARM占29%。

• 长期预计调整至：

1. x86占55%。

1. ARM占45%。

b) 哪些工作负载更适合x86？

• 浏览器自动化、任意客户代码、容器、沙箱及遗留二进制文件更适合x86。

• x86的核心优势是兼容性和成熟软件生态，而非其在AI计算方面天然更强。

• x86适合运行：

1. Chromium及相关扩展。

1. 带原生扩展的Python软件包。

1. Node模块、Java和数据库客户端。

1. 第三方或专有二进制文件。

• ARM可能支持90%至95%的控制栈，但剩余5%至10%的兼容性问题在数百万项异构任务中会产生较高运维成本。

c) 哪些工作负载更适合ARM？

• 在企业可以控制并验证完整软件栈的情况下，ARM更适合：

1. 编排和API服务。

1. 工具调用。

1. ETL。

1. 检索。

1. 无状态微服务。

• 某项每天处理100亿次RPC的标准化编排服务中，ARM每瓦性能可提高25%，适合积极迁移。

• 即使ARM单位吞吐成本低20%，如果任务涉及任意软件包或第三方二进制文件，Meta仍可能选择x86，以规避兼容性故障。

d) 为什么x86长期仍将占据主导地位？

• 主要原因包括：

1. 数十年积累的软件兼容性及测试生态。

1. 现有数据中心拥有大量x86设备、容器镜像、运维工具和安全沙箱技术。

1. 企业已经拥有熟悉x86系统的工程团队。

1. AMD EPYC和Intel Xeon具备成熟的高核心数、大内存、PCIe和虚拟化能力。

• ARM迁移通常需要实现15%至30%的总体拥有成本改善，才能覆盖验证及迁移成本。

• 智能体越通用、越自主，向后兼容性越重要；ARM的机会主要集中在平台可控制整个软件环境的标准化服务中。

6. 智能体场景下CPU与GPU配比

a) 当前及未来每个GPU需要多少CPU资源？

• 当前智能体额外CPU需求主要来自工具调用、浏览器操作、检索和解析。

• 更长期的计算机操作、代码和多模态工作流将需要持久化执行环境。

• 原始记录将长期时间点表述为“2039年及以后”，结合上下文可能存在年份口误，核心判断是长期每GPU对应3至4颗CPU。

b) MTIA系统的CPU与加速器配比如何？

• Meta新型MTIA 300系统采用约1:1的CPU与加速器配比。

• 主要原因包括：

1. 支持CPU卸载。

1. 智能体推理产生更小、更频繁且对延迟更敏感的通信模式。

1. AI负载正从单一大模型推理转向异构推理及测试时推理。

7. 各类智能体任务的CPU资源消耗

a) 不同工作负载的CPU核心、CPU秒及并发量分别是多少？

b) 未来复杂任务占比是否会提升？

• 智能体CPU需求增速预计高于请求量增速，主要原因是任务结构向多步骤、长周期任务迁移。

• 任务结构预计如下：

1. 简单API调用、查询和消息任务：2026年占55%，2030年降至30%，每项消耗2至20 CPU秒。

1. 浏览器操作、工具调用和检索等中等复杂任务：当前占30%，3至4年后升至38%，每项消耗30至150 CPU秒。

1. 长周期自主任务：当前占3%，3年后升至7%，4年后升至12%，每项消耗500至2,000+ CPU秒。

• 即使智能体请求量每年仅增长30%，复杂任务占比上升也会使智能体CPU算力需求增长超过30%。

c) 智能体CPU算力增长是否等于物理CPU出货量增长？

• 不等同。

• 新一代CPU每个插槽能够提供更多核心及更高性能。

• 智能体CPU算力需求增长50%，并不意味着物理CPU数量也增长50%。

• 专家模型显示：

1. CPU计算需求每年增长约20%。

1. 物理CPU插槽需求每年增长约6%。

1. 高端产品组合及ESPV提升贡献约4%。

8. 全球CPU市场增长判断

a) 未来全球CPU市场收入增速是多少？

• 基准情景下，全球CPU市场收入预计到2030年保持约10%的复合年增长率。

• 各细分市场增速明显分化：

1. 消费级PC CPU：年增长2%至5%。

1. 传统企业服务器CPU：年增长约7%。

1. 云端超大规模服务器CPU：年增长约12%。

1. 高端高核心数服务器CPU：年增长约20%。

1. 支持AI智能体的CPU容量：年增长25%至45%。

1. 智能体专用CPU容量：年增长约45%。

b) 为什么CPU市场收入增速高于出货量增速？

• 智能体提高CPU使用强度

1. 简单聊天机器人RAG请求约需2至10单位CPU计算量。

1. 复杂研究及编码任务约需150至600单位CPU计算量。

1. 长周期智能体可能需要500至2,000以上单位CPU计算量。

• 产品组合向高端迁移

1. 高端服务器CPU ASP约11,000美元。

1. 主流服务器CPU ASP约5,000美元。

1. 市场向96至192核心产品迁移，可在插槽数量增幅有限的情况下推动收入提升。

• AI基础设施需要更多CPU

1. 传统推理每GPU约需0.5至1个CPU等效计算量。

1. 当前智能体需要1至2个。

1. 未来执行密集型智能体需要2至4个。

• 性能提升形成抵消

1. 假设每个插槽CPU性能每年提升20%。

1. CPU计算需求增长40%时，处理器数量无需同步增长40%。

9. CPU供应短缺与ASP趋势

a) 当前服务器CPU是否存在供应限制？

• 服务器CPU已出现明显供应紧张。

• AMD交付周期约为8至10周。

• 英特尔受影响市场的交付延迟最长达到6个月。

• 当前不同产品的典型交付周期为：

1. 主流服务器CPU：2至4个月。

1. 高端服务器CPU：约6个月。

1. 专用或最新款CPU：约9个月或更长。

1. AI GPU及加速器：主要由合同和配额决定，难以用固定交付周期衡量。

• AMD已扩大下一代EPYC Venice的产量，该产品采用台积电2纳米制程，供应状况预计后续逐步改善。

b) 服务器CPU ASP未来如何变化？

• 高端与主流服务器CPU的ASP比值预计由当前2倍升至2.25倍。

• ASP上涨不仅由供应短缺驱动，也受到高核心数、高带宽和高端产品组合迁移影响。

c) 当前及未来CPU供需缺口有多大？

• 当前基准供应缺口约为12%至13%。

• 高核心数SKU供应缺口约为17%。

• 供需缺口预计如下：

1. 当前：约12%至13%。

1. 明年：约15%。

1. 2028年：约17%。

1. 2029年：约11.5%。

1. 2030年：约6.5%。

• 2027至2028年是主要风险期。

• 需求端驱动包括浏览器及代码任务增加、每个加速器配套CPU容量提升，以及向96至192核心产品迁移。

• 供应端则受到晶圆代工、先进封装、内存、基板及服务器认证周期制约。

10. DRAM、SSD及存储需求

a) 企业级SSD供应趋紧是否与智能体有关？

• 企业级SSD供应趋紧与AI基础设施周期相关，但智能体并非唯一驱动力。

• AI集群正在扩展：

1. 模型和训练检查点存储。

1. 模型、嵌入及向量数据库。

1. 训练数据集。

1. KV缓存卸载。

1. 智能体记忆及高吞吐暂存层。

• 当前AI相关企业级SSD增量需求中：

1. 传统AI基础设施扩张贡献约60%至70%。

1. 智能体工作负载贡献约15%至25%。

• 到2029年，随着持久化记忆和检索发展，智能体对增量SSD需求的贡献预计升至30%至40%。

b) 各类基础设施容量需求增速如何？

• GPU及HBM需求：年增长约32%。

• 高端服务器CPU：年增长约20%。

• 高带宽服务器DRAM：年增长约55%。

• 企业级SSD容量：年增长约24%。

• 高性能企业级NVMe：年增长约30%。

• HDD及冷存储：年增长约9%。

• 原始记录中的“HPM”应为“HBM”。

c) 20至30分钟的Muse任务需要多少SSD？

• 必须区分“处理100亿个Token”和“永久存储100亿个Token”。

• 处理100亿个Token的工作流：

1. 每个并发智能体需要10至30GB本地NVMe工作容量。

1. 任务完成后需保留约1至5GB。

• 100亿个Token按每Token约4字节计算，原始文本约为40GB。

• 实际执行期间还会生成截图、嵌入、索引、日志及临时文件，但压缩和去重会减少容量需求。

• 模型权重及检查点属于共享基础设施，不会为每个用户任务单独创建。

• 单项任务的主要SSD负担来自：

1. RAG数据。

1. 浏览器及沙箱状态。

1. 任务产物。

1. 日志及缓存。

d) 10万个重型并发智能体需要多少SSD？

• 按每个智能体20GB工作集计算，需要约2PB活动SSD容量。

• 该数字尚未计入：

1. 数据复制。

1. 备用容量。

1. 数据库。

1. 共享RAG语料库。

1. 模型存储。

1. 系统开销。

e) DRAM和NAND哪一类增长更快？

• 短期内DRAM需求增速快于NAND及SSD：

1. 服务器DRAM容量需求年增长约30%。

1. 高带宽高端服务器DRAM增长约30%至35%。

1. NAND需求增长约23%。

1. 高性能企业级NVMe增长约30%。

1. 通用NAND增长约15%。

• 核心原因是：

1. 智能体正在主动处理的内容必须放在DRAM中。

1. 后续可能使用的内容可以放在SSD中。

1. 高核心数CPU需要高内存带宽才能发挥性能。

f) 单个智能体及未来节点的内存配置如何？

• 对20至30分钟Muse任务，每个并发智能体预计配置：

1. 约6GB增量活跃DRAM。

1. 10至30GB SSD工作容量。

• 未来高密度智能体节点预计配置：

1. 128至192个CPU核心。

1. 1至2TB DRAM。

1. 15至60TB企业级NVMe。

• 当前通用CPU节点通常仅配置256至512GB DRAM。

• 智能体基础设施可能推动每个CPU插槽配置的DRAM容量提升2至4倍。

• NAND的长期优势在于持久化记忆、嵌入、用户文件、执行轨迹和RAG语料会持续累积。

11. 软件优化与网站重构的节省空间

a) 软件工程优化可以节省多少CPU资源？

• 相较未经优化的实现，软件和工作负载工程优化整体可降低约35%的CPU需求。

• 部分浏览器工作负载最高可节省60%。

• RAG及查询缓存可节省约17%。

b) 网站重构如何降低浏览器智能体的CPU消耗？

• 未经优化的计算机操作智能体需要：

1. 启动Chromium。

1. 下载约10MB页面数据。

1. 执行数百个JavaScript任务。

1. 完成布局、渲染及截图。

1. 再由模型理解页面像素。

• 通过DOM和无障碍API，可将页面重构为轻量语义数据，如产品、价格、库存、尺码和操作按钮。

• 每次浏览器交互的CPU时间可由10至30 CPU秒降至3至10 CPU秒。

• 对应CPU资源节省幅度约为50%至70%。

c) 优化能否抵消智能体带来的CPU需求增长？

• 不能完全抵消。

• 专家示例显示：

1. 未来智能体执行的浏览器工具及代码操作达到当前3倍。

1. 原始需求从200 CPU秒上升至600 CPU秒。

1. 优化40%后仍需要360 CPU秒。

1. 相比当前未经优化水平，单项用户任务CPU需求仍为1.8倍。

• 当前供应缺口预测已经考虑浏览器重构、缓存、预热沙箱池、合理调度和高效解析等优化。

• 如果不优化，CPU需求缺口可能达到约30%，但这并非现实基准情景。

12. 智能体对GPU使用量的影响

a) 智能体相比聊天机器人会增加多少GPU计算？

• 聊天机器人通常在每轮交互中调用GPU一次。

• 智能体通过执行循环，在完成任务前多次调用GPU。

• 一项供应商搜索任务可能包括：

1. GPU制定计划。

1. CPU和浏览器搜索供应商。

1. GPU解读搜索结果。

1. CPU打开供应商页面。

1. GPU判断重要信息。

1. CPU提取价格。

1. GPU比较报价。

• 一个用户请求可能产生8至15次GPU推理调用。

• 由于中间调用规模较小，整体GPU计算量并非简单增加10倍。

• 相较聊天机器人1个计算单位，一个包含10个步骤的智能体通常消耗约5至10个GPU计算单位。

b) 小模型路由能否降低智能体的GPU需求？

• 智能体需要将GPU需求拆分为：

1. Token总量。

1. 每个Token的计算量。

• 一项智能体任务的Token量可能是聊天机器人任务的10倍。

• 通过模型路由，60%至80%的Token无需调用最大模型，使每Token平均计算量降低2至5倍。

• 因此，每项任务的GPU计算量预计增加约2至5倍，而非与Token量同步增加10倍。

• 常规观察和工具决策可由30亿至300亿参数模型处理，只有复杂规划或综合分析才调用大模型。

c) Muse和Groq是否有固定模型参数规模？

• Muse未公布统一参数规模。

• Muse采用由路由器调度的模型组合，而非每个步骤都调用最大Llama级模型。

• Groq是推理硬件平台，并非固定参数规模的单一基础模型。

• Groq的价值在于高Token吞吐量及低延迟，可缩短智能体循环中的重复模型调用时间。

d) 智能体未来会如何降低任务时延？

• 当前一项20至30分钟的Muse任务中：

1. 模型及GPU推理耗时约2至5分钟。

1. 浏览器、代码、文档及CPU执行耗时约5至10分钟。

1. 其余时间用于网络延迟、页面加载、API调用及顺序依赖。

• 未来系统将通过并行化降低时延：

1. 不再顺序检查20家供应商。

1. 由规划器同时启动10至20个子智能体。

1. 每个子智能体在独立浏览器及工具环境中运行小模型。

• CPU、GPU和工具使用环节整体都会加速，GPU等待时间也将下降。

13. NVIDIA平台对CPU采购及互连方案的影响

a) NVIDIA GPU是否会影响CPU采购选择？

• 会影响，但耦合程度取决于部署形态：

1. 定制PCIe GPU服务器：CPU选择自由度较高，可采用AMD EPYC或Intel Xeon。

1. HGX服务器：传统8 GPU服务器通常搭配2颗x86服务器CPU，因此NVIDIA GPU采购会带动第三方CPU需求。

1. 集成式机架级平台：CPU选择自由度降低，NVIDIA Grace成为整体架构的一部分。

• NVIDIA正进一步通过Grace控制CPU、内存、互连及加速器整体架构。

• 在集成系统中，客户不再独立购买GPU后选择CPU，而是采购完整平台。

b) 智能体场景应选择PCIe还是NVLink？

• 如果用于大模型训练或推理中的GPU间通信，应优先选择NVLink或NVSwitch。

• 如果是CPU向GPU提供推理工作负载，可采用PCIe或集成式一致性互连。

• 浏览器执行和代码沙箱可以使用纯CPU资源池，无需NVLink。

• RAG及向量检索主要依赖CPU、DRAM和SSD，并可通过网络访问远端GPU。

• 智能体架构在网络层面趋于解耦，CPU和GPU可以独立扩展。

• NVLink的核心优势主要体现在GPU与GPU之间，并非所有CPU都需要与GPU建立超高速连接。

c) 各类互连架构的市场份额如何变化？

• PCIe在整体智能体架构中仍占较高份额，原因是CPU执行、NVMe、NIC、浏览器、沙箱及检索基础设施均不依赖NVLink。

• 若仅统计NVIDIA智能体推理集群内部GPU到GPU的高带宽流量，NVLink/NVSwitch占比预计可达70%至90%。

14. Meta资本开支与数据中心电力规划

a) Meta 2027年资本开支规模及结构如何？

• 2027年资本开支约为1,820亿美元，专家此前给出的区间为1,800亿至1,900亿美元。

• 主要构成为：

• CPU芯片约占总资本开支的6%。

• CPU约占计算服务器硬件采购额的10%。

b) Meta 2026年资本开支是多少？

• 2026年资本开支指引约为1,400亿美元。

• 2027年预计增至约1,820亿美元，同比增长约30%。

c) Meta数据中心电力容量如何规划？

• 资本开支与实际通电容量之间存在时间差，建筑、电力接入、冷却和设备部署均会影响最终上线节奏。

结构化总结表格

新版prompt提炼之后的转译

分析师：在开始之前，请问您是否直接参与了Meta的Muse智能体项目？

专家：是的。我是FAIR Labs，即基础人工智能研究实验室的首席研究工程师，也是开发部分Muse产品线的50名工程师之一，参与了开源和闭源版本的开发。

分析师：据我了解，Muse项目主要涉及基础设施建设，包括CPU、GPU和内存，对吗？

专家：是的，正确。

分析师：我的第1个问题是，针对智能体工作负载，您会如何选择不同类型的CPU？有人认为，与聊天机器人相比，智能体对GPU性能的要求更高，包括更多核心和更高带宽等。您是否认同这一观点？

专家：Muse对CPU SKU的选择取决于具体工作负载。浏览器、沙箱和代码执行更适合较高的核心密度，即每个插槽配置64至128个物理核心，因为每台主机可以运行50至200个相互隔离的智能体环境，而且大部分工作负载都具有很高的并行度。

文档解析和预处理更重视内存带宽及内存容量，因此每个节点需要8至12个DDR5通道，以及512 GB至1.5 TB的内存。这些处理流程可能在算术吞吐能力耗尽之前就受到带宽限制。

对于较重的智能体编排工作，需要在核心数量和较强的单线程性能之间取得平衡。Python运行时、调度器、序列化和RPC处理都可能对延迟较为敏感，即使总体CPU利用率只有50%至70%。

对于CPU到GPU的服务节点，应优先考虑PCIe带宽、NUMA拓扑和网络I/O，而不是单纯追求核心数量最大化。具体配置可以是2颗具有64至96个核心的CPU，为8个加速器提供支持，并配备每秒400至800 GB的网络带宽。

分析师：这是否意味着需要采购高端CPU，而不是普通的服务器CPU？

专家：我不认同这种说法，因为高端CPU与服务器CPU并不是相互对立的概念。对于Muse，仍然会采购服务器级CPU，但会进行选择。

专家：只有在工作负载能够证明其必要性时，才会采用高端服务器SKU。例如，浏览器沙箱执行需要高核心密度的服务器SKU，每个插槽配置96至128个核心。解析和ETL可以采用价格更高的SKU，因为其能够提供更高的DDR5内存带宽、更多内存通道、更大缓存以及更好的IO性能。负载较轻的层级或编排层则会采用价格较低的32至64核心SKU，因为购买最高档配置会造成成本浪费。

因此，需要判断高端SKU能否减少每项任务消耗的CPU时间，或充分提高安全并发能力，以抵消高出20%至50%的服务器成本。如果一颗15,000美元的CPU相比一颗8,000美元的CPU，只能多完成5%的智能体任务，就不会进行大规模部署。如果内存带宽密集型的Muse工作负载能够获得30%至40%的吞吐量提升，那么采用高端服务器CPU在经济上会更加合理。

分析师：总的来说，当工作负载增加时，购买高端CPU实际上能够节省成本，对吗？

专家：在某些情况下是正确的。我们的目标是提高工作负载密度，而不只是增加工作负载。高端服务器CPU每个插槽的成本要高出30%至60%，但能够提供高出50%至100%的有效吞吐量。因此，这一结论只在部分情况下成立。

分析师：在哪些场景下，高端服务器CPU是必需的？

专家：当价格较低的SKU形成难以通过增加普通服务器来经济解决的硬性瓶颈时，高端服务器CPU就是必需的。这通常出现在高并发场景，以及同时具有大内存和高IO需求、对延迟敏感的智能体执行场景中。

例如，单台主机同时运行100至200个浏览器沙箱工作进程，并执行文档解析、Python执行、加密、压缩和RPC流量处理。如果这些任务需要96至128个核心、每秒500 GB以上的聚合内存带宽、512 GB至1 TB内存，以及满足网络带宽需求的高PCIe能力，那么较低档的32至48核心CPU即使理论上可以通过增加机器数量来扩展，也会触及CPU饱和或内存带宽上限。

另一个重要场景是为高成本GPU提供支持。如果一台8 GPU服务器配备价值200,000美元至400,000美元的加速器，为节省5,000美元至10,000美元而降低CPU配置，却导致CPU预处理、词元化、网络或编排环节使GPU容量出现5%至10%的闲置，这并不合理。因此，高端CPU本质上是一种保障，可避免浪费成本高得多的加速器容量。当CPU性能处于S的关键路径上时，高端CPU就是必需的。

专家：关键考量包括SLA、GPU利用率、机架密度以及每项已完成任务的总成本。仅凭工作负载规模较大，并不足以证明必须采用高端CPU。

分析师：您能否举一个必须使用高端CPU的具体例子？我理解您刚才提到的理论，即需要提高包括GPU在内的整个系统的运行效率，因此需要高端CPU与之协同。但具体适用于哪些场景？

专家：以文档密集型智能体为例。一个智能体需要接收1份300页的PDF文件以及50个附件，并同时执行PDF解码、OCR准备、HTML转换、分块、嵌入准备和压缩。如果需要并发处理50至100个此类任务，高内存带宽和96个以上核心的重要性可能远高于CPU的标称时钟频率。

另一个例子是，每台机器运行100至250个相互隔离的Python、JavaScript或容器沙箱。这种场景可能需要较多的核心数量、缓存和内存容量。如果每个活跃执行任务平均占用0.5个核心，但峰值占用达到2至4个核心，那么32核心的通用配置将难以在高并发条件下高效运行。

分析师：如果预测未来智能体场景中高端CPU占CPU总量的比例，您预计这一比例将从多少提升至多少？您可以针对所有智能体应用场景进行估算。

专家：如果高端CPU是指具备高内存带宽的AMD EPYC、Intel Xeon级别CPU，那么在浏览器和计算机操作智能体场景中，高端CPU目前的占比约为52%，到2028年至2030年将达到约73%。

在代码执行和沙箱场景中，目前的占比为58%，3年后将达到约77%。在文档解析和多模态处理场景中，目前的占比约为41%，2至3年后将达到约64%。在ETL和数据转换场景中，目前的占比约为33%，未来将达到46%。在检索和内存基础设施场景中，目前的占比为37%，未来将达到53%。在智能体编排和调度场景中，目前的占比为22%，未来将达到33%。

加权后的整体占比目前为42%，未来将达到63%，并不是说智能体CPU的采用比例会达到100%。

回　答　者：PU将成为高端产品，这并非预测。我们观察到的比例在60%至65%之间。

提问者：您提到高端CPU时，它与常规服务器CPU相比贵多少？您之前提到贵30至16，随后又提到贵30至60。这个数字可靠吗？我想了解单颗CPU的平均售价，即常规CPU与高端CPU的ASP分别是多少？

回　答　者：常规服务器CPU面向超大规模客户的单颗ASP在4,000美元至5,000美元之间，通常配置32至64个核心，主要用于主流服务器集群。

高端服务器CPU的单颗ASP在9.5,000美元至11.5,000美元之间，通常配置96至192个核心，并具有更高的带宽和缓存，成本约为常规服务器CPU的2.5至3倍。

最高规格及专用CPU的单颗ASP在14,000美元至16,000美元之间，具备最高密度和最大带宽，主要承载加速器主机工作负载。

在估算中，我们通常将常规CPU的单颗ASP设为5,000美元，将高端CPU的单颗ASP设为10,000美元，因此高端CPU的单颗ASP约为常规CPU的2倍。

提问者：在上述价格下，每颗CPU配置多少个核心？常见CPU可能配置8个、16个或32个核心，因此我想确认您所提供的ASP分别对应多少个核心。

回　答　者：常规服务器CPU的单颗ASP为4,000美元，配置32至48个核心，每核心ASP约为100美元。

常规高端CPU的单颗ASP为6,000美元，配置48至64个核心，每核心ASP为100美元。

高端CPU的单颗ASP约为9.5,000美元，配置96至128个核心，每核心ASP约为90美元。

高端高核心数产品的单颗GPU ASP在12,000美元至13,000美元之间，配置128至192个核心，每核心ASP约为83美元。

专用最高规格产品的单颗ASP为16,000美元及以上，配置128至192个以上核心，每核心ASP约为100美元以上。

提问者：下一个问题是，在运行Agile工作负载时，PC CPU或消费级……

分析师：CPU也适用于这类任务吗？我认为可能不适用。您刚才提到，未来高端CPU的占比将提高约20%，因此未来PC CPU的市场空间在大多数情况下可能会缩小，对吗？

专家：是的。消费级PC和CPU通常不是生产规模智能体工作负载的经济选择。桌面CPU通常配备8至24个核心和64至192 GB内存，完全能够运行浏览器智能体、Python沙箱、文档解析器，甚至本地编码智能体。但当每分钟需要执行数百个并发智能体任务、每天需要处理数百万项任务时，就会出现问题。服务器CPU每个插槽可提供64至192个以上的核心，并具备更大的内存容量、ECC和RAS功能、更多内存通道及PCIe资源。

分析师：您提到了浏览器、本地编码和PDF处理。如果客户使用智能体进行对话，例如与电商供应商沟通并要求降低价格，PC或消费级CPU能否支持这一场景？

专家：如果我正确理解了您的问题，答案是完全可以。

分析师：对于服务器CPU而言，更具经济性的适用场景主要是运行应用程序等负载较重的智能体任务，对吗？而在面向客户的场景中，例如打开浏览器、处理PDF、进行智能体通话等，PC CPU同样可以支持。

专家：是的，正确。

分析师：但在消费级智能体场景中，您提到PC CPU并非经济的选择。对于通话或浏览器操作等非常基础的智能体功能，PC CPU是否可以成为经济的选择？

专家：这里需要作出一个重要区分。我所说的“不经济”，指的是超大规模生产集群。如果智能体执行API和工具调用、供应商通话、VoIP编排、1至2个浏览器会话、电子邮件和网页抓取，以及轻量级文档解析，实际只会占用1至2个CPU核心。由于大部分时间都在等待网络、网站、人工响应或远程LLM推理，因此1颗8至16核的消费级CPU可以轻松处理多个此类智能体。

一旦开始运营拥有100,000个并发智能体的云端智能体服务，经济性就会逆转。此时需要每个插槽具备64至192个核心、数百GB的ECC内存、高内存带宽以及高密度配置。

提问者：总的来说，PC CPU 可以支持这类基础智能体功能，但在用户数量较多时并不经济，对吗？

回答者：对。

提问者：在为 MUSE 或类似智能体部署 CPU 时，您对 x86 和 ARM 这2种方案有偏好吗？

回答者：我们的 CPU 容量实际上有所拆分，其中约 71% 为 x86，29% 为 ARM。

对于浏览器自动化、任意客户代码、容器、沙箱及遗留二进制文件，x86 更具优势，因为兼容性至关重要。如果企业拥有软件栈，并且能够在 ARM 上验证所有内容，那么 ARM 更适合编排、API、工具调用、ETL、检索及无状态微服务等可控服务。

当我们运行包含原生扩展的任意 Python 软件包、Chromium 扩展和第三方二进制文件时，即使 ARM 的单位吞吐量成本低 20%，我们仍会选择 x86，因为兼容性故障的代价非常高。

我们有一项标准化编排服务，每天处理 100 亿次 RPC，ARM 的每瓦性能提升 25%，因此我会积极将这类工作负载迁移至 ARM。长期来看，我认为占比将达到 55% x86 和 45% ARM，但在开放式计算机操作和代码执行层面，x86 仍将保持很强的黏性。

提问者：为什么 x86 未来仍会占据更主导的地位？

回答者：x86 具备多项优势，但核心在于兼容性和生态系统，而不是它在 AI 方面更出色。

智能体工作负载需要执行其他人的软件。如果浏览器、计算机操作智能体或编程智能体突然需要使用 Chromium、带有原生扩展的 Python 软件包、Node 模块、Java、数据库客户端或专有二进制文件，x86-64 拥有数十年积累和测试的软件生态。对于 ARM，控制栈中 90% 至 95% 的部分可以正常运行，但当企业需要处理数百万项异构智能体任务时，剩余 5% 至 10% 的兼容性问题会带来很大困难。

另一个因素是现有基础设施。大型数据中心已经拥有规模庞大的 x86 设备集群，以及相关运维工具、优化后的容器镜像、安全与沙箱技术栈和熟悉这些系统的工程师。将服务迁移至 ARM，需要实现足够显著的总体拥有成本改善，可能要达到 15% 至 30%，才能证明验证和迁移工作的合理性。

第3个因素是高端服务器选择和工作负载灵活性，例如 AMD EPYC 和 Intel Xeon。

回答者：每个插槽可提供约数十个至100多个核心，并具备大内存容量、丰富的PCIe连接能力和成熟的虚拟化能力。Arm服务器CPU在这些方面表现出色，但X86能够为运营商提供非常广泛且成熟的供应商软件生态系统。

对于Muse，我们会将大语言模型推理任务交由GPU加速器处理。如果运行的是已知且标准化的类CPU服务，Arm更具吸引力；如果涉及浏览器、任意代码和第三方软件，X86则更具吸引力。因此，智能体越趋于通用化和自主化，向后兼容性就越有价值。Arm的机会在于平台能够控制整个软件环境，并针对该环境进行专门优化。

提问者：业内普遍在讨论GPU与CPU的配比，可能会从1个GPU搭配1个CPU，发展到未来1个GPU搭配4个CPU。正如您刚才提到的，即使只能减少5%至10%的GPU空闲时间，采购高端CPU也是值得的。目前，Muse智能体的GPU与CPU配比大致是多少？未来几年这一配比会如何变化？

回答者：需要确认一下，您问的是GPU与CPU的配比，不涉及TPU，对吗？

提问者：是的，不涉及TPU。

回答者：这里需要注意计量单位。Meta正在开发的新型MTIA 300系统采用1:1的CPU与加速器配比，部分原因是为了支持CPU卸载。Meta还认为，未来的推理和智能体推理将产生规模更小、频率更高且对延迟更敏感的通信模式。Meta披露的整体基础设施信息也强调，AI工作负载具有异构性，并且越来越多地包含推理和测试时推理。

对于传统的大语言模型服务，每个GPU配备0.5至1倍的物理CPU，以及48至96个CPU核心。在这种情况下，GPU占主导地位。

对于目前的智能体工作负载，每个GPU配备1至2倍的物理CPU，以及96至200个CPU核心，主要用于工具调用、浏览器操作、检索和解析。

对于未来约1至2年的高级智能体，每个GPU将配备2至3倍的物理CPU，以及200至400个CPU核心。

回　答　者：这适用于计算机使用、代码和多模态工作流。此后是3年、3年以后，即2039年及以后，每个GPU将对应3至4个物理CPU，以及350至600+个CPU核心，并具备持久化执行环境。

提问者：关于智能体AI带来的CPU需求，能否提供更多量化参考，例如刚才Harry提到的CPU与GPU比例、每项任务的CPU用量或每个智能体的调用量等，以帮助我预测未来CPU需求的增长？您能否提供更多数据？

回　答　者：预测智能体AI带来的CPU需求，主要关注完成每项任务所需的CPU秒数、每个并发智能体占用的活跃核心数，以及每个GPU对应的CPU等效需求。下面我会根据仪表盘数据，说明不同工作负载下每个智能体占用的活跃CPU核心数、典型操作所需的CPU秒数，以及每台主机的典型并发量。

对于API和工具编排，每个智能体占用0.05至0.2个活跃CPU核心，消耗0.1至1个CPU秒，每台主机的典型并发量为500至2,000。

第2类工作负载是语音通话智能体，不包括模型推理。每个智能体占用0.1至0.4个活跃CPU核心。关于对话时长，原表述为每分钟50，随后更正为每次对话5至30分钟，典型并发量为200至800。

对于检索和记忆查询，每个智能体占用0.1至0.5个活跃CPU核心，消耗0.2至2个CPU秒，典型并发量为300至1,000。

对于基础浏览器智能体，每个智能体占用0.5至1.5个活跃CPU核心，消耗5至30个CPU秒，典型并发量为75至200。

对于重度Chromium工作负载，每个智能体占用1至3个活跃CPU核心，消耗20至120个CPU秒，每台主机的典型并发量为40至120。

对于Python和JS沙箱，每个智能体占用0.5至2个活跃CPU核心，消耗2至60个CPU秒，每台主机的典型并发量为50至200。

对于复杂代码智能体，最初表述为每个智能体占用1至2个活跃CPU核心，随后更正为1至4个；其消耗30至300个CPU秒，典型并发量为25至100。

对于PDF和文档解析，每个智能体占用0.5至2个活跃CPU核心，每份文档消耗5至60个CPU秒，典型并发量为50至150。

对于重度多模态文档工作流，每个智能体占用2至6个活跃CPU核心，消耗30至300个CPU秒，典型并发量为20至75。

对于ETL数据转换工作负载，每个智能体占用0.5至4个活跃CPU核心，消耗10至300个CPU秒，每台主机的典型并发量为30至150。

提问者：您是否看到重度、更重或复杂任务的占比……

分析师：不同任务的CPU秒消耗取决于其复杂程度。未来，复杂任务的占比是否会进一步提高？

专家：如果我理解正确，答案是肯定的。这也是我预测智能体相关CPU需求增速将高于智能体请求量增速的主要原因之一。工作负载结构正在转向更加复杂的多步骤任务。

在智能体任务中，简单API调用、查询和消息处理类任务在2026年的任务占比为55%，到2030年将降至30%，每项任务消耗2至20 CPU秒。浏览器操作、工具调用和检索等中等复杂度智能体任务目前占比为30%，约3至4年后将达到38%，每项任务消耗30至150 CPU秒。长周期自主任务目前占比为3%，3年后将达到7%，4年后将达到12%，每项任务消耗500至2,000+ CPU秒。

建模时，我会同时考虑任务量增长和复杂任务占比变化。即使智能体请求总量每年仅增长30%，工作负载结构向更复杂任务转移，也会推动CPU需求以高于30%的速度增长。

分析师：您所说的高于30%，是指整个CPU市场的总体增速吗？

专家：不是。这里指的是智能体工作负载所消耗的CPU算力，而不是整个CPU市场。智能体只是服务器CPU需求的一部分，同时新一代CPU能够在每个插槽中提供更多核心和更高性能。因此，智能体CPU算力需求增长50%，并不意味着物理CPU数量也需要增长50%。

分析师：您能否给出未来整个CPU市场的总体增长数据？您已经提供了很多数据点，那么对于整个市场的CPU增长，合理的年增长率是多少？

专家：对于全球CPU整体市场，我们采用约10%的年收入增长率作为基准情景，预计这一趋势将大致持续至2030年，对应约10%的复合年增长率。关键在于各个细分市场。

回答者：各细分市场的增长明显分化。2026年至2030年，消费级PC CPU的年增长率假设为2%至5%，传统企业服务器CPU的增长率为7%，云端超大规模服务器CPU约为12%，高端高核心数服务器CPU约为20%，支持AI智能体的CPU容量增长率约为25%至45%，智能体专用CPU容量增长率为45%。CPU市场总收入将同比增长10%，即CPU市场收入的复合年增长率为10%。

CPU市场收入增速高于出货量增速主要有以下原因。首先，智能体提高了CPU使用强度。我们在实验室中建立了模型：简单的聊天机器人RAG请求需要每秒2至10个CPU计算量，复杂的研究和编码任务则需要每秒150至600个CPU计算量，长周期智能体的需求可能超过每秒500至2,000个CPU计算量。

其次，产品组合正在向高端迁移。高端服务器CPU的ESPV为11,000美元，而主流服务器CPU为5,000美元。随着市场转向96至192核心的高端处理器，即使插槽数量没有相应增长，CPU收入也会提高。

再次，AI基础设施本身需要更多CPU。根据模型，传统推理中每个GPU约需要0.5至1个CPU等效计算量，当前智能体需要1至2个，未来执行密集型智能体可能需要2至4个CPU等效计算量。

与此同时，性能提升会形成一定抵消作用。如果每个插槽的CPU性能每年提升20%，所需CPU计算量增加40%并不意味着处理器数量也会增加40%。总体而言，CPU计算需求每年增长约20%，实体CPU插槽需求每年增长6%，ESPV产品组合增长4%。

分析师：目前供应链是否存在 CPU 短缺？是否已经出现无法采购到足够 CPU 的情况？

专家：是的，服务器 CPU 确实存在供应限制。英特尔和 AMD 已向客户提示服务器 CPU 短缺，其中 AMD 的交付周期约为8至10周，英特尔在受影响市场的交付延迟达到6个月。TrendForce 报告称，CPU 及其他服务器组件的交付周期正在显著延长，部分组件的交付周期已接近1年。

此外，AMD 的 Lisa Su 在2026年Q2表示，由于需求预测不足，服务器 CPU 供应链非常紧张。AMD 预计供应状况将在明年改善，并已开始扩大下一代 EPYC 的产量，其代号为 Venice，采用 TCMC 2纳米制程。

分析师：不确定我是否听得准确，您刚才是说英特尔的交付周期为6个月吗？

专家：是的。目前主流服务器 CPU 的交付周期为2至4个月，高端服务器 CPU 为6个月，专用或最新款 CPU 约为9个月或更长。AI GPU 和加速器则由合同和配额决定，没有明确的交付周期。

分析师：从新闻来看，各类 CPU 的 ASP 调整幅度约为10。考虑到高端 CPU 的交付周期如此之长，您是否预计其 ASP 在不久的将来会再次上涨？

专家：是的。未来4年，主流服务器 CPU 的 ASP 预计将从5,000美元上升至约6,000美元；高端服务器 CPU 的 ASP 预计将从今年的10,000美元上升至2030年的14,000美元；顶级及专用 CPU 的 ASP 预计将从目前的15,000美元上升至4年后的21,000美元。目前，高端服务器 CPU 与主流服务器 CPU 的 ASP 比值为2X，未来将达到2.25X。

分析师：这主要是由供应短缺导致的吗？您能否估算目前供应低于需求的比例？

回答者：10%、20%。基准情景下，供应缺口约为12%、12%、13%；对于供应最紧张的高核心数SKU，供应缺口为17%。

提问者：考虑到Muse拥有如此强劲的用户增长，这一数字明年是否会进一步上升？

回答者：如果您指的是供应缺口，答案是肯定的。当前模型预测的供应缺口约为12%、13%，明年约为15%，2028年约为17%，2029年约为11.5%，2030年约为6.5%。

真正的风险期是2027年至2028年。在此期间，智能体基础设施将通过增加浏览器和代码执行任务、提高每个加速器对应的CPU容量，以及向高端96至192核心产品迁移，同时推升CPU需求。供应端的响应则需要更长时间，因为晶圆代工产能、先进封装、内存、基板及完整服务器认证均存在交付周期。

提问者：我想了解一下SSD。您对CPU显然非常乐观，而CPU也需要大量高带宽DRAM。正如您提到的，TrendForce也表示，企业级SSD的供应突然比以前紧张了许多。这是否与Muse等智能体有关，还是由其他新出现的需求驱动？

回答者：企业级SSD供应趋紧与此相关。我们看到，同一轮广泛的AI基础设施周期正从GPU扩展至高端CPU、高带宽DRAM和企业级SSD，但不同组件的驱动机制有所不同。

对于CPU和DRAM，智能体工作负载会直接提高对计算、内存容量及带宽的需求，因为浏览器执行、沙箱、检索和长上下文处理都会显著增加CPU和内存负载。企业级SSD需求受到的影响则更为间接。AI集群正在扩展检查点存储、模型与嵌入存储、向量数据库、训练数据集、KV缓存卸载、智能体内存及高吞吐量暂存层。

目前，传统AI基础设施扩张约占AI相关企业级SSD增量需求的60%至70%，智能体工作负载占15%至25%。随着持久化内存和检索的发展，到2029年，智能体的贡献将上升至30%至40%。

回答者：随着用户数量和计算机使用工作负载持续扩大，在容量规划方面，我们预计GPU和H HPM的需求每年增长32%，高端服务器CPU每年增长20%，高带宽服务器DRAM每年增长55%，企业级SSD容量每年增长24%，高性能及企业级NVMe每年增长30%，HDD和冷存储每年增长约9%。

提问者：在智能体执行任务期间，需要使用SSD存储检查点、RAG和向量数据库。实际应用中，如果某项任务最终消耗10 billion个token，通常需要多少SSD容量？或者，在Muse上运行一项典型的20至30分钟任务，需要多少SSD容量？

回答者：需要区分处理10 billion个token和存储10 billion个token。一个运行20至30分钟的Muse智能体会通过重复推理、检索和工具调用处理大量token，但不会将接近10 billion个token的数据永久写入SSD。

对于处理10 billion个token的工作流，每个并发智能体需要10至30 GB的本地NVMe工作容量，任务完成后需要保留1至5 GB。这里假设10 billion是模型调用过程中累计处理的token数量，而不是实际写入磁盘的10 billion个不重复token。

还可以进行一项合理性检验：原始文本所占空间其实很小。10 billion个token乘以每个token约4字节，相当于40 GB的原始文本内容。即使将每个token都存储1次，所需容量也是数十GB，而不是TB。不过，智能体执行期间可能会生成多种表示形式、截图、嵌入、索引、日志和临时文件，而压缩和去重则会减少容量需求。

此外，并不会为每个用户的智能体任务单独创建模型检查点。模型权重和检查点属于共享基础设施。特定任务产生的SSD负担主要包括RAG数据、浏览器和沙箱状态、产物、日志及缓存。

如果需要支持100,000个并发运行的重型智能体，按照每个智能体20 GB的工作集计算，在尚未计入复制、备用容量、数据库、共享RAG语料库、模型存储和系统开销之前，就已经需要2 PB的活动SSD容量。

提问者：对于这些智能体应用场景，您如何看待DRAM与SSD的需求，两者有何差异？

提问者：DRAM和NAND中，哪一个增长更快？

回　答　者：短期内，DRAM的需求增速快于NAND和SSD。服务器DRAM容量需求每年增长30%，高带宽高端服务器DRAM需求增长30%至35%。相比之下，NAND需求增长约23%，高性能企业级NVMe需求增长30%，通用型NAND需求增长15%。

其原因在于内存层级。智能体正在主动处理的任何内容都需要存储在DRAM中，之后可能需要使用的内容则可以存储在SSD中。以此前讨论的20至30分钟Muse任务为例，我会为每个并发智能体配置6 GB的增量活跃DRAM，以及10至30 GB的SSD工作容量。虽然每个智能体所需的SSD容量更大，但DRAM必须保持可即时寻址，带宽也至关重要。如果内存带宽不足，也无法高效运行128核CPU，因此这一问题在服务器层面会变得非常重要。

未来的高密度智能体执行节点将配备128至192个CPU核心、1至2 TB的DRAM，以及15至60 TB的企业级NVMe。目前，通用CPU节点可能仅配备256至512 GB的DRAM。因此，即使CPU核心数量持续增加，智能体基础设施也可能推动每个CPU插槽配置的DRAM容量提升2至4倍。

NAND具备另一项优势，即智能体会随着时间推移不断积累数据。持久化记忆、嵌入数据、用户文件、执行轨迹和RAG语料库不会在任务完成后消失。因此，即使NAND的短期增速较低，最终也可能拥有非常大的容量增长空间。

提问者：通过网站重构或工程优化等方法，可以节省多少CPU资源？

回　答　者：工程优化与网站重构略有不同。软件和工作负载工程优化可以使CPU需求相较于未经优化的实现降低35%，部分浏览器工作负载可节省60%，RAG和查询缓存则可节省17%。

网站重构非常重要。智能体需要从电商页面中获取产品名称、价格、库存和加入购物车状态。未经优化的计算机操作智能体会启动Chromium、下载10 MB数据、执行数百个JavaScript任务、完成页面布局和渲染、截取屏幕画面，之后再解读这些像素。基础设施也可以通过DOM和无障碍API数据重构轻量级语义表示，例如产品为鞋、价格为$129、库存状态为有货、尺码为e。

专家：等于9，操作等于点击“添加到购物车”。这样一来，每次浏览器交互所需的CPU时间可以从10至30 CPU秒降至3至10 CPU秒，意味着这部分工作负载可节省50%至70%的CPU资源，但这并不能消除CPU需求的增长。

到2039年，由于智能体的自主性增强，其执行的浏览器工具和代码操作将达到原来的3倍。因此，需求将变为2003，即每秒600 CPU。若进一步优化40%，则为600.6，即360 CPU秒。与目前未经优化的智能体相比，完成每项用户任务所需的CPU仍为其1.8倍。CPU需求预测就是这样得出的。

分析师：您刚才提到的短缺预测数据，已经考虑了优化或资源节省，对吗？

专家：是的，已经考虑了优化，包括有实际意义的软件和硬件优化。我们假设会采用浏览器网站重构、缓存、预热沙箱池、更合理的调度以及更高效的解析等技术。如果不进行这些改进，需求缺口约为30%。但这并不是现实的基准情景，因为超大规模云服务商会积极优化，不会任由CPU需求以如此低效的方式增长。

分析师：这非常有帮助。您能否说明智能体如何增加GPU使用量？与聊天机器人相比，智能体循环会使GPU使用量增加多少？

专家：聊天机器人在每轮用户交互中调用GPU 1次，而智能体会运行一个执行循环，在返回1项完整任务的结果前多次调用GPU。因此，即使底层模型保持不变，智能体也可能使GPU消耗成倍增加。

例如，如果要求聊天机器人“帮我寻找这款产品的最佳供应商”，聊天机器人会向GPU发送提示词并生成答案，GPU通常会忙碌2至5秒。而Muse会先向GPU发送提示词以制订计划，再由CPU和浏览器搜索供应商，由GPU解读结果；随后由CPU和浏览器打开供应商A的页面，由GPU判断哪些信息重要；再由CPU提取价格，由GPU比较报价。

这样，1个用户请求会产生8至15次独立的GPU推理，但GPU计算量并不会因此变为10倍，因为中间调用的规模要小得多。第1次规划可能需要4,000个Token，页面解读可能需要1,000个Token，工具决策可能为5，且仅需500个Token。如果聊天机器人完成1轮交互消耗1个GPU计算单位，那么1个包含10个步骤的智能体实际会消耗5至10个计算单位，而不是10个。

分析师：还有一个后续问题。考虑GPU需求时，实际上涉及2个方面，其中1个是Token数量，对吗？

分析师：Agent loop确实会大幅增加Token消耗。但我担心，Agent实际上可能并不需要非常大的模型，参数规模可以很小。Muse以及Grockbot等类似产品是否确实如此？具体而言，Muse和SpaceX类似产品Grockbot的参数规模如何？

专家：需要将GPU需求拆分为Token量和每个Token的计算量。Agent可以显著增加循环次数和执行步骤，同时通过模型路由，将执行循环中的大量任务交给较小的模型，从而降低每个Token的平均计算量。

例如，一项Agent任务消耗的Token数量可能是聊天机器人任务的10倍，但每个Token的平均计算量会降低2至5倍，因为其中60%至80%的Token不需要使用最大的模型。因此，每项已完成任务的GPU计算量仍会增加约2至5倍，而不是10倍。

具体到Meta Muse，我们没有公布其参数量，也不会将Muse描述为拥有X十亿参数。我们采用的是通过路由器调度的模型组合，而不是在每次浏览器观察和工具决策中反复调用最大的Llama级模型。

Grock则是一个推理硬件平台，而不是具有固定参数规模的单一基础模型。它可以支持不同模型，因此不存在一个有意义的、统一的Grock参数量。它与Agent的相关性在于，极高的Token吞吐量和较低的延迟，可以显著缩短Agent循环中重复调用模型所需的实际时间。

因此，Agent的GPU需求等于Agent的Token总量乘以每个Token的计算量，再除以硬件吞吐量。Agent会显著增加每项任务的Token数量，模型路由会降低每个Token的计算量，而更快的推理硬件则会提高每个GPU每秒处理的Token数量。GPU需求的关键在于，第1项的增长速度是否快于后2项的改善速度。未来，我们预计第1项的增长速度会更快，但GPU需求的增幅将远低于Agent原始Token量的增幅。

分析师：您提到目前Agent的运行速度较慢。未来这种情况会发生怎样的变化？Agent loop中的第1部分是否会比其余部分增长得更慢？

专家：Agent的延迟将显著下降，下降速度可能快于普通聊天机器人，因为目前的缓慢并非不可避免。对于一项耗时20至30分钟的Muse任务，实际用于模型和GPU推理的时间为2至5分钟，浏览器、代码、文档和CPU执行需要5至10分钟，其余时间则消耗在网络延迟、网站加载、API调用和顺序依赖上。

未来的系统会并行处理这些任务。例如，系统不会再按顺序检查20家供应商，而是由规划器同时启动10至20个子Agent。

回　答　者：每个实例都在各自的浏览器和工具环境中运行一个小模型。模型路由机制是指，由30亿至300亿参数的模型处理常规观察和工具决策，仅在需要进行复杂规划或综合分析时调用更大的模型。总体而言，未来整个系统，包括工具使用环节，都会运行得更快，因此GPU的等待时间也会缩短。

提　问　者：如果大部分GPU工作负载都基于英伟达平台，这是否会影响CPU采购选择？例如，相较于英伟达GPU与Graviton的组合，您是否会更倾向于选择英伟达CPU与英伟达GPU的组合？完整的系统方案是否会成为CPU选型中的加分项？

回　答　者：这确实会影响CPU采购，但具体耦合程度取决于采购的是GPU、完整的英伟达系统，还是机架级架构，主要分为3个层面。

如果在定制服务器中部署PCIe GPU，CPU的选择自由度较高，可以选择AMD EPYC或Intel Xeon。如果部署英伟达集成式机架级平台，CPU的选择自由度会降低，英伟达Grace会成为整体架构的一部分。

如果采用配备8CP、8块GPU的HGX服务器，则可以使用经过验证的X86主机平台。过去，配备8块H100或H200的HGX服务器通常搭配2颗服务器CPU，一般为AMD EPYC或Intel Xeon。因此，采购英伟达GPU也会带动对第三方服务器CPU的需求。

目前，英伟达正进一步转向Grace，使其能够更全面地控制CPU和GPU架构。在这类系统中，用户不再是独立采购8块英伟达GPU后再选择AMD CPU，而是将CPU、内存、互连和加速器作为一个完整系统进行采购。

提　问　者：您提到，采购选择取决于GPU与CPU的连接方式。在选择连接方案时，您会更倾向于PCIe还是NVLink？PCIe的通信速度相对较慢。

回　答　者：具体选择取决于工作负载对CPU与GPU通信的需求。如果是用于大语言模型推理或训练的GPU间通信，首选NVLink或NVSwitch，因为其带宽很高、延迟很低。

如果是由CPU向GPU提供推理工作负载，则首选PCIe或集成式一致性互连，具体取决于平台。如果工作负载是浏览器执行，则可使用纯CPU资源池，没有必要采用NVLink。代码沙箱也是纯CPU工具，因为GPU通常位于远端。如果是RAG或向量检索，则主要使用CPU、DRAM和SSD，因为可以在需要时通过网络访问GPU。

专家：最终，智能体编排在网络层面是解耦的，因为 GPU 和 CPU 可以独立扩展。关键区别在于，NVLink 的显著优势体现在 GPU 与 GPU 之间，并非每个 CPU 都需要与每个 GPU 建立超高速连接。

分析师：例如在智能体场景中，NVLink 在连接市场中能够占据多大份额？NVLink 与 PCIe 的市场份额分别是多少？

专家：NVLink 运行在高密度 NVIDIA 加速系统内部，而 PCIe 是覆盖范围更广的 CPU 到设备互连架构。目前，PCIe 的份额为 55%，到 2030 年将为 45%；NVLink 和 NVSwitch 目前为 30%，到 2030 年将为 35%；以太网网络架构目前为 12%，4 年后将达到 17%；CXL 及其他一致性互连架构目前低于 5%，到 2030 年将达到 7%。

总体来看，PCIe、NVLink、以太网和 CXL 的份额分别为 55%、30%、12%和 3%。但如果将统计范围限定为 NV 智能体推理集群内部的 GPU 到 GPU 流量，情况则会相反。根据我们的模型，在 NVIDIA 部署占比较高的环境中，最终将有 70%至90% 的高带宽节点内和机架内加速器流量通过 NVLink 和 NVSwitch 传输。

PCIe 在整体智能体架构中占比较高，原因在于智能体涉及大量 CPU 执行、NVMe、NIC、浏览器、沙箱和检索基础设施，而这些组件并不需要 NVLink。

分析师：非常清楚。最后一个问题，您是否了解 Meta 明年的 GPU 和 CPU 资本开支计划？不确定您是否可以获取相关数据。

专家：我可以获取相关数据。Meta 2027 年的资本开支总额约为 180 billion至190 billion，具体分配如下：NVIDIA GPU 及系统为 52 billion，Meta MTIA 及其他加速器为 16 billion，服务器 CPU 为 10 billion，DRAM 和 HPM 为 16 billion，SSD 和存储为 8 billion，网络交换机和光学设备为 14 billion，建筑、电力、冷却及其他项目为 62 billion。

CPU 芯片约占资本开支总额的 6%，约占计算服务器硬件采购额的 10%。

分析师：明白了。总体而言，这些资本开支大约需要多少吉瓦的电力？

提问者：数据中心的电力容量情况如何？

回答者：目前，2026年资本开支指引为140 billion美元。去年获得资金支持的新增计算容量为3吉瓦，实际通电容量为2吉瓦。今年获得资金支持的容量为5吉瓦，实际通电容量接近4吉瓦。明年获得资金支持的容量为6吉瓦，计划实际通电容量为4.7吉瓦。到2028年，预计获得资金支持的容量为7吉瓦，实际通电容量为6吉瓦。

提问者：您刚才提到的资本开支数据是今年还是明年的？

回答者：我提到的140 billion美元是今年的资本开支。

提问者：您是否有明年的资本开支数据？

回答者：2027年的资本开支为182 billion美元。

原文转译

know a little bit more about the um, CPU used for agent. Yeah, thank you for that. Yes, thank you. Yeah. Um, like I send you some of the question list, um, before we get start, can we know, um, were you directly involved in Meta's agent of news project? uh, yes, um, I I'm a principal research engineer at uh, FAIR Labs, the fundamental AI research labs and we were one of the 50 engineers that developed some of the news lines or newsmer, uh, the the the open source one, the closed source one. Okay, got it. So, um, so your project at muse actually, as far as I know is uh actually it's from the infra, how to build up the infra including CPU, GPU, even memory, right? Yes. Correct. Okay, got you, got you. Okay. So, so, um, um my first question actually is about how would you choose different CPU type for agent works. I heard some people said that for agent, actually, um, agent versus Chatbot need higher GPU performance requirement, including more cores, uh higher bandwidth, etc. I'm not sure whether do you agree with this statement? Uh, so So let me just let me just try to uh uh your Okay, so the muse CPU SKUs, um, we the the the browser and sandbox and code execution, they favor higher core density. which is uh 64 to 128 physical cores and sockets because you could run 50 to 200 isolated agent environments per host and much of the workload is very, very parallel. Also, document parsing and preprocessing, they favor memory bandwidth and um, you know, being able to uh uh have memory capacity. So 8 to 12 DDR 5 channels and 512 GB to 1.5 TB RAM per node. And these pipelines can become bandwidth bound well before exhausting arithmetic throughput. And then you have the heavy agent orchestration. This balances cores with strong single thread performance, uh uh because Python runtimes and schedulers, uh you know, and serialization and RPC handling can leave you latency sensitive even when aggregate CPU utilization is only 50 to 70%. Uh and then you have the last thing is the CPU to GPU serving nodes. So you prioritize the PCIE bandwidth, the NUMA topology and the network IO rather than simply maximizing course. So two by 64 to 96 core CPUs feeding eight accelerators with 400 to 800 GB per second networking. Okay. Uh, so does that mean you need to buy the premium CPU rather than regular CPU server CPU? Uh, right. So to to get this premium level, you know, quality, um, I mean, I don't agree with with that because premium CPU and server CPU are not the opposite. For for muse, you you still buy server class CPUs, but you choose premium server SKUs only where the workload justifies it. So, when you see for example, a browser sandbox execution, um, that that has a high court density server SKU, 96 to 128 cores per socket. Parsing and ETL can justify a more expensive SKU because it provides higher DDR5 memory bandwidth, more memory channels, larger cache, and better IO. A lighter or orchestration tier uses a cheaper 32 to 64 core SKU because buying the the top bin would waste money. Um, so, does this premium SKU you know, replace the CPU seconds per task or increase the safe concurrency enough to offload a 20 to 50% higher server cost. So, if you have a $15,000 CPU that gives you 5% more completed agent tasks than a $8,000 CPU, you would not deploy it broadly. If a memory bandwidth heavy muse workload gets 30 to 40% more throughput, the premium server CPU makes more economic sense. Does that make sense? Yeah. Yeah. And uh so, okay. Uh so, so in conclusion that when you have more workload, more uh you need, you you buy premium CPU can actually save your save money for you. Um, so, that is more or less sometimes correct. Um, that we are going for higher workload density, not just more workload. Because the premium server CPU costs 30 to 60% more per socket, but delivers 50 to 100% more useful throughput. So, yes, but sometimes. Okay. So, in what like scenario like premium server CPU is a necessity? Right. Um, so, this is when you look at uh when the cheaper SKU creates a hard bottleneck that can't be economically solved by adding more ordinary servers. When we have high concurrency situations and latency sensitive agent execution with large memory and IO requirements at at the same time. You know, imagine one host running 100 to 200 concurrent browser, um sandbox workers and document parsing and Python ex execution and encryption and compression and RPC traffic. If that requires 96 to 128 cores, 500 plus GBs per second aggregate memory bandwidth, 512 GB to 1 terabyte RAM and high PCIE for network bandwidth, a lower tier 32 to 48 core CPU hits the CPU saturation or the memory bandwidth limits even though you could, you know, theoretically add more machines. Another important case is feeding expensive GPUs. If if you have an 8 GPU server that has $200,000 to $400,000 of accelerators, saving $5,000 to $10,000 on CPUs makes little sense if the CPU pre-processing, tokenization, networking or orchestration leaves even 5 to 10% of GPU capacity idle. So the premium CPUs are in are basically are insurance against wasting much more expensive accelerator capacity. So the premium CPU is necessary when CPU performance is on the critical path for S SLA, uh and GPU utilization and rock density or total cost per completed task. The high workload volume alone does not make it necessary. Okay. got it. Um, and can you give me like some example, um, like a specific example when the premium CPU is necessary? I know the theory you mentioned just now, you need make the whole system including GPU to work efficient, so you need a premium CPU to collaborate with it. But what specific example is there can can can could be the scenario? You mentioned Okay, I'll give you an example. Yeah, yeah. Thank you so much. Yes. Uh we have a document heavy agent. right? So, so you have an agent that receives a 300 page PDF plus 50 attachments and simultaneously performs PDF decoding, OCR preparation, HTML, you know, conversion, chunking, embedding, you know, preparation and compression. If you need 50 to 100 of those jobs concurrently, high memory bandwidth and 96 plus cores can become much more important than nominal CPU clock speed. Another example is, um when we have uh, you know, 100 to 250 isolated Python or JavaScript or container sandboxes per machine, that can require large core counts, cash, and memory capacity. If each active execution averages 0.5 core, but bursts to two to four cores, the 32 core commodity configuration becomes difficult to operate efficiently at high concurrency. So, um, yeah. Okay. That's it. Got it, got it. So, if you want to predict for the future agent, the premium CPU as a percentage of total CPU, what would you predict the percentage to increase from how much to how much in the future? Um in agent. You mean like the usage? in agent, in all the agent scenarios. And you can give me a a a guess, yeah. I see, I see. Okay. So, um, uh I mean, if by premium CPU, you you mean the the like the high memory bandwidth AMD, EPYC, Intel Xeon class, uh then then I would say that the browser and computer use agents premium CPU share today is around 52%. And in 2028 to 2030, it'll be around uh 73%. For the code execution and sandboxes, today, it's 58%, and then in in in three years, it'll it'll be about 77%. Document parsing and multimodal processing now is about 41%. Uh, in the in two three years it'll be about 64%. ETL and data transformation now is about 33%, in the future it'll be 46%. Uh retrieval and memory infrastructure is 37%. In the future it'll be uh 53%. Agent orchestration and scheduling is 22%. In the future it'll be 33%. Um and the weighted overall is 42% now and uh 63% in the future. Not not that 100% of agent CPU, PU becomes premium, that's not the prediction. Okay. We're, you know, we're looking at between 60 and 65%. Okay, okay. That's super, super helpful. Yeah. And also can know that there when you mention premium CPU, how much is more expensive compared with regular server CPU? You you earlier you mentioned 30 to 16. Uh, 30 to 60 more expensive. Is that number a reliable number I can refer to? So, I'll give you exact Yeah, I want to know the the the maybe the ASP per CPU, um regular CPU versus a premium CPU. What what's their what's the ASP for that? As far as you know. On average. Yes. So, Yeah, yes, yes. So, so, um, for the regular server CPU, the the hyper scalar ASP per CPU is uh between $4,000 and $5,000. Uh that it's it's it's typical positioning is 32 to 64 cores and it's the mainstream fleet. For the premium server CPU, we're looking at um, 9 .5,000 to 11.5,000. Uh so that's 96 to 192 cores, higher bandwidth per per cache. So, uh you know, we're talking two and a half to three times the the cost. Uh now, for the very top bin and specialized CPU tier, that is actually between $14,000 and $16,000. That's the maximum density. uh and that's the, you know, the maximum bandwidth and accelerator host workloads. Uh, we use, you know, for our estimations, we say $5,000 is a regular one and $10,000 is a premium one. So roughly two times ASP per CPU. Okay, that's helpful. And by the way, what what does it how many core per CPU under this rice uh under this price? So you really CPU have like eight core, 16 core, 32 core. I'm not sure what what this ASP you give to me how many core per CPU. Correct. So for the regular server, it's 4000 ASP per CPU and it and it has between 32 and 48 cores. And the ASP per core is is around $100. For the regular high-end, the ASP per CPU is 6,000, it has 48 to 64 cores, and it's cost uh sorry, it's ASP per core is $100. The premium, um, uh is around $9.5,000, and it has between 96 and 128 cores, and it's and it's about $90 ASP per core. The premium high high core class is uh between 12,000 and 13,000 ASP per GPU. It has 128 to 192 cores, and it's and it's ASP per core is about $83. And finally, the specialized top-in class is um, you know, $16,000 and higher. Uh and that's, you know, also 128 to 192 plus cores, uh and it's and it's ASP per core is about $100 uh plus. Okay, got it, got it. It's super helpful. Yeah, the next type of question is about the um when doing the Agile workload, can PC CPU or consumer CPU also works for it? I I think not, maybe because you already mentioned that the premium CPU actually will account like 20% more in the future. So I think the um the market for the PC CPU actually will be less in the future, right? In most case. So, uh Yeah, yeah. Go ahead. Yes, most this. Uh, the consumer PCs and CPUs are generally not the economic choice for production scale agent to workloads because a desktop CPU works with 8 to 24 cores and maybe, you know, 64 to 192 gigabyte RAM. It's it's perfectly capable of of running a browser agent, uh or or a Python sandbox or a document parser or even a local coding agent. But the problem happens when you need hundreds of concurrent agent executions per minute and millions of tasks per day. So the server CPU gives you 64 to 192 plus cores per per socket and much larger memory capacity and ECC and RAS features and more memory channels and PCIE. Um, so yeah. That's that's it. Okay, got it, got it. Um you mentioned about browser, uh local coding and PDF. How about like you call for your customer to like talk talk like like a like an agent like like talk with a e-commerce supplier to ask for a lower price, etc. Is that a um PC or consumer CPU can work for that scenario? Um Okay, so if I understand your question correctly, um then then absolutely yes. Okay. Um Yeah. Yeah. Got it. Got it. It's Yeah, so go ahead. Yeah. So, so so for the like the server CPU, the more economic of better scenario is more like a a very heavy agent task, like run a um APP, etc, right? So some like like to customer scenario, like open the browser, um PDF, agent calling, etc. That's actually PC CPU can works as well. Yes, correct. Okay. But in the eight like in the consumer agent scenario, you mentioned their um PC CPU is not an economic choice. That is that also for this very like basic agent function, like calling or browser, is that PC CPU can be an economic choice or not? Um, so there's an important distinction for basic agent functions, right? Um, uh uh, you know, when I said not economic, I was talking about the hyper scale production fleets. So if if you have an agent doing API and tool calls and supplier calling, uh voice over IP orchestration, and one to two browser sessions, email and web scraping, and lightweight document parsing, this this consumes only um, you know, one to two CPU cores actively. But an 8 to 16 core consumer CPU could handle several such agents without difficulty because much of the time they're waiting on the networks, websites, humans or the remote LLM inference. Once you operate a cloud agent service with 100,000 concurrent agents, the the the economics reverse. You want 64 to 192 cores per socket, hundreds of GB of ECC memory, high memory bandwidth, dense Yeah, go ahead. Yeah, yeah, yeah. I I think it's super helpful. So in conclusion, PCCPU can support this kind of basic agent function, but it won't be like economic when you have lots of user. Correct. Okay, got it, got it. Super helpful. Um, and also next question is about the x 86 versus on. Uh actually when you like deploy CPU for muse or such agent, do you have preference between this two kind of um choice? X62 versus arm. Yes, so um, the we okay, so so we have we have a split actually. It's it's about uh 71% X86 and 29% arm for CPU capacity. X86 is preferable for the browser automation and the arbitrary customer code and the containers and sandboxes and legacy binaries because compatibility is is a critical and arm is attractive for controlled services like orchestration, API, tool calling, ETL, retrieval and stateless microservices when you own the software stack and and can validate everything on arm. So, uh, when we launched, you know, arbitrary Python packages with native use, uh and chromium extensions and third-party binaries, we we chose X86, even if arm was, you know, 20% cheaper per unit of throughput because the compatibility failures are very expensive. Um, so we have a standardized orchestration service processing 10 billion RPCs per day and arm gives 25% better performance or, you know, per watt. So I would move that workload aggressively to to arm. Long long term, I think it's going to be 55% X86 and 45% arm, but X86 will be very sticky for the open-ended computer use and code execution layer. Okay. Um so what made their X86 more dominant in the future as well. Um, so X X86 actually has uh a number of advantages. Uh the the um it's a compatibility and ecosystem story, not that it's actually better at AI. The the the agent workloads that execute other people's software. Um if you have a browser or computer use or coding agent that might suddenly need chromium uh or you know, Python packages with native extensions, node modules, Java, database clients, you know, proprietary binaries. X86 64 has decades of software built and tested around it. When you look at arm, 90 to 95% of a control stack works, but the remaining 5 to 10% compatibility tail becomes painful when you're operating millions of heterogeneous agent tasks. The second thing is existing infrastructure. So the large data centers already have enormous X86 fleets, operational tooling and optimized container images and security and sandboxing stacks and engineers familiar with them. Moving a service to arm needs enough total cost of ownership improvement, maybe 15 to 30% to to to justify qualification and migration work. This the the third thing is the high-end server choice and the workload flexibility. So the AMD EPYC and the Intel Xeon provide configurations from roughly tens to over 100 cores per per socket. And you have the large memory footprints, extensive PCIe connectivity and mature virtualization. The arm server CPUs are excellent on these dimensions, but X86 gives operators a very broad, mature supplier software ecosystem. For for Muse, we we have an LLM inference leading to a GPU accelerator. If you have a known standardized CPU like service, then arm is more attractive. If you have browser and arbitrary code and third-party software, X86 is is attractive. So the more general purpose and autonomous agents it become, the more valuable backward compatibility can become. So arm's opportunity is where the platform controls the entire software environment and can optimize specifically for it. Okay, that's super helpful. Um Okay, my my colleague Harry also have follow-up question for it. Hi, um thank you so much for your time. Um, I think there's a lot of chatter in industry about, you know, sort of the ratio of GPU to CPU go going from, you know, uh one GPU to one CPU, um, to in the future maybe, you know, you need four CPUs per one GPU. Um, and I think you sort of alluded to it where, you know, even if you can save like 5% to 10% of a GPU sort of idle time, then the spend on, you know, premium CPUs become worth it. Um, I I'm just wondering, you know, right now, what's sort of your GPU to CPU ratio for uh for Muse agents in general and, you know, in a couple of years where where do you see that going? Thanks. Um, okay, so just to to clarify, you're you're asking about GPU to CPU ratio. There is no TPU in the sentence, correct? No, no TPU. Sorry if I spoke. Yeah. No, no. It's no, no, no, no, sorry, it's the voice uh, uh quality. So uh, so so the so so there's an important unit issue. It's the it's the um uh so so the new MTIA 300 system that meta is making, uses a one-to-one CPU to accelerator ratio, in part to support CPU offloading. And meta also um believes that future reasoning and agentic in inference creates smaller, more frequent latency sensitive communication patterns. Uh, and basically meta's broader infrastructure disclosures also emphasize that AI workloads are heterogeneous and more and more include reasoning and test time inference. So, um, for the traditional LLM serving, we have from 0.5 to 1 times physical CPUs per per GPU. And we have 48 to 96 CPU cores per GPU, and in that case the GPU, you know, dominates. For agent workloads today, uh, we have 1 to 2X physical CPUs per per GPU, and 96 to 200 CPU cores per GPU. So this is more tools, browser retrieval and parsing. We also have the advanced agents um in in about one to two years. That's going to be two to 3X physical CPUs per GPU and 200 to 400 CPU cores per GPU. Um, that that's for the computer use and code and multi-modal workflows. And then three three years and after, so, you know, 2039 and after that, it'll be three to 4x physical CPUs per GPU and 350 to 600 plus CPU cores per GPU. So there's persistent execution environments there. Got it. Yeah, super helpful. Thank you. Yeah. Thank you. And follow the question, also actually this question also on my question question list. Can you give me more quantitative reference point, uh like what Harry just mentioned about their CPU GPU ratio, um and also the CPU per task or the call per agent, etc, um to help me to project the growth of CPU in the future? Can you give me more data point? Um, sure. Um, so, uh, the so so for forecasting the CPU demand created by agentic AI, this is around CPU seconds per completed task and active cores per concurrent agent and CPU equivalent per per GPU. So, I'll give you a number of workloads and I'll tell you from from our dashboards, uh the active CPU course per agent, the CPU, uh second per typical operation and the typical, you know, concurrency host. Okay. For the API and tool orchestration, it's 0.05 to 0.2 active CPU course per agent, and 0.1 to 1 CPU seconds, and 500 to 2,000 typical concurrency per host. For the second workload, the voice calling agent, excluding the model inference, it's 0.1 to 0.4 active CPU course per agent. 50, 5 to 30 per minute, sorry, 5 to 30 uh uh minute conversations and 200 to 800 typical concurrency. Uh for the retrieval and memory like lookup, it's 0.1 to 0.5 active CPU cores per agent, 0.2 to 2 CPU seconds, and 300 to 1,000 typical concurrency. For the basic browser agent, it's 0.5 to 1.5 active CPU course, 5 to 30 CPU seconds and 75 to 200 typical, you know, concurrency. For the heavy Chromium, it's 1 to 3 active CPU course, 20 to 120 CPU seconds, and 40 to 120 typical concurrency per host. For the Python and JS sandbox, it's 0.5 to 2 active CPU course, 2 to 60 CPU seconds and 50 to 200 typical concurrency per host. For the complex code agent, it's 1 to two uh sorry, it's 1 to 4 active CPU course per agent, 30 to 300 CPU seconds and 25 to 100 typical concurrency. For the PDF and document parsing, it's 0.5 to 2 active CPU course per agent, 5 to 60 CPU seconds per document and 50 to 150 typical concurrency. Um, there's two more remaining. The heavy multi-modal document workflow workload is 2 to 6 active CPU course per agent, uh 30 to 300 CPU seconds, uh and 20 to 75 typical concurrency. And the ETL data transformation workload is 0.5 to 4 active CPU course per agent and 10 to 300 CPU seconds and 30 to 150 typical concurrency per host. Okay. Okay. Also, uh follow up question like, would you see the heavy, more heavy or complex task the percentage of it is increasing when views publish. because different tests have So when you said what? Um, so because different task depends on how complex it is, they will consume more CPU second. Will you see the complex tax actually will have higher percentage in the future? Um, so, Okay, so so if I understand your question correctly, then the answer is yes. Um, uh, that's actually one of the main reasons I forecast agent related CPU demand growing faster than just agent request volume. The workload mix shifts is is shifting towards more complex multi-step tasks. Um, so, so for the agent, uh task class that is simple API and look up and messaging, 2026 task share is 55, you know, percent and uh by 2030, it'll be 30%. The CPU second per task is 2 to 20 seconds. For the medium agent tasks, like browser and tools and retrieval, that's that's now 30% task share and in about three uh four years, it'll be about 38% and it'll be 30 to 150 second CPU uh, you know, CPU seconds. For the long horizon autonomous, now it's uh 3% and in three years it'll be 7% and then four years it'll be um, 12% and essentially have 500 to 2,000 plus second CPU second per task. But the thing is is is that, um, I will model exactly, you know, both the task volume growth and complex task shift even if the total agent requests grew only, um, you know, uh uh, you know, it grew only uh 30% annually, moving the workload mix towards having your task will push CPU demand faster than 30%. Okay. So you just faster than 30%. Uh is that what what that number means? Is that the overall um, growth for the CPU market? Um, so, uh, so yes, okay, so, so actually no, the I actually mean here the CPU capacity consumed by agent workloads, not the overall CPU market. Okay. So, so yeah, the the the agents are only one portion of server CPU demand and the newer CPUs deliver more cores and more performance per per socket. So 50% more agent CPU compute does not require 50% more physical CPUs. Okay, got it, got it. So so if you want to give me, can you give me a like a a overall number for the CPU growth? Um, because I I think you already have lots of the um, data points. So, so do you have any conclusion about the CPU growth for the whole market in the future? What's a like what's a growth rate per year is reasonable number for you? Okay, um, a few questions. So, uh, we we are using 10 % annual revenue growth, um, for the overall global CPU market through roughly 2030, with about 10% CAGR as as the base case. The the important part is that the segments, uh, are are are sharply, you know, divided. Um, so for the first CPU segment, which is consumer PC CPU, that is 2 to 5% 2026 to 2030 annual growth assumption. For the traditional enter enterprise server CPU, the growth will be 7%. For the cloud hyper scale server CPU, it's about 12%. For the premium high core server, you know, CPU, it's about 20%. Um, for the uh uh for the CPU capacity supporting AI agents, that's about 25 to 45%. For the agent specific CPU capacity, that is 45%. And the total CPU market revenue um growth will be 10% year-over-year. So we're looking at 10% CPU market revenue CAGR. Um and there's there's a couple of reasons for that actually. Um uh why the revenue is growth is above the unit growth? Because first the agents increase the CPU intensity. Um and we actually modeled in our labs the transition from two to 10 CPU per second for simply chatbot rag requests towards 150 to 600 CPU per second for sophisticated research and coding tasks with with long horizon agent um potentially exceeding 500 to 2,000 CPU per second. Second, the the the the the mix is moving upward. So, um when you see the premium server CPUs are, you know, $11,000 ESPV versus um $5,000 for the mainstream server CPUs, then you can see the shifts towards 96 to 192 cores. Um, premium processors, it raises CPU revenue even without equivalent socket growth. Third thing is that the AI infrastructure itself becomes more CPU heavy. So the the modeled progression is roughly 0.5 to 1 CPU equivalent GPU for conventional inference and 1 to 2 for current agents and potentially two to four CPU equivalents per GPU for execution heavy future agents. So the counterweight is is actually performance improvement. So if the CPU performance per socket improves 20% annually, then 40% increase in required CPU compute doesn't translate into 40% more processors. Um, so, so, uh uh basically the CPU computer demand is increasing around 20% per year overall, and the physical CPU, you know, uh socket demand is increasing 6% per year, uh the ESP mix is uh 4% per you know, percent. Okay. Oh, sorry. Can you hear me? Yeah, yeah. I can hear you now. Yeah, yeah. Okay. Hello? Can you hear me? Yes, I can hear you. Sorry, what's the um how long was my voice out? I think about one minute. Oh, wow. Oh, sorry about that. Yeah, but but you don't I I think I got most of the numbers. Yeah, it's okay. Um if I have a question, I will I will like call you back something like that. Um so, um that's super helpful. And also one question, like, um, is there any shortage of CPU right now from the supply chain? Did you already see the you you actually can't buy more CPU you want. can't buy enough CPU you want. Well, um, okay, so, so the uh, I mean, yes, there's a real server CPU supply constraint. Um, because, you know, Intel and AMD warned uh customers about server CPU shortages with AMD lead times around 8 to 10 weeks, and Intel delays reaching six months in in in affected markets. So TrendForce uh, uhm, if you if you had read that, it it reported that CPU and other server component lead times are extending substantially. Some components are actually approaching a year. Also, Lisa Su from AMD said that um in Q2 2026 that the server CPU supply chain is very tight because the demand was under forecast and it AMD expects the supply conditions to improve next year. So AMD has already started ramping next generation EPYC. Um, it's it's code name is Venice on the TCMC 2 nanometers. Oh, okay. So so um, you I'm not sure whether I heard it correctly. You said Intel's lead time is six months? Yes. So, so, so right now, the mainstream server like CPUs is two to four months. The high-end premium server CPU is six months. The specialized or newest, you know, CPU is uh about nine months and higher. And the AI GPU and accelerator is actually cop-contract and allocation driven. It's not, it's not a specific time. Okay. So I I I I from the news, actually there all the CPU actor with a ASP for around 10 um for all type of CPU. So would you expect the the ASP for CPU especially for premium considering the lead time is so long? Actually, we're going to rise ASP again in the future. In the near future. Uh, so I are you asking if you expect the ASP for the CPU? Yeah, would you expect Yeah, the premium CPU. I think do you think it's possibly that it's going to raise price again in the near future for premium CPU? Ah, raising the prices? Yeah. Uh, well, uh, okay, so, so it's like definitely, um, like, I'd, I'd definitely say that this is a yes, because, uh, we will expect it to go from $5,000 to about uh uh $6,000 in the next four years for the mainstream server CPU. The premium server, we are looking at uh an increase from $10,000 this this year to $14,000 in 2030. The top end and specialized CPU, we're looking at uh $15,000 now and uh $21,000 in four years. And the premium versus mainstream ASP now is 2X, but in the future, it'll be 2.25X. Okay. Got it. Got it. Thank you. Is that that mainly because of the shortage, right? Can um can you give me a guess about the how many percentage the supply is under um demand? Like, 10%, 20% Uh, okay, so, uh, the like, it's about 12, 12, 13% under supply as a base case and uh, 17% for the most constrained high core count SKUs. Okay, okay. So that number, I think going to be larger in the in next year, considering Muse have so much strong user growth system. Uh, uh, so, if you're asking about the under supply, Yeah. um, that that number, yes, of course, it will be higher. Um, uh now it's, I mean, the the the modeled under supply is about 12, 13% now. Uh, next next year will be about 15%. Um, 2028 will be about 17%. 2029 will will will be about 11.5% and 2030 will be uh 6.5%. So the risk period is actually 2027 to 2028, where the agent infrastructure will simultaneously increase the CPU demand through more browser and code execution and higher CPU capacity per accelerator, and migration towards premium 96 to 192 core parts. And the supply takes longer to respond because the foundry capacity, the advanced packaging and memory and substrates and and and the complete server qualification, they all have lead times. Okay, got it. All right. Um, I I I want to ask about uh SSD. So I I was reading your response, right? Obviously super bullish for uh for CPU and it requires a lot of high bandwidth DRAM. Um, but as as you alluded to, in terms of trend force, they're also saying uh SSDs, uh, enterprise SSDs are all of a sudden much tighter than before. Um, is that related to sort of these uh, agents like Muse or or is that sort of like a separate demand driver that's emerging? Um, right. I I think I understand your question here. Um, so, Okay, so, so the enterprise SSD tightening is related. So, okay, so we are seeing the same broad AI infrastructure cycle propagate beyond GPUs into premium CPUs. The high bandwidth DRAM and enterprise SSDs also, but the mechanism is different by the component. So, for CPUs and DRAM, the agent workloads directly increase compute and memory capacity and bandwidth, you know, requirements because the browser execution, sandboxing and the retrieval and long context processing add substantial CPU and memory intensity. So the enterprise SSD demand is more indirect. So the AI clusters are scaling checkpoint storage, model and embedding stores, vector databases, training data sets and KV cache offload, agent memory and high throughput scratch tiers. So the conventional AI in, you know, infrastructure expansion is about 60 to 70% of the incremental AI related enterprise SSD demand today, while the agentic workloads account for 15 to 25%, but the agent contribution will rise to 30 to 40% by 2029 as persistent memory and uh and the retrieval. people and the computer use workloads are scaling. Um, for the capacity planning, the GPU and H HPM, we are looking at a 32% demand growth assumption per year. For the premium server CPUs, that number is 20%. For the high bandwidth server DRAM, it's 55%. For the enterprise SSD, the capacity, you know, we're looking at, uh, 24% per per year, uh, demand growth. High performance and enterprise NVMEs, we're looking at 30% per year. And the HDD and cold storage is is about uh 9% per year. Got it. Got it. Maybe maybe um I'm curious so for so so um obviously during a agent execution um of tasks, um you know, it's it's going to require, you know, some, you know, um SSDs to store to your point, the checkpoints, the rags and the vector databases. Um in practice, you know, if like I don't know how to think about this actually, but if you had a certain task that required that that ultimately consumes like 10 billion tokens or something. You know, what's what's the rule of thumb for how much SSD that's going to take? Um, or you know, where a typical 20, 30 minute um task you run on Muse, you know, how much SSD is required? Right. Um, okay, that's a that's a good question. So, let me distinguish the 10 billion tokens processed from 10 billion tokens stored. Okay? So a 20 30-minute muse agent will process enormous token volume through repeated inference and retrieval and tool calls without writing anything close to 10 billion tokens permanently to SSD. Um, for the for the 10 billion token workflow, we need 30 sorry, 10 to 30 gigabytes of local NVMe working capacity per concurrent agent and 1 to 5 gigabytes to retain after completion. This assumes that the 10 billion figure is aggregate tokens processed across model cells, not 10 billion unique tokens materialized on, you know, on disk. Also, another sanity check, the raw text is surprisingly small. Uh the 10 billion tokens times roughly 4 bytes per token is 40 GB of raw textual content. Even if you literally stored every token once, you're talking tens of GB, not TB. But the agent execution can create multiple, you know, representations, screenshots, embeddings, indexes, logs, and temporary files, while the compression and de-duplication moves the other way. Um, and the last thing that I want to say is that the the model checkpoints are not created separately for each user agent task. The model weights and checkpoints are shared infrastructure. The task specific SSD burden is just rag data and browser and sandbox state and artifacts and logs and caches. Um, also, if you support 100,000 concurrent heavy agents, times 20 GB working set, that's already two petabytes of active SSD capacity before replication, uh spare capacity, databases, share drag, corpora and a model storage and system overhead. Got it. Um, that that's super helpful. So, um, how do you think about the demand for DRAM versus SSD for for these agent, um, use cases. Which? which one is growing quicker? Uh is it like DRAM or or NAND? Uh, DRAM or NAND? Yeah. Yeah, okay. So, um, the the DRAM demand is growing faster than NAND and SSD in the near term. Uh, the the server DRAM capacity is increasing 30% demand every year and high bandwidth premium server DRAM is increasing 30 to 35%. However, NAND is increasing about uh 23%. and the high performance enterprise NVMes are increasing 30% and the commodity NAND is increasing 15%. So, the reason for this is the memory hierarchy. So anything the agent is actively manipulating wants to be in DRAM and anything it may need later can live on SSD. Um, so you take the 20 to 30 minute muse task that we discussed, I'll provision 6 gigabytes of incremental active DRAM per concurrent agent, but 10 to 30 GBs of SSD working capacity. The SSD capacity per agent is is is larger, but the DRAM has to remain immediately addressable and the bandwidth is is critical. You also cannot run a 128 core CPU efficiently with insufficient memory bandwidth. So, at this uh server level, this actually becomes uh significant. So a future high density agent execution node will have, you know, 128 to 192 CPU cores plus 1 to 2 terabytes of DRAM plus 15 to 60 terabytes of enterprise NVMe. Uh, today, a a general purpose CPU node might have only 256 to 512 GB DRAM. So the agent infrastructure could drive DRAM per CPU socket up 2 to 4X, even while CPU core counts increase. NAND has a different advantage. The agents accumulate data over time. So persistent memories, embeddings, user files, execution traces and RAG corpora don't disappear when when a task finishes. Therefore, NAND could ultimately have a very large capacity, you know, opportunity, even if it's near-term growth rate is is lower. Got it. Perfect, yeah. Okay, and it's super helpful. And also a follow on question for CPU, um how much CPU can be saved through approaches like website reconstruction or engineering optimization? Right, so engineering optimization uh is is slightly different. Um, depending on, I mean, it it it's saying quite a lot. Um, you can, you can, you could have software and workload engineering capable of reducing CPU demand by uh, um, 35% versus a naive implementation. Uh, some browser workloads can reach 60% savings. Um, for RAG and query caching, you could save 17%. Anyway, website reconstruction is very important. An agent uh needs the product name, the price, inventory and the add to cart state from an e-commerce page. A naive computer use agent launches Chromium, downloads 10 megabytes, executes hundreds of JavaScript tasks, lays out the page, renders it and captures screenshots and then interprets those those pixels. But instead, the infrastructure reconstructs a lightweight semantic representation from DOM and accessibility API data. And the product is, you know, shoes, the price is $129, uh, you know, stock equals yes, sizes e. equals 9, action equals add click to card. So this could turn something like 10 to 30 CPU seconds per browser interaction into 3 to 10 CPU seconds, meaning 50 to 70% CPU savings on that portion of the workload. But it doesn't eliminate the CPU growth. So, uh, by by 2039, the agent will perform three times as many browser tool and code operations because it's more autonomous. So the requirement becomes 200 * 3, which is 600 CPU per second. And if you apply another 40% optimization, you get 600 * .6, which is 360 CPU second. So you're still at 1.8 times the CPU per completed user task compared with today's unoptimized agent. And this is how you you build your CPU forecast. Okay. Okay. So so actually the the shortage, um, uh number you mentioned about the forecast already considering the optimization or the saving, right? Uh, the the optimization, yes. Uh, uh, so, so it's it it's really about um, the the like we we you consider optimization, um, the meaningful like software and you know, and a hardware one. Uh, so we're assuming techniques like browser website reconstruction, caching, warm sandbox pools, better scheduling more efficient parsing. Without those improvements, the the the demand gap will be about 30%. But, um, that's not a realistic base case because hyperscalers aggressively optimize before allowing CPU requirements to scale that inefficiently. Also, um, yeah, that that's it, sorry. Okay, okay, that's super helpful. And also, um, can you um, help me understand how the agent boosts the use of GPU as well? Like the agent loop, um, actually bring how much more GPU use versus a chatbot. Right. Um, so the, right. Um, the chatbot invokes the GPU once per user turn. The agent runs an execution loop that can invoke the GPU many times before returning one completed task. This is why agents can multiply GPU consumption even if the underlying model is is is is unchanged. So, um, uh uh uh like if if you ask a chatbot, find me the best supplier for this product, that the chatbot will say, you know, prompt to GPU to answer. And the GPU is probably busy for two to five seconds. Um, but then Muse would would do prompt to to GPU to make plan. For the CPU browser, you search suppliers, for GPU, you interpret the results. For the CPU and browser, you open supplier A. For the GPU, you decide what information matters. For CPU, you extract prices. For the GPU, you compare offers. So one user request now has 8 to 15 separate GPU inference episodes. But it's not 10 times the GPU comp compute. The the intermediate calls are much, you know, are much smaller. So plan one could take 4,000 tokens, page interpretation could be a thousand, the tool decision could be five 500 only. Um, and you know, if if a chatbot turn costs one GPU compute unit, a 10-step agent will realistically consume five to 10 units rather than 10. Okay. Um, also follow on question. like when when we consider about the demand for GPU actually is related to two things. One is how much token uh, I can see the point. Uh the agent loop actually help increase the token a lot. But I'm concerned, a little bit concerned about that for agent, actually you don't need a very large model. Um the parameter can be very slow, very very small. So, is that the real case for Muse or for any other agent like Grockbot etc? Sorry, for Muse or for what? Uh the the the parameter for Muse and for Grockbot, uh the the the signal product, yeah, the similar product from SpaceX, yeah. Yeah. Yeah. Um Right. So so so the let's let's separate the GPU demand into token volume and compute per token. The agent can dramatically increase the the the the loop, the step. you know the first part. Yeah. Yeah. while while reducing the second by routing much of the execution loop to to the smaller models. Uh for for I mean, like an agent will consume 10 times the tokens of a chatbot task, but the average compute per token will be two to five times lower because 60 to 80% of those tokens do not require the largest model. The net GPU compute per completed task will still rise around 2 to 5X, not 10X. For for metal muse, specifically, uh we we don't have a parameter count. We you know, we don't say Muse is X billion of parameters, but but we are using a model portfolio per router, not repeatedly invoking the largest llama class model for every browser observation and tool decision. So Grock, however, is inference hardware per platform, not one fixed parameter foundation model. It can serve different models, so there is no meaningful single Grock parameter count. Its it's relevance to agents is is is that very high token throughput and low latency can make repeated model calls inside an agent loop much cheaper in wall clock time. So the agent GPU demand is the total agent tokens multiplied by the compute per token, divided by the hardware throughput. The agents push token tokens per task sharply up upward, and model routing pushes compute per token downward, and faster inference hardware pushes tokens per GPU second upward. The key question for GPU demand is whether the first grows faster than the other two improve. So, uh, for for the future, we will expect it to, but by much less than the raw agent token growth would suggest. you mentioned is much slow? Yes. Okay. what would will will that change in the future? The the the the the Asian loop, the first part grows slower than the the rest of it. Um, so, well, obviously, yes, that that that agent's latency will will fall dramatically, maybe faster than the ordinary chatbot because uh right now the slowness is is not unavoidable. like you will have to face it. Uh for a 20 to 30 minute muse task, two to five minutes is actual model and GPU inference, and 5 to 10 minutes is browser, code, document, CPU execution, and the remainder is network latency and website loading and APIs and sequential dependencies. Future systems will parallelize this. So instead of checking 20 suppliers sequentially, the planner will spawn 10 to 20 sub agents. and each has a small model in its own browser and tool environment. So the model routing means that a 3 billion to 30 billion model will handle routine observations and tool decisions, while a much larger model is invoked only for difficult planning or synthesis. Okay, so so in conclusion, in the future, it's going to be faster because the whole system including the tool use will be fast. So GPU won't wait so wait for so long. Exactly. Okay, Got it. Got it. And also, um a question about their, um, if the most of the GPU workload is based on Nvidia, for example, will that influence um the CPU choice when you purchase? Like for example, you prefer Nvidia CPU combined with a GPU combined with a CPU rather than Nvidia's GPU combined with maybe Graviton, for example. Would would the system package will be a plus um for in in CPU scenario. Uh, yes. It does influence the CPU purchasing, but um the the the coupling depends on whether you're buying GPUs or complete Nvidia systems or rack scale architectures. Um there are three layers. If your deployment is PCIe GPUs in a custom server, then you have the high CPU freedom. You could have AMD, EPYC or or Intel Xeon. However, if your deployment is Nvidia integrated rack scale platform, um then your CPU freedom is is actually lower. You you know, Nvidia Grace becomes part of the architecture. Um if you have an HGX 8CP eight GPU server, then you can use um a validated X86 host platform. So, historically, um, eight H100s and H200s, HGX box pairs with two server CPUs, often AMD EPYC or or Intel Xeon. So buying Nvidia generates demand for uh third-party server CPUs. Nvidia is moving more towards Grace, where then Nvidia controls more of the CPU and GPU architecture. And in those systems, you are no longer independently saying, I'll buy eight Nvidia GPUs and then choose an AMD CPU. The CPU and memory interconnected accelerators become one system. Okay. So when you purchase, you mentioned it really depends on how you link your GPU with CPU. Will you prefer PCIe or NVLink when you purchase, choose the connection method? Cuz PCI is actually slower in communication. Well, yeah, so so choice depends on what CPU, GPU communication you need. So if you have an LLM inference training GPU to GPU, then your preferred connection is the NVLink or the NV switch because it's a very high bandwidth and low latency. If you have a CPU feeding GPU inference workload, uh the preferred connection is the PCIe integrated coherent link depending on, you know, a platform. If your workload is browser execution, then it's a CPU only pool. There's no reason for MV link. For the code sandbox, it's a CPU only only tool because the GPU is normally remote. If it's a rag or vector retrieval, it's CPU and DRAM SSD. because the GPU can be accessed over the network whenever needed. And finally finally the agent orchestration is network disaggregated because the GPU and CPU scale independently. So the key distinction here is that the NV link's huge advantage is GPU to to GPU, not every CPU needs an ultra fast link to every GPU. Okay. So, for example, in agent scenario, like how many uh percentage NV link can acquire in their connection market? Sorry? How many percentage what? Uh the NV link can can can can acquire, can take, the market share in agent scenario. What's the NV link market share versus PCIe? Ah, okay. um All right, so, uh, let me, let me check this out. I think we have like a dashboard for for this. If you're if you mean Okay, so, NV link runs inside dense Nvidia accelerator systems. PCIe is the uh broader CPU to device fabric. The the exposure. So so PCIe share now is 55% and in 2030, it'll be 45 percent. The NV link and NV switch is 30% now, will be 35% in 2030. The Ethernet network fabric is 12% now, 17% in four years. The CXL and other coherent fabrics is less than 5% now and 7% in 2030. So we're you know, we're looking at 55% PCIe, 30% NV link, 12% Ethernet, 3% CXL. But if you restrict the denominator to GPU to GPU traffic inside NV agent inference clusters, the picture becomes reversed. We we model 70 to 90% of high bandwidth infra, uh sorry, in intranode and intra-rack accelerator traffic eventually riding NV link and NV switch in Nvidia heavy deployments. The reason PCIe is larger in the overall agent architecture is what we've been, you know, discussing. An agent has enormous amounts of CPU execution, NVMe, NIC, browser, sandbox and retrieval infrastructure. Those components don't need NV link. Mhm. Okay, that's that's very clear. Thank you so much. And also a very, very last question. Um, do will you know the capex plan for GPU or CPU for Meta next year? I'm not sure you have the access to the data. Sorry, you you're asking about the capex plan for for GPUs? And the CPU for Meta next year. Okay. So, um, yes, I do have access to it. Um, but uh uh it's it's it's about 180 to 190 billion 2027 capex uh total. And it'll be distributed as as follows: 52 billion for Nvidia GPUs and systems, uh 16 billion for Meta MTIA and other accelerators, 10 billion server CPUs, uh 16 billion DRAM and HPM, 8 billion for SSD and storage, uh 14 billion for networking switches and optics, uh 62 billion for buildings, power, cooling and all the other stuff. So, CPU silicon is about 6% of total capex, but it's about 10% of compute server hardware procurement. Okay, that's clear. So, so in total, how many gigawatts the capex could could need? the power, the power. Uh so Yeah. Yeah, yeah, yeah. So, uh, the the the data center power capacity, it's it's it's basically so the 2026 CAPEX guidance right now is 140 billion dollars. Um, so, uh uh we're looking at uh three three, you know, gigawatts of incremental compute capacity funded uh last year and the capacity energized was two gigawatts. This year, it's uh uh funded is five 5 gigawatts. And the capacity actually energized is coming close to 4 gigawatts. Next year, uh the funded is six, you know, gigawatts. Um, but the energized is planning to be uh 4.7 gigawatts. And 2028, we are looking at 7 gigawatts funded and 6 gigawatts actually energized. Okay, got it, got it. And and the capax number you you just given to me is for this year or next year? The capex that I gave you, um the the 140 billion, that is for this year. Oh, okay. So do you have the number for next year? Yeah, so so Did I mention it earlier? Uh, for the 2027, the CAPEX is 1 182 billion. Okay. Got it. got it. Okay. Thank you thank you so much. I think that's all for our questions. Thank you so much. It's super super helpful. And also, do you mind I um ask the vendor to give me your like email, etc., just in case we can keep in keep in touch. Um we won't lose connection. Sure. Okay, okay. Thank you so much. I I will ask the the vendor to give me your email, email. Thank you. And then we'll keep in touch. Thank you so much. It's super super helpful. Yeah. Thank you. Thank you. Okay, bye bye. Thank you. Bye bye. Bye.