AI・テクノロジー

Intel AI PC群で大規模LLMを分散稼働——3つの技術が実現する、オフィスPC連携による推論基盤

docker agent

• 21 min read
Share

はじめに：眠っているAI PCを活かす発想

Intel Lunar Lake世代以降のAI PCは、統合GPU（Intel Arcシリーズ）とNPU（ニューラルプロセッシングユニット）を搭載し、16GB以上のユニファイドメモリを備えている。しかし実際には、これらのハードウェアリソースは日常業務の大部分でアイドル状態にある。Webブラウジングやドキュメント作成、メール処理といった一般的なオフィスワークでは、統合GPUもNPUもほとんど活用されず、せっかくのAI処理能力が眠ったままになっているのが現状だ。

1台のAI PCで実行可能なLLM（大規模言語モデル）には明確な限界がある。16GBのユニファイドメモリでは、INT4量子化されたLlama 3.1 8B（80億パラメータ）程度が現実的な上限であり、Llama 3.1 70B（700億パラメータ）のような大規模モデルは単一マシンではメモリ不足で動作しない。しかし、複数台のAI PCをネットワークで協調させれば話は変わる。各マシンがモデルの一部を担当し、パイプライン状に処理を連携させることで、1台では絶対に動かない大規模モデルも扱えるようになる。

このアプローチを実現するには、3つの技術的工夫が必要となる。第一に、パイプライン並列性を用いてモデルを分割しても、単一マシンで動かした場合と同等の速度（モノリシックパリティ）を達成する方法。第二に、投機的デコード（小規模モデルで候補トークンを生成し、大規模モデルで一括検証する高速化手法）をOpenVINOのステートフルモデル上で現実的に動作させる工夫。第三に、パイプラインの各ステージに生じるアイドル時間を、複数ユーザーのリクエストをインターリーブすることで埋めるマイクロバッチングである。これらの組み合わせにより、2台のノードでモノリシック比1.79倍のスループット、3台で2.64倍という結果が得られている。

flowchart LR
    subgraph PC1["AI PC #1"]
        direction TB
        Stage0["パイプラインレイヤー群（前半）"]
    end
    subgraph PC2["AI PC #2"]
        direction TB
        Stage1["パイプラインレイヤー群（後半）"]
    end
    subgraph PC3["AI PC #3"]
        direction TB
        Stage2["さらに後半のレイヤー群"]
    end

    Input["入力トークン"] --> Stage0
    Stage0 -- "中間表現（ネットワーク経由）" --> Stage1
    Stage1 -- "中間表現（ネットワーク経由）" --> Stage2
    Stage2 --> Output["出力トークン"]

既存ハードウェアの潜在力を引き出すこの発想は、追加投資ゼロでLLM推論基盤を構築できる可能性を示している。データが社内ネットワークから出ないというデータローカリティの観点でも、クラウドAPIに依存しないというコスト面でも、企業にとって有力な選択肢となり得る。本記事では、この分散LLM推論を実現する3つの技術の詳細と、実際のベンチマーク結果を解説する。

なぜ分散LLM推論が難しいのか

大規模言語モデルを複数のマシンで協調動作させる「分散LLM推論」は、一見すると単純な発想に思える。しかし実際には、ソフトウェアスタックの各層に潜む技術的障壁が立ちはだかる。まず基本から確認しよう。

パイプライン並列性の基本

分散LLM推論の根幹となるのがパイプライン並列性である。LLMは数十〜数百のトランスフォーマーレイヤーで構成されており、これらのレイヤーをレイヤー単位で分割し、各マシンが担当するレイヤー範囲だけを実行する。たとえば32層のモデルなら、2台のマシンで16層ずつ担当する。各マシンは前段の出力を受け取り、自分の担当層を処理して次段へ渡す。この方式はモデル並列性の一種であり、単一マシンのメモリに収まらない大規模モデルを扱える点が最大の利点である。

flowchart LR
    subgraph ノード0
        L0["レイヤー 0-15"]
    end
    subgraph ノード1
        L1["レイヤー 16-31"]
    end
    Input --> ノード0 --> ノード1 --> Output

しかし、このシンプルなアイデアをIntel AI PCの統合GPU環境で実現しようとすると、以下4つの課題に直面する。

課題1：動的制御フローによるエクスポート失敗

モデルを分割するには、PyTorchモデルをOpenVINOの中間表現（IR）にエクスポートする必要がある。標準的な手段は torch.export だが、LLMに含まれる動的制御フローで失敗する。具体的には、RoPE（Rotary Position Embedding）の動的な位置計算や、KVキャッシュの管理ロジックが、静的なグラフへの変換を阻む。その結果、エクスポートそのものが完了せず、分散化の第一歩で頓挫する。

課題2：分割によるGPU最適化の喪失

仮にエクスポートに成功しても、分割された各シャードは本来のOpenVINO GPUプラグインの最適化——特にIndirectKVCache最適化——を受けられなくなる。この最適化はGPU上のメモリアクセスパターンを効率化するもので、モノリシック（単一マシン）推論では大きな効果を発揮する。しかし分割後のシャードを単純にエクスポートしただけではこの最適化が発動せず、結果としてモノリシックよりも遅い逆転現象が発生する。

課題3：ネットワーク伝送の支配的コスト

LLMの推論は自己回帰（オートレグレッシブ） 方式で動作する。つまり1トークンずつ順番に生成し、前のトークンの出力を次のステップの入力として使う。分散環境では、各ステップで中間結果（アクティベーション）をネットワーク経由で次段に転送しなければならない。1トークンあたりの転送データ量は小さくても、TCPのラウンドトリップ時間が支配的なコストとなる。LANでも数ms、WANでは数十〜数百msの遅延が1トークンごとに発生するため、単純な実装では実用的な速度が得られない。

課題4：投機的デコードとの非互換性

近年のLLM高速化技術として投機的デコード（Speculative Decoding） が注目されている。これは小規模なドラフトモデルが複数トークンを提案し、ターゲットモデルがそれらをまとめて検証する手法である。しかし、標準的な投機的デコードの実装はvLLMのPagedAttentionを前提として構築されており、OpenVINOのステートフルモデル（KVキャッシュをグラフ内に組み込んだモデル）ではそのまま利用できない。特に、拒否されたドラフトトークンをKVキャッシュから削除する処理に大きなコストがかかるため、投機的デコードの利得が相殺されてしまう。

これらの4つの課題が複合的に作用するため、Intel AI PC群での分散LLM推論は単なる「モデルを分割して配置する」だけでは実現できない。次節以降では、これらの各課題を解決する3つの技術的貢献を詳しく見ていく。

貢献1：ビームID Gather注入によるモノリシックパリティの達成

パイプラインシャードのエクスポート手法

モデルを複数のマシンに分割する第一歩は、PyTorchモデルをOpenVINOの中間表現（IR）としてエクスポートすることである。しかし前述の通り、標準的な torch.export はLLMに含まれる動的制御フローで失敗する。この問題を回避するため、本手法では torch.jit.trace と事前計算RoPE（Rotary Position Embedding）を組み合わせる。RoPEはトークンの位置情報を埋め込む処理で動的な計算を含むが、あらかじめ最大コンテキスト長までの位置エンコーディングを計算して定数としてグラフに埋め込むことで、静的なトレースを可能にしている。

エクスポートの流れは4つのステップで構成される。まず、各ステージが担当するレイヤー範囲のみを元のモデルから抽出する。次に、抽出したサブグラフに対してINT4量子化を適用し、メモリ使用量を削減する。続いて、KVキャッシュを ReadValue / Assign ペアとしてグラフ内に組み込み、ステートフルモデル（状態を持つモデル）としてエクスポートする。最後に、OpenVINO IR形式でファイルに書き出す。

flowchart TD
    A["元のPyTorchモデル（Llama 3.1 8B）"] --> B["担当レイヤー範囲の抽出\n（例：レイヤー0-15）"]
    B --> C["INT4量子化の適用"]
    C --> D["KVキャッシュをReadValue/Assign\nとしてグラフに組み込み"]
    D --> E["OpenVINO IRとしてエクスポート"]

この手順により、各ステージは独立したOpenVINO IRとして動作可能になる。ただし、このままではもう一つの問題——モノリシック比13〜23%の性能低下——が残る。

IndirectKVCache最適化を発動させる「おまじない」

ナイーブにエクスポートしたシャードは、モノリシック（単一マシン）推論と比較して13〜23%も低速になる。たとえばLlama 3.1 8B INT4のモノリシック推論が24.54 tok/sであるのに対し、単純な2段分割では21.26 tok/s程度に低下する。原因はOpenVINO GPUプラグインのIndirectKVCache最適化が発動しないことにある。この最適化はGPU上のKVキャッシュアクセスを効率化する変換であり、モノリシック推論では自動的に適用されるが、分割後のシャードでは適用条件を満たさない。

解決策は、ポストエクスポート段階でのグラフ手術である。具体的には、beam_idx というParameterノードと、Gather(ReadValue, beam_idx, axis=0) という操作をIRグラフに注入する。この beam_idx は「ビームサーチでどのビームの状態を参照するか」を指定するインデックスだが、本手法ではコンパイル時のパターンマッチングのためだけに存在する。実行時には常に [0] が渡されるため、実際のビームサーチは行われない。

この「おまじない」により、OpenVINO GPUプラグインのIndirectKVCache変換が正しく発動し、1ステージ構成ではモノリシックと0.4%以内の誤差、2〜3ステージでも11〜15%のオーバーヘッドに抑制される。beam_idx注入前後の速度比較では、21.26 tok/sから24.45 tok/sへと約15%の改善が見られた。この結果は、ソフトウェアの内部最適化を正しくトリガーするために、モデルグラフの構造自体を調整するという発想の有効性を示している。

貢献2：マスクベースKVキャッシュ巻き戻し——投機的デコードを現実的に

投機的デコードとは

LLMの推論を高速化する手法として投機的デコード（Speculative Decoding） が注目されている。通常の自己回帰（オートレグレッシブ）推論では、1回のフォワードパスで1トークンしか生成できない。これに対し投機的デコードは、小規模なドラフトモデル（候補生成モデル）がまず複数トークンを高速に提案し、大規模なターゲットモデルがそれらのトークンをまとめて検証する仕組みである。ターゲットモデルは1回のフォワードパスで複数トークンの妥当性を同時にチェックできるため、1ステップあたりの生成トークン数を増やせる。

flowchart LR
    subgraph Draft["ドラフトモデル（小規模）"]
        G1["トークンAを生成"]
        G2["トークンBを生成"]
        G3["トークンCを生成"]
    end
    subgraph Target["ターゲットモデル（大規模）"]
        V["A・B・Cをまとめて検証"]
    end
    subgraph Accept["受理/棄却"]
        A1["A: 受理 ✓"]
        A2["B: 受理 ✓"]
        A3["C: 棄却 ✗"]
    end

    G1 --> G2 --> G3 --> V --> Accept

分散LLM推論の文脈では、投機的デコードはさらに大きなメリットをもたらす。ドラフトモデルが複数トークンを連続生成し、それを1回のネットワーク転送でターゲットモデルに送れば、トークンあたりのネットワーク往復回数を削減できる。つまり、計算効率と通信効率の両方で利得が得られる。

ステートフルOpenVINOでの問題

しかし、OpenVINOのステートフルモデル（KVキャッシュをグラフ内にReadValue/Assignとして組み込んだモデル）で投機的デコードを実装しようとすると、大きな壁に直面する。投機的デコードでは、ターゲットモデルがドラフトトークンの一部を「棄却」した場合、棄却されたトークンに対応するKVキャッシュのエントリを削除し、状態を巻き戻す必要がある。この「KVキャッシュの巻き戻し」を標準的な方法で行おうとすると、query_state と set_state というAPIを使ってKVキャッシュ全体を読み出し、修正して書き戻すことになる。

問題はこの処理のコストである。測定によれば、query_state / set_state による物理的なKVトリムには約 48ミリ秒 かかる。一方、OpenVINO上でのデコード1ステップは約 47ミリ秒 である。つまり、投機的デコードで得られるはずの高速化効果が、KVキャッシュの巻き戻し処理だけで完全に相殺されてしまう。これでは投機的デコードを導入する意味がなくなる。

マスクベースの解決策

この問題に対する解決策が、マスクベースKVキャッシュ巻き戻しである。発想はシンプルで、KVキャッシュを物理的に削除する代わりに、attention_mask（アテンション計算でどの位置に注目するかを制御するマスク）で対象位置を無効化する。具体的には、棄却されたドラフトトークンに対応する位置のマスク値を 0 に設定する（attention_mask[j] = 0）。するとアテンション計算時にその位置のKV値は無視され、あたかも削除されたかのように振る舞う。

この手法の優れた点は以下の通りである。

  • 出力の同一性: 物理トリムとビット単位で同一の結果が得られる。fp32精度での比較では最大差0.0000であり、完全一致する。
  • 処理コスト: マスクの操作はCPUのみで行える単純な配列操作であり、1ステップあたりの追加コストは 1%未満 である。物理トリムの48msとは比べ物にならない。
  • 実装の簡便さ: 既存のステートフルモデルのグラフ構造を変更する必要がなく、attention_maskの値だけを書き換えればよい。

実際の性能測定では、単一ノードで平均 1.33倍、コード補完タスクでは 1.50倍、長い2048トークン世代では約 1.6倍 の高速化が確認されている。特にコンテキストが長くなるほど、マスクベース方式の相対的な利点が大きくなる。さらにこの手法は、パイプライン並列性によるシャーディングと自然に合成可能であり、3段シャード構成でも 1.32倍 の高速化を維持している。つまり、モデルを分割しても投機的デコードの効果は損なわれない。

以上の仕組みにより、OpenVINOのステートフルモデル上で投機的デコードを現実的なコストで動作させることが可能になった。次節では、もう一つの高速化技術であるマイクロバッチングについて解説する。

貢献3：マイクロバッチングによるマルチユーザースループット向上

パイプラインのアイドル時間を埋める発想

パイプライン並列性はモデルを複数のステージに分割して各マシンに割り当てる手法だが、単一ユーザーのリクエストを逐次的に処理する場合、パイプラインの各段には本質的に待ち時間が生じる。2段パイプラインを例にとると、ステージ0が計算を終えて中間結果をステージ1に転送した後、ステージ1が推論を完了するまでの間、ステージ0は遊休状態となる。単一リクエストを直列に流すだけでは、パイプライン全体の効率は理論上50%程度にとどまり、実際の2段パイプラインのスループットはモノリシック（単一マシン）比で0.67倍まで低下する。

このアイドル時間を有効活用するのがマイクロバッチングである。OpenVINOの各InferRequestは独立したKVキャッシュを保持する。つまり、あるリクエストのKVキャッシュを別のリクエストが上書きすることなく、複数のリクエストを並行して管理できる。この性質を利用して、複数ユーザーのリクエストをパイプラインのステージ間でインターリーブ（交互投入）することで、1台のマシンが遊休になる時間をほぼゼロにできる。

以下の図は、2ユーザーがマイクロバッチングを利用する様子を示している。ユーザーAのトークンがステージ0で処理されている間にユーザーBのトークンが到着し、ステージ0が空いた瞬間にすぐ次の処理を開始する——このような時分割多重により、パイプライン全体の稼働率が向上する。

sequenceDiagram
    participant S0 as ステージ0（ノード0）
    participant S1 as ステージ1（ノード1）
    participant T as 時間軸
    
    Note over T: 単一ユーザー（通常のパイプライン）
    S0->>S1: ユーザーA トークン1
    S0-->>S0: 遊休
    S1->>S1: ユーザーA トークン1 処理
    S0->>S1: ユーザーA トークン2
    S0-->>S0: 遊休
    
    Note over T: マイクロバッチング（2ユーザー）
    S0->>S1: ユーザーA トークン1
    S0->>S1: ユーザーB トークン1
    S1-->>S1: ユーザーA/B交互に処理
    S0->>S1: ユーザーA トークン2
    S0->>S1: ユーザーB トークン2

実装と性能

マイクロバッチングの実装は比較的シンプルである。各ユーザー（ストリーム）に対して独立したcompile_model()を実行し、それぞれが専用のコンパイル済みグラフとKVキャッシュ状態を持つようにする。推論時はラウンドロビン方式で各ストリームのリクエストを順次パイプラインに投入するだけでよい。

追加で発生するコストは2つある。1つ目はコンパイル時間で、ストリームごとにcompile_model()を呼び出すため数秒のオーバーヘッドが生じる。2つ目はGPUメモリ消費で、Llama 3.1 8B INT4の場合、1ステージあたり約2GBの追加メモリがストリーム数に比例して必要となる。ただし、AI PCの統合GPUはシステムメモリと共有のユニファイドメモリを使用するため、16GB以上の搭載マシンであれば2〜3ストリーム程度は問題なく収まる。

性能面では顕著な効果が確認されている。v5_beamシャード（2段パイプライン）に2ストリームのマイクロバッチングを適用した場合、スループットは1.80倍に向上した。理論上の上限は2倍であるため、この値はほぼ理想に近い。さらに3段構成に3ストリームを適用すると、スループットは64.67 tok/sに達し、モノリシック（24.54 tok/s）との比較では2.64倍という驚異的な値を記録している。これは3ユーザーが同時に利用しても、1ユーザーあたり約21.6 tok/sの速度が得られることを意味し、実用的な対話速度をマルチユーザー環境で提供できる。

以下の表は、マイクロバッチングのストリーム数とスループットの関係をまとめたものである。

構成 ストリーム数 スループット モノリシック比
2段パイプライン（v5_beam） 1 16.33 tok/s 0.67x
2段パイプライン（v5_beam） 2 29.34 tok/s 1.20x
3段パイプライン 2 50.55 tok/s 2.06x
3段パイプライン 3 64.67 tok/s 2.64x

マイクロバッチングのもう一つの利点は、他の2つの技術——ビームID Gather注入とマスクベースKVキャッシュ巻き戻し——と独立に組み合わせられることである。パイプラインのアイドル時間を埋めるという原理上、投機的デコードの有無にかかわらず効果を発揮する。実際、2段パイプライン＋2ストリームの段階で29.34 tok/sを達成した後、さらに投機的デコードを重ねることで43.97 tok/s（モノリシック比1.79倍）に到達しており、3つの技術が乗算的に効いていることが確認されている。

総合性能：フルスタックの威力

2ノード構成（Llama 3.1 8B INT4）

ここまで紹介した3つの技術——ビームID Gather注入によるモノリシックパリティ、マスクベースKVキャッシュ巻き戻しによる投機的デコード、マイクロバッチングによるアイドル時間活用——をすべて組み合わせたときの性能を検証する。2台のASUS Zenbook S 14（Lunar Lake AI PC）でLlama 3.1 8B INT4を実行した結果が以下の表である。

構成 スループット モノリシック比
モノリシック単一ユーザー 24.54 tok/s 1.00x
2段パイプライン（単一ストリーム） 16.33 tok/s 0.67x
+2ストリームマイクロバッチング 29.34 tok/s 1.20x
+投機的デコードK=3 43.97 tok/s 1.79x

ナイーブな2段パイプライン（単一ストリーム）ではモノリシック比0.67倍と低下するが、そこにマイクロバッチング（2ストリーム）を適用することで1.20倍まで逆転し、さらに投機的デコード（K=3）を重ねることで1.79倍に到達する。注目すべきは、この値が各要素の倍率の積とほぼ一致することだ。16.33（ベース）×1.797（マイクロバッチング相当）×1.499（投機的デコード相当）=43.97となり、実測値との誤差は0.05 tok/s以内である。3つの技術が互いに干渉せず、独立に乗算効果を発揮していることがわかる。また、最終的な出力はモノリシック実行とビット単位で同一であり、品質の劣化は一切ない。

スケーリング：3ノードと70Bモデル

ノード数を増やした場合のスケーラビリティも検証されている。3台のAI PCに3段パイプラインを構成し、3ストリームのマイクロバッチングと投機的デコード（K=5）を組み合わせた場合、スループットは64.67 tok/sに達する。これはモノリシック比2.64倍に相当し、3ユーザーが同時に利用しても1ユーザーあたり約21.6 tok/sの対話速度を維持できることを意味する。

さらに挑戦的なのが70Bパラメータモデル（Llama 3.1 70B INT4）の実行である。このモデルは1台のAI PCではメモリ容量の不足により動作しない。4台のノードに分割し、投機的デコードK=10を適用した結果、スループットは5.42 tok/sを記録した。対話型AIの実用閾値は一般に5 tok/s以上とされており、この値はそれを上回る。オフィスに置かれた4台のPCが、1台では絶対に動作しない大規模モデルを、実用的な速度で稼働させられるという点は、本手法の最もインパクトのある成果の一つである。

以下のmermaid図は、2ノード構成におけるフルスタックのデータフローを示している。

flowchart LR
    A[ユーザーリクエスト<br/>複数ストリーム] --> B[ステージ0<br/>ノード0]
    B --> C[ネットワーク転送]
    C --> D[ステージ1<br/>ノード1]
    D --> E[出力トークン]
    
    B --> F[beam_idx Gather<br/>IndirectKVCache]
    D --> G[マスクベース<br/>KV巻き戻し]
    
    H[投機的デコード<br/>K=3〜5] -.-> D
    I[マイクロバッチング<br/>2〜3ストリーム] -.-> B
    
    style B fill:#4a90d9,color:#fff
    style D fill:#4a90d9,color:#fff
    style F fill:#e6a23c,color:#fff
    style G fill:#e6a23c,color:#fff
    style H fill:#67c23a,color:#fff
    style I fill:#67c23a,color:#fff

このように、3つの技術を組み合わせたフルスタック構成により、2ノードでモノリシック比1.79倍のマルチユーザースループット、4ノードでの70Bモデル分散実行が現実のものとなる。既存のオフィスPC群を活用しながら、データを社外に出さずに大規模LLM推論を実現できる点が、本手法の最大の価値である。

WAN環境でも使えるか——ネットワーク遅延への耐性

パイプライン並列性は各ステージ間でトークンを逐次転送するため、ネットワーク遅延がスループットを低下させる原因となる。社内LAN（レイテンシ1ms未満）では問題になりにくいが、拠点間や在宅勤務環境のようなWAN回線ではラウンドトリップタイム（RTT）が数十〜数百msに達し、ナイーブな実装では実用速度を維持できなくなる。本手法では投機的デコードによるトークン数の償却と、転送データ量の削減という2つの対策でWAN環境に耐性を持たせている。

シミュレートWAN（100ms/hop）での性能検証

各ホップに100msの遅延をかけたシミュレーション環境で、Llama 3.1 8B INT4の2ノード構成を測定した結果を表に示す。

構成 スループット モノリシック比
モノリシック（遅延なし） 24.54 tok/s 1.00x
ナイーブ2段パイプライン 2.77 tok/s 0.11x
フルスタック（MB+SD） 11.20 tok/s 0.46x

ナイーブなパイプラインではスループットが2.77 tok/sまで低下し、対話に必要な最低速度（一般的に5 tok/s以上とされる）を下回る。一方、マイクロバッチングと投機的デコード（K=10）を適用したフルスタック構成では11.20 tok/sを達成し、対話閾値を上回る。ナイーブ比で4.04倍の改善であり、投機的デコードが1トークンあたりのネットワーク往復コストを複数トークンで償却する効果がWAN環境で特に顕著に現れている。

K値の最適化戦略

投機的デコードのK値（ドラフトモデルが一度に提案するトークン数）はネットワーク遅延に応じて調整が有効である。LAN環境ではK=5〜7が最適だが、100ms/hopのWANシミュレーションではK=10が最良の結果を示した。これは、ネットワーク往復1回あたりのコストが大きいほど、1回の検証でより多くのトークンをまとめて処理する方が有利になるためである。K値を大きくすると棄却率が上昇するトレードオフがあるが、WANのように通信が支配的な環境では大きなK値が有効に働く。

実WAN検証：Top-1ロジット圧縮の効果

Intel Tiber Cloud上のインスタンス間をTailscale DERP（中継サーバ）経由で接続した実WAN環境での検証も行われた。この環境ではレイテンシが変動し、シミュレーションより厳しい条件となる。

もっとも大きな改善をもたらしたのは、Top-1ロジット圧縮である。通常、パイプラインのステージ間では全語彙の確率分布（FP32ロジット）を転送するが、これを転送せずに直前のステージでTop-1トークンのみを決定して次ステージに送る方式である。これにより転送データ量が語彙サイズ（Llama 3.1で128,000）分のFP32値から単一トークンIDのみに削減される。

実測値の比較を以下に示す。

方式 スループット 対話可否
非圧縮FP32ロジット転送 2.80 tok/s 不可（5 tok/s未満）
Top-1ロジット圧縮 22.88 tok/s 可

非圧縮では2.80 tok/sと対話不能な速度にとどまったが、Top-1圧縮を有効にすると22.88 tok/sへと8.17倍もの改善を達成した。これはWAN環境でも実用的な対話速度を維持できることを示している。ただし、Top-1圧縮はドラフトモデルを使わない単純なパイプラインでのみ有効であり、投機的デコードと併用する場合は全ロジットの転送が必要となる点には注意が必要である。

以上の結果から、本手法は100ms/hop程度のWAN遅延であれば、適切なK値調整とTop-1ロジット圧縮の組み合わせにより、対話可能な速度を維持できることが実証されている。

関連技術との比較

Petals：ボランティアGPUによる分散推論

Petalsは、BLOOM-176B（1760億パラメータ）の分散推論を目的として開発されたシステムである。世界中のボランティアが提供するコンシューマGPU（主にNVIDIA製）上でモデルを分割実行し、libp2pプロトコルを用いて動的なノード参加・離脱を可能にする。本研究との最大の違いはターゲットハードウェアにある。PetalsはCUDA対応のNVIDIA GPUを前提としており、Intel統合GPU（iGPU）やNPUは対象外である。また、Petalsは動的なピアツーピアネットワークを採用するため、ノードの信頼性保証や認証機構がなく、企業のオフィス環境での運用には適していない。一方、本手法は同一組織内の管理されたAI PC群を前提とし、Intel OpenVINOランタイム上で動作する点が異なる。

比較項目 Petals 本手法
ターゲットGPU NVIDIA（CUDA） Intel iGPU（OpenVINO）
ネットワークモデル P2P（libp2p、動的） 固定トポロジ（管理下）
モデル圧縮 FP16 / INT8 INT4（OpenVINO NNCF）
投機的デコード 未対応 マスクベースKV巻き戻し対応
マイクロバッチング 未対応 対応（2~3ストリーム）

Parallax：地理的に分散したコンシューマGPU向け

Parallaxは、地理的に離れたコンシューマグレードのNVIDIA GPUを束ねてLLM推論を行うシステムである。パイプライン並列性とテンソル並列性を組み合わせ、高レイテンシネットワーク環境でも安定した推論スループットを提供する。Petalsと同様にNVIDIA GPU専用であり、OpenVINOやIntel iGPU/NPUの最適化は考慮されていない。また、Parallaxはユーザー間の帯域幅が数十Mbps〜数百Mbpsと様々な環境を想定しており、ローカルオフィスの同一ネットワーク（1Gbps以上）を前提とする本手法とはネットワーク前提条件が異なる。本手法はWAN環境でもTop-1ロジット圧縮により22.88 tok/sを達成するが、Parallaxはより広範なネットワーク条件に対応する代わりに、Intelハードウェア独自の最適化（IndirectKVCache変換など）を利用できない。

vLLM（PagedAttention）：データセンターGPUクラスタ向け

vLLMは、PagedAttentionと呼ばれる効率的なKVキャッシュ管理機構を核とする推論エンジンで、現在最も広く使われているLLMサービスの一つである。NVIDIA A100/H100などのデータセンターGPUを前提としており、マルチGPU・マルチノード構成でも高いスループットを発揮する。しかし、vLLMのコンパイルグラフはPagedAttentionの動的ページ管理を前提に設計されており、OpenVINOのステートフルモデル（ReadValue/AssignによるKVキャッシュ管理）とは互換性がない。また、vLLMはIntel iGPU上では動作せず、CUDAまたはROCmに依存するため、Intel AI PCの統合GPUを活用することはできない。本手法は、vLLMが想定するような高価なデータセンターGPUではなく、既存オフィスPCの統合GPUを活用する点で、導入コストと運用の敷居が根本的に異なる。

その他の関連研究との違い

MDI-LLMはエッジデバイス向けのリカレントパイプライン並列性を提案しており、モバイルSoCや低電力デバイスを対象とする。しかし、Intel iGPUのOpenVINO最適化やINT4量子化との組み合わせは研究範囲外である。Sarathi-Serveはチャンク化プリフィルによるプリフィル・デコードの効率化、Splitwiseはプリフィルとデコードを異なるノードに分離する手法だが、いずれもNVIDIAデータセンターGPUを前提とする。GEARやSkipKVはKVキャッシュ圧縮技術だが、これらはPagedAttentionとの組み合わせが前提であり、OpenVINOステートフルモデルへの適用は検討されていない。

本手法の独自性のまとめ

以下の4点が、既存技術に対する本手法の独自性である。

  1. Intel iGPU + OpenVINOランタイム：NVIDIA CUDAではなく、Intel統合GPU上でOpenVINOを介した推論最適化を実現している点
  2. ビームID Gather注入によるIndirectKVCache最適化：ポストエクスポートグラフ手術により、OpenVINO GPUプラグインの最適化パスを強制的に発動させる独自手法
  3. マスクベースKVキャッシュ巻き戻し：OpenVINOステートフルモデルで投機的デコードを実現する、物理トリム不要の軽量な手法
  4. マイクロバッチングとの組み合わせ：パイプライン並列性・投機的デコード・マイクロバッチングの3技術を同時適用し、各技術の効果が乗算的に積み上がる構成

これらの技術は独立しても有用だが、組み合わせることで2ノード構成でモノリシック比1.79倍のマルチユーザースループットを達成し、3ノード3ストリームでは64.67 tok/s（2.64倍）を実現する。既存研究がNVIDIA GPUやデータセンター環境に最適化されているのに対し、本手法はオフィスに既存するIntel AI PCの潜在能力を引き出す点で、明らかに異なるユースケースとハードウェア前提に立っている。

制約と今後の課題

本システムは実用的な性能を示した一方で、いくつかの制約が存在する。まずネットワーク環境については、現状の実装は信頼できる同一セグメントのLANを前提としており、認証・暗号化・フォールトトレランスは未実装である。これはつまり、ノード間の通信が改ざんや傍受に対して無防備な状態であり、実運用ではVPNやTLSによる保護が別途必要になる。また、いずれかのノードがダウンした場合に推論を継続する仕組みはなく、全ノードが正常であることが前提となる。

加えて、すべてのノードが同一のソフトウェアスタック（OpenVINOのバージョン、Pythonランタイム、PyTorch等）を揃えなければならないという運用上の制約もある。バージョン不一致が発生するとモデルのエクスポートや実行時に互換性の問題が生じるため、管理対象のPC群を統一的にメンテナンスできる環境が求められる。

ハードウェア面では、ノートPCでの継続的なGPU推論に伴う電力消費と熱問題が未評価である。本論文のベンチマークはASUS Zenbook S 14で実施されたが、ラップトップの放熱設計は限られており、長時間の推論負荷でサーマルスロットリング（熱によるクロック低下）が発生する可能性がある。デスクトップ型AI PCや冷却機構の強化されたワークステーションでは問題になりにくいが、実際のオフィス環境での持続性能は実測による検証が待たれる。

NPU（ニューラルプロセッシングユニット）の活用にも制約がある。現時点ではNPU向けのコンパイル時にコンテキスト長が固定され、実行中の動的な長さ変更には再コンパイルが必要となる。さらにKVキャッシュはFP16精度に固定されており、メモリ効率の面でINT4などの圧縮形式が利用できない。コンパイル自体にも長時間を要するため、実用的なNPUステージの構築は今後の課題である。

最後に、外部リファレンスとしての70Bモデル検証が未完了である点も挙げられる。Llama 3.1 70BのFP16キャリブレーションには256GB以上のRAMが必要であり、現状のテスト環境では物理メモリが不足していた。この検証が完了すれば、本手法の70B対応がさらに確かなものとなる。

今後の展望としては、フォールトトレランス機構の組み込み、マルチベンダーGPU（AMD・Apple Silicon等）へのポータビリティ向上、認証・暗号化の統合、電力効率の最適化などが挙げられる。また、NPUステージの動的コンテキスト長対応やINT4 KVキャッシュの実現により、より多様なエッジデバイスでの分散推論が可能になるだろう。

よくある質問

この技術を使うには特別なハードウェアが必要ですか？

第13世代以降のIntel Core Ultraプロセッサ（Lunar Lake以上）を搭載したAI PCであれば利用可能である。統合GPU（Arcシリーズ）が必須で、最低2台、推奨3〜4台の同一構成マシンが理想的だ。追加のGPUや専用サーバーは不要で、既存のオフィスPCをそのまま活用できる。

既存のLLMサービス（ChatGPT等）と比べてどんなメリットがありますか？

最大のメリットはデータローカリティとゼロ限界費用の2点である。機密データをクラウドに送信せずに社内ネットワーク内でLLM推論が完結するため、プライバシーとセキュリティを確保できる。また、既存の社内PCリソースを活用するため、API課金や追加ハードウェア投資が不要になる。

70Bパラメータモデルが本当にオフィスPC4台で動くのですか？

はい、可能である。Llama 3.1 70BをINT4精度に圧縮し、4台のLunar Lake AI PCに分割することで、Intel Tiber Cloud上で5.42 tok/s（1ユーザー）の対話速度を確認している。1台では絶対に動作しない70Bクラスのモデルが、オフィスPC4台で実用的な速度で推論可能になる。出力はビット単位で正しく、モノリシック実行と同一の結果が得られることも検証済みだ。

セットアップは難しいですか？

論文のコードはGitHub（https://github.com/labscommunity/pipeline-sharded-inference-paper）で公開されており、Makefileとreproduction/ディレクトリに再現用スクリプトが一式含まれている。ただし、全ノードに同一バージョンのOpenVINO・Python環境が必要で、現時点では研究用途を想定したセットアップとなっている。

インターネット越し（WAN）でも使えますか？

Tailscale等のVPN経由でも使用可能である。特にTop-1ロジット圧縮を有効にすることで、通常のオフィスネットワーク間でも対話速度を維持できる。100ms/hopの遅延をシミュレートしたWAN環境では、フルスタックで11.20 tok/sを達成し、ナイーブな実装（2.77 tok/s）の約4倍の性能を示している。

まとめ：Intel AI PCが切り拓く分散LLM推論の新たな地平

本記事で紹介した3つの技術——beam_idx Gather注入によるモノリシックパリティの達成、マスクベースKVキャッシュ巻き戻しによる投機的デコードの実用化、マイクロバッチングによるマルチユーザースループット向上——は、それぞれ独立した改善でありながら、組み合わせることで相乗効果を発揮する。2台のLunar Lake AI PCを用いたフルスタック構成では、モノリシック（単一マシン）推論の24.54 tok/sに対して43.97 tok/s（1.79倍）のスループットを達成した。この内訳は16.33 tok/s（2段パイプライン単体）×1.797（マイクロバッチング効果）×1.499（投機的デコード効果）という乗算構造になっており、各要素が独立して貢献していることが実測値から確認できる。

最も重要なのは、この高速化が出力品質の劣化を一切伴わない点である。3つの技術すべてにおいて、出力はモノリシック実行とビット単位で完全に一致する。つまり、単一マシンで動かすのと同じLLMを、より多くのユーザーにより高速に提供できることを意味する。

70Bクラスの大規模モデルについても、Llama 3.1 70B INT4を4台のAI PCで分散実行し、投機的デコード（K=10）を用いて5.42 tok/sの対話速度を確認した。1台のIntel AI PCでは絶対にロードできないモデルが、オフィスに転がっているPC数台で実用的な速度で動作するという事実は、エッジAIの可能性を根本から広げるものである。

さらに、WAN環境（100ms/hopの高レイテンシネットワーク）でもフルスタック構成はナイーブなパイプライン実行の4.04倍のスループットを維持し、Top-1ロジット圧縮を併用すれば実WANで22.88 tok/sと、対話速度の閾値を大きく上回る性能を示した。

この研究の本質は、「眠っているハードウェアを活用する」という発想にある。最新のIntel AI PC（Lunar Lake / Panther Lake世代）は強力な統合GPUとNPU、そして16GB以上のユニファイドメモリを備えながら、多くの時間をアイドル状態で過ごしている。この潜在リソースに目を向け、ソフトウェアの工夫だけで分散LLM推論基盤を構築できることを実証した点が、本手法の最大の価値である。データをクラウドに送信せずに済むデータローカリティ、追加投資ゼロで始められるコスト効率、そしてビット単位の再現性保証——これらの特性は、機密データを扱う企業や研究機関にとって極めて重要な選択肢となる。

コードとベンチマークの再現手順は完全にオープンソースとして公開されている（https://github.com/labscommunity/pipeline-sharded-inference-paper）。実際のハードウェアを使って再現検証を行い、自社のAI PC群でどの程度の性能が得られるかを計測してみることを強く勧める。本記事で紹介した3つの技術を組み合わせれば、あなたのオフィスにあるAI PC群も、クラウドに依存しない自律的なLLM推論基盤へと変貌するだろう。

参考資料

関連記事