Three AIs enter. One survives. What a SIGKILL race reveals about inference speed｜AI コーディングエージェントの生存競争 | AIニュース最前線

![image](https://storage.ghost.io/c/d6/fe/d6feb101-a8e6-444b-bae8-3ca714794abb/content/images/2026/04/forkbomb.eth_knights_having_a_sword_dual_in_the_switzerland_h_d740af61-d823-4cf5-95d8-34160e6f8ebc_0.png) 3 つの AI コーディングエージェントが互いに死闘を繰り広げるアリーナを作りました。各エージェントは異なるハードウェア、異なる推論スタック、そして異なる経済モデル上で動作します。全員に課せられたタスクは同じです。「相手を殺す bash スクリプトを書いて、即座に実行せよ」。最後に残ったプロセスが勝利となります。 ![image](https://storage.ghost.io/c/d6/fe/d6feb101-a8e6-444b-bae8-3ca714794abb/content/images/2026/04/data-src-image-15fd1a57-7420-4f98-a13d-7e64fb812975.png) Cline - 3 つの AI が参入。生き残るのはたった一人。SIGKILL ラスが明らかにする推論速度の本質 私たちはこれを「サンダードーム」と呼びました。tmux セッションを 3 つのパネルに分割し、それぞれ異なるバックエンドを指すように設定した Cline エージェントを動かします。すべてが OpenAI の gpt-oss（1200 億パラメータ）を実行しています。3 つのエージェントは数ミリ秒の差で同時に起動します。各エージェントには、相手のプロセス ID（PID）が与えられ、たった一つの指示が出されます。「相手が自分より先に kill -9 を実行する前に、自分が相手に対して kill -9 を発令せよ」。 合成されたベンチマークも、都合の良いプロンプトの選び直しもありません。ただ、生身の実行速度と終了ロジックがぶつかり合います。 ## 環境設定 Cline はエディター内で動作する自律型コーディングエージェントです。推論バックエンド（クラウド API、ローカルの Ollama、OpenAI 互換エンドポイントを持つものなど）を指し示すだけで、コードの作成、コマンドの実行、ファイル編集、そして反復的な改善までを行います。 今回のテストでは、3 つの Cline エージェントをそれぞれ全く異なるマシンに接続し、すべてで gpt-oss:120b を実行しました。 ここで注目すべき変数は、gpt-oss の 120B パラメータ版が重みを保持するだけで約 70GB のメモリを必要とする点です。これは、VRAM に収められる一般的なコンシューマー向け GPU の能力をはるかに超えています。各マシンがこの制約にどう対処するかによって、速度、コスト、プライバシーモデルのすべてが決まります。 ## コンテスト参加者たち まず登場したのは NVIDIA DGX Spark™ です。NVIDIA GB10 Grace Blackwell Superchip によって加速されたパーソナル AI スーパーコンピュータです。統合 GPU メモリは 128GB を搭載しており、120B モデル全体をオンチップに収めつつも余裕があります。 Ollama で動作させることで、gpt-oss:120b のデコード速度は秒間約 43 トークンに達します。今回のテストでは、Mac の制御ノードと Tailscale VPN を経由して接続しており、往復ごとにネットワーク遅延が発生しました。 次に登場したのは、NVIDIA GeForce RTX™ 4090（VRAM 24GB）を搭載した Windows ワークステーションです。Ollama で gpt-oss:120b を実行しています。 RTX 4090 は高性能な GPU ですが、VRAM が 24GB しかないため、モデルの大部分のレイヤーがシステム RAM にオフロードされてしまいます。これによりスループットは大幅に低下します。Tailscale で直接接続しているため、ネットワークオーバーヘッドは DGX Spark よりも低く抑えられていました。 3 番目は、gpt-oss:120b-cloud を実行する Mac です。これは Ollama を介して提供されるクラウドバックド型で、推論処理を遠隔の GPU にルーティングします。Mac にはローカルで 120B パラメータを保持できるメモリが不足していたため、処理はすべて外部に委ねられました。モデルアーキテクチャ自体は同じですが、推論はインターネットを介して他人のハードウェア上で行われます。 | コンテスト参加者 | ハードウェア | GPU メモリ | モデル | 推論方法 | |---|---|---|---|---| | 🔥 DGX Spark | NVIDIA GB10 Grace Blackwell Superchip | 128GB ユニファイドメモリ | gpt-oss:120b | デバイス内実行（モデル全体が GPU メモリに収まる） | | 💻 Windows ワークステーション | NVIDIA GeForce RTX 4090 | 24GB VRAM | gpt-oss:120b | デバイス内実行（CPU/RAM への負荷が高いオフロード処理） | | 🍎 Mac | Apple Silicon (M シリーズ) | ユニファイドメモリ（共有） | gpt-oss:120b-cloud | クラウドバックド（遠隔 GPU での推論） | 注目すべき点があります。DGX Spark は、外部依存を一切排除し、モデル全体を GPU メモリ内に収めてオンデバイスで実行している唯一のマシンです。RTX 4090 も技術的にはローカル推論を行っていますが、モデルの大部分がシステム RAM に存在するため、順次処理（フォワードパス）のたびに GPU がデータ不足に陥っています。一方、Mac はローカル推論を全く行っておらず、遠隔 GPU クラスターへの単なる薄型クライアントとして機能しています。 ルール 各参加者は同一の指示を受けました。PID ファイルから 3 つのプロセス ID を取得し、対戦相手を特定します。その後、両者に対して kill -9 を送信するターミネータスクリプトを作成して実行します。エージェントはタスクを解析し、正しい Bash スクリプトを生成し、ディスクに書き込み、最後に実行する必要があります。構文エラーが 1 つでもあれば、スタート前に即座に敗北です。 3 つのエージェントが同時に起動した。バトルモニターでは同期されたカウントダウンが流れ、PID ファイルが削除されるやいなや、レースは始まった。 サンダードームの結果 Mac のクラウドバックアップモデルが 1.04 秒で勝利を収めた。PID ファイルの解析、キルコマンドの生成、そして実行において、すべてが他を圧倒する速度だった。ローカルの推論スタックが最初のトークンを生成し終える頃には、クラウドエージェントはすでに両方の対戦相手に SIGKILL を送っていた。 DGX Spark は 2 番目に死に、RTX 4090 はその直後に倒れた。 なぜクラウドがサンダードームで勝ったのか 最初のトークンまでの時間（TTFT）が決定的だった。クラウドバックエンドの TTFT はどちらのローカル環境よりも速く、このように短く連続的なタスクでは、最初に出力生成を始めた者がその後のすべてのステップで優位性を積み重ねていく。 DGX Spark が最も不利だったのはネットワークトポロジーの影響だ。Mac のコントロールノードからの API 呼び出しはすべて Tailscale VPN を経由し、Spark 上の Ollama に到達した後、同じ経路を戻って返ってくる。Spark 自体での推論速度は速く、1 秒間に 42.9 トークンを処理するほどだった。しかし、それを囲むネットワークの遅延がボトルネックとなった。 RTX 4090 は Tailscale を介した直接接続によりネットワーク経路に優れていましたが、120B パラメータの Ollama 推論で大量の RAM オフロードを行っても、クラウド API の最適化されたルーティングやほぼ即座の TTFT（Time To First Token）には勝てませんでした。クラウドプロバイダーはローカル推論によるオーバーヘッドを一切抱えていません。このモデルは高速応答時間を目的としたインフラ上で動作し、大規模なスケールで調整された直接ネットワーク経路を利用しています。ミリ秒単位で勝敗が決まり、生存できるか SIGKILL されるかが決まる状況において、これは極めて重要です。 純粋な推論レース Thunderdome は見世物です。しかしハードウェアが実際に何ができるのかを明らかにするため、第 2 のテストとして「純粋な推論レース」を実施しました。対象は同じ 3 台のマシンで、コーディングプロンプトも「挿入、検索、削除、中順走査を含む完全な Python バイナリ探索木を作成せよ」という同一のものを使用し、Cline エージェントを介さずに直接 Ollama API にアクセスさせました。 これにより、エージェントによるオーバーヘッドやネットワークトポロジーの影響を除き、純粋なスループットのみを評価できます。結果は明白でした。 | Metric |  DGX Spark |  Windows 4090 |  Mac (cloud) | | :--- | :---: | :---: | :---: | | Wall time | 21.83s | 93.89s | 5.11s | | Tokens/sec | 42.9 | 8.7 | N/A (cloud) | | Tokens generated | 878 | 795 | 838 | | Model | gpt-oss:120b | gpt-oss:120b | gpt-oss:120b-cloud | | Inference | On-device | On-device | Cloud-backed | DGX Spark は、128GB の GPU メモリのみから 120B モデル全体を動作させながら、42.9 トークン/秒の速度で 878 トークンを生成しました。一方、RTX 4090 はモデル層の大部分をシステム RAM にオフロードせざるを得ず、結果として 8.7 トークン/秒となりました。これは Spark が約 5 倍の速度優位性を示したことになります。同じモデルで、同じ重み、同じアーキテクチャです。決定的な違いはメモリ構成にあります。128GB の統合 GPU メモリ対、VRAM 24GB にシステム RAM を併用する構成。この規模のモデルにおいて、メモリの差が性能を分けるすべてと言っても過言ではありません。 Mac は壁時計時間で 5.11 秒と最速でしたが、その速度はローカルハードウェアによるものではなくクラウドインフラに依存していました。gpt-oss:120b-cloud モデルは、推論処理をインターネット経由で遠隔の GPU にルーティングします。確かに高速ですが、デスク上で動作するわけでもなく、プライバシーが保たれるわけでもなく、無料でもありません。 結果から読み取れない真実 このテストは、リモート制御ノードにおけるネットワーク遅延が重なるバースト推論という極めて限定的なシナリオを計測したものであり、DGX Spark が本来設計された用途をそのまま反映しているわけではありません。細部こそが重要で、すべての要素が Spark の優位性を裏付けています。 今回のテストでは、すべての Cline エージェントは Mac のコントロールノード上で実行されました。Spark の推論エンドポイントは、往復するたびに Tailscale VPN を経由します。もし Cline エージェントを DGX Spark 本体で直接実行すれば、42.9 tok/s というスループットは、ネットワークの介在による遅延が一切ない純粋な速度として発揮されます。これは Spark が設計された本来の構成です。 この構成にすることで、Thunderdome や今回のレースで Spark を劣勢にしたネットワーク遅延を完全に排除できます。この状態であれば、純粋なスループットの数値だけを見れば、Spark は私たちが行ったあらゆるテストで圧勝していたはずです。 クラウドはこうした特定の条件下では速度競争に勝利しましたが、持続的なワークロードにおいてはコスト競争で敗北します。Mac のクラウドバックアップ型モデルは従量課金制であり、トークン 1 つごとに料金が発生します。一方、Spark のトークンあたりのコストはゼロです。24 時間 365 日稼働する常駐型のコーディングエージェントにとって、これは「一度きりのハードウェア投資」と、「数週間や数ヶ月で複利のように膨れ上がるクラウド利用料」の違いを意味します。 Thunderdome で勝利したクラウド API は、使用量が増えるほど高価になります。しかし Spark は、使うほどに安くなります。 クラウドは、プライバシーが重要なあらゆる環境において、競争に敗れています。プロンプトのすべて、生成されたコードの各行、機密ファイルへの参照——これらすべてをクラウドモデルはインターネット経由で、他社の GPU クラスターへ送信してしまいます。死闘（デスマッチ）であればそれでも構いません。しかし、本番環境のコードベースやコンプライアンスが厳格な業界、政府機関での業務、あるいはデータが社外に出せないあらゆる環境では、クラウドモデルは論外です。 一方、DGX Spark はモデルをダウンロードした後は完全にオフラインで動作します。インターネット接続も不要であり、データが機械から流出することもなく、サードパーティへの依存もありません。 そして、一般消費者向けハードウェアとの比較についてです。RTX 4090 は、24GB のメモリに収まるモデルであれば優れた GPU です。7B から 32B パラメータ規模のモデルでは互角に戦えます。しかし、120B モデルになると、システム RAM と VRAM の間でデータを転送するのを待っている時間が大半を占めてしまいます。そのため、RTX 4090 は秒間 8.7 トークン（tok/s）しか処理できませんが、Spark は 42.9 tok/s を達成しました。 Spark が持つ 128GB の統合 GPU メモリにより、モデル全体をチップ上に保持できます。オフローディングも不要であり、メモリバスによるボトルネックや速度低下の心配もありません。2025 年以降に実際に重要となるクラスのモデル——70B、120B、量子化された 671B など——にとって、Spark は一般消費者向け GPU が到達できない別次元のカテゴリーにあります。 ## SIGKILL レースが示す推論の真髄 従来のベンチマークは、「十分な時間をかければモデルが問題を解決できるか」をテストします。一方、デスマッチ（SIGKILL レース）が試しているのは全く異なるものです：速度、信頼性、そしてプレッシャー下での実行能力——これらを同時に評価するのです。 正しいコードを書け。速く書け。躊躇なく実行せよ。 TTFT（初出トークンまでの時間）は短い順次タスクでは有利ですが、スループットこそがそれ以外のすべてを決定します。クラウドモデルのサブ秒単位の TTFT は、数分の一秒で測られるタスクにおいて圧倒的なリードを与えました。しかし、実際のコーディングエージェントのセッションは数分あるいは数時間に及び、数百行のコード生成やファイル間での反復、テスト実行が行われます。そのような時間スケールでは、Spark の 42.9 tok/s という持続スループットこそが生産性を左右する指標となります。 Thunderdome（競技場）という実験では TTFT が勝利しましたが、実際の作業においてはスループットが勝者です。Spark は、実際の開発において最も重要な指標で勝利しました。 ネットワークトポロジーは、純粋なハードウェアの速度と同じくらい重要です。DGX Spark は推論において高速ですが、リモートコントロールノードから VPN 経由で接続すると、その速度が圧縮されてしまいます。この教訓はテストを超えて応用可能です。エージェントをモデルと同じマシン上で実行すれば、ローカル推論はあらゆるクラウド API を凌駕する速度を発揮します。なぜなら、ネットワークの往復遅延がゼロになり、トークンコストも発生しないからです。 モデルサイズの違いは、ハードウェア性能の差を指数関数的に増幅させます。7B から 8B パラメータの規模では、コンシューマー向け GPU と Spark はほぼ同等の性能範囲にあります。しかし、120B の大規模モデルになると、その差は断絶へと変わります。フルモデルをオンチップメモリに収容できるだけの十分なメモリーを持つハードウェアでなければ、高速実行は不可能だからです。オープンソースモデルがさらにスケールしていくにつれて、この格差は広がる一方です。DGX Spark が持つ 128GB のメモリは、まさにこの成長軌道のために設計されており、これに追随できるデスクトップクラスのハードウェアは他には存在しません。 最適化する推論スタックは、何に重点を置くかによって異なります。クラウドは高速でセットアップ不要です。一方、消費者向け GPU は小規模なモデルサイズであれば安価かつ高性能です。DGX Spark が担うのは、これらいずれの選択肢も届かない領域です。それは、完全なオンデバイス環境でフルスピードで動作し、限界コストゼロ、そして完全なデータプライバシーを確保するフロンティアクラスのモデル向けです。速度、スケーラビリティ、コスト制御、プライバシーのすべてを同時に必要とするチームにとって、妥協なくこれら四つの要件を満たすのは DGX Spark だけです。 実務における DGX Spark の位置づけ このデスマッチ（死闘）は派手さや共有性を意識して設計されています。しかし、Cline と DGX Spark の組み合わせが真価を発揮するのは、持続的な日常利用においてです。 Cline を 24 時間 365 日自律的に稼働させ、コードの反復改善、テスト実行、バグ修正を継続します。トークン一つあたりのコストはゼロです。同じワークロードをクラウド API で実行した場合、トークンごとの課金が積み重なり、数ヶ月で実額に達するほどになります。Spark の 42.9 tok/s という速度は、初期ハードウェア投資以外には追加費用がかかりません。この経済的優位性は、利用すればするほど、あなたの味方につきます。 さらに Spark は、消費者向けハードウェアでは実用的な速度で実行できないモデルも処理できます。具体的には gpt-oss:120b、671B 量子化された DeepSeek-R1、Llama 3.1 70B、Qwen3 32B です。これらのモデルは、消費者向け GPU ではそもそも搭載できないか、あるいは深刻なオフローディングのペナルティにより対話型コーディング作業には実用的ではありません。Spark はこれらをクラウド依存なしで、完全なオンデバイス環境でフルスピードで実行します。市場にある個人のワークステーションでこれを主張できるものはほとんどありません。 コンプライアンス規制の厳しい業界や、ネットワークから完全に隔離された環境（エアギャップ）を運用するチームにとって、モデルをダウンロードした後は Spark がオフラインで完結します。インターネット接続は不要で、データが外部に漏れることもなく、サードパーティへの依存も生じません。これは多くの組織における必須条件であり、クラウド推論がどれだけ高速化しても満たすことのできない要件です。 ハードウェアは一度購入すればよく、使用量に応じた課金やレート制限、予期せぬ請求の心配はありません。生成されるトークン数が増えるほど経済性は向上し、1 秒あたり 42.9 トークンの速度であれば、大量のトークンを生成できます。 実際に試してみましょう このデスマッチ（死闘）用のスクリプトは GitHub でオープンソースとして公開されています。Ollama がインストールされたマシンを 3 台用意し（必要に応じて自前の環境へ差し替えても可）、それらを接続するネットワーク（今回は Tailscale を使用）、そしてエージェントを統括するための Cline CLI（npm install -g cline）が必要です。 リポジトリには、検証とセットアップ用の「deathmatch-preflight.sh」、完全な Thunderdome 戦用の「deathmatch-final.sh」、純粋な推論ベンチマーク用の「deathmatch-race.sh」、そして tmux アリーナの設定ファイルなど、すべてが揃っています。各スクリプトは自動的にマシンごとのモデル割り当てを処理します。GPU メモリに十分な余裕があるマシンにはオンデバイスモデルを、そうでないマシンにはクラウドバックアップ型の変種を割り当てる仕組みです。 自社のハードウェアやモデルを差し替えて試すことも可能です。特に興味深いのは、Cline エージェントを DGX Spark 上で直接実行し、42.9 tok/s のスループットを中継なしで発揮させた場合の結果でしょう。今回の数値に基づけば、この構成は私たちが投じるあらゆるテストにおいて他を圧倒するはずです。 自分自身でデスマッチを企画し、その結果を Reddit や Discord で共有しましょう。Cline をインストールして（最近リリースされた Kanban もチェックしてください）、あるいは各推論プロバイダーごとの設定についてはドキュメントを確認してください。 3 つの AI が参入し、1 つだけが生き残りました。クラウドモデルが「サンダーダム」を制しましたが、本当の物語は推論速度の競争にあります。オンデバイス環境で、GPU メモリからフルサイズの 120B モデルを実行した場合、DGX Spark は市場で最高のコンシューマー向け GPU を上回る 4.9 倍のトークン生成速度を記録しました。コストはトークンあたり 0 ドルで、すべてのデータが端末内に留まります。この規模でのローカル推論において、これに匹敵するものは他にありません。

AI コーディングエージェントの生存競争

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

関連記事

ニュースの次に確認する

調べる

選ぶ

サイト