企业官网建设流程全解析

2026年5月22日，modelscope 发布了 v1.37.1 这个补丁版本。
从官方给出的说明来看，这次更新的核心非常明确：修复 trust_remote_code 在多个场景下的兼容性问题。
虽然它是一个 patch release，但从实际改动文件和代码分布来看，这次更新涉及面并不小，覆盖了模型基类、多个视觉模型、音频管线、管线构建器、训练器构建器、预处理器、注册机制、自动模型工具、镜像构建脚本以及版本号更新等多个部分。

一、v1.37.1 官方更新说明

本次版本发布信息如下：

• 版本：v1.37.1
• 发布时间：2026年5月22日
• 更新类型：Patch release
• 核心修复：Fix compatibility issues with trust_remote_code across multiple scenarios

也就是说，官方明确强调的不是新增大功能，而是围绕trust_remote_code的跨场景兼容性问题做了集中修复。

从变更记录看，这次版本共包含：

• 7 commits
• 16 files changed
• 3 contributors
• 43 additions
• 24 deletions

说明这次更新虽然是补丁版本，但实际代码联动范围比较广，且改动集中在安全加载、信任远程代码、白名单逻辑、管线和模型加载流程这些关键路径上。

二、本次更新的整体核心：trust_remote_code 兼容性修复

如果只用一句话概括 v1.37.1，那就是：

让 trust_remote_code 在更多场景下能正确生效，同时避免在某些受信任模型或特定模块中出现不必要的参数传递和兼容性问题。

从修改文件来看，这次更新围绕以下几类场景展开：

1. 基类模型加载时的 trust_remote_code 判断优化
2. pipeline 构建时对模型来源的信任判断优化
3. trainer 构建时对模型来源的信任判断优化
4. 预处理器加载接口补齐 trust_remote_code 参数
5. 多个具体模型、pipeline 中 check_trust_remote_code 的调用方式统一
6. 注册和构建逻辑中去除不该传递给非 modelscope 模块的 trust_remote_code 参数
7. 白名单机制扩展到 iic 和 damo
8. Docker CPU 镜像里的依赖版本约束调整
9. 版本号提升到 1.37.1，发布日期同步更新

下面逐项展开。

三、docker 相关更新

1. docker/Dockerfile.ubuntu：CPU 镜像依赖约束调整

在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。

这类修改通常是为了保持与现有代码或依赖组合的兼容性。虽然这里没有展开具体原因，但从补丁版本定位和本次整体更新主题看，它属于兼容性修复链路中的一环。

2. docker/Dockerfile.ubuntu.old：新增镜像构建模板

docker/Dockerfile.ubuntu.old发生了新增内容，内容包括：

• FROM {base_image}
• ARG CUR_TIME={cur_time}
• RUN echo $CUR_TIME
• 通过GIT_LFS_SKIP_SMUDGE=1克隆 modelscope 仓库指定分支
• 进入modelscope目录执行pip install . -f https://modelscope.oss-cn-beijing.aliyuncs.com/releases/repo.html
• 最后删除临时目录并清理 pip 缓存

这一部分显示出 Docker 构建模板中加入了时间戳和分支变量替换机制，也和后面的build_image.py修改形成呼应。

3. docker/build_image.py：补充 cur_time 变量替换

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

是配套的，说明镜像构建流程加入了时间信息注入。

四、模型基类 base_model.py 的关键修复

这是本次更新最重要的文件之一。

1. 初始化时 trust_remote_code 的判断变化

在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为真。

2. from_pretrained 逻辑增强

在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合并。

3. default_args 的传递条件收紧

原来逻辑是：

• 只要trust_remote_code为真，就把它放入default_args

现在改成：

• if trust_remote_code and not _model_trusted:
• 才设置default_args = {'trust_remote_code': trust_remote_code}

这点非常关键。
它表示：如果模型本身已经是可信来源，就没有必要再把trust_remote_code作为默认参数强行传递下去。

这类处理的作用就是减少不必要的参数污染，同时提高和下游构建流程的兼容性。

五、多个具体模型中的 check_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.py
• modelscope/models/cv/image_view_transform/image_view_transform_infer.py
• modelscope/models/cv/tinynas_detection/detector.py
• modelscope/models/cv/video_depth_estimation/dro_model.py

1. anydoor_model.py

这里原来是：

• self.check_trust_remote_code()

现在变为：

• self.check_trust_remote_code(self.model_dir)

说明该模型在校验远程代码信任状态时，明确依赖模型目录信息。

2. image_view_transform_infer.py

这里原来是：

• self.check_trust_remote_code()

现在变为：

• self.check_trust_remote_code(model_dir=model_dir)

同样是在初始化阶段把模型目录显式传给信任校验逻辑。

3. tinynas_detection/detector.py

这里原来是：

• self.check_trust_remote_code()

现在变为：

• self.check_trust_remote_code(model_dir=model_dir)

4. video_depth_estimation/dro_model.py

这里原来也是：

• self.check_trust_remote_code()

现在变为：

• self.check_trust_remote_code(model_dir=model_dir)

这一组改动的共同方向很明显：
统一把模型目录作为信任判断的上下文输入，避免仅靠默认状态做判断带来的兼容性问题。

六、音频 pipeline 的修复

在modelscope/pipelines/audio/linear_aec_pipeline.py中，check_trust_remote_code的调用也被调整。

原来类似是：

• 调用self.check_trust_remote_code(...)

现在补充了：

• model_dir=model

也就是在提示信息之外，明确把模型路径传进去。

这表明该音频 pipeline 在加载模块时，也需要依赖模型目录来判断是否允许远程代码执行。

从改动结构看，这部分不仅仅是提示文案微调，而是加载上下文更完整了。

七、disco_guided_diffusion pipeline 的修复

modelscope/pipelines/multi_modal/disco_guided_diffusion_pipeline/disco_guided_diffusion.py中有两处调整。

1. check_trust_remote_code 增加 model_dir 参数

原来只传了提示信息，现在增加了：

• model_dir=model

也就是说，和其他模型/管线一样，信任判断时加入模型目录参数。

2. 删除了重复或冗余的 trust_remote_code 检查

原来文件中存在一段：

• self.trust_remote_code = kwargs.get('trust_remote_code', False)
• self.check_trust_remote_code(...)

这部分在本次更新中被删除。

这说明这个 pipeline 的 trust_remote_code 处理逻辑进行了收敛，避免重复判断或重复传参。

八、pipeline builder 的重要调整

modelscope/pipelines/builder.py是这次更新的核心文件之一，因为它直接影响 pipeline 构建流程。

1. 引入受信任模型判断

新增导入：

• 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 构建时也加入了“受信任来源自动放行”的逻辑。

2. build_pipeline 的 default_args 传递方式改变

原来逻辑是直接：

• 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 内部对象时。

九、preprocessors/base.py：补齐 trust_remote_code 参数

modelscope/preprocessors/base.py中的from_pretrained签名新增了：

• trust_remote_code=False

这个修改非常直接：
说明预处理器加载也开始支持统一的远程代码信任控制。

虽然这段 diff 只展示了方法签名变化，但从版本主题看，它是完整修复链路的一部分，确保预处理器在从远程仓库加载时具备与模型、pipeline 一致的控制入口。

十、trainer builder 的调整

modelscope/trainers/builder.py也加入了与 pipeline 类似的逻辑。

新增导入：

• from modelscope.utils.automodel_utils import check_model_from_owner_group

并且在build_trainer()中：

• 从default_args中取出model
• 解析model_id
• 计算trust_remote_code = default_args.get('trust_remote_code', False) or check_model_from_owner_group(model_id)

这说明 trainer 的构建逻辑也开始基于模型来源自动判断是否可信。

这与 pipeline 和 base_model 的改动思路统一：
只要模型属于特定受信任来源，就可以自动进入可信路径，减少对外显式参数的依赖。

十一、automodel_utils.py：增强模型来源检查

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 改动，说明这个函数在本次版本里被更多地方调用，因此需要更稳健的输入防护。

十二、registry.py：去除非 modelscope 模块的 trust_remote_code 参数

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'

这和本次版本发布信息是对应的。

十四、本次更新的文件清单意义总结

从本次改动涉及的文件来看，更新覆盖范围非常明确：

• Docker 构建链路
• 模型基类
• 多个视觉模型
• 音频 pipeline
• 多模态 pipeline
• pipeline 构建器
• preprocessor 基类
• trainer 构建器
• 自动模型工具
• registry
• version

这说明 v1.37.1 不是单点修补，而是围绕trust_remote_code的完整链路修正。

十五、这次更新最值得关注的结论

如果要提炼这次版本更新的重点，可以概括为以下几点：

1. 官方明确修复了trust_remote_code在多个场景下的兼容性问题。
2. 模型、pipeline、trainer、preprocessor、registry 等多个入口都统一了 trust 判断逻辑。
3. 对于iic和damo这类受信任来源，系统会自动识别，减少手动传参。
4. 在非 modelscope 模块构造过程中，会主动去掉trust_remote_code，降低兼容风险。
5. 多个具体模型和 pipeline 的check_trust_remote_code调用方式被统一为带model_dir参数。
6. CPU 镜像中的transformers版本被限制为<5.9，体现了依赖层面的兼容性控制。
7. 版本号从 1.37.0 升级到 1.37.1，属于正式补丁发布。

十六、结语

代码地址：github.com/modelscope/modelscope

总的来说，modelscope v1.37.1 是一次典型但非常重要的补丁更新。
它没有带来大规模功能扩展，却精准地修复了trust_remote_code在多场景下的兼容问题，并同步调整了 Docker、模型加载、管线构建、训练器构建、注册机制等关键路径。