9月8日、IBM Researchが「How llm-d makes the most of the hardware you already have」と題した記事を公開した。オープンソースのLLM推論フレームワーク「llm-d」を用いて753Bパラメータの大規模モデルをH100 GPU上で動かし、商用API比でトークンあたり5〜10倍のコスト削減を実現した実装知見を詳細に紹介している。「次世代アクセラレータを待たなくても、今持っているH100フリートでフロンティア規模のモデルが動く」——この主張を裏付ける数字が揃っている。
なぜ今、エージェント型推論が注目されるのか
LLMを取り巻く状況は、チャットボット的な単発Q&Aから、複数ステップを自律的にこなす「エージェント」利用へと急速にシフトしている。コーディング補助・自動テスト・セキュリティ解析など、エージェントが長大なコンテキストを何度も参照しながら並列で動作するユースケースが増えるにつれ、推論コストと遅延の問題は以前とは質的に異なる形で顕在化してきた。
同時に、エンタープライズがLLMを自社インフラで動かしたい理由も明快だ。トークン単価の高騰と、プロプライエタリなコードやデータを外部APIに送りたくないというセキュリティ上の要請である。IBM Research、Red Hat、Googleが主導するオープンソースプロジェクトllm-dは、この課題に正面から取り組んでいる。
商用API比5〜10倍のコスト削減——H100で753Bモデルを動かす
今回の検証では、約753Bパラメータ（アクティブパラメータ約39B）のMixture-of-Expertsモデルを、544枚のNVIDIA H100 GPU上に展開した。現行クラウドレンタル価格を基準にすると、llm-dによるセルフホストのコストは、同等の商用APIと比べてトークンあたり5〜10倍安い。特にエージェント型ワークロード特有の「入力トークン比率が高いトラフィックパターン」でこの差が大きく出る。
H100はH200やBlackwellと比べると一世代前のGPUだが、多くの企業がすでに大規模に運用している。今回のデモは「調達済みのH100フリートをそのまま活かせる」というメッセージを企業向けに強く打ち出している。
エージェント型ワークロードは従来の推論と何が違うのか
llm-dが解こうとしている問題を理解するには、エージェント型ワークロードの特性を把握する必要がある。
実際のコーディングエージェントセッション219件の分析によると、リクエストの中央値は入力トークン約195,000に対して出力はわずか317トークンだった。計算コストの大半は「テキスト生成」ではなく「コンテキストの読み込み」に費やされている。
さらに重要なのが「コンテキストの再利用」だ。メインエージェントのリクエストの96%が、直前リクエストの入力の90%以上を一字一句再利用していた。同じソフトウェアリポジトリを何度も繰り返し処理するという構造的な無駄が発生している。加えて、サブエージェントの並列実行による予測不能なバースト（全リクエストの半数超が事前予告なしの並行サブエージェントタスク）も、従来の推論システムには想定外の負荷を与える。
6つの最適化の組み合わせ
llm-dが今回用いた主な技術は以下の6つで、単体の効果ではなくこれらの組み合わせが重要だとチームは強調している。
- プレフィックス対応ルーティング（Prefix-aware routing）: キャッシュされたコンテキストを持つサーバーにリクエストを転送し、再計算を回避。CyberGymベンチマークでは、近似ルーティングから精密なプレフィックスマッチングに切り替えることでスループット79%向上、TTFT（Time-to-First-Token）67%削減を達成した。
- 階層型KVキャッシュ管理: GPU VRAMに収まらないキャッシュをCPU DRAMに退避し、プレフィックスの再計算を防ぐ。
- P2P KVキャッシュ共有: 必要なキャッシュが別サーバーにある場合、そのサーバーから直接取得する。
- Wide Expert Parallelism with Data-Parallel Attention: 753Bモデルを複数ノードに分散。Multi-Head Latent Attention（MLA）アーキテクチャでテンソル並列が必要とするKVキャッシュの複製を回避する。
- Prefill/Decode 分離（Disaggregation）: コンテキスト処理とトークン生成を独立したプールに分け、それぞれ個別にスケールする。2つのプールの通信はNVIDIAのNIXLライブラリによるゼロコピー転送で行われ、ベンチマーク全体を通じて転送失敗ゼロを記録した。
- Multi-Token Prediction（MTP）: 1回のフォワードパスで複数トークンを生成し、高並列時の出力スループットを向上させる。
ベンチマーク結果——最も刺さる数字
3種類の構造化ベンチマークで検証が行われた。なかでも際立つ数字を先に挙げると、入力トークンの85.2%をキャッシュから提供し、フルの再計算が必要な処理を14.8%まで削減している点だ。CPU階層キャッシュの導入により、GPU単体キャッシュと比較して残りの再計算量をさらに約45%削減した。
各ベンチマークの概要は以下のとおりだ。
AutomationBench（大規模並行コーディングエージェント）では、2,500エージェント同時並行時に毎分7,612リクエスト、入力トークン毎分1億3,489万、出力トークン毎分605万をプリエンプションゼロで維持。3,000エージェント時には出力が毎分660万トークンに達した。
CyberGym（長コンテキスト・エージェント完了）では、400エージェントが376K文字のコンテキストを10ターン処理。全400エージェントのトラジェクトリが248秒で完了し、ローカルプレフィックスヒット率は近似ルーティング時の44.46%から73.18%に向上した。
AgentX（インタラクティブスループット）では、128エージェントが約195Kトークンのコンテキストを約15分間処理し、7,251リクエストを7.7 req/sで完了した。
NIXLは合計620万回のKVキャッシュ転送を実行し、転送あたり平均2.71 GiB、フリートp90で約580 Gb/sを維持、転送失敗はゼロだった。
オープンソースとして進化を続ける
llm-dは現在、Cloud Native Computing Foundation（CNCF）のサンドボックスプロジェクトとして運営されており、IBM Research、Red Hat、Googleのほか、コントリビューターのコミュニティが参加している。デプロイメントガイドや検証済み設定、マルチプラットフォームサポートが提供されている。
IBM ResearchのDistinguished Engineerでllm-dメンテナーのCarlos Costaは「エージェント推論はシステムの問題だ。勝ちはGPUの生のスループットだけでなく、冗長な処理の回避、正しいキャッシュへのルーティング、プレフィルとデコードの独立したスケールによって生まれる」とコメントしている。
詳細はHow llm-d makes the most of the hardware you already haveを参照していただきたい。
