AI の推論を強化する：高度なテクニックとベストプラクティス

リアルタイムの AI ドリブン アプリケーション、たとえば自律走行車やヘルスケア モニタリングでは、入力の処理に余分な 1 秒かかると深刻な結果を招く可能性があります。リアルタイムの AI アプリケーションでは、信頼性の高い GPU と処理能力が必要ですが、これは多くのアプリケーションにとって非常に高価でコストプロヒビティブでしたが、今ではそうではありません。

推論プロセスを最適化することで、企業は AI の効率を最大化するだけでなく、エネルギー消費と運用コストを削減することができます（最大 90%）。プライバシーとセキュリティを強化し、顧客満足度を向上させることもできます。

推論の一般的な問題

企業が AI の効率を管理する際に直面する最も一般的な問題の 1 つは、GPU クラスターの未使用、一般目的のモデルへのデフォルト、関連コストへの洞察の欠如です。

チームは、ピーク負荷のために GPU クラスターをプロビジョニングしますが、70% から 80% の時間は、ワークフローが不均一であるため未使用になります。

さらに、チームは、より小さい、より安いオープンソース モデルで実行できるタスクでも、GPT-4 や Claude などの大きな一般目的のモデル (GPT-4、Claude) を使用します。理由は、カスタム モデルの構築における知識と学習曲線の欠如です。

最後に、エンジニアは各リクエストの実際のコストに関する洞察が不足しているため、大きな請求書に直面することになります。PromptLayer や Helicone などのツールは、この洞察を提供するのに役立ちます。

モデル選択、バッチ処理、利用率に対する制御が不足している場合、推論コストは指数関数的に増加する (最大 10 倍) 可能性があり、リソースを浪費し、精度を低下させ、ユーザー エクスペリエンスを損なう可能性があります。

エネルギー消費と運用コスト

GPT-4、Llama 3 70B、または Mixtral-8x7B などの大きな LLM を実行するには、トークンあたりの電力が大幅に増加する必要があります。平均して、データセンターで使用されるエネルギーの 40% から 50% がコンピューティング機器の動作に使用され、さらに 30% から 40% が機器の冷却に使用されます。

したがって、大規模な推論を実行する会社にとっては、クラウド プロバイダーではなくオンプレミス プロバイダーを検討する方が有利です。そうすれば、プレミアム コストを避け、エネルギー消費を削減できます。

プライバシーとセキュリティ

シスコの 2025 年データ プライバシー ベンチマーク スタディ によると、「64% の回答者は、機密情報を意図せずに公開または競合他社と共有することを心配していますが、ほぼ半数は、GenAI ツールに個人情報または非公開データを入力することを認めています。」 これにより、データが不正にログまたはキャッシュされる場合、コンプライアンスのリスクが増大します。 別のリスクは、共有インフラストラクチャ上で異なる顧客組織間でモデルを実行することです。これにより、データ漏洩やパフォーマンスの問題が発生し、ユーザーのアクションが他のユーザーに影響を与える可能性があります。したがって、企業は通常、クラウドにデプロイされたサービスを好みます。

顧客満足度

応答が数秒以上かかると、ユーザーは通常、ドロップアウトします。これは、エンジニアがゼロ遅延を最適化する努力を支持しています。さらに、アプリケーションは、Gartner のプレスリリース によると、「幻覚や不正確さなどの障害が存在し、広範な影響や採用を制限する可能性があります。」

これらの問題を管理するビジネス上の利点

バッチ処理を最適化し、適切なサイズのモデル (たとえば、Llama 70B またはクローズド ソース モデルである GPT から Gemma 2B に切り替える) を選択し、GPU の使用率を改善することで、推論請求書を 60% から 80% 削減できます。vLLM などのツールを使用することも役立ちます。スパイク ワークフローでは、サーバーレス ペイ アズ ユー ゴー モデルに切り替えることもできます。

クリーンラボを例に挙げます。クリーンラボは、信頼できる言語モデル (TLM) を立ち上げました。これは、LLM の各応答に信頼性スコアを追加するように設計されています。これは、企業アプリケーションでチェックされていない幻覚を防ぐために不可欠です。Inferless の前に、クリーンラボは GPU コストの増加に直面しました。GPU は、使用されていないときでも実行され続けていました。彼らの問題は、従来のクラウド GPU プロバイダーの典型的な問題でした。高遅延、コスト管理の非効率、管理が複雑でした。サーバーレス推論を使用すると、コストを 90% 削減しながらパフォーマンス レベルを維持できました。さらに重要なのは、追加のエンジニアリング オーバーヘッド コストなしで 2 週間以内に本番環境に移行できたことです。

モデルのアーキテクチャを最適化する

GPT や Claude などの基礎モデルは、効率性や特定のタスクではなく、汎用性のためにトレーニングされています。オープンソース モデルを特定のユースケースにカスタマイズしないと、メモリとコンピューティング時間が無駄になります。

H100 などの新しい GPU チップは高速で効率的です。これらは、大規模なオペレーション (ビデオ生成や AI 関連タスク) を実行する場合に特に重要です。CUDA コアが増えると、処理速度が速くなり、小さい GPU を上回ります。NVIDIA の Tensor コア は、これらのタスクを大規模に高速化するように設計されています。

GPU メモリも、モデルのアーキテクチャを最適化する上で重要です。大きな AI モデルでは大量のメモリが必要です。この追加のメモリにより、GPU はスピードを損なうことなく大きなモデルを実行できます。逆に、VRAM が少ない小さい GPU のパフォーマンスは、データを遅いシステム RAM に移動するため低下します。

モデルのアーキテクチャを最適化することの利点は、時間とお金の節約です。まず、Dense Transformer から LoRA-optimized または FlashAttention-based バリアントに切り替えることで、応答時間を 200 から 400 ミリ秒削減できます。これは、チャットボットやゲームなどの例では重要です。さらに、4 ビットまたは 8 ビットの量子化モデルは、VRAM が少なくて済み、安い GPU でより速く実行できます。

長期的には、モデルのアーキテクチャを最適化すると、推論に費やされるお金を節約できます。最適化されたモデルは、小さいチップで実行できます。

モデルのアーキテクチャを最適化するには、次の手順が含まれます。

• 量子化 — 精度の低減 (FP32 → INT4/INT8)、メモリの節約、コンピューティング時間の高速化
• プルーニング — 不要な重みやレイヤー (構造化または非構造化) の削除
• 蒸留 — 小さい「学生」モデルをトレーニングして、大きいモデルの出力を模倣する

モデルのサイズを圧縮する

小さいモデル は、推論が速くて、インフラストラクチャのコストがかかりません。大きなモデル (13B+、70B+) では、高価な GPU (A100s、H100s)、多くの VRAM、そして多くの電力が必要です。これらを圧縮すると、より安いハードウェア (A10s または T4s) で実行でき、待ち時間が大幅に短縮されます。

圧縮されたモデルは、デバイス (電話、ブラウザ、IoT) 上での推論を実行する場合にも重要です。小さいモデルでは、インフラストラクチャをスケールアップせずに、より多くの同時リクエストを処理できます。1,000 人を超える同時ユーザーを持つチャットボットでは、13B から 7B の圧縮モデルに切り替えることで、1 つの GPU でユーザー数を 2 倍以上増やすことができました。

特殊なハードウェアを活用する

汎用 CPU はテンソル演算に最適化されていません。NVIDIA A100s、H100s、Google TPUs、または AWS Inferentia などの特殊なハードウェアは、LLM に対して推論を 10 倍から 100 倍高速化し、エネルギー効率も向上します。1 リクエストあたり 100 ミリ秒を削減するだけでも、毎日数百万のリクエストを処理する場合には大きな違いになります。

以下は仮定の例です。

チームは内部の RAG システムのために、標準の A10 GPU で LLaMA-13B を実行しています。待ち時間は約 1.9 秒で、VRAM の制限によりバッチを多く実行できません。そこで、H100 に切り替え、TensorRT-LLM を有効にし、最適化されたアテンション カーネルを有効にします。バッチ サイズを 8 から 64 に増やします。結果は、待ち時間を 400 ミリ秒に切り、スループットを 5 倍に増やすことです。
結果として、同じ予算でリクエストを 5 倍処理でき、エンジニアがインフラストラクチャのボトルネックに苦労する必要がなくなります。

デプロイ オプションの評価

さまざまなプロセスには、さまざまなインフラストラクチャが必要です。ユーザーが 10 人のチャットボットと、1 日あたり 100 万回のクエリを処理する検索エンジンには、異なるニーズがあります。クラウド (たとえば AWS Sagemaker) または DIY GPU サーバーにすべてを注ぎ込むと、コスト パフォーマンス比を評価せずに無駄な支出とユーザー エクスペリエンスの低下につながります。ただし、早期に評価し、ペイ アズ ユー ゴー構造を使用すると、将来の選択肢が得られます。

評価には、次の手順が含まれます。

• モデルの待ち時間とコストをプラットフォーム間でベンチマークします。AWS、Azure、ローカル GPU クラスター、またはサーバーレス ツールで A/B テストを実行して結果を再現します。
• コールド スタート パフォーマンスを測定します。これは、サーバーレスまたはイベント ドリブンのワークロードの場合に特に重要です。モデルはより迅速にロードされるからです。
• 可視性とスケーリングの制限を評価します。利用可能なメトリックを評価し、クエリあたりの秒数 (QPS) が低下するまでの最大クエリ数を特定します。
• コンプライアンスのサポートを確認します。地理的なデータ ルールまたは監査ログを適用できるかどうかを判断します。
• 所有コストの総額を推定します。これには、GPU 時間、ストレージ、帯域幅、およびチームのオーバーヘッドが含まれます。

結論

推論により、企業は AI のパフォーマンスを最適化し、エネルギー使用量とコストを削減し、プライバシーとセキュリティを維持し、顧客を満足させることができます。