限制与约束

仅 Atlas 800I A2 推理产品支持此特性。
LLaMA3.1-70b浮点模型和Qwen2-72B 浮点模型支持对接此特性。
暂不支持与LoRA特性配合。
该特性不能和PD分离、Multi-LoRA、并行解码、Prefix Cache、Function Call、多机推理和长序列特性同时使用。
该特性支持的量化特性：W8A8，其他量化特性暂不支持。

原理

大模型推理过程中，推理性能主要受访存速度限制，在此种条件下可见模型推理耗时主要与Forward Tokens的数量呈线性关系，如图1所示。因此，打开SplitFuse时，当需要增量推理时延满足特定控制服务级别目标（SLO），如90%轮次的增量推理时延（SLO_P90 decode时延）小于50ms时，可以通过控制SplitFuse特性的ChunkSize进行控制。需要说明的是减少ChunkSize在约束SLO指标的同时，可能会增加推理轮次，从而产生额外的开销导致总体吞吐的下降。

图1 模型推理耗时与Forward Tokens的拟合关系
点击放大

图2 模型推理耗时与系统吞吐
点击放大

操作步骤

本章节简单介绍如何使用Splitfuse功能。

打开MindIE Server的config.json文件。

cd {MindIE安装目录}/latest/mindie-service/
vi conf/config.json

配置“plugin_params”、“templateType”和“enableSplit”参数开启Splitfuse特性。对于性能调优，需要编辑config.json配置文件中的ScheduleConfig部分，建议将“maxBatchSize”与“splitChunkTokens”参数配置为相同大小，并通过调整这两个参数的值来控制SLO的Decode时延指标。

请参见以下配置样例，SplitFuse的相关配置已加粗显示，参数具体解释请参见表1。

        "ModelDeployConfig":
        {
            "maxSeqLen" : 65536,
            "maxInputTokenLen" : 65536,
            "truncation" : false,
            "ModelConfig" : [
                {
                    "modelInstanceType": "Standard",
                    "modelName" : "llama2-7b",
                    "modelWeightPath" : "/home/models/llama2-7b/",
                    "worldSize" : 8,
                    "cpuMemSize" : 5,
                    "npuMemSize" : -1,
                    "backendType": "atb",
                    "plugin_params": "{\"plugin_type\":\"splitfuse\"}"
                }
            ]
        },
        "ScheduleConfig":
        {
            "templateType": "Mix",
            "templateName" : "Standard_LLM",
            "cacheBlockSize" : 128,

            "maxPrefillBatchSize" : 40,
            "maxPrefillTokens" : 65536,
            "prefillTimeMsPerReq" : 600,
            "prefillPolicyType" : 0,

            "decodeTimeMsPerReq" : 50,
            "decodePolicyType" : 0,
            "policyType": 0,

            "maxBatchSize" : 256,
            "maxIterTimes" : 512,
            "maxPreemptCount" : 0,
            "supportSelectBatch" : false,
            "maxQueueDelayMicroseconds" : 5000,

            "enableSplit": true,
          "splitType": false,
          "splitStartType": false,
          "splitChunkTokens": 256,
          "splitStartBatchSize": 16
        }

表1 Splitfuse补充参数
配置项	取值类型	说明
ModelDeployConfig
plugin_params	std::string	必选； "{\"plugin_type\":\"splitfuse\"}"：表示执行splitfuse。不添加该字段或将该字段设置为""：表示默认不生效任何插件功能。
ScheduleConfig
templateType	std::string	必选； Mix：混部推理场景；Prefill和Decode可同时进行批处理。 Standard：基线场景；表示Prefill和Decode各自分别组batch。
policyType	Enum	可选； 0：先入先出策略（FCFS）。 4：短任务优先（SJF）。 5：长任务优先（LJF）。 6：多级反馈队列（Skip-Join MLFQ）。 7：短任务优先多级反馈队列（SJF-MLFQ）。
enableSplit	bool	必选； true：开启对prompt进行动态切分。 false：关闭对prompt进行动态切分。
splitType	bool	可选； true：优化切分长度，仅对超出切分长度2倍的prompt进行切分。 false：按照配置的切分长度切分。建议值：false；默认值：false
splitStartType	bool	可选； true：每次组batch时重置切分状态，重新判断当前是否满足splitStartBatchSize false：首次满足splitStartBatchSize条件后，不再重置切分状态建议值：false；默认值：false
splitChunkTokens	uint32_t	可选；当前参与组batch的总token个数。取值范围：[1,8192]；建议值：16的整数倍；默认值：512
splitStartBatchSize	uint32_t	可选；当batch数达到该值时开启切分。取值范围：[0,maxBatchSize]；建议值：16；默认值：16

保存修改后的配置并启动服务化：
```
./bin/mindieservice_daemon
```

本样例以MindIE Benchmark方式展示调优方式。config.json配置完成后，执行如下MindIE Benchmark启动命令。

benchmark \
--DatasetPath "/{数据集路径}/GSM8K" \
--DatasetType "gsm8k" \
--ModelName llama2-7b \
--ModelPath "/{模型权重路径}/llama2-7b" \
--TestType client \
--Http https://{ipAddress}:{port} \
--ManagementHttp https://{managementIpAddress}:{managementPort} \
--Concurrency 100 \
--RequestRate 5 \
--TaskKind stream \
--Tokenizer True \
--MaxOutputLen 512 \
--TestAccuracy True

根据首Token时延和Decode时延的实际数据调整参数。
- 首Token时延和Decode时延（均值，P90）都满足约束阈值，则加大“RequestRate”的值。
- Decode时延均值位于约束阈值以内，而首Token时延均值大于约束阈值。则“RequestRate”已大于系统吞吐GenerateSpeed，为满足约束需降低“RequestRate”的值。
- 当首Token时延均值和Decode时延均值满足阈值约束，而Decodes时延P90不满足均值时，则考虑降低ChunkSize减小切分，但该操作可能影响吞吐。
- 在输入问题长短不一的场景下，PD混部策略产生更多调度空泡；而SplitFuse特性相对PD混部策略受调度空泡影响较少，所以相对PD混部策略的优势会增加。
使用MindIE Benchmark对GSM8K数据集进行测试的结果如下：
- 关闭SplitFuse时：
  测试集：GSM8K；并发数：100。
- 打开SplitFuse时：
  测试数据集：GSM8K；并发数：100；相对基线吞吐：101.59%；相对基线首Token时延：22.42%；

使用样例

限制与约束

原理

操作步骤