请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/inference/chat.md 

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/inference/inference.md 

前段时间买房一直为找不到好的房源而头大，徒增三千烦恼丝。首先在预算范围内，周边交通便利，有优质学区房，离医疗条件配备齐全的医院距离又要适中的好房源到底哪里找？每天钻进各个平台上研究，耗费大把时间，而且信息繁多难以筛选。无意中发现了这个开发神器，不到几分钟就能按照提供的筛选条件推荐了好几个优质房源，不得不给大家安利一下！大家可以按照步骤试试：案例体验：基于华为云开发者空间-Versatile Agent开发平台零基础开发购房助手实操步骤：领取登录华为开发者空间，开通Versatile Agent；创建Versatile Agent应用；使用Versatile Agent开发平台的服务模型-平台预置功能配置MaaS；使用Versatile Agent的MCP服务，创建车票查询工具MCP；配置购房助手应用模型、提示词、知识库、开场白等，完成预览调试；发布Versatile Agent应用。按照以上步骤完成部署，输入你想要的房源条件，不出几秒就可以给你推荐合适的房源了，节省很多时间，分分钟和购房烦恼say goodbye！  

【话题交流】2025年已悄然步入尾声～这一年，大家有哪些悄然生长的收获？华为云的ModelArts Studio（MaaS）让我们更好的调用deepseek等大模型；对象存储，让海量数据存得下、管得好、用得快。

邀请数据公示信息如下：1、符合条件的邀请人数公示见本论坛贴附件1，PC端下载后查看！2、完成指定任意1门课程学习或实验进度100%，抽奖公示查看附件2，3、开发者空间案例抽奖查看附件3【公示时间】：2025年12月18日—2025年12月22日（含），若有疑问请在该时间段反馈，逾期视为放弃奖励！【奖品发放】：所有奖励将于活动公示期后陆续安排发放，请耐心等待！  【活动时间】2025年 11月 20日 - 2025年 12月 17日活动报名链接：cid:link_8【活动福利】福利1、邀请新用户注册华为云+领取开发者空间+完成指定任意1项学习或实验进度100%，最高可领6000元云资源券（可购买、续费云服务）。邀请新用户+领取开发者空间+指定任意学习或实验奖品2选1（云资源券与实物礼品2选1）云资源券金额实物礼品4人120元/8人240元HC鼠标垫（限50）15人450元开发者定制水杯（限10）20人600元开发者空间定制冲锋衣（颜色/尺码随机）（限10）40人1200元开发者空间定制双肩包（限10）60人1800元罗技MK20键鼠套装（限5）80人2400元开发者空间定制冲锋衣+开发者定制水杯（限5）100人3000元开发者空间定制双肩包+开发者定制水杯（限5）150人4500元开发者空间定制冲锋衣+开发者空间定制双肩包（限5）200人6000元HUAWEI FreeClip  星空黑（限3）  福利2、完成指定任意1项课程学习或实验进度100%可参与抽奖，抽开发者定制双肩包、水杯、数据收纳包、100元云资源券。课程列表（含报名入口）实验列表（含实验入口）DeepSeek大模型服务API发布与调用使用MindSpore开发训练模型识别手写数字基于DeepSeek搭建Agent智能助手基于ECS制作模型镜像在ModelArts训练模型DeepSeek + AI编程助手Cline自动化游戏开发基于鲲鹏架构的飞机大战游戏开发MCP协议基础与MCP Server服务实践部署Python电商项目MCP协议高级应用与AI助手协同理论/ 福利3、完成指定任意1项开发者空间案例可参与抽奖，抽华为云定制键盘、开发者空间定制长袖卫衣、华为智能体脂秤3、华为FreeLace 活力版耳机。（1） 点此免费领取华为开发者空间，然后完成下方任意1项案例实践后，在论坛贴评论区发布：案例名称+完成案例实践截图+心得，再抽奖→（点此抽奖）。抽华为FreeLace 活力版耳机、华为云定制键盘、开发者空间定制长袖卫衣、华为智能体脂秤等好礼。开发者空间案例（含实操入口）基于开发者空间-Versatile Agent构建内容审核工作流智能应用基于华为开发者空间-Versatile Agent开发平台构建旅游规划助手基于华为云开发者空间-Versatile Agent开发平台零基础开发购房助手基于华为开发者空间-Versatile Agent预置MCP资产快速构建智能体基于华为开发者空间-云开发环境（容器）+MaaS实现智语灵犀-AI对话助手基于华为开发者空间-云开发环境（容器）+MaaS大模型构建智能写作助手应用基于华为开发者空间开发平台-云开发环境（容器），完成贪吃蛇小游戏开发华为开发者空间-云开发环境（虚拟机）IDE插件远程连接操作指导  点击前往活动页，可查看详细福利。

案例体验《云主机调用DeepSeek实现代码自动生成》在云主机上调用ModelArts Studio预置的DeepSeek V3模型API实现代码自动生成，跟着步骤一步步做，简单有趣，很快就帮我自动生成一款带图形画界面的双人乒乓球对战游戏啦，重点还是免费体验的，快都来试！步骤很简单！已经总结在下面啦① 开发者空间领取免费云主机，配置开发环境（免费的！！！）② 安装大模型应用开发框架AutoGen③ CodeArts IDE运行DeepSeek V3 API调用程序④ 调用ModelArts Studio预置DeepSeek V3模型（还是免费的！！！）⑤ 返回生成的代码免费DeepSeek V3模型领取路径，偷偷告诉你！戳这里直接领代金券——购买DeepSeek V3模型——选用领取的代金券即可抵扣眼见为实，快看我生成的游戏截图！↓↓  

一文走进IPv4和IPv6cid:link_7 IPv6和Ipv4笔记分享cid:link_8 防火墙HRP笔记分享cid:link_9 openEuler 国产化替代：平衡生态兼容与自主创新cid:link_10 openGauss 全密态数据库：计算过程隐私保护技术解析cid:link_11 常见的ONU与IP静态绑定配置分享cid:link_12 无 GPS 环境米级定位方案分享：大型仓库物资追踪解决方案cid:link_0 户外气象站全面防雷保护方案：从器件选型到接地系统cid:link_13 物联网设备并发上线抗雪崩方案：从协议优化到架构升级cid:link_14 边缘 AI 部署中的典型挑战cid:link_15 物联网设备深度休眠下的 "瞬时唤醒" 方案cid:link_16 边缘设备与云平台业务不中断保障cid:link_17 NB-IoT 设备电池寿命精准估算与功耗优化全方案cid:link_18 多品牌智能家居设备互联互通全方案cid:link_1 工业温湿度传感器数据滤波全方案：从硬件到算法的精准降噪cid:link_19 农业传感器防伪造：低成本设备身份认证全方案cid:link_2 低功耗边缘 AI 芯片选型指南：电池供电设备的实时异常检测方案cid:link_20 物联网设备OTA升级设计cid:link_3 LoRa 模块 (SX1278) 传输距离不足：实战排查与距离提升方案cid:link_4 智能家居协议实测：MQTT vs CoAP 真实体验与选型指南cid:link_5 一文带你走进autovacuumcid:link_21 Docker数据丢失核心原因及解决方法cid:link_6 

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/finetune/qlora_finetune.md 

各位华为云社区的技术同行们，大家好！初冬寒意渐浓，但技术学习的热情从未降温～ 转眼间 2025 年 11 月已近尾声，在华为云这个汇聚根技术生态的平台上，想必大家都收获了满满的新知识与实战经验。或许是昇腾 AI 的最新适配技巧，是仓颉编程的高效开发方法，是鸿蒙端云协同的创新实践，又或是 MCP 协议、DeepSeek 大模型的落地应用心得？技术的成长从不止步于独自探索，每一份知识分享都能碰撞出创新火花，每一次经验交流都能助力共同成长。现在就来畅所欲言，聊聊这个 11 月你解锁的新技能、吃透的新技术，让我们在交流中互学互鉴，让知识在分享中持续增值！

 数据丢失的核心原因是 数据卷挂载配置错误（路径不对、权限不足、挂载类型误用），Docker 环境下 PostgreSQL 的数据持久化完全依赖正确的卷挂载 ——PostgreSQL 容器的默认数据存储目录是 /var/lib/postgresql/data，如果挂载时路径不匹配、宿主机目录无写入权限，数据会默认存到容器的 “临时存储层”，容器重启后就会丢失。一、先排查：你的数据卷挂载到底错在哪？1. 最常见错误：挂载路径不匹配（没对准容器内默认数据目录）PostgreSQL 容器的 数据必须存储在 /var/lib/postgresql/data 目录下（这是官方镜像的固定路径，改不了）。如果你的启动命令里挂载路径写错了（比如多写一层目录、少写路径），数据根本没写到宿主机卷里。常见小错误（路径错误）： # 错误1：挂载到 /var/lib/postgresql（少了 /data 后缀）docker run -d -v pgdata:/var/lib/postgresql postgres:15# 错误2：自定义容器内路径（比如 /data），但PostgreSQL不往这写docker run -d -v /宿主机路径:/data postgres:15# 错误3：绑定挂载时宿主机路径拼写错误（比如 /home/user/pgdata 写成 /home/user/pgdat）docker run -d -v /home/user/pgdat:/var/lib/postgresql/data postgres:15 正确示例（路径必须对准 /var/lib/postgresql/data）： # 命名卷（推荐，Docker自动管理路径和权限）docker run -d -v pgdata:/var/lib/postgresql/data postgres:15# 绑定挂载（宿主机路径自定义，需确保权限）docker run -d -v /home/user/pgdata:/var/lib/postgresql/data postgres:15 2. 第二常见：宿主机目录权限不足（容器内用户写不进去）PostgreSQL 容器内默认使用 postgres 用户（UID=999，GID=999）运行，如果是 绑定挂载（直接挂载宿主机目录），宿主机目录的属主 / 权限不对，postgres 用户无法写入数据，会自动降级为 “临时存储”（重启丢失）。错误场景：宿主机创建了 /home/user/pgdata 目录，但默认属主是 root，权限是 755（只有 root 能写），容器内 postgres 用户没权限写入，只能用临时存储。修复方法（绑定挂载时）：  # 1. 先给宿主机目录设置正确权限（让 UID=999 能写入）sudo chown -R 999:999 /home/user/pgdatasudo chmod -R 700 /home/user/pgdata # PostgreSQL要求数据目录权限为700（仅所有者可读写）# 2. 再启动容器（路径正确+权限正确）docker run -d -v /home/user/pgdata:/var/lib/postgresql/data postgres:15 3. 其他的小错误：误用 “匿名卷” 或 “临时存储”匿名卷：启动命令里只写 -v /var/lib/postgresql/data（没指定宿主机路径或卷名），Docker 会创建随机命名的匿名卷，容器删除后匿名卷可能被清理（重启容器不删，但手动删容器时容易丢）；临时存储：如果启动时没加任何 -v 挂载，数据直接存在容器的 “可写层”，容器重启 / 重建后 100% 丢失。二、Docker 部署 PostgreSQL 的正确流程（确保数据不丢）推荐用 命名卷（Docker 自动管理路径、权限，避免手动配置错误）1. 提前创建命名卷（也可启动时自动创建） # 创建名为 pgdata 的命名卷（Docker会把数据存在 /var/lib/docker/volumes/pgdata 下）docker volume create pgdata 2. 启动容器（核心：正确的去挂载卷 + 设置必要环境变量）docker run -d \ --name postgres-db \ -p 5432:5432 \ # 端口映射（宿主机:容器） -v pgdata:/var/lib/postgresql/data \ # 命名卷挂载（关键） -e POSTGRES_USER=myuser \ # 自定义数据库用户（避免用默认postgres） -e POSTGRES_PASSWORD=mypassword \ # 自定义密码（必须设置，否则容器启动失败） -e POSTGRES_DB=mydb \ # 初始化时创建的数据库（可选） -e PGDATA=/var/lib/postgresql/data/pgdata \ # 可选：指定数据子目录（避免和配置文件混放） --restart=always \ # 容器异常退出时自动重启 postgres:15 # 指定具体版本（不要用latest，避免版本迭代问题） 3. 验证数据持久化（确保重启后不丢） # 1. 进入容器，创建测试数据docker exec -it postgres-db psql -U myuser -d mydb# 执行SQL创建表并插入数据CREATE TABLE test (id int);INSERT INTO test VALUES (1);SELECT * FROM test; # 确认能查到数据，退出容器（ctrl+d）# 2. 重启容器docker restart postgres-db# 3. 再次进入容器，验证数据是否存在docker exec -it postgres-db psql -U myuser -d mydbSELECT * FROM test; # 能查到 (1) 说明持久化成功 三、Docker 环境使用 PostgreSQL 的关键注意事项1. 数据卷相关（重中之重）优先用 命名卷：避免绑定挂载的权限、路径问题，Docker 会自动维护卷的生命周期（容器删除后卷不会删，数据保留）；绑定挂载需注意：宿主机目录必须提前创建并设置 999:999 属主（容器内 postgres 用户的 UID/GID），权限设为 700（PostgreSQL 安全要求，禁止其他用户访问数据目录）；不要修改容器内默认数据目录：官方镜像的 /var/lib/postgresql/data 是固定路径，修改 PGDATA 环境变量时需确保挂载路径同步（比如 PGDATA=/var/lib/postgresql/data/pgdata，挂载路径仍为 /var/lib/postgresql/data）。2. 配置与权限必须设置密码：PostgreSQL 官方镜像从 10 版本后，必须通过 POSTGRES_PASSWORD 环境变量设置密码，否则容器启动失败；避免硬编码密码：生产环境不要直接在命令行写密码，可用 --env-file 加载环境变量文件（比如 docker run --env-file .env ...，.env 文件里写 POSTGRES_PASSWORD=mypassword）；挂载配置文件：如果需要修改 postgresql.conf（比如调整内存、连接数），可将宿主机的配置文件挂载到 /var/lib/postgresql/data/postgresql.conf（命名卷中会自动生成默认配置，可先拷贝出来修改再挂载）： # 先拷贝容器内默认配置到宿主机docker cp postgres-db:/var/lib/postgresql/data/postgresql.conf /home/user/pgconf/# 修改后重新挂载配置文件docker run -d -v pgdata:/var/lib/postgresql/data -v /home/user/pgconf/postgresql.conf:/var/lib/postgresql/data/postgresql.conf ...  3. 容器管理禁止用 docker rm -v 删除容器：-v 参数会同时删除挂载的卷（包括命名卷），导致数据丢失；定期备份数据卷：即使挂载了卷，也要定期备份（比如用 docker run --rm -v pgdata:/source -v /宿主机备份路径:/dest alpine tar -czf /dest/pgbackup.tar.gz -C /source .）；指定具体镜像版本：不要用 postgres:latest，避免容器重建时自动升级版本（可能出现兼容性问题），比如固定 postgres:15.6。4. 网络与端口避免暴露 5432 端口到公网：默认 -p 5432:5432 会把端口暴露到公网，容易被暴力破解，生产环境可改为内网访问（比如 -p 127.0.0.1:5432:5432，仅允许宿主机访问），或用 Docker 自定义网络隔离；容器间通信：如果其他容器需要访问 PostgreSQL，建议创建 Docker 网络（docker network create pg-network），启动时加入网络（--network pg-network），通过容器名（比如 postgres-db）访问，无需暴露端口。5. 资源限制限制 CPU / 内存：避免 PostgreSQL 容器占用过多宿主机资源，可通过 --cpus 和 --memory 限制（比如 --cpus 2 --memory 4g，限制 2 核 CPU、4G 内存）；磁盘空间监控：命名卷默认存在 /var/lib/docker/volumes/ 下，需监控宿主机磁盘空间，避免数据量增长导致磁盘满。四、如果数据已经丢失，怎么去救救数据呢？如果容器还没删除，可尝试从容器的 “临时存储层” 抢救数据： # 1. 查看容器是否还存在（即使已停止）docker ps -a | grep postgres-db# 2. 用新容器挂载原容器的存储层，拷贝数据docker run --rm -v /宿主机临时路径:/backup alpine \ cp -r /var/lib/docker/containers/[原容器ID]/mounts/secrets/ /backup/# （注：如果原容器已删除，临时存储层会被清理，无法恢复，只能依赖之前的备份） 总结一下下数据丢失的核心是 挂载路径不对 或 权限不足，记住：PostgreSQL 容器必须挂载 /var/lib/postgresql/data 目录；推荐用 命名卷 部署，避免手动配置权限和路径的麻烦；生产环境务必做好 定期备份 和 权限隔离，不要暴露端口到公网，指定固定镜像版本。

一、autovacuum 是干什么的？—— PostgreSQL 的 “自动清洁工 + 优化师”PostgreSQL 基于 MVCC（多版本并发控制） 机制工作，这个机制会导致两个关键问题，而 autovacuum 就是专门解决这两个问题的后台进程：1. 核心功能 1：清理 “死元组”（垃圾数据）当你执行 DELETE 或 UPDATE 时，PostgreSQL 不会直接删除旧数据：DELETE：只是给旧数据打个 “已删除” 标记（变成 “死元组”）；UPDATE：本质是 “删除旧行 + 插入新行”，同样会产生死元组。这些死元组会占据磁盘空间，还会让查询时扫描更多无效数据，导致表变大、查询变慢。autovacuum 会自动扫描表，清理这些死元组，释放磁盘空间，让查询更高效。2. 核心功能 2：更新统计信息PostgreSQL 的查询优化器（ Planner ）需要依赖 “表数据统计信息”（比如某列有多少不同值、数据分布）来生成最优执行计划。如果统计信息过时，优化器可能会选低效的执行计划（比如明明该走索引却全表扫描），导致查询变慢。autovacuum 会定期更新这些统计信息，确保优化器决策准确。3. 核心功能 3：防止事务 ID 回卷（致命风险）PostgreSQL 中每个事务都有一个唯一的事务 ID（XID），XID 是 32 位整数，会循环使用。如果长期不运行 autovacuum，旧事务的 XID 会被 “冻结”，一旦 XID 循环到临界值，数据库会直接进入只读模式（甚至不可用），这就是 “事务 ID 回卷”，修复成本极高。二、能不能直接关掉？—— 绝对不建议哦！直接关闭 autovacuum 会导致三个致命问题：死元组堆积：表体积暴增，查询、备份、恢复速度越来越慢；统计信息过时：查询执行计划变差，业务 SQL 可能从毫秒级变成秒级 / 分钟级；事务 ID 回卷风险：数据库最终会只读或崩溃，影响业务连续性。例外情况：仅当你有严格的手动维护流程（比如每天凌晨手动执行 VACUUM ANALYZE），且能确保覆盖所有表，才可能考虑关闭 —— 但实际生产中几乎没人这么做（手动维护容易遗漏大表 / 热点表）。三、核心解决方案：调整 autovacuum，避开夜间高峰期你的问题本质是 autovacuum 在半夜 12 点（可能是业务低峰期，但数据库仍有压力）集中运行，导致资源占用过高。解决方案是：让 autovacuum 在更空闲的时段运行，或分散运行，降低单轮资源消耗。调整思路分 3 类，优先从简单的来：1. 第一步：调整 autovacuum 运行时段（避开 12 点）PostgreSQL 12+ 版本支持通过 autovacuum_naptime 和 autovacuum_vacuum_cost_delay 控制运行频率，或通过 pg_cron 插件指定固定时段运行（推荐）。方法 1：修改全局参数（适用于所有表）编辑 PostgreSQL 配置文件 postgresql.conf（路径通常在 $PGDATA/postgresql.conf），调整以下参数：  # 1. 控制 autovacuum 进程的唤醒间隔（默认1分钟，可缩小让它更频繁但轻量化）autovacuum_naptime = 30s # 每30秒唤醒一次，分散清理压力（默认1min）# 2. 降低 autovacuum 的资源消耗（避免单轮清理占用过多CPU/IO）autovacuum_vacuum_cost_delay = 20ms # 每消耗一定“成本”就暂停20ms（默认0，不暂停）autovacuum_vacuum_cost_limit = 100 # 单次清理的“成本上限”（默认-1，继承全局vacuum_cost_limit）# 3. 避开12点高峰期：让 autovacuum 主要在凌晨3-6点运行（需配合 pg_cron）# 先启用 pg_cron 插件（需提前安装，多数云数据库已预装）shared_preload_libraries = 'pg_cron' # 新增或添加到现有列表cron.database_name = '你的数据库名' # 指定 pg_cron 生效的数据库# 然后在数据库中执行SQL，禁用默认自动触发，改为定时执行-- 1. 全局禁用自动 autovacuum（仅禁用触发，保留进程）ALTER SYSTEM SET autovacuum = off;-- 2. 用 pg_cron 定时在凌晨3点执行全库 vacuum analyze（低峰期）SELECT cron.schedule('daily-autovacuum', '0 3 * * *', 'VACUUM ANALYZE;');-- 3. 可选：对大表单独定时（比如凌晨4点清理大表）SELECT cron.schedule('vacuum-big-table', '0 4 * * *', 'VACUUM ANALYZE public.你的大表名;'); 方法 2：针对单个大表调整（如果是某张大表导致的慢）如果日志显示是某张大表（比如千万级 / 亿级数据的表）在 12 点触发 autovacuum，可以单独给这张表设置参数，让它在其他时段清理：  -- 给大表设置：降低触发阈值（更早清理，避免堆积后单次消耗过大）+ 调整运行时段ALTER TABLE public.你的大表名 SET ( autovacuum_vacuum_threshold = 5000, -- 死元组达到5000就触发（默认50） autovacuum_vacuum_scale_factor = 0.05, -- 死元组占比达到5%也触发（默认20%） autovacuum_vacuum_cost_delay = 50ms -- 单表清理时更慢，减少资源占用); 2. 第二步：限制 autovacuum 的资源占用（避免拖慢数据库）如果 autovacuum 运行时占用过多 CPU/IO，导致业务 SQL 变慢，可以通过以下参数限制资源：  # postgresql.conf 中调整vacuum_cost_page_hit = 1 # 内存中命中数据页的“成本”（默认1）vacuum_cost_page_miss = 10 # 磁盘中读取数据页的“成本”（默认10）vacuum_cost_page_dirty = 20 # 修改脏数据页的“成本”（默认20）autovacuum_vacuum_cost_limit = 50 # 单次清理的最大“成本”（默认-1，继承全局） 核心的逻辑：autovacuum 每清理一页数据会累积 “成本”，达到 cost_limit 后，就会暂停 cost_delay 时间，避免持续占用资源。小建议：IO 压力大的场景，可增大 cost_delay（比如 50ms），减小 cost_limit（比如 50），让清理更 “温和”。3. 第三步：排查是否有其他任务冲突（比如备份）半夜 12 点可能同时运行其他耗资源任务（比如数据库备份、ETL 同步），和 autovacuum 争夺 CPU/IO，导致变慢。可以：查看日志，确认 12 点是否有备份 / ETL 任务，将其调整到其他时段（比如凌晨 2 点）；如果必须同时运行，降低备份的 IO 优先级（比如 PostgreSQL 备份用 pg_dump -F c -j 2 限制并发，避免全量备份占满 IO）。四、验证调整效果调整后，需要确认 autovacuum 是否在目标时段运行，且不再导致数据库变慢：查看 autovacuum 运行状态： -- 查看当前正在运行的 autovacuum 进程SELECT pid, query, state, now() - query_start AS duration FROM pg_stat_activity WHERE query LIKE '%autovacuum%' AND state = 'active';-- 查看各表的 autovacuum 统计（比如死元组数量、最后清理时间）SELECT relname AS 表名, n_dead_tup AS 死元组数量, last_vacuum AS 最后手动清理时间, last_autovacuum AS 最后自动清理时间, autovacuum_count AS 自动清理次数FROM pg_stat_user_tables ORDER BY n_dead_tup DESC; 观察数据库负载：调整后半夜 12 点的 CPU/IO 使用率、查询响应时间是否恢复正常。总结一下下autovacuum 是 PostgreSQL 的 “必需进程”，负责清理垃圾、更新统计、防止事务 ID 回卷，不能直接关掉；夜间变慢的核心是 autovacuum 与业务 / 其他任务争夺资源，优先通过 pg_cron 调整运行时段（比如凌晨 3-6 点）；辅助调整资源限制（cost_delay/cost_limit）和表级触发阈值，让清理更分散、更温和；若调整后仍慢，排查是否有备份 / ETL 等任务冲突，或优化大表结构（比如分区表）。

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/finetune/lora_finetune.md 

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/finetune/multi-turn_conversation.md 

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/finetune/multi_sample_pack_finetune.md 

请查阅参考昇腾社区文档：https://gitee.com/ascend/MindSpeed-LLM/blob/2.1.0/docs/pytorch/solutions/finetune/instruction_finetune.md