## 项目总结

### 概述

本报告总结了2024/6/16 -- 7/30期间在客户服务器上进行的工作。主要包括模型迁移与适配、硬件问题排查、环境配置优化，以及客户需求的支持。

### 1. 模型迁移与适配

#### 1.1 Qwen 和 GLM 模型迁移的训练服务

**测试目标**: 确保最新的Qwen2和GLM4模型在客户指定的NPU服务器环境中能稳定运行，并达到预期的性能指标。

**工作内容**:
- **Qwen1.5 14b**: 在面临NPU显存不足的问题时，通过设置Deepspeed的Zero2模式，将部分优化器参数缓存至CPU端，成功完成了模型微调运行，并生成了适用于Mindie部署的训练权重文件。
- **Qwen2**: 尽管昇腾的代码仓库尚未完全适配Qwen2，但是翻看模型配置文件，发现1.5和2使用的模型结构相同，所以参考Qwen1.5的配置，成功进行Qwen2_7b模型的微调训练。性能测试结果显示，训练速度达到33秒/iteration，满足性能预期。

- **GLM3_6b**: 由于和Qwen1.5 14b是相同的代码仓，已经经过昇腾官方的适配，可以顺利拉起训练服务；成功启动推理服务，性能指标达标，证明其在现有硬件配置下的兼容性良好。
- **GLM4_9b**: 由于模型结构的显著差异，初步调试未成功。后续通过llama-factory框架尝试训练微调，简单数据集测试成功，但训练效率尚待优化。

#### 1.2 模型迁移的推理服务

**测试目标**: 实现模型在昇腾平台上的高效推理，提升推理速度和精度。

**工作内容**:最初是使用代码仓中的在线推理模式来测试，之后为了优化和简化模型的部署流程，通过使用昇腾最新推出的推理框架mindie来拉起推理服务。mindie的适配只能是被动接受官方白名单中的模型。首先我们对白名单内的模型，GLM3，Qwen1.5做了测试，可以正常推理。然后针对与白名单中模型结构相似的模型如Qwen2，进行了简单的分析，使用和Qwen1.5的配置方式成功地拉起服务，并确认了Qwen2在mindie框架上可以提供可靠的推理结果。

以下是将测试的模型、训练框架和推理测试结果汇总成的表格：

| **模型名称**        | **模型大小** | **训练框架**                          | **Mindie推理测试** |
|--------------------|--------------|--------------------------------------|--------------------|
| Qwen1.5            | 7B           | Modelzoo, Mindformers, Llama-Factory | 跑通                |
| Qwen1.5            | 14B          | Modelzoo, Mindformers, Llama-Factory | 跑通                |
| Qwen1.5            | 72B          |                                      | 跑通                |
| Qwen2              | 7B           | Modelzoo, Mindformers, Llama-Factory | 跑通                |
| Qwen2              | 14B          | Modelzoo, Mindformers, Llama-Factory | 跑通                |
| GLM3               | 6B           | Modelzoo, Mindformers, Llama-Factory | 跑通                |
| GLM4               | 9B           | Modelzoo, Mindformers, Llama-Factory | 未测试              |

#### 1.3 其他模型测试

**测试目标**: 测试其他常见模型在NPU上的适配性和性能表现。

**工作内容**: 
- 测试模型包括YoloV8、ECAPA_TDNN、DBNet等。在从GPU Pytorch到Ascend OM模型的转换过程中，解决了多个转换问题，并进行了推理精度和性能的详尽测试对比。结果显示，部分模型在推理精度上存在轻微的损失，但整体性能提升明显。

### 2. 硬件及环境问题排查

#### 2.1 NPU及服务器问题

**问题描述**: 测试过程中出现多次NPU硬件问题，如P2P带宽测试失败、ascend kernel runtime initialization failed等，严重影响了模型的稳定运行。

**解决方案**:
- 使用Ascend-DMI工具进行详细的硬件排查，并参考社区经验，通过升级npu驱动，CANN版本和调整系统配置，成功修复了这些问题。之后的测试验证显示，系统稳定性显著提高，运行过程中未再出现同类问题。

#### 2.2 环境配置与迁移

**问题描述**: 从x86服务器迁移到ARM64服务器过程中，遇到镜像不兼容和服务拉起异常等问题，影响了多项服务的正常部署。

**解决方案**:
- 采用手工安装的方式，拉取昇腾镜像仓上的基础镜像，然后在这个镜像上参考昇腾官方的tensorflow指导文档安装并配置与NPU兼容的tensorflow版本。
- 由于预先不清楚迁移的模型有哪些，客户选择把原来服务器上的所有python包都安装到npu服务器上，需要安装的包达到了300个左右，并且arm平台很多python需要编译安装，解决了依赖问题后，完成了环境配置。
- 同事试图将运行于x86服务器上的Milvus load到ARM架构的服务器上。然而，在迁移过程中遇到了`exec format error`的错误。这种错误通常是由于镜像的架构与目标系统架构不兼容引起的。告知同事从一个私人搭建的dockerhub镜像站上拉取arm镜像，并验证镜像确保其正常运行。
- 验证Milvus服务的基本功能，编写了测试脚本，按照以下步骤进行：

1. **创建集合**: 测试创建向量集合。
2. **插入数据**: 向集合中插入向量数据。
3. **创建索引**: 为集合创建索引，以加速检索。
4. **检索操作**: 基于向量相似度进行检索操作，验证结果的准确性。

### 3. 客户需求支持与技术指导

#### 3.1 Langchain 测试与优化

**测试内容**: 
- 对Langchain 的知识库功能进行了测试，涵盖知识库创建、文件批量向量化、API服务调用等多个方面。

**发现问题**: 
- 主要问题集中在版本兼容性和参数传递格式的不一致性。

**解决方案**:
- 通过调整配置参数和修改代码，解决了这些问题。对于低版本Langchain无法正常启动webui服务的问题，由于客户暂时用不到，尚未解决。


在项目初期，按传统方法迁移并完全依赖昇腾官方代码库的方式导致了大量时间浪费。后期改用新的推理和训练框架（如Mindie和Llama-Factory），显著提高了工作效率，并缩短了项目周期。这一策略调整有效地提升了模型适配的速度和准确性，确保了项目目标的顺利实现。