声称 38/38 解 NP-hard 的 GPU-free 引擎，为何只有 1 分？

QαT 是什么：一个 11,000 行的 GPU-free 通用优化器

在 GitHub 上撞见这个仓库时，我先注意到的不是名字，而是日期。Quantum Alpha Technology 公司，作者 Jahua Chang，发布日 2026 年 7 月 19 日，版本号 v1.1.1，状态写着 Public Proof of Concept Release 来源：BPPA。一个 NP-hard 求解器做到这个节点还愿意公开 POC，说明作者对实现本身有底气。但 HN 上那篇帖子只有 1 分、0 条评论 来源：HH，让我不得不反复读几遍 README，确认自己没看漏什么。

它自称 Universal Optimization Engine，缩写 QαT。核心卖点在标题里就写完了：GPU-free，universal，low-power。参考实现约 11,000 行逻辑，物理行数含空白和注释约 15,000 行 来源：BPPA。这个规模不是刻意压缩出来的，作者说它是开发过程中自然形成的，保持在这个体量是为了能维护、能审计、能适配。单核架构，不依赖 GPU，面向未来逻辑电路和 ASIC 实现 来源：BPPA。

设计原则有四条。Feasibility-first，所有解都保证 true_conflicts 等于 0。确定性可验证，100% 可复现，每个解附带 SHA-256 和 Ed25519 数字签名。三种优化模式，Minimization、Maximization、Balance。还有硬件友好，从一开始就把逻辑电路和 ASIC 当目标，而不是事后补一句"可以移植" 来源：BPPA。

量化结果：38/38 实例零冲突，4 个最优解

量化结果在 README 里写得比标题更具体。SteinLib B 和 C 集合，38 个实例全部解决，无一例外 true_conflicts 等于 0 来源：BPPA。这个集合是 Steiner Tree 的国际标准测试，拿它做基准比自造数据有说服力得多。

38 个实例里，4 个达到 0% gap，也就是官方最优解。B03，25 个终端；B08，19 个终端；B09，38 个终端；B18，50 个终端 来源：BPPA。终端密度高的实例表现也不错，C05 偏差 2.4%，C10 偏差 3.5% 来源：BPPA。这些数字不算惊艳，但放在单核、无 GPU、内存小于 6GB 的条件下，就有点意思了。

单核支持三种模式，最小化、最大化、平衡，不是三个独立求解器，是同一套核心切换 来源：BPPA。覆盖 47 种以上优化任务，作者说这个数字反映的是验证投入，不是架构能力上限 来源：BPPA。每个解都能复现，SHA-256 和 Ed25519 双重校验，这个设计在工程上比单纯追求解的质量更实用。

多源交叉验证：高声称与低关注的反直觉反差

问题就出在这里。HN 那篇帖子，标题强调 GPU-free universal low-power，正文指向 GitHub README，结果 Points 1，Comments 0 来源：HH。没有讨论，没有质疑，没有点赞。而 README 里躺着 38/38 零冲突、4 个最优解、47+ 任务覆盖的声明 来源：BPPA。

这个反差让我反复检查了两边。HN 链接的确实是同一个仓库，标题和 README 第一行对得上，作者、公司、发布日期一致。所以不是钓鱼链接，不是搬运错误，就是一份无人问津的高质量声明。1 分意味着只有发布者自己点了投票，0 评论意味着连质疑的人都没有 来源：HH。

一个可能的解释是，NP-hard 求解器在这个圈子里并不新鲜。SteinLib 有公开基准，38/38 全部零冲突在现有算法库里有先例，4 个最优解也不算打破纪录。真正的差异点是 GPU-free 和低功耗，面向 ASIC 的设计路线，这条路径在软件社区里本来就不是热点。作者把验证和签名放在前面，把性能和功耗放在后面，这种排序对 HN 读者来说不够刺激。

我不确定这个引擎最终能不能进 ASIC，也不确定 11,000 行逻辑在硬件上会变成什么样子。但有一件事我有把握：一个愿意把 38/38 实例结果、最优解编号、偏差百分比、内存上限都写进 README 的项目，不会只有 1 分的热度。要么是宣传方式出了问题，要么是它解决的问题太小众，小到没人愿意花时间讨论。两种可能我都没法排除。

原文：

QαT GPU-free universal low-power NP-hard solver · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年11月2日