GitHubのリリースノートを流し読みしていたら、LiteLLMのナイトリービルドで気になる記載を見つけた。Python 3.9のサポートが終了して、最低バージョンが3.10になったという話だ。`requires-python`が`>=3.9, <3.14`から`>=3.10, <3.14`に変わった。
これ、地味に刺さる。自分のプロジェクトで「なんとなく3.9で動いてるからいいか」みたいな環境、ちゃんと棚卸しできてるだろうか。
Python 3.9はそもそも2025年10月にEOLを迎えている。つまりセキュリティパッチも来ない。LiteLLMがバージョン要件を上げてきたのは、ある意味で正式な「切り捨て宣言」だ。
自分はLLM周りをいくつかのサービスに組み込んでいるけど、Lambda関数やDockerイメージのベースイメージを「最初に作ったときのまま」にしてるケースが正直ある。そういう環境から今回のリリースを素直にpip updateしたら、依存関係で詰まる可能性が普通にある。
Dockerイメージの話でいうと、今回のリリースでは署名検証の仕組みも整備されている。cosignを使って署名を検証するコマンドが公式に提供されていて、こんな感じで確認できる。
コミットハッシュ`0112e53`をキーのパスに使うのがポイントで、タグより改ざん耐性が高い。CI/CDで本番に自動デプロイしているなら、このステップを挟む価値はある。
Breaking Changesだけ見て終わりにするのはもったいなくて、今回のリリースには機能追加もある。中で気になったのが「APIキーとチームごとに複数の同時バジェットウィンドウを設定できる」という変更だ（`#24883`）。
自分の開発チームでは、APIコストを月単位でザックリ管理していたけど、用途別に日次・週次・月次とウィンドウを分けて監視したいケースが実はある。たとえば開発環境は日次で使いすぎを防いで、本番は月次で管理するみたいな構成が一つのLiteLLM設定で組めるようになったらしい。これは素直にありがたい。
さらに`feat(teams): per-member model scope + team default_team_member_models`という変更も入っている。チームメンバーごとに使えるモデルのスコープを絞れるようになった。APIキーのシェアをやめてチーム単位でアクセス制御したい場合、この粒度での設定はかなり実用的だと思う。
Python 3.9か3.10かを確認するのは30秒で終わる話だ。でも「全部の環境を確認する」となると意外と漏れが出る。
ローカル、CI、Lambdaのランタイム、Dockerイメージのベース、全部揃えて3.10以上になっているか、これを機会に一回チェックしておくのがいいと思う。自分は来週、チームの共有Dockerイメージのベースを整理してみるつもりだ。依存関係の棚卸しをやってみると、意外なものが引っかかる予感がしている。
これ、地味に刺さる。自分のプロジェクトで「なんとなく3.9で動いてるからいいか」みたいな環境、ちゃんと棚卸しできてるだろうか。
「まあ動いてるから」が一番危ない
Python 3.9はそもそも2025年10月にEOLを迎えている。つまりセキュリティパッチも来ない。LiteLLMがバージョン要件を上げてきたのは、ある意味で正式な「切り捨て宣言」だ。
自分はLLM周りをいくつかのサービスに組み込んでいるけど、Lambda関数やDockerイメージのベースイメージを「最初に作ったときのまま」にしてるケースが正直ある。そういう環境から今回のリリースを素直にpip updateしたら、依存関係で詰まる可能性が普通にある。
Dockerイメージの話でいうと、今回のリリースでは署名検証の仕組みも整備されている。cosignを使って署名を検証するコマンドが公式に提供されていて、こんな感じで確認できる。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.83.10-nightlyコミットハッシュ`0112e53`をキーのパスに使うのがポイントで、タグより改ざん耐性が高い。CI/CDで本番に自動デプロイしているなら、このステップを挟む価値はある。
機能面でも普通に変化がある
Breaking Changesだけ見て終わりにするのはもったいなくて、今回のリリースには機能追加もある。中で気になったのが「APIキーとチームごとに複数の同時バジェットウィンドウを設定できる」という変更だ（`#24883`）。
自分の開発チームでは、APIコストを月単位でザックリ管理していたけど、用途別に日次・週次・月次とウィンドウを分けて監視したいケースが実はある。たとえば開発環境は日次で使いすぎを防いで、本番は月次で管理するみたいな構成が一つのLiteLLM設定で組めるようになったらしい。これは素直にありがたい。
さらに`feat(teams): per-member model scope + team default_team_member_models`という変更も入っている。チームメンバーごとに使えるモデルのスコープを絞れるようになった。APIキーのシェアをやめてチーム単位でアクセス制御したい場合、この粒度での設定はかなり実用的だと思う。
まずやることは環境の確認
Python 3.9か3.10かを確認するのは30秒で終わる話だ。でも「全部の環境を確認する」となると意外と漏れが出る。
ローカル、CI、Lambdaのランタイム、Dockerイメージのベース、全部揃えて3.10以上になっているか、これを機会に一回チェックしておくのがいいと思う。自分は来週、チームの共有Dockerイメージのベースを整理してみるつもりだ。依存関係の棚卸しをやってみると、意外なものが引っかかる予感がしている。