不考虑时延的极限吞吐
不考虑时延的极限吞吐的调试方式如下所示。
- 服务端:
- “maxBatchSize”尽量调大到显存限制,一般情况下“maxBatchSize”值越大,则吞吐越大;若“maxBatchSize”增大时吞吐量不增反降,则停止调整。
- 设置supportSelectBatch=True,“prefillTimeMsPerReq”和“decodeTimeMsPerReq”按照模型实际平均首token时延和decode时延进行设置。
- 客户端
- 按并发数发送请求:客户端Concurrency通常配置为maxBatchSize的值减1。
- 按频率发送请求:则Concurrency可设置为1000,请求发送频率根据实际业务场景或按模型实际QPS设置。
操作步骤
- 使用以下命令启动服务,以当前所在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所示,与2.a中计算出来的值一致。
- 根据2.c计算出“maxBatchSize”的取值范围为[362,1088],设置初始值为435;“maxPrefillBatchSize”参数的值设置为“maxBatchSize”值的一半,取值为217。
- 配置完成后,用户可使用HTTPS客户端(Linux curl命令,Postman工具等)发送HTTPS请求,此处以Linux curl命令为例进行说明。
重开一个窗口,使用以下命令发送请求,获取当前的吞吐量(GenerateSpeedPerClient),如图2所示,此时吞吐量为2.8453 token/s。
benchmark \ --DatasetPath "/{模型库安装路径}/tests/modeltest/dataset/full/GSM8K" \ //数据集路径 --DatasetType "gsm8k" \ //数据集类型 --ModelName LLaMa3-8B \ //模型名称 --ModelPath "/{data}/LLaMa3-8B" \ //模型路径 --TestType client \ //模式选择 --Http https://{ipAddress}:{port} \ //请求url --Concurrency 1000 \ //并发数 --TaskKind stream \ //Client不同推理模式,此处为文本流式推理 --Tokenizer True \ //分词向量化标识 --MaxOutputLen 512 //最大输出长度
- 以“100”为单位且取整向上调试“maxBatchSize”的值,所以设置“maxBatchSize”的值为500,“maxPrefillBatchSize”参数的值设置为250。然后执行3,继续观察不考虑时延的极限吞吐,执行结果如图3所示,此时吞吐量为2.9803 token/s。
- 由于“maxBatchSize”的值为500的吞吐量优于“maxBatchSize”的值为435,所以继续设置“maxBatchSize”的值为600,“maxPrefillBatchSize”参数的值为300。然后执行3,观察其吞吐量,执行结果如图4所示,此时吞吐量为2.7588 token/s。
当“maxBatchSize”的值为600时,此时的吞吐量明显下降,停止调高“maxBatchSize”的值。
综上所述,当“maxBatchSize”的值在500左右时,可达到极限吞吐。如需获取达到极限吞吐时更精准的“maxBatchSize”值,请根据以上操作步骤继续调试。
父主题: 最佳实践