GPT-6 Astra利用一篇2014年的数学论文优化了我的Rust回测引擎

# 四个AI模型未能让我的Rust回测引擎更快。然后GPT-6 Astra阅读了一篇数学论文。来源：https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908 Astra，持续顺时针旋转一种由数十条精细的青色与金色数学轮廓构成的星际智能，悬浮于一篇研究论文之上。数学优化连续二次型背包问题∑ clamp\(vi − λ, 0, ci\) = t∑ clamp\(vi − λ, 0, ci\) = tλ\*COMINETTI · MASCARENHAS · SILVA2014NexusTrade · 基础设施 GPT-6 Astra让我相信通用人工智能已经到来，而人工超级智能将在不到两年内实现。这便是它解决了一个其他四个前沿模型告诉我不可能的优化问题的方式。创始人，NexusTrade2026年9月8日11分钟阅读 **01**速度 (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#begging-for-velocity)**02**基线 (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#the-baseline)**03**瓶颈 (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#the-wall)**04**突破 (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#the-breakthrough)**05**论文 (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#the-paper)**06**证据 (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#the-evidence)**07**成本 (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#the-cost)**08**五分钟 (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#five-minutes)**09**AGI (https://nexustrade.io/blog/gpt-6-astra-rust-backtesting-engine-optimization-20260908#the-argument)开篇 ## 渴望速度 9 2022年末，我放弃了我自己的平台。NextTrade是第一个版本，用TypeScript编写，我花了两年多时间开发它。它太慢了，无法完成我构建它的初衷。在我的MacBook Pro上运行遗传优化可能会导致整个机器崩溃，而如果我将种群规模保持得足够小以使其能运行，一个复杂策略的100代进化需要耗费数天时间。于是我将其开源了。我事先阅读了我能找到的每一篇Medium文章和每一个Reddit讨论串。Golang是我日常工作中熟悉的语言，尽管其垃圾回收器（GC）恰好在回测所依赖的尾部延迟中显现出问题。C++是传统选择，我曾梦想进入Jane Street工作。Rust胜出了，然后我花了18个月公开表达对它的厌恶，以至于因此走红 (https://nexustrade.io/blog/-i-spent-18-months-rebuilding-my-algorithmic-trading-in-rust-im-filled-with-regret--20240629) 才最终转变观念。ThePrimeTime在直播中阅读了那篇文章。就像亨特·佐洛蒙给自己注射速度类固醇一样，我渴望成为最快的那个。我使用AI来实现目标，但我从未使用过类似这样的工具。Zoom，戴着面具，蓝色的闪电爬过他的套装Zoom。那速度是借来的，代价是他的一切，这大致概括了接下来的两年。基线 ## 我的起点 让我们回到四月。我发布了一篇关于使用Claude Opus 4.7迁移引擎 (https://nexustrade.io/blog/claude-opus-47-rewrote-my-backtest-engine-20260421) 的文章，将其从每个worker 200GB的内存映射架构上迁移下来。那个周末，我的磁盘账单减少了七倍，热回测速度提升了四倍。TypeScript 对比 Rust · 秒一年SPY分钟K线 983.9 相同，使用Rust 16.6 遗传优化，36次回测 1994.3 相同，使用Rust 9.2 相同的十年窗口，相同的数据湖中的K线，两侧使用相同级别的Fly机器。分钟行测量的是吞吐量：TypeScript端在我为其构建的运行器上没有进行任何交易。NextTrade仍在GitHub上 (https://github.com/austin-starks/NextTrade)。我人生的两年换来了这个差距。当我进行Opus 4.7迁移时，我自己无法推导出那些成本优化，但一旦它们出现在屏幕上，我就理解了它们。它读取Parquet而非解码二进制文件，它在解码之前进行剪枝，并且它在一次并发的块获取中共享了预取的元数据读取。Astra就是……不一样。瓶颈 ## 四个模型告诉我“不行” 那次迁移给了我很多，我想从中获得更多。随着四月变成五月，五月变成六月，我将所有严肃的智能体工具链都应用到了这个代码库上，专门为了在我的公共投资组合挑战赛中加快分钟级回测速度。我使用了通过Claude Code运行的Claude Fable 5，GPT-5.6 Sol，Cursor中的Grok 4.6，以及跨十几个会话的Claude Opus。实时共享的投资组合快照· 这是实际的公共投资组合挑战赛账户。我投入了一个25,000美元的真实经纪账户并公开展示，因此账户、策略和每一笔交易在发生时都是可见的。策略本身在GitHub上 (https://github.com/austin-starks/Public-Portfolio-Challenge)。这些模型尽力使其更快。但它们都没有做的是触及分配求解器，最终其中一个告诉了我原因：Claude Opus 5告诉我的“物理学就是不允许它变得更快。” 这个判断是合理的。我的Rust回测引擎在一个紧密的事件驱动循环中遍历分钟K线，这个循环与实盘交易路径共享，因此重放2019年的代码就是下真实订单的代码。每个模型都追踪了相同的路径：LRU缓存、列式剪枝，然后是一个具有固定迭代预算、已经用LeetCode-hard二分查找调整过的分配器。一切都是有界且可预测的，没有垃圾回收器可指责，因此剩余的成本看起来是结构性的。它正在做什么 ### 一百次猜测来得到一个数字。原始求解器 提交3d679ac6d4 三个资产分别需要60%，35%和15%的账面价值。任何仓位不得超过其50%的上限，三者之和必须达到90%的配置目标。求解器寻找一个从每个提案中减去的偏移量。它没有这个偏移量的公式，因此它猜测、检查，然后减半区间。它在每次再平衡和每个模拟分钟都运行。**0**次/ 100次通过后停止 ` let mut low = min(value - cap); // -35 let mut high = max(value); // 60 for _ in 0..100 { let mid = 0.5 * (low + high); let sum = values.iter().zip(caps) .map(|(v, c)| (v - mid).clamp(0.0, *c)) .sum::(); if sum > target { low = mid; } else { high = mid; } } ` 偏移量猜测 low**\-35.00** high**60.00** 夹紧总和*目标 90.00* 点击播放。观察在总和稳定到90之前需要多少次通过。示例输入·迭代次数，非实测运行时间精确答案是偏移量5.00 → 50 / 30 / 10 我百分之百完全相信它。我开始询价硬件。提交 ## Astra实际做了什么 我的引擎通过将建议的组合权重投影到最近的可行集来分配资金：任何权重不低于零，不超过其上限，总和等于配置目标。以下是我编写以来一直使用的方式。` let mut lower = /* 最低可能偏移量 */; let mut upper = /* 最高可能偏移量 */; for _ in 0..100 { let midpoint = 0.5 * (lower + upper); let sum = values .iter() .zip(caps.iter()) .map(|(value, cap)| (value - midpoint).clamp(0.0, *cap)) .sum::(); if sum > feasible_target { lower = midpoint; } else { upper = midpoint; } } let offset = 0.5 * (lower + upper); ` 猜测一个偏移量。将所有权重相加。减半区间。每次任何策略再平衡时，在每个回测的每个模拟分钟，都执行一百次。这就是在常见情况下替代它的代码。` // 如果每个投影权重严格在其界限内，每个斜率 // 都是 -1。常见的偏移量遵循 sum(values) - n*offset = target。 // 在返回之前验证这个假设；否则使用完整扫描。 let goal = target.min(caps.iter().sum::()).max(0.0); let offset = (values.iter().sum::() - goal) / values.len() as f64; if goal > f64::EPSILON && offset.is_finite() && values.iter().zip(caps).all(|(v, cap)| { let w = v - offset; w > 0.0 && w < *cap }) { projected.clear(); projected.extend(values.iter().map(|value| value - offset)); // 验证总和，然后返回 } ` 将权重求和，减去目标，除以权重数量。然后检查每个权重是否严格落在其界限内，如果是，那么这个数字就是答案。搜索只是为了找到权重在零或其上限处被截断的地方。当没有截断时，每个权重移动相同的量，这个量通过一步算术就能得出。一百次减半解决的是大多数再平衡从未遇到的情况。一百次扫描变成了一次除法。观察数学 ### 相同的答案。*一条非常不同的路径。* 8个资产 1个共享偏移量 将每个建议权重移动相同的偏移量。保持每个在零和其上限之间。使总和等于100%。之前二分搜索 **0**次通过所有八个权重 λ—当前猜测 lowhigh 猜测，添加夹紧的权重，然后减半区间。` mid = (low + high) / 2 total = Σ clamp(vi − mid, 0, ci) if total > target: low = mid else: high = mid ` 夹紧总和**—** 之后·ASTRA直接求解 **—**除法然后边界检查 λ =1.86 − 1.008 0.107500 在返回前检查每个权重。` offset = (Σ values − target) / n if every weight is inside its bounds: return the verified projection else: solve the matching linear segment ` 验证的总和**—** 点击播放或单步执行以比较这两种方法。示例输入·每个上限为25%·迭代次数，非实测运行时间打开完整演示↗ (https://nexustrade.io/blog/astra-rebalance-demo.html) 与已发布基线相比 全年分钟K线上的八ETF风险平价：首次通过**从352.762秒到124.343秒（64.75%）**以及热缓存**从309.881秒到100.263秒（67.64%）**。相同的工具链，相同的主模块，相同的金融合约，只有分配模块不同。这两个数字衡量的是这一变更相对于它之前那个版本的改进，因此它们不是整个活动的总量。相同工作量的整个活动数字，从470.161秒到51.499秒热缓存，将在后面给出，并包含此后发生的所有变更。洞见 ## 论文 我之所以无法写出那七行代码，是因为我不知道我自己问题的名称。Astra为它命名了我的权重投影是连续二次型背包问题的一个特例，这个问题的文献可以追溯到几十年前，它引用了Cominetti，Mascarenhas和 Silva 2014年发表的《连续二次型背包问题的牛顿法 (https://www.ime.unicamp.br/~pjssilva/pdfs/papers/cqk.pdf) 》的第2节。一旦问题有了名字，其结构就显而易见了。每个权重都是`clamp\(proposal\[i\] \- offset, 0, cap\[i\]\)`，因此每个坐标在恰好两个偏移量处改变行为：一个使其固定在其上限，另一个使其降为零。在这些断点之间，总和是关于偏移量的线性函数。八个资产最多给你十六个断点。排序，扫描一次，求解包含你目标的段。夹紧方程 wi=clamp\(vi− λ, 0, ci\) vi· 建议权重 λ · 共享偏移量 ci· 权重上限 夹紧权重如何随着偏移量增加而变化权重保持在其上限，直到偏移量达到建议值减去上限，然后线性下降直到偏移量达到建议值，然后保持为零。光线从左向右穿过这三个区域。处于上限自由移动处于零 ci0λ = vi − ciλ = vi 偏移量增加 → 两个断点。它们之间是一条直线。增加偏移量，权重从其上限向零移动。这本身就用一次排序和一次扫描替代了一百次扫描。受保护的内部捷径随后也移除了排序，因为当没有权重被固定时，每个斜率恰好为 -1，答案就是算术运算。我写过这个分配器，分析过它，并优化过两次。我从未想过要去问是否有人已经在2014年解决了这个问题。完整差异 ## 同一发布中的其他所有内容 投影是Astra在单次发布中交付的五项变更之一，加上对其自身回归的修复。五项中有三项是Rust让你能明确表达的事情：借用而非克隆，重用缓冲区而非分配，以及在编译时确定两个扫描方向中哪个适用于某个篮子。作为源代码发布于9月6日，提交307932169a，覆盖所有五台回测机器。点击任何一行查看代码和数字。变更内容作用点击**断点扫描**在断点处而非通过二分法求解投影。这是来自论文的变更。**受保护的内部投影**这就是那七行代码。当没有权重被固定时，它以封闭形式求解偏移量，并在返回前验证。**分解风险梯度**重构风险平价梯度，使得共享项在每次求解中只计算一次。**重用试验存储**在求解器迭代中重用试验和投影缓冲区，而非每次分配。**精确零清算**修正了当目标权重恰好为零时的开仓时点偏差。**大篮子方向修复**对于超过128个资产的篮子，从零持仓向下扫描，修复第一个版本引入的回归。该发布是活动中被接受的21项变更之一。广泛的压力工作负载，5,655个名称的分钟期权数据，下降情况如下。广泛冷系列·秒选择一行查看变更↗ 阶段在测量之间重置。这些不是累加百分比。在所有这些中，我只有一个匹配的比较：在任何这些变更之前的引擎和之后的引擎之间，使用相同的保存的一年分钟期权请求，包含十八个记录观察值。未修改的引擎3d679ac6d4 对比优化后的版本。中位数是跨预声明样本取的。点击一行查看该缓存状态的含义。缓存状态之前之后减少时间加速点击新进程，空磁盘368.061s203.061s44.8%1.81×新进程，已填充磁盘368.061s97.726s73.4%3.77×热缓存，同一进程163.704s36.386s77.8%4.50× 因此，Rust回测引擎**在热缓存状态下快了77.8%，在已填充磁盘上从新进程启动时快了73.4%**。实际数字取决于缓存状态。在求解器实际触及的工作量（八ETF风险平价）上，热缓存执行时间从470.161秒降至51.499秒。减少了89%，或快了9.1倍。账单 ## 发布它花费了我什么 有两个真正的成本。**它消耗了存储空间，并带来了大量复杂性。**稀疏股票布局在规范布局旁边保存了同一每日数据的第二种表示，以便读取器可以仅获取策略实际触及的行。活跃的配套数据和索引总计69.375 GiB，包括保留金丝雀在内的整个稀疏前缀为77.044 GiB。以每GiB-月0.02美元计算，这大约是每月1.54美元。美元数字从来不是问题。成本在于现在有两种布局，一个发布者必须保持它们同步，一个读取器在配套数据缺失或过时时回退到规范布局，以及一整类bug，其中回测会悄悄读取错误的表示。这种复杂性是永久的，我从现在起的每一次修改都要承担它。在我的业务量下它是值得的，并且随着规模扩大而改善。一旦我运行足够的负载，使一台机器必须始终保持运行，每月一点五吉字节相对于它节省的计算资源就微不足道了。**第一个版本在关键地方更慢。**在包含2,048和8,192个资产的篮子上，扫描运行速度比它替代的二分法慢了近两倍，因为从一个大的上限总数中进行减法时的抵消导致它在已支付排序成本后进入了自身的回退路径。修复方法是在超过128个资产时从零持仓向下扫描。在8,192个资产时，最终版本快了1.17至2.20倍，并且它回落了