ワットか財布か？ AI アクセラレータ M&A の価格パフォーマンスとソフトウェア リーチ

導入

AI アクセラレータは、シリコン アーキテクチャ、メモリ、ネットワーキング、パッケージング、システム、コンパイラ、ライブラリ、フレームワーク、オーケストレーション、開発者サポートにわたって競合します。公開出願では、パフォーマンス、エネルギー効率、統合、使いやすさ、ワークロードの最適化、ソフトウェア エコシステム、ロードマップ、供給に基づく競争について説明しています [6-16]。 MLCommons ベンチマーク ルールは、比較に定義済みのモデル、シナリオ、精度制約、システムの説明、および可用性ステータスが必要な理由を示しています [1-5]。単一のピーク仕様では、このオペレーティング システムをキャプチャできません。

したがって、取引の問題は経済的かつ技術的なものになります。購入者は、ターゲットがどのワークロードを実行できるか、どのようなレイテンシとスループット、どのような精度、電力、メモリ、エンジニアリング負荷で実行できるか、そしてそれらの結果が顧客によって再現できるかどうかを知る必要があります。また、ソフトウェア スタックが新しいモデルをサポートしているかどうか、顧客が既存のプラットフォームから移行できるかどうか、クラスタ間で展開を拡張できるかどうか、供給と資本の制約を乗り越えてビジネスがロードマップを実現できるかどうかも把握する必要があります。

この文書は、戦略的バイヤー、プライベートエクイティ投資家、企業開発チーム、創業者、貸し手、投資委員会を対象に作成されています。勤勉さ、評価、取引条件、統合のためのシステムを提供します。エンジニアリング、法律、税務、会計、規制、投資に関するアドバイスは提供しません。各取引には、製品、契約、ベンチマーク、ソースコード、知的財産、供給手配、セキュリティ、輸出管理、顧客証拠についての最新の専門家のレビューが必要です。

1 プラットフォームの価格設定を行う前に、取得境界を定義する

アクセラレータ ターゲットは、プロセッサ アーキテクチャ、チップレット、メモリ インターフェイス、ボード、システム、コンパイラ テクノロジ、カーネル、ランタイム ソフトウェア、モデル サービング ツール、または垂直アプリケーションを所有する場合があります。法人は、顧客が使用する製品の一部のみを管理する場合があります。買い手は、クロージング時に移転する資産と義務を特定しながら、システム全体をマッピングする必要があります。

アセット マップは、特許、設計ファイル、検証環境、ファームウェア、コンパイラー、ライブラリ、モデル統合、ベンチマーク スクリプト、テレメトリ、顧客契約、クラウド イメージ、供給契約、訓練を受けたチームを結び付ける必要があります。各アセットには、所有者、リビジョン、依存関係、および使用の証拠が必要です。パフォーマンスのデモンストレーションにより可能性を示すことができます。これは、契約された経済性を伴う再現可能な顧客導入とは区別されるべきです。

取得境界線でも製品とサービスを区別する必要があります。エンジニアリング サポート、モデル変換、カーネルの最適化、導入支援により、ソフトウェアのギャップを隠しながら導入を加速できます。オーダーメイドのエンジニアリングに依存する収益は、安定したプラットフォームから得られる収益とは異なる耐久性とマージンを持っています。モデルでは、すべての資材の展開に必要な労働力、ツール、および顧客固有の作業を特定する必要があります。

提案された勤勉構造。技術的主張は、管理されたリポジトリおよび顧客記録と一致する必要があります。

2 ピーク時の仕様ではなく顧客のワークロードをベンチマークする

1 秒あたりのピーク操作数は、定義された精度と条件下での理論上の速度を表します。顧客の価値は、ワークロード、モデル、バッチ サイズ、シーケンスの長さ、精度目標、レイテンシ要件、同時実行性、メモリ フットプリント、ソフトウェア構成によって異なります。したがって、ベンチマークは、製品の価値に関する普遍的な記述ではなく、対照的な実験として扱われる必要があります。

MLCommons は、システム タイプ、可用性カテゴリ、ベンチマーク モデル、展開シナリオを分離しています [1-5]。そのドキュメントでは、精度の検証、レイテンシの追跡、負荷の生成、および結果のレビューについて説明しています。これらのコントロールは、有用な勤勉パターンを提供します。購入者は、完全なシステムの説明、ベンチマーク コード、コンパイラ フラグ、モデル バージョン、データ、電力境界、実行ログ、主張されるすべての利点の結果チェックを保存する必要があります。

テスト計画には、顧客の代表的なワークロードを含める必要があります。トレーニング、バッチ推論、インタラクティブ推論、検索、推奨、ビジョン、および科学技術コンピューティングは、さまざまなリソースに負荷をかける可能性があります。パフォーマンスは、モデルのサイズ、スパース性、精度、メモリ帯域幅、通信パターン、および要求されたサービス レベルによって変化する可能性があります。 1 つのワークロードをリードするターゲットは依然として商業的価値がある可能性がありますが、評価は AI 市場全体にわたって推定するのではなく、関連するアドレス可能なワークロードに従う必要があります。

ベンチマークの再現性はガバナンスの問題です。購入者は、制御されたシステム上でマテリアルクレームを再実行し、ベンダー最適化実装と移植可能な実装を比較し、ソフトウェアバージョンに対する感度をテストする必要があります。ウォームアップ、キャッシュ、量子化、バッチ処理、および除外されたエラーを文書化する必要があります。結果は、それを再現するために必要な条件を備えた範囲として提示される必要があります。

ベンチマークの来歴は、基礎となるモデルとデータにまで及ぶ必要があります。勤勉チームは、重量が公開されているか、認可されているか、または顧客が管理しているかを記録する必要があります。モデルが変更されたかどうか。どの精度または品質テストが適用されたか。前処理作業または後処理作業が測定間隔に含まれるかどうか。コンテナーイメージ、依存関係マニフェスト、ファームウェア、ドライバー、コンパイラーのバージョン、マシン構成を保持する必要があります。定期的なソフトウェア更新後に結果を再現できない場合、トランザクションの証拠は弱くなります。購入者は、実際的な場合には中立的な実装もテストする必要があります。ベンダーが調整したコードはプラットフォームの達成可能なパフォーマンスを示すことができますが、移植可能な実装は、そのパフォーマンスを達成するために必要なエンジニアリングの負担を明らかにすることができます。顧客の経済性は通常の導入から最適化された運用までのパスに依存するため、どちらの見方も重要です。

3 負荷下および時間の経過とともにパフォーマンスを再構築する

AI サービス システムは曲線を越えて動作します。同時実行性が高いと、ユーザーごとの遅延が増加する一方で、総スループットが向上する可能性があります。待機時間が短い場合、容量が十分に活用されていない可能性があります。長いプロンプト、大規模なモデル、検索ステップ、および変数出力により、バランスが変化する可能性があります。 MLCommons Endpoints では、スループット、対話性、最初のトークンまでの時間、同時実行性の測定について説明します。 ^[3]。トランザクション モデルでは、この曲線を顧客サービス レベルと実現価格に結び付ける必要があります。

管理者は、例示的なシステムが高スループットの動作ポイントで 1 時間あたり 118,000 の同等のタスクを実行すると想定しています。これは、顧客モデルの組み合わせで 15% の削減、遅延コミットメントでさらに 11%、運用可用性で 8%、ソフトウェアとデータのオーバーヘッドで 6% の削減を想定しています。結果として得られる販売可能なスループットは、1 時間あたり約 76,000 の同等のタスクになります。これらの仮定は手法を示すものであり、特定の企業を説明するものではありません。

提案された分類;購入者は、ターゲット固有のワークロード、システム、サービス レベルを使用する必要があります。

購入者は、システムが古くなりソフトウェアが進化するにつれて、劣化をテストする必要があります。新しいモデル アーキテクチャでは、サポートされていない演算子、メモリ制限、通信オーバーヘッドが露出する可能性があります。ドライバーとフレームワークを更新すると、回帰リスクが発生する一方でパフォーマンスが向上する可能性があります。したがって、パフォーマンスの証拠には日付を付け、バージョンを付け、製品ロードマップに結び付ける必要があります。

運用可用性には、メンテナンス、障害、展開エラー、および回復が含まれている必要があります。ベンチマーク速度が高いシステムは、使用が中断されたり、サポート需要が高まったりすると、経済性が低下する可能性があります。モデルでは、スケジュールされた容量、成功したジョブ、請求可能な単位、サービス クレジット、およびコレクションを調整する必要があります。

4 ドル当たり、ワット当たり、ラック当たりの価格パフォーマンス

顧客は制約の範囲内で有用な作品を購入します。 1 ドルあたりのパフォーマンスは、取得またはレンタルの価格を把握します。ワットあたりのパフォーマンスは、エネルギーコストと電力の可用性を把握します。ラックあたりのパフォーマンスは、施設の密度、ネットワーク、冷却を把握します。それぞれの措置により、優先プラットフォームが変更される可能性があります。購入者は、各顧客セグメントと所在地をどの制約が支配しているかを特定する必要があります。

コスト境界には、アクセラレータ、CPU、メモリ、ネットワーキング、ストレージ、シャーシ、電力変換、冷却、ソフトウェア、サポート、移行を含める必要があります。低価格チップでは、より多くのノード、エンジニアリング、またはネットワーキングが必要になると、システム コストが高くなる可能性があります。高価なプラットフォームは、使用率、ソフトウェアの適用範囲、導入までの時間が優れている場合に、強力な顧客経済性を生み出すことができます。評価は、コンポーネントの定価ではなく、納品された合計の経済性に基づいて行う必要があります。

すべての値は、年間に導入される同等のアクセラレータごとの管理上の仮定であり、方法のみを示しています。

電力は関連する境界で測定する必要があります。チップ電力、ボード電力、サーバー電力、施設電力は異なる尺度です。冷却、ネットワーク、アイドル容量はコストに大きな影響を与える可能性があります。購入者は、測定された証拠とそれが記録された動作点を調査する必要があります。また、パフォーマンスの向上が、顧客が維持できないような積極的な電力設定に依存しているかどうかもテストする必要があります。

施設の制約が戦略的価値を生み出す可能性があります。既存の電力エンベロープ内でより多くの受け入れられる作業を提供するアクセラレータは、データセンターの資本を遅らせることができます。その値は、ワークロードの再現性、システムの可用性、統合によって異なります。それは部分的に顧客または購入者に属しており、ターゲットの独立した価値に自動的に資本化されるべきではありません。

5 コンパイラの成熟度およびソフトウェアの営業資産としての価値

NVIDIA は、CUDA とそのテクノロジー スタックの一部としての幅広いライブラリ、フレームワーク、SDK、API について説明しています [6-10]。 AMD は、ROCm、顧客サポート、および拡大するデータセンター ポートフォリオについて説明しています [11-14]。 OpenXLA、LLVM、ONNX、および主要なフレームワークは、コンパイラ インフラストラクチャ、モデル表現、移植性の重要性を示しています [21-25]。これらの情報源は、ソフトウェアの価値の大きさを示しています。これらは、プラットフォーム間で同等の成熟度を証明するものではありません。

コンパイラーの注意は、フロントエンド、中間表現、グラフの最適化、コード生成、カーネルの選択、デバッグ、プロファイリング、数値の正確性、およびハードウェアのスケジューリングをカバーする必要があります。購入者は、サポートされているオペレーター、モデル カバレッジ、リリース ケイデンス、回帰履歴、および新しいアーキテクチャを有効にするために必要な時間を確認する必要があります。どのパフォーマンスが再利用可能なコンパイラ機能によるもので、どのパフォーマンスが顧客による手動調整によるものであるかを識別する必要があります。

ソフトウェアの範囲には、ドキュメント、インストール、クラウド イメージ、コンテナ、オーケストレーション、セキュリティ アップデート、可観測性、サポートが含まれます。開発者による導入は、積極的な運用環境での使用、リリース、問題解決、貢献者の質、顧客維持を通じて証明される必要があります。ダウンロード数、リポジトリ、コミュニティ活動はコンテキストを提供します。顧客の証拠がない限り、これらを経常的な経済学として扱うべきではありません。

ソフトウェアの成熟度は、測定可能な経済効果を通じて評価されるべきです。導入、利用、顧客転換、サポートコスト、更新までの時間を短縮できます。このモデルは、プログラムの証拠によって裏付けられていない広範なプラットフォームのプレミアムを回避する必要があります。各ソフトウェアの機能を顧客コホート、残りの投資、観察可能な成果に結び付ける必要があります。

ソースコードのディリジェンスでは、アーキテクチャ、保守性、テスト、セキュリティ、リリースの自動化、およびサードパーティの義務を調査する必要があります。購入者は、所有されているコード、寛容にライセンスされているコード、制限的にライセンスされているコード、顧客が提供するコード、または機密インターフェイスに依存するコードを特定する必要があります。ビルドの再現性は、クリーンな環境からテストする必要があります。重要なコンポーネントには、管理者の名前、レビュー履歴、および復旧計画が必要です。新しいモデルやチップごとに大規模な手動介入が必要になると、技術的負債が経済的に重大になる可能性があります。評価では、現在の収益を維持するために必要な改善と、プラットフォームの拡大を目的とした裁量的投資とを区別する必要があります。オープンソースへの参加により、導入と採用が強化されると同時に、個別のレビューが必要なコンプライアンス、開示、ガバナンスの義務が生じます。

6 顧客の変換を想定する前に移行コストを測定する

移行には、コードを再コンパイルするだけではありません。お客様は、モデルの変換、サポートされていない操作の置き換え、カーネルの再調整、精度の変更、精度の検証、コンテナの再構築、スケジューラの変更、チームの再トレーニング、モニタリングの再設計が必要になる場合があります。移行中にインフラストラクチャを複製する必要がある場合もあります。購入者は、作業負荷と顧客ごとにこの負担を測定する必要があります。

移行計画は、モデル、フレームワーク、カスタム オペレーター、データ パイプライン、サービス提供システム、セキュリティ制御、およびサービス レベルの一覧表から始める必要があります。各アイテムは、移植性評価、修復計画、責任ある所有者、テスト、および受け入れゲートを受ける必要があります。コスト モデルには、カスタマー エンジニアリング、ターゲット サポート、遅延使用、および並行運用を含める必要があります。

切り替えコストは、成長を制限しながら維持をサポートできます。ターゲットには、貴重な問題を解決するため、または離脱には費用がかかるため、強力な顧客がいる可能性があります。購入者は製品の利点と依存性を区別する必要があります。また、プラットフォーム所有者による買収によって顧客の信頼、中立性、またはワークロードを共有する意欲が変化するかどうかも評価する必要があります。

ビジネスを獲得するために移行インセンティブが必要な場合、移行インセンティブは取得コストとして扱われる必要があります。無料のエンジニアリング、クレジット、ハードウェア割引、容量保証により、実現価格を削減しながら導入を加速できます。収益ブリッジには、総予約、インセンティブ、受け入れられた使用量、および回収された現金が表示される必要があります。

移行能力は、制約のある配信システムとしてモデル化する必要があります。専門のエンジニア、顧客モデル、検証環境、実稼働ウィンドウへのアクセスにより、同時に動作できるプログラムの数が制限される場合があります。したがって、大規模なパイプラインでは、顧客が関心を示した場合でも、変換が遅くなる可能性があります。購入者は、ワークロードの種類ごとにエンジニアリング時間、経過時間、受け入れサイクル、およびサポートの強度を見積もる必要があります。後の移行コストを削減する再利用可能なツールと学習を特定する必要があります。この予測では、資金提供による雇用、自動化、またはパートナーのサポートが利用可能になるまで、実証された提供能力でコンバージョンを制限する必要があります。このアプローチにより、ターゲットが技術的に提供でき、顧客が運用的に受け入れることができるよりも早く販売パイプラインが収益に変換されるのを防ぎます。

7 テスト設計の成功、顧客の集中力、使用品質

アクセラレータ設計の成功は、技術的評価、承認されたベンダーのステータス、予約された容量、初期導入、またはコミットされた量を意味します。勤勉の語彙は、定義された証拠要件を各州に割り当てる必要があります。プレスリリースや覚書は戦略的背景を裏付けることができます。契約現金として評価すべきではありません。

購入者は、パイプラインの記録と契約、注文、遠隔測定、請求書、クレジット、および回収を照合する必要があります。顧客エンティティ、ワークロード、製品バージョン、導入サイト、サービス レベル、価格、最低コミットメント、キャンセル権、および受け入れ条件を特定する必要があります。予測ボリュームは、インストール済み、利用可能、消費済み、請求対象の容量から分離する必要があります。

集中度は、顧客、ワークロード、クラウド チャネル、システム パートナー、および共通の経済的親全体にわたって測定される必要があります。複数のプログラムが 1 つのハイパースケーラーまたは 1 つのモデル ファミリに依存することがあります。顧客は、資格、能力資金、またはソフトウェアへの貢献を通じて活用することもできます。評価では、各重要な関係の損失、遅延、または再価格をテストする必要があります。

提案されたフレームワーク。確率と変換期間にはターゲット固有の証拠が必要です。

使用品質は重要です。モデル、データ、または顧客の需要が遅れているため、デプロイメントは計画された使用率を下回って実行される可能性があります。サポートと電力コストが割安であるため、利益率が低くても高使用率で実行される可能性があります。投資委員会は、単一の設置容量の数値ではなく、顧客レベルのユニットエコノミクスを受け取る必要があります。

8 マップの作成、メモリ、パッケージング、およびネットワークの依存関係

アクセラレータのパフォーマンスは、製造、パッケージング、HBM、基板、ネットワーキング、システム統合、および電力供給に依存します。オープン コンピューティング プロジェクトの仕様は、モジュラー アクセラレータとシステム インターフェイスを示しています ^[26]。 UCIe、メモリ、相互接続規格は追加のコンテキストを提供します [27-29]。公的ファウンドリおよびパッケージングの開示には、継続的な投資と技術的な複雑さが記載されています [30-32]。ターゲットのロードマップは、これらの依存関係に対してテストする必要があります。

購入者は、ウェハ契約、パッケージングの割り当て、メモリの供給、基板の製造、コンポーネントの認定、変更管理、優先順位、価格設定、最低購入額、保証、およびセカンドソースのステータスを検査する必要があります。プラン上のサプライヤー名は、アクセス可能な容量を確立するものではありません。モデルでは、実行された権利、日付の準備状況、および実証された利回りを使用する必要があります。

クラスターが拡大するにつれて、ネットワークと通信がシステムのボトルネックになる可能性があります。テスト計画では、集合的な操作、輻輳、障害回復、ワークロードのスケーリングを測定する必要があります。ソフトウェアまたはファブリックのオーバーヘッドが増加すると、チップ レベルの利点が失われる可能性があります。したがって、評価には、システムレベルのパフォーマンスと、約束された構成に必要な資本を含める必要があります。

供給の約束は価値と責任の両方を生み出す可能性があります。前払いとテイク・オア・ペイ義務により、需要が変動した場合に流動性を消費しながら生産能力を確保できる可能性があります。顧客が資金を提供するキャパシティーにより、優先、返金、または独占条件を設けながら、必要な資金を削減できます。買い手は、製品、期間、取引相手、および支配権の変更による影響ごとに、それぞれのコミットメントを示す必要があります。

9 ロードマップを一連の証拠ゲートとして評価する

アクセラレータのロードマップは、アーキテクチャ、シミュレーション、テープアウト、最初のシリコン、ブリングアップ、ソフトウェアの有効化、システムの認定、顧客の受け入れを経て進みます。各ゲートは確率、残りコスト、タイミングが異なります。ロードマップ スライドは、変換を裏付ける証拠が得られるまでは、完全な運用価値を得ることができません。

購入者は、ハードウェアとソフトウェアを統合した 1 つのロードマップを維持する必要があります。コンパイラ、フレームワーク、システムの準備が整っていない場合、シリコンの配信は収益を遅らせる可能性があります。ソフトウェアは発売後に成熟し、パフォーマンスが向上する場合があります。予測には、各顧客プログラムに必要なバージョンと、それを提供するために必要なリソースを記載する必要があります。

ロードマップ値は、プログラム オプションのセットとしてモデル化できます。各オプションには、製品、ワークロード、顧客コホート、予想されるキャッシュ、確率、残りの投資、および最も早い決定日が定義されている必要があります。共有コストと依存関係は一度割り当てられる必要があります。このモデルは、同じ将来の能力が端末の成長と個別のオプション価値の両方に現れることを防ぐ必要があります。

最終価値は、有利な 1 世代ではなく、連続した製品を提供する能力を反映する必要があります。購入者は、アーキテクチャの再利用、チームの継続性、検証資産、ソフトウェアの移植性、サプライヤーのアクセス、顧客の信頼を評価する必要があります。以前のゲートが管理されたコストと品質で達成されている場合、速いケイデンスは価値を裏付けることができます。

10 受け入れられているワークロードの経済学に基づいて評価を構築する

独立した評価は、顧客レベルのキャッシュ フローから始める必要があります。収益は、受け入れられた導入、消費または契約されたユニット、実現価格および更新によって左右される必要があります。コストには、シリコン、メモリ、システム、ソフトウェア、サポート、移行、保証、資本、運転資本が含まれます。シナリオ分析では、パフォーマンス、使用率、価格、電力、ロードマップのタイミングを組み合わせる必要があります。

経営陣は、現在価値が USD 890 million に相当する 5 つの受け入れられた顧客コホート、USD 430 million に相当する 4 つの拡張展開オプション、USD 220 million に相当する 4 つの技術的選択、および USD 180 million に相当する 4 つのロードマップ オプションを想定しています。次に、顧客集中のための USD 190 million、移行サポートのための USD 120 million、および残りのロードマップ資本の USD 270 million が差し引かれます。 USD 540 million のプラットフォーム許容値により、想定されるスタンドアロンの企業価値 USD 1.68 billion が生成されます。すべての金額は経営上の仮定です。

値と確率は、メソッドのデモンストレーションのみを目的とした管理上の仮定です。

市場倍率は、比較可能性が確立された後に合理性をチェックすることができます。収益の質、ハードウェアの内容、ソフトウェアの成熟度、粗利益、資本集約度、顧客の集中度、ロードマップのリスクは、アクセラレータ ビジネスによって大きく異なります。ターゲットが AI 用語を使用しているというだけの理由でプラットフォーム倍数を適用すべきではありません。

モデルでは、独立した価値と購入者固有の価値を区別する必要があります。流通、供給アクセス、クラウドへのアクセス、システム統合、ソフトウェアの最適化が相乗効果を生み出す可能性があります。その価値は、購入者のリソース、実装コスト、顧客の反応、および競争の制約によって決まります。売り手は、買い手だけが生み出すことができる相乗効果に対する全額の支払いを受け取るべきではありません。

資金調達分析は、プラットフォームのボラティリティと資本ニーズを反映する必要があります。債務キャパシティは、供給約束、保証、サポート、ロードマップ投資後の経常的に受け入れられるキャッシュフローに基づく必要があります。未処理、予約、顧客予測は、執行可能性とキャンセル権によって分類する必要があります。貸し手は、収益を回収する前に、テープアウト、在庫、容量の保証金、および顧客の移行のために流動性を必要とする場合があります。導入の遅れ、実現価格の下落、サポートコストの上昇、ロードマップ支出の継続など、これらの圧力は同時に発生する可能性があるため、マイナス面のケースとして考えられます。買収資金には、ヘッドライン EBITDA がすぐに配布可能であると仮定するのではなく、契約上の余裕と統合計画のための資金を含める必要があります。

11 責任ある配送計画によりバイヤー固有の相乗効果を構築する

調達、パッケージの割り当て、ネットワーキング、クラウド配布、ソフトウェア統合、顧客アクセス、重複コストの削減から相乗効果が生まれます。各イニシアチブには、ベースライン、所有者、リソース、タイミング、依存関係、および測定可能な現金成果が必要です。エコシステムの活用などのラベルだけでは評価には不十分です。

技術的な相乗効果は、定義されたワークロードを通じてテストする必要があります。ターゲット アクセラレータをバイヤー コンパイラ、インターコネクト、またはシステムと組み合わせると、パフォーマンス、使用率、または展開時間を改善できます。モデルには、統合コストと、顧客がクローズドまたは変更されたプラットフォームを拒否するリスクを含める必要があります。結果は署名ベースラインと比較して測定する必要があります。

収益の相乗効果には顧客の証拠が必要です。購入者チャネルは、購入者と競合する顧客との衝突を引き起こしながらアクセスを拡大する可能性があります。モデルでは、顧客、オファー、販売サイクル、移行サポートおよびキャパシティを特定する必要があります。プログラム計画によってサポートされない限り、広範な割合の上昇は中心ケースの外に留まるべきです。

コストの相乗効果により、重要な機能が維持されるはずです。コンパイラー、検証、サポート、顧客の依存関係を理解せずに重複したエンジニアリングを削除すると、プラットフォームに損傷を与える可能性があります。統合計画では、ロードマップと信頼性に必要な製品作業と、除去可能な企業コストを区別する必要があります。

12 証拠の成熟度に応じた取引構造を選択する

完全な買収により、ロードマップと顧客リスクをクロージング時に集中させながら、統合された製品と流通の意思決定をサポートできます。段階的な買収では、所有権と対価をシリコン、ソフトウェア、または顧客ゲートに結び付けることができます。少数出資により、中立性を保ちながら学習権と商業権を確保できます。合弁事業では、ガバナンスが複雑になりながら、補完的な資産を組み合わせることができます。ライセンスまたは供給契約により、会社を買収しなくてもアクセスを提供できます。

提案された意思決定枠組み。法律、税務、会計、規制上の影響については、専門家のアドバイスが必要です。

指標が測定可能であり、購入者のコントロールに対処できる場合、条件付きの考慮により不確実性を埋めることができます。関連するゲートには、ベンチマークの再現性、コンパイラのカバレッジ、受け入れられた展開、使用法、粗利益、またはロードマップの配信が含まれる場合があります。契約では、構成、証拠、測定期間、顧客の変更、資本コミットメント、会計、監査、紛争解決を定義する必要があります。

ガバナンスは完全な制御の前に資産を保護する必要があります。情報の権利、資金調達の義務、ロードマップの決定、知的財産の使用、顧客の中立性、および関連当事者間の取引は、その構造と一致する必要があります。買い手は、正当な権利を超えて競争上重要な顧客情報を受け取らないようにする必要があります。

13 競争、相互運用性、プラットフォームの中立性に対処する

米国合併ガイドラインでは、プラットフォーム、補完物、相互運用性、インプットへのアクセスを含む取引について議論しています[37-39]。アクセラレータの買収は、開発者、クラウドプロバイダー、顧客、システムパートナー、競合ハードウェアに影響を与える可能性があります。購入者は、ターゲットがマルチプラットフォームの使用をサポートしている場所と、そのサポートを維持するための取引によってインセンティブが変更される可能性があるかどうかを特定する必要があります。

競争の評価では、市場の定義、顧客の選択肢、スイッチングコスト、ロードマップのタイミング、供給アクセス、開発者ツールとデータを調査する必要があります。目標が確立されたプラットフォームへの依存を減らすことができる場合、現在の収益基盤が小さいと将来的な問題が解消されません。分析は、現行法と事実に基づいて資格のある弁護士によって主導される必要があります。

救済策や約束は価値に影響を与える可能性があります。相互運用性、ライセンス、情報の分離、供給、顧客の中立性または無差別に関する要件により、計画された統合や相乗効果が制限される可能性があります。評価には、承認を二者択一のイベントとして扱うのではなく、コスト、遅延、信頼できる結果の戦略的効果を含める必要があります。

プラットフォームの中立性自体が資産になり得ます。顧客は、複数のアクセラレータをサポートしているため、コンパイラ、オーケストレーション レイヤー、またはモデル ツールを重視する可能性があります。 1 つのハードウェア サプライヤーによる買収は、その命題を弱める可能性があります。買い手は顧客やパートナーとの保持をテストし、中立性がキャッシュ フローをサポートするガバナンスを維持する必要があります。

データ、セキュリティ、輸出管理は統合境界を形成できます。顧客のワークロードには、機密モデル、トレーニング方法、個人データ、または規制情報が含まれる場合があります。ベンチマーク アーティファクトとテレメトリは契約によって制限される場合があります。ソース リポジトリには、管理された技術情報、暗号マテリアル、またはサードパーティのコードを含めることができます。購入者は、これらの資産がどこに保管されているか、誰がアクセスできるか、国境を越える方法、およびどの承認が適用されるかをマッピングする必要があります。統合計画では、最小限の特権アクセス、ロギング、分離、およびインシデント対応を維持する必要があります。チーム、ツール、技術の移転計画は、現在の輸出および制裁規則に照らして検討する必要があります。必要な管理に起因するコストと遅延は、トランザクション モデルとクロージング プランに含まれます。

14 資本支出、運転資本、サポート義務を調整する

アクセラレータの開発には、設計、検証、テープアウト、ソフトウェア、システム、インベントリ、認定、およびサポートが必要です。購入者は、メンテナンス、コミットメントされたロードマップ、裁量による成長、および顧客資金による投資を区別する必要があります。発表された資本は、発注書、契約、マイルストーン、支払い、および使用可能な生産高と調整される必要があります。

世代の移行中に在庫リスクが上昇する可能性があります。ソフトウェア、顧客のスケジュール、または新製品が移行すると、チップ、ボード、およびシステムの価値が低下する可能性があります。デリジェンス チームは、在庫をバージョン、顧客、資格、回収可能性、キャンセル権ごとに分類する必要があります。購入コミットメントとサプライヤーの保証金は、中央需要と下値需要の下でテストされる必要があります。

運転資本には、売掛金、クレジット、保証、サポート契約、前払い、容量予約が含まれる必要があります。ハードウェアの出荷は必ずしも最終的な受け入れと一致するとは限りません。キャッシュ フロー モデルには、インストール、受け入れ、使用、サービス クレジット、および回収が反映されている必要があります。

資産計上されるソフトウェアおよび開発費には会計上の検討が必要です。購入者は、経済的寿命と製品のペースおよび顧客の使用状況を調和させる必要があります。購買会計では、現在の基準を使用して、取得した技術、顧客関係、契約、営業権を特定する必要があります [43-47]。会計分類は営業評価に代わるものではありません。

15 統合を通じて顧客の信頼とエンジニアリングの継続性を保護する

統合では、ロードマップ、リリースの品質、顧客の機密保持、セキュリティ、供給、および責任ある決定権を維持する必要があります。顧客は、戦略的購入者が自社製品を優先したり、価格を変更したり、移植性を低下させたり、機密性の高いワークロードにアクセスしたりするのではないかと心配するかもしれません。コミュニケーションでは、統合後の会社が提供できるコミットメントを活用して、継続性、サポート、相互運用性、ガバナンスに取り組む必要があります。

キーパーソンのリスクは経営陣を超えて広がります。アーキテクチャ、検証、コンパイラ、カーネル、フレームワーク、サポート、および顧客の知識は、小規模なチームで担当できる場合があります。保持は、役割、権限、ロードマップ、知識の伝達と関連している必要があります。ドキュメントには、設計上の決定事項、ソース履歴、ビルド システム、ベンチマーク アーティファクト、テスト カバレッジ、既知の欠陥が含まれている必要があります。

提案された管理計画。タイミングは取引の承認と顧客の義務に合わせて調整する必要があります。

統合シーケンスは顧客とリリースのリスクに従う必要があります。コンパイラ、ドライバー、リポジトリ、ビルド システム、またはテレメトリを直ちに変更すると、回帰が発生する可能性があります。購入者は、どのシステムを初日に変更できるか、どのシステムを管理されたテストが必要か、どのシステムを製品または顧客のゲートまで分離しておかなければならないかを確立する必要があります。

16 署名から承認までの展開制御モデルを使用する

署名してから顧客による使用が承認されるまでの間に、大幅な価値の変動が含まれる可能性があります。製品スケジュール、ソフトウェア リリース、ベンチマーク結果、供給配分、顧客プログラムは変化し続けています。管理モデルは、クロージング、統合、および少なくとも受け入れられた導入と収集の最初の監査サイクルを通じた最終的なデリジェンスカットをカバーする必要があります。

モデルは凍結された署名ベースラインから開始する必要があります。各プログラム、作業負荷、構成、ベンチマーク、サービス レベル、価格、供給ルート、必要なスタッフ、資本、予測現金を記載する必要があります。変更はベースラインに対して記録する必要があります。ソフトウェアの回帰、テープアウトの遅れ、供給量の減少、顧客による再設計、価格の再設定などは、報告される収益に反映される前に価値に影響を与える可能性があります。

暫定規約は、法的な運営責任を維持しながら、重要な資産とプログラムを保護する必要があります。売り手は、チーム、ソースリポジトリ、リリース管理、供給権、顧客関係、および通常の資本を維持する必要があります。重要な知的財産権の付与、独占権、ロードマップの変更、キャンセル、または計画外のコミットメントには、適用される法律および交渉された基準に従って、同意が必要となる場合があります。

クロージングの準備には、リポジトリ、ビルド システム、署名キー、ベンチマーク アーティファクト、サポート システム、サプライヤーの連絡先、顧客エスカレーションへのテスト済みのアクセスが含まれる必要があります。購入者は、どの資格情報とデータを転送できるか、同意が必要なもの、分離しておかなければならないものを知っておく必要があります。すべての未解決の依存関係には、所有者と日付付きのアクションが必要です。

17 ディリジェンスの調査結果を価格、条件、統合アクションに変換する

発見によって意思決定が変わるとき、勤勉さは価値を生み出します。すべての重要な発見は、価格調整、構造項目、クロージング条件、契約上の保護、統合措置、または監視されたリスクとして分類される必要があります。分類では、証拠、財務上のエクスポージャー、タイミング、所有者、決定を特定する必要があります。

価格調整により、受け入れられる用途の低下、サポートされていないパフォーマンス、移行コスト、または必要な資本に対処できます。クロージング条件は、顧客の承認、供給の同意、または融資に対処できます。表明、補償、またはエスクローは、特定されたエクスポージャに対処することができます。誓約により、チーム、リポジトリを維持し、規律や供給を解放することができます。統合アクションにより、終了後に制御可能な弱点を修正できます。

表明と保証は、リスクの性質と期間に応じて行われるべきです。 IP 所有権、オープンソース コンプライアンス、ベンチマーク ステートメント、顧客契約、供給権、セキュリティ、輸出管理、財務諸表などをカバーできます。保険は契約上のリスクの一部に対応できます。これは、技術テスト、顧客の証拠、または資金提供された統合計画に代わるものではありません。

最終的な投資文書では、ヘッドライン価格、純負債、運転資本、条件付対価、保持、取引コスト、統合資金を調整する必要があります。独立した価値、購入者固有の価値、および対価を同じ基準で提示する必要があります。それぞれの主要なディリジェンスの調査結果がモデルや条件をどのように変更したかを示す必要があります。

結論

AI アクセラレータ トランザクションは、半導体、ソフトウェア、システム、顧客、プラットフォームの経済性を組み合わせます。信頼できる評価は、測定されたシリコン、成熟したソフトウェア、顧客導入、受け入れられた使用、および回収された現金を介して、制御された権利と供給に至る再現可能なチェーンをたどります。ピーク仕様と選択されたベンチマークがコンテキストを提供します。動作価値をサポートする前に、ワークロード、精度、遅延、電力、およびシステムの証拠が必要です。

最強のプラットフォームは、関連する顧客の状況全体にわたって有益な作業を経済的に提供します。再現可能なパフォーマンス、コンパイラとライブラリの成熟度、管理可能な移行、信頼性の高い供給、顧客の信頼、資金提供されたロードマップを組み合わせています。そのプレミアムは、1 回のテスト結果や製品サイクルではなく、反復可能な導入と耐久性のある制御に由来します。

取引規律は実践的です。アセットを定義します。負荷がかかった状態でパフォーマンスを再構築します。価格の完全なシステムの経済学。ソフトウェアの到達範囲と移行をテストします。お客様の使用状況を確認します。供給とロードマップの依存関係をマップします。受け入れられた現金からの価値のあるプログラム。個別の購入者の相乗効果。証拠の成熟度に一致する用語を選択してください。展開を終了して受け入れられるまで、1 つの管理されたベースラインを維持します。

情報源

1. MLCommons、MLPerf 推論ベンチマーク スイート、 一次ソースを読む
2. MLCommons、MLPerf 推論提出ガイド、 一次ソースを読む
3. MLCommons、MLPerf エンドポイント ベンチマーク、 一次ソースを読む
4. MLCommons、MLPerf 推論電力測定、 一次ソースを読む
5. MLCommons、MLPerf Inference v5 言語モデル ベンチマーク、 一次ソースを読む
6. NVIDIA、Form 10-K の 2026 年年次報告書、 一次ソースを読む
7. NVIDIA、2026 年年次報告書および委任状資料、 一次ソースを読む
8. NVIDIA、2026 会計年度第 4 四半期の業績、 一次ソースを読む
9. NVIDIA、CUDA プラットフォームのドキュメント、 一次ソースを読む
10. NVIDIA、TensorRT ドキュメント、 一次ソースを読む
11. Advanced Micro Devices、Form 10-K による 2025 年年次報告書、 一次ソースを読む
12. Advanced Micro Devices、ROCm ドキュメント、 一次ソースを読む
13. Advanced Micro Devices、データセンター、Instinct 製品の開示、 一次ソースを読む
14. アドバンスト・マイクロ・デバイス、年次報告書および提出書類、 一次ソースを読む
15. インテル、Form 10-K に関する 2024 年年次報告書、 一次ソースを読む
16. Intel、Gaudi アクセラレータのドキュメント、 一次ソースを読む
17. Google Cloud、TPU ドキュメント、 一次ソースを読む
18. アマゾン ウェブ サービス、Trainium ドキュメント、 一次ソースを読む
19. Microsoft、Maia AI アクセラレータの概要、 一次ソースを読む
20. メタエンジニアリング、MTIAアクセラレータープログラム、 一次ソースを読む
21. OpenXLA、コンパイラプロジェクトドキュメント、 一次ソースを読む
22. LLVM プロジェクト、コンパイラ インフラストラクチャのドキュメント、 一次ソースを読む
23. ONNX、オープンモデル交換ドキュメント、 一次ソースを読む
24. PyTorch、コンパイラのドキュメント、 一次ソースを読む
25. TensorFlow、XLA ドキュメント、 一次ソースを読む
26. オープン コンピューティング プロジェクト、OCP アクセラレータ モジュールの基本仕様、 一次ソースを読む
27. UCIe コンソーシアム、仕様リソース、 一次ソースを読む
28. PCI-SIG、Compute Express Link リソース、 一次ソースを読む
29. JEDEC、高帯域幅メモリ標準リソース、 一次ソースを読む
30. 台湾積体電路製造会社、2025 年年次報告書、 一次ソースを読む
31. Amkor Technology、年次報告書および提出書類、 一次ソースを読む
32. ASE Technology Holding、年次報告書、 一次ソースを読む
33. 米国国立標準技術研究所、AI リスク管理フレームワーク、 一次ソースを読む
34. 米国国立標準技術研究所、AI 標準化取り組み計画、 一次ソースを読む
35. 米国商務省、CHIPS for America、 一次ソースを読む
36. 米国産業安全保障局、輸出管理規制、 一次ソースを読む
37. 米国司法省および連邦取引委員会、2023 年の合併ガイドライン、 一次ソースを読む
38. 米国司法省、優越的地位の確立または拡大に関するガイドライン 6、 一次ソースを読む
39. 米国司法省、多面的なプラットフォームに関するガイドライン 9、 一次ソースを読む
40. 連邦取引委員会、ハート・スコット・ロディノ合併前通知プログラム、 一次ソースを読む
41. 欧州委員会、水平合併ガイドライン、 一次ソースを読む
42. 欧州委員会、デジタル市場法、 一次ソースを読む
43. IFRS財団、IFRS第3号企業結合、 一次ソースを読む
44. IFRS財団、IAS第38号無形資産、 一次ソースを読む
45. IFRS財団、IAS第36号資産の減損、 一次ソースを読む
46. IFRS財団、IFRS第13号公正価値測定、 一次ソースを読む
47. 財務会計基準審議会、トピック 805 企業結合、 一次ソースを読む
48. 世界知的所有権機関、知財評価、 一次ソースを読む
49. OECD、デジタル経済における競争、 一次ソースを読む
50. MLCommons、ベンチマーク作業グループとガバナンス、 一次ソースを読む