AIP の LLM 容量管理

LLM 容量は業界レベルで限られたリソースであり、すべてのプロバイダー（Azure、OpenAI、AWS Bedrock、Google Cloud Vertex など）はアカウントごとに利用可能な最大容量を制限しています。そのため、Palantir AIP も LLM プロバイダーによって設定された市場レベルの制約に従います。業界全体で標準的な測定単位は、1 分あたりのトークン数（TPM）および1 分あたりのリクエスト数（RPM）です。

エンロールメント容量とレート制限

Palantir は各エンロールメントに対して一定の最大容量を設定しており、これを「エンロールメントレベルのレート制限」と呼びます。この容量は TPM および RPM を使用してモデルごとに測定され、GPT、Claude、Gemini、Llama、Mixtral など、ユーザーのエンロールメントで有効になっているすべてのプロバイダーのすべてのモデルを含みます。このようにして、各モデルは他のモデルの使用に影響されない独立した容量を持ちます。

デフォルトでは、すべての顧客は中程度の層にあり、これは数百人のユーザーや大規模なデータセット（たとえば数百万のドキュメントを含む）でプロトタイプを構築し、いくつかのユースケースにスケールアップするのに十分な大きさです。

さらに、AIP では、追加の容量が必要な場合に、中程度の層から大規模または XL 層にエンロールメント容量をアップグレードするオプションを提供しています。エンロールメントレート制限に頻繁に達し、AIP の使用を拡大できない場合、またはパイプラインのボリュームやユーザー数が増加することが予想される場合は、Palantir サポートに連絡してください。

エンロールメント制限は、Resource Management アプリケーションの AIP レート制限 タブにエンロールメント層とともに表示されます。

AIP は、特に XL 層でエンロールメント層を使用して非常に大規模なワークフローを構築するのに十分な容量を提供します。これらの層は、LLM を大規模に使用する数百の Palantir 顧客に十分な容量を提供しており、これらの制限を引き続き増加させています。

プロジェクトレート制限

エンロールメント管理者は、Resource Management アプリケーションの AIP レート制限 ページに移動して、特定のプロジェクト内のすべてのリソースが毎分利用できる TPM および RPM の最大パーセントをモデルごとに設定できます。

これは、AIP における野心的なユースケースのために生産用途に LLM の利用を最大化し、実験的なプロジェクトがエンロールメント全体の容量を占有するのを制限または禁止する柔軟性を提供します。

デフォルトでは、すべてのプロジェクトに特定の制限が与えられます。管理者は追加のプロジェクト制限を作成し、各制限に含まれるプロジェクトを定義し、使用できるエンロールメント容量のパーセントを設定できます。

インタラクティブクエリの優先順位付け

一般的に、AIP はバッチリクエストを含むパイプラインよりもインタラクティブリクエストを優先します。インタラクティブクエリとは、AIP Assist、Workshop、Agent Studio、AIP Logic LLM ボードのプレビュー、および Pipeline Builder LLM ノードのプレビューなど、ユーザーが LLM とリアルタイムでやり取りする任意のインタラクションを指します。バッチクエリは、ユーザーが即時の応答を期待せずに送信する大量のリクエストセットを指し、たとえば Transforms パイプライン、Pipeline Builder、Automate（Logic 用）などです。

この原則は、エンロールメントおよびプロジェクトレベルで容量の 20% が常にインタラクティブクエリのために予約されることを保証します。つまり、特定のモデルに対する 100,000 TPM の容量の場合、任意の時点で最大 80,000 TPM がパイプラインに使用される一方で、少なくとも 20,000 TPM（および最大 100,000 TPM）はインタラクティブクエリのために利用可能です。

FAQ

プロジェクトレベルのレート制限がどのように使用されることが期待されているかの例は？

次の例を考えてみます：

• エンロールメントには本番環境での単一の AIP ユースケースしかないため、そのユースケースを含むプロジェクトは「Production」制限に移動され、エンロールメント制限の最大 100% にアクセスできるようになります。
• この本番ユースケースに加えて、検証段階の第 2 のユースケースも考慮する必要があります。この検証段階のユースケースは、本番使用全体を占有することなくテストを実行できるべきです。このユースケースは容量の最大 30% を持つ「Testing」制限に追加できます。「Production」制限は、常にテストのための容量が確保されるように 90% に減少されます。
• 先に述べたユースケースに加えて、2 番目の本番ユースケースを追加します。ただし、最初のユースケースが GPT4o を使用したのとは異なり、これは Claude 3.5 Sonnet を使用します。この新しいユースケースを最初の本番ユースケースの隣に「Production」制限に安全に追加できます。
• 同じエンロールメントでユーザーが LLM を実験できるようにしたいと考えています。エンロールメント管理者は 2 つのプロジェクトを容量の最大 20% を持つ「Experimentation」制限に追加します。
• 検証プロジェクトと 2 つの実験プロジェクトは、技術的には合計で容量の最大 70% を消費できますが、履歴データによると実際の使用量は通常これを下回ります。
• 最後に、このエンロールメントは複数のユーザーが LLM を実験できるようにしたいと考えています。エンロールメント管理者はデフォルトの制限を容量の 10% に設定し、ユーザーフォルダーを容量の 0% に設定し、これらの指定されたユーザーに Control Panel AIP 設定で LLM ビルダーの権限を付与できます。

なぜ制限カテゴリー内の各プロジェクトにパーセントが強制され、プロジェクト間で共有されないのですか？

• 複数のプロジェクトとリソースが同じ 100% の容量を共有できる理由は、過去 1 年間にわたる数百の顧客の LLM 使用パターンに基づくと、ほとんどのプロジェクトとリソースは LLM へのコールを行わないためです。このため、複数のリソースが同じ 100% の容量を共有できます。
• 制限カテゴリー内のすべてのプロジェクトが同じ使用率を共有する場合、使用には厳しい制限が課されますが、既存の使用に基づくと、これは 99% のケースでは正当化されません。複数のリソースが同じ時点で最大容量を使用することは非常にまれであり、これが発生した場合でも、リクエストは成功するまで再試行されます。

なぜ AIP の使用制限があるのですか？

• まず、TPM、RPM、および地域の可用性に関して、さまざまなプロバイダーの提供に大きなばらつきがあります。AIP はすべてのプロバイダーの容量を利用しますが、Palantir はさまざまなクラウドサービスプロバイダーによって課された制限を回避することはできません。
• さらに、Palantir が顧客に提供する LLM 容量には、ほとんどのプロバイダーの一般的な提供と比較して高い準拠要件があります。Palantir はゼロデータ保持（ZDR）と特定の地域へのデータルーティングの制御（地域制限）を保証します。
• Direct OpenAI はまだ AIP の地域制限をサポートしていません。たとえば、OpenAI はリクエストが EU にルーティングされ、EU 内に留まることを保証できません。リクエストは、アメリカ、アジア、アフリカ、またはヨーロッパのデータセンターで処理される可能性があり、OpenAI ははるかに柔軟で大規模な容量プールを利用できます。
  • 地域制限がない AIP 顧客は、この大規模な容量プールを使用できます。使用量が多いユーザー向けに XL 層へのアップグレードが利用可能です。
  • バッチ API などの特定の機能はまだ利用できません。バッチ API は 24 時間以内に数十億のトークンを処理できますが、その期間データを保存する必要があり、Palantir の準拠要件に違反します。
• 他のプロバイダー、すなわち Azure OpenAI、AWS Bedrock、GCP Vertex、および Palantir ホストの Llama および Mixtral モデルはすべて地域制限をサポートしていますが、地域制限されたリクエストのための LLM 容量保証ははるかに小さいです。
  • 特定の地域で容量を確保するのは難しく、しばしば事前に確保されたスループットを確保する必要があります。これは、Palantir が顧客のために行う毎月の前払い容量保証です。これはプロバイダー側でも制限されることがよくあります。
  • 特定のモデルは特定の地域ではまだ広く利用できませんが、Palantir はそれらへの早期アクセスを持っています。これはたとえば英国の GPT モデルの場合です。
• 上記のように、中から XL 層は大規模な生産ワークフローに十分です。層を変更するには Palantir サポートに連絡してください。

なぜ生産ユースケースのために最小保証容量を予約することができないのですか？

• これは現在開発中であり、2 つの別々の障害が含まれます。1 つ目は使用を解除するための最大容量を解決することであり、2 つ目は生産ユースケースの成功を保証するための最小予約容量を解決することです。
• さらに、スケールの代替手段として bring-your-own-model（およびアカウント）オプションを有効にするために取り組んでいます。詳細については Palantir サポートに連絡してください。

容量問題を解決する上での最大の障害は何ですか？

• 地域制限が容量問題の最も強い原因です。エンロールメントが地域制限されており、法的観点から地域制限を解除できる場合は、Palantir チームと協力してこれを行ってください。
• 新しいモデルは初期段階で容量が限られていることがよくあります。たとえば、GPT4-vision、GPT-o1、および Claude 3.5 Sonnet が最初に発売されたときの例です。
• 容量問題は、多くの数百万のアイテムを処理する大規模なパイプラインではるかに困難です。