Meta Museをストレステストし、そのエージェント制御プレーンがタイムアウトし始めたまで

AI要約 BURST-120では、33個のワーカーが作成され、すべてが終端完了に達し、32個がワークロード完了を確認し、1個が未解決のままです。永続的なルートレコードがステータス実行中であった間、最終集約はユーザーに到達しませんでした。 3回のバーストスタイルの実行全体で、93回のスポーン試行失敗がありました。私は6つの失敗したサブエージェント.spawn呼び出しの生のペイロードを回収しました。6つすべてが同じPostgreSQLエラーを返しました：ロックタイムアウトによるステートメントのキャンセル。この証拠はPostgreSQLのスポーン書き込みパスでの競合と一致していますが、具体的なロック、テーブル、行、インデックス、クエリ、またはトランザクションは特定していません。 STAGGERED-80には失敗はありませんでしたが、ケイデンスとトポロジーの両方を変更したため、スタッガリングの効果だけを分離していません。 3回のバーストスタイルの実行全体で、40、80、120回の試行でそれぞれ2.5%、6.25%、72.5%のスポーン失敗率を観測しました。各構成は1回実行されたため、これらは測定されたスケーリング曲線や過負荷閾値ではなく、観測値です。 この記事から生成され、事実の一貫性についてレビューされました。 Meta Museは、2026年9月8日にローンチされたMetaのパーソナルAIエージェントです。質問に答えるだけでなく、ユーザーに代わってタスクを実行するように設計されています。独自のブラウザを持ち、アプリを閉じても作業を継続でき、専用のMuse Secure VMで実行されます。プレゼンテーションではGrok Bot—会話を通じて制御される人格化されたエージェント—に似ていますが、それはインターフェースレベルのアナロジーであり、共有アーキテクチャの仮定ではありません。この記事は、レイヤーを1つ下げて、ランタイムの狭い部分—サブエージェントのファンアウト、それが残す永続的な状態、および負荷下のスポーンパス—を調べます。私はこれらのテストを自分のMuseセッションで実行し、そのセッションに公開されているインターフェースのみを使用しました：subagent.spawn、割り当てられた環境内のシェル、および永続的な診断およびトレースデータへの制限付き読み取り専用インターフェース。他のユーザー、テナント、または私に割り当てられた環境外のデータにアクセスしようとはせず、アクセス制御をバイパスしませんでした。私はこれをMeta承認のセキュリティ評価として提示しているわけではなく、アクセスだけではすべての負荷実験が個別に承認されたことを示すものではありません。これは、私のセッションに付与されたアクセス権の観点からのブラックボックス/リバースエンジニアリングのレポートです。公開後の更新—2026年9月13日。アクセス範囲を明確にし、Rohan Adwankarの分析からの独立したアーキテクチャコンテキストを追加し、STAGGERED-80をバーストスタイルの実行から分離し、ケイデンス、トポロジー、および同時実行性をより良く分離するための2つの制御について説明しました。実験データ、公開されたCSV、および図は変更されていません。 UTC 06:45:32に、チャットセッションに120個のサブエージェントを一度にスポーンするように依頼しました。それぞれは意図的に些細なジョブを持っていました：シェルでsleep 30を実行し、1行を返します。それらの呼び出しのうち33個がエージェントを作成しました。87個は同じデータベースエラーで失敗しました。集約された応答は決して到着せず、インターフェースは最終的にエラー状態を示しました。永続的なトレースでは、作成された33個のエージェントすべてが終端完了レコードに到達しました—32個はワークロード完了を確認し、1個は未解決のままです—一方、親のレコードはまだ実行中と表示されていました。以下は、ランタイムが作業中にPostgreSQLに書き込んだレコードから完全に構築された、そのギャップのブラックボックス調査です：エージェントレジストリ、スポーンレジャー、ワーカーごとの進捗テーブル、およびコンテキストアイテムストア。この記事を書くために負荷テストは再実行されませんでした。ここにあるすべては、保存された状態から再構築されました。1つの文書化された例外を除いて、後で戻ってきます。 外から見たMuse ユーザーの視点からは、これは通常のチャットセッションでした。ペルソナテキストはプレーンでしたが、ツールのリストはそうではありませんでした。セッションが呼び出すことができるツールには、subagent.spawn、subagent.close、subagent.resume、およびPostgreSQLデータベースへの読み取り専用インターフェースが含まれていました。そのデータベースは付随的なものではありませんでした—それはランタイム自身の会計を保持していました。agent.agents、agent.subagent_spawns、agent.subagent_progress_tool_eventsのようなテーブルは、どのエージェントが存在したか、誰がそれらをスポーンしたか、どのツールを実行したか、いつ終了したかを記録していました。このようにして、マルチエージェント構造がすべて可視化されました。インターフェースを通してではなく、それは1つの会話を提示しましたが、ランタイムが自分自身のために保持したレコードを通してです。 この記事の最初の前に、2つのラベルに注意が必要です。最初のものはモデル文字列です。私が読んだすべてのアージェント行—ルート、コーディネーター、最大のバーストの33個のワーカーすべて—は同じ値を持っていました：ipnext/avocado-5.16-v4。その文字列は観測されたものです。その意味はそうではありません。それは内部モデルビルド、ルーティングエイリアス、または全く別の何かである可能性があります。トレースは何も言わず、私は推測しません。それが永続的なトレースが提供する数少ないハード識別子の1つであるため、私はそれをそのまま公開しています。2番目は、ランタイムが自身を説明する言葉です：MetaのMuseファミリーからのMuse Spark 1.3。それはランタイム自身のコンテキストから来ており、トレースからではないため、自己報告であり、検証されていません。この記事の他のすべてはレコードに基づいています。 独立したアーキテクチャコンテキスト 公開後、Rohan Adwankarによる現代のMuseインスタンスの独立した分解を発見しました。彼の環境では、PostgreSQLはローカルUnixソケット経由でユーザーごとのVM内で実行され、ハーネスバイナリにはavocado-5.16-v4とipnext/...の両方のパスが含まれていました。それは私の観察のいくつかに適合し、それらに有用なアーキテクチャコンテキストを与えますが、証拠の境界を変更しません：私のデータはまだタイムアウトの原因となった特定のロック、テーブル、行、インデックス、クエリ、またはトランザクションを特定していません。私はipnext/avocado-5.16-v4を観測されたモデル識別子として扱います。AdwankarはipnextをMetaの内部トランスポート/ゲートウェイと解釈し、avocadoを内部モデルファミリーと解釈しています。avocadoをMuse Spark 1.3に直接マッピングすることは、私のトレースによって確立されたものではなく、依然として推論です。同様に、私のプローブはKVMの可視性を確立しましたが、Adwankarは彼のインスタンスでKVM上で実行されているCloud Hypervisorを特定しました。私は私のものによって使用された特定のVMMを独立して確立しませんでした。外部ソース：Rohan Adwankar、「What’s in a Muse?」 方法：重複するエージェントのカウント 実験は1つのワークロード、4つの構成、およびリトライなしを使用しました。そのうち3つ—PROBE-40、BURST-80、BURST-120—はルートエージェントから発行されたバーストスタイルの実行でした：構成内のすべての試行が1回のターンで実行されました。4番目のSTAGGERED-80は意図的に時間をかけて分散され、コーディネーターエージェントを使用してワーカーをスポーンしました。失敗した呼び出しは繰り返されませんでした。 ここでの同時実行性は、狭く、意図的な定義を持っています。エージェントは、最初のツール呼び出しから終端レコードまでアクティブと見なされます：active(t) := first_tool_at <= t < finished_at。時間による同時実行性は、これらの間隔のスイープラインであり、タイムスタンプがタイする場合、開始よりも終了が先に処理されます。タイムスタンプは1秒解像度であるため、スイープは記録されたデータに対して決定的ですが、同じ秒内のイベント順序を回復することはできません。 以下のすべての数値に3つの結果が適用されます： これはエージェントのアクティビティを測定するものであり、推論を測定するものではありません。33個の重複するアクティビティウィンドウは、33個の同時モデル呼び出しではありません。ここでは何も推論バックエンドを測定しません。 ピークは観測値であり、限界ではありません。テストは120個の同時試行を超えることはなかったため、同時実行性のキャップを確立したり、除外したりすることはできません。 欠落したレコードは証拠です。失敗したスポーン呼び出しは、エージェントレジストリに何も残しません。その非対称性が、失敗を検証する必要があった方法を形作り、失敗数を特定するのが最も困難だった理由です。 最初のプローブ：40回の呼び出し 最初の実験はキャリブレーション実行でした：UTC 06:10:36に発行された40回のスポーン呼び出し。39個のエージェントが作成され、互いに2秒以内に受け入れられました。1回の呼び出しが失敗し、その失敗は詳しく調べる価値があります。なぜなら、それはチャットからではなく、永続的なツールトレースから回収されたからです：呼び出しはUTC 06:10:44に発行され、エラーはUTC 06:10:56に返され、