InvokeAI 中的 IP-Adapter 模型格式规范目录结构、权重加载与配套 CLIP Vision 编码器【免费下载链接】InvokeAIInvoke is a leading creative engine for Stable Diffusion models, empowering professionals, artists, and enthusiasts to generate and create visual media using the latest AI-driven technologies. The solution offers an industry leading WebUI, and serves as the foundation for multiple commercial products.项目地址: https://gitcode.com/GitHub_Trending/in/InvokeAIIP-Adapter 是图像提示image prompt技术中最为流行的一类模型它让 Stable Diffusion 在保留原有文生图能力的同时直接以参考图像作为条件输入。本文以 InvokeAI 仓库中 invokeai/backend/ip_adapter/README.md 为骨架系统讲解 InvokeAI 自定义的 IP-Adapter 模型文件格式InvokeAI format、配套 CLIP Vision 图像编码器的组织方式、权重为何使用.bin而非.safetensors的原因并结合 模型加载源码 与 推理节点源码让读者既能手工整理/导入这类模型又能理解 InvokeAI 底层如何识别、加载并在扩散过程中注入 IP-Adapter 特征。背景为什么官方 IP-Adapter 仓库与 InvokeAI 模型管理不兼容IP-Adapter 由腾讯实验室提出论文见 arXiv 2308.06721其官方模型发布在h94/IP-Adapter。该仓库的模型以 PyTorch pickle 形式的 checkpoint 分发目录内同时混杂图像编码器与 IP-Adapter 权重。而 InvokeAI 的模型管理走的是「模型注册表 按类型/格式分派的加载器」路线见 invokeai/backend/model_manager/taxonomy.py 中ModelType.IPAdapter、ModelFormat.InvokeAI的定义官方仓库的打包方式无法与其模型探测、校验、按需下载机制良好衔接。因此 InvokeAI 定义了一套自有文件结构下文称InvokeAI format并在 invokeai/backend/ip_adapter/README.md 中给出完整规范。这套规范的核心目标有两点把CLIP Vision 图像编码器与IP-Adapter 权重拆成两个独立可管理的模型条目用文本文件记录图像编码器与 IP-Adapter 的配套关系从而在节点执行时自动选择正确的编码器。CLIP Vision 图像编码器diffusers 格式的目录结构IP-Adapter 本身不直接处理原始图片它依赖一个 CLIP Vision 模型把输入图像编码为视觉嵌入image embeddings。InvokeAI 将这类编码器按diffusers格式组织期望的目录结构为ip_adapter_sd_image_encoder/ ├── config.json └── model.safetensorsconfig.jsondiffusers 标准配置文件描述模型结构CLIPVisionModelWithProjection等model.safetensors编码器权重使用 safetensors 格式存储。在源码中编码器通过CLIPVisionModelWithProjection加载并配合CLIPImageProcessor完成图像预处理见 ip_adapter.pyget_image_embeds()先调用CLIPImageProcessor得到pixel_values再经编码器输出image_embeds。SD1.5 与 SDXL 两代模型使用不同的编码器编码器模型对应 CLIP ViT 变体用途InvokeAI/ip_adapter_sd_image_encoderCLIP-ViT-H-14CLIP-ViT-H-14-laion2B-s32B-b79KSD1.5 系列 IP-AdapterInvokeAI/ip_adapter_sdxl_image_encoderCLIP-ViT-bigG-14CLIP-ViT-bigG-14-laion2B-39B-b160kSDXL 系列 IP-Adapter这两个内置starter模型在 invokeai/backend/model_manager/starter_models.py 中注册baseBaseModelType.Any、typeModelType.CLIPVision意味着它们不绑定特定的扩散模型基座可被任意 SD1.5/SDXL IP-Adapter 复用。IP-Adapter 权重InvokeAI 格式的目录结构IP-Adapter 模型本体在 InvokeAI 格式下是一个目录其中恰好包含两个文件image_encoder.txt纯文本写入与该 IP-Adapter 配套的 CLIP Vision 编码器模型标识符model identifier即上表中的源 IDip_adapter.binIP-Adapter 权重文件PyTorch 序列化格式。标准目录结构示例ip_adapter_sd15/ ├── image_encoder.txt └── ip_adapter.bin这段结构被 模型配置 中的探测逻辑严格校验IPAdapter_InvokeAI_Config_Base.from_model_on_disk()会检查目录存在、ip_adapter.bin权重文件存在、image_encoder.txt元数据文件存在任何一个缺失都会抛出NotAMatchError该目录不会被识别为 InvokeAI 格式的 IP-Adapter 模型。image_encoder.txt中的标识符在实际推理时被读取并解析在 ip_adapter.py 推理节点 中invoke()首先通过模型配置取出image_encoder_model_id即image_encoder.txt的内容拆分出模型名后调用get_clip_image_encoder()在本地模型中查找对应ModelType.CLIPVision条目若尚未安装则调用installer.heuristic_import()自动下载最多等待 600 秒。也就是说只要按规范放置好两个文件InvokeAI 就能在节点执行时自动补齐配套编码器。为什么权重保存在.bin而不是.safetensors这是该 README 中一个专门解释过的设计取舍ip_adapter.bin内的权重存储为嵌套 dictnested dict结构safetensors不支持这种结构。虽然可以通过拆分为多个文件来解决但当前选择与官方h94/IP-Adapter仓库的 checkpoint 结构保持一致。从 加载源码 可以印证这一点load_ip_adapter_tensors()对.safetensors后缀路径使用safetensors.torch.load_file()对目录路径则直接torch.load(ip_adapter_diffusers_checkpoint_path / ip_adapter.bin, map_locationcpu)。加载后按前缀把键拆分为ip_adapter、image_proj、adapter_modules、image_proj_model等命名空间后两者用于兼容 noobai-mark-ipa 类模型的额外模块遇到未知键则抛出RuntimeError。需要说明的是这一限制仅针对官方风格的嵌套结构。仓库同时兼容Checkpoint 格式单个.safetensors文件键以image_proj.、ip_adapter.或ip_adapter_proj_model.开头见 IPAdapter_Checkpoint_Config_Base。此外 FLUX 的 XLabs IP-Adapter 也以 checkpoint 形式加载flux.py 中的 FluxIpAdapterModel经infer_xlabs_ip_adapter_params_from_state_dict()推断参数后构建XlabsIpAdapterFlux。架构自动识别从权重形状推断模型类别InvokeAI 加载 IP-Adapter 时并不依赖用户在目录里填写架构类型而是通过权重张量形状自动推断。核心函数是 build_ip_adapter()判定逻辑如下image_proj中存在proj.weight→ 基础版IPAdapter使用ImageProjModel单层线性投影 LayerNorm将 CLIP 嵌入投影为 4 个 cross-attention tokenimage_proj中存在proj_in.weight→IPAdapterPlus / IPAdapterPlusXL使用Resampler即 Perceiver 重采样器。此时读取ip_adapter中1.to_k_ip.weight的最后一维作为 cross-attention 维度768 → SD1.5 版 Plus2048 → SDXL 版 Plus其他值报错image_proj中存在proj.0.weight→IPAdapterFull使用 MLP 投影即 Plus 的 full-feature 变体都不匹配 → 抛出ValueError提示无法识别的架构。模型配置层使用了完全一致的判定标准在 ip_adapter.py 配置 中cross_attention_dim为 768/1024/2048 时分别映射到StableDiffusion1、StableDiffusion2、StableDiffusionXL基座。也就是说一个 IP-Adapter 目录只要放对两个文件其「是什么架构、适配哪个基座、该配哪个编码器」全部由 InvokeAI 自动探测得出。三种图像投影架构在源码中对应关系清晰架构类投影模型特征粒度IPAdapterImageProjModelLinearLayerNorm全局图像嵌入global featureIPAdapterPlusResamplerPerceiverdepth4, heads12细粒度特征fine-grainedSD1.5IPAdapterPlusXLResamplerPerceiverdepth4, heads20细粒度特征SDXLIPAdapterFullMLPProjModelLinear-GELU-Linear-LayerNormPlus 的 full-feature 变体Resampler实现位于 resampler.py以可学习的latents作为查询通过PerceiverAttention与FeedForward的残差堆叠把图像特征压缩为固定数量的查询 tokenfrom_state_dict()会从张量形状反推dim、num_queries、embedding_dim、output_dim等超参数。而每个 attention processor 的可插拔权重to_k_ip/to_v_ip则由 ip_attention_weights.py 中的IPAttentionWeights按索引组织成ModuleDict供扩散阶段注入。推理节点与目标块选择method 参数IP-Adapter 在 InvokeAI 中作为一个 conditioning 节点IPAdapterInvocation暴露给用户关键输入包括字段默认值说明image—IP-Adapter 图像提示可为单张或图像列表ip_adapter_model—要使用的 IP-Adapter 模型clip_vision_modelViT-HCLIP Vision 模型可选ViT-H/ViT-G/ViT-L对 checkpoint 格式模型为必选项weight1施加给 IP-Adapter 的权重须通过validate_weights校验methodfull应用方式full/style/composition/style_strong/style_precisebegin_step_percent/end_step_percent0/1IP-Adapter 生效的步数区间占总步数比例0–1maskNone可选 bool mask限制该 IP-Adapter 作用的区域其中method直接决定注入哪些 attention 块target_blocksstyleSD1.5 注入up_blocks.1SDXL 注入up_blocks.0.attentions.1只影响风格compositionSD1.5 注入down_blocks.2与mid_blockSDXL 注入down_blocks.2.attentions.1偏重构图style_strongSD1.5 覆盖 5 个 blockSDXL 覆盖 17 个 attention 位置风格施加最强style_precise介于两者之间full注入全部 block[block]默认行为。这些目标块列表的完整定义见 ip_adapter.py。对于 InvokeAI 格式的模型节点直接使用image_encoder.txt指定的配套编码器对于 checkpoint 格式则根据clip_vision_model从CLIP_VISION_MODEL_MAPip_adapter.py选择对应的 starter 编码器。官方托管模型清单InvokeAI 为每种架构托管了开箱即用的模型对应 README 中的 InvokeAI Hosted IP-Adapters 一节与上文两类模型一一对应图像编码器InvokeAI/ip_adapter_sd_image_encoderViT-H、InvokeAI/ip_adapter_sdxl_image_encoderViT-GIP-AdapterSD1.5InvokeAI/ip_adapter_sd15、InvokeAI/ip_adapter_plus_sd15、InvokeAI/ip_adapter_plus_face_sd15IP-AdapterSDXLInvokeAI/ip_adapter_sdxl、InvokeAI/ip_adapter_sdxl_vit_h、InvokeAI/ip-adapter-plus_sdxl_vit-h。在 InvokeAI 中使用 IP-Adapter 的完整流程综合以上规范与源码可以整理出一条完整的实战链路导入模型将编码器目录config.jsonmodel.safetensors与 IP-Adapter 目录image_encoder.txtip_adapter.bin放入模型根目录InvokeAI 的模型探测会依据 configs/ip_adapter.py 的规则自动识别为ModelType.IPAdapterInvokeAI 或 Checkpoint 格式并确定基座类型。若采用 checkpoint 单文件格式也可直接导入单个.safetensors。加载当节点首次使用该模型时注册在 model_loaders/ip_adapter.py 的IPAdapterInvokeAILoader同时注册了ModelFormat.InvokeAI与ModelFormat.Checkpoint两种格式调用build_ip_adapter()完成架构识别与权重装载。配套编码器推理节点读取image_encoder.txt定位配套 CLIP Vision 编码器未安装时自动下载安装。图像提示在 WebUI 工作流中连接 IP-Adapter 节点设置参考图像、weight、method、begin_step_percent/end_step_percent与可选mask即可在 SD1.5/SDXL 模型上实现风格迁移、构图控制、人脸特征保持等图像条件化生成。需要注意的边界条件image_encoder.txt与ip_adapter.bin两个文件缺一不可探测与校验逻辑会直接拒绝.bin格式仅限 InvokeAI 官方托管及同构模型使用其他来源模型建议使用 checkpoint.safetensors格式导入不同基座SD1.5/SD2/SDXL/FLUX的 IP-Adapter 不可混用需匹配对应主模型的base类型。小结InvokeAI 的 IP-Adapter 模型格式规范是一套「目录约定 元数据旁路 自动探测」的工程化方案用两个固定文件名image_encoder.txt与ip_adapter.bin把「配套关系」和「权重」显式化用张量形状推断架构与基座再借助模型注册表与自动下载机制实现「导入即用」。理解这套格式不仅有助于手工整理第三方 IP-Adapter 模型也能更清晰地把握 InvokeAI 从模型探测、加载到节点注入的完整链路。【免费下载链接】InvokeAIInvoke is a leading creative engine for Stable Diffusion models, empowering professionals, artists, and enthusiasts to generate and create visual media using the latest AI-driven technologies. The solution offers an industry leading WebUI, and serves as the foundation for multiple commercial products.项目地址: https://gitcode.com/GitHub_Trending/in/InvokeAI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 InvokeAI 中的 IP-Adapter 模型格式规范：目录结构、权重加载与配套 CLIP Vision 编码器
InvokeAI 中的 IP-Adapter 模型格式规范目录结构、权重加载与配套 CLIP Vision 编码器【免费下载链接】InvokeAIInvoke is a leading creative engine for Stable Diffusion models, empowering professionals, artists, and enthusiasts to generate and create visual media using the latest AI-driven technologies. The solution offers an industry leading WebUI, and serves as the foundation for multiple commercial products.项目地址: https://gitcode.com/GitHub_Trending/in/InvokeAIIP-Adapter 是图像提示image prompt技术中最为流行的一类模型它让 Stable Diffusion 在保留原有文生图能力的同时直接以参考图像作为条件输入。本文以 InvokeAI 仓库中 invokeai/backend/ip_adapter/README.md 为骨架系统讲解 InvokeAI 自定义的 IP-Adapter 模型文件格式InvokeAI format、配套 CLIP Vision 图像编码器的组织方式、权重为何使用.bin而非.safetensors的原因并结合 模型加载源码 与 推理节点源码让读者既能手工整理/导入这类模型又能理解 InvokeAI 底层如何识别、加载并在扩散过程中注入 IP-Adapter 特征。背景为什么官方 IP-Adapter 仓库与 InvokeAI 模型管理不兼容IP-Adapter 由腾讯实验室提出论文见 arXiv 2308.06721其官方模型发布在h94/IP-Adapter。该仓库的模型以 PyTorch pickle 形式的 checkpoint 分发目录内同时混杂图像编码器与 IP-Adapter 权重。而 InvokeAI 的模型管理走的是「模型注册表 按类型/格式分派的加载器」路线见 invokeai/backend/model_manager/taxonomy.py 中ModelType.IPAdapter、ModelFormat.InvokeAI的定义官方仓库的打包方式无法与其模型探测、校验、按需下载机制良好衔接。因此 InvokeAI 定义了一套自有文件结构下文称InvokeAI format并在 invokeai/backend/ip_adapter/README.md 中给出完整规范。这套规范的核心目标有两点把CLIP Vision 图像编码器与IP-Adapter 权重拆成两个独立可管理的模型条目用文本文件记录图像编码器与 IP-Adapter 的配套关系从而在节点执行时自动选择正确的编码器。CLIP Vision 图像编码器diffusers 格式的目录结构IP-Adapter 本身不直接处理原始图片它依赖一个 CLIP Vision 模型把输入图像编码为视觉嵌入image embeddings。InvokeAI 将这类编码器按diffusers格式组织期望的目录结构为ip_adapter_sd_image_encoder/ ├── config.json └── model.safetensorsconfig.jsondiffusers 标准配置文件描述模型结构CLIPVisionModelWithProjection等model.safetensors编码器权重使用 safetensors 格式存储。在源码中编码器通过CLIPVisionModelWithProjection加载并配合CLIPImageProcessor完成图像预处理见 ip_adapter.pyget_image_embeds()先调用CLIPImageProcessor得到pixel_values再经编码器输出image_embeds。SD1.5 与 SDXL 两代模型使用不同的编码器编码器模型对应 CLIP ViT 变体用途InvokeAI/ip_adapter_sd_image_encoderCLIP-ViT-H-14CLIP-ViT-H-14-laion2B-s32B-b79KSD1.5 系列 IP-AdapterInvokeAI/ip_adapter_sdxl_image_encoderCLIP-ViT-bigG-14CLIP-ViT-bigG-14-laion2B-39B-b160kSDXL 系列 IP-Adapter这两个内置starter模型在 invokeai/backend/model_manager/starter_models.py 中注册baseBaseModelType.Any、typeModelType.CLIPVision意味着它们不绑定特定的扩散模型基座可被任意 SD1.5/SDXL IP-Adapter 复用。IP-Adapter 权重InvokeAI 格式的目录结构IP-Adapter 模型本体在 InvokeAI 格式下是一个目录其中恰好包含两个文件image_encoder.txt纯文本写入与该 IP-Adapter 配套的 CLIP Vision 编码器模型标识符model identifier即上表中的源 IDip_adapter.binIP-Adapter 权重文件PyTorch 序列化格式。标准目录结构示例ip_adapter_sd15/ ├── image_encoder.txt └── ip_adapter.bin这段结构被 模型配置 中的探测逻辑严格校验IPAdapter_InvokeAI_Config_Base.from_model_on_disk()会检查目录存在、ip_adapter.bin权重文件存在、image_encoder.txt元数据文件存在任何一个缺失都会抛出NotAMatchError该目录不会被识别为 InvokeAI 格式的 IP-Adapter 模型。image_encoder.txt中的标识符在实际推理时被读取并解析在 ip_adapter.py 推理节点 中invoke()首先通过模型配置取出image_encoder_model_id即image_encoder.txt的内容拆分出模型名后调用get_clip_image_encoder()在本地模型中查找对应ModelType.CLIPVision条目若尚未安装则调用installer.heuristic_import()自动下载最多等待 600 秒。也就是说只要按规范放置好两个文件InvokeAI 就能在节点执行时自动补齐配套编码器。为什么权重保存在.bin而不是.safetensors这是该 README 中一个专门解释过的设计取舍ip_adapter.bin内的权重存储为嵌套 dictnested dict结构safetensors不支持这种结构。虽然可以通过拆分为多个文件来解决但当前选择与官方h94/IP-Adapter仓库的 checkpoint 结构保持一致。从 加载源码 可以印证这一点load_ip_adapter_tensors()对.safetensors后缀路径使用safetensors.torch.load_file()对目录路径则直接torch.load(ip_adapter_diffusers_checkpoint_path / ip_adapter.bin, map_locationcpu)。加载后按前缀把键拆分为ip_adapter、image_proj、adapter_modules、image_proj_model等命名空间后两者用于兼容 noobai-mark-ipa 类模型的额外模块遇到未知键则抛出RuntimeError。需要说明的是这一限制仅针对官方风格的嵌套结构。仓库同时兼容Checkpoint 格式单个.safetensors文件键以image_proj.、ip_adapter.或ip_adapter_proj_model.开头见 IPAdapter_Checkpoint_Config_Base。此外 FLUX 的 XLabs IP-Adapter 也以 checkpoint 形式加载flux.py 中的 FluxIpAdapterModel经infer_xlabs_ip_adapter_params_from_state_dict()推断参数后构建XlabsIpAdapterFlux。架构自动识别从权重形状推断模型类别InvokeAI 加载 IP-Adapter 时并不依赖用户在目录里填写架构类型而是通过权重张量形状自动推断。核心函数是 build_ip_adapter()判定逻辑如下image_proj中存在proj.weight→ 基础版IPAdapter使用ImageProjModel单层线性投影 LayerNorm将 CLIP 嵌入投影为 4 个 cross-attention tokenimage_proj中存在proj_in.weight→IPAdapterPlus / IPAdapterPlusXL使用Resampler即 Perceiver 重采样器。此时读取ip_adapter中1.to_k_ip.weight的最后一维作为 cross-attention 维度768 → SD1.5 版 Plus2048 → SDXL 版 Plus其他值报错image_proj中存在proj.0.weight→IPAdapterFull使用 MLP 投影即 Plus 的 full-feature 变体都不匹配 → 抛出ValueError提示无法识别的架构。模型配置层使用了完全一致的判定标准在 ip_adapter.py 配置 中cross_attention_dim为 768/1024/2048 时分别映射到StableDiffusion1、StableDiffusion2、StableDiffusionXL基座。也就是说一个 IP-Adapter 目录只要放对两个文件其「是什么架构、适配哪个基座、该配哪个编码器」全部由 InvokeAI 自动探测得出。三种图像投影架构在源码中对应关系清晰架构类投影模型特征粒度IPAdapterImageProjModelLinearLayerNorm全局图像嵌入global featureIPAdapterPlusResamplerPerceiverdepth4, heads12细粒度特征fine-grainedSD1.5IPAdapterPlusXLResamplerPerceiverdepth4, heads20细粒度特征SDXLIPAdapterFullMLPProjModelLinear-GELU-Linear-LayerNormPlus 的 full-feature 变体Resampler实现位于 resampler.py以可学习的latents作为查询通过PerceiverAttention与FeedForward的残差堆叠把图像特征压缩为固定数量的查询 tokenfrom_state_dict()会从张量形状反推dim、num_queries、embedding_dim、output_dim等超参数。而每个 attention processor 的可插拔权重to_k_ip/to_v_ip则由 ip_attention_weights.py 中的IPAttentionWeights按索引组织成ModuleDict供扩散阶段注入。推理节点与目标块选择method 参数IP-Adapter 在 InvokeAI 中作为一个 conditioning 节点IPAdapterInvocation暴露给用户关键输入包括字段默认值说明image—IP-Adapter 图像提示可为单张或图像列表ip_adapter_model—要使用的 IP-Adapter 模型clip_vision_modelViT-HCLIP Vision 模型可选ViT-H/ViT-G/ViT-L对 checkpoint 格式模型为必选项weight1施加给 IP-Adapter 的权重须通过validate_weights校验methodfull应用方式full/style/composition/style_strong/style_precisebegin_step_percent/end_step_percent0/1IP-Adapter 生效的步数区间占总步数比例0–1maskNone可选 bool mask限制该 IP-Adapter 作用的区域其中method直接决定注入哪些 attention 块target_blocksstyleSD1.5 注入up_blocks.1SDXL 注入up_blocks.0.attentions.1只影响风格compositionSD1.5 注入down_blocks.2与mid_blockSDXL 注入down_blocks.2.attentions.1偏重构图style_strongSD1.5 覆盖 5 个 blockSDXL 覆盖 17 个 attention 位置风格施加最强style_precise介于两者之间full注入全部 block[block]默认行为。这些目标块列表的完整定义见 ip_adapter.py。对于 InvokeAI 格式的模型节点直接使用image_encoder.txt指定的配套编码器对于 checkpoint 格式则根据clip_vision_model从CLIP_VISION_MODEL_MAPip_adapter.py选择对应的 starter 编码器。官方托管模型清单InvokeAI 为每种架构托管了开箱即用的模型对应 README 中的 InvokeAI Hosted IP-Adapters 一节与上文两类模型一一对应图像编码器InvokeAI/ip_adapter_sd_image_encoderViT-H、InvokeAI/ip_adapter_sdxl_image_encoderViT-GIP-AdapterSD1.5InvokeAI/ip_adapter_sd15、InvokeAI/ip_adapter_plus_sd15、InvokeAI/ip_adapter_plus_face_sd15IP-AdapterSDXLInvokeAI/ip_adapter_sdxl、InvokeAI/ip_adapter_sdxl_vit_h、InvokeAI/ip-adapter-plus_sdxl_vit-h。在 InvokeAI 中使用 IP-Adapter 的完整流程综合以上规范与源码可以整理出一条完整的实战链路导入模型将编码器目录config.jsonmodel.safetensors与 IP-Adapter 目录image_encoder.txtip_adapter.bin放入模型根目录InvokeAI 的模型探测会依据 configs/ip_adapter.py 的规则自动识别为ModelType.IPAdapterInvokeAI 或 Checkpoint 格式并确定基座类型。若采用 checkpoint 单文件格式也可直接导入单个.safetensors。加载当节点首次使用该模型时注册在 model_loaders/ip_adapter.py 的IPAdapterInvokeAILoader同时注册了ModelFormat.InvokeAI与ModelFormat.Checkpoint两种格式调用build_ip_adapter()完成架构识别与权重装载。配套编码器推理节点读取image_encoder.txt定位配套 CLIP Vision 编码器未安装时自动下载安装。图像提示在 WebUI 工作流中连接 IP-Adapter 节点设置参考图像、weight、method、begin_step_percent/end_step_percent与可选mask即可在 SD1.5/SDXL 模型上实现风格迁移、构图控制、人脸特征保持等图像条件化生成。需要注意的边界条件image_encoder.txt与ip_adapter.bin两个文件缺一不可探测与校验逻辑会直接拒绝.bin格式仅限 InvokeAI 官方托管及同构模型使用其他来源模型建议使用 checkpoint.safetensors格式导入不同基座SD1.5/SD2/SDXL/FLUX的 IP-Adapter 不可混用需匹配对应主模型的base类型。小结InvokeAI 的 IP-Adapter 模型格式规范是一套「目录约定 元数据旁路 自动探测」的工程化方案用两个固定文件名image_encoder.txt与ip_adapter.bin把「配套关系」和「权重」显式化用张量形状推断架构与基座再借助模型注册表与自动下载机制实现「导入即用」。理解这套格式不仅有助于手工整理第三方 IP-Adapter 模型也能更清晰地把握 InvokeAI 从模型探测、加载到节点注入的完整链路。【免费下载链接】InvokeAIInvoke is a leading creative engine for Stable Diffusion models, empowering professionals, artists, and enthusiasts to generate and create visual media using the latest AI-driven technologies. The solution offers an industry leading WebUI, and serves as the foundation for multiple commercial products.项目地址: https://gitcode.com/GitHub_Trending/in/InvokeAI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考