什麼是混元 Hyra 2.0
Hyra 2.0 是騰訊混元的自動化研究代理，不是一般聊天模型
聊天模型負責回答問題，研究代理則要持續處理一個可驗證的問題，直到取得結果。騰訊將 Hyra 稱為 Hunyuan Research Agent。從公開成果來看，它處理的範圍包括小型模型訓練、GPU 運算子、數學難題、量子電路、蛋白質建模與預測演算法。
例如，一般聊天工具可以告訴你「如何加快訓練速度」；研究代理的目標則更接近「修改訓練腳本、執行實驗、取得新指標，並留下可檢查的程式碼與紀錄」。我們認為，理解 Hyra 的重點不在於聊天有多自然，而在於它找到的方法能否重現、能否超越既有基準，以及是否值得投入運算資源。
騰訊公開的 Hyra-results 主要保存最終方案與部分重現腳本，並未完整公開代理的研究排程、搜尋策略或底層模型。Hyra 成果儲存庫
透過實驗回饋推進研究：串起程式碼、評分與驗證
Hyra 的公開成果有一個共通點：問題通常都有可計算的目標。例如，訓練後的驗證損失越低越好、相同準確度下的訓練時間越短越好、量子電路新增的閘越少越好。這讓好點子不只停留在看似合理的說明，而有機會成為具體程式碼、執行紀錄或證明資料。
我們建議將這類研究方式理解成四個可驗收的步驟：確定目標指標、產生候選方案、交由外部環境評估，再保存通過驗證的結果。這是根據公開產物歸納的工作方式，不代表騰訊已公開 Hyra 2.0 的全部內部架構。
對一般使用者而言，最容易理解的情境是「幫我們把已經能執行的程式改得更快」。前提是能提供測試資料、執行環境與明確的驗收條件。如果只有一句「讓演算法變得更好」，模型再強也很難知道什麼才算成功。
Hyra 2.0 已產出蛋白質模型，但產物不等於代理本身
截至本次查核，騰訊已在成果儲存庫發布兩個特別值得注意的專案。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 驗證 BPB。簡單來說，BPB 是衡量文字預測表現的損失指標，在這項工作中越低越好。
對開發者而言，這不是一篇空泛的「調參心得」，而是具體涵蓋注意力視窗、最佳化器設定、額外的 n-gram 特徵與訓練排程。我們建議先理解這些可重現的改動，再判斷是否適合自己的模型，不要將別人的訓練設定直接套用到完全不同的資料規模。nanochat 實驗
GPU 運算子最佳化：用可執行的實作呈現速度提升
GPU 最佳化很容易遇到一種情況：程式碼看起來更進階，實際上卻更慢，甚至對部分輸入算出錯誤結果。Hyra 在 SOL-ExecBench 公開了部分實際提交的成果，包含注意力、MoE 分派、矩陣乘法與推論階段的運算子。公開目錄列出 10 個通過正確性檢查的範例，每個都有提交編號、執行延遲與成績。
我們特別重視它保留了正確性檢查狀態。例如，某個 Flash/GQA attention 範例記錄的延遲為 0.177612 毫秒，但這只適用於對應的工作與硬體評測，不能推論任何模型的注意力計算都能達到相同速度。對推論服務團隊，我們建議先固定輸入形狀、精度、硬體與編譯器版本，再比較最佳化前後的延遲與輸出是否一致。
數學發現：從候選答案走向可查核的證明資料
數學是研究代理另一個值得關注的領域。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 個有正確性檢查的範例，但這些範例不能取代完整的基準資料集。
我們的建議：推論閘道或 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 產出的獨立模型，不是代理的端到端速度。騰訊公開的 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 比較：Hyra 在同類 AI 自動研究任務中發布了進一步改善的結果
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 研究如何擴大「候選方案、自動評估、繼續搜尋」的循環。論文涵蓋 6 個領域的 21 項研究任務，並公開量子電路路由等結果。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 代理 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 安裝與呼叫
為什麼重現時無法取得相同成績？應該如何評估成本？
我們建議先分開計算模型推論、訓練重現與完整研究代理的成本。公開 nanochat 紀錄使用一張 B200，nanoGPT Speedrun 使用八張 H100；都需要對應的資料、驅動程式、相依套件與驗證設定。即使程式碼相同，顯示卡時脈、編譯快取、負載與隨機性也可能影響最終指標。HyInv 的加速測試也明確排除了首次 Triton 編譯與 CUDA Graph 擷取時間。
因此，我們會用三類指標評估：品質是否達標、任務總耗時，以及每個通過驗證的結果需要多少資源。訓練任務要記錄 GPU 小時與至少三次執行的平均值；線上推論要分別統計首個請求延遲、穩定運作時的吞吐量、顯示記憶體用量與失敗率；研究代理還須納入失敗實驗與人工檢查時間。目前沒有可查核的 Hyra 2.0 通用 API 價格，因此我們不會填入猜測的 Token 單價。