人类主导、AI 辅助的量化投资系统,AI 极大放大了专家的能力边界与产出效率,但系统的上限,目前还是由人来决定——如同带领一个团队。不过,随着系统不断的进化,人类专家的经验能力和决策能力,总有一天会被替代。 docs 目录下集中了设计文档,并有一部分多轮人-AI 交互讨论记录,指导并约束 AI 架构与编码。

全系统基于 folly::coro 构建,所有任务以协程方式调度,禁止阻塞操作(禁止 std::mutex/std::shared_mutex/std::condition_variable/std::this_thread::sleep_for),确保 CPU 核充分并行利用。

量化计算具有典型的非均匀并行特征:因子 DAG 中不同节点的计算量差异大(SMA 是 O(n) 滑动窗口,CROSS_ABOVE 是 O(1) 比较),如果使用传统的线程池固定分配,长任务会阻塞短任务,导致尾部延迟放大。

Work-Stealing 天然适合这种场景:空闲 worker 主动从繁忙 worker 的队列尾部窃取任务,实现动态负载均衡,无需中心调度器介入。

Worker 0: [SMA_5 ████████████████░░░░] ← 繁忙
Worker 1: [RSI_14 ████░░░░░░░░░░░░░░]
Worker 2: [idle] ──steal──→ SMA_5 的后半段
Worker 3: [EMA_10 █████░░░░░░░░░░░░░░]

协程挂起后,其工作数据集(working set)仍留在原 CPU core 的 L1/L2 缓存中。如果唤醒时被调度到其他 core,所有数据需要从远端缓存或内存重新加载——这就是**缓存迁移(cache migration)**的代价。

量化计算场景中一次因子求值的数据集小(close_prices 数组 span),在 L1 缓存中热命中。跨 core 唤醒意味着:

• L1 命中 → L3 未命中(~40 cycles → ~200 cycles)
• NUMA 远端内存访问(~300 cycles, 5-7x 延迟)

WorkStealingExecutor 的 add_to_worker(worker_id, handle) 机制确保协程唤醒时精确恢复到挂起前的 CPU core,保持缓存热状态。32 个 worker 各绑一个物理 core(hwloc CPU pinning),同 NUMA 节点内窃取,跨 NUMA 隔离,最大化数据局部性。

本机 2 个 NUMA 节点(Intel Xeon Platinum 8173M 双路),每个节点有独立的本地内存控制器。跨 NUMA 访问远端内存的延迟是本地内存的 1.5-2x,且带宽受 QPI/UPI 链路限制。

NUMA Node 0 (31 GB) NUMA Node 1 (63 GB)
├── Core 0-27 (56 HT) ├── Core 28-55 (56 HT)
├── Worker 0-15 ├── Worker 16-31
├── Cache Shard 0-7 ├── Cache Shard 8-15
└── .seg files on local disk └── .seg files on local disk

• Worker 绑核:每个 worker 通过 hwloc 绑定到指定物理 core(跳过 HT sibling),避免两个 worker 争抢同一 L1/L2 缓存
• 同 NUMA 窃取:work-stealing 仅在 numa_peers_[my_numa] 范围内选 victim,杜绝跨节点窃取造成的远端内存访问
• Per-NUMA 全局队列:外部任务提交按目标 worker 的 NUMA 路由到对应队列,唤醒仅通知同节点 worker

这保证了因子计算的数据(span<const float>)始终在本地内存,写入的因子结果也留在本地缓存——一次量化任务的全生命周期不离开其 NUMA 节点。

folly::coro::Mutex/SharedMutex 不满足线程亲和要求(唤醒不经过 executor 路由,SharedMutex 内部含 SpinLock),因此自研:

• AffinityBaton — 单次通知原语,post 时通过 add_to_worker() 路由唤醒
• AffinityMutex — 互斥锁,单原子状态字编码锁标志+等待者指针,CAS 快速路径
• AffinitySharedMutex — 读写锁,读者计数+写者标志+写饥饿预防

三种原语均由单原子操作实现快速路径(无竞争时零系统调用),唤醒路径保证线程亲和。

策略定义与执行完全解耦,形成完整的编译生效通路:

Python DSL v2 → IRCompiler → IR JSON → etcd 提交 → C++ 引擎 watch → FactorDAG → 执行

• Python 负责策略编写与 IR 编译,不参与运行时计算
• C++ 引擎 watch etcd 实时感知策略变更,自动加载/激活/卸载
• FactorDAG 拓扑排序执行,同层无依赖节点并行计算
• 回测任务通过 etcd 下发,引擎执行后写回结果

三级存储架构,数据从热层向冷层自动沉淀:

核心原则:淘汰方向与同步方向正交 — 实时数据淘汰=沉淀(先 flush 到下一层),远端加载数据淘汰=纯淘汰(远端已有副本)。通过 DataSource enum 标记每个缓存条目的来源,驱动正确的淘汰策略。

数据规模支撑:5000+ A 股标的 ×ばつ 10 年 ×ばつ 6 频率 K 线 ≈ 204 GB 压缩后(Parquet Zstd ~7x),500 因子横截面 ≈ 25 GB。

• 列式压缩: ColumnBlock (Delta-of-Delta / Gorilla / Zstd),每块 8192 行,压缩比 5:1~10:1
• WAL + WriteBuffer: 单行写入先追加 WAL(fsync 崩溃安全)→ 攒批 8192 行后批量压缩 → 写入缓存与磁盘
• SegmentIndex: 内存索引消除 O(n) 目录遍历,查询 O(log n) 二分查找
• io_uring 异步 I/O: co_write_segment()/co_read_segment() 绕过 page cache,避免阻塞
• Read-Through: 查询 Cache → SegmentIndex → 磁盘 → 回填缓存,自动从下层加载

EventBus 发布/订阅模式,同步派发延迟 < 1μs(热路径零分配),异步派发 500 万事件/秒。KlineEvent → FactorUpdateEvent → TradeSignalEvent → RiskAlertEvent 形成完整数据处理流水线。

┌──────────────────────────────────────────────────────────────┐
│ Python 策略层 │
│ DSL v2 → IRCompiler → IR JSON → etcd 提交 │
└──────────────────────┬───────────────────────────────────────┘
 │ etcd watch
 ▼
┌──────────────────────────────────────────────────────────────┐
│ C++ 执行引擎 │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────────────┐ │
│ │ StrategyEngine│ │ FactorDAG │ │ BacktestRunner │ │
│ │ (策略管理) │ │ (因子依赖图) │ │ (回测执行) │ │
│ └─────────────┘ └──────────────┘ └─────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 多级存储引擎 │ │
│ │ Tier 2: LRU Cache (内存热数据, 分片 64, AffinitySharedMutex)│
│ │ Tier 1: Columnar Segment Files (磁盘温数据, SegmentIndex)│
│ │ Tier 0: MinIO/etcd/PostgreSQL (远端冷数据) │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 协程调度器 │ │
│ │ WorkStealingExecutor (线程亲和) │ │
│ │ AffinityBaton / AffinityMutex / AffinitySharedMutex │ │
│ └─────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘

├── cpp/quant/
│ ├── infra/ # 协程调度、同步原语、配置、etcd 客户端
│ ├── storage/ # 多级存储引擎(缓存/WAL/WriteBuffer/Segment/SegmentIndex)
│ ├── service/ # 常驻服务入口
│ ├── strategy/ # 策略引擎、FactorDAG、IR 加载、信号处理
│ ├── backtest/ # 回测框架
│ ├── network/ # TCP/WebSocket/HTTP、EventBus、CoIouring
│ ├── event/ # 事件类型定义、MPSC 无锁队列
│ └── pybind/ # Python 绑定
├── py/
│ ├── dsl/ # 策略 DSL 定义
│ ├── compiler/ # IR 编译器
│ └── client/ # 策略提交客户端
├── web/ # 前端 (React + WebSocket)
├── deploy/ # Docker 部署 (etcd + MinIO)
├── docs/ # 设计文档与讨论记录
└── Testing/ # 集成测试

环境: Ubuntu 24.04, Linux 6.17, x86_64 | Intel Xeon Platinum 8173M (×ばつ28C/56T/112T, L3 77 MiB) | 96 GB DDR4 | GCC 14.2

详见 benchmark_report.md

• C++20 (GCC 12+ / Clang 15+), CMake 3.22+, Python 3.10+, Node.js 18+, Docker

cd build && cmake .. && make -j$(nproc)
ctest --output-on-failure
cd deploy && docker-compose up -d # 启动 etcd + MinIO
cd web && npm install && npm run dev