自建AI出图平台存储选型实战：从NAS到iSCSI企业级存储的完整方案

1. 从“排队出图”到“自建平台”：这个项目到底解决了什么问题

先说说我自己的情况。工作室从去年开始转向AI商业出图，主要接电商场景、游戏原画初稿、还有短视频的配图需求。最开始图省事，直接用市面上的在线AI绘图服务，结果越用越难受：高峰期排队半小时起步，企业版账号一个月大几百上千块钱，出的图还不能商用，版权归属模模糊糊。最离谱的一次，客户临时要一套“凌晨海面月光+赛博霓虹感”的系列图，我在线平台试了十几遍，风格就是锁不住，然后还碰上平台晚上维护，直接傻眼。

后来想明白了：想去平台化、控制成本、保证风格一致性，就得自己搭一套AI生成图片平台。但这个事情吧，真正干起来才体会到，难点根本不在GPU算力够不够，也不在模型调参有多玄学，而是一个特别容易被低估的环节——存储。

为什么这么说？我给你算一笔账。工作室当时是两台主力机器，每台双卡4090，跑SD基础模型加微调LoRA，单张1024x1024的图出图时间大概3到5秒。听起来不慢，对吧？但如果我们要求平台“每分钟产出60张大图”，同时有好几个任务队列在跑，问题就出现了：模型文件加载要读存储，LoRA权重要读存储，生成结果要写回存储，如果再加上工作流的中间过程图、预览图、用户上传的参考图，整个I/O压力是成倍往上翻的。

那段时间我们用本地硬盘，一开始是单机直连NVMe，速度没问题，但只要两台机器并行跑就开始乱套——A机器写完了，B机器读不到，因为文件根本没到共享层；后来换成一台老的群晖做SMB共享，又出现更恶心的状况：高并发写入时SMBD进程CPU飙到100%，出图速度直接从每分钟50张跌到20张。所以这个项目的核心命题，从来不是“模型怎么调”，而是“怎么把每分钟60张大图的吞吐需求，平稳地塞进一套多人协作、多机并行的系统里”。

本文我不会去教你Stable Diffusion的LoRA训练教程，而是把整个自建AI出图平台从0到1的完整过程，尤其是存储选型和落地的部分，原原本本拆给你看：怎么定需求、怎么选存储设备、怎么搭架构、怎么调优，以及踩过的那些坑。如果你也在规划类似的工作室级AI平台，这篇应该能帮你少走不少弯路。

2. 需求拆解：60张/分钟这个数字背后，藏着哪些不直观的坑

2.1 先算清楚账：一张1024的大图，到底吃掉多少IO

很多人在规划自建平台的时候，第一反应是先看GPU，看显存，看算力，存储往往是最后才想的。但实际跑起来你会发现，存储带宽不够，GPU就在空转，这跟食堂出菜太慢、厨师技术再好也白搭是一个道理。

咱们先做一道小学数学题。假设目标是每分钟60张大图，也就是每秒1张。单张1024x1024的RGB PNG图片，体积大概在5到8MB之间，我们按6MB算，那图片文件本身的写入带宽需求就是：

• 6MB × 60张 = 360MB/分钟
• 360MB ÷ 60秒 = 6MB/秒

单纯看这个数字，任何一块普通机械硬盘都能扛，U盘都够了。但真实场景根本不是这么简单。首先，SD生成过程中不是只写最终结果图，还要写一堆中间过程文件——比如潜空间预览图、各阶段的采样结果、ControlNet预处理图，这些杂七杂八的可能有最终成品图的3到5倍。其次，模型文件动辄几个GB，从存储加载到内存时，存储读取速度直接决定模型切换耗时。如果你有多个模型轮流切换，模型读取慢，GPU就得闲下来干等。

更隐蔽的是小文件风暴。AI出图平台不只是生成图片，还有大量的元数据信息、任务状态JSON、缩略图、预览图，这些文件每个只有几十KB到几百KB，数量却极其庞大。你在本地SSD上写入几百个小文件可能感觉不到什么，但丢到共享存储上，如果设备的随机I/O能力不行，小文件写入直接把整个存储系统拖垮。我们之前用老群晖就遇到过这种状况——照片备份这种大文件传输没问题，但一旦异步任务同时写几百个预览图，整个SMB服务的响应时间直接飙升到几十秒。

所以，“每分钟60张”这个目标换算过来，对存储的真实要求是：

• 持续顺序写入带宽：建议不低于200MB/s，留出余量应对峰值
• 随机小文件I/O能力：越高越好，因为每天可能有数万个小文件写入
• 多机并发支持：至少要同时支撑4到6台工作机上并发跑任务
• 容量规划：保存最终图+模型库+过程文件，建议至少预留8TB起步，后期可扩容

2.2 单机直连、老NAS、还是专业存储？三种方案的取舍

我前后用过三种存储方案，直接说结论：单机直连适合一个人玩玩，老NAS撑不住中高并发，专业存储才是工作室级平台的底线。

方案一：单机直连NVMe。速度快是快，但问题是数据孤岛，A机器生成的文件B机器访问不到。你要么靠人肉拷贝，要么靠同步软件，一旦任务并行起来，文件冲突和版本混乱能把人逼疯。如果工作室只有一台机器出图，这个方案勉强能用，但谈不上“平台”。

方案二：传统NAS走SMB共享。这是很多小工作室的第一步，我们也是。部署简单，成本低，但问题在于大部分民用级NAS的硬件设计初衷是文件共享，而不是高并发随机写入。我实测过，当并发任务超过三个队列同时写图，加上模型加载读取，NAS的CPU占用直接飙到80%~90%，单次I/O延迟从几毫秒膨胀到几百毫秒甚至秒级。表现就是出图任务时快时慢，完全不可控。

方案三：工作流级存储，比如这次主角Infortrend普安的KS系列。它的定位不是“家里的文件共享盒子”，而是“ 小型工作组的存储底座”，硬件上用的是专门的存储控制器和缓存，走iSCSI协议直接给服务器提供块存储。跟NAS那种“用普通Linux攒一台机器然后装Samba”的思路完全不同。我后面会详细展开为什么这个区别如此关键。

2.3 自己搭平台，和“装个软件就能出图”完全是两码事

再补充一个自我认知的坑。很多人觉得自建AI出图平台，就是把Stable Diffusion WebUI装到服务器上，然后浏览器打开就能用。其实那只是“装了个软件”，离“平台”还很远。

真正的工作室级AI出图平台，至少需要包含几个模块：任务队列调度、多机并行执行、统一的模型管理、风格模板沉淀、用户/权限控制、以及最后的成品归档和交付。你光想想这几个模块之间怎么配合，就知道存储在这里面不只是“存文件”这么简单，它承担的是整个流水线的数据中枢。这和工厂里的传送带一个道理，传送带卡顿，产线上每个环节都得停下来等。

这也是我为什么最后选了Infortrend KS存储的核心原因——单纯追求性能峰值的话，高速网络+NVMе 自组方案也能跑，但稳定性、多机共享、集中管理这些“平台级”的需求，专业存储比DIY方案靠谱得多。

3. 为什么是Infortrend普安KS存储：从“能用”到“够用且稳”的选型逻辑

3.1 KS存储到底是什么定位，和消费级NAS有什么区别

Infortrend普安这个牌子，国内知名度不算高，但在存储圈子里属于老牌厂商了，做了三十多年企业级存储。它的产品线覆盖中小型到大型数据中心，而KS这个系列，定位就是小工作室、中小企业、边缘计算节点这一档，属于“入门级企业存储”。价格上比纯企业级中端存储低不少，但硬件架构跟民品NAS是完全两条路线。

我拿KS和群晖/威联通做个对比你就明白了：

最核心的区别在于，KS是块存储为主，NAS是文件存储为主。你可以把NAS理解成一个“网络硬盘”，提供的是文件服务；而KS通过iSCSI给你的服务器提供的是“一块远程硬盘”，服务器上看到的就是一个本地磁盘，直接格式化文件系统来用。

为什么这对AI出图平台很重要？因为AI工作流的很多操作，尤其是多个任务同时写文件时，是小块随机写入，文件协议和块协议在这个场景下的效率差距非常大。iSCSI块存储把底层的I/O调度交给存储端控制器处理，延迟和稳定性都更好。而SMB文件协议还得再走一层文件系统解析，开销天然就大。

3.2 KS系列有哪些硬实力，我实测下来的真实数据

我这次用的是KS的入门级型号，配置为8盘位，装上8块4TB企业级SATA SSD。说几个我实测比较关键的数据：

• 顺序读取：走10GbE网卡，单卷顺序读能跑到900MB/s以上，接近万兆网卡的理论上限
• 顺序写入：同样万兆网络下，稳定在700~800MB/s。这比我们的出图需求高出不少，冗余充分
• 4K随机写入：64队列深度下能到1.5万IOPS以上，这个指标是消费级NAS很难做到的，正好应对我们小文件风暴的痛点
• 双控制器架构：我这是单控版本，高配版本可以上双控，一个控制器挂了另一个自动接管，对7×24小时跑批量任务的平台来说很关键

补充一个细节：KS支持把SSD和HDD混插，用SSD做缓存层，磁盘阵列做大容量存储层。我当时预算有限没上混合方案，如果后续容量吃紧，可以考虑用大容量HDD搭配SSD缓存，性价比会更高。但对AI场景来说，全SSD的方案体验是最好的，毕竟出图过程中时不时的模型加载，如果读一个几个GB的大文件要等几秒钟，体验会非常割裂。

3.3 预算与性能的平衡：为什么“便宜大碗”的DIY方案不选

你可能想问了，既然高速网络+自组存储服务器也行，为什么非得买成品设备？我的看法是：如果只是自己折腾出图，DIY完全没问题；但如果是给工作室做生产系统，稳定性和售后比那点差价重要得多。

我见过太多DIY存储翻车的案例了。你自己配一台Xeon服务器，装TrueNAS或Unraid，性能可能跑得不错，但硬件兼容性问题、RAID卡掉盘、固件Bug导致的阵列重建失败，这些坑随便踩一个，可能就是好几个小时甚至一天的停工。工作室一天的出图工作量卡在存储上，损失可比省下的钱多多了。

Infortrend这个品牌在存储圈子里口碑相对稳，KS系列提供三年硬件质保和固件更新，我用了这段时间，固件升级过一次，在线执行没有重启，这个稳定性和售后体验，DIY方案是给不了的。

注意：如果你也是小团队起步，建议直接跳过消费级NAS，至少从入门级企业存储开始。有些钱看着能省，后面都会变成运维成本和时间成本找补回来。

4. 整体架构与硬件配置：从零搭建一套AI出图平台的实战清单

4.1 系统拓扑：服务器、存储、网络怎么连

先说我最终跑通的整体架构长什么样，再解释每个模块为什么这样放。

• 出图计算节点：2台主力机器，每台配置2张RTX 4090 24GB显卡，CPU是Intel i7-13700K，内存128GB，系统盘是1TB NVMe SSD
• 存储节点：Infortrend KS存储，8盘位，全SATA SSD，配置为RAID 6，总可用容量约24TB
• 网络互联：存储和计算节点通过一台万兆交换机连接，网线使用Cat6a屏蔽线，服务器端加装双口万兆网卡
• 出图软件栈：ComfyUI作为工作流引擎，配合自研Python任务调度脚本，将所有任务队列化后分发到各计算节点

拓扑大致就是这样一个星型结构：

[用户提交任务] → [调度服务器（跑Python脚本）] → [计算节点A/B（ComfyUI worker）] ↓ ↑ [Infortrend KS存储（iSCSI共享，存模型/图片/中间文件）]

第一眼看过去，存储的位置特别关键，它同时要给调度脚本、计算节点、归档目录提供服务。模型文件放在共享存储上，所有机器都能读，那任何一台节点都可以加载任意模型，不会再出现“这台机器没下这个模型”的尴尬。生成的结果直接写入共享目录，业务人员在自己的终端上立刻就能看到，不需要手动同步。

4.2 为什么用ComfyUI而不是WebUI作为工作流引擎

很多人纠结Stable Diffusion WebUI和ComfyUI哪个好用，我直接说结论：如果是单人、少量、偏手动地出图，WebUI够用；如果要批量、流程化、可复现地出图，必须上ComfyUI。

ComfyUI的核心优势在于它的“图流”工作方式。你可以把整个出图流程当成一个管道：加载模型→输入提示词→设置采样器→通过ControlNet调节姿势→VAE解码→保存图片。每个环节都是一个节点，节点之间的连接关系保存为JSON文件，这意味着工作流的复现变得极其简单。换一批图、换一个客户需求，只需要调整几个节点的参数，而不是重新操作一遍页面。

这个能力对批量出图至关重要。比如你接了客户的需求——“50张不同角度的产品图，背景统一用暗色调，光线从左上方打过来”，你只需要把50个不同的提示词丢进调度脚本里，剩下的全部自动化。ComfyUI的API模式支持通过HTTP请求直接提交任务，我用Python写了一个简单的队列脚本，轮询任务数据库，有新的任务就调用API分发到空闲的GPU节点上，这套链路测下来相当稳定。

4.3 服务器端和存储端的网络及硬件配置清单

硬件配置这块，我列一下最终的详细清单。不是让你照着买，而是提供一个参考样板，你把这里的思路替换成自己手里的设备就行。

计算节点配置（2台相同）：

• GPU：2× NVIDIA RTX 4090 24GB
• CPU：Intel Core i7-13700K
• 内存：128GB DDR5
• 系统盘：1TB Samsung 990 Pro NVMe
• 存储网卡：Intel X710-DA2双口万兆光口网卡
• 工作流：ComfyUI（Windows 11 + Python 3.11 + CUDA 12.1）

存储节点配置：

• 设备：Infortrend普安KS系列入门款（具体型号看你的盘位数需求）
• 硬盘：8× 4TB企业级SATA SSD（西部数据/三星均可）
• RAID级别：RAID 6（容许两块盘同时故障）
• 网络接口：板载4个千兆口+2个万兆光口，我用了其中1个万兆口连核心交换机
• 协议：iSCSI，划分两个LUN（一个存模型库，一个存输出图片/中间文件）

网络设备：

• 核心交换：TP-Link ST1008F 8口万兆交换机
• 服务器端：每台服务器加装双口万兆网卡，一张接存储vLAN，一张接业务vLAN

这里有个经验想分享：AI出图平台里，网络带宽是最容易被人忽略的瓶颈。很多工作室设备买齐了，结果用千兆网线连存储和服务器，那出图速度直接被网卡卡脖子。一块万兆网卡也没多少钱，但传输速度是千兆的10倍，这个钱千万别省。

4.4 容量规划：我的最终存储空间分配方案

容量方面的考虑，很多人一开始只想着“存图片能存多久”，忽略了模型文件也在快速增长。我的分配方案是这样的：

• 模型库：SD 1.5、SDXL、若干微调LoRA和ControlNet模型，总共约120GB，放在独立的LUN里，方便统一管理
• 出图输出目录：成品图片和过程文件，一个月的产出大约在2TB左右，按一年规划需要预留25TB
• 任务中间文件：为了防止任务异常中断导致前面步骤白跑，我开启了ComfyUI的临时文件保留功能，这个过程文件约占总量的20%

全部算下来，我最终做的RAID 6方案（8块4TB，可用约24TB），大概可以支撑8到10个月的图片归档量，到时候再通过迁移策略把早期成品转存到冷备设备上即可。

提示：如果你前期摸不准容量需求，宁可买大不买小。存储设备加硬盘比前期一步到位要贵得多，而且涉及的迁移、重新分区、业务中断，远远超过硬盘本身的差价。

5. 实操过程：从零配置Infortrend KS存储，到AI出图全链路打通

5.1 存储设备初始化：创建存储池和iSCSI LUN的完整步骤

这部分是本次项目里最零碎但最关键的环节。我尽量把步骤写全，避免你边看手册边猜。

第一步：管理后台初始化。

KS存储有一个Web管理界面，通过设备自带的管理网口，默认IP访问即可。初始账户名和密码，在设备贴纸标签上，首次登录后强制修改。登录后建议先把系统时间、邮件告警（出故障时发邮件提醒）和SNMP监控配上，这些基础设置决定了后续维护的省心程度。

第二步：创建存储池（RAID组）。

在管理界面进入“存储池”菜单，点“创建”，系统会弹出选择硬盘的窗口。这里要注意：不要盲目选“自动”，尤其是对性能有要求的时候，建议手动划分。

• 我选择的是RAID 6模式，因为8块盘RAID 6允许坏两块，对生产环境更稳妥
• 如果数据没那么重要，也可以选RAID 5或者RAID 10，前者减少空间浪费，后者提升速度，但安全性均不如RAID 6
• 系统会让选择“存储池的初始化方式”，我选了后台初始化，即不需要停机等待，可以边建卷边用，前期数据不多时完全可行

第三步：创建LUN（逻辑单元号）。

在“Logical Volume / LUN”菜单下，新建LUN，然后把这个LUN映射到存储池。LUN大小根据你的规划填，但要记住：LUN是“远程磁盘”的概念，服务器格式化后才会生成文件系统。我创建了两个LUN：

• LUN1：1TB，用于模型库
• LUN2：剩余空间，用于图片输出和中间文件

第四步：配置iSCSI Target并映射主机。

这一步是把LUN“发布”到网络上，让指定的服务器能看到它。在“Target / Portal”配置里创建一个iSCSI Target，然后添加允许访问的发起方（即服务器的iSCSI Initiator名称）。Windows服务器在“iSCSI发起程序”里能看到自己的IQN，直接把这个IQN填到KS的白名单里即可。

注意：生产环境切记开启CHAP认证，设置账号密码。不设白名单的话，你网络里所有服务器都能连到存储上，等于大门敞开。

5.2 Windows服务器端连接iSCSI盘并格式化的细节

服务器侧的操作相对简单，但有些细节容易踩坑。

1. 两台计算节点都打开“控制面板→系统和安全→管理工具→iSCSI发起程序”
2. 在“目标”标签页输入KS存储的IP地址，点“快速连接”
3. 连接成功后，进入“磁盘管理”，找到新出现的未分配磁盘（注意别选错，容量和型号能识别时最稳）
4. 右键初始化磁盘，选择GPT分区表，然后新建卷。

我还是按两个LUN的方式去挂载：

• 模型库盘符：M（Model首字母）
• 图片输出盘符：O（Output首字母）

Windows格式化时建议选NTFS，分配单元大小别用默认的4096，我测试下来分配给64KB，处理大文件的性能会更好。这个细节很容易被忽略，但对整体I/O吞吐有一定影响。

格式化完之后，双节点都挂载同一个LUN，它看起来就像是一个本地磁盘。但注意，同一时间只允许一台服务器以“读写”模式挂载块设备。所以我的划分方式是：

• 模型库LUN：设置为“只读”挂载在主节点上，其他节点通过只读挂载访问，保证模型文件不被意外改动
• 图片输出LUN：由调度服务器挂载为“读写”，计算节点通过API把结果写回调度服务器，再由它统一写入共享存储

如果你有多台计算节点需要同时写盘，正确做法是建一个集群文件系统，或者让所有节点通过SMB/NFS访问文件共享，而不是各自直连同一个iSCSI LUN。我在项目中简化了这一点：只有调度服务器需要写盘，其他计算节点只需读写模型库和临时文件，所以这样足够了。

5.3 ComfyUI接入共享存储：模型目录和输出目录的指向方法

ComfyUI接入共享存储，核心就是告诉它模型从哪里读、结果往哪里写。这里有两种做法，一是通过环境变量指向，二是修改ComfyUI的启动参数。

我在启动脚本中这样写：

set COMFYUI_OUTPUT_DIR=O:\output set COMFYUI_MODEL_DIR=M:\models python main.py --output-directory %COMFYUI_OUTPUT_DIR% --model-directory %COMFYUI_MODEL_DIR%

注意，ComfyUI支持这两个参数，WebUI不一定，所以用ComfyUI在存储对接上会更灵活。改完之后重新启动服务，原本默认写到本地磁盘的模型加载和图片保存，就全部走共享存储了。

还需要在ComfyUI配置文件中修改一个关键项：max_upload_size，在user.yaml或启动参数里调大到512MB。否则你往平台上传大参考图时，可能会被默认的100MB限制卡住。

5.4 Python调度脚本：把“每分钟60张”变成现实

“每分钟60张”这个目标和ComfyUI本身没有直接关系，它是通过调度策略实现的。我写了一个不到200行的Python脚本，核心逻辑其实很朴素：

1. 一个任务清单（可以是数据库表，也可以是一个JSON文件），记录每个出图任务的参数状态
2. 一个轮询循环，每隔几秒扫描一次任务表，把空闲的任务分发给空闲的GPU节点
3. 每个节点收到任务后调用ComfyUI的API接口，提交工作流JSON，然后轮询任务完成状态
4. 完成后把结果写入共享存储，任务状态标记为完成，再取下一个任务

这里的一个关键优化是“批处理”：ComfyUI支持在一个工作流里同时生成多张图（通过控制batch_size），但显存一次只能并行一定数量。我实测4090 24GB在1024分辨率下，batch_size=2比较稳定，3以上容易爆显存或者速度骤降。所以最终调度逻辑是：每台节点同时跑2个batch_size=2的任务，两台节点并行，那么在GPU有余量时，一分钟左右可以产出约120张，超出我们的60张目标一倍。

实际跑的过程中，我见过比较健康的状况是：平均每张1024图1.8到3秒不等，加上排队和网络传输损耗，每分钟完成60到70张是比较稳定的数字。高峰期如果任务更多，可以再加节点和存储带宽，架构上不会成为瓶颈。

6. 性能调优实录：如何把存储和GPU的配合调到最优状态

6.1 一次写入抖动引起的排查：iSCSI参数与网络巨帧调整

所有配置上来首测时，我发现一个奇怪的现象：单节点跑任务速度正常，但两节点同时跑半小时后，会周期性地出现“存储写入卡顿”，表现为单张图保存时间从不到一秒膨胀到七八秒。一开始以为是存储硬件有问题，后来排查发现是网络和iSCSI参数没做优化。

先说巨帧（Jumbo Frame）。万兆网络默认MTU是1500，但启用9000字节的巨帧后，单位时间传输的数据量大幅增加，CPU中断次数减少，文件写入效率更高。设置方法是：KS存储网口、交换机端口、服务器万兆网卡三端都要一起改MTU为9000。只要有一端没改，跨MTU的包会被分片，速度反而更慢。我调完这个，写入延迟明显改善。

再说iSCSI会话参数。Windows的iSCSI发起程序里，有一个“会话→设置→最大传输长度/最大接收长度”选项，微软默认的128KB对高性能存储来说偏小，我直接拉到2MB。另外要开启“多连接”（Multiple Connections per Session），由于我的KS只有一个万兆口接服务器，作用有限，但如果你有两张万兆网卡，这个功能可以聚合带宽。

6.2 小文件大量写入时的优化：关掉时间戳和索引服务

这是另外一个容易被忽视的坑。Windows对网络盘默认会启用“上次访问时间”更新和内容索引服务，当海量小文件频繁写入时，这两个服务会产生大量额外的I/O操作，白白消耗存储带宽。

处理方法：

1. 在盘符属性里取消勾选“除了文件属性外，还允许索引此驱动器上文件的内容”
2. 用命令行关闭NTFS时间戳更新：fsutil behavior set disablelastaccess 1
3. 关闭Windows搜索服务（Windows Search）对共享盘的索引

做完这三步，小文件的写入延迟又下降了一截。特别是第二项，很多AI出图工作流会产生大量小预览图，这步优化非常对症。

6.3 中间的坑：为什么我用SSD还是感觉慢，以及LUN对齐的常识

还有一个问题，排查起来比较隐蔽：建好iSCSI LUN并格式化后，我一开始没有做分区对齐，结果随机写入性能掉了一截。现代存储设备建议分区偏移量对齐到4KB或更高，但某些旧格式化工具的默认值可能不够理想。解决办法是：在DiskPart下面重新创建分区，或用系统自带磁盘管理工具，确保分区偏移量为4KB整数倍。

贴一条检查命令：

wmic partition get BlockSize, StartingOffset, Name, Index

StartingOffset如果能被4096整除，就是对齐的。如果不齐，建议备份数据后重新分区再做对齐，性能差距在随机小文件场景下能到15%左右，值得处理。

7. 常见问题与排查技巧：生产环境里我踩过的那些坑

7.1 模型加载太慢，GPU空转怎么办

症状：启动任务后，GPU利用率忽高忽低，任务进度条经常停在“加载模型”阶段。

原因链条：模型文件几十GB，散落在共享存储的多个目录，大文件顺序读速度如果跟不上，加载时间会拖到十几秒甚至半分钟，这个时间GPU完全在空转。

排查方法：先测存储单卷的顺序读取速度，最简单的方式是直接在共享盘上拷贝一个大文件到本地。如果实测速度低于300MB/s，优先检查网络链路（网卡速率、线缆损耗、交换机端口协商）是否真的跑在万兆，而不是协商到了千兆。

如果速度没问题，但模型加载还是慢，那大概率问题出在“首次冷加载”。ComfyUI每次启动都会重新读一遍全部模型列表，这一步会花不少时间。解决办法是：在ComfyUI配置里启用模型预载缓存，把最常用的模型在服务启动时就加载到内存或显存，后续任务切换模型就不用重新读盘。我实测下来，SDXL底模预载后，任务启动时间从20秒缩短到3秒以内。

7.2 共享盘空间不够，满盘导致任务大面积失败

我一开始没做容量告警，结果有一次任务跑到一半，整个共享盘写满，所有任务全部报“空间不足”，现场那叫一个酸爽。

后来我做了两件事：一是打开KS存储的容量监控和告警，空间使用率超过85%直接邮件+短信通知；二是在调度脚本里加了一个每5分钟查一次剩余空间的环节，低于阈值就自动暂停新任务，把已生成文件先归档到冷备盘，再恢复任务。

还要提醒一点：不要把模型库和输出目录放在同一个LUN里。模型文件是“只增不减”的，输出目录是“增减交替”的，混在一起，写满的几率成倍提升，而且做数据快照和备份都不好规划。我这个项目一开始模型和输出放在不同的LUN，后来有次临时调整，误把UpStable Diffusion的2GB临时模型丢到输出卷里没及时清理，结果那个卷就比模型卷更早告急。

7.3 双机同时写一个共享存储盘，文件冲突问题

块存储的共享盘，在多机场景下天然有冲突风险。我们一开始没有充分重视，结果出现过一次事故：调度服务器把一个模型文件更新到共享盘上，同时另一台计算节点正在读这个文件，结果读到一半文件被替换，任务直接崩溃。

解决办法我前面也提到过：同一块普通iSCSI LUN只允许一台服务器读写，其他服务器只读挂载，或者通过文件协议（SMB/NFS）访问。在我当前的架构里，调度服务器是唯一写者，计算节点都是读者，永远不会有写冲突。如果你有多台服务器都要写，建议上集群文件系统，能加层分布式锁，但配置复杂度会上去，小工作室慎用。

7.4 存储固件升级不重启的方法

KS存储的固件升级，很多人可能怕业务中断。我实测下来，KS支持在线升级，固件更新过程中不需要停机，业务基本无感。唯一需要注意的是，升级前一定先手动做一次快照，以防升级中出现意外导致数据损坏。如果设备支持双控制器，升级更安全——先升级备用控，切换主备后再升级另一个，完全无感知。

经验：无论存储设备多可靠，我强烈建议定期做快照备份。KS支持定时快照，我设置每天凌晨自动打一个快照，保留最近7个版本。这个功能对于误删文件、模型被改坏之类的意外情况，简直是后悔药。成本几乎为零，但关键时刻能救命。

8. 运行数据与收益分析：这套系统到底值不值

8.1 运行3个月的实际数据

搭建完成到现在已经跑了3个月，我统计了一些真实数据，供你参考：

• 累计生成图片：约45万张以上，日均生成量5000张左右
• 平均出图速度：单张1024x1024约2.2秒，每分钟稳定产出65~75张
• 任务失败率：各类因素综合下约1.5%（主要原因是提示词错误和模型不兼容，存储导致的失败率已经降到几乎为零）
• 存储利用率：当前使用了约18TB，占24TB的75%

对比之前在云平台上一个月将近1500元的使用费，现在自建平台包括电力、存储设备摊销，每月综合成本不到400元，而且出图量远远超出之前的上限。最核心的是，风格一致性彻底解决了——客户要的风格模板固化在工作流里之后，批量出图的统一性肉眼可见地提升了，甲方满意度高了很多。

8.2 KS存储的负载状况

在重负载下（两台计算节点同时满载跑任务），KS的控制器CPU占用率大约在40%~60%，写入带宽稳定在500MB/s左右，没有出现写延迟飙升的情况。随机小文件并发时偶尔会到80%，但从未触发过热保护或性能熔断。这套承载能力对于“分钟级60张大图”的工作室场景来说是绰绰有余的，往后就算再加两台GPU节点，存储端大概率也不是瓶颈。

8.3 可扩展的方向：从图片到视频生成

AI视频生成（比如Stable Video Diffusion这类方案）是下一步可以尝试的。视频生成的中间帧数和文件大小比图片高一个数量级，对存储带宽的需求也更大。目前KS的万兆网络和RAID 6容量的余量，对入门视频生成来说基本够用，如果后续真要跑视频批量生成，我会考虑再加一个KS扩展柜或者升级到双控制器版本，顺便把网卡聚合方案做起来。这部分等真正跑起来了再写一篇分享。

9. 写在最后：几个值得再提一嘴的经验

整个项目从立项、踩坑到稳定运行，我最有感触的一点是——做平台类的事情，硬件规划要比软件调试重要得多，而存储又是硬件规划里最容易被低估的一环。GPU性能不够你可以排队等，但存储带宽不够，所有节点都得陪跑，这种瓶颈的代价是最昂贵的。

最后分享三个我个人的小习惯：

第一，新建存储卷后，第一步就开快照和告警，不要等生产运行了才想起配置。中间态的东西永远比你想象的脆弱，数据和硬盘本身也都是消耗品。快照不占什么额外空间，但等你出问题时再想找后悔药就晚了。

第二，网络端口协商状态要定期看一眼，尤其是换过网线、重启过交换机之后。我自己就有过一次万兆口悄悄降成千兆却没注意的教训，导致出图速度慢了一半还以为是存储坏了。

第三，有任何变更操作之前，先手动做一个快照备份，再把变更操作记录下来。这块我可以负责任地说，我踩过好几次“明明改完就出问题”的坑，没有快照就只能靠日志还原，而且日志不一定完全清晰，那不是一般的痛苦。

这套架构目前跑得很顺，希望这篇分享能给准备自建AI出图平台、又对存储选型没底的朋友们提供一点参考。如果你也在规划类似的系统，或者遇到过更有意思的存储相关问题，欢迎在评论区交流，我看到了都会回复。