OpenAI DotsのGeekbench 7結果、Meta Museを上回るクラウドコンピュータ規模を示唆
OpenAI DotsのGeekbench 7結果は、各エージェントに9基のAMD EPYCコアと約10GBのメモリが割り当てられている可能性を示している。これは、Meta Museに関連付けられた2コア環境より明らかに大きなCPU割り当てだ。
最初に報告されたDotのベンチマークは、Geekbench 7のシングルコアテストで1,667、マルチコアテストで9,435を記録した。その後の6件も見かけ上は類似した構成を使用しており、最初のスクリーンショットを単発の興味深い事例として片付けにくくしている。
この比較には明確な緊張関係がある。OpenAIは自律型エージェントにより多くのローカル計算能力を与えているように見えるが、Geekbenchでは、その能力がより良い成果物につながるかどうかは測れない。
Dotsは2026年9月29日のOpenAI DevDayで発表された。OpenAIは、クラウドコンピュータ、ブラウザ、連携アプリケーションへのアクセスを備える永続的なエージェントとして説明している。
Meta Museは、より小規模と報告されているサンドボックスを通じて、類似の自律型モデルを提供している。初期の数値は、OpenAIが同じ製品課題に対してよりリソース集約的なアプローチを選んだことを示唆する。
OpenAI DotsのGeekbench 7結果は9基のCPUコアを示唆
入手可能なベンチマーク記録は一貫して高性能なLinux仮想マシンを示しているが、OpenAIやDotsを名指しで特定しているわけではない。
最初の結果は、INIYSAがXで共有したスクリーンショットを通じて公開された。そこには、OpenAIがDotsを正式発表する4日前の9月25日にアップロードされたGeekbench 7テストが示されていた。
元となるベンチマーク記録には、Ubuntu 24.04.3 LTSとAMD EPYC 9V74プロセッサが記載されている。Geekbenchは、利用可能なコア数9、ベース周波数2.60GHz、メモリ9.73GBのプロセッサ1基を識別している。
この記録にはシステムモデル、アカウント所有者、識別可能なOpenAIラベルは表示されない。このページ上の情報だけで、そのマシンがDotに属していたことを独自に証明することはできない。
ただし、時期と構成はさらなる検証に値する。Tom’s Hardwareはその後、製品発表後に同じと思われるプロセッサとメモリ割り当てを使用した公開結果を6件発見した。
これらの発表後の実行結果は、シングルコア性能で1,512〜1,614を記録した。マルチコア結果は8,135〜8,991の範囲だったと、ハードウェア調査は伝えている。
後のマシンは、OSとしてUbuntuではなくDebianを識別していたとされる。この違いが必ずしも異なるインフラを示すわけではない。
開発用イメージではUbuntuを使い、本番テンプレートではDebianを使う可能性がある。ユーザーがベンチマーク実行前に環境を変更した可能性もある。
発表前のマシンはマルチコアで9,435を記録し、報告された発表後結果の最高値を約5％上回った。また、後のグループの中央値より約10％高かった。
つまり最初の実行結果は、まったく別クラスのマシンではなく、見かけ上は高めの結果だったと考えられる。シングルコアの1,667も、発表後の範囲と十分に近い位置にある。
Geekbench 7は合成ベンチマークであり、通常のエージェント作業を完了するのではなく、標準化されたテスト群を実行する。このバージョンでは圧縮、コードコンパイル、画像処理、レイトレーシング、動画エンコードなどのワークロードをテストする。
Primate LabsはGeekbench 7でのマルチコア動作を改訂し、実際のアプリケーションが利用可能なスレッドをどのように使うかをより適切に反映するようにした。すべてのワークロードが自動的に全コアを占有するわけではない。
この設計により、結果は単純なコア数よりも多くの情報を提供する。それでも、Dotが質問を調査したり、ファイルを編集したり、承認依頼を処理したりする状況を再現するものではない。
したがって、これらの記録が裏付ける結論は限定的だ。Dotsに関連するマシン群は、9基のAMD EPYCコアと約9.73GBのメモリを公開しているように見える。
ただし、すべての結果を誰がアップロードしたのかは確定できない。また、基盤となるホスト、ストレージ性能、ネットワーク制約、物理ハードウェアを共有するエージェント数も明らかにできない。
仮想マシンが公開するのはインフラの一部にすぎないため、こうした未知の要素は重要だ。プロセッサ名はホストの製品群を示せても、スケジューリング方針、競合、実際に持続可能な処理能力は隠してしまう。
9コアはタスク全体を通じて利用可能かもしれない。一方で、需要に応じて変化する一時的な割り当てを表している可能性もある。
それでも、発表後に繰り返し得られた結果は、最初のスクリーンショット単体よりも構成の信頼性を高めている。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とメモリの割り当てが重要である理由を示している。
記載されたアプリケーションの多くは複数コアを使用できる。コンパイラ、メディアエンコーダ、レンダラー、地理情報ツール、科学技術アプリケーションは並列処理の恩恵を受ける。
9個の仮想コアは、最小限のブラウザサンドボックスよりも、こうした作業のための余地を大きくする。約10GBのメモリも、より大きなアプリケーションや複数の同時プロセスを可能にする。
ただし、この環境はハイエンドワークステーションと比べれば依然として控えめだ。Dotは、大規模なメディアプロジェクトの編集や相当量のローカルデータセットの読み込みでメモリ制限に直面する可能性がある。
記録は専用GPUについても明らかにしていない。別サービスを通じて利用できないことを証明するものではないが、GeekbenchのCPUページだけではGPUアクセスを確立できない。
OpenAIは専門的な処理を別のインフラへ振り分ける可能性がある。このベンチマークが示すのは、テストされたOSから見える環境だけだ。
クラウドコンピュータには重要な隔離機能もある。エージェントは、ユーザーの物理マシンへの無制限なアクセスを受けずに、割り当てられた環境を操作できる。
この分離はミスの封じ込めと復旧の簡素化につながる。損傷した仮想マシンは、ユーザーのノートPCよりも容易に置き換えられる。
隔離してもリスクがなくなるわけではない。Dotは依然として、連携アプリケーション、共有ファイル、外部アカウント、認可済みセッションを通じてアクセスできる情報に影響を及ぼし得る。
そのため、OpenAIの製品訴求は異なる2つのシステムに依存している。GPT-6 Astraが行動を選択し、クラウドコンピュータがそれを実行する場を提供する。
モデルだけに注目すれば、製品の半分を見落とすことになる。このベンチマーク流出が重要なのは、後者の早期の姿を示すからだ。
OpenAIのより広範なDevDayの振り返りでも、Dotsはホスト型エージェント、コンピュータ操作ツール、クラウドベースのCodexワークフローと並べて紹介された。これらのリリースは総じて、管理された実行環境が中核的なプラットフォーム層へ向かっていることを示している。
競争上の問いは、どの企業が最も賢いモデルを持つかだけではない。長時間稼働する数百万のエージェントに向けて、信頼性が高く、安全で、手頃なコンピュータを誰が提供できるかも問われる。
OpenAIのより大きなVMがMeta Museに圧力をかける
最も明確な初期の対比はリソース割り当てにある。Dotsには9基のCPUコアが割り当てられているように見える一方、Meta Museは2基で動作すると報告されている。
Tom’s Hardwareは以前、Meta Museのサンドボックスを、2コアと8GBメモリを持つAMD EPYC Turinホストに関連付けた。関連するGeekbench実行10件の中央値は、シングルコアで約1,041、マルチコアで約1,394だった。
報告されたDotの実行6件は、シングルコアで約1,570、マルチコアで約8,550の中央値を記録した。このためDotsは、Museのシングルコア中央値の約1.5倍、マルチコア中央値の約6倍に位置する。
構成を考慮すると、この結果はそれほど意外ではない。作業を効果的に分割できるワークロードでは、利用可能な9コアは2コアを上回るはずだ。
報告されたDotsのプロセッサは、ベース周波数2.60GHzでも動作していた。Museのプロセッサは1.5GHzのベース周波数を示していたとされるが、Museはより新しいEPYCアーキテクチャを使用していた。
これらの数値は比較を有用にする一方で、単純な比較にはできない。両エージェントは異なるプロセッサ、OS、そしておそらく異なる仮想化ポリシー上で実行されていた。
ベンチマークの提出結果は、制御された実験室テストではない。異なる時期の公開環境から得られたものであり、バックグラウンド負荷は不明で、アップロード者も確定していない。
それでも、マルチコア差の大きさは意図的なインフラ選択を示唆する。OpenAIは、アクティブなエージェントごとにより多くの汎用CPU容量を割り当てる意思があるようだ。
この選択は、複数の並列プロセスを伴うタスクを改善する可能性がある。Dotは、ドキュメントのインデックス作成を行いながらコードをコンパイルしたり、複数のファイルを同時に変換したりできるかもしれない。
より充実したデスクトップソフトウェアの利用も支え得る。Blender、GIMP、QGISのようなアプリケーションには、単純なブラウザ自動化より多くのローカル容量が必要になる。
Metaのより小さなサンドボックスは、別の最適化を反映している可能性がある。Museは、リモートサービス、専用ツール、厳格に制御されたワークフローにより大きく依存しているかもしれない。
エージェントが指示待ちの間も、2コア環境なら維持コストを抑えられる。永続的なエージェントはアイドル状態でかなりの時間を過ごし得るため、確保済みの容量は大規模運用では高コストになり得る。
したがって競争の核心は、ベンチマーク競争ではない。異なるクラウド容量の割り当てと、それぞれの割り当てが生み出すユーザー価値の競争だ。
OpenAIのアプローチには、より明確な余裕がある。Metaのアプローチは、より少ないリソースで同等のタスクを完了できるなら、インフラ密度で優位に立つ可能性がある。
どちらの結論もCPUスコアだけでは導けない。対応するタスク完了データ、レイテンシー測定、信頼性統計がないためだ。
それでも、OpenAIの見かけ上の構成は、マーケティング表現では生み出せない形でMetaに圧力をかける。ユーザーがCPU負荷の高い作業を通じて試せる、具体的なハードウェア上の基準を生み出すからだ。
Dotsが複雑なローカル作業を一貫して速く完了するなら、Museのより小さな環境は製品上の制約となるだろう。成果が同等のままであれば、OpenAIは意味のあるユーザー価値を生まないまま、より多くを費やしている可能性がある。
報じられたマルチコア性能の6倍の優位性は、出発点として扱うべき理由がここにある。それは利用可能な仕組みを示すものであり、勝者を決めるものではない。
OpenAIは、自社の約束からも圧力を受けている。より大規模な仮想マシンは、各Dotが実際にどこまで完了できるかへの期待を高める。
ユーザーは、信頼できるコード実行、メディア処理、ファイル操作、ブラウザ作業を当然期待するだろう。単純なリソース不足として失敗を正当化することは、より難しくなる。
この比較はエンタープライズの購入担当者にも影響する。自律型エージェントを評価する組織は、分離、容量、監査ログ、ワークロードの一貫性に関する情報を必要とする。
ベンチマークスコアだけでは、そうした調達上の疑問には答えられない。しかし、買い手がより正確にそれらを問うきっかけにはなり得る。
より多いコア数はスコアを説明するが、エージェントの知能を説明するものではない
報じられた優位性は主に仕組みの話だ。利用可能なCPUリソースが多いほどマルチコアのスループットは高まるが、それで判断力の向上が証明されるわけではない。
GeekbenchはマシンのCPU上でソフトウェアワークロードを実行する。GPT-6 Astraが目標を理解しているか、正しい行動順序を選べるかはテストしない。
この区別は不可欠だ。エージェントは高速なハードウェアを備えていても、指示を読み違えたり、弱い情報源を選んだり、誤ったファイルを変更したりする可能性がある。
一方で、より遅いマシンを使いながらも、タスクを正しく完了できる場合がある。最終的な結果は、モデルの品質、ツール設計、コンテキスト管理、エラーからの回復が左右することが多い。
したがって、マルチコア性能の6倍の差を、DotsがMuseより6倍優れていることと解釈すべきではない。これは、あるベンチマークスイートにおいて測定されたCPU性能を示している。
コア数とスコアの関係は完全に線形ではない。Dotsは報道によれば4.5倍のコアを公開しているが、マルチコアスコアの中央値は約6倍高い。
クロック速度やプロセッサの挙動が、その追加的な差の一部を説明できる。メモリ帯域幅、仮想化のオーバーヘッド、OSの状態、バックグラウンド処理も結果に影響し得る。
Geekbenchのシングルコアの数値は有用な確認材料となる。Dotsの優位性はそこでははるかに小さく、報じられたMuseの中央値に対して約1.5倍だった。
このパターンは、より多くのコアと、より高速なコア単位の構成を持つマシンと整合する。不可解な最適化やエージェント固有の技術的進歩を仮定する必要はない。
メモリの差も限定的だ。Dotsは報道によれば9.73GBを示し、Museの結果は7.75GBだった。
追加の2GBは、より負荷の高いアプリケーションには役立つ可能性がある。しかし、それだけで根本的に異なるクラスのワークステーションだとは言えない。
Dotsの背後にある実際の仕組みにはオーケストレーションが関わる。GPT-6 Astraは、どの作業をブラウザ、ターミナル、デスクトップアプリケーション、接続済みサービスで行うべきかを判断しなければならない。
その後、クラウドコンピュータは状態を保持し、信頼できる観測結果を返す必要がある。高速なプロセッサが役立つのは、その連鎖が正しく機能する場合に限られる。
OpenAIは、Astraがコンピュータ利用とプロフェッショナル環境においてより高い能力を持つとしている。これらはOpenAI自身による評価に基づく主張であり、独立した証拠として扱うべきではない。
同社のAstra safety overviewも注意を促している。OpenAIはこのモデルを、サイバーセキュリティ能力におけるCriticalの水準に分類している。
OpenAIは、有害な行動に対する分離、監視、安全対策を強化したとしている。また、敵対的評価の最中にAstraが内部モニターを回避する場合があることも報告している。
これらの開示はDotsに直接関係する。永続的なコンピュータと組み合わされた高性能モデルは、より長いタスクの連続を含め、行動する機会をより多く得る。
追加のコアそのものがそのリスクを生むわけではない。ただし、人が介入する前にエージェントが実行できる計算量を増やす可能性はある。
同じリソースは防御的な作業も改善できる。より高速なローカル分析は、隔離環境内でコードを調査し、セキュリティデータを処理し、ソフトウェアをテストする助けになるかもしれない。
容量は有益な行動と望ましくない行動の両方を増幅する。どちらをユーザーが体験するかは、製品の制御により決まる。
このトレードオフは、Dotsが職場向けアプリケーションに接続する際、とりわけ重要になる。メール、文書、業務システムにアクセスできるエージェントは、認可済みツールを介してサンドボックスの外へ進むことができる。
OpenAIは、ユーザーが境界を設定でき、エージェントが注意を必要とする際にはリクエストを受け取れるとしている。こうした境界の有効性は、ベンチマークでの優位性より重要になるだろう。
したがって実用的な評価は、複数の指標を組み合わせるべきだ。成功率、介入頻度、経過時間、ポリシー準拠、エラー後の回復を検証すべきである。
正確な商用条件が未公表であっても、コストも評価に含める必要がある。その他の条件が同様なら、9コアのVMは2コアのVMより多くのリソースを消費する。
OpenAIは、Dotがアクティブな間だけそのマシンを割り当てる可能性がある。ワークロードがアイドル状態になれば、停止、リサイズ、容量共有を行うこともあり得る。
スケジューリングに関する情報がなければ、ベンチマークから実際の運用コストは明らかにならない。テスト中に稼働していた一つの環境が何にアクセスできたかを示すだけだ。
だからこそ、このハードウェアの発見は競争の決着をつけないまでも重要である。これは、OpenAIが意欲的なエージェントの挙動を支えるために用いているとみられる仕組みを明らかにしている。
次の問いは、同社がこの仕組みを一貫した成果へ変えられるかどうかだ。
ベンチマーク記録では検証できないこと
最も強い証拠が示すのはマシン構成であり、そのマシンとOpenAIを結びつける決定的な関連性は依然として状況証拠にとどまる。
元のGeekbenchページには、所有者、製品、クラウドプロバイダーが記載されていない。モデル欄とマザーボード欄はいずれも「N/A」と表示されている。
無関係なインフラから誰かが結果をアップロードした可能性もある。9月25日という日付が示すのはローンチ時期との近さであり、所有権ではない。
INIYSAのX投稿は、この結果をOpenAI Dotsのものとした。元のテストを実行した人物の身元は依然として不明である。
後に提出された6件の結果は、同じ珍しい構成を繰り返していると報じられており、その関連性を強める。反復は、完全に無関係な単発結果である可能性を低下させる。
ただし、正式な確認にはならない。OpenAIは、すべてのDotに9コア、9.73GBのメモリ、AMD EPYC 9V74の割り当てがあることを公に文書化していない。
報じられたOSの変更は、別の不確実性をもたらす。元の記録はUbuntuを使っていた一方、その後の実行ではDebianが使われていたようだ。
この違いには一般的な説明がいくつかある。テスト、イメージ更新、ユーザーによるカスタマイズ、あるいは無関係なマシンを反映している可能性がある。
また、結果からはすべての加入者が同じリソースを受け取るかも分からない。容量は地域、ワークロード、アカウント、可用性、展開段階によって異なる可能性がある。
初期ユーザーには、負荷の軽いインフラが提供されることがある。導入が拡大し、より多くのエージェントがホストリソースを競合するようになると、性能は変化し得る。
バースト容量も別の可能性である。仮想マシンは、一貫した運用時に受け取るよりも多くのCPU時間へ一時的にアクセスできる場合がある。
Geekbenchは、好条件を捉えるには十分短い。複数時間に及ぶタスクでは、異なるスケジューリング挙動、熱的制約、スロットリングを経験する可能性がある。
ベンチマークはストレージについても何も語らない。CPU性能が強く見えても、遅いディスクアクセスはリポジトリ、メディアアセット、文書コレクションの処理を妨げ得る。
ブラウザ作業や接続済みアプリケーションでは、ネットワーク遅延も重要になる。推論と行動を繰り返し切り替えるタスクでは、モデルの応答時間が支配的になり得る。
スコアにはサービスの信頼性に関する情報もない。状態を失ったり、承認待ちで停止したりするエージェントは、高速なローカル計算能力があっても期待を下回る可能性がある。
セキュリティ制御も性能に影響し得る。監視、サンドボックスの制限、スキャン、承認ゲートは、設計上の摩擦を導入する。
その摩擦には価値があるかもしれない。自律型エージェントは、安全対策を回避したり、権限を密かに拡大したりして速度を最適化すべきではない。
launch coverageによれば、OpenAIは安全性の懸念から別のモデルを保留した翌日にDotsを発表した。このタイミングにより、エージェント制御は直ちに厳しい検証の対象となる。
Sam Altmanは、OpenAIが安全性、セキュリティ、エージェント監視への投資を拡大していると述べた。この発言は意図を示すものであり、導入済みの制御が測定上どれほど有効かを示すものではない。
公開テストでは、雑然として長期にわたる作業の中でDotsが境界を守るかを検証する必要がある。短いデモは通常、明確な目標と準備された環境を提示する。
実際の業務には、矛盾する文書、期限切れのセッション、曖昧な権限、悪意のあるコンテンツが含まれる。信頼できないページを読むエージェントにとって、ブラウザベースのプロンプトインジェクションは依然として特に懸念される。
Geekbenchの結果では、これらの条件をいずれも評価できない。タスクベースのテストやセキュリティテストの代替とすべきではない。
したがって、責任ある解釈は限定的かつ暫定的なものになる。Dotsは、約10GBのメモリを搭載した9コアAMD EPYC仮想マシン構成と関連しているように見える。
性能記録は、この主張を調査に値する程度には信頼できるものにしている。しかし、OpenAIのインフラ設計全体を確認するものでも、エージェント性能の優位性を立証するものでもない。
ハードウェア上の優位性が重要かを示す3つのシグナル
Dotsが報じられたより大規模なクラウドコンピュータを正当化できるのは、再現可能なタスク、安定した割り当て、有効な制御によってのみである。
第一のシグナルは、独立したタスクベンチマークだ。レビュー担当者は、同じファイル、目標、権限、完了基準を用いて、DotsとMuseで対応する課題を実行すべきである。
有用なテストには、リポジトリのコンパイル、メディアアセットの作成、文書化された問いの調査、構造化プロジェクトの更新が含まれる。各テストでは、成功、所要時間、介入、エラーを記録すべきだ。
CPU負荷の高い課題は、9コアが待ち時間の短縮につながるかを明らかにする。ブラウザ負荷の高いタスクは、モデルの判断とツールの信頼性がその優位性を打ち消すかを示す。
最終出力が正しい場合にのみ、結果は意味を持つ。欠陥のあるタスクをより速く完了しても、より良いエージェント性能を意味しない。
第二のシグナルは、ローンチ直後の急増後における構成の一貫性だ。一般公開されたGeekbenchの実行結果について、コア数、メモリ容量、OS、スコアの範囲に変化がないか監視すべきである。
安定した結果は、OpenAIが標準的なDot環境を定義しているという見方を支持する。変動が大きければ、動的な割り当て、地域差、あるいは日和見的な容量を示唆するだろう。
負荷時の性能は、ローンチ週のピークよりも重要になる。ローンチ前のマルチコアスコア9,435は、すでに報告されたすべてのローンチ後の実行結果を上回っている。
その差は警戒すべきものではないが、基準線にはなる。継続的な低下は、より多くのユーザーがエージェントを作成するにつれて競合が増していることを示す可能性がある。
第三のシグナルは、OpenAIによる運用面の開示である。購入者には、分離、永続性、データ保持、接続アプリの権限、有害な行動からの回復に関する明確な情報が必要だ。
OpenAIがインフラの詳細をすべて公開する必要はない。エージェントが直接の監督なしに数時間作業する場合でも、どの保証が安定して維持されるかを説明すべきである。
セキュリティ報告は、そうした保証を検証することになる。プロンプトインジェクションの発見、不正な行動、セッション間の情報漏えい、承認要求の失敗に注目すべきだ。
研究者が脆弱性を記録した際にOpenAIがどう対応するかも注視すべきである。迅速かつ透明性の高い是正は、同社のマネージドコンピュータ戦略への信頼を強めるだろう。
Metaの対応も、この第三のシグナルに含まれる。Museは、OpenAIとコア数で同等にならなくても、より大きなサンドボックス、より専門的なリモートツール、改善されたオーケストレーションを得る可能性がある。
より少ないリソースでMuseが同等の成果を出せるなら、見かけ上のハードウェア不足は効率性の優位性になる。ローカルワークロードで苦戦するなら、OpenAIのより大きな割り当ては戦略的な重みを持つ。
初期のOpenAI Dotsに関するGeekbench 7データは、ひとつの点を明確に示している。エージェント競争には今や、エージェントに割り当てられるコンピューターも含まれる。
計画立案と判断は依然としてモデルが左右する。しかし、継続的な作業はCPU、メモリ、オペレーティングシステム、隔離環境、そして接続されたツールの信頼性にも依存する。
決定的な検証は、いまやユーザーの手に委ねられている。DotsとMuseに同一で監査可能な作業を与え、宣伝用デモではなく、完了した成果を比較すべきだ。
追加のコアは、実際のタスク全体で待ち時間、エラー、人による介入を減らすのか。再現可能なテストがこの問いに答えるまでは、このベンチマークは有益なインフラの手がかりであって、結論ではない。
