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

揭秘AI大模型通信机制:深入理解流式传输与数据封装逻辑

揭秘AI大模型通信机制:深入理解流式传输与数据封装逻辑

文章目录 * 前言 * 一、 核心数据传输格式详解 * 1. 请求格式 * 2. 响应格式:非流式 * 3. 响应格式:流式 * 二、 流程图分析:从输入到输出 * 1. 流程逻辑描述 * 2. 流程图 (Mermaid 代码表示) * 三、 原理架构图分析 * 1. 架构层级说明 * 2. 架构图 (Mermaid 代码表示) * 四、 关键技术原理深度解析 * 1. 为什么选择 SSE 而不是 WebSocket? * 2. Token 与数据传输的关系 * 3. 数据压缩 * 五、 总结 前言 Ai聊天工具(如ChatGPT、Claude、文心一言等)的数据传输是核心功能的基石。要深入理解其背后的机制,

UnityMCP+Claude+VSCode,构建最强AI游戏开发环境

UnityMCP+Claude+VSCode,构建最强AI游戏开发环境

* 前言 * 一、UnityMCP+Claude+VSCode,构建最强AI 游戏开发环境 * 1.1 介绍 * 1.2 使用说明及下载 * 二、VSCode配置 * 2.1 连接UnityMCP * 2.2 在VSCode中添加插件 * 2.3 Claude安装 * 2.4 VSCode MCP配置 * 2.5 使用Claude开发功能 * 三、相关问题 * 总结 前言 * 本篇文章来介绍使用 UnityMCP+Claude+VSCode,打造一个更智能、高效的游戏开发工作流。 * 借助MCP工具,Claude可以直接与Unity编辑器进行双向指令交互,开发者则可以直接使用自然语言进行Unity游戏开发。 * 这一组合充分利用了AI的代码生成、问题诊断与创意辅助能力,极大提升了Unity项目的开发效率与质量。 一、UnityMCP+Claude+

人工智能:自然语言处理在医疗健康领域的应用与实战

人工智能:自然语言处理在医疗健康领域的应用与实战

人工智能:自然语言处理在医疗健康领域的应用与实战 学习目标 💡 理解自然语言处理(NLP)在医疗健康领域的应用场景和重要性 💡 掌握医疗健康领域NLP应用的核心技术(如电子病历分析、医学文本分类、疾病预测) 💡 学会使用前沿模型(如BERT、GPT-3)进行医疗健康文本分析 💡 理解医疗健康领域的特殊挑战(如医学术语、数据隐私、数据质量) 💡 通过实战项目,开发一个电子病历分析应用 重点内容 * 医疗健康领域NLP应用的主要场景 * 核心技术(电子病历分析、医学文本分类、疾病预测) * 前沿模型(BERT、GPT-3)在医疗健康领域的使用 * 医疗健康领域的特殊挑战 * 实战项目:电子病历分析应用开发 一、医疗健康领域NLP应用的主要场景 1.1 电子病历分析 1.1.1 电子病历分析的基本概念 电子病历分析是对电子病历文本进行分析和处理的过程。在医疗健康领域,电子病历分析的主要应用场景包括: * 病历结构化:将非结构化的电子病历文本转换为结构化数据 * 病历检索:检索相关的电子病历 * 病历质量评估:

OpenClaw 实操指南 07:飞书 CLI 开源:让 AI 真正接管你的飞书全流程

OpenClaw 实操指南 07:飞书 CLI 开源:让 AI 真正接管你的飞书全流程

2026年3月28日,飞书官方开源larksuite/cli(v1.0.0),以200+命令、19个AI Agent Skills,将飞书2500+开放API封装为命令行接口,面向人类开发者与AI Agent双用户,重构办公协作的操作范式。这不仅是工具升级,更是飞书从“GUI服务人”到“GUI+CLI双态并行”的战略跃迁——GUI给人交互,CLI给AI执行,让AI真正成为办公的“执行者”而非“旁观者”。 一、飞书CLI是什么:从API到命令行的能力跃迁 1. 核心定位与架构 飞书CLI是官方开源、MIT协议、免费商用的命令行工具,核心定位是让AI Agent直接操控飞书全量数据与业务,而非仅做信息查询。其三层架构清晰划分能力边界: * Shortcuts层:高频快捷命令(如lark-cli calendar +agenda查今日日程),降低人类使用门槛。 * API Commands层:200+