自社開発した大規模言語モデルをどうプロダクションに乗せて運用していくか 〜インフラ編〜
ota42yCloud Operator Days 2024
クロージングイベント

自己紹介● 太田佳敬 @ota42y (X/Github)● Engineer Manager in PFN○ ML以外だいたい全部やるエンジニアもやっています○ 経歴■ スマホゲーム会社(C++/Java/Objective-C)■ ヘルスケアスタートアップ会社(Ruby on Rails)■ Preferred Networks(Python/Go/YAML職人)

2

PFNの事業: AI技術のバリューチェーンを垂直統合
PFNは、チップ、計算基盤、生成AI・基盤モデル、ソリューション・製品まで、AI技術のバリューチェーンを垂直統合し、ソフトウェアとハードウェアを高度に融合することで、競争力の高い技術の開発および産業応用を進めています。
様々な産業・消費者向けのソリューション・製品群

ソリューション・製品

Preferred Potential (PFP)

生成AI・基盤モデル

PLaMo Prime（今秋提供予定のLLM）
PLaMo Lite（エッジ向けSLM）

計算基盤GPUクラスタMN-3(MN-Core™
クラスタ)

物質の電子状態・エネルギー計算モデル

MN-Core™ 2のクラウド提供(2024年開始予定）

AIチップ
MN-Core™

3

MN-Core™ 2

LLM向け
推論チップ

MN-Core第三世代

純国産の生成AI基盤モデル PLaMo● PFNグループでは生成AI基盤モデルを開発中● 開発したモデルのβ版をトライアルで提供中○ みんな使ってね！
○ 今ならトライアル期間で無料！
○ https://plamo.preferredai.jp/● 今回は自社でLLMを運用する際に突き当たる
LLMならではの辛い部分について話● HTTP API経由でLLMを提供する裏側の話● LLM周りの知識は無くても大丈夫○ 必要に応じて説明を入れます○ Transformerわからなくても🆗
4簡単なアーキテクチャ● 認証・認可のGateway● LLM(PLaMo)を使って文章を生成するLLMサーバ● 開発人員が少ないので最低限度のコンポーネントにこんにちは、お元気ですかGateway
ユーザ5LLMサーバ
by
PLaMo
こんにちは！
私は元気です簡単なアーキテクチャ● 今日はLLMサーバのインフラ的な面について話● 話さないこと○ モデルのアーキテクチャ○ モデルのトレーニング○ LLM以外のバックエンドの話○ フロントエンド○ Pythonの闇
こんにちは、○ LLMの闇
お元気ですかGateway
ユーザ

6

LLMサーバby
PLaMo
こんにちは！
私は元気ですLLMサーバのインフラ面での辛さ

7

LLMサーバは何をしているのか

こんにちは、お元気ですかGateway
ユーザ

8

LLMサーバby
PLaMo
こんにちは！
私は元気ですLLMサーバの概要● LLMをメモリ上に保持し、入力に対する返答を生成して返す● 仮コードのイメージ
model = PLaMo()○ 入力を元に1文字ずつ生成….
○ streamならすぐ送信
def generate(input: str, stream: bool):○ 非streamなら全部貯めて送信●●

LLMは文章をまとめて生成はせず1文字ずつ生成しかできない○
bufでためているのはそのせい○
PLaMoに限らず一般的
厳密にはgenerateするのは1文字ではなくtoken○
tokenizerによるdecodeが挟まる

9

buf = []
for word in model.generate(input)
if stream:
send_by_stream(word)else:
buf += word
if not stream:send(buf)

LLMサーバのインフラ的な難しさとは● アプリケーションコードのやっていることはシンプル● リクエスト処理中は除いて状態は持たないので依存も少ない○

理論上はImageMagicの画像変換サーバみたいに無限にスケールする● 適切にオートスケールつければ問題ないはず。。。

こんにちは、
お元気ですかGateway
ユーザ

10

LLMサーバ
byPLaMo
こんにちは！
私は元気ですLLMサーバのインフラ的な難しさとは● アプリケーションコードのやっていることはシンプル● リクエスト処理中は除いて状態は持たないので依存も少ない○

理論上はImageMagicの画像変換サーバみたいに無限にスケールする● 適切にオートスケールつければ問題ないはず。。。

そんなことなかった🫠
こんにちは、お元気ですかGateway
ユーザ11

LLMサーバ
byPLaMo
こんにちは！
私は元気ですLLMはあまりにLargeすぎる● PLaMo β版は1000億パラメータ(100 Billion)のモデルを利用中○ パラメータは16bit浮動小数点で読み込む前提○ 100 Billion * 2 byte (16bit) = 200GB● 起動後にGPUのメモリにこの200GBをロードする必要がある○ 単純なロードではないため、実測値7-10分ぐらい(A100での話)○ +インスタンスの起動とか諸々で最低10分は見込む必要あり● リクエスト増えてから立ち上げるのは全然間に合わない😇

12

LLMはGPU確保も大変● 100Bモデルのデプロイには200GBのGPUメモリが必要
CUDAの利用は必須 (なのでNVIDIA固定)○ bﬂoat16(浮動小数点のフォーマット)が一般的○ 主要クラウドプロバイダーで200GB確保できる■ 1インスタンスあたりGPU1〜8枚が一般的■ 複数インスタンス構成は一旦考えず1台で考える○(諸説あり)● NVIDIA GPUの選択肢は事実上以下のみ○ H100 (1枚80GB or 94GB)○ A100 (1枚40GB or 80GB)○ L40 (1枚48GB)○○

L4/A10とかは8枚で196GBまでしか取れないのでNG
H200はまだどこも提供していないので選択肢の外に

13

世界にはGPUが少なすぎる● H100 (2023年製、この中では最新)○ LLMのトレーニングでも凄く使う■ 性能が高くコスパが良い■ MetaのLLaMa 3.1では1万6000台使用○ 去年は50万枚生産されたが...
■ ほとんどGAFAMが買っている■ 一部がクラウドに出るのでそれを世界中で奪い合う●●

モデルトレーニングするなら社内でもというかA100の3倍強いのでトレーニングに回すほうが良い

出典: Nvidia sold half a million H100 AI GPUs in Q3 thanks toMeta, Facebook — lead times stretch up to 52 weeks: Report● A100 (2020年製、H100の1世代前)○ まだまだ現役で空きは少ない……が現実的な選択肢はこれ■「エヌビディアのGPUサーバーが確保できない」、国内のLLM開発企業が悲鳴● L40 (2023年製、推論特化GPU)○ まだ広く利用可能ではない○

先月AWSの一部で利用可能に

14

GPUは凄く高い● GPUを運よく確保できても、手放すと次取れる保障はない○ 必然的に常に確保し続ける必要あり(≒reserved割引が効く)● (A100前提で)1年間reservedして保有する場合○ 確保するのはA100(40GB) * 8枚のインスタンス■

本当はギリギリ5枚でよいが、だいたい1,2,4,8枚単位○ reserved割引後でだいたい $20-24/hour■■

AWS/GCP/Azure
間の$22/hourで考える○ $22/h * 365d = $192,720 (*140) = 2,698万/year (230万/month)■ LLM1つ動かすのに年間2700万■

参考: AWSで一番強いAuroraインスタンスdb.r6gd.16xlargeは年1135万
15LLMはリソース管理がとても難しい● LLMは起動に時間がかかる● GPUインスタンスが用意できるか怪しい
よって、リクエストに応じた自動スケーリングは難しい● GPUインスタンスはとても高い● 余らせるならトレーニング側で欲しくなる
よって、余分に立ち上げておくのも難しい

限られた台数のGPUをどれだけ使い倒せるかが勝負≒GPUを100%使い切りつつ、ユーザ体感を損ねないギリギリのラインを目指す

16

GPUをどう使い倒すか17

処理の高速化の重要性がとても高い● インフラ的にGPUを増やすのは凄くコストが高い○ 少ないGPUで可能な限り多くのリクエストをさばけると嬉しい○ 通常のWebアプリケーションより処理の高速化が重要■ 高速化を頑張るコスト < インスタンスのコスト になりやすい● LLMの高速化手法はまさに研究途中○ モデルアーキテクチャに関するものからデプロイで頑張るものまで○ インフラと関わるいくつかの手法を紹介します18

LLMの生成は2stepに分けられる● LLMの生成は2stepからなる○ 入力をもとに中間状態を作る(preﬁll)○ 中間状態を元に文字を生成する(decode)● 入力から中間状態を作るまで(preﬁll)○ 入力を使って中間状態を計算する○ 大量の計算をひたすらやっていく○ GPUの計算部分が全力で動くのでここがボトルネック

19生成時はGPUの転送速度がボトルネック
結果を元に次tokenを生成● 生成が始まってから(decode)○ これまでの生成結果を元に次の1文字を生成する○ 1文字生成するためにはすべての重みに対して計算しなければならない
output×LLM=output2

引用元: Attention Is All You Need20

生成時はGPUの転送速度がボトルネック
結果を元に次tokenを生成● 生成が始まってから(decode)○ これまでの生成結果を元に次の1文字を生成する○ 1文字生成するためにはすべての重みに対して計算しなければならない
output×LLM=output2

output2×

LLM=output3

引用元: Attention Is All You Need21

生成時はGPUの転送速度がボトルネック● GPUもCPUと同じく演算器の近くにキャッシュを持つ● 重み(例:200GB)はキャッシュに乗らない

GPU

GPUメモリ

output

LLM
キャッシュメモリ

演算器
22

生成時はGPUの転送速度がボトルネック● GPUもCPUと同じく演算器の近くにキャッシュを持つ● 重み(例:200GB)はキャッシュに乗らない■ 分割して演算部分に送り込む必要がある■ 何回も読み込みが実行される

GPU
outputGPUメモリロード
LLMpart 1キャッシュメモリ

演算器

LLM
part 1

LLM
part 2
LLM
23

生成時はGPUの転送速度がボトルネック● GPUもCPUと同じく演算器の近くにキャッシュを持つ● 重み(例:200GB)はキャッシュに乗らない■ 分割して演算部分に送り込む必要がある■ 何回も読み込みが実行される

GPU

GPUメモリ

output演算
キャッシュメモリ
output’演算器

LLM
part 1

LLM
part 1
LLM
part 2
LLM
24

生成時はGPUの転送速度がボトルネック● GPUもCPUと同じく演算器の近くにキャッシュを持つ● 重み(例:200GB)はキャッシュに乗らない■ 分割して演算部分に送り込む必要がある■ 何回も読み込みが実行される

GPU
output’演算
キャッシュメモリ

演算器

LLM
part 2

GPUメモリロード
LLMpart 1
LLM
part 2
LLM
25

生成時はGPUの転送速度がボトルネック● GPUもCPUと同じく演算器の近くにキャッシュを持つ● 重み(例:200GB)はキャッシュに乗らない■ 分割して演算部分に送り込む必要がある■ 何回も読み込みが実行される

GPU

GPUメモリ

output’演算
キャッシュメモリ
output’’演算器

LLM
part 2

LLM
part 1
LLM
part 2
LLM26

生成時はGPUの転送速度がボトルネック● GPUもCPUと同じく演算器の近くにキャッシュを持つ● 重み(例:200GB)はキャッシュに乗らない■ 分割して演算部分に送り込む必要がある■ 何回も読み込みが実行される

GPU

GPUメモリ

output’’演算キャッシュメモリ
output’’’演算器

LLM
part 3

LLM
part 1
LLM
part 2
LLM
27

生成時はGPUの転送速度がボトルネック● GPUもCPUと同じく演算器の近くにキャッシュを持つ● 重み(例:200GB)はキャッシュに乗らない■ 分割して演算部分に送り込む必要がある■ 何回も読み込みが実行される

GPU
output2

output..

演算
キャッシュメモリ

演算器

GPUメモリ

LLM
part n

LLM
part 1
LLM
part 2
LLM
28

重みをすべて処理するまで繰り返すと１文字生成できる

GPUは計算が爆速なのでloadのほうが時間を取る
output1

重みload

計算重みload計算

重みload計算

重みload

1字計
生成
算
完了

重みload

計 重み
算 loadt● decodeの計算は重みのloadに比べて一瞬○○

そもそも計算が爆速
計算対象も生成したoutputを元にするので少ない● 「生成した文字数×重み」をloadする必要がある○

100文字生成するなら200GB * 100 = 20TB みたいなイメージ● 演算はムーアの法則に沿って伸びてるが転送速度はそこまで伸びてない
decode時は転送速度がボトルネック
29

同じ重みを使う計算はまとめると効率良い● loadする重みは全ユーザで共通● 1回読み込んで複数回の計算をすると効率が良い○ 重みのloadを1回にまとめられるGPU
outputαoutputγ

GPUメモリ
outputβ
outputεキャッシュメモリ

演算器

LLM
part 1

LLM
part 1
LLM
part 2
LLM
30

引用元: Attention Is All You Needリクエストをまとめるとスループットが良くなる
重み
load

output1

重みload

重みload計算

計算

完了
計
算

計算
計
算

計算

output4

計算

完了計算

計算
計算

計
算

output3重みload計算

計算
計算

計算

output2重みload計算

完了
計算● レイテンシは短くならないがスループットは向上する● いかに同じプロセスにリクエストを束ねるかが重要になる
ユーザ

Application
Process

ユーザ

Process

Process

待たせすぎると体感が悪化するので、レイテンシとスループットのトレードオフ

LLM SererGPU

Quque31完了tWeb Applicationのベスプラが効きにくくなる● 一般的なWebアプリケーションでは処理は混ぜない○ リクエストごとにプロセス・スレッド等で厳格に分けられる○ DBへのコネクションも別(使いまわしたりはするが)■データは一個のtableになるがそこはDBが担保● 基本的に共用するメリットよりデメリットのほうが多い○ 束ねても早くなりにくため待ち時間の割合が大きくなる○ 処理が交わらないように適切に実装しないといけない
Application

DB

Process

ユーザ

tableconnection
Process

Process

ユーザ

connection32

LBの意味合いも変わってくる● LBはリクエストを分散させて負荷を均等にする● LLMの場合1台に集中させて負荷を上げたほうがコスパが良い○ 均等に動かすと逆にスループットは悪化する○ とはいえバッチだとレイテンシは悪化するのでトレードオフ
LB

ユーザ

App

LB

App

ユーザ

App

LLM App

LLM App

LLM App

ユーザ

ユーザ
33

ただのバッチだけだとまだ不足● LLMの出力は入力によって異なる○ 数文字で終わる場合も、長文の場合もある○ バッチ処理の一部だけ先に終わることがある○ 後半はバッチ処理の効率が悪くなりうる

こんにちは

計算1

計算1

計算1

生成1

終了1

ピカソの本名は？

計算2

計算2

生成2

生成2

生成2計算3

計算3

生成3

終了3

山！

こんにちは
生成2

生成2

生成2

生成2

パブロ・ディエゴ・ホセ・フラ...
川！

34

Continuous Batching
Continuous batching● LLMの出力は入力によって異なる○ 数文字で終わる場合も、長文の場合もある○ バッチ処理の一部だけ先に終わることがある○ 後半はバッチ処理の効率が悪くなりうる● 一連の処理を細かく分割し、ループ中に判定を行う○ 終わっていたら次の処理を始める○ バッチが終わってないがGPUは暇している という状態を防げる○ 1プロセスに大量に処理を詰め込むと、GPUをより使い倒せる
計算1

計算1

計算1

生成1

終了1

計算2

計算2

生成2

生成2

生成2

計算3

計算3

生成3

終了3

生成2

生成2

生成2

生成2

35

計算1

計算1

計算1

生成1

終了1

計算5

計算5

生成5終了5

計算2

計算2

生成2

生成2

生成2

生成2

生成2

生成2

生成2

計算3

計算3

生成3

終了3

計算4計算4

計算4

計算4

生成4

もし時間が余ったら話したい話● Tensor Parallel○ GPU 1枚あたり40GBしかないのでモデルの分割は必須○ 複数GPUで並列に読み込むのでload時間は早くなる○ ≒GPUを並べるとレイテンシは上がる○ 複数プロセスで安定&スループット上げるかよりGPUを割り当てて速度を上げるか● 量子化○ 100Bを16bitで読み込んでいるから200GBが必要○ 8bit/4bitで読み込めば容量が減る=推論のloadが減る=早い○ 情報が落ちる≒精度が下がるのとトレードオフ● バッチ処理を最大に活用するにはQueueが欲しいが…
○ stream処理と合わせたときの実装が複雑○ 運用コストを減らしたいので断念(Tensor Parallelism)

GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers○(状態を持つサーバを管理するだけのパワーがチームにない😇)

36

まとめ
● PFNグループはLLMを作って運用している● LLMの運用は一般的なWeb Applicationとは違う特性をもつ● GPUリソースは気軽に増やせないので事前の計画が大変○ GPUを使い倒す高速化のコスパが良い● バッチ処理がGPUの特性上凄く効く○ リクエストを束ねると劇的にスループットが上がる○ あえて負荷分散しないという選択肢●

LLMのinfra/backend/frontend/archtecutreのどれかに興味がある人達！
PFNで僕と握手！
○

LLM以外も募集してます⊂(・8・)⊃37