原始来源：doubleAI / Maxwell
doubleAI 的 Maxwell 尝试把优化放在程序运行过程中：观察当前硬件、数据形状与类型，找到耗时部分，再生成适合该机器的底层二进制。源码保持原样，替换的是机器实际执行的代码。它与编程助手的分工不同：后者帮助写程序，前者希望根据运行时才知道的条件持续调整执行方式。官网称它同时覆盖 CPU 和 GPU，例如将 Python 运算换成低层实现，为 PyTorch 生成适合当前 GPU 的内核；产品仍处于 early access 阶段。
运行中自动换代码，首先要回答新旧行为是否相同。官网把做法描述为“同时生成优化代码与语义等价证明”：在规定输入和条件下，结果及外部效果都应保持一致，证明再由机器检查。页面用一个刻意简化的例子解释：双层循环逐次累加，可以换成 n×(n−1)÷2；但给出的替换代码使用有限范围整数，证明注明 0≤n≤3037000500，条件不满足时，由运行时的条件检查（guard）转回原代码。这个例子说明了条件与回退的作用，不代表完整 Python 运行时已由这段演示覆盖。
官网展示的演示让同一个 Python 脚本在同一块 RTX 4090 上从冷启动开始，用 Whisper-small 做 180 次转写，总时间从 106.23 秒降至 49.82 秒，展示的文本输出相同。它提供了一个具体速度样本，但“这些转写相同”“某个替换在明确条件下等价”“整个运行系统及其依赖可信”是三层承诺，不能互相替代。
合作方 LTX-2 的 1.5.0 更新记录还披露了与 doubleAI 的性能优化，包括算子、切块和数据精度相关变化，同时明确新旧版本并非逐比特一致。这不直接否定某个特定 Maxwell 替换的等价证明，却说明评价产品和合作版本时，需要分清到底要求文本结果相同、数值容差内相同，还是每个比特完全相同。
可信度 65 · 重要性 66 · 新颖度 70
技术与主题
Remote-Telephone-682
回应原帖：查看原帖上下文
根据官网提出工程取舍问题，未实际测试 Maxwell。
忠实转述（非原句）：他问：如果性能剖析发现了新的优化规律，为什么不把它们加进编译器，而要给每一份构建出的二进制增加一个独立优化阶段？他能理解这种产品形态的商业理由，但对工程上新增环节是否值得持保留态度。
编辑评读
Maxwell 有吸引力的地方，是利用实际运行条件寻找静态源码看不出的优化机会，同时把替换行为是否保持纳入承诺。官网的求和例子虽然简单，却解释了一个关键取舍：利用有限输入范围可以获得更快的实现，运行时检查则负责确认这个范围仍成立。因此，评估时不应只看新代码有多快，还要看检查条件、生成优化与不满足条件时回退的费用，是否被端到端收益覆盖。
Reddit 评论者问“为什么不把发现的规律放进编译器”，正好提供了另一种取舍。可以普遍复用的变换进入编译器后，很多程序都能受益；依赖某台机器和当前数据的改写，则可能有在运行时专门优化的理由。这是依据产品机制展开的工程判断，尚需以优化耗时、版本复用和长期运行收益来比较，不能仅凭多了形式证明就认定额外环节一定划算。
等价性还必须绑定具体对象。Whisper 演示检查的是有限次转写结果，条件证明检查的是形式模型中的替换关系，LTX-2 更新记录描述的是整个合作版本的行为变化。把这三种对象分开，才能既保留正面速度证据，也正确理解输出不逐比特一致的披露。实际采用前最值得取得的材料，是证明覆盖的语义、guard 与回退边界、第三方库的假设，以及包含优化开销的同任务测量。
需要留意
- 本轮未执行产品、核验证明系统或取得同一版本独立复测。