LiteLLM 发布 v1.106.0：Docker 镜像启用签名验签，一键快速启动，stdio 型 MCP 默认关闭

LiteLLM 于 2026-10-18 发布 v1.106.0 正式版。这次值得留意的有三处：官方镜像改用 cosign 签名并给出验签命令；新增一条命令同时拉起网关、Postgres 与管理后台 UI 的快速启动方式；stdio 型 MCP 服务器改为默认关闭，属于带标记的破坏性变更。此外还补了新供应方、Claude Agent SDK 的追踪支持和一批成本与退役日期的修正。

这次发布的是什么

LiteLLM 在 2026-10-18 发布了 v1.106.0，GitHub 记录的发布时间是 2026-10-18T05:53:32Z，标记为正式版本；PyPI 上 litellm 的最新版本号同步为 1.106.0。LiteLLM 是把各家模型接口统一成同一套调用方式的那一层：对上给业务一个固定格式的接口，对下把请求路由到实际提供服务的厂商。

这次有三处改动值得单独拎出来。第一处是镜像供应链：官方宣布所有 Docker 镜像都用 cosign 签名，并在发布说明里直接给出了验签命令。第二处是上手路径：新增一条命令的快速启动方式，把网关、Postgres 数据库和管理后台界面一次拉起来。第三处是行为变更：stdio 型 MCP 服务器改为默认关闭，官方在变更记录里打了破坏性变更的标记。

说明一下版本号的坑：同一批 CHANGELOG 里还出现了 v1.103.5 与 v1.107.0-rc.1 两个条目，前者更早、后者是预发布通道的版本。写版本经验写到 published_at 而不是只看列表顺序——本次三个版本号里只有 v1.106.0 是当期正式版本。

可用性与限制

• 版本性质：v1.106.0 为正式发布版本；同期存在的 v1.107.0-rc.1 属预发布通道，生产环境不要混用。
• 镜像来源：官方说明镜像发布在 ghcr.io/berriai/litellm 下，验签所用的公钥托管在官方仓库里，具体路径以官方发布页为准。
• 验签方式有两种：用固定的提交哈希取公钥，或用发布标签取公钥。官方把前者标为推荐，因为提交哈希不可变；后者依赖仓库的标签保护规则，读取更直观但安全性取决于标签是否受保护。
• 行为变更：stdio 型 MCP 服务器不再默认启用，依赖这条路径的应用需要显式打开，升级前先确认自己的配置。
• 数据库依赖：快速启动方式会同时拉起 Postgres；是否适用于你的环境取决于本机或目标机是否已有可用的数据库服务。
• 价格与费率：本文不写任何金额。各模型单价、代币定价与退役日期请以官方或对应厂商的当期页面为准。

主要功能

• Docker 镜像用 cosign 签名，官方给出可直接执行的验签命令
• 新增一条命令的快速启动，同时拉起网关、Postgres 与管理后台界面
• stdio 型 MCP 服务器改为默认关闭
• 新增 Laya 网关与 OSS 分类器供应方支持
• 新增 Bespoke Nimble 网关与 OSS 分类器支持
• 追踪支持 Claude Agent SDK 的链路数据，含智能体名称与对话内容
• 新增把 JSON Web Token 映射到用户已有虚拟密钥的配置项
• 补入 OpenAI 语音合成与 GPT-5.x 系列的退役日期
• 修正 ClickHouse 追踪存储配置的统一性与大量界面、账单、路由相关的细节问题

技术原理

这次最容易被忽略、但价值最高的一条是镜像签名。容器镜像过去的信任模型是「我从官方 registry 拉的那个标签就是官方的镜像」，中间环节一旦被替换，使用者没有任何校验手段。cosign 的做法是对镜像做一个签名并放到可验证的位置，使用者拿公钥跑一次验签就能确认「这个镜像确实由持有私钥的一方签发过」。

官方在发布说明里特意提供了两种取公钥的方式，并且明确把「按提交哈希取」标为推荐。原因很直接：标签是可以被重新指向的，提交哈希不行。用标签取公钥的写法更容易读，但它依赖仓库的标签保护规则是否真的生效——官方在说明里也把这一点写明了。这是一个值得照搬的思路：验签这件事本身不难，难的是公钥从哪里来。

第二块是上手路径。之前的启动流程里，网关、数据库、管理界面是三件事，各自有配置文件与启动顺序；这次把它们合并成一条命令，本质是把「首次部署要读几份文档」降低为「跑一条命令看能不能起来」。对愿意先看到界面再逐个理解配置项的人来说，这比读文档更有效；反过来，如果你的环境已经有既定的数据库与部署方式，这条命令的价值就不大。

第三块是 MCP 传输方式的默认策略变化。MCP 服务器常见的传输方式有 stdio 与其他类型的远程传输两类：前者是把脚本本机拉起并通过标准输入输出通信，后者是走网络。默认关闭 stdio 意味着「本机拉起脚本」这条路需要显式打开。这类改动的动机通常是安全面：本机拉起子进程意味着继承本机的执行权限，把它从默认开启改为显式开启，是符合最小权限思路的处理。官方在变更记录上打了破坏性变更标记，说明这个默认是刻意收紧的。

实际体验

这篇不提供第一人称实测，只给出读者可以自己复现的验证步骤。

第一步，升级前先把版本号确认清楚。注意区分三个相邻条目：v1.103.5 更早、v1.106.0 是本次正式版、v1.107.0-rc.1 是预发布。用你自己环境里的包管理命令看过实际安装的版本号，再决定下一步。

第二步，验一次镜像签名。拉取官方镜像后，按发布页给出的命令执行验签。先试推荐的那条（用固定提交哈希取公钥），确认能看到「签名已校验通过」这类输出；再试按标签取公钥的那条做对比，体会两者在依赖条件上的差别。如果这一步拉公钥失败，先检查网络能否访问官方仓库，而不是跳过验签。

第三步，单独检查你的 MCP 配置。如果应用依赖 stdio 型 MCP 服务器，升级后大概率会发现服务不可用——这不是故障，是新默认值。先在配置里显式开启对应的传输方式，确认功能恢复，再把这个改动写进变更记录里。

第四步，试一下快速启动。找一台干净的机器或容器执行官方给的新命令，看网关、数据库与界面是否都起来了。这一步的意义在于建立一个「干净环境下可复现」的基线，之后自己的部署环境出问题时，可以拿它对照排除配置层面的干扰。

第五步，复核账单与退役日期相关的改动。这次补了若干模型的退役日期与计价档位修正。如果你依赖 LiteLLM 的成本统计做内部结算，建议在升级后拿同一批请求做一次前后比对，确认统计口径没有漂移。

项目地址与获取方式

官方发布说明：https://github.com/BerriAI/litellm/releases/tag/v1.106.0

官方仓库：https://github.com/BerriAI/litellm

Python 包索引：https://pypi.org/project/litellm/

官方 Docker 镜像：托管在 ghcr.io/berriai/litellm 下，具体标签与验签命令以官方发布页为准。

请通过官方渠道获取安装包与镜像，拉取后按官方给出的方式验签，避免使用来源不明的镜像。

适合谁用

• 在一处接入多家模型上游、需要统一调用方式与集中账单的团队
• 把镜像安全纳入交付流程、要求制品可验签的组织
• 刚开始试用这类网关、希望一条命令先跑通全链路的人
• 依赖 stdio 型 MCP 服务器、需要提前知道默认值变了的人
• 不必用的情况：只调用单一厂商接口且不需要统一层 —— 这一层带来的抽象对你没有收益

常见问题

为什么官方推荐用提交哈希而不是标签取公钥？

因为标签可以被重新指向，提交哈希不会。签名验证的安全性取决于「你拿到的公钥是不是对方的公钥」，用标签取公钥等于把这件事托付给仓库的标签保护规则是否生效；用固定哈希取则绕开了这层依赖。官方在发布说明里同时给了两种方式，并把前者标为推荐——本站建议照此办理。

升级后我的 MCP 功能不可用了，是不是升级坏了？

不一定是。这次把 stdio 型 MCP 服务器改成了默认关闭，官方在变更记录里打的是破坏性变更标记，说明是有意收紧。先确认你的应用是否依赖这种本机拉起脚本的传输方式，若是，在配置里显式开启即可；若不是在 stdio 路径上，则需要按常规排错流程排查。

v1.107.0-rc.1 比 v1.106.0 版本号更高，要不要直接上它？

不建议。rc 前缀代表预发布通道，用于提前试错与验证，稳定性没有正式版本保证。本次你可以依照 GitHub 上的发布记录判断：本次写的 v1.106.0 是正式发布版本，另一个是预发布版本。生产环境请跟随官方标注的正式版本。

快速启动那条命令适合用在生产环境吗？

它的定位是快速上手，会一次拉起网关、数据库与管理界面。生产环境通常已经有自己的数据库、备份与网络策略，把这三个组件压到一条命令里未必合适。建议用它建立一条「干净环境可复现」的基线，生产部署仍按你既有的方式编排。

这次说的 GPT-5.x 退役日期，我该怎么处理？

到官方或直接供应方的当期页面核对具体日期，再对照自己代码里使用的模型名。这类信息更新频繁，且不同厂商给出的时间点可能不一致，本文不写具体日期，也不建议依据第三方转述排期。

相关工具与内容

• 工具页：Dify、Claude Code、Cursor
• 分类：AI编程、AI智能体、AI对话
• 同题材快讯：MCP 官方服务器仓库 v1.0.0
• 延伸阅读：Beam 开放权重发布、智能体编排怎么选