什么是混元 Hyra 2.0
Hyra 2.0 是腾讯混元的自动科研 Agent，不是普通聊天模型
聊天模型负责回答问题，科研 Agent 要把一个可以验证的问题持续推进到结果。腾讯将 Hyra 称为 Hunyuan Research Agent。从公开成果来看，它工作的对象包括小模型训练、GPU 算子、数学难题、量子线路、蛋白质建模和预测算法。
例如，普通聊天工具可以告诉你“怎样优化训练速度”；科研 Agent 的目标则更接近“修改训练脚本、运行实验、得到新指标，并留下可检查的代码和日志”。我们认为，理解 Hyra 的重点并不是问它的聊天体验有多自然，而是看它发现的方案能否复现、能否超过现有基线，以及是否值得投入计算资源。
腾讯公开的 Hyra-results 主要保存最终方案和部分复现脚本，没有完整公开 Agent 的研究调度、搜索策略或底层模型。Hyra 成果仓库
以实验反馈推动研究：让代码、评分与验证形成闭环
Hyra 的公开成果有一个共同特点：问题通常带有可以计算的目标。例如，训练后的验证损失越低越好、同样精度下训练时间越短越好、量子线路新增的门越少越好。这样一来，好的想法不会只停留在一段看起来合理的解释里，而是有机会变成具体代码、运行记录或证明材料。
我们建议把这类研究方式理解成四个可验收的步骤：确定目标指标，产生候选方案，调用外部环境评估，再保存通过验证的结果。这是一种基于公开产物归纳的工作模式，不代表腾讯已公开 Hyra 2.0 的全部内部架构。
对于普通用户，最容易理解的场景是“帮我们把某个已经能运行的程序优化得更快”。前提是我们能提供测试数据、运行环境和清楚的验收条件。如果只有一句“让算法变得更好”，模型再强也很难知道什么叫成功。
Hyra 2.0 已产出蛋白质模型，但不要把产物当成 Agent 本体
截至本次核验，腾讯在成果仓库中发布了两个特别值得关注的项目。一个是 HyInv：约 196 万参数的蛋白质逆折叠模型，根据蛋白质骨架结构生成氨基酸序列；另一个是 HyPLM-Flash：约 6.5 亿参数的蛋白质语言模型，用于蛋白质序列表示和相关预测任务。两者 README 均写明由 Hyra 2.0 训练。
我们会特别提醒读者：HyInv 与 HyPLM-Flash 是可以获取代码与权重、按说明运行的独立模型；它们不是名为 hyra-2.0 的通用对话模型。它们分别解决结构到序列设计，以及序列编码和下游分析的问题。对研究人员来说，这比抽象的“AI 能做科研”更实在，因为至少可以从一个具体任务开始复现。
项目资料：HyInv README · HyPLM-Flash README
混元 Hyra 2.0 的核心功能与领域优势
自动 AI 研究：优化小模型训练配方，而不是只生成训练建议
我们认为，Hyra 的第一类价值是自动搜索训练方案。它在 nanochat_autoresearch 项目中发布了可以查看的 train.py、运行脚本和完整训练日志。公开配置是在单张 NVIDIA B200 上、固定约 300 秒训练预算内，得到 0.901543 validation BPB。BPB 可以简单理解为衡量文本预测效果的一种损失指标，这个任务里越低越好。
对开发者来说，这意味着研究成果不是一篇空泛的“调参心得”：它具体涉及注意力窗口、优化器设置、额外的 n-gram 特征和训练调度。我们更建议先学习这些可复现的改动，再判断它们是否适合自己的模型，避免把别人的训练配置直接照搬到完全不同的数据规模。nanochat 实验
GPU 算子优化：把速度提升落在可运行的实现上
GPU 优化很容易出现一种误区：代码看上去更高级，但实际可能更慢，甚至在部分输入上算错。Hyra 在 SOL-ExecBench 中提供了部分真实提交产物，包含注意力、MoE 分发、矩阵乘法和推理阶段的算子。公开目录给出 10 个已通过正确性检查的示例，每个都有提交编号、运行延迟与成绩。
我们特别看重它保留了正确性状态。例如，某个 Flash/GQA attention 示例记录的延迟是 0.177612 毫秒，但这个数字只属于对应任务和硬件评测，不能推导为任意模型的注意力计算都会达到同样速度。对于推理服务团队，我们建议先固定输入形状、精度、硬件和编译器版本，再比较优化前后的延迟与输出一致性。
数学发现：从找到候选答案走向可核验的证明材料
科研 Agent 另一个值得关注的领域是数学。Hyra 仓库记录了几何、组合数学与算子不等式方面的结果。例如，三维常宽凸体的体积下界从约 0.380799 推进到 0.411040；另外，2026 年 11 月 2 日新增的说明还报告了 Petty 等距点猜想在五维的结果，以及关于 Yau 圆作用猜想非单连通情形的反例。
这些成果不应被简单翻译成“AI 已经解决所有数学猜想”。我们更关注证明覆盖范围、形式化检查究竟证明了哪一部分，以及成果是否仍需要数学同行审阅。对于严肃的科研工作，我们建议保留定理原文、完整前提、证明文件和独立检查记录，再考虑对外引用。
蛋白质设计：HyInv 把结构输入转成候选氨基酸序列
HyInv 面向一个很具体的任务：研究人员已有蛋白质主链结构，希望设计出可能与该骨架匹配的序列。它提供了命令行和 Python 调用方式，支持读取 PDB 结构文件、选择链、固定指定位置，以及按随机种子生成多个候选序列。公开权重约 7.8 MB，参考实现可以在 CPU 或 GPU 上运行。
这类工具对生物技术团队的好处是能把重复生成候选序列的步骤程序化，但我们不会把“生成序列”直接写成“发现有效药物”。候选序列还需要结构、稳定性和实验验证。我们的使用建议是先用少量公开结构验证格式和输出，再结合团队自己的结构评分流程筛选，最后才进入实验阶段。
蛋白质序列分析：HyPLM-Flash 更适合批量编码与下游预测
HyPLM-Flash 的角色与 HyInv 不同：它接收蛋白质序列，输出每个残基或整条序列的向量表示，也提供用于突变评分的 logits。腾讯发布的实现包括 INT8 推理引擎，在单张 H20 上报告约 13 万个残基/秒的吞吐量。这个数字来自官方指定环境，不是任意显卡上的速度承诺。
我们更推荐把它当成“研究系统中的序列特征提取器”，例如批量编码蛋白质，再把向量交给自己的分类、聚类或性质预测程序。对于普通开发者，先理解输入是氨基酸序列、输出是向量，会比纠结 6.5 亿参数更有用。对于研究人员，我们建议同时比较精度、批处理量和冷启动时间，决定 INT8 或 BF16 哪一种更适合自己的任务。
混元 Hyra 2.0 基准测试与性能表现
我们在这一部分采用腾讯公开的任务级实验数据。需要特别说明：这些数字并不是统一口径下的 Hyra 2.0 聊天模型排行榜；有些是 Hyra 研究系统的发现记录，有些是由 Hyra 2.0 训练出来的独立模型评测。是否能复制到自己的业务，仍要看测试环境与基线。
语言模型训练质量：nanochat 的验证 BPB 从 0.9109 降至 0.9015
腾讯仓库将其结果与 Recursive 公布的同类记录进行对比：此前记录 0.9109 BPB，Hyra 达到约 0.9015 BPB，绝对差值约 0.0094。Hyra 的具体记录为 0.901543，运行在 1× B200，训练用时约 300.1 秒；包括准备与评估的总时间约 348.4 秒。这里的“改善”指验证损失降低，不能换算为通用问答准确率提升。
我们的建议：如果团队在做小模型训练优化，可以先把这个项目作为复现实验，检查显存、数据准备和验证方法；对于商业模型训练，仍应看本地数据集的指标与最终训练成本。不要直接把一个五分钟基准的收益推广到所有模型规模。
Hyra nanochat 记录 · Recursive 基线
训练速度：nanoGPT Speedrun 从约 77.5 秒缩短至 76.435 秒
在 nanoGPT Speedrun 实验中，Hyra 的公开脚本对大矩阵运算采用 FP8 计算，并调整训练计划。仓库保留三次运行：76.431、76.467、76.408 秒，平均 76.435 秒，平均验证损失约 3.28007。相对仓库引用的约 77.5 秒基线，时间减少约 1.1 秒，约 1.4%。
这个成绩的条件很严格：8× H100、对应的 CUDA、PyTorch、Triton 版本和数据集。平均损失四舍五入为 3.280，不能把显示为 3.280 误认为每次实验都严格低于 3.280。
我们的建议：只有训练环境接近时，才值得把这套 FP8 优化作为升级候选。我们会先复现三轮以上，比较均值、波动和最终损失；如果自己的训练系统已经采用别的算子实现，优先做小范围 A/B 测试。
GPU 算子评分：SOL-ExecBench 从 0.754 提升至 0.771
在公开的 SOL-ExecBench 对比中，Recursive 基线的综合 SOL 得分为 0.754，Hyra 仓库报告 0.771，提高 0.017。SOL 用来衡量实现与该基准定义的性能上限之间的接近程度，不是 77.1% 的通用代码正确率。腾讯另外公开了 10 个带有正确性检查的样例，但这 10 个样例不是完整基准数据集的替代品。
我们的建议：对于做推理网关或 GPU 服务的团队，我们会优先挑业务中真正的热点算子测试，记录 P50/P95 延迟、吞吐量、显存和数值误差。只追求单个微基准最高分，很可能无法降低完整服务的端到端成本。
Hyra SOL-ExecBench · Recursive 发布结果
量子线路路由：额外 CNOT 数量由 269,037 降至 258,369
量子计算也有可量化的优化任务：当两个量子比特在物理设备上不相邻时，路由算法必须添加操作。腾讯仓库记录了 61 条验证过的线路，在 Q20、Willow 风格和 Heron 风格三类拓扑上，与 SimpleTES 引用的基线比较：
| 设备拓扑 | SimpleTES 基线 | Hyra 结果 |
|---|---|---|
| Q20（20 比特） | 45,441 | 37,869 |
| Willow 风格（105 比特） | 96,774 | 95,898 |
| Heron 风格（156 比特） | 126,822 | 124,602 |
| 合计新增 CNOT | 269,037 | 258,369 |
在同表口径下，合计少 10,668 个 CNOT，约减少 4.0%。这衡量的是线路映射开销，而非量子计算机整体速度提升 4%。
我们的建议：如果做量子线路编译，优先复核生成的 OpenQASM 和连通性约束；如果只是选择通用 AI 聊天工具，这一成绩与日常问答质量并没有直接关系。
蛋白质推理：HyPLM-Flash 约每秒 13 万残基，HyInv 支持毫秒级批量设计
这一组是 Hyra 2.0 产出的独立模型，不是 Agent 的端到端速度。腾讯公开的 HyPLM-Flash 在单张 H20 的 INT8 运行配置下约 130,000 残基/秒，并报告在 32 项任务、28 个公开检查点的配套比较中，其 ProteinGym 零样本 Spearman 相关系数为 0.409，与若干同量级蛋白质编码器统计上接近。该指标衡量的是相关性，不能当作分类准确率。
HyInv 则报告在 H20 上批量生成 128 条、长度约 148 的蛋白质设计时，优化 BF16 路径约 25 毫秒，参考实现约 999 毫秒。但这个计时不包括首次编译和 CUDA Graph 捕获，并且优化路径与 FP32 参考路径存在数值差异，因此不能只用速度判断是否替换。
我们的建议：我们会让生物研究团队分别评估质量、批量吞吐与可复现性。经常只处理一条短序列的业务，应先量测首个请求延迟；大批量离线任务才优先看每秒残基数。同时，序列评分不能替代湿实验验证。
混元 Hyra 2.0 与 Recursive、SimpleTES、TTT-Discover、AlphaEvolve 同类系统对比
这里比较的都是科研自动化系统或研究框架，并非四个可以在同一个聊天接口中直接替换的“对话模型”。我们尽量使用有共同任务的数字；没有统一测试的部分只比较工作方式与适用场景。
对比 Recursive：在同类 AI 自动研究任务中，Hyra 发布了进一步优化的结果
Recursive 的 First Steps Toward Automated AI Research 是比较直接的参照。它公开了固定预算小模型训练、训练速度和 GPU 算子优化三个方向的结果，而 Hyra 在自己的公开目录中用这些基线继续对照：
| 指标 | Recursive 已公开基线 | Hyra 公布结果 | 更好方向 |
|---|---|---|---|
| NanoChat 验证 BPB | 0.9109 | 0.9015 | 越低越好 |
| NanoGPT 训练时间 | 77.5 秒 | 76.4 秒 | 越低越好 |
| SOL-ExecBench 得分 | 0.754 | 0.771 | 越高越好 |
我们认为，Hyra 在这些公开任务上展示了继续压低指标的能力，但跨机构实验仍应仔细核对代码、硬件和评分器。我们的场景建议：如果团队正在研究训练算法或 GPU 性能，可以把两个仓库放在一起复现；如果只需要现成的客服或写作 API，就不需要因为这些分数而更换日常模型。
对比 SimpleTES：两者都依赖客观评分，Hyra 在公开量子路由任务中更省门数
SimpleTES 研究的是怎样扩大“候选方案—自动评估—继续搜索”的循环。它的论文覆盖 21 个科研任务、6 个领域，并公开了量子线路路由等结果。Hyra 在三类硬件拓扑的公开对照中，将总新增 CNOT 从 269,037 压到 258,369。从这个方向看，Hyra 提供了更进一步的候选解。
不过，我们不会把“某一个任务更好”写成“整个科研系统全面领先”。SimpleTES 的强项是把实验评估与扩展策略讲得更系统，适合学习如何搭建科研优化流程。我们的场景建议：想设计自己的自动实验平台，先读 SimpleTES 的方法；想看量子路由的具体优化产物，再研究 Hyra 的 OpenQASM 文件。
对比 TTT-Discover：前者强调测试时继续训练，Hyra 展示了后续数学优化记录
TTT-Discover 的特点是模型在解决特定科研任务时继续学习，而不是只反复提示一个固定模型。它的论文报告了数学、GPU 算子、生物分析等领域的发现，并公开可复现代码。Hyra 仓库引用其自相关常数的先前记录 1.502870，同时报告自己推进到 1.502850。差值很小，但对需要精确数值界的数学优化来说，不能只用百分比大小判断研究价值。
两者方法和实验预算并未形成完整公开的统一对照。我们的场景建议：研究模型如何在具体任务上持续学习，可以优先看 TTT-Discover；研究结果如何以代码、数值证据和论文材料落地，可以参考 Hyra 的成果整理方式。
对比 Google AlphaEvolve：一个重在可核验科研成果，一个已有大规模生产案例
Google DeepMind 的 AlphaEvolve 同样把语言模型与自动评估器结合起来，寻找更好的算法。Google 官方介绍了它在数据中心调度、芯片设计和模型训练中的实际部署，例如数据中心计算资源平均回收约 0.7%。这是生产环境案例，不是 Hyra 的同项目基准成绩，我们不会把两边的数据放在一张表里硬比高低。
Hyra 值得看的部分是公开的数学、量子和蛋白质研究产物；AlphaEvolve 值得看的部分是从实验优化走到生产基础设施的经验。我们的场景建议：如果你管理实际在线服务，我们会优先借鉴 AlphaEvolve 强调的生产验证和长期收益核算；如果你想学习怎样提交可检查的科研结果，Hyra 的细分目录更容易找到单个复现入口。
Google DeepMind AlphaEvolve · AlphaEvolve 生产进展
混元 Hyra 2.0 API 常见问题
为什么在 API Hop 的模型列表中搜索不到 hyra-2.0？
因为当前公开模型目录没有把 Hyra 2.0 列为可调用的文本模型。如果 API Hop 支持了 hyra-2.0，我们会第一时间更新消息。
统一 Chat Completions 文档 · Hyra 成果仓库
HyInv 与 HyPLM-Flash 已开放哪些程序调用方式？
这两个由 Hyra 2.0 训练出的独立模型有具体入口，但不等于调用 Hyra Agent API。HyInv 支持 CLI 和 Python，例如：
# 在安装了 HyInv 的环境中运行；structure.pdb 是用户提供的结构文件
python -m hyinv design --pdb structure.pdb --n 16 --seed 0 --out designs.fastaHyPLM-Flash 提供 Python 编码接口，例如：
from hyplm import HyPLMEncoder
# 先按项目说明下载、合并并验证权重
encoder = HyPLMEncoder.from_pretrained("weights")
vectors = encoder.encode(["MKTAYIAKQRQISFVKSHFSRQ"], pooling="mean")我们建议把它们作为独立服务部署，先安装仓库指定依赖，再用小样本验证输入输出。HyPLM-Flash 的加速实现还依赖 CUDA、Triton 和相关 GPU 环境，不能假设任意 CPU 或显卡都能达到官方的吞吐量。
HyInv 安装与调用 · HyPLM-Flash 安装与调用
为什么复现时跑不出相同成绩，应该怎样评估成本？
我们建议先把模型推理、训练复现和完整科研 Agent 的成本分开。公开的 nanochat 记录用一张 B200，nanoGPT Speedrun 使用八张 H100；它们需要匹配的数据、驱动、依赖与验证设置。即使代码相同，显卡时钟、编译缓存、负载和随机性也可能让最后的指标变化。HyInv 的加速测试还明确不包含首次 Triton 编译和 CUDA Graph 捕获的时间。
因此，我们会用三类指标评估：质量是否达标、总任务耗时、每个通过验证的结果需要多少资源。对于训练任务，记录 GPU 小时与三次以上运行的均值；对于在线推理，分别统计首个请求延迟、稳态吞吐、显存占用和失败率；对于科研 Agent，还要把失败实验和人工检查时间算进去。当前没有可核验的 Hyra 2.0 通用 API 价格，我们不会填写一个猜测的 Token 单价。