DeepSeek H200テスト、「80倍安い」という主張に疑問を投げかける
The Call Center Doctorsは、DeepSeekの「80倍安い」という主張を検証するため、Nvidia H200 GPUを4基レンタルし、実運用でのコストテストを実施した。
このコンサルティング会社は、Claude Code経由でClaude Opus 5.5を使う代わりに、コーディングエージェントへDeepSeek V4.1 Flashを提供しようとした。同社の元のテストでは、安価なモデルウェイトが安価に機能するシステムにつながるわけではないことが示された。
DeepSeek H200テストは、トークン価格と実際のソフトウェア作業を完了するコストの隔たりを浮き彫りにした。レンタルサーバーは合成ワークロードを高速に処理したものの、チームが実際のコーディングトラフィックを再現すると、その経済性は悪化した。
通常のオンデマンドレンタル料金では、このサーバーのコストは、同じワークロードをDeepSeek自身のAPIへ送る場合のおよそ2倍だった。同社はまた、トークン価格ではなく完了したコード変更を測定すると、既存のClaude Codeサブスクリプションも競争力を維持していると結論付けた。
これらの結果は、1社のワークロード、構成、社内測定に基づくものである。どちらのモデルにとっても普遍的なベンチマークではない。テスト中、DeepSeekには本番コードの記述権限が与えられなかったため、完了作業の直接比較には限界がある。
それでも、この実験は孤立したベンチマークではなく、デプロイ済みコーディングエージェントのトラフィックを用いた点で重要だ。反復されるコンテキスト、同時実行性、レイテンシー、運用作業、自律的なコード実行を囲むセキュリティ境界を測定した。
中心的な逆転は単純である。DeepSeekの低いAPI料金は引き続き魅力的だった一方、プレミアムGPU上で同じモデルをセルフホストすると、この特定のワークロードでは経済性が悪化した。
この結果は、購入者に対し、プロバイダーを切り替える前に「安い」の意味を定義するよう促す。低い出力トークン単価には意味があり得るが、スループット、信頼性、エンジニアリング工数、成功したデリバリーを表すものではない。
DeepSeek H200テストは価格主張をワークロードテストに置き換えた
このコンサルティング会社が検証したのは、100万トークン当たりの価格表示だけでなく、完全な推論システムだった。
The Call Center Doctorsは、他企業向けにコールセンター環境を構築・運用している。また、その業務を支えるソフトウェアの保守にコーディングエージェントを利用している。
9月27日、同社はNvidia H200アクセラレータを4基搭載したサーバーをレンタルした。DeepSeek V4.1 Flashをダウンロードし、通常はClaude Codeに接続されるエージェント向けのバックエンドとして構成した。
このテストは、オープンウェイトモデルをめぐる2つの一般的な主張を対象とした。1つ目は、低いトークン料金が直接的に低い運用コストへ転換されるというものだ。2つ目は、組織がGPUをレンタルして自らモデルを提供すれば、プロバイダーのマージンを回避できるというものだ。
DeepSeekは、購入者がこうした主張を検討する理由を提供している。同社のモデル発表では、V4.1 Flashを、より高速な推論と高いスループットを目的に設計されたMixture-of-Expertsモデルとして説明している。
Mixture-of-Expertsモデルは、各トークンについてネットワークの一部だけを有効化する。この設計により、すべてのリクエストで全パラメータを動かす場合と比べ、計算量を減らせる可能性がある。
DeepSeekによれば、そのアーキテクチャは入力と出力の処理時に有効化するパラメータ数が少ない。また、前世代よりもキー・バリューキャッシュに必要な高帯域幅メモリが少ないとしている。
キー・バリューキャッシュは、以前のトークンから得られた中間的なアテンションデータを保存する。そのデータを再利用すれば、シーケンス全体を新規入力として処理するより、反復コンテキストを低コストで扱える。
そのため同社は、メモリ負荷の高い推論に適したハードウェアを選択した。NvidiaのH200仕様によると、各H200には141GBの高帯域幅メモリが搭載されている。
4基のGPU全体では、複数回の構成変更を経てモデルをロードし、提供するのに十分な容量があった。しかし、安定したサービスに到達するまでには5回の起動が必要だった。
再起動のたびに、モデルロードの時間が再び必要になった。ある最適化では想定外にメモリを消費し、別の実行ではフリーズが発生し、その後の構成はより高い同時実行数で失敗した。
5回目の試行では、同時実行数の上限を下げ、利用可能メモリの大半を割り当てることで安定した。この運用上の経緯は、経済性の結果の一部となった。
ホスト型APIでは、モデルダウンロード、メモリ割り当て、提供ソフトウェア、容量計画、起動失敗は隠蔽される。レンタルマシンでは、それぞれの作業が顧客に委ねられる。
安定化後、このサーバーは個別の1分間テストで良好な性能を示した。特にキャッシュ済み入力を高速に処理し、マシン全体で毎秒数千トークンを生成した。
この結果は当初、セルフホスティングの根拠を裏付けるように見えた。4基のH200には大きな生のスループットがあり、DeepSeekのキャッシュ重視設計も想定どおりに機能した。
問題は、チームが一度に1種類のトークンカテゴリをテストするのをやめたときに現れた。コーディングエージェントは、新規入力、キャッシュ済み入力、出力を均等な順序で送信してはいなかった。
エージェントは長い会話、ツール結果、ファイルコンテキスト、以前の推論を繰り返し送っていた。各リクエストの大半は、モデルがすでに確認したテキストで構成されていた。
このワークロードにより、テストの焦点は理論上の出力速度から移った。次の回答を生成する前に必要なコンテキスト処理に、マシンがほぼすべての時間を費やすことになった。
したがって、この事例は従来型のモデル競争ではなかった。魅力的な推論レートが、エージェントシステムの実トラフィックに直面しても維持されるかを検証するテストだった。
なぜエージェントのコンテキストが4基のH200を消費したのか
コーディングエージェントは、次の有用なトークンを書くよりも、履歴を読むために大幅に多くの計算資源を使うことが多い。
同社の9月のログには、読み取りトークン3885億、書き込みトークン3億9300万が記録されていた。入力のうち3742億トークンは、キャッシュからの再読み取りだった。
これは、記録された入力の96%以上が以前のコンテキストを反復していたことを意味する。出力トークンごとに、エージェントは新規入力を約41.6トークン、キャッシュ済み入力を1042トークン送っていた。
平均的なリクエストでは、およそ19万6000トークンが再読み取りされた。このパターンは重要である。キャッシュ済み入力はトークン当たりでは安価でも、計算コストがゼロになるわけではない。
レンタルサーバーは、新規トークンよりもキャッシュ済みトークンを高速に処理した。しかしエージェントが送るキャッシュ済みトークンは非常に多く、その小さなコストが積み重なり、支配的なワークロードとなった。
同社の測定では、キャッシュ済みトークンに必要なサーバー時間は約1.9マイクロ秒だった。新規入力トークンには約60マイクロ秒、出力トークンには約189マイクロ秒が必要だった。
これらの測定値を本番トラフィックの構成に適用すると、毎秒約213出力トークンという複合的な上限が得られた。これは4基すべてのGPUを共有するすべてのエージェントの合計結果である。
同社によると、この式はライブテストと3%以内で一致した。この一致はワークロードモデルの信頼性を高めるが、独立した第三者による再現はまだ行われていない。
同社は、この構成では1日に合計約200億トークンを処理できると見積もった。9月で最も利用が集中した日には510億トークンに達した。
したがって、容量が第2の制約となった。通常のレンタル経済性が有利だったとしても、1台のサーバーでは記録されたピークを吸収できなかった。
個別テストと混合テストの対比は、見出しになるスループットが誤解を招き得る理由を説明している。出力だけを測定した場合、このマシンは毎秒5000トークン以上を生成した。
実際のエージェントは、出力だけでは動作できない。指示、コード、ファイル、ログ、ツール応答、以前のメッセージを継続的に提供しなければならない。
長時間稼働するエージェントでは、会話が時間とともに増大するため、この不均衡が拡大する。後続の各呼び出しには、同じ履歴の多くに少量の新情報が加わることがある。
キャッシュ割引は、こうした反復トークンの料金を下げる。だが、メモリ帯域幅、スケジューリング遅延、サーバーを占有する機会費用をなくすものではない。
この区別は、モデル間比較も複雑にする。より能力の高いモデルは、より少ない試行、短いプロンプト、少ないレビューでタスクを完了できるかもしれない。
より安価なモデルでも、同程度のコンテキストを使用し、同等の結果を達成できれば優位に立つ可能性がある。一方、再試行が増え、説明が長くなり、別モデルによる検証が必要になれば不利になり得る。
DeepSeek H200テストでは、DeepSeekが主に読み取り専用のレビュアーとして使われたため、この品質の問題には完全に答えられなかった。ただし、出力トークン単価だけでは答えられない理由は示した。
重要な指標は、業務によって異なる。バッチ要約システムでは総スループットが優先されるかもしれないが、対話型エージェントには低レイテンシーと信頼できるツール利用も必要になる。
コーディング業務では、完了した変更、レビュー時間、回帰、セキュリティ、開発者の待機時間が重要になる。トークン効率は、その結果を左右する要素の一つにすぎない。
同社のログは、他の購入者にも有用な警告を与えている。ハードウェアを選ぶ前に、チームは新規入力、キャッシュ済みコンテキスト、生成出力の比率を分析しなければならない。
この比率がなければ、ベンチマークはワークロードのごく小さな部分を最適化してしまう可能性がある。高速な生成テストは、ほとんどの時間を読み取りに使うエージェントについて、ほとんど何も示さないかもしれない。
DeepSeekのセルフホスティングはDeepSeek APIに敗れた
最も明確な結果はDeepSeek対Claudeではなく、レンタルしたDeepSeekインフラとDeepSeekのマネージドサービスの比較だった。
通常のオンデマンドサーバー料金では、同じトラフィックをDeepSeek APIで処理する場合と比べ、1日当たりのコストはおよそ2倍から2.4倍になった。この計算は継続的な稼働率を前提としている。
実験で利用したスポットレンタルは大幅に安価だった。この一時的な料金では、サーバーがフル稼働した場合にのみ、DeepSeekのマネージドサービスとほぼ同等のコストに近づいた。
スポット容量には可用性のトレードオフがある。需要の変化に応じてプロバイダーが回収できるため、信頼できる本番インフラとして扱うのは難しい。
実験直後に、まさにそれが起きた。プロバイダーは最終テストから数分以内にマシンを回収した。
オンデマンドの代替案は中断リスクを回避したが、経済性を悪化させた。また、モデルのロード、再起動、トラフィック待ち、最大利用率未満での待機中も課金された。
DeepSeekのマネージドAPIでは、こうしたアイドル時間が多数の顧客に分散される。プロバイダーはリクエストをバッチ処理し、ハードウェアをプールし、より大規模に自社の提供スタックを運用できる。
同社のAPI料金表も、キャッシュ済み入力、新規入力、出力を区別している。オフピークのトラフィックには、平日のピーク時より低い料金が適用される。
この料金体系は、購入者に別の最適化手段を提供する。柔軟なバッチワークロードは、専用マシンを必要とせず、ピーク時間帯を避けて実行できる。
レンタルサーバーには、これに対応する需要調整がなかった。エージェントが有用な作業をしたかどうかにかかわらず、時間単位の課金は続いた。
この比較は、セルフホスティングが常に不経済だと示すものではない。組織は償却済みハードウェアを保有している場合もあれば、より低い容量料金を交渉できる場合もあり、複数のワークロードで安定した稼働率を維持できる場合もある。
大規模な導入では、短期間の実験で達成した水準を超えて、カーネル、量子化、ルーティング、バッチスケジューリングを最適化することも可能だ。DeepSeek自身も、非常に大規模な導入を計画する組織に対して、追加オプションの相談を呼びかけている。
ホスト型推論の方が安価であっても、プライバシー要件がローカル運用を正当化することはある。規制対象のワークロードでは、直接的な計算コストを上回るデータ管理が求められる可能性がある。
予測可能な容量も重要になり得る。継続的な需要を持つ企業は、特に外部APIに制限や可用性リスクがある場合、自ら管理するインフラを選好するかもしれない。
しかし、こうした利点を得るには、安定したマシン、経験豊富な運用担当者、監視、フェイルオーバー、そしてセキュリティ管理が必要となる。オープンウェイトだからといって、これらが自動的に備わるわけではない。
このテストでは、専門知識に伴う負担も明らかになった。エンジニアは、有用なワークロードを実行する前に、メモリ使用量、起動失敗、同時実行数の上限、サービングの挙動を診断する必要があった。
こうした作業は、単純なマシン比較には含まれていなかった。含めれば、短期的なセルフホスティング実験はさらに不利な結果になっただろう。
これは、DeepSeekのセルフホスト導入を検討する企業にとっての主要な教訓だ。比較すべきなのは、ある完成されたサービスと別の完成されたサービスである。
モデルウェイトは構成要素の一つにすぎない。ハードウェアのレンタル、アイドル時の余剰容量、オーケストレーション、可観測性、インシデント対応、電力、ストレージ、スタッフの時間によって、システムは完成する。
DeepSeek APIは、ダウンロード可能なモデルと同じアーキテクチャ上の効率性の恩恵を受ける。さらに、DeepSeekが多くの顧客にまたがって運用できるインフラの恩恵も受ける。
セルフホスティングでは、この二つの利点をいずれも乗り越えなければならない。APIプロバイダーのほうが利用率とサービングの専門性で優れている場合、APIの上乗せ料金を避けるだけでは不十分だ。
このワークロードでは、それを覆せなかった。オープンウェイトの選択肢は制御性をもたらしたが、より安価なDeepSeek体験を提供したのはDeepSeekのクラウドだった。
「80倍安い」という主張は異なる購入モデルを比較していた
見出しの比較が弱まったのは、公開API料金と高頻度で利用されたサブスクリプションアクセスを並べたためだ。
「80倍安い」という主張は、特定の前提に基づくトークン料金を比較したものだ。すべてのClaude Codeユーザーが実際に支払う金額を自動的に示すものではない。
このコンサルティング会社は、Anthropicの従量課金APIではなく、サブスクリプションを通じてClaudeにアクセスしていた。Anthropicは、対象プランが共有利用制限の対象となるClaude Codeへのサブスクリプションアクセスを提供することを確認している。
サブスクリプションとAPIは、異なる購入パターンに対応する。サブスクリプションは定められた上限内でアクセスをまとめて提供する一方、APIは測定された利用量に応じて課金する。
同社によると、サブスクリプションの利用は、公開API料金から大幅な割引を受けるのと同等だった。この差が、理論上の80倍という差の大半を吸収した。
9月のトラフィックを用いて、同社はDeepSeek APIの費用が、Claudeのサブスクリプションと比べてやや安くなる場合から高くなる場合まであり得ると算出した。利用量がピーク料金とオフピーク料金のどこに収まるかは、タイミングによって決まった。
報告された結果では、Claudeの公開API料金なら請求額ははるかに大きくなったとも推定されている。しかし、それは同社が購入していた製品ではなかった。
比較においてすべての製品を名目上のトークン料金に還元すると、この違いは見落としやすい。同じモデルでも、サブスクリプション、エンタープライズ契約、クラウドプラットフォーム、または直接APIを通じて販売されうる。
それぞれのチャネルには異なる制限と経済的インセンティブがある。サブスクリプションは継続的な個人利用に適する場合があり、APIはプログラム可能なスケールと詳細な利用状況の把握を提供する。
エンタープライズ契約では、交渉済みの容量、サービスに関する約束、または管理機能が追加される場合がある。セルフホスティングでは、ベンダーのサービスマージンをインフラと運用上の責任に置き換える。
単一の料金で、この4つの形態すべてを捉えることはできない。購入者は、実際に購入・運用できる経路を比較すべきだ。
このコンサルティング会社は、マージされたコード変更1件あたりのコストも算出した。測定期間中、Claudeエージェントは5,610件の変更をマージし、そのうち5件は後に差し戻された。
同社は、DeepSeekでは追加のトークン、再試行、Claudeによるチェックが必要になると見積もった。これらの前提に基づけば、受け入れられた変更1件あたりのコストはDeepSeekのほうが高くなる。
この推定には注意が必要だ。DeepSeekは同じ書き込み可能なタスクを実行していないため、この調査では実際の成功率や総トークン使用量を観測できなかった。
より良いプロンプティング、サービングソフトウェア、またはエージェント設計によってDeepSeekの出力が改善されれば、前提は厳しすぎる可能性がある。一方、レビューでさらに多くの欠陥が見つかれば、楽観的すぎる可能性もある。
それでも、受け入れられた変更あたりのコストは、出力トークンあたりのコストより有用な指標だ。推論への支出を、レビューを通過したソフトウェアと結び付けるからだ。
最適な単位はワークフローによって異なる。顧客サービスチームは解決済み案件を測定するかもしれず、研究者は検証済みの発見を測定するかもしれない。
モデルが同様の成果に到達するために必要な作業が同程度であれば、低いトークン料金は依然として価値がある。能力、レイテンシ、またはレビュー負担が異なる場合、その決定力は弱まる。
したがって、「80倍」という数字は普遍的な節約額ではなく、限定的な比較を表す。Call Center DoctorsはDeepSeekの公表料金を否定したわけではない。
むしろ、製品、ワークロード、成果物の品質が異なる場合、料金表に基づく計算が崩れ得ることを示した。
セキュリティ上の理由から、DeepSeekは本番コードを書けなかった
この実験における最大の制約は、最も重要な運用上の警告でもあった。DeepSeekは想定されたコーディング任務を完了しなかった。
同社は、コード作成エージェントにDeepSeekを利用する計画だった。しかしレビュー担当者は、生成されたコードが意図したサンドボックスから抜け出す可能性のある経路を見つけた。
サンドボックスとは、信頼できないコードがアクセスできる範囲を制限する隔離された実行環境である。エージェントが機密ファイル、認証情報、ネットワーク、管理者権限に到達することを防ぐべきものだ。
報告された弱点の一つには、共有一時ディレクトリ内の設定ファイルが関係していた。同社は、そこにある操作されたコンテンツにより、生成コードが昇格した権限で実行される可能性があると考えた。
そのため、このコンサルティング会社はビルダーエージェントをオフラインに維持した。DeepSeekは、48〜64の読み取り専用レビューエージェントとしてのみ運用された。
これらのレビュー担当者は2,377のコードフォルダを調査し、32件のバグ報告を作成した。この活動は有用な処理能力を示したが、自律的な実装は検証していない。
このセキュリティ問題は、DeepSeekのモデルウェイトの欠陥として提示されたものではない。問題となったのは、コンサルティング会社を取り巻くエージェント環境と実行制御だった。
この区別は重要だ。コマンドを生成できるモデルであれば、十分に隔離されていないツールチェーンの弱点を露呈させる可能性がある。
Claude、DeepSeek、あるいは別のモデルでも、エージェントにファイルシステムとシェルへのアクセスが与えられれば、危険な操作を生成しうる。セキュリティ境界では、モデル出力を信頼できないものとして扱わなければならない。
結果として、このテストは二つの別個の問いを混在させた。一つはDeepSeekの推論経済性に関するものだ。もう一つは、同社のエージェントサンドボックスが書き込み可能な自動化に対応できていたかどうかである。
直接的なワークロード測定を受けたのは最初の問いだけだった。二つ目の問いによって、想定されていたコーディングの直接対決は中止された。
このため、同じ実験でClaudeがより良いコードを生成したと強く主張することはできない。Claudeが9月に完了した作業は過去の本番データであり、DeepSeekの作業は制限付きのテストだった。
また、DeepSeekのマージ済み変更あたりのコストを公正に測定することもできない。このモデルは、レビューとデプロイのための変更を生成する機会を得なかった。
同社は、Opusが能力面で優位だと主張するために公開コーディングベンチマークを参照した。ベンチマークは文脈を提供できるが、同一の社内タスクセットの代替にはならない。
厳密な追試では、両モデルに同じリポジトリ、ツール、セキュリティ制約、プロンプト、受け入れテストを与えるべきだ。レビュー担当者はモデルの識別情報を知らない状態を維持する。
この調査では、成功した変更、回帰、不具合修正の再試行、レイテンシ、トークン使用量、人間によるレビュー時間、セキュリティ違反を記録するべきだ。そうして初めて、総配信コストを直接比較できる。
この制約にもかかわらず、中止された導入には実用的な教訓がある。実行レイヤーがモデルに意図されたツールを安全に公開できないなら、インフラコストにはほとんど意味がない。
エージェントシステムは、確率的なモデル出力を決定論的な操作に接続するため、攻撃対象領域を広げる。一つの危険な経路が、何千もの安価なトークンより重大になり得る。
したがって企業は、自律作業による節約を計算する前に、隔離をテストすべきだ。読み取り専用の分析と書き込み可能なエージェントは、まったく異なるリスクカテゴリに属する。
セキュリティは経済性にも影響する。より強力な隔離には、使い捨て環境、制限付き認証情報、ネットワーク制御、ログ記録、承認チェックポイントが必要になる場合がある。
これらの管理策はエンジニアリング時間を消費し、レイテンシを追加する。また、同時実行数を減らしたり、別個のインフラを必要としたりする可能性もある。
推論料金が最も低いモデルが、安全に提供されるコストも最も低くするとは限らない。関連するシステムには、その出力を信頼するために必要なあらゆる管理策が含まれる。
DeepSeek H200テストがAI購入者に示すこと
次の比較では、単一のトークン価格ではなく、受け入れられた作業、継続的な利用率、安全な実行に焦点を当てるべきだ。
最初に注目すべきシグナルは、書き込み可能な状態で管理された再実行だ。DeepSeekには、以前Claudeで使用されたのと同じツール、リポジトリ、プロンプト、受け入れ基準が必要となる。
限定的なレビューで同等の変更を完了できれば、このコンサルティング会社の否定的な結論は弱まる。再試行と修正が高水準のままであれば、成果ベースのコスト論は強まる。
二つ目のシグナルは、数週間にわたる継続的な利用率である。セルフホストサーバーは、有用な需要が一日を通じて容量に近い水準に保たれる場合に、より魅力的になる。
Call Center Doctorsは、1台のマシンの容量を超えるピークを測定した。しかし、変動するトラフィックは、そのピーク以外の時間帯に高価なアイドル時間を残しうる。
より長期のテストでは、時間ごとの利用率、キューの深さ、最初のトークンまでのレイテンシ、中断、読み込みまたは復旧に費やした時間の割合を報告すべきだ。
また、キャッシュされた入力、新規入力、出力を分けるべきである。これらのカテゴリは、メモリ帯域幅やバッチ処理と異なる形で相互作用する。
三つ目のシグナルはDeepSeek V4.1-Proだ。DeepSeekによると、現在のFlashアーキテクチャはより大規模なモデルへ拡張される予定だが、確定したリリース日は示されていない。
より強力なモデルは、より少ない再試行でより多くのタスクを完了できれば、経済性を変える可能性がある。一方で、より多くのメモリを必要としたり、スループットが低下したりする可能性もある。
購入者は能力とサービング要件の両方を注視すべきだ。ベンチマークの改善が、本番コストの低下を保証するわけではない。
DeepSeekの現在の成果は依然として重要だ。公式料金により大量の実験が利用しやすくなり、ダウンロード可能なウェイトはデプロイの柔軟性を提供する。
このテストは、その利点を消し去ったわけではない。節約につながる条件を絞り込んだのである。
断続的または不確実な需要に対しては、専用の4 GPUサーバーを借りるより、DeepSeekのマネージドAPIのほうが合理的に見える。顧客にインフラ運用を移管せずに、低いトークン料金を維持できる。
機密データ、予測可能で継続的な需要、または特化した最適化がある場合、セルフホスティングも引き続き評価に値する。ビジネスケースには、スタッフ、信頼性、セキュリティ、未使用容量を含めなければならない。
Claude Codeは異なる価値提案を示す。サブスクリプションの利用制限の下で、モデルアクセス、コーディングインターフェース、プロバイダー運用のインフラをまとめて提供する。
このパッケージは、個人による高頻度利用ではトークンベースの比較を上回る可能性がある。一方、組織がプログラム可能な容量や集中管理を必要とする場合には、制約となることもある。
そのため、調達チームとエンジニアリングリーダーに求められる対応は大きい。「API」「サブスクリプション」「セルフホスト」を、交換可能な購入単位として扱うことをやめなければならない。
まずはベンダーの事例ではなく、本番トレースから始めるべきだ。最も有用なトレースは、コンテキスト長、キャッシュヒット、出力、レイテンシ、失敗、受け入れ結果を記録する。
その後、チームは代表的なワークロードを競合するシステムで再生できる。テストには、デモの成功後に重要となる運用条件を含めるべきだ。
これらの条件には、同時実行性、トラフィックの変動、再起動、キューイング、モデル更新、監視、復旧が含まれる。エージェントに書き込み権限を与える前に、セキュリティテストを実施しなければならない。
成果指標は、組織の目標と一致しているべきだ。コーディングエージェントでは、マージされた変更、欠陥、リバート、レビュー時間、完了までの時間がこれに含まれる。
サポートエージェントでは、解決済み案件、エスカレーション、顧客満足度、ポリシー違反が有用な指標となる。リサーチエージェントでは、生成されたページ数よりも、検証済みの発見のほうが重要だ。
DeepSeek H200テストに価値があるのは、その基準に近づいたためだ。抽象的なレート比較を、実際のコンテキスト分布と実際のインフラに置き換えた。
その限界も同様に示唆に富む。短い実行時間、単一組織での検証、未完了のセキュリティ作業、不均等な本番アクセスにより、普遍的な結論を下すことはできない。
適切な結論は、より限定的なものだ。レンタルした4基のH200は、このエージェントワークロードにおいてDeepSeekのAPIを上回らず、APIもサブスクリプションに対して明白な80倍の優位性を示さなかった。
それだけでも、単純化された主張に疑問を投げかけるには十分だ。しかし、DeepSeek、オープンウェイト、またはセルフホスト型推論を退けるには不十分である。
AIスタックを変更する前に、代表的なトラフィックを1週間分収集し、受け入れられた結果1件あたりのコストを算出すべきだ。そのうえで、セキュリティ制御を有効にした状態で比較を繰り返す。
最も安いトークンが印象的かではなく、モデルが同じ作業を完了できるかを問うべきだ。次のDeepSeek H200テストは、そのより難しい問いに答える必要がある。
