AI ワークフローには、実際のツールと同時実行のためのリソース、およびモデルの外部でも強制可能な権限が必要です。リモート推論とローカル推論では、CPU、メモリ、ストレージ、GPU の判断が異なります。
マシンを選ぶ前にジョブを明確にする
AI ワーカーは、モデルと、タスクを受け取り、コンテキストを収集し、ツールを呼び出すソフトウェアを組み合わせたものです。スケジュールされた文書分類器、社内検索アシスタント、ブラウザ駆動のワークフローでは、運用上のニーズが異なります。入力、期待される出力、接触する可能性のあるシステム、および重要なアクションを人が承認するポイントを書き留めてください。この小さな仕様は、エージェントというラベルよりもホストについて多くを教えてくれます。
1つの反復可能なジョブと狭いアカウントから始めてください。応答の下書きを作成するワーカーは、それを送信するワーカーよりも少ない権限で済みます。アプリケーション内でこれらの段階を分離してください。サーバーは、生成されたすべての指示を実行可能な操作に変えることなく、承認されたワークフローをサポートする必要があります。完了とは、無期限に実行されるループではなく、検証済みの結果または明確な失敗状態を意味します。
リモートモデルとローカルモデルを分離する
モデルが外部 API の背後で実行される場合、VPS は主にキュー、アプリケーション、ツール、永続状態をホストします。そのメモリ需要は、ブラウザや文書パーサーを含むこれらのプロセスから生じます。このマシン上の GPU は、別の場所で実行されているモデルを高速化しません。どのコンテンツが API 境界を越えるかを記録し、ワーカーの場所とは独立してそのプロバイダーを評価してください。
ローカル推論では、モデルストレージ、モデルメモリ、ランタイム互換性が予算に追加されます。Ollama などの推論ツールは、CPU または GPU の配置と同時リクエストに関する情報を公開しています。選択したモデル、コンテキスト長、同時実行数をまとめてテストしてください。コンテキストが大きいほど、または同時ジョブが多いほど、メモリ需要が増加する可能性があります。モデルファイルのサイズだけでは不十分なサイジング方法です。GPU 構成を選択する前に、ランタイムがサポートするハードウェアを確認してください。
| ワーカーパターン | 主なリソースの問い | 確認すべき境界 |
|---|---|---|
| リモートモデル API | アプリケーションとツールのメモリ | モデルプロバイダーに送信されるコンテンツ |
| ローカルモデル | モデル、コンテキスト、作業メモリ | ランタイムとデバイスの互換性 |
| ブラウザワークフロー | ピーク時のブラウザプロセスと一時ファイル | ウェブコンテンツと許可されるアクション |
代表的なキューを測定する
通常の入力と異常に大きな入力を含む、少数のタスクセットを準備してください。ピークメモリ、処理経過時間、一時ストレージ、外部呼び出しの数を測定してください。失敗ケースも含めてください。利用できない API、不正な形式の文書、ツールのタイムアウトです。これらの測定は、お客様のソフトウェアのための計画演習であり、SwissOctet プランのベンチマークや性能保証ではありません。
アクティブなジョブの最大数と最大実行時間を設定してください。安全に開始できない作業はキューに入れ、過負荷を予測可能な方法で拒否してください。すべての失敗を即座に再試行すると、サーバー負荷と API の支出の両方が倍増する可能性があります。制限付きの再試行ポリシーと、同じ完了済みアクションが二重に適用されるのを防ぐ識別子を使用してください。ジョブがアクティブな間は、オペレーティングシステム、監視、メンテナンス用の容量を確保してください。
ツールにワーカーの野心より少ない権限を与える
モデルに提供される文書やウェブページには、モデルをリダイレクトさせることを目的とした指示が含まれている可能性があります。取得したコンテンツは、操作権限の源ではなく入力として扱ってください。プロンプトインジェクションに関する OWASP のガイダンスでは、制限されたツールや機密アクション周辺のチェックなど、複数の制御層を推奨しています。権限は、モデルが応答を通じて書き換えられないツールの実装と運用環境に置いてください。
ジョブごとに別々の認証情報を使用し、それぞれが必要とするレコードまたはディレクトリのみにアクセスできるようにしてください。モデルが生成したシェルコマンドよりも構造化パラメータを優先してください。ファイルの保存先と送信先を検証してください。メッセージの送信、変更の公開、重要なレコードの変更には、意図的な承認境界を設けてください。読み取り専用の調査ワーカーと本番管理者は、同じホスト上で実行されるという理由だけで同じ認証情報を継承すべきではありません。
リソース制御と復旧を明示的に保つ
コンテナは依存関係とプロセス境界を整理できますが、意図的な設定が必要です。Docker は、コンテナにはデフォルトでリソース制限がないことを文書化しています。適切なメモリと CPU の制限を設定し、サポートされている場合は非特権プロセスを使用し、必要なデータのみをマウントしてください。初期テストを便利にするためだけに公開するのではなく、モデルエンドポイントと管理インターフェースを制限してください。
タスク状態を一時作業ファイルとは別に永続化してください。すべてのプロンプトを永久に保存することなく、再起動後に完了した作業を認識するのに十分な情報を記録してください。認証情報をログや生成された成果物から保護してください。入力、出力、診断データの保持を定義してください。復旧テストでは、ワーカーを再起動し、未完了のジョブが安全に再開され、完了したジョブは完了のままで、失敗が運用者に見える状態であることを検証する必要があります。
最初のデプロイを受け入れテストにする
より広いアクセスを許可する前に、合成データまたは承認されたサンプルデータを使用して狭いワークフローを実行してください。有用な出力、権限、キューの動作、失敗した依存関係からの復旧を確認してください。ブラウザの子プロセスやデータダウンロードを含むプロセス全体を観察してください。モデルがローカルの場合は、コールドスタートと意図した同時リクエスト数をテストに含めてください。
通常のワーカーには Vector または Pulse を仕様の候補として使用し、推論ランタイムが適切な GPU リソースを必要とする場合にのみ Tensor を比較してください。実際の注文前に互換性と可用性を確認してください。ワーカーの動作を確認できるようになってから、その権限を拡張してください。目的は、明確な運用範囲、測定可能なリソース予算、作業を停止および復旧する簡単な方法を備えたサービスです。
実践チェックリスト。
- 1つのジョブとその承認境界を記述する。
- リモート API 処理とローカル推論を分離する。
- ツール、ブラウザ、ピーク同時実行数を測定する。
- 時間、リソース、権限の制限を適用する。
- 完了したアクションを重複させずに再起動をテストする。
重要な詳細。
すべての AI ワーカーに GPU が必要ですか？+
いいえ。リモートモデル API を呼び出すワーカーは通常、オーケストレーションとツール用のリソースを必要とします。ローカル推論には別のハードウェアとランタイム要件があります。
コンテナは自律ワークフローを安全にしますか？+
いいえ。その権限、マウント、ネットワークアクセス、リソース制限を設定し、モデル外部で重要なツールアクションを確認してください。
ワーカーをスイスでホストすれば、すべてのプロンプトがそこに留まりますか？+
いいえ。リモートモデル API やその他の連携は、コンテンツを別の場所で処理する可能性があります。それらの依存関係を明示的にマッピングしてください。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- Docker: リソース制約 docs.docker.com
- OWASP: LLM プロンプトインジェクション防止 cheatsheetseries.owasp.org
- Ollama: ランタイムと同時実行に関する FAQ docs.ollama.com
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。