モバイルのCPU/NPUとデスクトップのGPU、それぞれの得意分野に任せる「ネットワークGPU」構成
Copilot+ PCのNPUに関する記事で整理したとおり、Copilot+ PCが搭載するNPUは省電力・常時稼働タスクに強い一方、大きなモデルを高速に動かす推論性能ではGPUの圧勝です。実際、後述のとおり型落ちのデスクトップGPUでもCopilot+ PCのNPU/GPUに対して応答時間ベースで9倍以上の差が実測されており、現代のGPUアーキテクチャであればこの差はさらに開くと予想されます。これは単純な性能の優劣というより、そもそも最適化の方向性が違うことに起因します。モバイル向けのCPU/NPUは、限られたバッテリー・排熱の中で小規模なタスクを継続的にこなすことに最適化されたハードウェアであり、大規模な推論を高電力で回すことは想定されていません。逆にデスクトップのGPUは大規模な推論に最適化されている一方、電力・排熱の制約からノートPCにそのまま積むのは簡単ではありません。この記事では、LAN内のゲーミングPCなどGPUが強いデスクトップに推論を任せる「ネットワークGPU」構成が、モバイル側・デスクトップ側それぞれの苦手分野をどう補い合うかを整理します。
ネットワークGPUという構成
動作イメージは、クラウドAIに投げるプロンプトを、外部のクラウドではなくLAN内の別マシンに置き換えたようなものです。
リクエスト送信 推論実行
[クライアント: Copilot+ PCなど] ---- HTTP(LAN経由) ----> [デスクトップ機: GPUが強い]
レスポンス受信 <------------------------------------------ 結果返却UbuntuとRustでローカルAI推論サーバーを自作する記事では、この構成を実際にUbuntu機+型落ちのGeForce GTX 1080Tiで構築し、モデルを揃えたうえでノートPC側の推論と比較して応答時間ベースで約9.2倍高速という結果を実測しました。この数字が示すとおり、たとえ型落ちのGPUであっても、ノートPC側のGPU/NPUに任せるより圧倒的に高速な推論が得られます。
なお、もともとGPU自体が強いノートPC(強力なGPUを積んだゲーミングノートなど)や、ワークステーション本体で完結させる場合は、この構成自体が不要です。この記事が対象にしているのは、あくまでCopilot+ PCのようにモバイル向けの制約でGPUが非力な機体を、LAN内の別のGPU資源で補うケースです。
これは「ローカルAI」と呼んでいいのか
正直なところ、ネットワーク越しである以上、これを厳密に「ローカルAI」と呼んでよいのか筆者自身も判断に迷います。単一のマシン内で完結しているわけではないからです。ただし、クラウドAIとローカルAIの比較記事で整理した「ローカルAIの利点」に照らすと、この構成が保つものと失うものがはっきり分かれます。
- 保たれるもの: データが組織の外部(パブリッククラウド)に出ないという意味でのプライバシー・セキュリティ境界。LANの外側にリクエストが出ない限り、この境界は維持されます。
- 失われるもの: 完全なオフライン動作。クライアントとサーバー間のネットワーク疎通が前提になるため、真の意味で「ネットワークが一切要らない」状態ではありません。
つまりこの構成は、「マシン内で完結する狭義のローカルAI」と「外部クラウドAPI」の中間に位置します。呼び方として厳密に正しいかはさておき、実務上の性質としては「組織のLAN（ ローカル ・エリア・ネットワーク）という境界の中に閉じたAI」と表現するのがより正確かもしれません。
それぞれの苦手分野を補い合う
モバイル側の苦手分野(大規模推論)をデスクトップGPUが補う
UbuntuとRustでローカルAI推論サーバーを自作するで実測したとおり、2016年頃発売の型落ちGPUでもノートPC側の推論より大幅に高速でした。モバイル向けのCPU/NPUをいくら工夫して使っても、バッテリー・排熱という設計上の制約がある限り、大規模な推論という土俵ではデスクトップGPUに敵いません。ここをネットワークGPU経由で補ってしまえば、モバイル側は大規模推論を諦める必要がなくなります。
デスクトップGPUの苦手分野(携帯性)をモバイル機がそのまま引き受ける
一方、デスクトップGPUにも苦手分野があります。バッテリー駆動もできず、持ち歩くこともできません。ネットワークGPU構成では、この携帯性の欠如を無理に解消しようとせず、デスクトップ機は据え置きの計算資源として割り切り、日常的な持ち運び・常時稼働の軽量タスクはモバイル側のCPU/NPUにそのまま任せます。それぞれのハードウェアを、無理に相手の得意分野に寄せず、自分が最適化されている役割に専念させる、という考え方です。
構成上の注意点
誰がこのGPUサーバーにアクセスできるかという境界設計が必要
推論リクエストがLANの外に出ないため、パブリッククラウドのAI APIにデータを送る場合と比べて、外部へのデータ送信という経路自体が発生しません。ただし、これは「セキュリティを何も考えなくてよい」という意味ではありません。MCPサーバーをローカルAI環境で動かす記事の認証の節で書いたとおり、同一マシン内で完結する構成ではプロセス分離が実質的な境界になりますが、ネットワーク越しにする以上、この構成では改めて「誰がLAN内からこのGPUサーバーにアクセスできるか」という境界設計が必要になります。同じLANに繋がっている全端末を無条件に信頼してよいかは、家庭内か社内かでも変わってくるはずです。
単一障害点になりやすい
ネットワークGPU役のデスクトップ機が1台構成の場合、そのマシンが落ちれば全クライアントの推論が止まります。UbuntuとRustでローカルAI推論サーバーを自作する記事でも、SSHセッション終了と共にサーバープロセスが道連れで落ちる問題があり、systemdサービス化で解消しました。LAN内の共有インフラとして使う以上、こうした恒常稼働の作り込みは前提になります。
複数クライアントからのアクセスは直列化されやすい
UbuntuとRustでローカルAI推論サーバーを自作する記事で扱ったとおり、GPUを握るコンテキストはSend/Syncの制約から専用スレッド1本に閉じ込める設計になりやすく、複数リクエストは実質的にキューイングされて順番に処理されます。GPUというハードウェア自体、MIGのような機能がなければ論理分割されず結局直列化されるため、複数クライアントが同時にヘビーな推論を投げる用途では、応答速度がクライアント数に応じて劣化する点を織り込んでおく必要があります。
ネットワーク帯域はモダリティで負荷が大きく変わる
クラウドAIとローカルAIの比較記事で整理したとおり、音声・動画はテキストと比べて桁違いにトークンを消費します。テキストプロンプトのやり取りであればLANの帯域はまず問題になりませんが、音声・動画を扱うマルチモーダルな用途に広げる場合は、ネットワーク負荷も踏まえた設計が必要です。
まとめ
モバイル向けのCPU/NPUは省電力・小型・小規模タスクに最適化され、デスクトップのGPUは高電力・大規模タスクに最適化されている、という前提に立つと、両者は代替関係ではなく補い合う関係にあります。LAN内のGPUが強いデスクトップに推論を任せる「ネットワークGPU」構成は、モバイル側が苦手とする大規模推論をデスクトップGPUに肩代わりさせ、デスクトップGPUが苦手とする携帯性・常時稼働をモバイル側にそのまま任せる、という役割分担を実現します。ネットワーク越しである以上、狭義の「ローカルAI」と呼んでよいかは微妙なところですが、外部クラウドにデータを出さないという境界は維持されます。一方でLAN内アクセスの境界設計・単一障害点・複数クライアントからの直列化・モダリティごとの帯域負荷といった、クラウドAPIとも単一マシン完結のローカルAIとも異なる論点が発生する点には注意が必要です。もともとGPUが強いノートPCやデスクトップ本体で完結できるなら、この構成自体が不要になる点も忘れないようにしたいところです。