LocalAI 4.10、クラスター操作とプライベートソースのダウンロード認証情報を統一し、エンドツーエンドのベンチマークを追加

LocalAIは9月17日に4.10.0をリリースし、セルフホスト型推論サービスの管理単位をクラスター全体へと拡張した。新版はノードの健全性、リソース容量、モデルレプリカの配置、一括操作を統合し、プライベートソース用の認証情報ファイルとコマンドラインのベンチマークツールを追加した。複数のワーカーノードを維持管理するチームにとって、より直接的な意義のある更新だ。[リリース告知](https://github.com/mudler/LocalAI/releases/tag/v4.10.0)

クラスターダッシュボードは、GPUメモリ、メモリ、プロセッサー、ディスクの状態を集約し、各モデルが配置されているノードや処理中のリクエストも表示する。ドレイン、復帰、削除の一括処理では、最大8件の操作を同時に実行できる。ノードをドレインする際は、状態変更とモデルレコードの削除を同一トランザクションで処理し、並行更新によって管理データに不整合が生じるリスクを抑える。今回のインターフェース更新は、実際のライフサイクル管理にも踏み込んでいる。[クラスター関連の変更](https://github.com/mudler/LocalAI/releases/tag/v4.10.0)

プライベートモデルの配信では、認証情報ファイルでURLプレフィックスに応じた認証方式を指定する仕組みに変更された。コンテナレジストリ、社内ダウンロードサイト、プライベートリポジトリに対応する。シークレットの値は使用時に読み取られるため、マウントされたKubernetes Secretをローテーションすると、その変更がそのまま反映される。リダイレクトも各ホップで検証され、一致する設定がないCDNには元のサイトの認証情報が送信されない。これにより、モデルカタログとダウンロード権限を個別に管理できる。[プライベートソースのドキュメント](https://localai.io/docs/advanced/private-sources/index.html)

分散デプロイには、引き続き運用上の境界がある。モデルのダウンロードはコントローラーが担当する一方、バックエンドイメージは各ワーカーノードが自ら取得する。このため、コントローラーに認証情報を設定するだけではプライベートバックエンドをインストールできず、ワーカーノードにも対応する設定が必要になる。LocalAIはこれらのシークレットをNATS経由で送信しない。エンジニアリングチームはアップグレード時に、認証情報の配置とローテーションの対象範囲も併せて確認すべきだ。[分散環境の認証情報ルール](https://localai.io/docs/advanced/private-sources/index.html)

新たに追加された`local-ai benchmark`は、非ストリーミングのリクエストを逐次送信し、リクエスト全体の所要時間と報告された生成トークン数からスループットを算出する。JSON形式で出力し、回帰比較に組み込むこともできる。測定時間には通信、キューでの待機、プロンプト処理、生成が含まれるが、最初のトークンが出力されるまでの遅延は測定せず、多数の同時リクエストを処理するサービスの容量も示さない。ウォームアップ後に同じプロンプトを繰り返すと、キャッシュの影響を受ける可能性もある。[ベンチマークの測定方法](https://localai.io/docs/features/benchmark/index.html)

導入評価の観点では、今回の更新により、運用状況の把握と測定のための手段が充実した。単発のベンチマーク結果を本番環境のキャパシティプランニングに結び付けるには、ハードウェア、量子化設定、コンテキスト、バックグラウンド負荷を固定し、並行リクエストやノードのドレイン中の挙動を別途測定する必要がある。特に、リソースのテレメトリーに欠落がある場合、ダッシュボードの容量情報が運用判断にどう影響するかを確認すべきだ。