生成AIデザインパターン

第8章. 制約に対処する

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

本番環境にLLMをデプロイする LLMは、単にモデルを動作させるだけでは済まない、ユニークなチャレンジのセットを提示する。LLMは驚くべき機能を提供する一方で、かなりのコンピューティングリソースを必要とし、遅延の懸念が生じ、規模が大きくなるとすぐにコスト高になる可能性がある。単一のクエリで動作する概念実証と、数千のユーザにサービスを提供する本番システムとの間のギャップは、しばしば見落とされがちである。

この章では、LLMを本番システムにデプロイする際に直面しそうな懸念に対処するパターンを提供する。ハードウェアの制限、予算の制約、厳しい遅延要件など、ここで紹介するパターンは、LLMデプロイを最適化するための実証済みの戦略を提供する。

生産制約のさまざまな側面に取り組む5つの主要なパターンを探る。小さな言語モデル（パターン24）のセクションでは、モデルの蒸留と量子化テクニックによって計算オーバーヘッドを削減する方法を示す。プロンプト・キャッシングのセクション（パターン25）では、冗長性を排除し、コストと遅延の両方を削減する方法を示す。推論の最適化」（パターン26）では、連続バッチ処理や投機的デコードなどの高度なテクニックを取り上げ、ハードウェアの利用率を最大化する。劣化テストのセクション（パターン27）では、LLMベースのアプリケーションが良好なパフォーマンスであることを検証するために必要なメトリックを提供し、また、パフォーマンスのある側面で不足している場合に取ることができる対処法についても説明している。最後に、Long-Term Memory (パターン28)のセクションは、セッション間のユーザ履歴を保持し、パーソナライゼーションのためにユーザのリクエストを記憶するのに役立つ。

まとめてデプロイすることで、この章のパターンは、リソース集約的なLLMデプロイを効率的でスケーラブルな本番システムにトランスフォーメーションするための包括的なツールキットを形成する。

パターン24：スモール言語モデル

Small Language Model (SLM)パターン は、品質を過度に損なうことなく、コストと遅延の制約にうまく適合するような小さなモデルを使うことを可能にするテクニックのセットである。知識蒸留は知識範囲を狭めることでモデルのサイズを小さくし、量子化はモデル・パラメータの精度を下げることでメモリ消費を少なくし、投機的デコーディングは小さなモデルを使ってトークンを生成し、大きなモデルを使ってそれをバックアップする。

問題点

自分のハードウェアでフロンティアLLMを実行するには、 、最新鋭のグラフィック・プロセッシング・ユニット（GPU）と仮想マシン（VM）が必要で、それには大量のメモリが必要となる。インフラがハイパースケーラー（AWS、Azure、GCP、OCIなど）上にある場合、これらの要件には高額なクラウド料金と希少性が伴う-本稿執筆時点で、ハイパースケーラーは日常的に必要なハードウェアリソースを使い果たしている。もしあなたがプロバイダーのAPI経由でフロンティアLLMを呼び出すなら、マシンを操作する必要はないが、コストと可用性の問題はなくならない。

簡単にするために、このセクションではローカルで実行していると仮定する。しかし、この解決策は、完全に管理されたリモート版の基盤モデルだけを使用している場合にも適用できる。アプリケーションへのコストと可用性の影響を減らすために、類似性のあるホスト版のSLMに変更することもできる。 ...