企业官网建设流程全解析

最近整理机器的时候发现一个挺有意思的事：同一个v1-5-pruned-emaonly.safetensors，在硬盘里躺了三份，加起来 12GB 还多。ComfyUI 一份，另一个用习惯了的前端一份，下载缓存里还躺着一份。固态硬盘的空间就这么被一模一样的东西白白吃掉了。这个问题其实特别常见，尤其是有多套 Stable Diffusion 工具的玩家，模型文件重复下载、重复存储，纯属浪费。

这篇内容就围绕 Stable Diffusion 与 ComfyUI 场景，分享一套让多个前端共用同一个模型文件的实操方案。核心目标就是减少重复存储，把v1-5-pruned-emaonly.safetensors这种动辄 3GB、4GB 的大文件，从“每套工具各存一份”变成“全机只存一份”。文章会覆盖软链接、硬链接、以及 ComfyUI 原生支持的路径配置这几条路线，也会把我在实际操作中踩过的坑一并写出来。适合那些硬盘空间紧张、又同时在用多个 AI 绘画工具的人参考。

1. 为什么模型文件总在“重复下载”

1.1 一个基础模型到底有多大

以标题里的v1-5-pruned-emaonly.safetensors为例，它是 Stable Diffusion 1.5 时代的经典基础模型文件。常见的 safetensors 格式、emaonly 剪枝版，文件大小通常在 3GB 到 4GB 之间；有些 fp16 版本会小一些，大约 2GB 上下，但完整版或者包含其他组件时体积会更大。

这个大小对单文件来说其实不算夸张，问题是架不住多个工具各存一份。

ComfyUI 默认会把大模型放到ComfyUI/models/checkpoints/目录下；另一个常见的 WebUI 前端则习惯放在models/Stable-diffusion/目录里。如果你还装了模型管理工具、下载缓存、或者移动硬盘里的备份，那同一个文件被复制三五份非常正常。我见过有人机器上同一份 SD1.5 基础模型出现了 6 个副本，总共占用近 20GB，而这里面绝大多数都是冗余。

1.2 占用空间只是表面问题

重复存储带来两个问题，第一个很直接：硬盘空间被白白吃掉。第二个是隐性的：你很难判断哪个副本是最新版本。有时候为了测试某个微调模型，你会对基础模型文件做覆盖或重命名，结果多个副本之间版本不一致，加载出来的效果对不上。

而且下载模型本身也费时间。一个 4GB 的文件从网盘拉下来，就算速度不错也要几分钟，多个工具重复下载等于反复消费带宽和时间。所以“共享一份模型文件”不只是省空间，还会让本地管理更清爽。

2. 共享前需要先搞清楚的几个概念

2.1 三种“共享”方式的本质区别

在动手之前，有必要把概念理清楚，否则操作时容易产生误解。常用方式有三种：符号链接（软链接）、硬链接、以及原生路径配置。

• 符号链接：相当于创建了一个“快捷方式”，指向另一个位置的真实文件或目录。删除快捷方式不影响源文件，但如果源文件被移动或删除，快捷方式会失效。
• 硬链接：不是快捷方式，而是同一个文件的另一个名字。文件系统里多个文件名指向同一个数据块，修改任何一边的内容，另一边也会变（因为本来就是同一份）。删除其中一个名字，只要还存在其他引用，数据就不会丢。
• 原生路径配置：工具主动支持读取外部目录，比如 ComfyUI 的extra_model_paths.yaml，这算是最干净的做法，连链接都不用建。

这三者各有适用场景，后面具体操作会分别给出用法。先记住一句话：符号链接适合跨分区、目录级别共享；硬链接适合同分区、单文件级别共享；原生路径配置最优雅，但需要工具支持。

2.2 硬链接和符号链接的适用边界

很多人看到硬链接能“一份空间多个入口”，就想着无脑用。但硬链接有个硬性限制：只能在同一个文件系统内创建。什么意思？就是你的 C 盘和 D 盘是两个独立分区，跨盘创建硬链接，系统直接报错。这种场景就得用符号链接，或者干脆用工具自带的路径配置。

另外，NTFS 支持硬链接和符号链接，APFS 也支持，常见的 ext4 同样支持。但 exFAT、FAT32 这类移动存储格式就比较受限，基本只能靠文件复制。所以做方案之前，先确认你放模型的那个盘是什么文件系统。

2.3 硬链接占用空间的计算误区

有一个地方特别容易让人困惑：复制一个文件过去，占用翻倍；硬链接一个文件过去，系统里多了一个文件名，但占用空间不翻倍。

查看磁盘占用时，你可能会发现ls -l看到两个文件都显示 4GB，但df -h显示磁盘剩余空间并没有因为多次硬链接而明显减少。这是因为硬链接共享同一个 inode 和数据块，文件系统只会记录一份数据。Windows 上如果看单个文件属性，同样会显示完整大小，容易误以为自己没省空间，其实磁盘的实际占用只有一份。

理解了这一点，后面看空间变化时就不会慌。

3. 实操：三条路线让同一份模型被多个前端共用

3.1 方案一：ComfyUI 原生路径共享

先说我最推荐、也最稳妥的方式：ComfyUI 自带的extra_model_paths.yaml配置。

ComfyUI 会读取一个额外的配置文件，让你把模型搜索路径扩展到任意目录。这样你既不需要移动任何原文件，也不需要创建链接，只需要在配置文件里加上外部目录的绝对路径，ComfyUI 启动时就会自动在这些路径下扫描模型。

以实际场景为例，我的所有大模型都集中放在D:\SharedModels\checkpoints这个目录。想让它被 ComfyUI 识别，只需要打开 ComfyUI 根目录下的extra_model_paths.yaml.example，把它重命名为extra_model_paths.yaml，然后按需解注释并修改：

comfyui: base_path: D:\SharedModels checkpoints: checkpoints loras: | loras vae: vae embeddings: embeddings

如果 base_path 下还有子目录，可以这样写：

comfyui: base_path: D:\SharedModels checkpoints: | checkpoints checkpoints2

改完后重启 ComfyUI，刷新节点列表，加载模型时就能在列表里看到D:\SharedModels\checkpoints下的文件了。这个方式的优点是完全不动原有目录结构，你甚至可以让 ComfyUI 同时扫描多个路径，也不影响它自带的标准目录。

注意：配置文件里目前默认可能指向的是extra_model_paths.yaml.example，记得把文件名后面的.example去掉，否则 ComfyUI 不会读取。

3.2 方案二：符号链接实现跨盘共享

如果你用的另一个前端不支持多路径扫描，那符号链接就是跨分区、跨盘共享的主力方案。

在 Windows 上，管理员模式打开命令提示符，使用mklink命令。比如你把模型集中移动到D:\SharedModels\checkpoints后，想让某个前端的 models 目录指向它，可以这样：

mklink /J "C:\WebUI\models\Stable-diffusion" "D:\SharedModels\checkpoints"

这里的/J是创建目录联接（junction），比/D符号链接更稳，在 Windows 上不需要额外开启开发者模式，兼容性也好。如果只是给单个文件创建链接，用/H创建硬链接：

mklink /H "C:\WebUI\models\Stable-diffusion\v1-5-pruned-emaonly.safetensors" "D:\SharedModels\checkpoints\v1-5-pruned-emaonly.safetensors"

在 Linux 或 macOS 上，符号链接用ln -s：

ln -s /mnt/data/shared/checkpoints/v1-5-pruned-emaonly.safetensors ~/ComfyUI/models/checkpoints/v1-5-pruned-emaonly.safetensors

软链接的思维很简单：链接文件本身不是一个真正的模型文件，只是指向真实文件的路标。前端加载模型时，系统会顺着路标找到真实数据。缺点我也提一下：如果你把源文件移走，链接就变成“断链”，前端会报加载失败。所以一旦用符号链接，就不要随意挪动源目录。

3.3 方案三：硬链接让每个前端目录里都有“真文件”

符号链接最大的问题是，有些前端对链接文件的处理不友好，或者你在网络共享目录、云同步目录中使用时，链接会被同步工具误处理。这时候硬链接反而是更稳的选择。

硬链接的核心是：在目标目录里生成一个完整的文件条目，它看起来就是普通文件，任何软件都会把它当成一个真实文件来读取。但它与源文件共享磁盘上的同一份数据块，因此不会额外占用空间。

在 Windows 上创建硬链接：

mklink /H "C:\ComfyUI\models\checkpoints\v1-5-pruned-emaonly.safetensors" "D:\SharedModels\checkpoints\v1-5-pruned-emaonly.safetensors"

在 Linux/macOS 上：

ln /data/shared/v1-5-pruned-emaonly.safetensors ~/ComfyUI/models/checkpoints/v1-5-pruned-emaonly.safetensors

注意ln不带-s就是硬链接。

硬链接的局限前面说过：只能在同一个文件系统内使用。也就是说如果你把源文件放在 D 盘，目标不能是 C 盘。但我的实际经验是，大多数人的模型目录都在同一块大容量机械盘或同一块固态盘上，这种情况硬链接非常合适。

3.4 其他模型类型也可以一并共享

大模型只是重复存储最严重的部分，其他文件一样可以共享。Lora 模型、VAE、Embedding、ControlNet 这些组件，不同前端同样各自存放一份。使用extra_model_paths.yaml时，可以把这些类型的路径都映射到同一个中心目录。

一个比较标准的共享目录结构大致是这样：

D:\SharedModels ├── checkpoints ├── loras ├── vae ├── embeddings └── controlnet

然后每套前端只需要三个动作：下载模型时统一放中心目录、配置路径映射或创建链接、定期检查有没有失效链接。这样全机只留一份文件，所有工具共用，省心很多。

4. 从零开始：一台机器让两套前端共用同一份模型

4.1 现场实操记录

下面用一个完整的场景走一遍流程。假设机器上有 ComfyUI，也有另一套 WebUI 前端，两个前端各自下载过v1-5-pruned-emaonly.safetensors，现在要把它们合并成一份。

第一步：检查分区和文件系统。在 Linux 上用df -T查看，Windows 上可以用磁盘管理或fsutil fsinfo volumeinfo。确认两个模型的当前位置在同一个物理分区上，这样能用硬链接；如果在不同分区，就要换软链接方案。

第二步：统一模型文件位置。我先在 D 盘建了中心目录D:\SharedModels\checkpoints，把源模型和另一个前端的模型都移动过去。移动完成后，原来的两个目录里不再保留副本。

第三步：配置 ComfyUI。进入 ComfyUI 根目录，编辑extra_model_paths.yaml，加入base_path为D:\SharedModels，并将 checkpoints、loras、vae 路径指向对应子目录。重启 ComfyUI，打开工作流，加载模型列表，能看到模型正常出现。

第四步：配置另一个前端。因为我用的这套前端不支持多路径扫描，所以我给它手动创建了目录软链接。在管理员命令行里执行：

mklink /J "C:\WebUI\models\Stable-diffusion" "D:\SharedModels\checkpoints"

如果你的前端只需要单个模型文件，也可以直接硬链接单文件：

mklink /H "C:\WebUI\models\Stable-diffusion\v1-5-pruned-emaonly.safetensors" "D:\SharedModels\checkpoints\v1-5-pruned-emaonly.safetensors"

第五步：启动两个前端，分别加载模型，做一个最简单的文生图测试。确认都能正常读取后，再看一下磁盘空间占用。

4.2 空间实测结果

操作之前，两个前端的模型目录里各有一份v1-5-pruned-emaonly.safetensors，大约占用 7GB 左右。操作之后，两个入口都指向同一个文件，磁盘占用约 3.5GB，省了刚好一个基础模型的体积。如果还共享了 Lora 和 VAE，节省下来的空间会更明显。

这个“入口多份、数据一份”的效果，就是本文想要达到的核心目标。

4.3 操作中的几个易错点

第一个易错点：符号链接创建时路径写错。链接命令里的目标路径必须是真实存在的绝对路径，不能写相对路径。尤其是 Windows 上的mklink，路径里如果有空格，必须用英文双引号包起来。

第二个易错点：硬链接跨盘。很多人不理解为啥ln会报 “Invalid cross-device link”，其实就是目标文件系统和源文件系统不是一个分区。这种情况别硬试，改用软链接或路径配置。

第三个易错点：修改配置文件后没有重启。ComfyUI 的extra_model_paths.yaml不是热加载的，改完必须重启进程才会生效。如果发现模型列表没变化，先重启再排查。

5. 常见问题排查与避坑经验

5.1 模型在列表中不显示怎么办

最常见的原因是配置路径不对。检查extra_model_paths.yaml里的路径是否真实存在，是否写全了目录层级。其次是文件格式问题，有些工具对模型文件的扩展名敏感，.safetensors正常，但如果你不小心把扩展名改成.ckpt，工具可能识别不出来。

如果用的是符号链接且链接失效，可以打开链接的属性看一眼“目标”是否还存在。在 Linux 里用ls -l会看到链接末尾有-> 目标路径，如果目标路径变红或不存在，就说明链接断了，重新创建即可。

5.2 硬链接一边修改另一边也变了，是正常的

这个特性容易让人误会。硬链接的两个名字共享数据块，所以你通过 A 入口覆盖了模型文件，B 入口读到的内容也会变成新文件。这是硬链接的工作机制，不是 bug。好处是多个前端始终保持版本一致，坏处是如果你只想让某一个前端用旧版本，就别用硬链接。

5.3 云同步目录下慎用符号链接

如果模型目录在网盘同步盘里，符号链接很容易被同步软件当作一个特殊的“快捷方式”或普通小文件处理，导致另一个设备上拿到的是无效链接。我实际遇到过一次，同步后链接目标在原设备上正常，但在另一台机器上因为盘符不同，整个链接直接失效。所以网盘同步场景优先用原生路径配置，或者在每台机器上单独创建链接，不要让链接文件本身参与同步。

5.4 备份模型时别只复制链接文件

这个点很多人踩过。如果你用符号链接方式共享模型，备份时只把快捷方式拷走了，源文件没拷，那备份相当于白做。硬链接相对好一些，因为文件内容就在原地，但备份工具如果不认识硬链接，也可能产生重复副本。我的做法是：备份前先解除所有链接，把真实文件单独拷贝一份，或者在备份工具里明确选择“保留硬链接结构”。

5.5 常见问题速查表

5.6 换新模型时的清理思路

共享方案用久了，会积攒失效链接。我就遇到过某次整理目录，把旧模型文件删掉之后，几个前端里留下了指向空路径的链接，启动时虽然没有大问题，但列表里慢慢堆了不少无效项。建议定期检查，把所有链接文件列出来核对一遍源文件是否存在。

Windows 上用dir /AL可以列出当前目录层的符号链接；Linux 上用find -type l。把失效的清理掉，目录就干净了。

6. 最后再分享一点个人心得

这套共享思路我实际用了大半年，最明显的收益是模型目录从 80GB 降到了 45GB 左右，省出来的空间足够放不少新模型。如果你同时用 ComfyUI 和另一套前端，我建议优先用 ComfyUI 的extra_model_paths.yaml，这个方案最接近“官方推荐”的用法。只有在前端不支持路径扩展时，才考虑软链接或硬链接。

如果用链接，记得在自己的模型目录里建一个文本文件，记录哪几个入口是链接、指向哪里。这样几个月后再回来维护时，不用对着终端猜来猜去。配合定期检查和统一的命名规范，模型再多也不会乱。

对了，还有一个小技巧：给模型做硬链接之前先计算一次哈希值，保存到本地。以后如果怀疑某个模型文件被意外修改过，重新算一遍哈希对比一下就行。尤其当多个前端共用同一份文件时，这个操作能帮你很快定位是哪一步出了问题。