LLaMA Factory操作界面微调时报disable multiprocessing.

LLaMA Factory操作界面微调时报disable multiprocessing.

LLaMA Factory操作界面微调时报disable multiprocessing

陈述问题

由于显卡性能不强,微调模型时会报以下下错误,GPU内存或系统内存不足,尤其在处理大规模数据或大模型时,子进程因内存溢出崩溃。

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "G:\project\LLaMA-Factory\src\llamafactory\data\converter.py", line 420, in align_dataset return dataset.map( ^^^^^^^^^^^^ File "C:\Python312\Lib\site-packages\datasets\arrow_dataset.py", line 557, in wrapper out: Union["Dataset", "DatasetDict"] = func(self, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Python312\Lib\site-packages\datasets\arrow_dataset.py", line 3166, in map for rank, done, content in iflatmap_unordered( File "C:\Python312\Lib\site-packages\datasets\utils\py_utils.py", line 713, in iflatmap_unordered raise RuntimeError( RuntimeError: One of the subprocesses has abruptly died during map operation.To debug the error, disable multiprocessing. 

解决思路

我们可以调整LlamaFactory 训练命令中 --preprocessing_num_workers

–preprocessing_num_workers 是 LlamaFactoryLlamaFactory(以及基于 Hugging Face 生态的大模型训练框架)中用于数据预处理阶段的核心参数,具体作用如下: 核心定义
这个参数指定了数据预处理时使用的进程 / 线程数量(这里设置为 16),用于并行处理训练数据(比如加载数据集、分词、格式化、生成
attention mask 等操作)。 具体工作机制 默认情况下,preprocessing_num_workers 为
0,意味着所有数据预处理工作都在主线程中串行执行; 设置为 16 时,框架会启动 16 个独立的 worker 进程 /
线程,同时对不同批次的数据集进行预处理,充分利用 CPU 多核资源。 实际效果 ✅ 加速数据预处理:对于大尺寸数据集(比如几万 /
几十万条样本),多 worker 并行处理能显著减少数据加载和预处理的耗时,避免训练过程中出现 “GPU 等数据” 的空闲情况; ⚠️
资源占用注意:worker 数量并非越多越好: 如果设置的数值超过你的 CPU 核心数(比如你的 CPU 只有 8 核却设为
16),会导致进程切换开销增大,反而变慢; 过多的 worker 还会占用更多内存,可能引发 OOM(内存溢出)。 适用场景
这个参数仅作用于训练前的数据预处理阶段(比如分词、数据格式化),训练过程中的计算(如前向 / 反向传播)仍由 GPU
负责,不会影响训练阶段的并行逻辑。 实用建议 推荐设置值:通常设为你的 CPU 物理核心数(比如 8 核 CPU 设为 8,16 核设为
16),或核心数的 1-2 倍; 调试阶段:如果出现数据加载报错(如 BrokenPipeError),可以先将该值设为
0(单线程)排查问题; 内存敏感场景:如果数据集样本长、内存紧张,适当降低该值(比如 8 或 4)。 总结
–preprocessing_num_workers 16 表示启用 16 个并行进程处理训练数据的预处理(分词、格式化等); 核心作用是利用多核 CPU 加速数据加载,避免 GPU 训练时等待数据; 取值需匹配 CPU
核心数,并非越大越好,否则会增加开销或导致内存不足。

解决办法

点击‘预览命令’查看命令,可以看到命令中 --preprocessing_num_workers 16 `

在这里插入图片描述

先把之前运行网页的llamafactory-cli webui的进程停了⚠️⚠️⚠️
再把命令复制到cmd执行,执行前把–preprocessing_num_workers 改小

在这里插入图片描述


看到以下界面说明已经在跑了

在这里插入图片描述


跑完之后再运行网页的llamafactory-cli webui的进程
再进到网页查看刚才的训练参数可以选择导出了

在这里插入图片描述

Read more

Linux命名管道(FIFO)通信:从原理到实操,一文搞懂跨进程通信

Linux命名管道(FIFO)通信:从原理到实操,一文搞懂跨进程通信

🔥个人主页:Cx330🌸 ❄️个人专栏:《C语言》《LeetCode刷题集》《数据结构-初阶》《C++知识分享》 《优选算法指南-必刷经典100题》《Linux操作系统》:从入门到入魔 《Git深度解析》:版本管理实战全解 🌟心向往之行必能至 🎥Cx330🌸的简介: 目录 前言: 一、先搞懂:命名管道(FIFO)是什么? 1. 命名管道的本质 2. 命名管道的核心特点 3. 命名管道与匿名管道的对比 二. 命名管道的创建方式 2.1 命令行创建(mkfifo 命令) 2.2 代码创建(mkfifo 函数) 2.3 命名管道的打开规则 三、实操实现:手搓命名管道通信 3.1 前置准备(

By Ne0inhk
Flutter 组件 injectfy 适配鸿蒙 HarmonyOS 实战:逻辑注入矩阵,构建跨模块解耦与动态依赖管理架构

Flutter 组件 injectfy 适配鸿蒙 HarmonyOS 实战:逻辑注入矩阵,构建跨模块解耦与动态依赖管理架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 injectfy 适配鸿蒙 HarmonyOS 实战:逻辑注入矩阵,构建跨模块解耦与动态依赖管理架构 前言 在鸿蒙(OpenHarmony)生态迈向超大规模应用拆分、涉及数百个独立 Feature 模块与底层硬件服务深度解耦的背景下,如何实现灵活的“控制反转(IoC)”与“依赖注入(DI)”,已成为决定应用架构可维护性的“生命线”。在鸿蒙设备这类强调模块化挂载与 HAP/HSP 动态分发的环境下,如果应用内部的组件实例依然采用强耦合的硬编码初始化,由于由于各模块间复杂的循环依赖,极易由于由于初始化顺序错乱导致应用在流转拉起时的崩溃。 我们需要一种能够实现零成本解耦、支持单例(Singleton)与工厂(Factory)模式且具备极简注册语义的依赖注入框架。 injectfy 为 Flutter 开发者引入了轻量级的对象容器管理方案。它不仅支持对底层 Service 的全局托管,更提供了灵活的注入探测机制。在适配到鸿蒙

By Ne0inhk
一文通透OpenVLA——在Prismatic VLM(SigLIP、DinoV2、Llama 2)的架构上:基于“下一个token预测技术”预测离散化动作

一文通透OpenVLA——在Prismatic VLM(SigLIP、DinoV2、Llama 2)的架构上:基于“下一个token预测技术”预测离散化动作

前言 当对机器人动作策略的预测越来越成熟稳定之后(比如ACT、比如扩散策略diffusion policy),为了让机器人可以拥有更好的泛化能力,比较典型的途径之一便是基于预训练过的大语言模型中的广泛知识,然后加一个policy head(当然,一开始背后的模型比较简单,比如有用LSTM或MLP——RoboFlamingo) 再之后,便出来了越来越多成熟稳定的专门的VLA模型,比如OpenVLA,再比如近期介绍过过的π0——用于通用机器人控制的VLA模型:一套框架控制7种机械臂(基于PaliGemma和流匹配的3B模型) 1. π0的意义在于,首次用同一套策略/算法操作不同机器人/机械臂,这种基于机器人大模型的「预训练-微调」模式,很快会越来越多(犹如此前大模型革命NLP 其次CV等各模态,目前到了robot领域),算是代表了通用机器人的核心发展方向 2. 且π0 比英伟达的HOVER早一点,当然,同时期的RDT GR2也有这个潜力的,期待这两 后续的更新 一个多月前(本文首发于25年1月),有朋友曾说,一个月内,π0 会开源来着,当时虽然觉得不太可能,但还是抱着期待,可还

By Ne0inhk