首token时延限制严格，非首token时延也有限制

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

• 服务端：
  • “maxBatchSize”调小到卡对应的时延，一般情况下“maxBatchSize”越小，则Decode时延越小。
  • 设置supportSelectBatch为false。
• 客户端：
  • 按并发数发送请求：客户端Concurrency通常配置为maxBatchSize-1。
  • 按频率发送请求：则Concurrency可设置为1000，请求发送频率根据实际业务场景或按模型实际QPS设置。

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所示，与2.a中计算出来的值一致。

   图1 启动成功
   
2. 根据2.c计算出“maxBatchSize”的取值范围为[362，1088]，设置初始值为435；“maxPrefillBatchSize”参数的值设置为“maxBatchSize”值的一半，取值为217。
   

   需要将“supportSelectBatch”参数设置为false，以获取更低的首token时延。

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

   重开一个窗口，使用以下命令发送请求，获取当前首token平均值（Average）和DecodeTime的平均值（Average），如图2所示，此时首token平均时延为21252.0612ms，decode平均时延为73.7486ms。

   benchmark \
   --DatasetPath "/{数据集路径}/GSM8K" \          //数据集路径
   --DatasetType "gsm8k" \                                                         //数据集类型
   --ModelName LLaMa3-8B \                                                         //模型名称
   --ModelPath "/{模型路径}/LLaMa3-8B" \                                               //模型路径
   --TestType client \                                                             //模式选择
   --Http https://{ipAddress}:{port} \                                             //请求url
   --ManagementHttp https://{managementIpAddress}:{managementPort}  \                                   //管理面url
   --Concurrency 1000 \                                                            //并发数
   --TaskKind stream \                                                             //Client不同推理模式，此处为文本流式推理
   --Tokenizer True \                                                              //分词向量化标识
   --MaxOutputLen 512                                                              //最大输出长度

   图2 maxBatchSize取值为435时首token平均时延（Average）和Decode的平均时延（Average）
   

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

4. 设置“maxBatchSize”的值为300，“maxPrefillBatchSize”参数的值设置为150。然后执行3，继续观察首token平均时延和Decode平均时延，执行结果如图3所示，此时首token平均时延为11265.0242ms，Decode平均时延为61.9161ms。
   图3 maxBatchSize取值为300时首token平均时延（Average）和Decode的平均时延（Average）
   

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

5. 设置“maxBatchSize”的值为200，“maxPrefillBatchSize”参数的值设置为100。然后执行3，继续观察首token平均时延和Decode平均时延，执行结果如图4所示，此时首token平均时延为6364.6507ms，Decode平均时延为49.9804ms。
   图4 maxBatchSize取值为200时首token平均时延（Average）和Decode的平均时延（Average）
   

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