共有ホームAIサービスでリクエストごとのコスト上限を可能にする機能とは？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Features Enable Per-Request Cost Limits in a Shared Home AI Service?

リクエスト単位のコスト制限は、ゲートウェイがポリシーをトークン、時間、メモリ、ツール、再試行、キュー待ちの処理に対する強制可能な予算へ変換すると機能します。

家族の誰かによる単純な検索が、共有ホームサーバー上で長いモデル応答、3回の検索処理、OCR、複数のエージェントツールを予期せず引き起こすことがあります。ローカル推論にはトークン単位のクラウド請求はありませんが、限られたアクセラレーター時間、電力、RAM、対話処理能力を消費します。サービスには事前見積もり、実行中の使用量の記録、キャンセルポイント、いずれかの予算を使い切った場合の明確な動作が必要です。

受付時の見積もりで上限付きのリソース枠を確保する

実行前に、ゲートウェイは入力トークン数、最大出力、モデルクラス、KVキャッシュのメモリ、検索の深さ、ツール数、期限を見積もります。ユーザー、エンドポイント、ワークフローの各ポリシーを組み合わせて、1つの変更不可能なリクエスト予算にします。下流サービスがこの予算を密かに増やすことはできません。

反復単位のスケジューリングは、生成を反復単位でスケジュールし、長さの異なるリクエストを動的にバッチ処理します。この設計は、実際のデコード処理量が初期プロンプトの時点で完全に把握できるのではなく、トークンごとに明らかになる理由を示しています。この違いは、後の家庭環境でのテストでも確認できます。

したがって、見積もりでは上限を確保しつつ、すべてのリクエストにその上限まで到達したものとして課金すべきではありません。大規模でもリスクの低いバックグラウンドジョブはキューに入れる一方、最悪時のメモリ使用量が既存の予約枠を破る場合、対話処理は早期に拒否できます。

実行時メーターでトークン、時間、メモリ、ツールを制御する

すべてのサービスは、リクエストIDに対して標準化された使用量を報告します。対象には、プロンプトと生成トークン、GPUミリ秒、ピークメモリ、CPU時間、読み取りバイト数、ツール呼び出し、再試行、外部操作が含まれます。中央の台帳は使用量をアトミックに差し引くため、並列ブランチがそれぞれ残りの予算を全額使うことはありません。

チャンク化プリフィルスケジューリングは、スループットとデコード遅延のバランスを取るため、チャンク化プリフィルと停止のないスケジューリングを研究しています。これは、処理を強制可能な単位に分割しない限り、1つの長いプロンプトがサービス容量を断続的に消費し得ることを示しています。自動化が次の処理に進む前に、中間結果を検査できる状態にしておく必要があります。

ツール予算には、単なる呼び出し回数ではなく、意味に基づくカテゴリが必要です。読み取り専用のメタデータ呼び出し10回と、1回のメッセージ送信や再帰的なファイルスキャンは異なるため、ポリシーでは副作用の種類、対象範囲、出力バイト数、累積実行時間を個別に制限できます。

キャンセルと部分結果で予算の境界を定義する

協調的なキャンセルは検索、生成、ツール処理全体に伝播し、各段階は高コストな処理を開始する前に期限または残りの予算を確認します。冪等性キーにより、キャンセルされた再試行が外部副作用を繰り返すのを防ぎます。この境界は、現実的な運用条件の下で個別に測定すべきです。

公平なGPUスケジューリングは、アクセラレーターのサイクルを時間共有してリクエストの飢餓を防ぎ、推論コンテキストを移動するコストを検証します。この研究は、公平性の制御では計算時間とメモリ状態の両方を考慮する必要があることを示しています。限られたコンテキストを複数のソースが奪い合うと、その実際の影響が現れます。

失敗の境界となるのは、強制を伴わない使用量の記録です。ダッシュボードが超過を報告していても、1つのリクエストがGPUを独占し続ける可能性があります。制限に達したら、安全なチェックポイントでシステムを停止し、明示的な部分結果を返し、予算枯渇とモデルまたはツールの失敗を区別しなければなりません。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

敵対的なリクエスト形状で予算をテストする

巨大な入力、出力が無制限になるプロンプト、再帰的なツール計画、並列ブランチ、再試行ループ、低速なツール、キャッシュミス、副作用の実行中のキャンセルを含むリクエストを作成します。2人のユーザーと1つのバックグラウンドサービスに、それぞれ異なる予算を割り当てます。この依存関係は、最終インターフェースでも明示したままにしてください。

ユーザー単位のリソースポリシーにあるユーザー別QoSの境界を使い、予約トークン数と実際のトークン数、GPU時間、ピークメモリ、キュー待ち時間、ツール操作、再試行回数、キャンセル遅延、部分結果の品質を記録します。子スパンが親の予算をリセットせず、継承していることを確認します。

すべての高コストなアクションが帰属され、文書化されたクリーンアップ処理を除いて、ハードリミットを超えるリクエストがない場合にのみ合格とします。正確な見積もりが不可能なら、保守的に受付を行い、未使用の容量を返還してください。下流サービスに新しい予算を勝手に作らせてはなりません。