全体のフットプリントを見積もる
重み、量子化、コンテキスト長、キャッシュ、同時リクエストはすべてメモリに影響します。オペレーティングシステムとランタイム用の余裕を確保してください。CPU 推論と GPU 推論ではコストとスループットの特性が異なります。標準の VPS は GPU アクセスを意味するものではありません。
モデル API を非公開に保つ
Ollamaなどのランタイムは、適切なセキュリティ層なしにインターネットへ公開すべきではありません。可能な場合はループバックまたはプライベートインターフェースにバインドし、リモート経路の前段に認証付きの TLS アクセスを配置してください。
出所を確認してダウンロード
モデルのライセンス、ソース、提供されている場合はチェックサム、および意図された用途を確認してください。信頼できないモデル形式や周辺のローダーコードは攻撃対象領域を拡大する可能性があります。ランタイムと依存関係を保守してください。
実際のリクエストをベンチマークする
アプリケーションが使用するコンテキストサイズで、最初のトークンのレイテンシ、毎秒トークン数、メモリ負荷、同時実行時の動作を測定してください。リクエストサイズ制限、キューイング、タイムアウトを追加して、1 つの大きなプロンプトがマシンを枯渇させないようにしてください。
API が公開されていないことを確認する
ローカルのOllama APIアクセスには認証が不要です。ご自身のアプリケーションのみが呼び出す場合は、リスナーをループバックに保ってください。リモートで使用する場合は、認証付きのTLSゲートウェイ、またはリクエスト数と同時実行数の制限を備えたプライベートトンネルを追加してください。クラウドのAPI認証情報は、ローカルリスナーを自動的に保護するものではありません。アクセス権のないデバイスからテストし、拒否されることを確認してください。
- リッスンアドレスを確認する
- 許可されたネットワーク外から未認証のリクエストを試す
- コンテキストサイズと同時生成に制限を適用する
ss -lntp
curl --fail http://127.0.0.1:11434/api/tags公式ドキュメント: Ollama認証モデル
小さなベンチマークノートを保管する
正確なモデルバリアント、量子化、コンテキスト長、プロンプト、並列リクエスト数を記録してください。実行時のメモリを測定し、モデルのダウンロードサイズと等しいと仮定しないでください。設定変更後は同じリクエストを繰り返し、速度測定だけでなく品質チェックも保持してください。ジョブが激しくスワップしたり、メインアプリケーションを圧迫したりする場合は、同時実行数を減らすか、より適したマシンを使用してください。
コンテキストを増やす前にモデルのメモリを検討してください
パラメータ数に量子化ビット数を掛けて8で割った値を、重みのみの概算バイト数として使用し、そこにランタイム、コンテキスト/KVキャッシュ、同時実行数、オペレーティングシステムの余裕分を加えてください。これは容量の保証ではありません。Ollamaでは、並列リクエストとより大きなコンテキストがメモリ使用量を増やし、キューに入った処理が一見正常なサービスを遅くする可能性があります。まず1つのモデルと1つのリクエストから始め、ピークメモリを記録し、ワークロードがレイテンシ目標を満たしてから同時実行数を増やしてください。
- すべてのベンチマークでモデルタグ、ランタイムバージョン、量子化、プロンプト長、出力制限を記録してください。
- コールドスタートの読み込みとウォームリクエストのパフォーマンスを分けて扱ってください。これらは異なるサイジングの問いに答えるものです。
- ホストがスワップするかプロセスが強制終了される場合は、CPU コアを購入する前に、同時実行数/コンテキストを下げ、メモリイベントを確認してください。
- 最初のリクエストは高速だが以降のリクエストが停滞する場合は、読み込まれたモデルとキャッシュの増加を確認してください。
# Inspect the model runner and host without changing its configuration.
ollama ps
free -h
df -h公式ドキュメント: Ollama: メモリ、同時実行、ネットワーク設定
埋め込みを独立したワークロードとしてテストする
埋め込みモデルは入力テキストを検索用のベクトルに変換するものであり、長い生成回答とは同じリソースプロファイルではありません。インデックス作成時とクエリ時には、同じモデルと前処理戦略を一貫して使用してください。Ollama の embed エンドポイントはテキストまたはバッチを受け付け、truncate が false の場合は長すぎる入力を拒否することがあります。不都合な境界でドキュメントが暗黙に切り捨てられないよう、意図的なチャンク分割ポリシーを選択してください。
- インデックス作成バッチと対話型クエリを別々にベンチマークし、ストレージとベクトルデータベースのコストも含めて評価してください。
- モデル名と埋め込み次元数をインデックスとともに保持してください。これらを変更するには、通常、意図的な再インデックス計画が必要です。
- 小規模な検索評価セットを使用してください: 既知の質問、期待されるドキュメント、関連する結果を返すべきでないケース。
- プロンプト、インデックスされたドキュメント、アクセスログを、それぞれ独自のアクセスおよび削除ルールを持つ別々のデータストアとして扱ってください。
公式ドキュメント: Ollama: 埋め込みAPI