在Dify 的工作流定义当中，倘若碰到 LLM 需要接收可迭代对象（比如数组）作为参数的情形，为了加快⏩ LLM 生成答案的速度，我们能够思考把可迭代对象中的 n 项当作原本每次请求 LLM 的参数。如此一来，原本只请求一次 LLM 的操作，将转变为请求 n 次 LLM ，如下图：

在 Dify 中，这里的迭代是同步进行的，意味着每次仅会执行一次迭代内的工作。那么假设执行一次迭代的平均时间是t，迭代的次数为n，则总时间 T1 ≈ n * t。

然而在 Coze 中，LLM 的执行能够配置为Batch processing（批处理）模式，同样是把可迭代的操作从 1 次变为n次。其不同之处在于，通过配置Parallel runs参数，可以设定 LLM 节点同时执行的数量，这表明 Coze 的批处理模式是能够并发执行的。那么其执行的总时间（假如总调用次数 <= Parallel runs）为T2 = Max(t1,t2,t3,...) ≈ t，并且通常情况下 T2 < T1 是成立的。

由于Dify提供了直接将工作流作为接口调用的方式，而Coze并没有提供相关的功能，我们的应用将使用Dify作为机器人的开发平台。

既然平台侧没有提供并发的方式，我们就需要从请求接口的方向考虑并发的可能性。

1. Dify设置了一些变量的最大个数，比如字符串，Object数组的长度最大为30，数字字符串的长度最大为1000。所以当我们的中间变量可以超过这个限制的话，我们可以考虑将中间变量使用JSON.stringify进行字符串转化（最大长度为80000），当需要使用的时候，通过在代码节点里面使用JSON.parse进行转化即可。

2. 一个迭代最大执行的轮数为50。

3. 在实际运用中，当LLM一次性处理的复杂文案数量在一定数量时，容易出现生成标识符的大模型会出现缺漏掉一些数量文案标识符的现象，这对于我们平台整体的可靠性与稳定性是有相当大部分的影响，判断是超出LLM一次性可返回的Token数导致的。

请求参数

并发策略的设置

在代码层面上，S1将针对两类不同请求的方式走不同的工作流：

代码如下：

请求参数

并发策略的设置

综上所述，在此接口中，我们能够针对目标语言以及需要进行优化检测的翻译内容分别予以分割后再进行请求，原因在于返回的结果必然是唯一对应的。

所以，相应的策略如下：语言的分割维度设定为3，与 S1 保持一致；而对于翻译内容，或者说是依据标识符数组来进行分割，当前维度设置为20，不过这个后续或许还需要逐步进行调优。

切割的实现

我们运用 console.time() 以及 console.timeEnd() 来对请求的时间予以记录，每种情况均通过三次测试并取平均值进行对比，以此来评判优化的成效。