HY4 Preview Benchmarked: How the 770B MoE Compares

HY4 Preview: Big Ambition, Honest OpenVibeEval Numbers

Tencent published HY4 preview on August 28, 2026. I ran it through OpenVibeEval the same day on the Work-Buddy harness across all eight standard frontend prompts. Seven of the eight results are committed to my local results tree and visible on the public site at openvibeeval.com/models/hy4-preview. The model is bigger, more verbose, and worth a close look.

Tencent released HY4 preview as a flagship Mixture-of-Experts: 770 billion total parameters, 49 billion active per token, a one-million token context window, and the permissive Apache 2.0 open-source license. The release follows the same open-weights distribution path the HY family has used since the start.[1]

Public reviewers and aggregators position HY4 preview as a direct entry into the top tier of open-weights models. LM Market Cap and openai-hub both cover the launch as a flagship reasoning model. The aitoollab summary calls it top-of-class for open-weights in China. I am comfortable repeating that third-party signal because the source pages are linked.[1][3]

My own frontend benchmark tells a more nuanced story. HY4 preview produces substantially more raw code and DOM nodes than HY3. The bigger build brings real visual ambition. It also brings clear accessibility regressions on prompts that depend on interactive state machines.

The model is impressive on static layouts. It is not safe to ship the unvetted output to a client-facing product. Add a boundary check before you wire it into a frontend pipeline.

Architecture: 770B / 49B MoE, 1M Context, Apache 2.0

The base is a 770B parameter Mixture-of-Experts. 49B parameters activate per token. The context window is one million tokens. Tencent shipped the weights and code under Apache 2.0, so the model can be self-hosted without a separate license negotiation.[1][4]

The repository is on Hugging Face and ModelScope. Mirrors are published on GitCode, AtomGit, and CNB. Pick whichever distribution you already trust.[1][4]

Public reviewers and aggregators describe HY4 preview as a top-tier open-weights model on code generation leaderboards. That is a third-party signal worth weighting. I am not going to put a specific rank on the model from my own data because OpenVibeEval measures rendered frontend quality, not leaderboard scores.[3]

API pricing on Tencent Cloud TokenHub is reported at 6 RMB per million input tokens and 18 RMB per million output tokens, with cached input hits around 0.3 RMB per million. Read the published pricing page before you commit. The numbers shift.[1][3]

That puts HY4 preview roughly an order of magnitude above the budget flash tier. It is still meaningfully cheaper than the closed proprietary flagships. The cost story is the kind of thing that makes finance green-light a pilot.[3]

The official HY4 preview page is honest about the state of the release. Tencent calls it an early iteration with headroom in pretraining and post-training. They flag known issues: excessive self-verification, complex reasoning loops, and capability drop-offs on long-horizon tasks. I trust that disclosure because it is the launch team saying out loud what I would have flagged from the OpenVibeEval data anyway.[1]

Internal Engineering Blind Evaluation and Mathematical Progress

Tencent published an internal blind evaluation where HY4 preview reportedly edges past GLM 5.3 and Kimi K3 on average. I am treating that result as one data point, not the definitive read. Their own evaluation harness is not the same as mine.[1][2]

The win rate breakdown they published is competitive rather than dominant. Against GLM 5.3 the split is roughly even. Against Kimi K3 it is roughly even. Take that as confirmation that the open-weights frontier is crowded at the top, not as a clean ordering.[2]

Different models retain distinct strengths across specific workflows. A 40% loss rate against both competitors is a reminder that the model you pick depends on the task you have, not on a single leaderboard score.[2]

I am dropping the scientific research tangent. This is a frontend benchmark blog. If you want the math, the Tencent HY research page covers it directly.[2]

Tencent keeps a two-month release cycle. Releasing HY4 preview early is a deliberate move to collect real-world feedback from WorkBuddy, CodeBuddy, Yuanbao, and ima before the production model lands.[2][3]

OpenVibeEval Metrics: Verbosity and DOM Bloat

On the Work-Buddy harness, HY4 preview generated an average of 1,745 lines per single-file HTML artifact across the seven clean prompt runs.

That is a 76% increase over the 993 lines HY3 averaged on zcode. The model is not generating the same thing bigger. It is trying to construct richer UI frameworks inside a single file, with more detailed CSS blocks and more layered container structure.

The DOM tells the same story. HY4 preview averaged 515 nodes per rendered page. HY3 averaged 125. The HY4 page is four times heavier on the DOM side.

That expansion hits the accessibility score. HY4 preview averaged 70.4 on Work-Buddy. HY3 averaged 75.6 on zcode. The aggregate number regresses.

Bigger HTML brings more unmapped ARIA attributes, more broken focus indicators, and more redundant wrapper elements. The extra structural volume improves visual complexity. It costs compliance on automated axe-core checks.

Per Prompt: High Ceilings, Real Floor

On the static layout prompts, HY4 preview is strong. Web audio sequencer 100, retro arcade 95, digital garden 92. The model builds structured visual layouts and self-contained game loops competently. On web audio it wired the Web Audio API cleanly and the canvas loops held up. On digital garden the responsive grid was solid.

These high scores represent structured visual layouts and self-contained game loops. On the web audio sequencer, the model generated functional Web Audio API bindings alongside clean canvas rendering loops. On the digital garden, it organized responsive grid layouts effectively.

On the interactive and state-heavy prompts the numbers drop. Codesense SaaS landing 83. Smartwatch storytelling 83. Analytics dashboard 68. Vector drawing canvas 42.

The crypto trading terminal is the floor: 0 on accessibility. The model produced a detailed visual interface with trading charts and order panels, but it did not wire the controls to a state machine. The buttons exist in the DOM without functioning handlers.

axe-core flagged every disconnected control as a violation. Buttons and input fields without ARIA states or working handlers fail on the same automated checks that pass on the static layouts.

The interactive and canvas-bound prompts are the operational floor. The static and pattern-bound prompts are the ceiling. The model builds rich visual presentations. It does not consistently manage complex state wiring.

Methodology: The Harness Confound

Methodological honesty first. The harness is part of the test. Comparing results across different harnesses blends model capability with harness execution parameters.

In my evaluation suite, HY3 ran on zcode. HY4 preview ran on Work-Buddy. The aggregate metrics on the two harnesses are not directly comparable. I am calling that out before anyone reads the numbers as a clean HY3 vs HY4 ranking.

The harnesses differ in system prompt construction, tool integrations, file modification strategy, and retry behavior. One harness can enforce clean structural constraints. Another can encourage verbose component wrapping. The same model can look different across the two.

The honest read: HY4 preview generates more ambitious UI structures. The accessibility ceiling on Work-Buddy is lower than what HY3 achieved on zcode. Whether that is the model or the harness is the question that the next run will answer.

I do not have a HY3 on Work-Buddy, and I will not fabricate synthetic numbers. A dedicated HY4 preview run on zcode is queued. The next comparative piece will be harness-clean.

Architecture and Self-Hosting

Self-hosting HY4 preview means multi-GPU nodes with enough VRAM for sparse attention layers and speculative decoding. The model is permissive to run, but it is not a single-GPU workload.[4]

The architecture uses a sparse attention design that reuses index positions across layers in the million-token context window. Long-context memory retrieval overhead drops as a result. The official docs cover the details.[4]

The training stack uses a multi-residual-stream design and a Multi-Token Prediction layer for speculative decoding. The release notes describe the throughput gains as significant. I am not going to repeat every number from the docs. Read the official page.[4]

The Tencent team says HY4 preview participated in tuning its own training pipeline, data management, and evaluation framework. That is the kind of claim that needs to be taken with context. It is the model team describing their own process.[3]

Official deployment guides cover vLLM and SGLang with 8-way tensor parallelism on FP8 quantized weights. A 770B total MoE still demands serious VRAM even when only 49B fire per token. Plan the host before you start the download.[4]

The standard vLLM launch command is on the official deployment page. Treat the example below as a sketch of the configuration, not a copy-paste:

python3 -m vllm.entrypoints.openai.api_server --model tencent/hy4-preview --tensor-parallel-size 8 --quantization fp8 --enable-speculative-decoding

Evaluation Checklist for HY4 Preview

Do not deploy unvalidated HY4 preview output to end users. The interactive floor is real. Use this checklist to wire it into a frontend pipeline without shipping a regression.

Isolate every generated single-file artifact inside a restrictive iframe sandbox. Let scripts run. Block same-origin permissions so state leakage from the preview does not reach the surrounding app.

Run axe-core audits on every generated file. The specific things that fail on HY4 preview are missing form labels, unmapped ARIA attributes, and broken keyboard focus states. Check for those first.

Validate interactive state machines manually or with a test script. Confirm that buttons trigger state changes rather than failing silently. The crypto trading terminal failure on my run was exactly that: the layout rendered, the controls did nothing.

Prune generated DOM trees before rendering. 515 nodes per page is heavy. Strip redundant wrapper elements and you keep the visual ambition without paying the a11y cost.

Log the model identifier and the exact harness configuration alongside every result in a version-controlled git repository. That is the same discipline OpenVibeEval uses, and it is what makes the comparison reproducible when the next iteration lands.