LiteLLMのリリースノートを眺めるのが最近の習慣になってきた。v1.83.8-nightlyが4月15日にリリースされていて、いくつかのfixが自分のプロジェクトに直撃しそうだったので、今日はそこを掘り下げてみる。
キャッシュのTypeErrorは盲点だった
fix(cache): Prevent 'multiple values' TypeError in get_cache_key というPRが入っていた。キャッシュキーの生成まわりで multiple values なTypeErrorが起きうるというやつだ。自分のコードでもキャッシュを有効にしていて、「なんか稀にコケるな」と思いながら放置していた部分があった。原因がここだった可能性が高い。こういうサイレントに壊れる系のバグはログに残りにくくて、見つけにくいんだよな。
今回のfixを見て、まず自分のキャッシュ設定まわりを一通り確認しようと思った。特に同じキーに対して複数の値が渡るようなフローを作っていないか、パラメータの受け渡しをもう一度見直す予定だ。
S3との連携はSigV4の罠に注意
fix(s3_v2): use prepared URL for SigV4-signed S3 requests も地味に重要だった。SigV4署名つきのS3リクエストを使っているとき、prepared URLを使わないとリクエストが壊れるケースがある。自分はログをS3に飛ばす構成を組んでいて、署名まわりで謎のエラーが出たことが一度あった。あのときの原因これだったかもしれない。
SigV4の署名検証はURLのエンコード方法に敏感なので、微妙な差異が致命的になる。このfixはバックポートして使いたいレベルだった。
Dockerイメージの署名検証、やってる？
リリースノートを見ると、すべてのLiteLLMのDockerイメージがcosignで署名されているという記載がある。コミットハッシュを指定した検証が推奨されていて、こんな形で確認できる。
cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:v1.83.8-nightlyコミットハッシュは暗号学的に不変なので、タグよりも信頼できる。タグはリポジトリのprotection設定に依存するから、厳密に確認したいなら上のコマンドの方を使うべきだ。正直、LLM系のOSSを本番に乗せるとき、Dockerイメージの署名検証まで気にしてなかった。今回調べてみてちょっと反省した。
Prometheusのlatency histogramに7mと10mのバケットが追加されたfeatも入っていて、長時間処理の計測がしやすくなった。自分のPrometheus設定でこのあたりを拾えているか、Grafanaのダッシュボードも確認しておこうと思っている。
このリリースから学んだのは、「たまに出るエラー」をそのままにしておくのは危ないということだ。今回のキャッシュのTypeErrorみたいに、OSSの方でもひっそりfixされていることがある。リリースノートを読む習慣は、自分のデバッグ時間を削ってくれると改めて感じた。まずキャッシュまわりとS3連携のコードを今週中に見直してみるつもりだ。