1. 并行计算基础：为什么回测需要并行？单核瓶颈与多核优势

做量化回测的朋友，十有八九都遇到过这种情况：策略写好了，参数调优跑起来，结果一跑就是几个小时，甚至通宵。我刚开始做回测那会儿，就吃过这个亏。一个简单的双均线策略，参数网格稍微大一点，单核跑完要三个多小时。那时候我就在想，这效率也太低了。

为什么会这样？说白了，回测本质上是一个计算密集型任务。你想想看，一只股票的历史数据可能有十年，每分钟、每秒钟的行情都要处理。如果再加上几百个参数组合，计算量就是指数级增长。单核处理器就像一个人搬砖，再快也有限。

1.1 单核瓶颈：为什么你的CPU在“摸鱼”

先看一个典型的回测流程。假设我们要测试一个简单的动量策略：

# 伪代码：单核回测流程
for param_window in [5, 10, 20, 30, 60]:  # 参数遍历
    for stock in stock_list:               # 股票遍历
        for day in range(len(data)):       # 时间遍历
            signal = calculate_signal(data, param_window, day)
            if signal == BUY:
                execute_trade(day, stock)
            update_portfolio(day)

这个三层循环，就是典型的单核瓶颈。我曾在项目中遇到过，一个包含500只股票、5年数据、50组参数的回测任务，单核跑完需要整整8个小时。你想想看，如果策略需要反复调优，一天能跑几次？

单核的瓶颈主要体现在三个方面：

• 计算资源闲置：CPU只有一个核心在工作，其他核心都在“看热闹”。现代CPU通常有4核、8核甚至更多，但单核程序只用了1/8的资源。
• 内存带宽浪费：单核处理数据时，内存带宽利用率很低。数据从内存到CPU的通道很宽，但单核只能用小水管。
• I/O等待阻塞：读取历史数据、写入回测结果时，CPU经常处于等待状态。单核下，等待就是真的等待，没法干别的。

1.2 多核优势：把“一个人搬砖”变成“一群人搬砖”

多核处理器的优势，说白了就是并行。你想想看，如果回测任务可以拆分成多个独立的小任务，每个核心处理一部分，那总时间就能大幅缩短。

我举个例子。还是刚才那个动量策略，如果用多核并行：

# 伪代码：多核并行回测
from multiprocessing import Pool

def backtest_single_param(param_window):
    """单个参数的回测任务"""
    results = []
    for stock in stock_list:
        for day in range(len(data)):
            signal = calculate_signal(data, param_window, day)
            if signal == BUY:
                execute_trade(day, stock)
            update_portfolio(day)
        results.append(stock_result)
    return results

# 创建进程池，并行执行
with Pool(processes=8) as pool:
    all_results = pool.map(backtest_single_param, [5, 10, 20, 30, 60])

这段代码把参数遍历拆成了独立任务。每个核心处理一组参数，互不干扰。在我的测试中，8核并行比单核快了将近7倍。嗯，这里要注意，不是简单的8倍，因为还有任务分配和结果汇总的开销。

多核的优势具体体现在：

• 参数并行：不同参数组合的回测完全独立，可以同时跑。这是最常用的并行方式。
• 股票并行：不同股票的回测也互不依赖，可以分给不同核心。
• 时间切片并行：把历史数据分成多个时间段，每个核心处理一段。不过这种方式要注意数据依赖。

1.3 并行计算的适用场景与限制

不是所有回测都适合并行。我踩过这个坑，得跟大家说说。

场景	是否适合并行	原因
参数网格搜索	✅ 非常适合	参数之间完全独立，无数据依赖
多品种回测	✅ 适合	不同品种的回测互不干扰
单品种单参数	❌ 不适合	计算量太小，并行开销反而更大
有状态依赖的策略	⚠️ 需谨慎	如持仓管理、资金管理有全局状态

我曾经犯过一个错误：把一个需要共享全局状态的策略强行并行。结果每个核心维护自己的持仓，最后汇总时发现交易信号完全对不上。嗯，从那以后，我每次并行前都会先问自己：这些任务真的独立吗？

1.4 并行计算的性能模型：Amdahl定律

说到并行，就绕不开Amdahl定律。这个定律告诉我们：程序的加速比受限于串行部分的比例。

公式很简单：

加速比 = 1 / (串行比例 + 并行比例 / 核心数)

举个例子。如果回测程序有10%的代码是串行的（比如数据加载、结果汇总），90%可以并行。那么：

• 4核：加速比 = 1 / (0.1 + 0.9/4) ≈ 3.08倍
• 8核：加速比 = 1 / (0.1 + 0.9/8) ≈ 4.71倍
• 16核：加速比 = 1 / (0.1 + 0.9/16) ≈ 6.40倍

你看，核心数翻倍，加速比并没有翻倍。这就是串行部分的瓶颈。我建议在做并行优化时，先看看串行部分能不能优化。有时候把数据加载从串行改成并行，效果比加核心还明显。

1.5 本章知识体系：并行回测的核心逻辑

下面这张图展示了并行回测的核心逻辑。从单核瓶颈出发，到多核优势，再到实际应用中的注意事项。

这张图把并行回测的核心逻辑串起来了。从左到右，从问题到解决方案，再到实际应用中的注意事项。我个人习惯在做并行优化前，先画一张这样的图，理清思路再动手。

---

公众号:蓝海资料掘金营，微信deep3321