LiteLLMの新しいリリース候補 v1.83.7.rc.1 が出た。個人開発でLLMのAPIコストを抑えるためにLiteLLMを使い始めて数ヶ月、リリースノートを流し読みするのが週次の習慣になってきた。
今回のリリース、正直パッとした新機能はない。でも地味に刺さる変更がいくつかあって、自分のプロジェクトに引きつけると無視できない内容だった。
いちばん気になったのがBreaking Changesに書いてあったPrometheusまわりの変更だ。デフォルトの LATENCY_BUCKETS が35から18境界に削減された。自分はSLOの死活監視にPrometheusを使っていて、 le="1.5" みたいな特定のレイテンシ値でPromQLを書いている箇所がある。このバケット縮小によって該当のシリーズが消えるので、既存のダッシュボードやアラートが静かに壊れる可能性がある。
「静かに壊れる」というのが一番やばいやつで、アラートが飛ばなくなるだけで誰も気づかないパターン。アップグレード前に自分のPromQLを全部確認しておく必要がある。
今回のリリースで個人的に評価しているのはセキュリティ修正の密度だ。具体的には以下の3件が入っている。
#25467のSQLインジェクション対策は、自分がLiteLLMをプロキシとして本番に近い環境で動かしているなら特に見ておいたほうがいい変更だ。パラメータ化クエリへの置き換えは地味だけど、入れておかないといけないやつ。
Dockerイメージの署名検証の話もリリースノートに書かれていて、cosignを使った検証フローが整備されている。コミットハッシュ 0112e53 に紐づく公開鍵で署名されているので、以下のコマンドで確認できる。
タグではなくコミットハッシュを使った検証が推奨されている理由は、タグは書き換えられる可能性があるがコミットハッシュは暗号学的に変更不可だから。CIでDockerイメージを引っ張る処理を書いているなら、この検証ステップをパイプラインに入れておくのは悪くない選択だと思う。
今回はリリース候補なので、本番への適用は正式リリース待ちが無難だ。ただ個人開発の検証環境で先に試しておくことで、正式リリース時の対応コストをゼロに近づけられる。自分の場合、Prometheusのダッシュボードを確認するのは今週中にやっておくつもりだ。
リリースノートを読む習慣は地味だけど、「アップグレードしたら壊れた」という後手の対応を減らすためには一番効いてくる。特にBreaking Changesの欄は毎回必ず読んでおいてほしい。
今回のリリース、正直パッとした新機能はない。でも地味に刺さる変更がいくつかあって、自分のプロジェクトに引きつけると無視できない内容だった。
Prometheusのlatencyバケットが減った話
いちばん気になったのがBreaking Changesに書いてあったPrometheusまわりの変更だ。デフォルトの LATENCY_BUCKETS が35から18境界に削減された。自分はSLOの死活監視にPrometheusを使っていて、 le="1.5" みたいな特定のレイテンシ値でPromQLを書いている箇所がある。このバケット縮小によって該当のシリーズが消えるので、既存のダッシュボードやアラートが静かに壊れる可能性がある。
「静かに壊れる」というのが一番やばいやつで、アラートが飛ばなくなるだけで誰も気づかないパターン。アップグレード前に自分のPromQLを全部確認しておく必要がある。
セキュリティ系の修正が3件まとめて入っている
今回のリリースで個人的に評価しているのはセキュリティ修正の密度だ。具体的には以下の3件が入っている。
- 管理エンドポイントへの入力バリデーション強化（#25445）
- combined_viewのトークンルックアップでパラメータ化クエリを使用（#25467）
- スキルアーカイブ展開時のファイルパス解決のハードニング（#25475）
#25467のSQLインジェクション対策は、自分がLiteLLMをプロキシとして本番に近い環境で動かしているなら特に見ておいたほうがいい変更だ。パラメータ化クエリへの置き換えは地味だけど、入れておかないといけないやつ。
Dockerイメージの署名検証の話もリリースノートに書かれていて、cosignを使った検証フローが整備されている。コミットハッシュ 0112e53 に紐づく公開鍵で署名されているので、以下のコマンドで確認できる。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.83.7.rc.1タグではなくコミットハッシュを使った検証が推奨されている理由は、タグは書き換えられる可能性があるがコミットハッシュは暗号学的に変更不可だから。CIでDockerイメージを引っ張る処理を書いているなら、この検証ステップをパイプラインに入れておくのは悪くない選択だと思う。
rc.1という段階でどう付き合うか
今回はリリース候補なので、本番への適用は正式リリース待ちが無難だ。ただ個人開発の検証環境で先に試しておくことで、正式リリース時の対応コストをゼロに近づけられる。自分の場合、Prometheusのダッシュボードを確認するのは今週中にやっておくつもりだ。
リリースノートを読む習慣は地味だけど、「アップグレードしたら壊れた」という後手の対応を減らすためには一番効いてくる。特にBreaking Changesの欄は毎回必ず読んでおいてほしい。