LLaMA-Factory全流程训练模型

LLaMA-Factory全流程训练模型

 

f7b2c270ae3844559da67828c8d2f9f2.jpeg

🤗本文主要讲述在docker下使用LLaMA-Factory训练推理模型。

🫡拉取镜像

首先需要启动docker,然后在终端中输入:

docker run -tid --gpus all -p 8000:8000 --name LLM -e NVIDIA_DRIVER_CAPABILITIES=compute,utility -e NVIDIA_VISIBLE_DEVICES=all --privileged=true ubuntu:20.04
  • 这个命令启动了一个 Ubuntu 20.04 容器,使用所有可用的 GPU
  • 主机的 8000 端口映射到容器的 8000 端口
  • 容器命名为 LLM,以特权模式运行容器

进入容器 

docker exec -it LLM /bin/bash

 

1ef5885b4e0748c8a10b8d7e3e31efdd.png

🥰但现在还不行,我们只将GPU映射到了docker里,还没有安装驱动。

wget https://developer.download.nvidia.com/compute/cuda/12.6.2/local_installers/cuda_12.6.2_560.35.03_linux.run

然后运行程序

sh cuda_12.6.2_560.35.03_linux.run

随后会生成一些指引,默认安装就行。

root@82c2f2b69781:/home# ls /usr/local/ | grep cuda cuda cuda-12.6 root@82c2f2b69781:/home# nvcc -V bash: nvcc: command not found
  • 这说明系统的 PATH 环境变量没有包含 /usr/local/cuda-12.6/bin
编辑环境变量 vim ~/.bashrc 加入下面两行: export PATH=/usr/local/cuda-12.6/bin:$PATH export LD_LIBRARY_PATH=/usr/local/cuda-12.6/lib64:$LD_LIBRARY_PATH 然后重新运行一下就生效了: source ~/.bashrc

 验证成功 ~

root@82c2f2b69781:/home# echo $PATH /usr/local/cuda-12.6/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 

🤗docker内安装python

docker拉取的Ubuntu20.04没有任何配置,比如wget等命令需要自己通过apt-get install 安装

Index of /ftp/python/3.10.6/ 这是python源码包的地址(3.10.6为例)

wget https://www.python.org/ftp/python/3.10.6/Python-3.10.6.tgz
tar -zxvf Python-3.10.6.tgz cd Python-3.10.6 sudo ./configure # configure 脚本会检查系统环境,并生成 Makefile 文件,以便后续的 make 命令可以正确编译源代码

🤗最后一步:

sudo make sudo make test sudo make install

💥LLaMA-Factory

💫安装

git clone --depth 1 https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e ".[torch,metrics]"

如果使用昇腾NPU的话,先设置一下环境变量:

export ASCEND_HOME_PATH=/usr/local/Ascend/ascend-toolkit/latest

 💫下载模型

git lfs install git clone https://www.modelscope.cn/Qwen/Qwen2.5-1.5B-Instruct.git

 💫我们在 LLaMA-Factory/examples下创建 train.yaml 文件,这是微调训练模型的配置文件

### model model_name_or_path: /home/Qwen/Qwen2___5-1___5B-Instruct ### method stage: sft do_train: true finetuning_type: freeze # lora_target: all dataset: alpaca_zh_demo template: qwen cutoff_len: 10240 max_samples: 1000 overwrite_cache: true preprocessing_num_workers: 16 ### output output_dir: output logging_steps: 10 save_steps: 500 plot_loss: true overwrite_output_dir: true ### train per_device_train_batch_size: 1 gradient_accumulation_steps: 2 learning_rate: 1.0e-4 num_train_epochs: 3.0 lr_scheduler_type: cosine warmup_ratio: 0.1 fp16: true ddp_timeout: 180000000 ### eval val_size: 0.1 per_device_eval_batch_size: 1 eval_strategy: steps eval_steps: 500 

💫使用vim写好后,我们使用 LLaMA-Factory/data/ alpaca_zh_demo.json这个数据集

ea3d2121e2e148bda8903f27d847e0f4.png
  •  instruction 部分描述了任务的具体指令。
  • input 部分通常包含任务所需的输入数据或信息。
  • output 部分是模型的输出。

 💫开始微调训练

llamafactory-cli train examples/train.yaml
68c34fc7986b430380b1cef3876d99d6.png

🕛️🕧️🕐️🕜️🕑️🕝️🕒️🕞️🕓️ 

ba73456fa00d459e8cfc25459fee0751.png
  • loss :模型在当前批次上的预测结果与实际标签之间的差异。
  • grad_norm:模型参数梯度的范数,反映梯度的大小,用于监控梯度爆炸或梯度消失的问题。
  • learning_rate:学习率是优化器在更新模型参数时使用的步长。
  • epoch:整个训练数据集被模型完整遍历的次数,一个 epoch 包含多个批次(batch)。
90378eaa5a0e4b4593cfc5840d124845.png

训练指标总结

***** train metrics ***** epoch = 3.0 total_flos = 2906404GF train_loss = 1.0846 train_runtime = 0:04:15.80 train_samples_per_second = 10.555 train_steps_per_second = 5.277
  • epoch: 训练的总轮次(3.0 个 epoch)。
  • total_flos: 训练过程中总共计算的浮点运算次数(2906404 亿次浮点运算)。
  • train_loss: 训练过程中的平均损失值(1.0846)。
  • train_runtime: 训练总共花费的时间(4 分 15.80 秒)。
  • train_samples_per_second: 每秒处理的样本数(10.555 个样本/秒)。
  • train_steps_per_second: 每秒处理的批次数(5.277 个批次/秒)。

💫 训练结束 ~

95c644db986e4062b30fb1edab2a40fb.png
  • 这是模型微调后产生的输出文件,包含了训练过程中生成的各种配置、权重、日志和结果 

💯这时我们可以加载这个训练后的模型权重来对话:

from transformers import AutoModelForCausalLM, AutoTokenizer import torch # 我们的模型输出路径 model_name_or_path = "/home/LLaMA-Factory/output" model = AutoModelForCausalLM.from_pretrained(model_name_or_path) tokenizer = AutoTokenizer.from_pretrained(model_name_or_path) device = "cuda" if torch.cuda.is_available() else "cpu" model.to(device) prompt = "列出一个应该在野营应急包中的7件物品。" inputs = tokenizer(prompt, return_tensors="pt").to(device) with torch.no_grad(): outputs = model.generate(inputs.input_ids, max_length=50) response = tokenizer.decode(outputs[0], skip_special_tokens=True) print(response)

💦输出:

cd674bee5c1948d3a8a9e47f402cd635.png

💯评估 

Llamafactory 支持mmlu、cmmlu、ceval三种数据集验证。

llamafactory-cli eval --task mmlu --model_name_or_path /home/Qwen/Qwen2___5-1___5B-Instruct --template qwen --batch_size 1 –n_shot 5
b12a371ddd3045d98f46049545052611.png

💯推理 

我们在LLaMA-Factory/examples 目录下新建一个 infer.yaml 文件进行推理,内容:

model_name_or_path: /home/Qwen/Qwen2___5-1___5B-Instruct template: qwen do_sample: false 

运行:

 llamafactory-cli chat infer.yaml
43bf526f46b44dc2a8b979e15b913637.png

Read more

构建下一代 AIOps 监控系统:基于 Go 语言与 DeepSeek 大模型的深度实践

构建下一代 AIOps 监控系统:基于 Go 语言与 DeepSeek 大模型的深度实践

前言 在云计算与微服务架构日益复杂的当下,传统的基于静态阈值的服务器监控系统正面临严峻挑战。海量的告警噪音与滞后的故障定位能力,促使运维体系向 AIOps(人工智能运维)转型。本文将详细阐述如何利用高性能的 Go 语言结合 DeepSeek 大语言模型,从零构建一个具备智能分析能力的服务器监控探针。我们将深入探讨 Linux 内核信息采集机制、Go 语言并发编程模式以及大模型 API 的工程化集成。 第一章:基础设施环境构建与系统初始化 构建高效监控系统的基石在于一个稳定且配置得当的运行环境。本次实践基于 Ubuntu LTS(长期支持版)系列,涵盖 20.04 至 24.04 版本,这些版本提供了稳定的内核支持与广泛的软件包兼容性。 1.1 系统更新与依赖管理 在部署任何生产级软件之前,维持操作系统的最新状态是保障安全与稳定性的首要原则。通过包管理器 apt,系统能够从官方源获取最新的安全补丁与软件版本。 执行更新操作不仅仅是简单的软件升级,其背后涉及更新本地包索引数据库(apt update)以及根据依赖关系图谱进行二进制文件的替换(

By Ne0inhk
Flutter 三方库 ethereum 鸿蒙分布式区块链数字资产上链钱包适配突破:接通 JSON-RPC 加密管线深入打通智能合约闭环实现高价值数字加密交互-适配鸿蒙 HarmonyOS ohos

Flutter 三方库 ethereum 鸿蒙分布式区块链数字资产上链钱包适配突破:接通 JSON-RPC 加密管线深入打通智能合约闭环实现高价值数字加密交互-适配鸿蒙 HarmonyOS ohos

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 ethereum 鸿蒙分布式区块链数字资产上链钱包适配突破:接通 JSON-RPC 加密管线深入打通智能合约闭环实现高价值数字加密交互无缝穿透 随着 Web3 技术与移动端的深度融合,支持区块链交互的应用日益增多。ethereum 库专注于以太坊(Ethereum)协议的底层通讯,为开发者提供了便捷的 Web3 集成方案。本文将详细介绍该库在 OpenHarmony 上的适配要点与实战指南。 前言 以太坊是目前最活跃的智能合约平台。在鸿蒙操作系统这个创新的万物智联生态中,支持以太坊交互可以为鸿蒙应用带来去中心化身份(DID)、数字资产(NFT)以及去中心化金融(DeFi)等前沿能力。本文将带你实现在鸿蒙端极速调起智能合约并查询链上数据。 一、原理解析 1.1 基础概念 ethereum 库封装了标准的以太坊 JSON-RPC 协议。在鸿蒙端,它利用 HTTP 请求与以太坊节点(

By Ne0inhk
Flutter 组件 dart_chromecast 的鸿蒙化适配实战 - 驾驭极致多屏交互大坝、实现 OpenHarmony 分布式端高性能投屏控制、设备发现与工业级多媒体协同核方案

Flutter 组件 dart_chromecast 的鸿蒙化适配实战 - 驾驭极致多屏交互大坝、实现 OpenHarmony 分布式端高性能投屏控制、设备发现与工业级多媒体协同核方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 dart_chromecast 的鸿蒙化适配实战 - 驾驭极致多屏交互大坝、实现 OpenHarmony 分布式端高性能投屏控制、设备发现与工业级多媒体协同核方案 前言 在鸿蒙(OpenHarmony)生态的分布式全场景交互、智慧屏协同或者是对跨设备媒体流转有极其严苛要求的 0308 批次影音娱乐应用中。“跨终端的设备发现速度与指令下发的极速响应维度”是衡量整个系统多设备协同能力的最终质量门禁。面对包含数十台局域网内的智能终端、动态变化的 mDNS 宣告报文、甚至是由于网络抖动产生的 0308 批次 MDNS 发现波次。如果仅仅依靠简单的“硬编码 IP 连接”或者是干瘪的 HTTP 轮询。不仅会导致在处理多设备投屏时让系统如同在逻辑废墟中盲人摸象。更会因为协议握手耗时过长,令用户在多屏切换时瞬间陷入卡顿甚至掉线的盲区。 我们需要一种“逻辑自动发现、协议深度对齐”的分布式资产流转艺术。 dart_chromecast

By Ne0inhk
Flutter 组件 chopper_built_value 适配鸿蒙 HarmonyOS 实战:强类型网络层架构,构建不可变模型与高性能序列化闭环

Flutter 组件 chopper_built_value 适配鸿蒙 HarmonyOS 实战:强类型网络层架构,构建不可变模型与高性能序列化闭环

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 chopper_built_value 适配鸿蒙 HarmonyOS 实战:强类型网络层架构,构建不可变模型与高性能序列化闭环 前言 在鸿蒙(OpenHarmony)生态迈向大规模企业级应用、涉及高频网络数据交互、复杂业务模型及严苛运行时稳定性的背景下,如何确保网络请求返回的数据在进入 UI 层前具备绝对的类型安全,已成为衡量应用架构“护城河”深度的核心标准。在鸿蒙设备这类强调 AOT 极致性能与低容错率的环境下,如果应用依然依赖动态类型的 Map<String, dynamic> 进行数据传递,由于由于后端字段变更或类型溢出,极易由于由于运行时强转失败导致应用在关键业务路径上的红屏崩溃。 我们需要一种能够实现自动化代码生成、支持不可变(Immutable)模型且具备拦截器解耦能力的序列化粘合层。 chopper_built_value 为 Flutter 开发者引入了将 Chopper

By Ne0inhk