デプロイして本番システムで 使うことから考えるAI 2024/06/18 Shibui Yusuke

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

● 発売中！ ● 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で自動化が難しそう & 自分が得意 & 意外とブルーオーシャンな領域を考えた結果、 非構造化データ関連に注力中。 ● 以前はMLOpsや機械学習の実用化、システム開発、バックエンド全般。 ↑ 今日はこっちの話です。

目次 ● 推論で使うための機械学習システム ● 生成AIの推論と構成 ● まとめ

推論で使うための 機械学習システム

機械学習で課題を解決するために必要なもの

機械学習システムはどこから作れば良いか悩ましい ● そもそもこの絵って生成AIでも同じなんだっけ？

● 機械学習を本番システムで使うときの大まかな構成。 システムとワークフロー 写真を撮る タイトル入力 説明入力 投稿する 機械学習 ねこ データ 評価 データ 基盤 推論 API 推論 batch 検索 評価、 アノテー ション 学習 Pipeline ML 基盤 投稿 利用

● ユーザ価値に近いところから考える。 ● 機械学習から考えない。 機械学習を実用化するときに考える順番 ユーザが常に使う投稿や 検索機能をより良くしたい。 そのためにデータ分析と 便利な推論が必要。 有効な推論のためには モデルとデータの改善が重要。 (前提：ビジネスモデルとか PMFとかIssue drivenとかUIとか)

● 実用のためには推論から考えるべきだが、開発は学習から始まることが多い。 ● 推論できないとユーザに価値を届けられないが、良いモデルを学習できないとやはり価値がない。 学習環境と推論環境 インフラ、OS ランタイム モデル 入力 前処理 推論 出力 データ取得 前処理 学習 評価 ビルド インフラ、OS ライブラリ 学習環境のみ - Jupyter Notebook - バッチ学習用のライブラリ 　（例：PyTorch、Transformers、Keras、JAX） - バッチ学習用のインフラ（ GPUとか） - データ・モデルバージョニングツール 両環境に共通 - モデルファイル - 前処理で使うライブラリ 　（例：Sklearn, PIL, Tokenizer） - 入出力のデータ型と形 推論環境のみ - 推論用のライブラリ 　（例：TorchServe, VLLM, TFLite…） - ランタイムと外部インターフェイス - ロガーとモニタリングツール

機械学習開発の課題 ● 機械学習開発はプログラミングとデータによって開発する。 ● プログラミングとデータが正しくないと機械学習のモデルも正しくなくなる。 ● しかし機械学習のモデルの正確さを開発中に評価することは難しい。 データ分析、取得 前処理 学習 評価 リリース 例：リリース後にデータが間違っていることが判明 データまで戻る

推論から考える ● 常に推論できるモデル（=本番システムで使えるモデル）を学習する。 ● 推論の優先順位 ○ まずはルールベースや統計処理で対応可否を検討する。 ○ 機械学習が必要な場合はバッチ推論（学習と同じシステム構成で可能）を検討する。 ○ バッチ推論が利用不可の場合（入力が動的に変わる）、同期推論や非同期処理を検討する。 ■ TorchServe、ONNX Runtime等を活用可能なモデルを優先して選ぶ。 ■ 推論ライブラリを使えない場合はサーバで稼働させた場合のパフォーマンスと安定性を 重点的に検証する。 ○ ユーザ端末でリアルタイム処理が必要な場合はEdge AIを検討する。 ■ 本当にリアルタイム性が必要か立ち止まって考える。 ■ Edge AIで使えるモデルは選択肢が少なく、モデルの更新リリースが難しいことを考慮する。 ● 学習の考慮事項 ○ 推論で活用可能なモデルを学習する。 ○ 学習基盤はメンバー数とモデル数に応じて徐々に導入する。一度に全部入れる必要はない。 ○ 【超重要】以下4点を疎かにしてはいけない。 ■ リーダビリティ、テスト、インターフェイス、ライブラリ管理。

同期的に推論 ロードバランサー REST API Inference server Web API server Runtime ● 最もシンプルな構成の推論器。 ● すぐリリースしたいときに有効。 ● リクエストに対して同期的に レスポンスする。 Model

非同期推論パターン Messaging/ Queue 推論器 ● 推論結果を同期的に得る必要がない場合に 有効なパターン。 ● クライアントと推論器の中間にApache Kafkaや RabbitMQのようなメッセージングを配置する ことで実現。 ● 非同期の方式はリクエスト非同期型、 Publish/Subscribe型、Notification型等がある。 ワークフローに応じて選択。 Inference server Model Runtime Queue Client バックエンド

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

Step1. オフラインで実験 ● オフラインでモデルの学習を実験する。 ● 用途例：機械学習の PoCや開発 ● 必要なスキルセット ○ 学習モデル開発、評価 ○ モデル管理 ○ GPU等のインフラ管理 実験 Laptop or Google Colab Model DB DWH レポジト リ

Step2. バッチ学習 + バッチ推論 ● 定期的に学習と推論を実行する。 ● 推論の利用が固定値かつ定期更新で良い場合に有効。 ● 学習と同じ方法で推論することが可能であるため、 インフラやコードを学習と推論で共有できる。 ● 用途例：需要予測、推薦等。 ○ テーブルデータで使うことが多く、逆に画像や テキストデータだと有効でないことが多い。 ● 必要なスキルセット ○ 学習基盤と学習パイプライン ○ 推論結果をDBに保存 ○ 最低限のモニタリング ● あると便利なスキルセット ○ BI ○ ドリフト検知 DB バッチ 学習 ML基盤 バッチ 推論 Model DB CI/ CD DWH レポジト リ 実験 環境 ここを変更するの は簡単。 推論結果を出力す るテーブルはしっ かり設計したほう が良い。

Step3. バッチ学習 + 同期推論 or 非同期推論 ● 定期的に学習したモデルを推論器としてデプロイ。 ● リクエストに応じて推論する用途で有効。 ● 学習と推論で異なるコード、ライブラリ、インフラ、 ライフサイクルが必要になる。 ● 用途例：推薦、検索、違反検知、異常検知。 ○ 多様な用途で利用可能だが、ワークフローが 複雑になると開発運用が難しくなる。 ● 必要なスキルセット ○ 学習基盤と学習パイプライン ○ Web APIや非同期処理 ○ 推論器のビルドとCI/CD ● あると便利なスキルセット ○ BI ○ ドリフト検知 ○ API開発と運用 実験 環境 バッチ 学習 ML基盤 CI/ CD DWH ビルド 推論 API 運用 管理 CI/ CD レポジト リ インターフェイスと パフォーマンスが 重要。 ビルドとCIがボト ルネックになるこ とも多い。 推論モデルを目 標に設計する。 Model DB

Step4. バッチ学習 + 同期推論 or 非同期推論 + A/Bテスト ● リクエストグループに応じて推論する APIを分散する。 ● 本番システムで複数の推論モデルを比較する場合に有効。 ● 学習と推論で異なるコード、ライブラリ、インフラ、 ライフサイクルが必要になる。 ● 学習と推論リリースは比較対象との優位性によって判定する。 ● 用途例：Webやアプリ等、ユーザ次第で有効なアルゴリズムが 変動する用途。 ○ A/Bグループとモデルの対応次第では 複雑なライフサイクルが必要になる。 ● 必要なスキルセット ○ 学習基盤と学習パイプライン ○ Web APIや非同期処理 ○ 推論器のビルドとCI/CD ○ A/Bの分割と学習、推論のライフサイクル管理 ● あると便利なスキルセット ○ BI ○ ドリフト検知 ○ API開発と運用 実験 環境 バッチ 学習 ML基盤 CI/ CD DWH 推論 API 管理/ 監視 CI/ CD レポジト リ A/B proxy 推論 API リリースを制 御する。 振り分けルールと バックアッププランが 鍵。 ビルド Model DB

● 推論が許容範囲内で正しい ● ソフトウェアのエラー率 ● レイテンシーと耐障害性 ● リソース利用量とコスト 「推論が正しく動いている」 Client LB LB 時間 RAM CPU group A CTR group B 時間 req/sec 時間 nodes 時間 error rate レイテンシー（ms） 時間

アンチパターン：Nobody knowsパターン LB API API ML DB DB API ML? ● 稼働中の推論器がなぜ動いているのか 誰も知らないパターン。 歴史的にシステムが複雑になっていくと 頻繁に発生する。 ● プロジェクトの初期にプロトタイプで作った モデルや、緊急対応で稼働させた推論器を 残しておくと「Nobody knows」になる。 ● 学習データが残っていない状態は珍しくない。 学習コードもJupyter Notebookのみの場合、 モデルの評価や再現が困難。 ● ドキュメントを書く。 システムにわかりやすい名称を付ける。 （Professor-XとかVegetarianとか、 　意味がわからない名前をつけない！！！） ML? API

ここまでのまとめ ● ユーザに価値を届けることを念頭に機械学習プロジェクトに望む。 ● ソフトウェアも機械学習も、おそらく永遠に完璧なものは作れないが、 それは改善することを諦める理由にはならない。 ● 安定運用するシステムを作るためにはビジネスプランや開発と同じくらい、 設計とドキュメンテーションが大事。

生成AIの推論と構成

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

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

第一候補：APIで公開されているLLMを使う ● 使い方 ○ 選択肢1. サービスが公開しているUIやAPI、ライブラリを使う。 ○ 選択肢2. Langchain等の統合ライブラリを使う。 ● インターフェイス：最近のAPIやライブラリはOpenAI GPTのインターフェイスを 真似ているものが多いため、抽象化しやすい。 ● 個人的な工夫：JSON modeやFunction Callingを使って構造化されたJSONで リクエスト、レスポンスすると開発が楽（不確定な自然言語処理が減る）。 ● 注意点 ○ インフラはまだまだ不安定。障害、パフォーマンス劣化は頻繁に発生。 ○ 課金はリクエストよりレスポンスのプロンプトのほうが高い。 長文をレスポンスさせるのは得策ではない。 ○ Moderationが厳しい。

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

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

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

技術選定 ● 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

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。

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の学習、推論を高速化するライブラリ。 ● 推論の高速化：並列処理（Tensor Parallel）、Deep fusion、Mixture of Quantization等。 ● 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

DeepSpeed ● DeepSpeed-FastGenで用いられている手法の概要。 ● Blocked KV-Cache：KV-Cacheのメモリフラグメンテーションを回避。 ● Continuous batchingの有効化 ○ Static batching：リクエストがきたら推論する。バッチサイズはクライアントがコントロール。 ○ Dynamic batching：リクエストをキューに貯めて、一定量に達した or 一定時間経過した場合に推論する。 リクエストをバッチにまとめることで効率化する。 すべてのリクエストで生成する文章量が同じくらいなら速いが、 1リクエストだけ長文生成だと他のリクエストも その長文の生成を待つことになる。 ○ Continuous batching：1トークンの生成ごとにバッチを作りなおすことで、すでに推論が終わったリクエストはバッチから削除し、 新しいリクエストをバッチを割り当てる。 ● Dynamic SplitFuse ○ プロンプトを一定サイズに分割・充足することで推論時間を一定に保つ。 Dynamic batching Continuous batching

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

その他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の推論で考慮すること

まとめ

毎年数回イノベーションが発生する世界 Machine learning Deep learning Generative AI Platform 2011 2012 2013 2023 2022 2021 2020 2014 2015 2016 2017 2019 2018 BigQuery dbt Kubeflow AlexNet DCGAN TensorFlow DQN AlphaGo AlphaZero XGBoost LightGBM ONNX PyTorch Anaconda GoogleNet ResNet Kaggle SageMaker Keras Core ML MediaPipe TensorRT Nvidia K80 Jupyter Notebook Google Colab Word2Vec Vertex AI MLflow Spark CLIP BERT GPT-3 OpenAI Hidden debt paper Diffusion model HuggingFace AutoML Optuna Katib ChatGPT Snowflake Airflow Cycle GAN Style GAN Magenta VAE CatBoost Flax TFServing TorchServe Stable Diffusion Nvidia A100 TPU Transformer イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション イノベーション CodeX BQML 2024 Llama LoRA DeepSpeed GPT4 Gemini Nvidia H100 AnimateDiff イノベーション Copilot

まとめ ● 新しい技術は多々あるが、DevOpsの観点から技術選定と設計することは変わらない。 ● LLMがイノベーションを加速させつつ、 LLMのおかげで新技術のキャッチアップが 容易になっているのも事実。 ● 俺達の戦いはこれからだ！

● 7/24（水）15:10-15:40で登壇します！ ● セッション名 『生成AIの研究開発を事業につなげるデータ、仕組み、コミュニケーション』 ● https://event.shoeisha.jp/devsumi/20240723/session/5126 ● ぜひご参加ください！

PROPRIETARY & CONFIDENTIAL 55 Twitter Stability AI (日本語): @StabilityAI_JP Stability AI (global): @StabilityAI ja.stability.ai stablevideo.com stableaudio.com sales-jp@stability.ai https://stability.ai/stable-artisan