AI推論インフラはなぜ急拡大するのか｜2026年9月の実績・メモリ・電力・コストを読む

1．いまAI推論インフラに注目する理由

AIの話題は、モデルがどこまで賢くなったかに集中しがちです。一方で、そのモデルを毎日使えるサービスにするには、返答のたびに計算する設備が必要です。この「使うための計算」を支えるAI推論インフラが、2026年9月時点で大きな需要と技術競争を確認できるテーマになっています。ここで扱うのは、半導体、メモリ、ネットワーク、ストレージ、電源、冷却、そしてそれらを動かすソフトウェアです。

注目度を確かめるため、本記事では企業の決算、設備投資の発表、調査会社の予測、共通ベンチマークの更新を調べました。これらは測っている対象が異なります。売上が増えた事実と、将来の利用が増えるという予測を一つの証拠として扱わず、読者がそれぞれの意味を確認できるように整理します。

AI分野の全トピックを同じ条件で比較した世界ランキングは、今回の資料からは作れません。そのため「世界で一番」と断定する代わりに、複数の独立した指標で需要の大きさを検証できる分野として選びました。検索数、利用者数、設備売上、投資額は互いに代替できず、どの指標を重視するかによって評価も変わります。

本記事の中心は、サービスの返答速度や利用コストが、どの設備条件によって決まるかです。モデルの性能ランキングや、AIアプリの操作方法は扱いません。設備を購入する担当者だけでなく、AIサービスを利用する会社の企画担当者も、見積もりや速度の説明を読み解けることを目標にしています。

出典：NVIDIA：FY2027第2四半期決算（2026年8月26日） ／ AMD：2026年第2四半期決算（8月4日） ／ Gartner：AI最適化IaaS支出予測（2026年8月10日） ／ MLCommons：MLPerf Inference v6.1発表（2026年9月16日）

2．実績・計画・予測を一枚の表で分ける

まず、需要の裏付けを並べます。金額は発表元の通貨のままとし、変動する為替で円換算して規模を誇張することは避けました。billionは10億なので、たとえば89.0 billion dollarsは890億ドルです。表の数字を合算して「世界のAI市場」とすることもできません。部品の売上とクラウド利用料には重複が生じる可能性があり、対象期間も一致していないためです。

小さな画面では表を横にスクロールできます。

出典：NVIDIA：FY2027第2四半期決算（2026年8月26日） ／ AMD：2026年第2四半期決算（8月4日） ／ Google：フィンランドへの投資計画（2026年9月9日） ／ Gartner：AI最適化IaaS支出予測（2026年8月10日） ／ MLCommons：v6.1結果分析（2026年9月17日）

この表から本記事が読み取るのは、設備の販売、クラウド消費の見通し、測定手法の整備という別々の側面で推論基盤への関心が強まっていることです。これは編集部による資料の解釈です。各社の決算だけから「利用者の大半が推論を使う」「すべての投資が回収できる」といった結論は導けません。

設備売上が増えても、購入された機器の稼働率まではわかりません。投資計画が大きくても、開通する電力、工事の進み方、サービスの販売状況によって実際の供給は変わります。読者が今後のニュースを見る際も、「いくら発表したか」と「何が動き始めたか」を別々に記録すると、熱量と実態の距離を確認できます。

3．NVIDIAとAMDの決算で確認できること

NVIDIAのFY2027第2四半期の全社売上は962億ドルでした。そのうちData Centerは890億ドルです。発表は2026年8月で、対象四半期も2026年に終了しています。「FY2027」という会計年度の呼称を、2027年の未来の実績と読み違えないことが大切です。この区分にはデータセンター向けの幅広い製品が含まれ、推論だけを切り出した市場規模にはなりません。

出典：NVIDIA：FY2027第2四半期決算（2026年8月26日）

AMDの2026年第2四半期では、Data Center部門売上が67.18億ドルとなり、前年同期比107%増でした。説明ではEPYCサーバーCPUとInstinct GPUの需要が挙げられています。GPUだけの金額でも、特定モデルを動かした推論利用料でもありません。CPUを含む部門が伸びている点は、AI基盤をGPU一種類の話だけで理解しないための材料になります。

出典：AMD：2026年第2四半期決算（8月4日）

両社の数字は、それぞれの会社で前年同期から拡大したことを示します。しかし、製品構成も決算期間も異なるので、二つを割り算して世界シェアを算出することはできません。同じ「Data Center」という名称であっても、販売対象が完全に一致するとは限りません。

発注や契約を検討する立場では、売上の勢いよりも、必要な機器の供給条件、保守、利用できるソフトウェア、要求する性能を満たすかが直接の判断材料になります。決算は市場の動きを確認する入口として使い、購入候補の性能を証明する資料とは分ける。この読み方なら、企業の好調さと自社にとっての適合性を混同せずに済みます。

4．推論が学習を上回るという予測の正確な意味

Gartnerは2026年8月の発表で、同年のAI最適化IaaS支出のうち推論を233億ドル、学習を190億ドルと予測しました。推論の構成比は55%という見通しです。これは特定のクラウド基盤市場についての年間予測であり、2026年の支出がすべて確定したという意味ではありません。

出典：Gartner：AI最適化IaaS支出予測（2026年8月10日）

この予測を読むときには、金額、構成比、増加率を区別します。55%が支出の構成比として書かれている箇所と、成長に関する見出しは、意味を確認して読む必要があります。また、学習の設備需要が消えるという説明でもありません。推論が大きくなる予測と、学習も大きな市場であることは同時に成立します。

企画担当者にとっては、「今後は推論向けの購入が増えるから自社も買う」という使い方より、「常時提供するサービスの運用費を別枠で見積もる」という使い方が有用です。試作時には小さかった呼び出し回数が、公開後に日々の費用へ変わります。導入費だけを稟議に書き、継続利用の費用をゼロ扱いすると、サービス開始後に予算の説明が難しくなります。

編集部の整理では、開発費、公開前の評価費、公開後の推論費、監視と運用の費用を分けると、予測の不確実性を扱いやすくなります。それぞれに利用量の前提を置き、少ない場合と多い場合を計算すれば、市場全体の予測が外れたときも自社の判断を更新できます。市場の成長率をそのまま自社の必要台数に掛ける方法は使いません。

5．Googleの130億ユーロ計画が示す設備の広がり

Googleは2026年9月9日、フィンランドで今後2年間に130億ユーロを投じる計画を発表しました。対象はデジタルインフラ、エネルギー、地域との取り組みを含み、Search、Maps、Geminiなどを支える説明になっています。全額が推論専用設備に使われるとも、すでに支出されたとも発表していません。

出典：Google：フィンランドへの投資計画（2026年9月9日）

この発表を設備の観点で読むと、AIを届けるためにはチップの調達以外の工程が必要であることが見えてきます。施設を使える状態にし、電力を供給し、ネットワークにつなぎ、運用できる人と仕組みを用意する。設備を増やすニュースでは、それぞれの完成時期が同じかどうかを確かめる必要があります。

たとえば会社がクラウドの利用枠を予約した場合でも、使いたい場所で希望する機器がすぐ借りられるとは限りません。ある地域で供給が増える計画と、自社が必要とする地域の空き容量は別の情報です。データの保存場所、通信遅延、障害時の代替先も含めて、サービスとして使える条件を確認します。

本記事は投資先の社会的評価や政策の是非を論じるものではありません。設備計画の対象と期間を確認し、AIサービスの供給に必要な条件を理解するために扱っています。大きな金額の発表を読んだら、対象、期間、計画か実績か、利用開始の条件という四つの欄に書き分けると、他の発表とも比較しやすくなります。

6．推論の内部には「読む処理」と「出す処理」がある

一般的な自己回帰型のLLMでは、入力を処理するprefillと、出力を順に生成するdecodeを区別します。前者では入力の情報を計算し、後者では直前までの情報を使いながら次のトークンを生成します。推論の説明で二つをまとめて「GPUで計算する」と書くと、何を改善すれば速くなるかが見えにくくなります。

出典：NVIDIA：LLM推論の最適化・技術解説

ここからは設備を見るための編集部による整理です。長い資料を渡して短く答えさせる仕事では、入力処理に注目します。短い質問から長文を出す仕事では、生成を続ける時間に注目します。同じモデルでも、二つの仕事を同一の試験として測ると、必要な設備条件を取り違える可能性があります。

問い合わせを受け付ける処理、順番待ち、出力の表示も利用者の待ち時間に含まれます。GPU内の処理が改善しても、待ち行列が伸びていたら最初の返答は遅くなります。逆に、最初の文字がすぐ出ても、その後の生成が遅いと長い回答を待つ時間は改善しません。調査時には、どの区間の数字なのかを先に確かめます。

本記事では、実在サービスでこの性能を実測したとは主張しません。公開されている技術の仕組みを説明し、実際に比較する際の記録項目を提案しています。将来、自社で評価する場合には、入力の長さ、出力の長さ、同時実行数、キャッシュの状態を揃えたうえで、工程別の測定結果を残してください。

7．GPU・専用チップ・CPUを役割で比較する

Googleは第8世代TPUとして、学習を主に想定したTPU 8tと、遅延に敏感な推論を主に想定したTPU 8iを発表しました。設計を分けた理由の一つに、推論で求められるメモリ帯域を挙げています。両方が他の処理を一切実行できないという説明ではありません。発表時点の提供予定と、現在の利用可能地域は分けて確認する必要があります。

出典：Google：第8世代TPUの設計と提供予定（2026年4月22日）

小さな画面では表を横にスクロールできます。

表は製品の勝敗を示すものではありません。どの部品についても、利用したいモデルが動くことが最初の条件です。次に必要な応答速度と品質を確認し、その条件を満たすときの総費用を比べます。公表された最大性能だけで候補を順位付けしても、実行ソフトや処理条件が違えば、サービスの速度を予測できません。

CPUは、GPUの販売ニュースに比べると話題の中心から外れがちです。しかし見積もりを読むときには、受付や前後処理、運用に必要なホストも含めて確認します。GPUの費用しか計上していない案と、サービス全体を含む案を比較すると、価格の差を誤って評価することになります。

専用チップを検討する場合は、移行時に必要な作業を別の項目にします。既存の実装をどれだけ変更するか、変更後に品質を再評価するか、担当者が運用できるかを確認するためです。設備の利用料が下がる可能性と、移行の工数が発生することは両方書けます。採用判断は、予測した効果を実際の条件で検証してから行います。

8．HBMは「入る量」と「運ぶ速さ」を分けて読む

Micronは2026年3月16日、36GB・12層のHBM4について量産出荷を発表し、帯域が2.8TB/sを超えると説明しました。容量は保持できる量、帯域は単位時間に運べる量を表します。この帯域は同社の製品に関する発表値で、アプリ全体がその速度で動くと保証するものではありません。

出典：Micron：HBM4の量産出荷発表（2026年3月16日）

二つの指標を身近な例で理解するなら、保管場所の広さと、そこから物を取り出す速さの違いです。保管場所が広くても取り出しが遅ければ待ち時間が生まれます。取り出しが速くても必要な物が入らなければ、別の場所に分けて置く設計が必要です。これは概念を説明するたとえで、実機の性能を換算する式ではありません。

設備検討の資料では、モデルの重みだけでメモリを見積もっていないかを確認します。実行時には処理に必要な領域も使います。利用者が同時に増えたとき、入力が長くなったときの余裕を計上しなければ、平常時には動いてもピーク時に条件を満たさない案になり得ます。必要容量の説明には、どの条件で算出したかを添えるべきです。

容量の単位がGBかGiBかにも注意します。数字の見た目が同じでも、単位の定義が異なれば厳密な比較には調整が必要です。また、チップ一個の仕様と、サーバー一台やラック全体の仕様を取り違えないようにします。比較表には測定対象の欄を置き、「一個」「一台」「複数台」のどれを示すか記載します。

仕様表の大きな数字を見て購入を決めるより、必要なモデル、同時実行、速度条件を満たす構成で見積もりを取る方が判断しやすくなります。HBMの進化は重要な技術材料ですが、その製品が自社の必要条件に合うかは、ソフトウェアと他の部品を含む構成として評価します。

9．KVキャッシュが長い入力と同時利用を結び付ける

KVキャッシュは、生成の際に過去のトークンについて計算した情報を再利用するための仕組みです。Hugging Faceの資料では、キャッシュの保持方法、メモリへの退避、量子化などの選択肢を説明しています。モデルの重みとは別に、実行中の情報を置く容量が必要になります。

出典：Hugging Face：KVキャッシュの戦略

設備の検討では「モデルが一回動いた」という確認から、同時利用を前提とする確認へ進みます。実務で必要なのは、長い入力が複数同時に来る条件でも、要求する速度で動くかです。長い入力の上限を製品が掲げていても、その上限の入力を多数同時に処理する能力まで同じ数字からはわかりません。

編集部が提案する記録項目は、入力長、出力長、同時実行数、モデル、キャッシュの形式、空きメモリ、失敗件数です。一件だけの試験と複数件の試験を分け、増やしたときに何が変わったかを比較します。最大の入力を使う試験だけでなく、日常的な入力と、ときどき来る長い入力を混ぜた試験も設計します。

キャッシュを別の場所に置く設計を評価する場合には、節約した容量と追加された待ち時間を両方測ります。退避によって動かせる処理が増えても、速度の条件を外れるなら、そのサービスには適さない可能性があります。容量の改善、速度の改善、同時利用の改善を一つの「性能向上」にまとめず、別々に記録することが大切です。

この章の内容は、特定のモデルやソフトウェアを実機で評価した報告ではありません。測定の設計を考えるための整理です。実装によってキャッシュの形式や挙動が変わるため、構築を担当する人は使用するバージョンの公式資料を確認し、その条件を評価レポートに残してください。

10．ストレージは容量だけでなく、待ち時間を見積もる

推論基盤のストレージを考えるとき、本記事では三つの用途を分けます。モデルなどを継続して保存する場所、サービスが参照するデータの保存場所、実装が対応している場合のキャッシュ退避先です。同じSSDを使っていても、読み込むタイミングや必要な速度は異なります。Micronの発表も、メモリとデータセンター向けSSDを別の製品として説明しています。

出典：Micron：HBM4の量産出荷発表（2026年3月16日）

見積もりの段階では、保存量だけの計算を終えたら、読み出す回数と同時アクセスを確認します。大量の情報を保存できる構成と、利用者が待たずに必要な情報を読める構成は同じとは限りません。特にサービス開始や再起動時に、モデルを使える状態にするまでどれだけ時間がかかるかは、定常稼働中の速度とは別に記録します。

計画の例として、日中に止められないサービスなら、再起動の間に代替の実行先を使えるかを確認します。毎日決まった時間にだけ実行する仕事なら、起動時間を含めて締め切りに間に合うかを確認します。これらは読者が設計する際の例であり、特定の顧客で実施した事例ではありません。

SSDの最大読み出し性能が高いという説明を、サービスの返答が同じ割合で速くなるという説明に置き換えることはできません。どこでデータを待っているかを測り、その区間が全体のどれだけを占めるかを確認します。処理の別の区間が時間を使っているなら、ストレージの更新だけでは期待する改善が出ないことがあります。

運用担当者と見積もりを読む人の間では、容量、定常時の速度、起動時間、障害時の復旧時間を四つの欄に分けると話しやすくなります。一つの最大値を共有するより、どの条件でサービスを続けられるかが明確になります。これが、設備の仕様を利用者の体験に結び付けるための確認方法です。

11．ネットワークは推論の処理分離で重要になる

NVIDIA Dynamoの資料では、prefillとdecodeを別のエンジンで処理し、KVキャッシュを受け渡す構成を説明しています。入力処理と生成処理の必要条件に合わせて設備を割り当てる考え方です。その構成では、キャッシュの転送が効率よく行えることが性能上の要点になります。

出典：NVIDIA Dynamo：prefill・decodeの分離

ここからの比較手順は編集部の提案です。分離する構成と、同じ設備で処理する構成を比べるときには、計算の効率だけでなく、転送、待ち時間、運用の複雑さも含めます。利用量が少ない場合と多い場合、入力が短い場合と長い場合で、結果が同じになるとは限りません。単一の条件だけを測って全体の優劣を決めないようにします。

回線の仕様表も、最大帯域だけでは十分ではありません。必要なデータがどの経路を通るか、他の通信と混雑を共有するか、障害時に経路が変わるかを確認します。複数のサーバーを組み合わせる案では、サーバーの台数を増やしたときに転送量がどう変わるかを書いておくと、見積もりの漏れを探せます。

ネットワーク利用料が別料金なら、設備利用料だけを比較しても総費用は揃いません。見積もりでは、サービス外との通信と、実行基盤内の通信を分け、課金条件を確認します。特定の会社の料金を推測で書くのではなく、対象地域と契約で有効な料金表を取得して計算します。

新しい構成を採用する判断は、説明図が複雑か簡単かでは決まりません。必要な品質と速度を達成でき、運用できる人と仕組みがあり、総費用を説明できるかで決めます。処理分離は検討する選択肢の一つとして扱い、自社の条件で改善が確認できたときに採用する、という手順が適しています。

12．電力需要の485TWhと950TWhを読み違えない

IEAの2026年版資料では、世界のデータセンターの電力消費を2025年の485TWhから、2030年には950TWhへ増える中心的な見通しとして示しています。前者は過去の消費についての推計、後者は将来の予測です。また、この数字はデータセンター全体で、AI推論だけの電力ではありません。

出典：IEA：Key Questions on Energy and AI・要約（2026年4月16日／CC BY 4.0）

TWhは電力量の単位で、ある期間に使った量を表します。施設の受電能力などに使うMWという電力の単位と、そのまま比較しないようにします。設備のニュースでは、能力、実際の消費量、将来の需要予測が混在しやすいため、単位と期間をまず確認してください。

この資料を自社の設備検討に使うなら、国際的な電力需要の見通しを自社の請求額へ直接換算する方法は適切ではありません。必要なのは、選んだ構成が実際に使う電力と、対象地域・契約の料金です。GPU一個の上限値だけでは、ホスト、ネットワーク、ストレージ、冷却などを含む施設全体の電力を表しません。

編集部が提案する確認事項は、必要な受電能力、供給開始の時期、ピーク時の余裕、停止時の対応です。購入したサーバーが届いても、施設側の準備が整っていなければ使い始められません。設備を発注する前に、利用開始の条件を工程表に並べ、どの項目が日程を決めるか確認します。

電力については、政策への賛否や理想像ではなく、処理を実行するための物理的条件として扱います。予測は更新されるため、数字を固定的な未来として使わず、実際の供給と利用がどう進んだかを継続して確かめます。これにより、成長のニュースも制約のニュースも、同じ基準で読み解けます。

13．冷却はGPUを動かし続けるための設備条件

Googleの第8世代TPUの発表は、チップだけでなく液冷を含むシステム設計も説明しています。高い処理性能の説明と、冷却の条件の説明を一緒に読むことが重要です。チップ単体の性能値が示されていても、施設の冷却能力を超えた状態で同じ性能が持続するかは、別の確認が必要になります。

出典：Google：第8世代TPUの設計と提供予定（2026年4月22日）

設備の見積もりでは、空冷か液冷かという名前だけで結論を出さず、対象のサーバーに必要な仕様を確かめます。冷却方式ごとに接続、監視、保守の条件を確認し、現在の施設で対応できる項目と追加工事が必要な項目を分けます。液冷という言葉から水の消費量や省電力効果を一律に推測することはしません。

企画担当者には、冷却の工事費を設備の本体価格とは別に見ることを提案します。サーバーが安く見えても、施設の改修が必要なら総額は変わります。逆にクラウドサービスを利用する場合には施設設備の費用が利用料に含まれることがありますが、どの範囲まで含まれるかは契約で確認します。

性能試験では、短い処理が一回終わる条件と、利用が続く条件を分けます。最初の数分だけ良い数字が出るか、業務で必要な時間にわたって条件を満たすかでは、設備としての意味が違います。温度や電力の記録を、処理件数や待ち時間の記録と同じ時刻で残すと、変化の原因を調べやすくなります。

冷却設備の設計は、一般的なブログの計算例だけで決めるものではありません。実際に構築する場合は、機器と施設の担当者が必要条件を確認します。読者がここで持ち帰るべき点は、「計算能力がある」ことと「その能力を継続して利用できる」ことを、同じ確認項目にしないということです。

14．返答速度は最初の一文字・生成速度・完了時間で見る

推論の速度指標には、最初のトークンまでの時間であるTTFT、出力中のトークン間隔であるITL、すべての応答が完了するまでの時間があります。NVIDIAの測定解説は、TTFTに待ち行列、prefill、通信などが含まれること、指標の定義がツールによって異なる点を説明しています。

出典：NVIDIA：LLM推論ベンチマークの指標（2025年4月2日）

小さな画面では表を横にスクロールできます。

編集部が勧めるのは、一つの平均値だけで合否を決めない方法です。平均が良くても、一部の要求に大きな遅れが生じる場合があります。平均、中央値、遅い側の分位点、最大値、失敗件数を分けて残せば、利用者が待つ状況を説明しやすくなります。p95は、おおむね95%の観測がその値以下に収まる境界として読む指標です。

「毎秒何トークン」という数字を見る際には、一人の返答速度か、複数の要求を合計した量かを確認します。さらに、モデルが違えば文章の分割方法も変わるため、同じトークン数が同じ文字数を意味するとは限りません。用途の違う測定値を一列に並べて順位付けすることは避けます。

たとえば、読み始めるまでの速さが重要なサービスと、締め切りまでに大量の結果を処理する仕事では、求める条件が変わります。利用者が許容できる時間を先に定め、条件を満たす構成同士で費用を比較します。設備側の数字に合わせて利用者の要求を書き換えるのではなく、要求に合う測定を選ぶことが大切です。

15．9月のMLPerf更新を、性能比較にどう使うか

MLCommonsは2026年9月16日にMLPerf Inference v6.1の結果を発表しました。翌日の分析では30提出組織と120システムを示し、新しい評価としてEnd-to-End RAGとAgentic Edge Inferenceを説明しています。本記事が注目するのは、AIモデル一回の実行だけでなく、処理全体や複数段階の実行を測る方向に評価が広がった点です。

出典：MLCommons：MLPerf Inference v6.1発表（2026年9月16日） ／ MLCommons：v6.1結果分析（2026年9月17日）

結果を使う際には、同じモデル、同じシナリオ、同じ部門で比較します。MLCommonsは、ClosedとOpen、購入やクラウド利用が可能なAvailableと、将来の提供に関するPreviewなどの区分を説明しています。現在調達できる構成と、今後の構成が同じ表に載ることがあるため、提供区分も確認してください。

出典：MLCommons：Datacenterの測定・公開区分

編集部の比較手順は、候補の結果を見つけたら、まず条件を記録し、次に自社の条件との差を書き出す方法です。異なる入力長、並列数、品質条件で高い数字が出ていても、そのまま自社のサービスに適用できるとは限りません。結果は候補を絞る材料にし、最終的な合否は自社で必要な条件に合わせて確かめます。

また、公開結果には、対象の試験で測った数値と、説明欄に記載された機器の仕様があります。電源の定格や部品の消費電力の上限を、処理全体の実測電力と同じ意味で読まないようにします。MLCommonsの電力測定の説明では、測定結果が該当ベンチマークに対して有効であることも確認できます。

本記事は、v6.1の結果から一社を総合優勝とするランキングを作っていません。読者が自分の目的と同じ試験を探し、提供区分や測定条件を確認することに重点を置いています。新しい評価項目が増えたことと、すべての実務を再現できることも分けて理解します。

16．最適化は、何を削減したかを説明できる形で評価する

vLLMのAutomatic Prefix Cachingは、入力の先頭部分を共有する要求で、既存のKVキャッシュを再利用する仕組みです。公式資料は、入力処理の時間を減らす一方、新しいトークンを生成するdecodeの時間を直接減らすものではないと説明しています。入力を共有しない条件では、同じ効果を期待できません。

出典：vLLM：Automatic Prefix Caching

編集部の評価案では、キャッシュを使う試験と使わない試験を別に記録します。実際の利用でどれだけ入力が共通するかを確認し、試験のために共通部分を増やして見栄えの良い数字を作らないことが大切です。毎回違う内容が来るサービスなら、その条件を代表する入力で測ります。

量子化を検討する場合には、削減したメモリや改善した速度とともに、必要な品質を保てるかを確認します。処理量を増やす工夫についても、待ち時間の条件を満たすことが必要です。最適化の名称を導入したという事実だけで合格にせず、変更前後で同じ条件を使い、良くなった項目と悪くなった項目を記載します。

推論ソフトウェアを含めた最適化については、NVIDIAのDynamoの技術解説も、処理全体を構成する仕組みを扱っています。部品を一つ更新した効果と、複数の変更をまとめた効果を分けて測ることが、再現できる評価に必要です。どの変更が結果に影響したかを残さなければ、別の環境で同じ数字を期待できません。

出典：NVIDIA：Dynamoによる推論処理全体の最適化

実施順の例は、基準となる構成を測り、変更を一つ加え、品質と速度を測り直し、採用するか決めるというものです。改善が小さい場合には、運用が複雑になる負担も計算します。設備費の節約だけでなく、変更後の検証と監視に必要な工数まで含めて、採用する理由を説明できるようにします。

17．API・専有クラウド・自前設備の費用範囲を揃える

推論基盤を自社で購入することだけが選択肢ではありません。サービスのAPIを呼び出す、クラウドで実行基盤を確保する、自前の設備で動かすという方法を、費用の範囲を揃えて比較します。以下は編集部による比較の枠組みで、個別サービスの価格表や機能保証ではありません。実際の料金は契約地域、期間、構成、利用量を指定して確認してください。

小さな画面では表を横にスクロールできます。

APIの方式では、利用しない時間の設備を直接確保しない設計にできますが、契約するサービスの制限や課金条件を確認します。専有クラウドでは、使っていない時間も確保するのか、必要なときだけ確保できるのかで費用が変わります。自前の設備では、購入後に利用量が減っても、保有と運用に必要な費用を考える必要があります。

どの方式でも、同じ仕事を完成させるための費用に揃えると比較がしやすくなります。失敗してやり直した分を除外した費用と、再実行を含む費用を同じ表で比べないようにします。一定の品質を満たして完了した件数を定義し、その件数を分母にする方法なら、安価でもやり直しが多い構成を見分けられます。

本記事では、現在の料金を確認していないサービスについて、特定の単価を記載していません。次の章では仮の数字を置き、計算方法だけを示します。見積もりを作る際には、その数字を自社が実際に取得した料金と測定結果へ置き換えます。単位と費用の範囲が揃っていれば、価格が変わっても計算を更新できます。

18．独自計算：単価と利用量を分けた費用比較

以下は説明用の仮定です。実在サービスの料金、性能、請求実績ではありません。API案を入力100万トークンあたり2ドル、出力100万トークンあたり8ドル、専有基盤案を一時間5ドルと置きます。月の入力を1億、出力を2,000万トークン、専有基盤の確保時間を720時間と仮定します。通貨はドルで揃え、税、通信、運用などはこの段階では含めません。

小さな画面では表を横にスクロールできます。

この条件で小計が10倍違うことは計算できます。しかし「専有基盤は10倍の利用量で必ず得になる」という結論にはなりません。専有基盤がその量を処理できるか、必要な応答速度を保てるか、APIの料金や割引がどう変わるかを、まだ確認していないためです。算術上の一致点と、実際の採算条件を分けます。

この例の目的は、固定的な費用と利用量に連動する費用を分けて考えることです。利用量が少ない月と多い月の両方を計算し、何が変わると案の評価が変わるかを示します。運用費、通信費、保守費が加わったら、その項目を同じ費用範囲に足して比較します。計算の前提が変わった場合も、どこを変更したかが見える表にします。

別の仮定として、月の総費用が1,000ドル、要求した仕事が10万件、そのうち品質条件を満たして完了したものが8万件なら、一件の完了あたり費用は0.0125ドルです。要求件数で割った0.01ドルとは意味が異なります。完了をどう定義するかによって費用比較が変わることを、この例から確認できます。

自社の計算では、完了の判定基準を先に決めます。正解かどうか、必要な形式か、時間内に終わったかという条件を明確にし、失敗や時間切れを別に数えます。改善後に判定基準を緩くして費用が下がったように見せないことも大切です。数値は条件と一緒に記録して初めて比較の材料になります。

19．独自計算：平均とピークを分けて容量を考える

ここも説明用の仮定です。一日に10万件の要求があり、全件を24時間に均等に分けると、一秒あたり約1.16件になります。ところが10万件のうち4万件が2時間に集中する場合、その2時間の平均は一秒あたり約5.56件です。一日平均だけで設備を計画すると、この時間帯の必要量を見落とします。実際のサービスでこの分布を観測したという報告ではありません。

さらに、2時間の内部で要求が偏れば、短い時間のピークは5.56件を超える可能性があります。どの時間幅で需要を集計したかを記録することが必要です。日単位、時間単位、分単位の平均は、同じものを表していません。利用者の集中が短時間で起きるサービスでは、短い時間幅のデータで条件を検討します。

一件を処理する時間も固定とは限りません。入力や出力の長さが異なるなら、要求件数だけでは処理量を表せません。編集部の提案では、要求件数とともに入力・出力の分布を記録し、普段の要求、長い要求、重なった要求を区別します。設備が混雑したときに何を待たせるか、何を時間切れとして扱うかも、サービス設計の項目にします。

余裕を確保する場合も、根拠なく一律に倍の設備を購入する方法は使いません。利用の集中、障害時に減る容量、起動に必要な時間など、余裕が必要になる理由を列挙します。その条件を満たす案を検証し、予測が変わったら調整できる契約かを確認します。

以上の計算例は、利用量の予測を設備台数へ直結させるものではありません。必要量を整理する入口です。台数を決めるには、同じ品質と速度の条件で一台や一構成がどれだけ処理できるかを測定し、複数に増やした場合の挙動も確認します。予測、算術、測定、採用判断を四つの段階に分けると、何がまだ不明なのかを説明できます。

20．導入前の評価手順：同じ仕事を、同じ条件で測る

ここでは編集部が提案する評価の手順を示します。記事作成時に有料GPUを借りたり、実機にモデルを配備したりして計測した結果ではありません。記事中の画面画像は一次資料をブラウザで確認した記録です。性能の実測と、公開資料の確認を混同しないために、実施した作業の範囲を明示しています。

1. 要件を書く。 必要な仕事、品質、最初の出力までの時間、完了までの時間、想定する利用量を定める。
2. 代表する入力を揃える。 短い・長い・通常の入力と出力を分け、候補ごとに同じ組み合わせを使う。
3. 基準となる構成を測る。 モデルとソフトウェアの版、機器、地域、キャッシュの状態を記録する。
4. 同時実行を増やす。 平常時とピーク時の条件で、速度、失敗、使用容量、実測できる電力を記録する。
5. 完了件数で費用を比較する。 必要な品質と時間を満たした件数を使い、再実行と運用を含む範囲を揃える。
6. 変更と再測定を行う。 最適化は一つずつ評価し、採用理由と残る条件をレポートにまとめる。

サンプルは、自社の仕事を代表することが大切です。短い質問だけで測って、長い資料を処理するサービスへ結果を適用しないようにします。試験用の入力が同じでも、キャッシュが温まった状態だけを測った候補と、初回の状態を測った候補では条件が揃いません。試験の順番とキャッシュの状態も記録します。

評価結果には、成功した結果だけでなく、失敗した要求、応答が途中で止まった要求、時間切れを含めます。速度の集計から失敗を除外した場合には、その扱いを明記します。失敗を除けば平均が良く見えることがありますが、サービスを利用する側の問題は残ります。

費用については、試験をした時間と通常運用する時間の違いを確認します。短い試験で得られた処理性能を、24時間の利用料へ直ちに換算しても、起動、待機、ピーク対応、保守の条件は未確認です。見積もりには未確認の項目を残し、採用前に必要な確認を終えるようにします。

評価の記録は、後で別のモデルや設備を検討するときにも役立ちます。結果だけを保存するのではなく、入力の分布、品質の判定方法、測定した区間、構成、課金の範囲をセットにします。これなら、価格やソフトウェアが更新されても、前回と同じ基準で比較し直せます。

21．稼働率と障害対応を、性能表の外に置かない

性能の比較が終わったら、実際に使い続ける条件を確認します。編集部が提案する運用評価は、通常時、利用が集中する時、設備の一部が止まる時、再起動する時という四つの状態を分ける方法です。最大性能の数字は、すべての状態で同じサービスを続けられる証明にはなりません。

自前の設備を使う案では、故障時に代替機を使えるか、交換までどれだけ待つか、モデルを再び使える状態にする時間を確認します。クラウドやAPIを使う案では、利用できる地域、割当量、制限、障害時の切り替え方法を契約と実装の両方で確認します。どの方式でも、運用を担当する人が条件を理解できる資料が必要です。

稼働率を比較する場合には、設備を確保した時間と、必要な仕事に実際に使った時間を区別します。常時確保する案と、必要な時間だけ確保する案では、利用料の計算が異なります。また、処理している時間であっても、品質や締め切りの条件を満たしていなければ、事業に必要な成果が得られているとは限りません。

運用レポートには、単に「GPU使用率が高い」と書くより、必要な仕事の完了数、待ち時間、失敗率、利用料、構成変更を記録することを提案します。設備の数字とサービスの数字を結び付けることで、増設する理由や、最適化を先に試す理由を説明できます。

この記事では、特定のサービスが障害を起こしやすいという評価は行っていません。公開情報だけでは同じ条件で比較できないためです。運用条件は契約と自社の評価によって確認する項目として整理し、確認できていない保証や実績を補って書くことはしていません。

22．一般のAI利用者にも、設備需要は関係する

AIサービスを利用する人が、データセンターを自分で設計する必要はありません。それでも設備の見方を知ると、「なぜ混雑時に遅くなるのか」「長い入力や大量処理で条件が変わるのか」「利用料の説明に何が含まれるのか」を確認しやすくなります。サービスの品質を、モデル名だけで判断しないための知識です。

契約を検討する際には、必要な仕事の量と速度を具体的に伝えます。「速いAIが欲しい」という依頼より、「この量の資料を、何時までに、どの品質で処理したい」と伝える方が比較可能な条件になります。最初の返答の速さと、すべての仕事が終わる時間も分けて説明してください。

会社で使う場合には、試作時にうまく動いたことと、複数の人が毎日使えることを分けて確認します。利用が集中する時間帯や、普段より長い入力を処理する条件を整理し、契約や利用制限と照らし合わせます。設備への投資が増えているニュースから、自社の利用が無制限になると推測することはできません。

また、サービスの価格が変わったときには、請求の単位、対象のモデル、処理条件が同じかを確認します。単価の値下げだけで総費用が下がるとは限らず、利用量や再実行が増えれば請求額は変わります。どの項目が変わったかを記録して比較する方法は、設備を持たない利用者にも役立ちます。

基盤の知識は、AIを無条件に推進するためのものでも、否定するためのものでもありません。必要な仕事に対して、品質、時間、費用が合っているかを事実と測定で確認するためのものです。これらの条件が言葉にできれば、サービスを選ぶ判断を、話題の大きさだけに依存せず進められます。

23．今後のAI設備ニュースを読むための確認表

この先の発表では、投資額、出荷、提供開始、性能、電力などの数字が増えていくと考えられます。以下は、新しい記事を読むときに使える編集部の確認表です。数字の大きさを見る前に、その数字が何を表すかを揃えるために作りました。

小さな画面では表を横にスクロールできます。

この表を使うと、根拠が足りない数字を無理に解釈せず、どこが未確認なのかを書けます。たとえば提供地域が確認できない場合には、性能の説明から利用可能と結論しません。測定条件が掲載されていない場合には、同じ条件での順位表へ追加しません。

自社の稟議や企画書に数字を転載する際も、出典と確認日を添えます。予測なら予測と書き、後から新しい資料が出た場合に差し替えられる形で残します。過去の実績と将来の見通しを同じグラフにする場合には、表示を分け、境界がわかるようにしてください。

本記事の資料確認日は2026年9月28日です。新しい決算、料金、提供条件、ベンチマークの修正が発表されたら、その項目を再確認する必要があります。ここで示した技術上の確認方法と、特定の日に確認した数字を分けて持っておけば、ニュースが更新されても判断の手順を続けられます。

24．AI推論インフラについてよくある質問

AI推論インフラとは何ですか？

学習済みのAIを使って結果を出すための基盤です。計算チップだけでなく、メモリ、ネットワーク、ストレージ、電源、冷却、実行ソフトウェアを含めて考えます。

2026年に推論が学習を上回ったと断定できますか？

本記事で確認したGartnerの数字は、AI最適化IaaS市場における2026年の年間支出予測です。AIの全市場で確定した実績という意味ではありません。

データセンター売上は、すべてAI推論の売上ですか？

いいえ。今回取り上げた決算の部門は推論だけの売上として公表されていません。学習や他のデータセンター製品を含み得るため、推論市場の総額へ置き換えません。

GPUを増やせば必ず返答が速くなりますか？

必ずとは言えません。処理のどこで時間を使っているか、メモリや通信、待ち行列の条件を確認し、必要な仕事で変更前後を測ります。

APIと自前設備のどちらが安いですか？

利用量、品質、待ち時間、契約、運用費によって変わります。同じ仕事を同じ条件で完了する費用を揃えて比較します。本記事の単価は計算説明用の仮定です。

記事中の画像や計算例は実機の検証結果ですか？

画面画像は公開一次資料をChromeで確認した記録です。表紙はAI生成の概念イラストです。計算例は仮定に基づく算術で、有料設備の実測や顧客事例ではありません。

25．関連するAI技術を読む

本記事は、AIを実行する設備とサービス条件を扱いました。モデル自体の構造や、検索・埋め込みを使う仕組み、端末側の実行環境について詳しく知りたい場合は、AQUAの別記事を参照できます。それぞれの主題を分けて読むと、モデルの能力と、利用する基盤の条件を混同せず理解できます。

• Nemotron-3-Superのモデル構造を解説した記事：モデル自体の仕組みを確認する入口。
• Gemini Embedding 2の解説：埋め込みモデルが担う役割を読む。
• MacBook Air M5のAI開発レビュー：端末で実行する環境を読む。
• AQUAブログの記事一覧：目的に合う技術テーマを探す。

26．一次資料・確認日・記事の扱い

情報確認日：2026年9月28日。企業の実績や計画は発表元の資料、市場見通しは調査機関の発表、技術の仕組みは公式技術資料を参照しました。仕様や提供条件は更新されます。

1. NVIDIA：FY2027第2四半期決算（2026年8月26日）
2. AMD：2026年第2四半期決算（8月4日）
3. Google：フィンランドへの投資計画（2026年9月9日）
4. Gartner：AI最適化IaaS支出予測（2026年8月10日）
5. MLCommons：MLPerf Inference v6.1発表（2026年9月16日）
6. MLCommons：v6.1結果分析（2026年9月17日）
7. MLCommons：Datacenterの測定・公開区分
8. IEA：Key Questions on Energy and AI・要約（2026年4月16日／CC BY 4.0）
9. Google：第8世代TPUの設計と提供予定（2026年4月22日）
10. Micron：HBM4の量産出荷発表（2026年3月16日）
11. NVIDIA：LLM推論の最適化・技術解説
12. NVIDIA：LLM推論ベンチマークの指標（2025年4月2日）
13. Hugging Face：KVキャッシュの戦略
14. vLLM：Automatic Prefix Caching
15. NVIDIA Dynamo：prefill・decodeの分離
16. NVIDIA：Dynamoによる推論処理全体の最適化

編集：AQUA合同会社。需要についての解釈、比較の枠組み、評価手順は、出典で確認できる事実をもとにした編集部の整理です。説明用の数値は仮定として示しました。特定企業への投資判断、政策への賛否、未確認の顧客効果は記事に含めていません。引用した資料の事実と、本記事の提案が識別できるように記載しています。