master

ascend-robotmodel_runner重构

57da56a0创建于 1月24日历史提交

文件	最后提交记录	最后更新时间
test_config_qwen3_moe.py	qwen3_moe aclgraph回合dev Co-authored-by: bowenli<libowen82@huawei.com> # message auto-generated for no-merge-commit merge: !158 merge dev_qwen3_moe into dev qwen3_moe aclgraph回合dev Created-by: bowenli Commit-by: bowenli Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20251225 --> # 合入背景 > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 注意：Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. aclgraph qwen3-moe模型侧代码适配 # 修改内容 > 请描述修改内容的具体实现，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。\ > 如果是需求或者重构类的PR，需要补充详细设计文档（说明上下游组件关系、时序图、类图、DFX能力等内容）。 新增qwen3_moe文件夹代码，以及相关测试文件 # 资料变更 > 请确认是否涉及资料变更。如涉及，需要在PR中体现，并简要说明修改内容。如不涉及，需填写“不涉及”。 不涉及 # 接口变更 > 请确认是否涉及跨代码仓或者客户面可见的接口变更。如涉及，需要详细说明接口以及对应的变更内容，同时需要在资料中体现。如不涉及，需填写“不涉及”。 不涉及 # 测试结果 > 请说明测试场景，测试方法以及测试结果。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。  # CheckList > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x]。 - [x] 代码注释完备 - [x] 正确记录错误日志 - [x] 进行了返回值校验 (禁止使用void屏蔽安全函数、自研函数返回值；考虑接口的异常场景；调用底层组件接口时，需要进行返回值校验) - [x] 进行了空指针校验 - [x] 若存在资源申请，使用后资源被正确的释放了 - [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 - [x] 按照[代码仓中提供的格式模板](https://gitcode.com/Ascend/MindIE-LLM/blob/master/.clang-format)，使用clang-format工具格式化代码 - [x] 符合Ascend社区的编码规范。[C++ 语言编程指导](https://gitcode.com/Ascend/community/blob/master/docs/contributor/Ascend-cpp-coding-style-guide.md) | [C++ 语言安全编程指导](https://gitcode.com/Ascend/community/blob/master/docs/contributor/Ascend-cpp-secure-coding-guide.md) See merge request: Ascend/MindIE-LLM!158	4 个月前
test_input_builder_qwen3_moe.py	qwen3_moe aclgraph回合dev Co-authored-by: bowenli<libowen82@huawei.com> # message auto-generated for no-merge-commit merge: !158 merge dev_qwen3_moe into dev qwen3_moe aclgraph回合dev Created-by: bowenli Commit-by: bowenli Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20251225 --> # 合入背景 > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 注意：Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. aclgraph qwen3-moe模型侧代码适配 # 修改内容 > 请描述修改内容的具体实现，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。\ > 如果是需求或者重构类的PR，需要补充详细设计文档（说明上下游组件关系、时序图、类图、DFX能力等内容）。 新增qwen3_moe文件夹代码，以及相关测试文件 # 资料变更 > 请确认是否涉及资料变更。如涉及，需要在PR中体现，并简要说明修改内容。如不涉及，需填写“不涉及”。 不涉及 # 接口变更 > 请确认是否涉及跨代码仓或者客户面可见的接口变更。如涉及，需要详细说明接口以及对应的变更内容，同时需要在资料中体现。如不涉及，需填写“不涉及”。 不涉及 # 测试结果 > 请说明测试场景，测试方法以及测试结果。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。  # CheckList > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x]。 - [x] 代码注释完备 - [x] 正确记录错误日志 - [x] 进行了返回值校验 (禁止使用void屏蔽安全函数、自研函数返回值；考虑接口的异常场景；调用底层组件接口时，需要进行返回值校验) - [x] 进行了空指针校验 - [x] 若存在资源申请，使用后资源被正确的释放了 - [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 - [x] 按照[代码仓中提供的格式模板](https://gitcode.com/Ascend/MindIE-LLM/blob/master/.clang-format)，使用clang-format工具格式化代码 - [x] 符合Ascend社区的编码规范。[C++ 语言编程指导](https://gitcode.com/Ascend/community/blob/master/docs/contributor/Ascend-cpp-coding-style-guide.md) | [C++ 语言安全编程指导](https://gitcode.com/Ascend/community/blob/master/docs/contributor/Ascend-cpp-secure-coding-guide.md) See merge request: Ascend/MindIE-LLM!158	4 个月前
test_qwen3_moe.py	model_runner重构 Co-authored-by: LostFox11<wangziyue17@huawei.com> Co-authored-by: huanglei1<huanglei1@huawei.com> Co-authored-by: Katrina-CXY<chenxinyi20@huawei.com> Co-authored-by: xsxhw1<xiaoshixiang2@huawei.com> # message auto-generated for no-merge-commit merge: !255 merge mid into dev model_runner重构 Created-by: LostFox11 Commit-by: LostFox11;Katrina-CXY;stanzzzzz;xsxhw1;huanglei1 Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20251225 --> # 合入背景 > 重构model_runnner 支持异步 # 修改内容 > 1.区分h2d与d2d场景 支持异步以及与其他特性叠加 2.泛化metadata，支持各特性持有自己的参数与方法 3.使用batch_descriptor选图 4.eager mode支持padding 5.新增input_buffer存储固定入图地址 6.修改sampler 下沉为layers里面的实例 直接返回device tensor 7.修改plugin_manger的exp逻辑 将fill_in_model_result放到forward_loop 即第二条流 8.修改seq_lens_list的计算逻辑，取消不必要同步操作，减小异步空泡 9.修改forward_context以及持有的attn_metadata的构造逻辑 统一使用model_input构造 # 资料变更 > 不涉及。 # 接口变更 > 不涉及 # 测试结果 > 新model_runner dsv3.2 dp+tp+ep `curl http://localhost:7070/v1/chat/completions -d '{ "model": "ds_v3.2", "messages": [ {"role": "user", "content": "告诉我大模型推理中的vllm的具体实现细节"} ], "stream": false, "max_tokens": 1024 }' {"id":"endpoint_common_0","object":"chat.completion","created":1768983661,"model":"ds_v3.2","choices":[{"index":0,"message":{"role":"assistant","content":"好的，我来详细解释一下 **vLLM（Virtual Large Language Model）** 的具体实现细节。\n\nvLLM 是一个旨在**高效服务大型语言模型（LLM）**的系统，其核心思想是通过**虚拟化**技术来优化内存管理和推理过程。下面我们从几个关键方面来分解它的实现：\n\n---\n\n### 1. 核心问题：传统LLM服务的内存瓶颈\n\n大型语言模型（如GPT-3规模模型）的主要挑战是：\n* **内存占用巨大**：模型参数（权重）需要大量GPU内存。\n* **注意力机制内存开销**：推理过程中，Key-Value（KV）缓存随着序列长度增长而线性增长，尤其对于长上下文模型，这成为主要瓶颈。\n\n传统方法：\n* 将整个模型加载到GPU内存。\n* 每次推理为整个序列分配KV缓存。\n* 结果：单个GPU只能服务较小模型或短序列，或者需要多GPU并行，但效率低。\n\n---\n\n### 2. vLLM的虚拟化思想\n\nvLLM通过“虚拟化”来解决这个问题，意思是**它并不在物理内存中实际存储全部所需数据，而是按需动态加载和卸载**。\n\n具体虚拟化两个方面：\n\n#### **2.1 模型权重虚拟化（PagedModel）**\n\n灵感来自操作系统的**分页内存管理**：\n* 将庞大的模型权重（参数）划分为多个“页”（blocks）。\n* 仅将当前推理所需的部分“页”加载到GPU内存。\n* 不需要的“页”可卸载到成本较低的CPU内存或甚至磁盘。\n* 通过一个“页表”（block table）来管理这些页的映射和调度。\n\n**实现细节**：\n* **划分策略**：根据模型结构（如Transformer层的线性顺序）自然划分页。通常按层或层的部分划分。\n* **调度策略**：根据请求的推理进度（已处理到的层）预测下一所需页，预加载。\n* **换入换出**：当GPU内存不足时，将最远页换出到CPU内存。\n\n这样，**单个GPU可以服务一个物理内存装不下的更大模型**。\n\n#### **2.2 KV缓存虚拟化（PagedAttention）**\n\n这是vLLM最著名和核心的创新！\n\n注意力机制中的KV缓存问题：\n* 在自回归推理中，每生成一个新token，需存储其Key和Value向量到缓存，以便后续token计算注意力时使用。\n* 序列长度L，则KV缓存大小约 O(L)。\n* 长序列（如100K token）时，KV缓存可能比模型权重还大。\n\n**PagedAttention解决方案**：\n* 将KV缓存也**分页管理**！不再为整个序列连续分配内存，而是将每个token的KV向量分配到固定大小的“页”中。\n* 这些页按需分配：当新token生成，若当前页满，则分配新页。\n* 注意力计算时，可能需访问多个页（分散的KV向量），但系统通过页表知道所有KV向量位置，并能高效组合它们。\n\n**实现细节**：\n* **页大小**：通常一个页存储多个token的KV向量（如16或32 token）。\n* **页分配**：类似OS的内存分配，有空闲页列表，需要时分配。\n* **注意力计算算法修改**：传统注意力计算假设KV缓存是连续内存数组。现在需修改算法以处理“分页的KV缓存.......' 旧model_runner dsv3.2 dp+tp+mtp+ep [2026-01-20 23:39:12,313] [460569] [281472785282432] [tokenizer] [INFO] [io_utils.py-15] : tokenizer start. [2026-01-20 23:39:12,315] [460567] [281472785282432] [tokenizer] [INFO] [io_utils.py-15] : tokenizer start. [2026-01-20 23:39:17.984161] [380115] [380126] [server] [INFO] [infer_tokenizer.cpp:411] [tokenizer] Finished to init tokenizer sub process size 8 [2026-01-20 23:39:17.984191] [380115] [380126] [server] [INFO] [endpoint.cpp:158] [endpoint] mExpertParallel is false, healthchecker init skipped [2026-01-20 23:39:17.992593] [380115] [node-13] [system] [server] [Start mindie server] [success] Daemon start success! [2026-01-20 23:39:17.992604] [380115] [380126] [server] [INFO] [endpoint.cpp:142] [endpoint] Start endpoint success [2026-01-20 23:39:17.992630] [380115] [node-13] [system] [server] [start endpoint] [success] [2026-01-20 23:39:17.992654] [380115] [380126] [server] [INFO] [llm_daemon.cpp:339] [daemon] Daemon start success! curl http://localhost:7070/v1/chat/completions -d '{ "model": "ds_v3.2", "messages": [ {"role": "user", "content": "告诉我大模型推理中的vllm的具体实现细节"} ], "stream": false }' {"id":"endpoint_common_0","object":"chat.completion","created":1768925434,"model":"ds_v3.2","choices":[{"index":0,"message":{"role":"assistant","content":"好的，我来详细解释一下 **vLLM**（Virtual Large Language Model）的具体实现细节。\n\nvLLM 是 NVIDIA 在 2024 年提出的一种 **推理优化技术**，旨在解决大模型推理中的两个核心痛点：**内存瓶颈** 和 **计算效率**。它的本质思想是：**用“虚拟化”的方法，让一个较小的物理GPU模型，去服务一个较大的逻辑用户模型**。\n\n下面我们从 **核心思想、关键技术、实现步骤、优势与局限** 四个方面展开。\n\n---\n\n### 1. 核心思想\n\n传统大模型推理的问题是：\n- **模型太大**（例如 70B参数）：需要巨大的GPU内存，单卡甚至多卡都放不下。\n- **即使放得下**，推理过程中，计算单元（SM）利用率低，因为很多时间花在内存访问（IO）上。\n\nvLLM 的虚拟化类比：\n- **就像操作系统中的虚拟内存**：物理RAM只有4GB，但通过分页机制，程序可以认为自己有8GB内存。\n- **就像云计算中的虚拟资源**：物理服务器只有10核，但通过调度，用户可认为自己有100核。\n\nvLLM 的具体类比：\n- **物理模型**：实际存储在GPU内存中的模型参数，可能只有 **20B**（通过精选、压缩）。\n- **逻辑模型**：用户请求时，模型表现出的行为，像是一个 **70B** 的完整模型。\n\n实现这一幻觉的关键是：**只在需要时，动态加载缺失的参数**。\n\n---\n\n### 2. 关键技术\n\nvLLM 依赖三大技术支柱：\n\n#### **2.1 模型分块（Model Chunking）**\n\n将完整大模型按某种策略拆成“块”：\n- **一部分块** → **常驻块**（Resident Chunks）：永远留在GPU内存中。\n- **另一部分块** → **虚拟块**（Virtual Chunks）：平时存放在慢速存储（CPU内存、NVMe SSD），需要时才加载到GPU。\n\n**分块策略**：\n- 可以是 **按层分块**（例如Transformer的某些层常驻，某些层虚拟）。\n- 也可以是 **按参数类型分块**（例如Attention层的权重常驻，MLP层的权重虚拟）。\n- 策略选择基于：**哪些块对推理延迟影响最大？哪些块使用频率最高？**\n\n#### **2.2 预取与缓取（Prefetching & Caching）**\n\n类似CPU虚拟内存的预取机制：\n- **根据推理序列的预测**，提前将接下来可能需要的虚拟块，加载到GPU。\n- 预测可以基于：\n - **静态分析**：模型结构的知识，知道下一token计算需要哪一层。\n - **动态历史**：从已生成的token序列，推测下一步的访问模式。\n\n**缓存管理**：\n- GPU内存作为虚拟块的缓存，需要替换策略（LRU等）。\n- 目标是最大化 **缓存命中率**，减少实时加载次数。\n\n#### **2.3 计算流水线重组（Compute Pipeline Reorganization）**\n\n调整模型推理的计算步骤顺序，以 **隐藏加载延迟**。\n\n传统顺序：\n1. 需要层X → 2. 加载层X → 3. 计算层X → 4. 需要层Y → ...\n\nvLLM 重组顺序：\n1. 预取层X & 层Y → 2. 计算层Z（常驻） → 3. 同时：层X已就绪，直接计算 → ...\n\n通过 **重叠IO与Compute**，类似计算机体系结构中的“流水线”，让加载时间不成为显性延迟。\n\n---\n\n### 3. 具体实现步骤\n\n我们模拟一个 vLLM 推理一次token的流程：\n\n**步骤0：初始化**\n- 模型分块：定义常驻块集合 R，虚拟块集合 V。\n- 虚拟块存储位置：映射到CPU内存或SSD。\n\n**步骤1：接收请求**\n- 用户输入序列，模型开始推理。\n\n**步骤2：预取预测**\n- 根据当前序列位置，预测接下来1-3步需要哪些虚拟块（V1, V2, V3）。\n- 发起预取指令：将V1, V2, V3从慢存储加载到GPU缓存。\n\n**步骤3：计算常驻块**\n- 在预取进行的同时（IO时间），GPU计算那些常驻块（R）的部分。\n- 这部分计算不依赖虚拟块，所以可并行进行。\n\n**步骤4：计算虚拟块**\n- 当预取完成，虚拟块在GPU就绪，接着计算这些块。\n- 如果预取命中，则无缝衔接；如果未命中（预测错），则实时加载，产生小延迟。\n\n**步骤5：生成token**\n- 整合常驻与虚拟块的计算结果","tool_calls":[]},"logprobs":null,"finish_reason":"length"}],"usage":{"prompt_tokens":15,"prompt_tokens_details":{"cached_tokens":0},"completion_tokens":1024,"completion_tokens_details":{"reasoning_tokens":0},"total_tokens":1039,"batch_size" ` atb qwen 异步 `[2026-01-21 17:38:02,205] [1639725] [281468181718400] [tokenizer] [INFO] [io_utils.py-15] : tokenizer start. [2026-01-21 17:38:02,205] [1639723] [281468181718400] [tokenizer] [INFO] [io_utils.py-15] : tokenizer start. [2026-01-21 17:38:08.393860] [1636970] [1636981] [server] [INFO] [infer_tokenizer.cpp:411] [tokenizer] Finished to init tokenizer sub process size 8 [2026-01-21 17:38:08.393903] [1636970] [1636981] [server] [INFO] [endpoint.cpp:158] [endpoint] mExpertParallel is false, healthchecker init skipped [2026-01-21 17:38:08.402387] [1636970] [node-13] [system] [server] [Start mindie server] [success] Daemon start success! curl http://localhost:7070/v1/chat/completions \ -d '{ "model": "qwen3", "messages": [ {"role": "user", "content": "告诉我大模型推理中的vllm的具体实现细节"} ], "stream": false }' {"id":"endpoint_common_0","object":"chat.completion","created":1768988738,"model":"qwen3","choices":[{"index":0,"message":{"role":"assistant","content":"<think>\n好的，我现在要详细了解一下vLLM的具体实现细节。首先，我之前知道vLLM是一个高效的大语言模型推理框架，但具体它是如何工作的呢？我需要从几个方面来拆解：KV缓存优化、张量并行、PagedAttention机制、量化技术、动态批处理、内存管理以及分布式推理。可能还需要了解它如何与其他框架如Hugging Face Transformers或DeepSpeed比较。\n\n首先，KV缓存优化。KV缓存是Transformer模型中的关键部分，用于存储键和值向量。在传统的实现中，KV缓存可能会占用大量内存，尤其是在处理长序列时。vLLM可能通过某种方式优化了KV缓存的存储和访问，比如使用分页技术，类似于操作系统的内存分页，将KV缓存分割成块，并按需加载到内存中。这样可以减少内存占用，同时保持高效的访问速度。我需要确认这个分页机制是如何工作的，是否使用了硬件加速，比如GPU的内存管理单元。\n\n接下来是张量并行。张量并行是将模型的权重矩阵分割到多个设备上，每个设备处理一部分计算。在vLLM中，张量并行可能被用来扩展模型的规模，使得单个设备无法处理的模型可以通过多个设备并行处理。具体来说，可能是在线性层（如注意力层的Q、K、V投影）中将权重矩阵进行分割，每个设备计算对应的子矩阵，然后通过AllReduce操作聚合结果。需要了解vLLM如何实现张量并行，是否使用了特定的通信库（如NCCL或PyTorch的分布式包），以及如何优化通信开销。\n\n然后是PagedAttention机制。这个听起来像是将注意力计算中的KV缓存分页存储，类似于分页内存管理。传统的注意力机制在处理长序列时，KV缓存会占用大量内存，而PagedAttention可能将KV缓存分成固定大小的块，仅在需要时加载到内存中。这样可以减少内存占用，同时通过预取（prefetching）技术提前加载可能需要的块，减少等待时间。需要了解这种分页机制如何与注意力计算结合，是否使用了硬件特性（如GPU的缓存）来加速访问，以及如何管理分页表。\n\n量化技术方面，vLLM可能采用了模型量化的方法，将模型参数从高精度（如FP32）转换为低精度（如INT8或FP16），从而减少内存占用和计算量。量化可能包括权重量化、激活值量化以及混合精度量化。需要了解vLLM使用了哪种量化方法，是否动态调整精度，以及如何处理量化带来的精度损失（如使用量化感知训练或后训练量化）。\n\n动态批处理（Dynamic Batching）是另一个关键点。动态批处理可以将多个请求合并成一个批次进行处理，从而提高GPU利用率。vLLM可能通过某种调度机制，在运行时动态组合来自不同请求的输入序列，生成更大的批次。需要了解这种批处理策略如何处理不同长度的序列，如何避免长序列阻塞短序列的处理（如使用优先级队列或时间片轮转），以及如何平衡批处理带来的延迟和吞吐量的提升。\n\n内存管理方面，vLLM可能采用了高效的内存分配策略，比如使用内存池或预分配内存块，减少频繁的内存分配和释放带来的开销。此外，可能还使用了异构内存（如GPU和CPU内存协同）来优化数据传输和存储。需要了解vLLM如何管理不同设备之间的内存，是否支持零拷贝或高效的内存映射技术。\n\n分布式推理部分，vLLM可能支持模型并行和数据并行。模型并行将模型的不同层分配到不同的设备上，而数据并行将同一模型的多个副本分配到不同设备上处理不同的数据批次。需要了解vLLM如何实现这两种并行方式，是否支持自动并行策略选择，以及如何优化跨设备的通信和同步。\n\n此外，vLLM可能与其他框架（如Hugging Face Transformers）有接口兼容性，允许用户轻松地将现有模型迁...... ` # CheckList > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x]。 - [x] 代码注释完备 - [ ] 正确记录错误日志 - [x] 进行了返回值校验 (禁止使用void屏蔽安全函数、自研函数返回值；考虑接口的异常场景；调用底层组件接口时，需要进行返回值校验) - [x] 进行了空指针校验 - [x] 若存在资源申请，使用后资源被正确的释放了 - [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 - [x] 按照[代码仓中提供的格式模板](https://gitcode.com/Ascend/MindIE-LLM/blob/master/.clang-format)，使用clang-format工具格式化代码 - [ ] 符合Ascend社区的编码规范。[C++ 语言编程指导](https://gitcode.com/Ascend/community/blob/master/docs/contributor/Ascend-cpp-coding-style-guide.md) | [C++ 语言安全编程指导](https://gitcode.com/Ascend/community/blob/master/docs/contributor/Ascend-cpp-secure-coding-guide.md) See merge request: Ascend/MindIE-LLM!255	4 个月前
test_router_qwen3_moe.py	qwen3_moe aclgraph回合dev Co-authored-by: bowenli<libowen82@huawei.com> # message auto-generated for no-merge-commit merge: !158 merge dev_qwen3_moe into dev qwen3_moe aclgraph回合dev Created-by: bowenli Commit-by: bowenli Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20251225 --> # 合入背景 > 请描述为什么要做这个PR内的改动。\ > 如涉及，请关联前序PR或同特性/需求下的其他PR。\ > 如果是修复之前PR引入的问题，请关联引入问题的PR。\ > 注意：Fixes #ISSUE ID会自动关闭issue，如问题部分解决请不要使用Fixes，可以用Fix part of #ISSUE ID替代. aclgraph qwen3-moe模型侧代码适配 # 修改内容 > 请描述修改内容的具体实现，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列。\ > 如果是需求或者重构类的PR，需要补充详细设计文档（说明上下游组件关系、时序图、类图、DFX能力等内容）。 新增qwen3_moe文件夹代码，以及相关测试文件 # 资料变更 > 请确认是否涉及资料变更。如涉及，需要在PR中体现，并简要说明修改内容。如不涉及，需填写“不涉及”。 不涉及 # 接口变更 > 请确认是否涉及跨代码仓或者客户面可见的接口变更。如涉及，需要详细说明接口以及对应的变更内容，同时需要在资料中体现。如不涉及，需填写“不涉及”。 不涉及 # 测试结果 > 请说明测试场景，测试方法以及测试结果。\ > 测试用例设计时需考虑硬件、部署方式、功能、性能、精度、显存等维度。  # CheckList > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x]。 - [x] 代码注释完备 - [x] 正确记录错误日志 - [x] 进行了返回值校验 (禁止使用void屏蔽安全函数、自研函数返回值；考虑接口的异常场景；调用底层组件接口时，需要进行返回值校验) - [x] 进行了空指针校验 - [x] 若存在资源申请，使用后资源被正确的释放了 - [x] 若涉及多线程场景，考虑了并发场景，不存在死锁问题 - [x] 按照[代码仓中提供的格式模板](https://gitcode.com/Ascend/MindIE-LLM/blob/master/.clang-format)，使用clang-format工具格式化代码 - [x] 符合Ascend社区的编码规范。[C++ 语言编程指导](https://gitcode.com/Ascend/community/blob/master/docs/contributor/Ascend-cpp-coding-style-guide.md) | [C++ 语言安全编程指导](https://gitcode.com/Ascend/community/blob/master/docs/contributor/Ascend-cpp-secure-coding-guide.md) See merge request: Ascend/MindIE-LLM!158	4 个月前