写点什么

MindIE 服务化性能 MindIE service 如何调优?首 token 时延限制严格,非首 token 时延也有限制

作者:zjun
  • 2025-06-25
    上海
  • 本文字数:2798 字

    阅读完需:约 9 分钟

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本文只对场景“不考虑时延的极限吞吐”进行说明

4 首 token 时延限制严格,非首 token 时延也有限制

以首 token 平均时延限制在 8000ms 以内、Decode 平均时延限制 50ms 以内为目标,首 token 时延限制严格,且非首 token 时延也有限制的调试方式如下所示。


  • 服务端:

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

  • 设置 supportSelectBatch 为 false。

  • 客户端:

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

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


  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的值。
复制代码


  1. 使用以下命令启动服务,以当前所在 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。说明需要将“supportSelectBatch”参数设置为 false,以获取更低的首 token 时延。4. 配置完成后,用户可使用 HTTPS 客户端(Linux curl 命令,Postman 工具等)发送 HTTPS 请求,此处以 Linux curl 命令为例进行说明。重开一个窗口,使用以下命令发送请求,获取当前首 token 平均值(Average)和 DecodeTime 的平均值(Average),此时首 token 平均时延为 21252.0612ms,decode 平均时延为 73.7486ms。


   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
复制代码


以上结果超过了首 token 平均时延为 8000ms 和 Decode 平均时延为 50ms 的限制,所以需要调小“maxBatchSize”的值继续调试。5. 设置“maxBatchSize”的值为 150,“maxPrefillBatchSize”参数的值设置为 75。然后执行4,继续观察首 token 平均时延和 Decode 平均时延,此时首 token 平均时延为 11265.0242ms,Decode 平均时延为 61.9161ms。以上结果同样超过了首 token 平均时延为 8000ms 和 Decode 平均时延为 50ms 的限制,所以需要调小“maxBatchSize”的值继续调试。6. 设置“maxBatchSize”的值为 100,“maxPrefillBatchSize”参数的值设置为 50。然后执行4,继续观察首 token 平均时延和 Decode 平均时延,此时首 token 平均时延为 6364.6507ms,Decode 平均时延为 49.9804ms。


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

用户头像

zjun

关注

还未添加个人签名 2020-03-06 加入

还未添加个人简介

评论

发布
暂无评论
MindIE服务化性能MindIE service如何调优?首token时延限制严格,非首token时延也有限制_昇腾_zjun_InfoQ写作社区