



2026年5月22日,modelscope 发布了 v1.37.1 这个补丁版本。 从官方给出的说明来看,这次更新的核心非常明确:修复 trust_remote_code 在多个场景下的兼容性问题。 虽然它是一个 patch release,但从实际改动文件和代码分布来看,这次更新涉及面并不小,覆盖了模型基类、多个视觉模型、音频管线、管线构建器、训练器构建器、预处理器、注册机制、自动模型工具、镜像构建脚本以及版本号更新等多个部分。
本次版本发布信息如下:
也就是说,官方明确强调的不是新增大功能,而是围绕 trust_remote_code 的跨场景兼容性问题做了集中修复。
从变更记录看,这次版本共包含:
说明这次更新虽然是补丁版本,但实际代码联动范围比较广,且改动集中在安全加载、信任远程代码、白名单逻辑、管线和模型加载流程这些关键路径上。
如果只用一句话概括 v1.37.1,那就是:
让 trust_remote_code 在更多场景下能正确生效,同时避免在某些受信任模型或特定模块中出现不必要的参数传递和兼容性问题。
从修改文件来看,这次更新围绕以下几类场景展开:
下面逐项展开。
在 docker/Dockerfile.ubuntu 中,CPU 分支的安装命令发生了变化:
原来是:
pip install --no-cache-dir huggingface-hub transformers peft diffusers -U现在改成:
pip install --no-cache-dir huggingface-hub "transformers<5.9" peft diffusers -U这说明在 CPU 镜像环境下,transformers 被增加了版本上限约束,限制为 <5.9。
这类修改通常是为了保持与现有代码或依赖组合的兼容性。虽然这里没有展开具体原因,但从补丁版本定位和本次整体更新主题看,它属于兼容性修复链路中的一环。
docker/Dockerfile.ubuntu.old 发生了新增内容,内容包括:
FROM {base_image}ARG CUR_TIME={cur_time}RUN echo $CUR_TIMEGIT_LFS_SKIP_SMUDGE=1 克隆 modelscope 仓库指定分支modelscope 目录执行 pip install . -f https://modelscope.oss-cn-beijing.aliyuncs.com/releases/repo.html这一部分显示出 Docker 构建模板中加入了时间戳和分支变量替换机制,也和后面的 build_image.py 修改形成呼应。
docker/build_image.py 中两处 generate_dockerfile() 逻辑都新增了:
content = content.replace('{cur_time}', formatted_time)也就是说,Dockerfile 模板中的 {cur_time} 会被实际构建时间替换掉。
这和上面的 docker/Dockerfile.ubuntu.old 里的:
ARG CUR_TIME={cur_time}RUN echo $CUR_TIME是配套的,说明镜像构建流程加入了时间信息注入。
这是本次更新最重要的文件之一。
在 modelscope/models/base/base_model.py 中,原来是:
self.trust_remote_code = kwargs.get('trust_remote_code', False)现在改成:
self.trust_remote_code = kwargs.get('trust_remote_code', False) or check_model_from_owner_group(model_dir)这意味着:
如果用户没有显式开启 trust_remote_code,但模型属于受信任的 owner group,那么也会自动认为 trust_remote_code 为真。
在 from_pretrained 中新增:
_model_trusted = check_model_from_owner_group(model_name_or_path)trust_remote_code = trust_remote_code or _model_trusted也就是说,加载模型时会先判断模型是否属于受信任来源,再与用户传入的 trust_remote_code 合并。
原来逻辑是:
trust_remote_code 为真,就把它放入 default_args现在改成:
if trust_remote_code and not _model_trusted:default_args = {'trust_remote_code': trust_remote_code}这点非常关键。
它表示:如果模型本身已经是可信来源,就没有必要再把 trust_remote_code 作为默认参数强行传递下去。
这类处理的作用就是减少不必要的参数污染,同时提高和下游构建流程的兼容性。
本次更新中,多个模型文件都把原来的:
self.check_trust_remote_code()改成了带 model_dir 参数的形式,例如:
self.check_trust_remote_code(self.model_dir)self.check_trust_remote_code(model_dir=model_dir)涉及文件包括:
modelscope/models/cv/anydoor/anydoor_model.pymodelscope/models/cv/image_view_transform/image_view_transform_infer.pymodelscope/models/cv/tinynas_detection/detector.pymodelscope/models/cv/video_depth_estimation/dro_model.py这里原来是:
self.check_trust_remote_code()现在变为:
self.check_trust_remote_code(self.model_dir)说明该模型在校验远程代码信任状态时,明确依赖模型目录信息。
这里原来是:
self.check_trust_remote_code()现在变为:
self.check_trust_remote_code(model_dir=model_dir)同样是在初始化阶段把模型目录显式传给信任校验逻辑。
这里原来是:
self.check_trust_remote_code()现在变为:
self.check_trust_remote_code(model_dir=model_dir)这里原来也是:
self.check_trust_remote_code()现在变为:
self.check_trust_remote_code(model_dir=model_dir)这一组改动的共同方向很明显: 统一把模型目录作为信任判断的上下文输入,避免仅靠默认状态做判断带来的兼容性问题。
在 modelscope/pipelines/audio/linear_aec_pipeline.py 中,check_trust_remote_code 的调用也被调整。
原来类似是:
self.check_trust_remote_code(...)现在补充了:
model_dir=model也就是在提示信息之外,明确把模型路径传进去。
这表明该音频 pipeline 在加载模块时,也需要依赖模型目录来判断是否允许远程代码执行。
从改动结构看,这部分不仅仅是提示文案微调,而是加载上下文更完整了。
modelscope/pipelines/multi_modal/disco_guided_diffusion_pipeline/disco_guided_diffusion.py 中有两处调整。
原来只传了提示信息,现在增加了:
model_dir=model也就是说,和其他模型/管线一样,信任判断时加入模型目录参数。
原来文件中存在一段:
self.trust_remote_code = kwargs.get('trust_remote_code', False)self.check_trust_remote_code(...)这部分在本次更新中被删除。
这说明这个 pipeline 的 trust_remote_code 处理逻辑进行了收敛,避免重复判断或重复传参。
modelscope/pipelines/builder.py 是这次更新的核心文件之一,因为它直接影响 pipeline 构建流程。
新增导入:
from modelscope.utils.automodel_utils import check_model_from_owner_group并且在 pipeline() 函数中:
model 中提取 model_id_model_trusted = check_model_from_owner_group(model_id)trust_remote_code = trust_remote_code or _model_trusted也就是说,pipeline 构建时也加入了“受信任来源自动放行”的逻辑。
原来逻辑是直接:
return build_pipeline(cfg, task_name=task, default_args={'trust_remote_code': trust_remote_code})现在改成:
_model_trusted,直接 return build_pipeline(cfg, task_name=task)return build_pipeline(cfg, task_name=task, default_args={'trust_remote_code': trust_remote_code})这和 base_model.py 的改法是一致的: 受信任模型不再额外传递 trust_remote_code 参数。
这类变化对于修复跨场景兼容性非常重要,因为很多构建链路并不希望收到这个参数,尤其是当目标对象并不是 modelscope 内部对象时。
modelscope/preprocessors/base.py 中的 from_pretrained 签名新增了:
trust_remote_code=False这个修改非常直接: 说明预处理器加载也开始支持统一的远程代码信任控制。
虽然这段 diff 只展示了方法签名变化,但从版本主题看,它是完整修复链路的一部分,确保预处理器在从远程仓库加载时具备与模型、pipeline 一致的控制入口。
modelscope/trainers/builder.py 也加入了与 pipeline 类似的逻辑。
新增导入:
from modelscope.utils.automodel_utils import check_model_from_owner_group并且在 build_trainer() 中:
default_args 中取出 modelmodel_idtrust_remote_code = default_args.get('trust_remote_code', False) or check_model_from_owner_group(model_id)这说明 trainer 的构建逻辑也开始基于模型来源自动判断是否可信。
这与 pipeline 和 base_model 的改动思路统一: 只要模型属于特定受信任来源,就可以自动进入可信路径,减少对外显式参数的依赖。
modelscope/utils/automodel_utils.py 中,check_model_from_owner_group 的开头判断从:
if not model_dir:变成:
if not model_dir or not isinstance(model_dir, str):这个修复看起来很小,但很关键。 它意味着这个函数现在会先排除非字符串类型输入,避免在某些场景下因为传入列表、对象或其他类型而导致兼容性问题。
结合上面的 pipeline、trainer、base_model 改动,说明这个函数在本次版本里被更多地方调用,因此需要更稳健的输入防护。
modelscope/utils/registry.py 中有一处非常值得注意的改动。
新增逻辑:
obj_cls.__module__ 不是以 modelscope 开头args.pop('trust_remote_code', None)这意味着:
当要构造的类并不是 modelscope 自己的模块时,trust_remote_code 这个参数会被移除,不再传给外部类构造函数。
这一点正是“跨场景兼容性修复”的典型做法。 因为很多第三方类并不接受这个参数,如果强行传递,就容易出现构造失败或参数冲突。
所以这次更新本质上是在 registry 这一层做了参数隔离,防止 trust_remote_code 被错误地扩散到不需要它的对象上。
modelscope/version.py 中进行了版本升级:
__version__ = '1.37.0' 改为 __version__ = '1.37.1'同时发布说明日期也更新为:
__release_datetime__ = '2026-05-20 23:59:59'这和本次版本发布信息是对应的。
从本次改动涉及的文件来看,更新覆盖范围非常明确:
这说明 v1.37.1 不是单点修补,而是围绕 trust_remote_code 的完整链路修正。
如果要提炼这次版本更新的重点,可以概括为以下几点:
trust_remote_code 在多个场景下的兼容性问题。iic 和 damo 这类受信任来源,系统会自动识别,减少手动传参。trust_remote_code,降低兼容风险。check_trust_remote_code 调用方式被统一为带 model_dir 参数。transformers 版本被限制为 <5.9,体现了依赖层面的兼容性控制。代码地址:github.com/modelscope/modelscope
总的来说,modelscope v1.37.1 是一次典型但非常重要的补丁更新。
它没有带来大规模功能扩展,却精准地修复了 trust_remote_code 在多场景下的兼容问题,并同步调整了 Docker、模型加载、管线构建、训练器构建、注册机制等关键路径。