OCP2026｜Helion与Vera CPU机架
Agent执行与模型推理应分别规划容量
截至 2026 年 10 月 17 日
OCP 2026 带来了两项不同的机架设计进展：AMD 新发布面向 Agent 的 Helion 蓝图，支持独立 CPU 执行机架和企业 CPU/GPU 一体化形态；NVIDIA 则开放 Vera CPU 机架设计规格，扩展已有产品的生态协作。[9][1] 相较围绕模型推理配置整套资源，这两项动作让执行代码、调用工具与运行沙箱的能力，成为可以单独规划的基础设施对象。
核心变化是执行池有了更明确的产品边界，CPU、内存和运行环境可以按任务需求配置。发布状态仍需分清：Helion 的伙伴配置开发中，计划11月可用并计划贡献 OCP；Vera CPU 与机架已在3月 GTC 发布，本届增量是设计规格开放。[9][10] 它们提供了建设路径，实际任务产能仍要靠端到端验证。
Helion 让执行与推理可以分开配置
Helion 的 独立 CPU 执行机架（CPU-only）基于第六代 EPYC，宣布的最高配置为32768个 CPU 核心，定位为 Agent 执行提供专属容量，并连接独立模型推理基础设施。企业一体化形态则在一个蓝图中组合 EPYC CPU、Instinct MI350P GPU 和通用计算节点。[9] 核心数是配置上限，不是活跃 Agent 数量，更不是每秒能够完成的任务数；具体应用还会受到内存、工具响应和隔离方式约束。
两种形态对应不同的资源组织方式。对于已经拥有大型模型服务、需要大量执行环境的运营者，独立 CPU 池可以按工具调用和代码执行压力扩容，不必每次都连同 GPU 一起采购。对希望在现有 IT 条件中部署 Agent 的企业，一体化形态则提供较集中地配置执行、推理和辅助计算的路径。独立扩容与集中部署处理的是不同约束，选择应由任务结构、网络、成本和运营条件决定。
独立执行池的灵活性有条件。执行环境与模型服务之间需要网络和状态交接，模型请求的排队可能把大量沙箱留在等待状态；反过来，工具执行过慢也可能使模型资源周期性闲置。一体化机架减少了组织复杂度的某些部分，却仍可能出现 CPU 和 GPU 需求比例随业务变化的问题。产品化的价值，是允许采购、配置和运营围绕这些差异展开，而不能预设固定的核心与 GPU 配比。
AMD 还在 Helion 发布中提到为模型调用选择去向的路由组件 token router。[9] 对产品评估，值得进一步核对的是模型选择、配额、计费与故障回退怎样保持一致。不同模型的输出长度、工具调用次数和失败恢复方式可能改变 CPU 负载。采购时把路由能力和执行硬件完全分开看，容易遗漏模型策略变化带来的容量需求。公告中的功能描述也不能替代具体版本与端到端测试。
Vera 本届开放的是已有 CPU 机架设计
NVIDIA 在3月 GTC 已宣布集成256颗 Vera CPU 的液冷机架。10月 OCP 的进展，是把 Vera CPU rack 设计规格纳入 MGX 开放架构扩展，明确服务工具调用、编排与沙箱执行。[10][1] 生态伙伴因此能够围绕开放设计开展制造与集成，并让 CPU 执行侧与加速计算侧沿用共同的机架设计原则。
这一动作与 Helion 放在一起，支持一个更具体的趋势判断：Agent 执行正在成为可独立规划的基础设施能力。模型生成计划、脚本或操作意图之后，还需要环境运行程序、处理文件、访问服务并返回结果。若这一段没有明确的容量和责任边界，GPU 的推理速度提高后，任务仍可能堵在执行队列上。
开放机架设计解决的是基础设施协作的一部分，不会自动统一沙箱 API、工具权限或任务验收标准。机架能够采用共同的供电、冷却和集成原则，应用层仍需决定运行环境、网络出口、镜像管理与任务状态如何衔接。对经营者，产品设计开放可以降低某些集成阻力，但从机架上线到“Agent 能稳定完成工作”之间，依然需要一条软件与运营链路。
独立规划执行池要从完整任务路径开始
设想一个数据分析 Agent：它先理解问题，再读取文件、运行代码、检查结果，必要时修改代码重试，最后生成解释。模型推理只是其中若干步骤。文件解析、压缩解压、数据库访问、浏览器操作和代码执行，可能分别消耗 CPU、内存、存储与外部服务额度。究竟谁是瓶颈，取决于任务路径，而不是产品被归类为“生成式 AI”还是“Agent”。
因此，任务级追踪需要把模型请求和工具调用串起来。若同一个任务在沙箱队列里等了几秒，模型接口的首 Token 指标依然可能很好看；若工具超时后引发多轮重新规划，Token 总量反而会上升。对外表现是完成时间变长，对内却可能出现“推理吞吐增长”的假象。把这些事件关联到同一个任务标识，才看得见真实成本和失败位置。
任务分解也改变了尾延迟。多个工具并行调用时，等待结果汇总的阶段可能受最慢分支控制；连续工具调用时，启动、鉴权、网络和结果校验的耗时会反复进入关键路径。并行度增加还会放大同时到达的沙箱创建请求。因而，Agent 平台应同时控制每项任务的并行预算和整个租户的并发额度，避免某个任务的自我加速挤占其他任务的完成机会。
CPU 与内存需要分别计算容量
CPU 的需求可以先从单位任务消耗拆起，而不必立刻选处理器型号。编排线程的计算时间、工具进程的运行时间、沙箱管理和网络处理，最好分别计量。等待外部 API 的任务可能几乎不占核心，却仍占内存、连接、沙箱槽位与状态存储。把“活跃 Agent 数”直接换算成“忙碌核心数”，容易同时高估计算需求、低估其他资源。
举一个只用于容量思考的假设：系统稳定接收每秒 100 个任务，每个任务平均累计消耗 0.3 核秒 CPU，则平均计算需求是 30 个持续工作的核心当量。再假设每项任务独占一个沙箱，沙箱平均保留 2 秒、实际常驻内存均为 1 GiB，且没有额外排队，则平均在场沙箱约为 200 个，对应约 200 GiB 内存。这不是采购规格；突发、尾部、系统开销、冗余和不同核心的性能差异均未计入。算例只是说明，CPU 与内存不能按同一个倍率扩容。
同样，更多核心也不保证更短的关键路径。单线程工具的执行速度、内存带宽、存储读写、NUMA 放置以及网络往返，都可能影响结果。选型应使用自己的任务集合，观察加核、提频、增内存或改进存储分别改变了哪个阶段。对于 Token 工厂经营者，这意味着 CPU 执行池应成为有独立容量、成本和服务目标的产品能力，而不是 GPU 服务器上未被认真核算的附属资源。
当执行资源成为独立池，容量模型还需要连接两条到达流：用户任务到达率和模型产生工具调用的速率。同样每秒100个任务，如果每项任务平均工具调用次数增加，执行池可能先于模型服务达到瓶颈；如果工具改为长时间等待外部 API，增加核心未必有效，但沙箱驻留内存和连接数会继续增长。模型升级、提示词调整和重试策略因此也应纳入执行侧容量回归测试。
执行权限是产能承诺的一部分
沙箱负责限制执行环境能影响的范围，但模型生成的代码仍可能在授权范围内做错事。即使无法逃逸到宿主机，它也可能错误修改已挂载文件，或向被允许访问的服务发送不恰当请求。gVisor 的安全说明明确指出，隔离不能替代沙箱内部应用的安全，也不会取消应用已经获得的访问权限。[6] 对 Agent 产品，工具权限与动作审批因此需要独立设计。
不同执行技术的取舍也应基于威胁模型。轻量虚拟机（MicroVM）、应用内核和普通容器，采用的隔离机制、兼容性及运维路径不同，不能只按启动速度排序。平台应该验证不可信代码、租户数据、宿主资源与外部系统之间的边界，再测量在这个边界下能达到的性能。为了得到更好的基准而关闭出口限制或放宽资源控制，得到的数字可能对应另一种产品。
用有效任务而不是单项峰值选择机架
Agent 工厂需要比 Token 产量更接近业务结果的分母。这里建议使用“在约定时间内完成、通过验收、没有违反约束的任务数”，并按任务类别分别统计。代码任务可以通过测试与结果检查验收，数据处理任务可以检查输出完整性，涉及外部动作的任务还要核对实际状态。模型自己声称完成，不足以充当所有任务的验收依据。
单位有效任务成本，应把模型推理、CPU 执行、内存驻留、存储、外部工具费用、失败重试以及必要人工复核都计入。为了可比，还要固定任务难度、成功条件和允许的重试次数。便宜模型如果引发更多工具调用和修复循环，整体成本可能更高；更快的 CPU 如果对应阶段只占极少时间，也未必值得溢价。这些都应由端到端记录验证。
对运营者，独立执行池是否值得建设，应先观察 CPU 执行与模型推理的负载是否经常错峰、扩容需求是否不同，以及集中部署能够节省多少集成和运维工作。若任务经常长时间等待工具，CPU 核心可能不是首要约束，沙箱驻留内存、连接和恢复容量反而更重要。把这些需求量化以后，再比较具体机架与托管方案，采购讨论才有共同分母。
CPU 的商业位置由此变得清楚：它承担把模型决定变成实际工作的执行能力。企业应自行掌握任务定义、验收、权限、成本口径和失败责任；运行时、模板管理与基础编排则可以集成或采购。购买托管服务时，重点应是可用性、恢复、审计和数据处理边界，而不只是每秒能创建多少环境。
Helion 与 Vera CPU rack 的本届动作，让执行侧的容量规划拥有了更清晰的产品对象。企业可以开始对照自己的任务路径，评估独立执行池还是集成部署更合适，再向下选择处理器、内存、运行时和配套服务。技术路线仍应由任务结构和服务要求决定，不能从机架名称直接推出采购答案。
OCP 2026 在这条线上的重要变化，是执行能力开始以开放蓝图和机架设计规格进入生态协作。下一步需要验证的，是这些形态怎样转化为稳定供应、可升级的软件栈和可承担事故责任的服务。GPU 仍决定许多推理阶段的效率，执行池则需要让工具与代码按权限完成工作；两者共同支持的有效任务数量，才接近 Agent 产品最终能够出售的产能。
技术附页
以下以公开运行时文档和沙箱供给测试，展开执行池的启动、恢复、权限和验收方法。这些实现与微基准是补充证据，不是 Helion 或 Vera 已交付能力的证明。
一 启动 暖池与暂停恢复的容量边界
沙箱启动至少包含环境准备、运行时恢复或启动、网络与策略配置，以及应用真正可用几个环节。CubeSandbox 的官方架构将控制面、节点生命周期、MicroVM、存储和出口控制分别列出，说明“创建一个环境”本身已经是一条系统调用链。[3] 一个创建 API 返回成功，是否等于工具依赖已经就绪，需要根据具体平台和测试定义确认。
暖池可以提前准备常用环境，减少请求到来后的等待，但保留环境也会占用资源。预热多少、保留多久、哪些租户可以共享基础模板，应由到达分布和隔离要求决定。对偶发长任务，常驻大量暖实例可能得不偿失；对短时高峰，暖池耗尽后的冷启动曲线可能比平时的平均值更重要。经营者需要知道，服务承诺覆盖的是暖态体验，还是包括扩容与恢复时的体验。
暂停与恢复是另一种选择，却也存在容量承诺。CubeSandbox 生命周期文档把暂停后的物理资源释放与调度配额保留分开：释放更多配额可以提高密度，也可能使后续恢复因为资源不足而被拒绝。[4] 这项设计揭示了普遍问题：把环境暂存起来，只是把立即占用改成未来恢复需求，并没有让需求消失。给客户承诺随时恢复，就必须为同时唤醒保留余量。
模板、镜像、依赖包和快照还会把压力传给存储。大量沙箱同时恢复时，控制面的平均 CPU 占用未必很高，但快照读取、文件系统元数据或网络策略更新可能排队。运维看板应拆开创建、就绪、首次工具执行和回收的耗时，才不会把所有等待都归咎于处理器。长会话还应验证暂停后外部连接和凭据状态，恢复进程内存不能保证外部世界没有变化。
二 出口代理和工具凭据的边界
CubeSandbox 的出口代理把域名控制、凭据注入和审计列为独立能力。[7] 这种分工对平台设计有启发：尽量让工具凭据不进入模型可读的环境，让访问范围随任务身份确定，并让越权尝试留下证据。但代理也需要高可用、策略一致性和性能预算。安全功能进入实际请求路径后，应与业务负载一起压测，不能只在验收表上确认“已经开启”。
出口控制需要与任务身份保持一致。一次恢复后的任务，可能面对已经失效的凭据、变化后的外部对象或新的访问策略；恢复进程内存不代表外部权限也应原样恢复。验收应包含凭据失效、策略变更、代理不可用和越权尝试，并确认失败能够被记录、拒绝或安全重试。
三 Intel 沙箱供给微基准的测量范围
Intel 在10月8日发布的 Xeon 测试，可以作为观察执行池供给的补充，但它早于本届大会，也不是 Helion 或 Vera 的产品测试。9月进行的 CubeSandbox 创建与删除测试（create/delete），给单个沙箱配置2000 milliCPU和2000 MiB内存，逐步增加创建并发；在平均创建延迟200毫秒阈值附近，Xeon 6990E+、Xeon 6980P和EPYC 9965的并发约为313、277和246。平台的核心数、内存速率和功耗规格不同。[2]
创建并发衡量的是供给路径的一段能力。它不等于持续运行的 Agent 数，平均延迟也不能推出任务尾延迟达标。CubeSandbox 的 cube-bench 文档进一步说明，测试直接调用创建与删除接口；其网络策略模式等待创建 HTTP 成功，但不检查数据面的允许、拒绝或沙箱内连通性。[5] 因此，控制面性能、运行时安全和应用成功率需要分别测量，再通过同一任务链串联验证。这项测试适合帮助设计验收方法，不应替某一机架产品签署端到端性能结论。
四 运行时路线图与产品验收
产品团队可以先建立一小组代表性任务，再观察正常流量、突发流量、暖池耗尽和部分节点不可用时的表现。测试中的错误和拒绝必须进入统计，失败后是否可以安全恢复也应作为验收内容。CubeSandbox 当前公开路线图仍列有故障恢复、调度运维增强和 API 兼容性等后续工作。[8] 已有代码、可运行示例与所需生产承诺，依然要逐项对齐。
采购评估应把三种证据分开：公开蓝图说明能够怎样组织系统，具体配置和支持矩阵说明可以采购什么，端到端任务测试说明这些资源能够交付什么结果。Helion 的计划可用时间不能写成现货，Vera 本届开放设计也不能直接证明所有伙伴配置已普遍交付。后续应跟踪明确的配置、软件版本、恢复能力和服务支持，而不只追踪峰值核心数。
参考资料
[1] NVIDIA OCP 2026 公告中的 Vera CPU 机架用途，2026-10-12。
https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/
[2] Intel Scaling Sandboxed Agentic AI on Xeon CPUs，2026-10-08；Intel 新闻目录日期记录。测试时间为 2026 年 9 月。
https://www.intel.com/content/www/us/en/newsroom/news/data-center/scaling-sandboxed-agentic-ai-xeon-6.html
https://www.intel.com/content/www/us/en/newsroom/home.html?filters=[-7300596454%2C2661798488]
[3] CubeSandbox 架构说明，读取于 2026-10-17。
https://github.com/TencentCloud/CubeSandbox/blob/master/docs/architecture/overview.md
[4] CubeSandbox 沙箱生命周期与暂停配额，读取于 2026-10-17。
https://github.com/TencentCloud/CubeSandbox/blob/master/docs/guide/lifecycle.md
[5] cube-bench 官方测试说明及网络验证边界，读取于 2026-10-17。
https://github.com/TencentCloud/CubeSandbox/blob/master/examples/cube-bench/README.md
[6] gVisor 安全架构与保护边界，读取于 2026-10-17。
https://gvisor.dev/docs/architecture_guide/intro/
[7] CubeSandbox 安全代理文档，读取于 2026-10-17。
https://github.com/TencentCloud/CubeSandbox/blob/master/docs/guide/security-proxy.md
[8] CubeSandbox 官方公开路线图，读取于 2026-10-17；路线图内容不等于已交付能力。
https://github.com/TencentCloud/CubeSandbox/blob/master/docs/guide/roadmap.md
[9] AMD Helion Agentic AI Compute at Rack Scale，2026-10-12。开放蓝图已宣布，计划贡献 OCP，伙伴配置开发中并计划于2026年11月可用；不等于已经获得 OCP 批准或全面现货交付。
https://ir.amd.com/news-events/press-releases/detail/1301/introducing-amd-helion-agentic-ai-compute-at-rack-scale
[10] NVIDIA 在 GTC 发布 Vera CPU 与 CPU 机架，2026-03-16。用于历史基线；OCP 本届新进展为设计规格开放，不能将3月产品发布重记为10月首发。
https://nvidianews.nvidia.com/news/nvidia-launches-vera-cpu-purpose-built-for-agentic-ai
[11] AMD Helion 官方产品页及机架外观图，读取于2026-10-17。图片为官方产品外观渲染，具体交付配置以伙伴方案为准。
https://www.amd.com/en/products/rackscale-solutions/helion.html
文中两个机架形态的比较、任务容量和采购建议为作者分析。100任务/秒、0.3核秒、2秒驻留、1GiB内存为明确假设的说明性算例。Intel 厂商测试仅支持其特定配置下的沙箱创建供给比较。