Ollamaのプレリリース版、検証済みモデルを再利用　埋め込みのウォームリクエストで遅延が4割超低下

Ollamaは10月12日、推論ルーティングにおけるモデル検索方法を変更するPR #18947をマージし、同日リリースしたv0.40.4-rc0に変更を取り込みました。この最適化はgenerate、chat、embed、System Oneを対象とし、モデルのロード後もリクエストごとに繰り返していた検索処理を減らすことを目的としています。現時点では、引き続きプレリリース版として位置付けられています。リリースノート

新しい処理では、名前付きモデルのmanifest解析と実行バックエンドの選択を、検証済みの単一のコールド検索にまとめています。実行プロセスがすでに存在する場合は、v2タグが引き続き同じダイジェストを指していることを確認してから、モデルオブジェクトを再利用します。パーサーの選択はリクエストごとに行い、モデル共有時に設定が変更されないようにしています。提案には、タグ変更、バックエンド選択、並行アンロード、モデル不在に関する回帰テストも含まれています。技術提案

メンテナーが公開した、同じモデルへの後続ウォームリクエストのテストでは、EmbeddingGemma 2のMLX埋め込み応答は17.0ミリ秒から7.52ミリ秒に、nomic-embed-textのGGUF応答は13.8ミリ秒から8.11ミリ秒に短縮しました。キャッシュ済みチャットのケースでは、最初のトークンまでの遅延の低下は約4.8%にとどまりました。効果はワークロードによって異なるため、すべてのモデルで同程度に高速化すると推定することはできません。テストデータ

RAGエンジニアにとって、この種の固定オーバーヘッドは測定する価値があります。同じモデルを頻繁に呼び出して短いテキストをベクトル化する場合、モデル検索時間が遅延に占める割合が高くなる可能性があります。これは変更の仕組みに基づく技術的な推論です。公式の/api/embedは、単一のテキストとテキスト配列に対応し、keep_aliveも提供しています。そのため、バージョンを比較する際は、バッチサイズとモデルの常駐条件を揃える必要があります。埋め込みAPIドキュメント

公開テストだけでは、コールドスタート、長い入力、高並行性のサービスを代表するには不十分です。デプロイチームはクライアント側の遅延に加えて、APIのtotal_duration、load_duration、入力トークン数を同時に記録し、効果がロード関連のオーバーヘッドによるものかを確認できます。公式の時間フィールドはナノ秒単位です。今後は、正式版への採用状況に加え、モデルタグの更新、バックエンドの切り替え、並行アンロード時の実際の挙動を確認する必要があります。パフォーマンスフィールドの説明