模型训练变慢，不一定是计算本身出了问题。若同一批节点既要执行矩阵运算，又要清洗文本、调用 SentencePiece 分词器或解码 JPEG 图片，处理器和内存带宽就可能被预处理占用，数据供给跟不上时，加速卡也会等待。规划训练数据预处理集群与模型计算节点的协同部署，关键不是把所有工作一刀切地搬走，而是按负载特征划分任务，并验证数据能否稳定送达。
先区分计算密集型与在线轻处理
文本去重、格式校验、分词和大规模图片解码通常适合在独立的预处理节点完成。这类任务可并行运行，却会持续消耗处理器、内存及存储读写能力；与训练共享资源时，负载高峰容易互相干扰。预处理集群完成后，可将结果写成带版本信息的数据分片，供训练节点读取。
随机裁剪、轻量颜色变换等紧贴每个训练批次的操作，则可能留在计算节点更合适：数据不必为每种随机结果提前重复保存，且训练流程较简单。不过，变换过重时会拉低数据加载速度。选择应依据实际瓶颈，而不是固定规定“预处理必须外置”。
协同部署要解决的是交接与供给
训练数据预处理集群与模型计算节点的协同部署，需要同时考虑数据位置、格式和生产节奏。预处理节点可以把已完成的数据写入共享文件系统，例如 Ceph；计算节点也可把常用分片暂存到本地 NVMe SSD。共享存储便于多节点读取，本地缓存能减少重复远程读取，但会占用节点空间，也必须处理缓存失效和版本更新。
交付时保留数据集版本、分片清单、处理配置和校验结果。训练任务据此读取明确的数据版本，避免预处理配置变化后误用旧缓存。若生产速度长期低于训练消耗速度，队列会逐渐变空；若只盲目加大队列，则可能挤占内存。因此要观察数据加载等待时间、缓存命中率、存储吞吐和加速卡利用情况，并根据指标定位瓶颈。
按这个顺序落地
- 测出基线：先用现有训练任务记录每秒处理样本数、数据等待情况、处理器占用和存储读写；同时确认加速卡空闲是否与数据输入中断相对应。
- 挑出重负载：分别测量清洗、分词、解码等步骤的耗时和资源占用。把耗时长、可批量处理、结果可复用的工作优先移到预处理集群。
- 确定交付格式：将输出拆成适合并行读取的数据分片，生成清单并记录版本。选用共享文件系统或本地 NVMe 缓存时，明确容量、权限及数据更新方式。
- 小规模对照：用相同模型、数据和训练配置比较拆分前后的样本吞吐与等待时间。若计算节点资源争抢减少、训练输入更连续，再逐步扩大；若存储成为新瓶颈，应先调整分片和缓存，而非继续增加预处理节点。
别忽略背压和例外情况
预处理速度超过存储写入能力时，生产端应能暂停或降低并行度，这种背压可避免临时结果无限堆积。相反，预处理明显落后时，可增加可并行的工作进程，但要检查共享存储是否承受得住。对于很小的数据集、轻量变换或必须依赖训练批次随机状态的操作，把任务留在计算节点可能更简单；对于处理结果可重复利用、且会持续抢占训练资源的任务，拆分通常更有价值。
归根结底，训练数据预处理集群与模型计算节点的协同部署不是追求节点完全隔离，而是让数据生产、缓存与模型消费形成可观测的交接链路。先拆出可复用的重负载，再通过对照测量确认收益，才能减少资源争抢而不把瓶颈转移到存储或网络。
常见问题
预处理节点一定要与训练节点使用同一种硬件吗？
不一定。若任务主要是分词、校验或解码，可按其处理器、内存和存储需求配置；重点是实测处理速度与训练读取能力是否匹配。
什么时候值得配置本地缓存？
当训练反复读取同一批数据，且共享存储读取成为瓶颈时，可以评估本地 NVMe 缓存。数据更新频繁或本地空间紧张时，缓存管理成本可能抵消收益。
怎样判断预处理已经影响训练？
观察训练等待数据的时间是否增加，并对照处理器占用、存储吞吐和加速卡利用率。单看加速卡利用率不足以确定原因。
分离后还需要在计算节点做数据处理吗？
可以保留轻量、依赖批次随机性的操作；应避免把耗时重、可提前完成且会长期争抢资源的步骤原样放回训练节点。
