MindIE 服务化性能 MindIE service 如何调优？限制非首 token 时延的极限吞吐

1 简介

MindIE Service 是面向通用模型场景的推理服务化框架，通过开放、可扩展的推理服务化平台架构提供推理服务化能力，支持对接业界主流推理框架接口，满足大语言模型的高性能推理需求。

MindIE Service 的组件包括 MindIE Service Tools、MindIE Client、MindIE MS（MindIE Management Service）和 MindIE Server，通过对接昇腾推理加速引擎带来大模型在昇腾环境中的性能提升，并逐渐以高性能和易用性牵引用户向 MindIE 原生推理服务化框架迁移。其架构图如图 1 所示。

MindIE Service 提供推理服务化部署和运维能力。

• MindIE Service Tools：昇腾推理服务化工具；主要功能有大模型推理性能测试、精度测试、可视化以及自动寻优的能力，并且支持通过配置提升吞吐。

• MindIE Client：昇腾推理服务化完整的 Client 客户端；配套昇腾推理服务化 MindIE Server 提供完整的推理服务化能力，包括对接 MindIE Server 的通信协议、请求和返回的接口，提供给用户应用对接。

• MindIE MS：服务策略管理，提供服务运维能力。主要功能包括模型 Pod 级和 Pod 内实例级管理、简化部署并提供服务质量监控、模型更新、故障重调度和自动扩缩负载均衡能力，不仅能够提升服务质量，同时也能提高推理硬件资源利用率。

• MindIE Server：推理服务端；提供模型推理服务化能力，支持命令行部署 RESTful 服务。

• EndPoint：提供 RESTful 接口；EndPoint 面向推理服务开发者提供 RESTful 接口，推理服务化协议和接口封装，支持 Triton/OpenAI/TGI/vLLM 主流推理框架请求接口。

• GMIS：模型推理调度器，提供多实例调度能力；实现从推理任务调度到任务执行的可扩展架构，适应各类推理方法。

• BackendManager：模型执行后端，昇腾后端和自定义后端的管理模块；Backend 管理模块面向不同推理引擎，不同模型，提供统一抽象接口，便于扩展，减少推理引擎、模型变化带来的修改。

• MindIE Backends：支持昇腾 MindIE LLM 后端。

• MindIE LLM：提供大模型推理能力，同时提供多并发请求的调度功能。

2 性能调优流程

通过参数调优，使吞吐率（TPS）达到时延约束条件下的最大值。首先，大家需要对调优的一些参数做一个了解。

2.1 最优性能参数配置项

最优性能配置各参数说明及取值如下表所示。

最优性能参数配置

3 具体示例

各个参数操作的具体示例可以参见：https://www.hiascend.com/document/detail/zh/mindie/20RC2/mindieservice/servicedev/mindie_service0105.html本文只对场景“不考虑时延的极限吞吐”进行说明

４ 限制非首 token 时延的极限吞吐

以 Decode 平均时延限制 50ms 以内为目标，限制非首 token 时延的极限吞吐的调试方式如下所示。

• 服务端：

• “maxBatchSize”调小到卡对应的时延，一般情况下“maxBatchSize”越小，则 Decode 时延越小。

• 设置 supportSelectBatch 为 true，“prefillTimeMsPerReq”和“decodeTimeMsPerReq”按照模型实际平均首 token 时延和 Decode 时延进行设置。

• 客户端：

• 按并发数发送请求：客户端 Concurrency 通常配置为 maxBatchSize-1。

• 按频率发送请求：则 Concurrency 可设置为 1000，请求发送频率根据实际业务场景或按模型实际 QPS 设置。

4.1 操作步骤

1. 在裸机中执行以下命令开启 CPU 高性能模式和透明大页，开启后可提升性能，建议开启。

2. 开启 CPU 高性能模式，在相同时延约束下，TPS 会有约 3%的提升。

     cpupower -c all frequency-set -g performance

• 开启透明大页，多次实验的吞吐率结果会更稳定。

     echo always > /sys/kernel/mm/transparent_hugepage/enabled

 说明
 服务化进程可能与模型执行进程抢占CPU资源，导致性能时延波动；可以在启动服务时将服务化进程手动绑核至CPU奇数核，以减少CPU抢占影响，降低性能波动，具体方法如下所示。
 1. 使用lscpu命令查看系统CPU配置情况。

        lscpu

    CPU相关配置回显信息如下所示：

        NUMA:                             NUMA node(s):         8          NUMA node0 CPU(s):    0-23          NUMA node1 CPU(s):    24-47          NUMA node2 CPU(s):    48-71          NUMA node3 CPU(s):    72-95          NUMA node4 CPU(s):    96-119          NUMA node5 CPU(s):    120-143          NUMA node6 CPU(s):    144-167          NUMA node7 CPU(s):    168-191

 2. 使用taskset -c命令将服务化进程绑核至CPU奇数核并启动。

        taskset -c $cpus ./bin/mindieservice_daemon

    $cpus：为CPU配置回显信息中node1、node3、node5或node7的值。

2. 使用以下命令启动服务，以当前所在 Ascend-mindie-service_{version}_linux-*{arch}*目录为例。

   ./bin/mindieservice_daemon

回显如下则说明启动成功。

   Daemon start success!

服务启动后，可通过 info 级打屏日志 k_caches[0].shape=torch.Size([npuBlockNum, x, x, x])中 torch.Size 的第一个值获取 npuBlockNum 的值，如图1所示，与3.a中计算出来的值一致。

图 1 启动成功

3. 根据3.c计算出“maxBatchSize”的取值范围为[90，272]，设置初始值为 200；“maxPrefillBatchSize”参数的值设置为“maxBatchSize”值的一半，取值为 100。

4. 配置完成后，用户可使用 HTTPS 客户端（Linux curl 命令，Postman 工具等）发送 HTTPS 请求，此处以 Linux curl 命令为例进行说明。

5. 重开一个窗口，使用以下命令发送请求，获取当前 DecodeTime 的平均值（Average），此时 Decode 平均时延为 60.1889ms。

   benchmark \   --DatasetPath "/{数据集路径}/GSM8K" \   --DatasetType "gsm8k" \   --ModelName LLaMa3-8B \   --ModelPath "/{模型路径}/LLaMa3-8B" \   --TestType client \   --Http https://{ipAddress}:{port} \   --ManagementHttp https://{managementIpAddress}:{managementPort}  \   --Concurrency 1000 \   --TaskKind stream \   --Tokenizer True \   --MaxOutputLen 512

以上结果超过了 Decode 平均时延为 50ms 的限制，所以需要调小“maxBatchSize”的值继续调试。

5. 设置“maxBatchSize”的值为 100，“maxPrefillBatchSize”参数的值设置为 50。然后执行4，继续观察 Decode 平均时延，此时 decode 平均时延为 46.9689ms。

6. 以上结果可以看到 Decode 平均时延满足 50ms 以内的限制，但是还未接近 50ms，所以需要调大“maxBatchSize”的值继续进行调试。

7. 设置“maxBatchSize”的值为 150，“maxPrefillBatchSize”参数的值设置为 75。然后执行4，继续观察 Decode 平均时延，此时 decode 平均时延为 49.846ms。

8. 以上结果可以看到 Decode 平均时延已经很接近 50ms，此时几乎已达到限制 Decode 时延下的最大吞吐量。如需获取 Decode 平均时延更接近 50ms 时的“maxBatchSize”值，请根据以上操作步骤继续调试。