GPUを“遊ばせない”――銀行が「アクセラレータ1万枚」の利用率を35%→60%超に、その工夫とは?:処理内容によって計算リソースの「使い方が違う」ことがハードルに
GPUなどのアクセラレータカードを約1万枚導入した中国の招商銀行では、その利用率をどう高めるかが課題になっていた。複数のOSSを組み合わせて、利用率を大幅に引き上げたという。その具体的な方法とは。
中国の銀行大手である招商銀行(China Merchants Bank)は、AIの演算を担うGPU(グラフィックス処理プロセッサ)などのアクセラレータカードを約1万枚利用している。AI活用を進める一方で、用意した計算リソースをいかに効率よく使うかが課題となっていた。そこでハードルになったのは、学習(トレーニング)やファインチューニング、推論の各処理において、計算リソースの使い方が大きく異なることだった。
特に計算リソースに対する要求の違いが大きいのが「分散学習」と「オンライン推論」だった。分散学習は、1つの学習を複数のワーカー(学習を分担する実行単位)に分けて進める方式だ。必要なワーカーとアクセラレータカードがそろうまで実質的に処理を進められず、一部のワーカーが先に起動しても、残りがそろうまで確保した計算リソースが遊休状態になる。一方でオンライン推論は、利用者のリクエストにリアルタイムで応答する処理だ。リクエスト量の予測は難しいことから、需要に応じて使用する計算リソースを素早く増減させる必要がある。
利用率35%→60%超、GPUなどを“遊ばせない”ために何をした?
性質の異なる複数の処理で、同じアクセラレータカードの計算リソースを効率よく使うにはどうすればよいのか――。招商銀行は、複数のオープンソースソフトウェア(OSS)を組み合わせて、この課題を解決する仕組みを構築した。その結果、アクセラレータカードの利用率が大きく向上し、推論のコストも大幅に下がったという。どのように構築したのか。
招商銀行のAIインフラチームは、コンテナオーケストレーションツール「Kubernetes」に複数のOSSを組み合わせて、「統合コントロールプレーン」を構築した。統合コントロールプレーンは、学習や推論などの処理に対する、アクセラレータカードの計算リソースの割り当てを一元的に管理・制御する仕組みだ。
AIインフラチームは招商銀行のデータセンターチームと連携し、アクセラレータカードの計算リソースの99%を、この統合コントロールプレーンで管理することにした。学習と推論では、アクセラレータカードの計算リソースを共有する一方、それぞれの実行環境(ランタイム)は分離した。計算リソースを共有しながら、それぞれに適した仕組みで処理できるようにする狙いだ。
招商銀行は用途に応じてOSSを組み合わせた。学習では、Kubernetesにおけるジョブ(処理単位)を効率的にキューイング(待機・順序制御)する「Kueue」を活用。学習ジョブをキュー(実行待ち行列)に入れ、計算リソースのクオータ(利用できる上限)を基に実行を開始できるかどうかを判断するようにした。これにより、実行できる状態になる前に計算リソースを確保してしまうことを防ぐ。
推論では、システムの稼働状況を監視する「Prometheus」で、推論リクエストの量や待ち時間などの指標を取得することにした。その指標を基に、Kubernetes向けのイベント駆動型オートスケーラーである「KEDA」でオンライン推論の処理能力を増減させ、推論リクエストの量の変動に素早く追従できるようにした。
学習と推論の双方で、Kubernetes向けのアクセラレータカード共有ミドルウェア「HAMi」を使い、アクセラレータカードの計算リソースを必要な分だけ割り当てることにした。Kubernetes向けのデータ管理ソフトウェア「Fluid」により、学習では学習用データ、推論ではAIモデルの重み(学習で得たパラメーター)の読み込みを高速化した。
ファインチューニングでは「LoRA」(Low-Rank Adaptation)を引き続き採用することにした。LoRAは、ベースモデル(土台となる学習済みのAIモデル)のパラメーターを固定したまま、ファインチューニング用に追加したパラメーターを学習する手法だ。招商銀行は、複数のLoRAテナント(LoRAによるファインチューニングを利用する単位)が同じアクセラレータカードを共有するマルチテナント運用を採用している。
招商銀行はファインチューニング向けのフレームワーク「Twinkle」により、5つのLoRAテナントで1つのベースモデルのインスタンス(アクセラレータカードで動作するAIモデルの実体)を共有できるようにした。従来はLoRAテナントごとに1つずつベースモデルを用意していたことから、5つのテナントでレプリカ(複製インスタンス)が計5つ必要だった。Twinkleによって、1つのレプリカだけで済むようになった。
推論コストも60%以上減 取り組みは次の段階へ
統合コントロールプレーンで学習や推論の計算リソースを一元管理した結果、約1万枚のアクセラレータカード全体の平均利用率(計算リソースが処理に使われている割合)は35%から60%超に向上した。AIモデルやサービスなどの条件をそろえた場合、オンライン推論のコストは、100万トークン(AIモデルが処理するテキストの単位)当たりで60%以上低くなった。加えてTwinkleによって、アクセラレータカードの計算リソースの使用量が80%減少した。
招商銀行は今後、ファインチューニングで同時に実行するLoRAテナントの数を動的に調整できるようにする計画だ。アクセラレータカードの利用率や学習ジョブの待ち状況、推論の応答にかかる時間(レイテンシ)などを組み合わせて、トークン当たりのコストを基準にした計算リソースの管理にも取り組む。推論では、需要に応じて処理能力を増減させ、需要がない間は処理能力をゼロまで縮小する「サーバレス推論」の実現を目指す。
クラウドネイティブに関する非営利団体Cloud Native Computing Foundation(CNCF)は2026年9月8日(現地時間)、エンドユーザー企業のクラウドネイティブ技術活用事例を競う「CNCF End User Case Study Contest」で招商銀行が優勝したと発表した。中国・上海で開催されたカンファレンス「KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026」の基調講演で明らかにした。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
第一生命が独自AIを3万5000人規模で活用 「“使えない”と思われた社内システムは終わる」問題をどう回避した?
開発した社内システムを現場に定着させるには、何が必要なのか。第一生命は営業支援AI「デジタルバディ」を開発し、3万5000人規模での活用にまで広げた。定着につなげた開発プロセスの工夫とは。
「AIを使えば早くできるでしょ」と言われがち――エンジニアを困らせる"勘違い"の正体とは?
AIは万能ではないのに、非エンジニアから「AIがあるのだから、もっと早くできるのではないか」と期待されてしまう――。エンジニアを悩ませる、こうした“認識のずれ”の背景には何があるのか。調査から探る。
「Windows Server」サポート終了で“ファイルサーバの危機”に直面――ヤマハ系企業はどう乗り越えた?
ヤマハサウンドシステムでは「Windows Server 2012 R2」のサポート終了を前に、ファイルサーバのリプレースを迫られた。本社移転でサーバ室の確保が不透明な中、同社はファイルサーバをどう見直したのか。