第7章 大規模な推論のためのモデルデプロイ
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
ビジョン言語モデル(VLM)のトレーニングが完了し、次は実際に人々に利用してもらいたいと考えているだろう。ここで推論のデプロイが重要になる。多くの開発者がここで気づくのは、「自分の環境ではモデルが動作する」ことと、「1,000人のユーザに信頼性を持ってサービスを提供できる」こととは、かけ離れているということだ。
デプロイには、2つの課題がセットになっている。第一に、最適化の課題だ。どうすれば推論を実用的なレベルまで高速かつ低コストにできるか。第二に、クラウドクラスタ、ブラウザ、エッジデバイス、あるいは特定のハードウェアなど、実行が必要な場所にモデルをパッケージ化してデプロイする課題だ。
この章では、推論の最適化、vLLMのようなサービングフレームワーク、そしてモデルをランタイム間で移植可能にしデプロイする方法といった、複数の問題に取り組む。ここで言及するライブラリのいくつかは、スイスアーミーナイフのような存在だ。モデルを独自の形式にエクスポートし、量子化し、サービングを処理してくれる。
VLMの推論最適化
VLMのトレーニングを完了し、テストを通じてその精度を確認した 。これで、本番環境への展開準備が整った。しかし、実際のユーザへのサービングを開始すると、新たな質問が生じる。なぜスループットがこれほど低いのか?
このセクションでは、その質問に答え、解決するための概念モデルと実践的なテクニックを紹介する。VLMの推論パイプラインを分解し、重要性の測定方法を学び、重みの量子化からアテンション効率性向上に至るまで、包括的な最適化手法を探求する。
テキスト専用のLLMをデプロイする場合、推論時間の大部分は、1トークンずつ生成する自己回帰的デコーディングに費やされる。VLMでは新たな要素が加わる(図7-1)。ビジョンエンコーダは各画像を1回処理するが、そこで生成された視覚トークンは生成プロセス全体を通じてコンテキストに残る(図7-2を参照)。 これら2つの要因を、順を追って見ていこう。図7-1に示すように、エンコーダからの視覚トークンは、LLMのバックボーンに入る前にテキスト埋め込みと結合される。プリフィルはすべての入力トークンを同時に処理し、デコードはキャッシュされたコンテキスト全体を考慮しながら、トークンを次々と生成する。
図7-1. VLM推論パイプライン 。
図7-2に示すように、テキストの履歴が蓄積されても、視覚トークンは変わらない。これが、VLMの会話がテキストのみのチャットよりも多くのメモリを使用する理由だ。
図7-2. 会話のターンごとのキーバリュー (KV)キャッシュメモリの内訳。
トランスフォーマーの推論には2つのフェーズがある:
- プリフィルフェーズ
-
モデルは ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access