不考虑时延的极限吞吐的调试方式如下所示。

服务端：
- “maxBatchSize”尽量调大到显存限制，一般情况下“maxBatchSize”值越大，则吞吐越大；若“maxBatchSize”增大时吞吐量不增反降，则停止调整。
- 设置supportSelectBatch为true，“prefillTimeMsPerReq”和“decodeTimeMsPerReq”按照模型实际平均首token时延和Decode时延进行设置。
客户端：
- 按并发数发送请求：客户端Concurrency的值通常配置为maxBatchSize的值减1。
- 按频率发送请求：则Concurrency可设置为1000，请求发送频率根据实际业务场景或按模型实际QPS设置。

操作步骤

在裸机中执行以下命令开启CPU高性能模式和透明大页，开启后可提升性能，建议开启。
- 开启CPU高性能模式，在相同时延约束下，TPS会有~3%的提升。
```
cpupower -c all frequency-set -g performance
```
- 开启透明大页，多次实验的吞吐率结果会更稳定。
```
echo always > /sys/kernel/mm/transparent_hugepage/enabled
```
使用以下命令启动服务，以当前所在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.c计算出“maxBatchSize”的取值范围为[362，1088]，设置初始值为435；“maxPrefillBatchSize”参数的值设置为“maxBatchSize”值的一半，取值为217。
配置完成后，用户可使用HTTPS客户端（Linux curl命令，Postman工具等）发送HTTPS请求，此处以Linux curl命令为例进行说明。
重开一个窗口，使用以下命令发送请求，获取当前的吞吐量（GenerateSpeedPerClient），如图2所示，此时吞吐量为2.8453 token/s。
```
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
```
图2 maxBatchSize取值为435的吞吐量
以“100”为单位且取整向上调试“maxBatchSize”的值，所以设置“maxBatchSize”的值为500，“maxPrefillBatchSize”参数的值设置为250。然后执行4，继续观察不考虑时延的极限吞吐，执行结果如图3所示，此时吞吐量为2.9803 token/s。
图3 maxBatchSize取值为500的吞吐量
由于“maxBatchSize”的值为500的吞吐量优于“maxBatchSize”的值为435，所以继续设置“maxBatchSize”的值为600，“maxPrefillBatchSize”参数的值为300。然后执行4，观察其吞吐量，执行结果如图4所示，此时吞吐量为2.5206 token/s。
图4 maxBatchSize取值为600的吞吐量

当“maxBatchSize”的值为600时，此时的吞吐量明显下降，停止调高“maxBatchSize”的值。

综上所述，当“maxBatchSize”的值在500左右时，可达到极限吞吐。如需获取达到极限吞吐时更精准的“maxBatchSize”值，请根据以上操作步骤继续调试。