concurrent.futures并发numpy.dot结果与串行结果差异排查

核心成因 #

该差异不是并发逻辑错误，是浮点数运算特性与计算顺序变化共同导致的正常现象，具体原因如下：

• float64类型浮点数仅支持15~17位有效数字，且浮点数加法不满足结合律，计算过程中累加顺序不同，舍入误差的累积结果就会出现差异。观测到的1e-14量级偏差完全在float64的正常舍入误差范围内。
• 串行执行np.dot时，NumPy调用的底层BLAS后端（OpenBLAS、MKL等）会使用固定的分块策略、固定的累加顺序完成计算，因此连续两次串行运行结果完全一致。
• 拆分任务并发计算时，子任务的调度完成顺序、子任务内部BLAS的计算路径、最终合并结果时的累加顺序，都和串行整段计算的顺序不一致，自然会产生微小的舍入偏差。
• 观测到的特殊现象均符合该逻辑：
  • 偏差仅在float64类型下出现、int64类型无异常：因为整数在有效取值范围内运算无精度损失，只要计算逻辑正确，顺序变化不会改变结果。
  • 多次运行aa == cc的结果不稳定、True/False随机出现：线程/进程调度本身存在随机性，每次运行的计算、累加顺序不完全固定，误差出现的位置也会随之变化。
  • ThreadPoolExecutor和ProcessPoolExecutor都会触发问题：偏差和并发实现范式无关，只和计算顺序改变有关。
• 现有代码存在放大随机性的问题：cf.wait()返回的done集合是无序的，直接遍历该集合取结果时，两个子任务的返回值顺序可能随机调换，进一步改变最终sum的累加顺序，增加误差出现的概率。

修复方案 #

根据业务对结果一致性的要求选择对应方案即可：

• 通用标准方案：放弃浮点数精确相等判断，改用容差校验
  浮点数计算场景下用==做精确相等判断本身就是不符合数值计算规范的做法，直接替换为NumPy提供的容差比较接口即可：

  # 替换原有的 aa == cc
  np.allclose(aa, cc, rtol=1e-12, atol=1e-12)
  

  上述判断会自动忽略1e-12量级以内的舍入误差，完全覆盖观测到的1e-14级偏差，判定结果符合数值正确性要求。
• 位精确结果方案：强制固定全链路计算顺序
  如果业务强制要求结果和串行完全位一致，需要做两处修改：
  1. 在代码最开头添加环境变量配置，关闭NumPy底层BLAS的多线程调度，固定BLAS计算顺序：

     import os
     os.environ["OPENBLAS_NUM_THREADS"] = "1"
     os.environ["MKL_NUM_THREADS"] = "1"
     import numpy as np
     

  2. 修正结果收集逻辑，按任务提交顺序取结果，不要用cf.wait返回的无序集合遍历：

     with cf.ThreadPoolExecutor(max_workers=ncpus) as executor:
         futures = []
         rstart = 0
         rend = batchsize
         for split_arr in a_split:
             futures.append(executor.submit(np.dot, split_arr, W[rstart:rend, :]))
             rstart += batchsize
             rend += batchsize
     # 按提交顺序取结果，保证累加顺序固定
     results = [f.result() for f in futures]
     cc = np.sum(results, dtype="float64", axis=0)
     

  注意：即使做了上述修改，拆分计算的累加顺序和原生np.dot的内部累加顺序依然可能存在差异，最稳妥的方式还是配合容差判断使用。
• 无误差方案：使用定点整数运算
  如果业务完全不能接受任何浮点误差，可以将浮点值按精度要求缩放为整数，所有计算用整数完成后再缩放回浮点值，该方案实现成本较高，非特殊场景不推荐使用。

内容的提问来源于stack exchange，提问作者Sun Bear