使用 AutoClass 加载预训练模型Transformers 自动架构推断与 from_pretrained 实战指南【免费下载链接】transformers Transformers: the model-definition framework for state-of-the-art machine learning models in text, vision, audio, and multimodal models, for both inference and training.项目地址: https://gitcode.com/GitHub_Trending/tra/transformers导读面对数量众多的 Transformer 架构为某个 checkpoint 手动挑选并实例化正确的模型类往往繁琐且易错。 Transformers 提供的AutoClass系列正是为此而生它从给定的 checkpoint 中自动推断并加载正确的架构让同一份代码适配任意 checkpoint成为可能。本文以docs/source/es/autoclass_tutorial.md为骨架结合仓库内src/transformers/models/auto/下的实现源码完整讲解如何使用AutoTokenizer、AutoFeatureExtractor、AutoProcessor与AutoModelFor*加载预训练实例并深入其底层推断机制。读完本文你将掌握一套 checkpoint 无关的模型加载范式能够为 NLP、音频、视觉与多模态任务快速搭建可复用的推理与微调流水线。一、核心概念架构Architecture与 Checkpoint在开始之前必须先厘清三个术语见 autoclass_tutorial.md架构architecture模型的结构骨架例如 BERT 是一种架构checkpoint某一架构对应的权重及配置例如google-bert/bert-base-uncased是 BERT 架构下的一个 checkpoint模型model一个通用说法既可以指架构也可以指 checkpoint。AutoClass的哲学正是建立在架构与权重解耦之上从源码看Auto 系列的核心是_BaseAutoModelClass定义于 auto_factory.py它本身不能被直接实例化——直接调用__init__会抛出OSError提示必须使用from_pretrained或from_config这两个类方法。也就是说Auto 类不是一个模型而是根据 checkpoint 分派到具体模型类的工厂。这种设计带来的直接收益是只要你的代码对一个 checkpoint 可用那么对另一个为相似任务训练的 checkpoint 同样可用——即使两者的底层架构完全不同。二、AutoClass 的推断机制AutoConfig 是枢纽从源码结构看Auto 系列的推断链路全部经由配置类完成核心文件集中在 src/transformers/models/auto/文件职责configuration_auto.pyAutoConfig根据config.json的model_type字段推断配置类auto_factory.py_BaseAutoModelClass工厂基类实现from_pretrained/from_config通用逻辑tokenization_auto.pyAutoTokenizer与TOKENIZER_MAPPING_NAMES注册表feature_extraction_auto.pyAutoFeatureExtractorimage_processing_auto.pyAutoImageProcessorprocessing_auto.pyAutoProcessormodeling_auto.py各类AutoModelFor*在_BaseAutoModelClass.from_pretrainedauto_factory.py中加载流程大致如下若未显式传入config先调用AutoConfig.from_pretrained读取 checkpoint 的config.json得到具体的配置类通过配置类在_model_mapping一个_LazyAutoMapping延迟映射中查找对应的模型类若配置中存在architectures字段则优先按其中的类名精确匹配_get_model_class见 auto_factory.py否则取映射表中默认第一个模型类最后把控制权交给具体模型类的from_pretrained完成权重的下载与加载。此外从 tokenization_auto.py 可以看到TOKENIZER_MAPPING_NAMES以model_type为键、分词器类名为值例如(bert, BertTokenizer)、(albert, AlbertTokenizer)、(gpt2, GPT2Tokenizer)这印证了Auto 类 注册表 分派逻辑的实现事实。同一份 checkpoint 之所以能加载出不同任务的模型序列分类、Token 分类等正是因为AutoModelFor*各自维护了独立的映射表。三、AutoTokenizerNLP 流水线的起点几乎任何 NLP 任务都以分词器tokenizer开始它负责把原始文本转换为模型可处理的输入格式。加载方式如下原文档示例 from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(google-bert/bert-base-uncased)随后对输入进行分词 sequence In a hole in the ground there lived a hobbit. print(tokenizer(sequence)) {input_ids: [101, 1999, 1037, 4920, 1999, 1996, 2598, 2045, 2973, 1037, 7570, 10322, 4183, 1012, 102], token_type_ids: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], attention_mask: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]}返回结果中的三个字段含义如下input_ids每个 token 在词表中的索引首尾的 101 / 102 分别是 BERT 的[CLS]与[SEP]特殊标记token_type_ids区分不同句子段的段标识单句场景下全为 0attention_mask标记真实 token1与 padding0供模型在注意力计算时忽略填充位。值得一提的实现细节是AutoTokenizer在分派时会检查依赖可用性从 tokenization_auto.py 可以看出许多model_type在安装了tokenizers库时优先使用基于 Rust 后端的快速分词器否则回退到纯 Python 实现代码中以is_tokenizers_available()/is_sentencepiece_available()等守卫区分。这解释了为什么同一个 checkpoint 在不同环境下可能拿到Fast或非Fast的分词器实例。四、AutoFeatureExtractor处理音频与视觉信号对于音频任务特征提取器feature extractor负责把原始音频信号处理成正确的输入格式。原文档示例使用了一个语音情感识别 checkpoint from transformers import AutoFeatureExtractor feature_extractor AutoFeatureExtractor.from_pretrained( ... ehcalabres/wav2vec2-lg-xlsr-en-speech-emotion-recognition ... )作为补充仓库同时提供了AutoImageProcessor实现于 image_processing_auto.py用于视觉任务中把图像转换为模型输入例如 from transformers import AutoImageProcessor image_processor AutoImageProcessor.from_pretrained(google/vit-base-patch16-224)在实际使用中AutoFeatureExtractor与AutoImageProcessor的职责有所区分前者通常处理音频波形或频谱如 wav2vec2 系列后者处理图像缩放、归一化、patch 化等。两者的分派逻辑与AutoConfig一致——先读取 checkpoint 的配置再按model_type在各自映射表中定位具体的处理类。五、AutoProcessor多模态任务的组合器多模态任务往往需要把两种以上的预处理工具组合起来。例如 LayoutLMV2参见 layoutlmv2 模型文档既需要图像处理器处理文档图像又需要分词器处理文本而AutoProcessor会把两者封装为单一入口 from transformers import AutoProcessor processor AutoProcessor.from_pretrained(microsoft/layoutlmv2-base-uncased)从仓库实现看AutoProcessor的分派位于 processing_auto.py其核心是对若干PreTrainedProcessor子类内部持有 tokenizer、image processor、feature extractor 的组合的按需加载。这种设计的工程价值在于调用方无需关心这个多模态模型需要哪些预处理组件只需面向processor(images..., text...)的统一接口编程。六、AutoModelFor*按任务加载预训练模型AutoModelFor*系列类允许你为给定任务加载预训练模型。例如使用AutoModelForSequenceClassification加载一个用于序列分类如情感分析的模型 from transformers import AutoModelForSequenceClassification model AutoModelForSequenceClassification.from_pretrained(distilbert/distilbert-base-uncased)同一个 checkpoint 可以轻松复用于不同的下游任务——只需更换AutoModelFor*类即可 from transformers import AutoModelForTokenClassification model AutoModelForTokenClassification.from_pretrained(distilbert/distilbert-base-uncased)AutoModelFor*的可用任务清单非常庞大覆盖文本分类、Token 分类、问答、文本生成、翻译、摘要、音频分类、图像分类、目标检测、视觉问答等完整列表参见 auto.md 模型文档。从 modeling_auto.py 的源码看每个任务类如AutoModelForSequenceClassification都绑定了一张独立的映射表例如MODEL_FOR_SEQUENCE_CLASSIFICATION_MAPPING_NAMES其中每个条目把一个配置类指向一个带任务头的模型实现。一个值得强调的通用细节来自_BaseAutoModelClass.from_pretrained的 docstringfrom_pretrained加载完成后模型默认处于评估模式内部调用model.eval()dropout 等模块被停用若要训练需要显式调用model.train()切回训练模式。七、from_pretrained 常用参数速查AutoClass.from_pretrained支持传入丰富的关键字参数这里结合 auto_factory.py 的 docstring 整理最常用的几项参数默认值作用pretrained_model_name_or_path必填Hub 上的模型 id如google-bert/bert-base-uncased或本地目录路径目录内应含config.json与权重文件configNone显式传入PreTrainedConfig跳过自动加载配置的步骤cache_dirNone覆盖默认缓存目录指定权重下载位置force_downloadFalse强制重新下载忽略已有缓存local_files_onlyFalse仅使用本地文件不尝试联网下载revisionmain指定模型版本可以是分支名、tag 或 commit idtrust_remote_codeFalse是否允许执行 Hub 上自定义模型代码仅在完全信任的仓库中设为Truetorch_dtype/dtypeNone以指定精度加载权重如torch.float16auto表示自动选择output_attentions等 kwargs—可覆盖配置属性并传给底层模型__init__另外从实现上看from_pretrained会把_from_auto True注入 kwargs并专门提取cache_dir、force_download、local_files_only、proxies、revision、subfolder、token等 Hub 相关参数单独处理其余参数先用于构造/更新配置再传递给底层模型——这就是kwargs 既能改配置又能传模型的原因。八、安全提示不要加载不可信的模型对于 PyTorch 模型from_pretrained()内部使用torch.load()而后者底层依赖存在已知安全风险的pickle反序列化。因此永远不要加载来自不可信来源、或可能被篡改的模型文件Hub 上托管的公共模型因每次提交都会进行恶意软件扫描风险相对可控若对来源有疑虑建议校验提交签名等方式确认模型完整性详见 Hub 安全相关文档。九、推荐用法与下一步官方推荐原文档结论始终是使用AutoTokenizer类与AutoModelFor*类加载预训练实例。这样做可以确保每次都加载到与 checkpoint 匹配的正确架构同时让代码天然具备跨架构的可移植性。加载完成只是第一步。下一步可以学习如何使用新加载的 tokenizer、image processor、feature extractor 与 processor 对数据集进行预处理为微调fine-tuning做准备——这正是 preprocessing 教程 的内容。整体链路可以概括为AutoTokenizer/AutoImageProcessor/AutoFeatureExtractor/AutoProcessor完成原始数据到模型输入的转换AutoModelFor*从 checkpoint 加载带任务头的预训练模型组合二者即可快速搭建面向具体任务的推理或微调脚本且全部代码与具体架构解耦天然可复用。【免费下载链接】transformers Transformers: the model-definition framework for state-of-the-art machine learning models in text, vision, audio, and multimodal models, for both inference and training.项目地址: https://gitcode.com/GitHub_Trending/tra/transformers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 AutoClass 加载预训练模型：Transformers 自动架构推断与 from_pretrained 实战指南
使用 AutoClass 加载预训练模型Transformers 自动架构推断与 from_pretrained 实战指南【免费下载链接】transformers Transformers: the model-definition framework for state-of-the-art machine learning models in text, vision, audio, and multimodal models, for both inference and training.项目地址: https://gitcode.com/GitHub_Trending/tra/transformers导读面对数量众多的 Transformer 架构为某个 checkpoint 手动挑选并实例化正确的模型类往往繁琐且易错。 Transformers 提供的AutoClass系列正是为此而生它从给定的 checkpoint 中自动推断并加载正确的架构让同一份代码适配任意 checkpoint成为可能。本文以docs/source/es/autoclass_tutorial.md为骨架结合仓库内src/transformers/models/auto/下的实现源码完整讲解如何使用AutoTokenizer、AutoFeatureExtractor、AutoProcessor与AutoModelFor*加载预训练实例并深入其底层推断机制。读完本文你将掌握一套 checkpoint 无关的模型加载范式能够为 NLP、音频、视觉与多模态任务快速搭建可复用的推理与微调流水线。一、核心概念架构Architecture与 Checkpoint在开始之前必须先厘清三个术语见 autoclass_tutorial.md架构architecture模型的结构骨架例如 BERT 是一种架构checkpoint某一架构对应的权重及配置例如google-bert/bert-base-uncased是 BERT 架构下的一个 checkpoint模型model一个通用说法既可以指架构也可以指 checkpoint。AutoClass的哲学正是建立在架构与权重解耦之上从源码看Auto 系列的核心是_BaseAutoModelClass定义于 auto_factory.py它本身不能被直接实例化——直接调用__init__会抛出OSError提示必须使用from_pretrained或from_config这两个类方法。也就是说Auto 类不是一个模型而是根据 checkpoint 分派到具体模型类的工厂。这种设计带来的直接收益是只要你的代码对一个 checkpoint 可用那么对另一个为相似任务训练的 checkpoint 同样可用——即使两者的底层架构完全不同。二、AutoClass 的推断机制AutoConfig 是枢纽从源码结构看Auto 系列的推断链路全部经由配置类完成核心文件集中在 src/transformers/models/auto/文件职责configuration_auto.pyAutoConfig根据config.json的model_type字段推断配置类auto_factory.py_BaseAutoModelClass工厂基类实现from_pretrained/from_config通用逻辑tokenization_auto.pyAutoTokenizer与TOKENIZER_MAPPING_NAMES注册表feature_extraction_auto.pyAutoFeatureExtractorimage_processing_auto.pyAutoImageProcessorprocessing_auto.pyAutoProcessormodeling_auto.py各类AutoModelFor*在_BaseAutoModelClass.from_pretrainedauto_factory.py中加载流程大致如下若未显式传入config先调用AutoConfig.from_pretrained读取 checkpoint 的config.json得到具体的配置类通过配置类在_model_mapping一个_LazyAutoMapping延迟映射中查找对应的模型类若配置中存在architectures字段则优先按其中的类名精确匹配_get_model_class见 auto_factory.py否则取映射表中默认第一个模型类最后把控制权交给具体模型类的from_pretrained完成权重的下载与加载。此外从 tokenization_auto.py 可以看到TOKENIZER_MAPPING_NAMES以model_type为键、分词器类名为值例如(bert, BertTokenizer)、(albert, AlbertTokenizer)、(gpt2, GPT2Tokenizer)这印证了Auto 类 注册表 分派逻辑的实现事实。同一份 checkpoint 之所以能加载出不同任务的模型序列分类、Token 分类等正是因为AutoModelFor*各自维护了独立的映射表。三、AutoTokenizerNLP 流水线的起点几乎任何 NLP 任务都以分词器tokenizer开始它负责把原始文本转换为模型可处理的输入格式。加载方式如下原文档示例 from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(google-bert/bert-base-uncased)随后对输入进行分词 sequence In a hole in the ground there lived a hobbit. print(tokenizer(sequence)) {input_ids: [101, 1999, 1037, 4920, 1999, 1996, 2598, 2045, 2973, 1037, 7570, 10322, 4183, 1012, 102], token_type_ids: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], attention_mask: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]}返回结果中的三个字段含义如下input_ids每个 token 在词表中的索引首尾的 101 / 102 分别是 BERT 的[CLS]与[SEP]特殊标记token_type_ids区分不同句子段的段标识单句场景下全为 0attention_mask标记真实 token1与 padding0供模型在注意力计算时忽略填充位。值得一提的实现细节是AutoTokenizer在分派时会检查依赖可用性从 tokenization_auto.py 可以看出许多model_type在安装了tokenizers库时优先使用基于 Rust 后端的快速分词器否则回退到纯 Python 实现代码中以is_tokenizers_available()/is_sentencepiece_available()等守卫区分。这解释了为什么同一个 checkpoint 在不同环境下可能拿到Fast或非Fast的分词器实例。四、AutoFeatureExtractor处理音频与视觉信号对于音频任务特征提取器feature extractor负责把原始音频信号处理成正确的输入格式。原文档示例使用了一个语音情感识别 checkpoint from transformers import AutoFeatureExtractor feature_extractor AutoFeatureExtractor.from_pretrained( ... ehcalabres/wav2vec2-lg-xlsr-en-speech-emotion-recognition ... )作为补充仓库同时提供了AutoImageProcessor实现于 image_processing_auto.py用于视觉任务中把图像转换为模型输入例如 from transformers import AutoImageProcessor image_processor AutoImageProcessor.from_pretrained(google/vit-base-patch16-224)在实际使用中AutoFeatureExtractor与AutoImageProcessor的职责有所区分前者通常处理音频波形或频谱如 wav2vec2 系列后者处理图像缩放、归一化、patch 化等。两者的分派逻辑与AutoConfig一致——先读取 checkpoint 的配置再按model_type在各自映射表中定位具体的处理类。五、AutoProcessor多模态任务的组合器多模态任务往往需要把两种以上的预处理工具组合起来。例如 LayoutLMV2参见 layoutlmv2 模型文档既需要图像处理器处理文档图像又需要分词器处理文本而AutoProcessor会把两者封装为单一入口 from transformers import AutoProcessor processor AutoProcessor.from_pretrained(microsoft/layoutlmv2-base-uncased)从仓库实现看AutoProcessor的分派位于 processing_auto.py其核心是对若干PreTrainedProcessor子类内部持有 tokenizer、image processor、feature extractor 的组合的按需加载。这种设计的工程价值在于调用方无需关心这个多模态模型需要哪些预处理组件只需面向processor(images..., text...)的统一接口编程。六、AutoModelFor*按任务加载预训练模型AutoModelFor*系列类允许你为给定任务加载预训练模型。例如使用AutoModelForSequenceClassification加载一个用于序列分类如情感分析的模型 from transformers import AutoModelForSequenceClassification model AutoModelForSequenceClassification.from_pretrained(distilbert/distilbert-base-uncased)同一个 checkpoint 可以轻松复用于不同的下游任务——只需更换AutoModelFor*类即可 from transformers import AutoModelForTokenClassification model AutoModelForTokenClassification.from_pretrained(distilbert/distilbert-base-uncased)AutoModelFor*的可用任务清单非常庞大覆盖文本分类、Token 分类、问答、文本生成、翻译、摘要、音频分类、图像分类、目标检测、视觉问答等完整列表参见 auto.md 模型文档。从 modeling_auto.py 的源码看每个任务类如AutoModelForSequenceClassification都绑定了一张独立的映射表例如MODEL_FOR_SEQUENCE_CLASSIFICATION_MAPPING_NAMES其中每个条目把一个配置类指向一个带任务头的模型实现。一个值得强调的通用细节来自_BaseAutoModelClass.from_pretrained的 docstringfrom_pretrained加载完成后模型默认处于评估模式内部调用model.eval()dropout 等模块被停用若要训练需要显式调用model.train()切回训练模式。七、from_pretrained 常用参数速查AutoClass.from_pretrained支持传入丰富的关键字参数这里结合 auto_factory.py 的 docstring 整理最常用的几项参数默认值作用pretrained_model_name_or_path必填Hub 上的模型 id如google-bert/bert-base-uncased或本地目录路径目录内应含config.json与权重文件configNone显式传入PreTrainedConfig跳过自动加载配置的步骤cache_dirNone覆盖默认缓存目录指定权重下载位置force_downloadFalse强制重新下载忽略已有缓存local_files_onlyFalse仅使用本地文件不尝试联网下载revisionmain指定模型版本可以是分支名、tag 或 commit idtrust_remote_codeFalse是否允许执行 Hub 上自定义模型代码仅在完全信任的仓库中设为Truetorch_dtype/dtypeNone以指定精度加载权重如torch.float16auto表示自动选择output_attentions等 kwargs—可覆盖配置属性并传给底层模型__init__另外从实现上看from_pretrained会把_from_auto True注入 kwargs并专门提取cache_dir、force_download、local_files_only、proxies、revision、subfolder、token等 Hub 相关参数单独处理其余参数先用于构造/更新配置再传递给底层模型——这就是kwargs 既能改配置又能传模型的原因。八、安全提示不要加载不可信的模型对于 PyTorch 模型from_pretrained()内部使用torch.load()而后者底层依赖存在已知安全风险的pickle反序列化。因此永远不要加载来自不可信来源、或可能被篡改的模型文件Hub 上托管的公共模型因每次提交都会进行恶意软件扫描风险相对可控若对来源有疑虑建议校验提交签名等方式确认模型完整性详见 Hub 安全相关文档。九、推荐用法与下一步官方推荐原文档结论始终是使用AutoTokenizer类与AutoModelFor*类加载预训练实例。这样做可以确保每次都加载到与 checkpoint 匹配的正确架构同时让代码天然具备跨架构的可移植性。加载完成只是第一步。下一步可以学习如何使用新加载的 tokenizer、image processor、feature extractor 与 processor 对数据集进行预处理为微调fine-tuning做准备——这正是 preprocessing 教程 的内容。整体链路可以概括为AutoTokenizer/AutoImageProcessor/AutoFeatureExtractor/AutoProcessor完成原始数据到模型输入的转换AutoModelFor*从 checkpoint 加载带任务头的预训练模型组合二者即可快速搭建面向具体任务的推理或微调脚本且全部代码与具体架构解耦天然可复用。【免费下载链接】transformers Transformers: the model-definition framework for state-of-the-art machine learning models in text, vision, audio, and multimodal models, for both inference and training.项目地址: https://gitcode.com/GitHub_Trending/tra/transformers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考