LLMで推論するための ライブラリを整理する 2024/07/30 Shibui Yusuke

自己紹介 shibui yusuke ● いろいろ → Stability AI Japan（いまここ） ● MLOps & データ & バックエンド & インフラ & その他諸々エンジニア ● Github: @shibuiwilliam ● FB: yusuke.shibui ● 本発表は私個人の見解であり、 所属組織を代表するものではありません。 cat : 0.55 dog: 0.45 human : 0.70 gorilla : 0.30 物体検知

● 発売中！ ● https://www.amazon.co.jp/dp/4798169447/ ● 発売中！ ● https://www.amazon.co.jp/dp/4798173401/

技術評論社 Software & Designで MLOpsについて連載しました！ ● 2023年8月号　 MLOpsの概要 ● 2023年9月号　 MLOpsのためのスキルセットとチーム構成 ● 2023年10月号　方針策定とMLOpsのためのツール ● 2023年11月号　MLOpsのための技術選定 ● 2023年12月号　LLMのためのDevOps ● 2024年1月号　 MLOpsと評価 ● 2024年2月号　 推論システム（予定） ● 2024年3月号　 機械学習システムの引き継ぎ ● 2024年4月号　 LLMのデータエンジニアリング ● 2024年5月号　 機械学習の使い途と未来 MLOpsについてあまり他では取り上げられないテーマを 中心に記事を書きました！

生成AIの推論と構成

● 第一候補：ChatUIやAPIで公開されているLLMを使う。 ○ 例：OpenAI GPT、Google Gemini、Anthropic Claude。 ○ 利点：簡単に使い始められる。性能も良い。 Chatで検証できる。 ○ 難点：自社専用にできない。カスタマイズが難しい。障害率高い。 ● データだけでも自社のものを使いたい： RAGを構築する。 ○ 例：Dify.aiとかすごい便利。 ○ 利点：データがあれば始められる。 ○ 難点：LLMよりもデータ整理や検索性能で詰まることが多い。 ● 完全に自社専用に用意したい：基盤モデルから学習する。 ○ 例：llama3等を使ったモデル開発。 ○ 利点：目的や用途専用にカスタマイズできる。 ○ 難点：GPUの確保とか推論システムの構築とかデータ準備とか。 使うことから考える LLMの選定

第一候補： APIで公開されている LLMを使う ● 使い方 ○ 選択肢1. サービスが公開している UIやAPI、ライブラリを使う。 ○ 選択肢2. Langchain等の統合ライブラリを使う。 ● インターフェイス：最近の APIやライブラリはOpenAI GPTのインターフェイスを 真似ているものが多いため、抽象化しやすい。 ○ しかしLangchainの苦労を見てると、いろいろ課題は多い。 ● 個人的な好み：JSON modeやFunction Callingを使って構造化された JSONで リクエスト、レスポンスすると開発が楽（不確定な自然言語処理が減る）。 ● 注意点 ○ 課金はリクエストよりレスポンスのプロンプトのほうが高い。 長文をレスポンスさせるのは得策ではない。 ○ Moderationが厳しい。 ○ 入力トークン量は緩和されてきてる。

データだけでも自社のものを使いたい： RAGを構築する ● データ検索の改善と自作する箇所の選定が難しい。 検索 統合 生成 社内文書や DB インターネット LLM 検索ワードを 生成 情報を整理 文章生成 要自作 ロジックは 要自作 自作は 超大変 自作 不可能 検索Indexは要自作 検索基盤はOSS等を 使うことが多い プロンプトは 要自作 ワークフローの インテグレーションをがんばろう！ UI ツール 次第 コスト、運用、安定、 セキュリティ！ 非機能要件超重要！

完全に自社専用に用意したい：基盤モデルから学習する ● 基盤モデル選定、データ用意、事前学習、チューニング、評価、 Lora等。 ● 全工程が必要とは限らないが、目的、評価、デプロイ、ユーザは必ず登場する。 基盤 モデル データ 目的 Issue 目的に応じて用意する 事前 学習 クレンジ ング チューニング (RLHF, SFT, DPO…) 評価 Lora UI, RAG 解決できてる？ デプ ロイ

LLMの小型化がトレンド（？）

デプロイを考える 基盤 モデル データ 目的 Issue 目的に応じて用意する 事前 学習 クレンジ ング チューニング (RLHF, SFT, DPO…) 評価 Lora UI, RAG 解決できてる？ デプ ロイ ● 機能要件：学習（データやLora含む）やRAGでどうにかする。 ○ 自然言語処理。 ○ リクエストに対して適切なレスポンスを返す。 ● 非機能要件：エンジニアの腕の見せ所！ ○ レイテンシとスループット ○ 安定性 ○ コスト ○ デプロイ容易性とスケーラビリティ ○ トラブルシューティング ○ ログとメトリクス

LLMの推論で考慮すること ● 不適切なリクエスト ○ 「爆弾の作り方を教えて」のような不適切なリクエストには回答しないことが 重要。 ○ ファインチューニングで不適切なリクエストに回答しないように 学習することが可能。 ○ 網羅しきれない or 品質が低い場合は不適切な文章を判定する自然言語モデルを 別に用意することも検討。コスト、レイテンシ、品質次第。 ● ハルシネーションや不適切なレスポンス ○ ユーザ向けに推論している場合、推論結果が適切、合法、正確等であることが 望ましい。 ○ LLMレベルで品質を担保できない場合はレスポンス前に不適切さを判定する 自然言語モデルを別に用意することも検討。コスト、レイテンシ、品質次第。

不適切なリクエスト対策 ● 事前に判定してフィルタリング ● レッドチーミング（Red teaming） LLM 推論器 リスク 判定AI 猫の飼い方 を教えて 人のXXし方 を教えて 不適切な質問を判定するAIを 用意する必要がある。 LLM 推論器 猫の飼い方 を教えて 人のXXし方 を教えて 事前に不適切な 質問と回答を 学習しておく。 猫の飼い方 は・・・ その質問に はお答えで きません。

技術選定 ● LLMの学習で使う主なライブラリ ○ PyTorch + Transformers ○ Jax/Flax（あとTensorFlowやKeras） ● 推論で使う主なライブラリ ライブラリ PyTorch Jax/Flax TorchServe ◯ ✕ ONNX Runtime ◯ ◯ TF Serving ✕ ◯ vLLM ◯ ✕ DeepSpeed ◯ ✕ llama.cpp ◯ ✕ 注：◯になっててもすべてのモデルをサポートしてるとは限らない。

技術選定 ● 推論で使えるライブラリや基盤は学習時のモデルやライブラリに依存することが多い。 ● 推論ライブラリがすべてのモデルをサポートしているとは限らない。 ○ ライブラリによってサポートしているモデルは異なる。 ○ 計算基盤（CPU, GPU, TPU）によってもサポートしているモデルは違う。 ○ 特定のライブラリはGPUで特定のモデルを稼働させることはできるけど、 CPUでは動かないこともある。 ● ひとまずメジャーな計算基盤でメジャーなライブラリを使ってメジャーなモデルを 利用するのが無難。 ○ メジャーな計算基盤：NvidiaのGPU ○ メジャーなライブラリ：PyTorch + Transformers ○ メジャーなモデル：Llama系 ○ しかしLLMの開発は日進月歩。他の選択肢が有力になっていく可能性も否めない。 ○ あとGPU確保が難しい・・・。

LLMの推論方式 ● バッチ推論 ● いわゆるバッチ処理。 ● 大量のデータを一挙に推論する。 ● 実行時のみ推論器が必要。 ● レスポンシブな推論 ● ChatやWeb APIのようにリクエストに レスポンスする。 ● 1リクエストに1~レスポンスする。 ● サービス提供中は常に推論器が必要。

バッチ推論 ● 学習用のライブラリをそのまま使って推論するのでも問題ない。 ● そもそも学習プロセス自体が巨大なバッチ処理。 ● PyTorch + TransformersのLLMであれば、TorchScript、torch.compileだけでなく、 AccelerateやFlashAttention、DeepSpeedが有効。 ○ ただし、GPU前提で作られているものもある。 ● バッチ処理されたデータが必要になるスケジュール含めて検討する必要がある。

レスポンシブな推論 ● リクエストに対してレスポンスを返す。 ● 方式はさまざま。 ○ 同期的に推論する。 ○ 非同期に推論する。 ○ 内部的に非同期にする。 ● 推論ランタイムの有力なライブラリ ○ TorchServe ○ vLLM ○ DeepSpeed MII ○ llama.cpp server

内部的に非同期推論 ロードバランサー REST API Inference server Web API server Model Runtime ● 推論サーバの中にQueueと 推論ランタイムを導入。 ● モデルの処理可能なリクエスト量を 内部的にスケジューリングする。 Model Queue

TorchServe ● PyTorchが提供する推論器。 ● REST API、gRPCで起動可能。 ● バッチ、レスポンシブ両方の推論に対応。 ● 起動手順 ○ PyTorchでモデルを学習して保存する。 ○ torch-model-archiverで.marファイルに変換する。 ■ 実態はzipにしているだけ。 ■ 前処理、推論、後処理のプログラムは Pythonでハンドラーに書く。 ○ torchserveで起動。 学習済み モデル.pth torch- model- archiver モデル.mar torchserve config .properties torch- workflow- archiver workflow.yml workflow.mar hander.py

TorchServe ● 利点 ○ 複数バージョンのモデルを同時に起動できる。 ○ DAGワークフローを組める。 ■ 例：modelA→modelB→modelCの順番に推論。 ○ handler_utilsで簡易的なマイクロバッチやストリーム処理を提供。 ○ PiPPy (or torch.distributed.pipelining)によるパイプライン並列処理

PiPPy (torch.distributed.pipelining) ● Pipeline Parallelism for PyTorch。 ● torch.distributed.pipeliningに移行中。 ● 複数GPUにまたがるLLMの推論で有効。 ● Frontend：モデルを読み込み、 データフローを取り込みつつ モデルパーティションに分割する。 ● torchrun：モデルパーティションを それぞれのデバイスに割り当て、 ワーカーを起動する。 ● PiPPy：割り当てられたモデル パーティションをロード。 マイクロバッチに分割された リクエストデータを順次処理する。 Rank0が最初の処理。

vLLM ● 主にLLMの推論に特化したライブラリ。 ● 量子化モデル、VLM（Vision Language Model）、LoRA、Speculative Decodingもサポート。 ● 他の推論ライブラリ同様、公式にサポートしているモデルはvLLM仕様で推論できるように モデルクラスを実装している。 ○ そのため、独自モデルを追加するためには独自にモデルクラスを実装する必要がある。 ● OpenAI API仕様準拠のREST APIサーバを提供（中身はFastAPI）。 ● 推論リクエストは内部的にQueueに登録して非同期に推論している。 ● 利点：Automatic Prefix Caching、並列処理、Speculative Decoding、LoRA。 Llama from HuggingFace vLLM Models LlamaModel StableLMModel … vLLM Engine

vLLM ● Automatic Prefix Caching：推論済みプロンプトの KVキャッシュからPrefixをキャッシュに 登録する。 ● Prefixが共通する場合、キャッシュを使って入力プロンプトの Prefillingをスキップする。 ● 生成（Decoding）を短縮できるわけではない。 ● 用途：RAGやチャットで、毎回推論プロンプトに含まれる長文ドキュメントやチャット履歴を 処理することを回避する。 Prefill Prompt KV cache Decode Result Output Output Output Output ここを短縮

vLLM ● 並列処理 ● 並列手法はMegatron-LMのTensor Parallel。 ● 並列処理にはRayまたはPython標準の Multiprocessingを使用。 ● GPU間のコミュニケーションのために NCCL（NVIDIA Collective Communications Library）を ラップしたPyNcclを実装している。 ● Speculative Decoding (experimental) ● 推論を高速化する手法。 ● 小規模なドラフトモデルで候補トークンを生成した後、 ターゲットモデルで並列に候補トークンを検証して アウトプットを生成する。 Speculative Decoding Tensor Parallel

DeepSpeed ● LLMの学習、推論を高速化するライブラリ。 ● 推論の高速化：並列処理、Deep fusion、Mixture of Quantization、Continuous Batching、 Dynamic SplitFuse等。 ● DeepSpeed-MIIとDeepSpeed-FastGen。

● Deep Fusion ● 複数オペレーションを一つのカーネルに合成する。 ● 要素単位のオペレーション（element-wise operation、 加算、乗算、sin/cos/sigmoid等）自体は早いが、 メモリアクセスがボトルネックになる。 ○ メモリからデータを読む →演算 →メモリに結果を書き出す ● 複数の演算を合成して一つにすることで、メモリアクセスを 一回にまとめ、高速化する。 ここまではtorch.jitやtorch.compileでも可能。 ● Deep Fusionでは複数の演算を組み合わせたレイヤー自体を 合成することで、さらなる高速化を実現。 例：TransformerのQKVやAttention、MLPレイヤー等 DeepSpeed ● 赤い点線が合成の単位。 ● たとえば、左上のQKVを合成することで 1.5倍の高速化を実現している。

● DeepSpeed-MII（Model Implementations for Inference）とDeepSpeed-FastGen ● DeepSpeed-MII：DeepSpeed推論をREST API, gRPCとして稼働するWebサーバ。 ● DeepSpeed-FastGen：MIIの推論を高速化するための各種手法。 DeepSpeed

llama.cpp ● llama.cppはggml（C/C++で実装されたMLライブラリ）でllamaモデルを実装したもの。 ● 推論するにはggufファイルが必要。HuggingFaceやONNXモデルのConverterあり。 ● Converterではメジャーなモデルのアーキテクチャーを判定し、それぞれを修正して ggufに 変換している。まさに執念の業。 そのため、Converterでサポートされていないアーキテクチャーの LLMは独自にgguf変換クラスを 用意する必要がある。 ● CLIとしてLLMを使いたいならllama.cppやollamaは便利。 ● Web APIとして使う場合、ggufファイルを読み込んで REST APIとして起動するllama.cpp serverが 提供されている。 Llama from HuggingFace gguf converter LlamaModel StableLMModel QwenModel … Llama.gguf llama.cpp ollama llama.cpp server CLI REST API

その他LLMの推論で考慮すること ● LLMの処理量をどう計測するか？ ○ 処理負荷 LLMの処理負荷はI/Oのトークン量。 リクエスト量を見ても、処理されるトークン量はわからない。 リクエスト量（RPS）はインフラレベルで計測可能だが、 トークン量（TPR）はアプリケーションレベルでメトリクスを取る必要がある。 ○ このあたりのメトリクスは推論ライブラリで取れるものが多い。 モニタリングシステム（DataDog等）との連携が必要。 ○ 処理負荷 vs サービス品質 リクエストされるプロンプトの長短はユーザ次第だが、 レスポンスするトークン量はサービサー側で上限をコントロールできる。 しかし、レスポンスが長い（≒詳しい）ほうがユーザに親切なケースが多い。

● そもそもPythonやサーバサイド推論ではない場合 ○ 汎用的な方法として、ONNXに変換する。 Optimum CLIを使えばHuggingFaceのLLMモデルをONNXやTFLiteに変換可能。 ○ llama.cppはAndroid向けにモデルを変換することも可能らしい。 ○ iOS向けならCore MLを使う。 ○ Edge AIはサーバサイド推論よりもサポートできるモデルは減るし、 メモリ容量や計算量も不足するけど、自分専用にチューニングしたモデルを スマホで動かすのはロマンがある。 その他LLMの推論で考慮すること

まとめ

まとめ ● LLMがイノベーションを加速させつつ、 LLMのおかげで新技術のキャッチアップが 容易になっているのも事実。 ● 俺達の戦いはこれからだ！

Stability AIではデータエンジニアを募集しています！ ● Senior Data Engineer https://stability.ai/careers?gh_jid=4370707101 ● Data Operations Engineer https://stability.ai/careers?gh_jid=4370789101 どちらも日本オフィスで募集中！