Hunyuan Hyra 2.0: automated research, protein design, benchmarks and API access

What is Hunyuan Hyra 2.0?

Hyra 2.0 is Tencent Hunyuan’s automated research agent, not an ordinary chat model

A chat model answers questions. A research agent works on a testable problem until it produces a result. Tencent calls Hyra the Hunyuan Research Agent. Its published work covers small-model training, GPU operators, mathematical problems, quantum circuits, protein modeling and prediction algorithms.

For example, a chat tool can explain how to speed up training. A research agent aims to change the training script, run experiments, obtain new measurements and leave code and logs that others can inspect. To understand Hyra, we think the useful questions are whether its solutions can be reproduced, whether they improve on existing baselines and whether the gains justify the computing resources.

Tencent’s public Hyra-results repository mainly contains final solutions and some reproduction scripts. It does not fully disclose the agent’s research scheduling, search strategy or underlying models. Hyra results repository

Learning from experiments: connecting code, scores and verification

Hyra’s published results share a common feature: the problems usually have a measurable goal. Lower validation loss after training is better; shorter training at the same accuracy is better; fewer added gates in a quantum circuit is better. This lets a promising idea become actual code, an execution record or a proof, rather than stopping at a plausible explanation.

We suggest thinking of this approach as four steps with checkable outcomes: define a target metric, generate candidate solutions, evaluate them in an external environment and save the verified results. This is a working pattern inferred from the public artifacts. It does not mean Tencent has published Hyra 2.0’s complete internal architecture.

For everyday users, a useful example is asking it to make an already working program faster. That requires test data, a working environment and clear acceptance criteria. An instruction as vague as “make the algorithm better” leaves even a strong model without a clear definition of success.

Hyra 2.0 has produced protein models, but those models are not the agent itself

At the time of this review, two projects in Tencent’s results repository stand out. HyInv is a protein inverse-folding model with about 1.96 million parameters, generating amino acid sequences from protein backbone structures. HyPLM-Flash is a protein language model with about 650 million parameters, used for protein sequence representations and related prediction tasks. Both READMEs state that they were trained by Hyra 2.0.

It is worth being precise here: HyInv and HyPLM-Flash are independent models with code and weights that you can obtain and run using the project instructions. They are not a general chat model called hyra-2.0. They address structure-to-sequence design and sequence encoding for downstream analysis, respectively. For researchers, this is more concrete than saying “AI can do research”: there is a specific task to start reproducing.

Project details: HyInv README · HyPLM-Flash README

Hunyuan Hyra 2.0’s main capabilities and strengths

Automated AI research: improving small-model training recipes, not just suggesting changes

We see automated searches for better training recipes as one of Hyra’s main uses. The nanochat_autoresearch project provides an inspectable train.py, run scripts and complete training logs. Its published configuration achieves 0.901543 validation BPB on a single NVIDIA B200 within a fixed training budget of about 300 seconds. BPB is a loss metric for text prediction; for this task, lower is better.

For developers, this means the result is more than a vague account of parameter tuning. It includes concrete changes to attention windows, optimizer settings, extra n-gram features and the training schedule. We recommend understanding these reproducible changes first, then deciding whether they fit your model, rather than copying someone else’s configuration to a very different data scale. nanochat experiment

GPU operator optimization: turning speed gains into runnable implementations

GPU optimization has a common trap: more sophisticated-looking code may actually run slower, or even produce incorrect results for some inputs. In SOL-ExecBench, Hyra provides selected real submissions covering attention, MoE dispatch, matrix multiplication and inference operators. The public directory contains 10 examples that passed correctness checks, each with a submission ID, latency and score.

We particularly value the recorded correctness status. One Flash/GQA attention example reports a latency of 0.177612 milliseconds, but that figure belongs to its particular task and hardware evaluation. It does not imply that every model’s attention computation will run at that speed. For inference service teams, we recommend fixing input shapes, precision, hardware and compiler versions before comparing latency and output consistency.

GPU operator results

Mathematical discovery: moving from candidate answers to checkable proofs

Mathematics is another area to watch. Hyra’s repository records results in geometry, combinatorics and operator inequalities. For example, the lower volume bound for three-dimensional convex bodies of constant width improved from about 0.380799 to 0.411040. Notes added on November 2, 2026 also report a result on Petty’s equilateral set conjecture in five dimensions and a counterexample to Yau’s circle action conjecture in the non-simply-connected case.

These findings should not become a claim that AI has solved every mathematical conjecture. We care about the scope of each proof, exactly which parts were formally checked and whether mathematical peer review is still needed. For serious research, we recommend keeping the original theorem statement, all assumptions, proof files and independent verification records before citing the result publicly.

Mathematical results directory

Protein design: HyInv turns structures into candidate amino acid sequences

HyInv addresses a specific task: a researcher has a protein backbone structure and wants sequences that may fit it. It offers command-line and Python interfaces, with support for reading PDB structure files, selecting chains, fixing chosen positions and generating several candidates using random seeds. Its published weights are about 7.8 MB, and the reference implementation runs on a CPU or GPU.

For biotechnology teams, the benefit is automating the repetitive generation of candidate sequences. But generating a sequence is not the same as discovering an effective drug. Candidates still need structural, stability and experimental validation. We suggest checking formats and outputs on a small set of public structures first, screening with your team’s structural scoring process next, and only then moving to experiments.

HyInv project and running instructions

Protein sequence analysis: HyPLM-Flash suits batch encoding and downstream prediction

HyPLM-Flash serves a different purpose from HyInv. It takes protein sequences and returns vector representations for individual residues or entire sequences, as well as logits for mutation scoring. Tencent’s implementation includes an INT8 inference engine and reports throughput of about 130,000 residues per second on a single H20. This comes from the specified official environment, not a speed guarantee for any GPU.

We suggest treating it as a sequence feature extractor within a research system. You could encode proteins in batches, then pass the vectors to your own classification, clustering or property-prediction software. For a general developer, understanding that amino acid sequences go in and vectors come out is more useful than focusing on the 650 million parameters. Researchers should compare accuracy, batch capacity and cold-start time when choosing between INT8 and BF16 for their tasks.

HyPLM-Flash project

Hunyuan Hyra 2.0 benchmarks and performance

This section uses task-level experimental data published by Tencent. These figures are not a unified leaderboard for a Hyra 2.0 chat model. Some describe discoveries by the Hyra research system; others evaluate independent models trained by Hyra 2.0. Whether the results transfer to your work still depends on the test environment and baseline.

Language-model training quality: nanochat validation BPB falls from 0.9109 to 0.9015

Tencent’s repository compares its result with a similar record published by Recursive: the previous result was 0.9109 BPB, while Hyra reached about 0.9015 BPB, an absolute difference of about 0.0094. Hyra’s exact recorded result is 0.901543, using 1× B200, with about 300.1 seconds of training and 348.4 seconds in total including setup and evaluation. The improvement here means lower validation loss, not a corresponding increase in general question-answering accuracy.

Our advice: If your team optimizes small-model training, start by reproducing this project and checking GPU memory, data preparation and validation methods. For commercial training, your own dataset metrics and total training costs still matter. Do not assume that gains in a five-minute benchmark apply to every model size.

Hyra nanochat record · Recursive baseline

Training speed: nanoGPT Speedrun drops from about 77.5 seconds to 76.435 seconds

In nanoGPT Speedrun, Hyra’s public script uses FP8 for large matrix operations and changes the training schedule. The repository keeps three runs: 76.431, 76.467 and 76.408 seconds, averaging 76.435 seconds, with mean validation loss around 3.28007. Compared with the cited baseline of about 77.5 seconds, this saves about 1.1 seconds, or 1.4%.

These results depend on strict conditions: 8× H100, the matching CUDA, PyTorch and Triton versions, and the corresponding dataset. The mean loss rounds to 3.280. A displayed value of 3.280 does not mean every run was strictly below 3.280.

Our advice: Consider this FP8 optimization as an upgrade candidate only if your training environment is similar. We would reproduce at least three runs and compare averages, variation and final loss. If your system already uses different operator implementations, start with a small A/B test.

Hyra’s three nanoGPT runs

GPU operator score: SOL-ExecBench rises from 0.754 to 0.771

In the published SOL-ExecBench comparison, Recursive’s aggregate SOL baseline is 0.754, and Hyra reports 0.771, a gain of 0.017. SOL measures how closely an implementation approaches the performance limit defined by this benchmark. It does not mean 77.1% general code correctness. Tencent also publishes 10 examples with correctness checks, but those examples do not replace the complete benchmark dataset.

Our advice: For inference gateways and GPU services, test the operators that are actual bottlenecks in your workload. Record P50/P95 latency, throughput, GPU memory and numerical error. Chasing the highest score on a single microbenchmark may not reduce the end-to-end cost of the full service.

Hyra SOL-ExecBench · Recursive’s published results

Quantum circuit routing: added CNOT gates fall from 269,037 to 258,369

Quantum computing also has measurable optimization tasks. When two qubits are not adjacent on physical hardware, a routing algorithm must add operations. Tencent’s repository records 61 verified circuits and compares three topology types, Q20, Willow-style and Heron-style, against the baseline cited by SimpleTES:

On the basis used in this table, that is 10,668 fewer CNOT gates, a reduction of about 4.0%. It measures circuit-mapping overhead, not a 4% speedup for the whole quantum computer.

Our advice: If you compile quantum circuits, check the generated OpenQASM and connectivity constraints first. If you are choosing a general AI chat tool, this result has no direct connection to everyday answer quality.

Quantum circuit project · SimpleTES paper

Protein inference: HyPLM-Flash reaches about 130,000 residues per second; HyInv supports millisecond-scale batch design

These figures concern independent models produced by Hyra 2.0, not the agent’s end-to-end speed. Tencent reports about 130,000 residues per second for HyPLM-Flash using INT8 on a single H20. In the accompanying comparison across 32 tasks and 28 public checkpoints, it reports a zero-shot ProteinGym Spearman correlation of 0.409, statistically close to several protein encoders of similar size. This measures correlation, not classification accuracy.

For HyInv, Tencent reports about 25 milliseconds on the optimized BF16 path versus 999 milliseconds for the reference implementation when generating a batch of 128 protein designs of length about 148 on an H20. The timing excludes initial compilation and CUDA Graph capture. The optimized path also differs numerically from the FP32 reference path, so speed alone is not enough to decide whether to switch.

Our advice: Biology research teams should evaluate quality, batch throughput and reproducibility separately. If you often process just one short sequence, measure first-request latency first. Residues per second matters more for large offline batches. Sequence scores also cannot replace wet-lab validation.

HyPLM-Flash · HyInv

Comparing Hunyuan Hyra 2.0 with Recursive, SimpleTES, TTT-Discover and AlphaEvolve

These are research automation systems or research frameworks, not four chat models you can swap in the same chat API. We use numbers from shared tasks wherever possible. Where there is no common test, we compare working methods and suitable uses only.

Recursive: Hyra publishes further improvements on similar automated AI research tasks

Recursive’s First Steps Toward Automated AI Research is a fairly direct reference. It publishes results for fixed-budget small-model training, training speed and GPU operator optimization. Hyra compares against these baselines in its own public directory:

We think Hyra demonstrates further improvements on these public tasks, but comparisons between organizations still require careful checks of the code, hardware and scoring tools. Where we would use this: Teams studying training algorithms or GPU performance can reproduce work from both repositories. Teams that simply need a ready-made support or writing API need not change their everyday models because of these scores.

Hyra records · Recursive research results

SimpleTES: both rely on objective scores; Hyra uses fewer gates on the published quantum routing task

SimpleTES studies how to scale the cycle of generating candidates, evaluating them automatically and continuing the search. Its paper covers 21 research tasks across 6 fields and publishes results including quantum circuit routing. In its public comparison across three hardware topologies, Hyra reduces total added CNOT gates from 269,037 to 258,369. For this task, Hyra provides an improved candidate solution.

We would not turn a better result on one task into a claim of overall superiority. SimpleTES is especially useful for its systematic explanation of experimental evaluation and scaling strategies, making it a good resource for building research optimization workflows. Where we would use this: Read the SimpleTES method when designing your own automated experiment platform. Study Hyra’s OpenQASM files when you want concrete quantum routing results.

Original SimpleTES paper · Hyra quantum routing results

TTT-Discover: continued training at test time, alongside Hyra’s later mathematical improvements

TTT-Discover’s distinguishing feature is that the model keeps learning while solving a particular research task, rather than repeatedly prompting a fixed model. Its paper reports discoveries in mathematics, GPU operators and biological analysis, and provides reproducible code. Hyra cites its previous autocorrelation constant record of 1.502870 and reports a further improvement to 1.502850. The difference is small, but percentages alone do not determine the research value of mathematical optimization requiring precise numerical bounds.

There is no complete, public, unified comparison of the two methods and their experimental budgets. Where we would use this: Start with TTT-Discover to study how models keep learning on a specific task. Look at Hyra’s results organization to see how research can be documented through code, numerical evidence and papers.

TTT-Discover paper · Hyra mathematical results

Google AlphaEvolve: checkable research results versus large-scale production experience

Google DeepMind’s AlphaEvolve also combines language models with automated evaluators to find better algorithms. Google describes deployments in data-center scheduling, chip design and model training, including the recovery of about 0.7% of data-center computing resources on average. That is a production case study, not a Hyra benchmark on the same project, so we would not put the figures in one table to rank them.

Hyra is useful for its public mathematical, quantum and protein research artifacts. AlphaEvolve is useful for its experience taking experimental optimization into production infrastructure. Where we would use this: If you manage live services, we would prioritize AlphaEvolve’s emphasis on production validation and accounting for long-term gains. If you want to learn how to submit checkable research results, Hyra’s task directories offer easier entry points for individual reproductions.

Google DeepMind AlphaEvolve · AlphaEvolve production progress

Hunyuan Hyra 2.0 API questions

Why can’t I find hyra-2.0 in API Hop’s model list?

Because the current public model catalog does not list Hyra 2.0 as a callable text model. If API Hop adds support for hyra-2.0, we will share an update promptly.

Unified Chat Completions documentation · Hyra results repository

What programming interfaces do HyInv and HyPLM-Flash provide?

These two independent models trained by Hyra 2.0 have concrete interfaces, but using them is not the same as calling a Hyra Agent API. HyInv supports the CLI and Python, for example:

# Run in an environment with HyInv installed; structure.pdb is your structure file
python -m hyinv design --pdb structure.pdb --n 16 --seed 0 --out designs.fasta

HyPLM-Flash provides a Python encoding interface, for example:

from hyplm import HyPLMEncoder

# Download, merge and verify the weights as described in the project instructions first
encoder = HyPLMEncoder.from_pretrained("weights")
vectors = encoder.encode(["MKTAYIAKQRQISFVKSHFSRQ"], pooling="mean")

We suggest deploying them as separate services: install the dependencies specified by the repository, then check inputs and outputs with small samples. HyPLM-Flash’s accelerated implementation also depends on CUDA, Triton and a suitable GPU environment. Do not assume any CPU or graphics card can match the published throughput.

Installing and calling HyInv · Installing and calling HyPLM-Flash

Why might reproduced results differ, and how should I assess costs?

Start by separating the costs of model inference, training reproduction and a complete research agent. The public nanochat record uses one B200, while nanoGPT Speedrun uses eight H100s. Both require matching data, drivers, dependencies and validation settings. Even with identical code, GPU clock speeds, compilation caches, load and randomness can change the final metrics. HyInv’s accelerated tests also explicitly exclude initial Triton compilation and CUDA Graph capture time.

We would therefore use three groups of measures: whether quality meets the target, total task time and resources spent per verified result. For training, record GPU hours and averages over at least three runs. For online inference, track first-request latency, steady-state throughput, GPU memory and failure rates separately. For research agents, also count failed experiments and human review time. There is currently no verifiable general Hyra 2.0 API price, so we will not invent a per-token rate.

Hyra nanochat reproduction instructions · nanoGPT Speedrun reproduction instructions