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

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

3 PFNの事業: AI技術のバリューチェーンを垂直統合 ソリューション・製品 計算基盤 AIチップ PFNは、チップ、計算基盤、生成AI・基盤モデル、ソリューション・製品まで、AI技術のバリュー チェーンを垂直統合し、ソフトウェアとハードウェアを高度に融合することで、競争力の高い技術の 開発および産業応用を進めています。 生成AI・基盤モデル 様々な産業・消費者向けのソリューション・製品群 MN-Core™ MN-Core™ 2 GPUクラスタ MN-3 (MN-Core™ クラスタ) PLaMo Prime（今秋提供予定のLLM） PLaMo Lite（エッジ向けSLM） MN-Core 第三世代 MN-Core™ 2のクラウド提供 (2024年開始予定） 物質の電子状態・ エネルギー計算モデル Preferred Potential (PFP) LLM向け 推論チップ

4 ● PFNグループでは生成AI基盤モデルを開発中 ● 開発したモデルのβ版をトライアルで提供中 ○ みんな使ってね！ ○ 今ならトライアル期間で無料！ ○ https://plamo.preferredai.jp/ ● 今回は自社でLLMを運用する際に突き当たる LLMならではの辛い部分について話 ● HTTP API経由でLLMを提供する裏側の話 ● LLM周りの知識は無くても大丈夫 ○ 必要に応じて説明を入れます ○ Transformerわからなくても🆗 純国産の生成AI基盤モデル PLaMo

5 ● 認証・認可のGateway ● LLM(PLaMo)を使って文章を生成するLLMサーバ ● 開発人員が少ないので最低限度のコンポーネントに 簡単なアーキテクチャ ユーザ Gateway LLMサーバ by PLaMo こんにちは、 お元気ですか こんにちは！ 私は元気です

6 ● 今日はLLMサーバのインフラ的な面について話 ● 話さないこと ○ モデルのアーキテクチャ ○ モデルのトレーニング ○ LLM以外のバックエンドの話 ○ フロントエンド ○ Pythonの闇 ○ LLMの闇 簡単なアーキテクチャ こんにちは、 お元気ですか こんにちは！ 私は元気です ユーザ Gateway LLMサーバ by PLaMo

7 LLMサーバのインフラ面での辛さ

8 LLMサーバは何をしているのか こんにちは、 お元気ですか こんにちは！ 私は元気です ユーザ Gateway LLMサーバ by PLaMo

9 ● LLMをメモリ上に保持し、入力に対する返答を生成して返す ● 仮コードのイメージ ○ 入力を元に1文字ずつ生成 ○ streamならすぐ送信 ○ 非streamなら全部貯めて送信 ● LLMは文章をまとめて生成はせず1文字ずつ生成しかできない ○ bufでためているのはそのせい ○ PLaMoに限らず一般的 ● 厳密にはgenerateするのは1文字ではなくtoken ○ tokenizerによるdecodeが挟まる 　　 LLMサーバの概要 model = PLaMo() …. def generate(input: str, stream: bool): buf = [] for word in model.generate(input) if stream: send_by_stream(word) else: buf += word if not stream: send(buf)

10 ● アプリケーションコードのやっていることはシンプル ● リクエスト処理中は除いて状態は持たないので依存も少ない ○ 理論上はImageMagicの画像変換サーバみたいに無限にスケールする ● 適切にオートスケールつければ問題ないはず。。。 LLMサーバのインフラ的な難しさとは こんにちは、 お元気ですか こんにちは！ 私は元気です ユーザ Gateway LLMサーバ by PLaMo

11 ● アプリケーションコードのやっていることはシンプル ● リクエスト処理中は除いて状態は持たないので依存も少ない ○ 理論上はImageMagicの画像変換サーバみたいに無限にスケールする ● 適切にオートスケールつければ問題ないはず。。。 LLMサーバのインフラ的な難しさとは こんにちは、 お元気ですか こんにちは！ 私は元気です ユーザ Gateway LLMサーバ by PLaMo そんなことなかった🫠

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

13 ● 100Bモデルのデプロイには200GBのGPUメモリが必要 ○ CUDAの利用は必須 (なのでNVIDIA固定) ○ bfloat16(浮動小数点のフォーマット)が一般的 (諸説あり) ○ 主要クラウドプロバイダーで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はまだどこも提供していないので選択肢の外に LLMはGPU確保も大変

14 ● H100 (2023年製、この中では最新) ○ LLMのトレーニングでも凄く使う ■ 性能が高くコスパが良い ■ MetaのLLaMa 3.1では1万6000台使用 ○ 去年は50万枚生産されたが... ■ ほとんどGAFAMが買っている ■ 一部がクラウドに出るので それを世界中で奪い合う ● モデルトレーニングするなら社内でも ● というかA100の3倍強いのでトレーニングに回すほうが良い ● A100 (2020年製、H100の1世代前) ○ まだまだ現役で空きは少ない……が現実的な選択肢はこれ ■ 「エヌビディアのGPUサーバーが確保できない」、国内のLLM開発企業が悲鳴 ● L40 (2023年製、推論特化GPU) ○ まだ広く利用可能ではない ○ 先月AWSの一部で利用可能に 世界にはGPUが少なすぎる 出典: Nvidia sold half a million H100 AI GPUs in Q3 thanks to Meta, Facebook — lead times stretch up to 52 weeks: Report

15 ● 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万 GPUは凄く高い

16 ● LLMは起動に時間がかかる ● GPUインスタンスが用意できるか怪しい よって、リクエストに応じた自動スケーリングは難しい ● GPUインスタンスはとても高い ● 余らせるならトレーニング側で欲しくなる よって、余分に立ち上げておくのも難しい 限られた台数の GPUをどれだけ使い倒せるかが勝負 ≒GPUを100%使い切りつつ、ユーザ体感を損ねないギリギリのラインを目指す LLMはリソース管理がとても難しい

17 GPUをどう使い倒すか

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

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

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

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

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

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

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

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

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

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

28 GPU ● GPUもCPUと同じく演算器の近くにキャッシュを持つ ● 重み(例:200GB)はキャッシュに乗らない ■ 分割して演算部分に送り込む必要がある ■ 何回も読み込みが実行される 生成時はGPUの転送速度がボトルネック 演算器 キャッシュメモリ output.. GPUメモリ LLM part 1 LLM part 2 LLM LLM part n 演算 output2 重みをすべて 処理するまで 繰り返すと １文字生成できる

29 GPUは計算が爆速なのでloadのほうが時間を取る　 t ● decodeの計算は重みのloadに比べて一瞬 ○ そもそも計算が爆速 ○ 計算対象も生成したoutputを元にするので少ない ● 「生成した文字数×重み」をloadする必要がある ○ 100文字生成するなら200GB * 100 = 20TB みたいなイメージ ● 演算はムーアの法則に沿って伸びてるが転送速度はそこまで伸びてない decode時は転送速度がボトルネック output1 重み load 計 算 1字 生成 完了 重み load 重み load 重み load 重み load 重み load 計 算 計 算 計 算 計 算

30 ● loadする重みは全ユーザで共通 ● 1回読み込んで複数回の計算をすると効率が良い ○ 重みのloadを1回にまとめられる 同じ重みを使う計算はまとめると効率良い 引用元: Attention Is All You Need GPU 演算器 キャッシュメモリ outputα GPUメモリ LLM part 1 LLM part 2 LLM LLM part 1 outputβ outputγ outputε

31 ● レイテンシは短くならないがスループットは向上する ● いかに同じプロセスにリクエストを束ねるかが重要になる リクエストをまとめるとスループットが良くなる 重み load t 計 算 完 了 完 了 完 了 完 了 計 算 ユーザ Application LLM Serer ユーザ GPU Quque 待たせすぎると体感が悪化するので、 レイテンシとスループットのトレードオフ 重み load 重み load 重み load 重み load output1 output2 output3 output4 計 算 計 算 計 算 計 算 計 算 計 算 計 算 計 算 計 算 計 算 計 算 計 算 計 算 計 算 計 算 Process Process Process

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

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

34 ただのバッチだけだとまだ不足 ● LLMの出力は入力によって異なる ○ 数文字で終わる場合も、長文の場合もある ○ バッチ処理の一部だけ先に終わることがある ○ 後半はバッチ処理の効率が悪くなりうる 計算1 計算1 計算1 生成1 終了1 計算2 計算2 生成2 生成2 生成2 生成2 生成2 生成2 生成2 計算3 計算3 生成3 終了3 こんにちは ピカソの本名は？ 山！ 川！ こんにちは パブロ・ディエゴ・ホセ・フラ...

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

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

37 まとめ ● PFNグループはLLMを作って運用している ● LLMの運用は一般的なWeb Applicationとは違う特性をもつ ● GPUリソースは気軽に増やせないので事前の計画が大変 ○ GPUを使い倒す高速化のコスパが良い ● バッチ処理がGPUの特性上凄く効く ○ リクエストを束ねると劇的にスループットが上がる ○ あえて負荷分散しないという選択肢 ● LLMのinfra/backend/frontend/archtecutreのどれかに興味がある人 達！ PFNで僕と握手！ ○ LLM以外も募集してます⊂(・8・)⊃