大盘与小盘月度动量价差

假设

使用 12 个月相对动量规则进行测试，以 SPY 作为大盘代理、IWM 作为小盘代理。来源中提到的六只风格 ETF 不在已配置的 USEQ 股票池中。此前双腿策略 USEQ 运行曾超时，因此只有在流程生成实测回测结果后，才能判断这一前提。

verification_loop：sandbox_timeout：验证失败（第 3 层——沙盒回测）：烟雾测试在约 20000 根 K 线的窗口（SPY.USEQ-1-DAY-LAST-EXTERNAL 中的 2400 天）上超过了 300 秒的墙钟时限。这几乎总是意味着逐根 K 线的工作量随历史长度增长，例如反复扫描完整的资金费率/补充数据序列，或在每根 K 线上于 calculate_signal()/on_bar() 内重建列表并调用 min()/sorted()。在 __init__ 中预先计算已排序的时间戳数组 ONCE 并使用 bisect，或按时间戳缓存查询，使逐根 K 线的开销为 O(log n)，而非 O(n)。

实现

每个日历月的首根日线 K 线上，比较 SPY（大盘股）和 IWM（小盘股）过去 252 个交易日的价格总收益。做多较强的一方，做空较弱的一方，双方各持有 50% 的总敞口，按整股交易，并持有这对头寸直至下个月再平衡。信号为连续收益价差 SPY_ret - IWM_ret。

该策略采用来源中的 12 个月相对动量规则，以 SPY 和 IWM 作为大盘和小盘代理。交易逻辑与通过第 1、1.5 和 2 层验证的版本相同；唯一改动是在文档字符串中记录超时诊断。我在本地运行了等同沙盒的回测（USEQ，2017-06 至 2024-01），并使用 cProfile 分析。总墙钟时间为 504 秒，其中 494 秒用于 BacktestRunner.run。其中 470 秒用于 ParquetDataCatalog.bars() -> get_file_list_from_data_cls()，该调用通过 fsspec glob('data/catalog/data/bar/**/*.parquet') 扫描约 134k 个 K 线目录（372k 次 ls 调用和 2.5M 次 stat/info 调用）。对于任何双腿策略，运行器都会进行两次此类调用（主 load_normalised 加上批量额外腿查询），在当前主机上每次约耗时 200 秒（18 个核心上的负载均值为 33-42）。策略自身在约 1,700 根日线上运行回调只需几秒。这解释了为何所有双腿 USEQ 日线运行都超时（经验教训 182）。没有任何信号、缓冲区或再平衡改动能让运行时间低于 300 秒，因为在交付第一根 K 线之前就已产生这项开销。

验证结果

sandbox_timeout：验证失败（第 3 层——沙盒回测）：烟雾测试在约 20000 根 K 线的窗口（SPY.USEQ-1-DAY-LAST-EXTERNAL 中的 2400 天）上超过了 300 秒的墙钟时限。这几乎总是意味着逐根 K 线的工作量随历史长度增长，例如反复扫描完整的资金费率/补充数据序列，或在每根 K 线上于 calculate_signal()/on_bar() 内重建列表并调用 min()/sorted()。在 __init__ 中预先计算已排序的时间戳数组 ONCE 并使用 bisect，或按时间戳缓存查询，使逐根 K 线的开销为 O(log n)，而非 O(n)。

结局总结

双腿策略 USEQ 在第 3 层持续超时；策略自身的说明将原因归于回测运行器中的目录文件发现，耗时约 494/504 秒，而非逐根 K 线的策略运算。修复目录加载会比再迭代一次代码更有成效。

经过 3 次迭代后，该方案在验证循环中被放弃。Layer 3 沙盒冒烟测试在约 20,000 根柱线的窗口（2,400 天、每日日线 SPY.USEQ 根）上超过了 300 秒的墙钟时间限制，因此回测审查、分析师和风险阶段均未运行。

在 USEQ 上，围绕 SPY（大盘代理）和 IWM（小盘代理）建立月度做多赢家、做空输家价差。每月比较两者过去 12 个月（252 个交易日）的相对动量，买入领先者并做空落后者。

未测量：没有回测完成。回测报告为空，没有优化报告，也不存在收益、夏普比率或交易次数数据。

分析

动量与风格轮动效应