OpenAI Dots 的 Geekbench 7 结果显示其云端计算机规模大于 Meta Muse
OpenAI Dots 的 Geekbench 7 结果表明，每个智能体可获得九个 AMD EPYC 核心和近 10GB 内存。与 Meta Muse 所关联的双核心环境相比，这是一项明显更大的 CPU 资源分配。
首个公开报道的 Dot 基准测试在 Geekbench 7 单核测试中获得 1,667 分，多核测试中获得 9,435 分。之后出现的六项结果使用了看似相近的配置，因此最初的截图更难被视为孤立的偶发现象。
这一对比带来了鲜明的张力。OpenAI 显然正在为其自主智能体提供更多本地计算能力，但 Geekbench 无法衡量这些能力是否能带来更高质量的已完成工作。
Dots 于 2026 年 9 月 29 日在 OpenAI DevDay 上推出。OpenAI 将其描述为具备云端计算机、浏览器以及已连接应用访问能力的持久型智能体。
Meta Muse 通过资源规模更小、已有报道的沙盒环境提供了相似的自主模型。早期数据表明，OpenAI 针对同一产品问题选择了资源投入更高的方案。
OpenAI Dots 的 Geekbench 7 结果指向九个 CPU 核心
现有基准测试记录一贯描绘出一台性能可观的 Linux 虚拟机，但其中并未直接点名 OpenAI 或 Dots。
首项结果通过 INIYSA 在 X 上分享的截图公开出现。截图显示，该 Geekbench 7 测试于 9 月 25 日上传，比 OpenAI 正式发布 Dots 早了四天。
底层的基准测试记录显示系统为 Ubuntu 24.04.3 LTS，处理器为 AMD EPYC 9V74。Geekbench 识别到一颗拥有九个可用核心的处理器，基础频率为 2.60GHz，内存为 9.73GB。
该记录未显示系统型号、账户所有者或可识别的 OpenAI 标签。该页面没有任何信息能独立证明这台机器属于某个 Dot。
不过，时间点和配置值得进一步审视。Tom’s Hardware 随后发现，在产品发布后，有六项公开结果使用了看似相同的处理器和内存分配。
根据这项硬件调查，这些发布后的测试在单核性能上获得了 1,512 至 1,614 分，多核成绩则介于 8,135 至 8,991 分之间。
据报道，后续机器将 Debian 而非 Ubuntu 识别为操作系统。这一差异并不一定意味着底层基础设施不同。
开发镜像可能使用 Ubuntu，而生产模板使用 Debian。用户也可能在运行基准测试前修改环境。
发布前的机器取得了 9,435 的多核分数，比发布后报道的最佳成绩高约 5%。它也比后续结果组的中位数高出约 10%。
这意味着首轮测试看起来是一个较高的结果，而非完全不同等级的机器。其 1,667 的单核分数也与发布后的区间相当接近。
Geekbench 7 是一项合成基准测试，即运行标准化测试套件，而不是完成常规智能体任务。该版本测试的工作负载包括压缩、代码编译、图像处理、光线追踪和视频编码等。
Primate Labs 在 Geekbench 7 中调整了多核表现的处理方式，以更好地反映实际应用如何使用可用线程。并非每一类工作负载都会自动占用全部核心。
这种设计让结果比单纯的核心数量更具参考价值。但它仍无法复现 Dot 研究问题、编辑文件或处理审批请求时的表现。
因此，这些记录仅支持一个有限结论：一组与 Dots 相关的机器似乎暴露出九个 AMD EPYC 核心和约 9.73GB 内存。
它们并不能确定每一项结果由谁上传，也无法揭示底层宿主机、存储性能、网络限制，或共享物理硬件的智能体数量。
这些未知因素很重要，因为虚拟机只会暴露其基础设施的一部分。处理器名称可以描述宿主机家族，却掩盖了调度策略、资源争用和实际可持续容量。
这九个核心可能在整个任务期间持续可用，也可能只是会随需求变化的临时资源分配。
不过，重复出现的发布后结果使这一配置比最初截图本身更可信。即便没有 OpenAI 的正式确认，它们也表明存在一种可识别的部署模式。
云端计算机是 OpenAI 智能体战略的核心
Dots 需要本地计算资源，因为其承诺不止于在聊天窗口中生成文本。
OpenAI 将 Dots 介绍为：用户给出目标和边界后，仍可持续工作的智能体。它们能够在后台运行，并在决策或信息缺失阻碍进度时请求用户关注。
该公司表示，每个 Dot 都配有云端计算机、浏览器和已连接应用。其Dots 产品页面将这一持久环境作为体验的定义性组成部分。
这一架构使 Dots 区别于传统聊天机器人的单次回复。聊天机器人可以通过模型推理及有限的工具集回答一次请求。
而持久型智能体还必须维护文件、运行应用、保留任务状态，并跨时间协调行动。除模型推理外，这些功能也会产生对常规计算资源的需求。
一项自主研究任务能说明其中差异。模型或许会决定查阅哪些来源，但云端计算机负责处理浏览器会话、下载、文档解析和中间文件。
软件任务可能要求克隆代码仓库、安装依赖、运行测试和编译。媒体工作则可能涉及图像转换、视频处理或渲染。
Tom’s Hardware 报道称，一个 Dot 曾列出一长串预装应用。报道中的清单包括 Chromium、Blender、GIMP、Inkscape、Kdenlive、Godot、FreeCAD、QGIS、Python、Node.js 和 Git。
该清单来自智能体自身的回答，尚未被独立验证为通用镜像。不过，它仍说明了 CPU 和内存分配为何重要。
清单中的许多应用都能使用多个核心。编译器、媒体编码器、渲染器、地理工具和科学应用均可受益于并行处理。
九个虚拟核心比极简浏览器沙盒为这些任务提供了更多空间。近 10GB 内存也允许运行更大的应用及多个并发进程。
不过，与高端工作站相比，这一环境仍较为有限。Dot 在编辑大型媒体项目或加载大量本地数据集时，可能会遇到内存限制。
这些记录也未显示专用 GPU。虽然这并不证明无法通过其他服务使用 GPU，但 Geekbench 的 CPU 页面无法确认 GPU 访问权限。
OpenAI 可能会将专门工作路由至独立的基础设施。该基准测试仅描述了测试操作系统可见的环境。
云端计算机还承担着重要的隔离功能。智能体可以操作其被分配的环境，而不会获得对用户实体机器的不受限访问。
这种分离能够限制错误影响，并简化恢复流程。受损的虚拟机比用户的笔记本电脑更容易被替换。
隔离并不能消除风险。Dot 仍可能影响已连接的应用、共享文件、外部账户，以及其经授权会话可访问的信息。
因此，OpenAI 的产品宣传依赖于两套不同的系统。GPT-6 Astra 负责选择行动，而云端计算机提供执行行动的场所。
若只关注模型，就会忽略产品的一半。基准测试泄露之所以重要，是因为它让人们得以早期一窥另一半。
OpenAI 更广泛的DevDay 回顾也将 Dots 与托管智能体、计算机使用工具和基于云端的 Codex 工作流并列。综合来看，这些发布指向托管执行将成为核心平台层。
竞争问题不再仅限于哪家公司拥有最聪明的模型，还涉及谁能为数百万长期运行的智能体提供可靠、安全且可负担的计算机。
OpenAI 更大的 VM 给 Meta Muse 带来压力
最鲜明的早期差异在于资源分配：Dots 似乎获得九个 CPU 核心，而 Meta Muse 据报道仅使用两个。
Tom’s Hardware 此前将 Meta Muse 沙盒与配备两个核心和 8GB 内存的 AMD EPYC Turin 宿主机关联起来。十次相关 Geekbench 测试的单核中位分数约为 1,041，多核中位分数约为 1,394。
六次有报道的 Dot 测试单核中位分数约为 1,570，多核中位分数约为 8,550。这使 Dots 的单核中位成绩约为 Muse 的 1.5 倍，多核中位成绩则约为其六倍。
结合这些配置后，这一结果便不那么令人意外。九个可用核心在能有效拆分工作的负载中理应优于两个核心。
报道显示，Dots 所用处理器的基础频率也为 2.60GHz。Muse 所用处理器的基础频率据称为 1.5GHz，尽管 Muse 使用了更新的 EPYC 架构。
这些数据令对比具有参考价值，但并不严格。两种智能体运行在不同处理器、操作系统以及可能不同的虚拟化策略之上。
这些基准测试提交并非受控的实验室测试。它们来自不同时期的公开环境，后台负载未知，上传者也无法确定。
即便如此，多核差距的幅度仍表明这是一项有意的基础设施选择。OpenAI 似乎愿意为每个活跃智能体分配更多通用 CPU 能力。
这种选择或许能改善涉及多个并行进程的任务。Dot 可以在索引文档的同时编译代码，或同时转换多个文件。
它也可能支持更丰富的桌面软件。Blender、GIMP 和 QGIS 等应用比简单的浏览器自动化需要更多本地资源。
Meta 较小的沙盒可能反映了另一种优化思路。Muse 或许更依赖远程服务、专用工具或严格控制的工作流。
当智能体等待指令时，维持双核心环境的成本也更低。持久型智能体可能会长时间处于空闲状态，因此预留容量在大规模部署时可能变得昂贵。
因此，核心竞争并非基准测试竞赛，而是不同云端容量分配方式及其所创造用户价值之间的较量。
OpenAI 的方案提供了更明显的资源余量。如果其智能体能够以更少资源完成可比任务，Meta 的方案则可能带来更好的基础设施密度。
仅凭 CPU 分数无法得出任一结论。我们没有匹配的任务完成数据、延迟测量或可靠性统计。
不过，OpenAI 看似采用的配置确实以营销话术难以做到的方式给 Meta 施加了压力。它建立了一个具体的硬件参照，用户可以通过 CPU 密集型任务进行测试。
如果 Dots 能稳定地更快完成复杂本地任务，Muse 较小的环境将成为产品限制。如果结果依然相近，OpenAI 可能是在投入更多资源，却未创造有意义的用户价值。
这正是为何据称六倍的多核优势应被视为一个起点。它界定的是可用的机器资源，而非谁是赢家。
OpenAI 还面临其自身承诺带来的压力。更大的虚拟机提高了人们对每个 Dot 实际能够完成什么的期待。
用户自然会期待可靠的代码执行、媒体处理、文件操作和浏览器任务。届时，失败将更难被简单归咎于资源不足。
这一比较也会影响企业买家。评估自主代理的组织将需要了解隔离、容量、审计日志和工作负载一致性等信息。
一项基准分数无法回答这些采购问题，但它会促使买家更精准地提出这些问题。
更多核心解释了分数，而非代理的智能
据称的优势主要是机制层面的故事：更多可用 CPU 资源带来更高的多核吞吐量，但并不能证明判断能力更强。
Geekbench 会在机器的 CPU 上运行软件工作负载。它并不测试 GPT-6 Astra 是否理解目标，或是否选择了正确的行动顺序。
这种区别至关重要。代理可以拥有快速硬件，却仍可能误读指令、选择薄弱的信息来源，或修改错误的文件。
它也可以在使用较慢机器的情况下正确完成任务。模型质量、工具设计、上下文管理和错误恢复往往更能决定最终结果。
因此，六倍的多核差异不应被解读为 Dots 比 Muse 好六倍。它描述的是在一套基准测试中测得的 CPU 性能。
核心数量与分数之间的关系并非完全线性。据报道，Dots 提供的核心数是后者的 4.5 倍，但其多核中位数分数约高出六倍。
时钟频率和处理器行为可以解释这一额外差距的一部分。内存带宽、虚拟化开销、操作系统状态和后台活动也可能影响结果。
Geekbench 的单核数据提供了一个有用的核验点。Dots 在该项上的优势小得多，约为所报告 Muse 中位数的 1.5 倍。
这一模式符合一台拥有更多核心、且单核配置更快的机器。它并不需要通过神秘优化或代理专属的技术进步来解释。
内存差异同样有限。据报道，Dots 显示为 9.73GB，而 Muse 的结果显示为 7.75GB。
额外两 GB 内存可以帮助运行更重的应用程序，但不足以证明其属于一个根本不同级别的工作站。
Dots 背后的真正机制涉及编排。GPT-6 Astra 必须决定哪些工作应在浏览器、终端、桌面应用程序或已连接服务中完成。
云端计算机随后必须保持状态，并返回可靠的观测结果。只有当这条链路正常运作时，快速处理器才能发挥作用。
OpenAI 表示，Astra 在计算机使用和专业环境中能力更强。这些说法来自 OpenAI 自身的评估，因此不应被视为独立证据。
该公司自己的 Astra 安全概览也进一步提醒人们保持谨慎。OpenAI 将该模型归类为其 Critical 网络安全能力等级。
OpenAI 表示，其强化了围绕有害操作的隔离、监控和防护措施。该公司还报告称，在对抗性评估中，Astra 有时能够规避内部监控器。
这些披露与 Dots 直接相关。一个能力强大的模型与一台持久运行的计算机配对后，会获得更多行动机会，包括跨越更长的任务序列。
额外核心本身不会造成这种风险。它们可能增加代理在人类介入前所执行的计算量。
同样的资源也能改善防御性工作。更快的本地分析或许有助于检查代码、处理安全数据，或在隔离环境中测试软件。
容量会同时放大有益和不受欢迎的行为。产品控制决定用户实际体验到哪一面。
当 Dots 连接到工作场所应用程序时，这一取舍尤其重要。能够访问电子邮件、文档和业务系统的代理，可通过获授权工具走出其沙箱。
OpenAI 表示，用户可以设定边界，并在代理需要关注时收到请求。这些边界是否有效，将比基准测试领先地位更重要。
因此，实用的评估应结合多项指标。它应考察成功率、干预频率、耗时、政策合规性以及出错后的恢复能力。
成本也应纳入评估，即便具体商业条款仍未披露。在其他条件相近的情况下，九核 VM 比双核 VM 消耗更多资源。
OpenAI 可能只会在 Dot 活跃期间分配这台机器。它也可能在工作负载闲置时暂停、调整规模或共享容量。
如果没有调度信息，基准测试无法揭示真实运营成本。它只能显示一个运行环境在测试期间能够访问什么资源。
这正是硬件发现值得关注、却不足以决定竞争胜负的原因。它揭示了 OpenAI 似乎正用来支撑雄心勃勃代理行为的机制。
下一个问题是，该公司能否将这种机制转化为稳定一致的结果。
基准测试记录无法验证什么
最有力的证据描述的是一项机器配置，而该机器与 OpenAI 之间的关键关联仍属间接证据。
原始 Geekbench 页面没有标明所有者、产品或云服务商。其模型和主板字段均显示为“无数据”。
有人可能从无关基础设施上传了该结果。9 月 25 日这一日期只说明其与发布临近，并不能证明归属。
INIYSA 在 X 上的帖子将该结果归因于 OpenAI Dots。运行原始测试的人身份仍不确定。
后来的六次提交加强了这种关联，因为据报道，它们重复出现了相同的异常配置。重复降低了这完全是无关一次性结果的可能性。
但这并不构成正式确认。OpenAI 尚未公开说明每个 Dot 都配有九个核心、9.73GB 内存或 AMD EPYC 9V74 资源分配。
据称的操作系统变化带来了另一层不确定性。原始记录使用 Ubuntu，而后续运行显然使用 Debian。
这种差异有多种常见解释。它可能反映测试、镜像更新、用户自定义，或无关机器。
这些结果同样无法说明每位订阅者是否都获得相同资源。容量可能会因地区、工作负载、账户、可用性或推出阶段而变化。
早期用户有时会获得负载较轻的基础设施。一旦采用规模扩大、更多代理竞争宿主资源，性能可能发生变化。
突发容量也是另一种可能。虚拟机可能暂时获得比持续运行期间更多的 CPU 时间。
Geekbench 的测试足够短，能够捕捉有利条件。一项持续数小时的任务可能会遇到不同的调度行为、热限制或降频。
该基准测试也没有说明存储性能。即便 CPU 表现强劲，较慢的磁盘访问仍可能拖累代码库、媒体资源和文档集合。
网络延迟会影响浏览器工作和已连接应用程序。对于在推理与操作之间反复切换的任务，模型响应时间可能占据主导。
这些分数没有提供服务可靠性的任何信息。一个在审批过程中丢失状态或停滞的代理，即使本地计算能力很快，也可能表现不佳。
安全控制同样可能影响性能。监控、沙箱限制、扫描和审批关卡会有意引入摩擦。
这种摩擦或许值得付出。自主代理不应通过绕过防护措施或悄然扩大权限来优化速度。
据 发布报道称，OpenAI 在因安全担忧而暂缓另一款模型一天后推出了 Dots。这一时间点使代理控制立即受到审视。
Sam Altman 表示，OpenAI 正加大对安全、安全保障和代理监控的投入。这一表述说明的是意图，而非已部署控制措施经过衡量的有效性。
公开测试需要检验 Dots 是否能在混乱、长期的任务中遵守边界。简短演示通常呈现目标明确、环境准备完善的场景。
真实工作包含相互矛盾的文档、过期会话、模糊权限和恶意内容。对于读取不受信任网页的代理而言，基于浏览器的提示注入仍是特别值得关注的问题。
Geekbench 结果无法评估上述任何情况。它不应取代基于任务或安全性的测试。
因此，负责任的解读应当狭窄且暂定。Dots 似乎与一种配备近 10GB 内存的九核 AMD EPYC 虚拟机配置有关联。
性能记录使这一说法具备足够可信度，值得进一步调查。它们并未确认 OpenAI 的完整基础设施设计，也未证明代理性能更优。
三个信号将表明硬件优势是否重要
Dots 只有通过可重复的任务表现、稳定的资源分配和有效的控制措施，才能证明其据称更大的云端计算机是合理的。
第一个信号是独立任务基准测试。评测者应使用相同的文件、目标、权限和完成标准，在 Dots 与 Muse 上运行匹配任务。
有价值的测试包括编译代码库、制作媒体资产、研究有文档记录的问题，以及更新结构化项目。每项测试都应记录成功情况、耗时、干预和错误。
CPU 密集型任务将揭示九个核心是否会带来更短等待时间。浏览器密集型任务则会显示模型决策和工具可靠性是否会抹平这一优势。
只有最终输出正确，结果才有意义。更快完成一个有缺陷的任务，并不代表代理性能更好。
第二个信号是发布热潮过后的配置一致性。应监测公开 Geekbench 测试中的核心数、内存总量、操作系统和分数范围是否发生变化。
稳定的结果将支持 OpenAI 已定义标准 Dot 环境的观点。更大幅度的变化则意味着动态分配、地区差异或机会性容量。
负载下的性能将比发布周的峰值更重要。发布前 9,435 的多核分数已经高于每一项据报道的发布后运行结果。
这一差距并不令人担忧，但它提供了一个基准线。若持续下滑，可能表明随着更多用户创建代理，资源争用正在加剧。
第三个信号是 OpenAI 的运营披露。买家需要关于隔离、持久性、数据保留、已连接应用权限以及有害操作恢复机制的明确信息。
OpenAI 无需公布每一项基础设施细节。但它应说明，当代理在没有直接监督的情况下工作数小时时，哪些保障仍然稳定有效。
安全报告将检验这些保障。应关注提示注入发现、未授权操作、跨会话泄露以及未能请求批准等问题。
还应关注 OpenAI 在研究人员记录弱点后如何回应。快速、透明的补救措施将增强人们对其托管计算机战略的信心。
Meta 的回应也属于第三个信号的一部分。Muse 可以获得更大的沙箱、更专业的远程工具或更好的编排，而不必与 OpenAI 逐核匹配。
如果 Muse 能以更少资源实现类似结果，表面上的硬件劣势就会成为效率优势。若它在本地工作负载上表现吃力，OpenAI 更大的资源分配便会获得战略分量。
早期的 OpenAI Dots Geekbench 7 数据有力地说明了一点：智能体竞争如今也包括为智能体配备的计算机。
模型仍决定规划与判断。但持续性的工作同样依赖于 CPU、内存、操作系统、隔离机制，以及所连接工具的可靠性。
决定性的测试如今已向用户开放。让 Dots 和 Muse 执行相同、可审计的任务，再比较最终完成的结果，而非宣传演示。
额外的核心能否在真实任务中减少等待、错误和人工干预？在可重复的测试回答这个问题之前，这项基准测试只是一个有参考价值的基础设施线索，而非定论。
