多源语料预处理常包含解压、解析、去重、分词和格式转换，工作负载会随数据来源与批次变化；模型计算节点则更关心计算资源的持续供给。规划训练数据预处理集群与模型计算节点的协同部署，不能只看节点总数，还要检查资源是否在正确的环节可用。
1. 计算资源：避免预处理任务挤占模型负载
预处理通常偏向并行的 CPU 任务，模型训练或推理可能依赖加速器。若两类任务共用主机，CPU 核数、加速卡和内存都可能出现争用；数据转换进程即使没有使用加速器，也可能因占满 CPU 而拖慢模型的数据供给或请求处理。
按任务类型设资源请求与上限，并优先将高峰期的批量数据清洗安排到独立节点或低负载时段。需要共机时，先用代表性任务做并发测试，再逐步增加并行度；观察模型等待输入的时间、处理吞吐和 CPU 使用率，而不是只看加速器利用率。
2. 内存：控制并发与单任务占用
解析大型 JSON、合并小文件或执行全局去重，可能产生远大于压缩文件的中间数据。并发数过高时，容易出现内存回收、进程被系统终止或任务反复重试。Apache Spark 等分布式处理框架可以调节执行并行度，但参数应依据数据分区大小和实际峰值内存确定。
先抽取有代表性的样本，记录每个任务的峰值内存，再以单机可用内存扣除系统和常驻服务后，估算安全并发数。检查是否启用了不必要的全量缓存；若任务可按分区处理，优先采用分批读写，避免将全部语料一次载入内存。
3. 存储：区分吞吐、延迟与临时空间
对象存储适合保存大规模原始语料和处理结果，但大量小文件可能增加列举、打开和请求开销；NVMe本地盘适合临时排序、缓存和中间结果，却不应被误当作长期唯一副本。Parquet 等列式格式有利于按列读取分析数据，但具体收益取决于查询方式、压缩设置和文件大小。
部署前分别测量顺序读写、随机读写和小文件访问表现，并核对临时目录容量、清理策略及故障后的数据去向。训练数据预处理集群与模型计算节点的协同部署，应明确哪些数据留在共享存储、哪些允许缓存到本地，避免预处理结束后临时文件占满系统盘。
4. 网络：避免数据搬运成为隐性瓶颈
语料从存储端传到预处理节点，再送往模型计算节点，会消耗网络带宽；跨机架或跨可用区传输还可能增加延迟。只增加处理节点，不一定能提高整体吞吐：如果存储出口或网络链路已饱和，新增并发只会造成排队。
先确认存储与计算节点的网络路径、共享链路及带宽限制，再在实际批次中观察传输速率、重传和任务等待时间。尽可能让计算靠近数据存放位置；只有在网络余量充足、下游确实能消费时，才提高数据预取和并行传输规模。
5. 调度：把优先级和资源边界写清楚
批处理任务适合排队运行，面向在线服务的模型节点则可能需要稳定的资源余量。若所有任务使用同一优先级，临时的大批预处理作业可能延迟更紧急的计算任务；若隔离过度，也可能导致资源闲置。
使用集群调度器时，为任务设置资源请求、上限、队列或优先级，并明确抢占规则。先区分可中断的批处理与需要连续运行的任务，再观察队列等待时间和资源空闲情况，按业务窗口调整配额。不要仅根据单次峰值扩容，应结合多个批次的负载变化判断。
6. 故障恢复：预留重试空间并验证数据一致性
预处理任务失败后重跑，可能造成重复输出、临时数据堆积或对共享存储形成突发压力。节点重启、源文件不完整和磁盘空间耗尽都是需要考虑的故障场景。断点续跑是否安全，取决于任务是否记录已完成分区，以及输出是否支持幂等写入。
上线前用小批次验证失败重试、临时文件清理和结果校验；为日志、中间文件和最终结果设置不同保留策略。按实际恢复时间规划容量余量，余量大小需结合故障概率、重跑成本和存储配额确定，不宜套用固定比例。
部署前的核对顺序
- 按数据源选取代表性样本，测出解析、清洗和写出的资源峰值。
- 核实计算、内存、存储与网络的瓶颈位置，并区分共享资源和独占资源。
- 设置任务并发、资源上限、调度优先级及临时数据清理规则。
- 用真实批次验证吞吐、模型等待情况与故障重试，再逐步提高负载。
归根结底，训练数据预处理集群与模型计算节点的协同部署，重点不是把所有资源简单合并，而是让数据处理速度、存储供给和模型侧需求相匹配。先定位瓶颈，再按实测调整，通常比盲目增加节点更稳妥。
常见问题
预处理集群是否必须独立部署？
不一定。负载可预测、资源隔离有效时可以共用；峰值冲突明显或故障影响范围较大时，独立部署更容易控制影响。
先扩计算还是先扩存储？
先确认瓶颈。若处理节点经常等待读写，优先检查存储吞吐和网络；若存储与网络有余量而 CPU 长期饱和，再评估增加计算并行度。
如何判断协同部署是否有效？
同时观察预处理完成时间、模型侧等待输入的情况、资源利用与队列等待；在相同数据和任务配置下对比，避免只凭单项利用率判断。
