商业机构的网站是什么酒店网站模板设计方案
以Decode平均时延限制50ms以内为目标，限制非首token时延的极限吞吐的调试方式如下所示。
- 服务端：
“maxBatchSize”调小到卡对应的时延，一般情况下“maxBatchSize”越小，则Decode时延越小。
设置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!
- 计算出“maxBatchSize”的取值范围为[362，1088]，设置初始值为435；“maxPrefillBatchSize”参数的值设置为“maxBatchSize”值的一半，取值为217。
- 配置完成后，用户可使用HTTPS客户端（Linux curl命令，Postman工具等）发送HTTPS请求，此处以Linux curl命令为例进行说明。
重开一个窗口，使用以下命令发送请求，获取当前DecodeTime的平均值（Average），如图2所示，此时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”的值继续调试。
- 设置“maxBatchSize”的值为300，“maxPrefillBatchSize”参数的值设置为150。继续观察Decode平均时延，执行结果decode平均时延为46.9689ms。
以上结果可以看到Decode平均时延满足50ms以内的限制，但是还未接近50ms，所以需要调大“maxBatchSize”的值继续进行调试。
- 设置“maxBatchSize”的值为350，“maxPrefillBatchSize”参数的值设置为175。继续观察Decode平均时延，执行结果decode平均时延为49.846ms。
结果可以看到Decode平均时延已经很接近50ms，此时几乎已达到限制Decode时延下的最大吞吐量。如需获取Decode平均时延更接近50ms时的“maxBatchSize”值，请根据以上操作步骤继续调试。