Tencent Hy4: A 770B Open-Weight Model and What It Means for Your Business

Tencent Hy4: A 770B Open-Weight Model and What It Means for Your Business

The direct answer: on 28 August 2026 Tencent published Hy4 preview as an open-weight model under the Apache 2.0 licence, with 770 billion total parameters of which only 49 billion activate per token, and a context window of up to one million tokens. In practice that means any company can download the model and run it on its own infrastructure with no vendor permission and no per-call fee. It does not mean you can run it on a server in your office. The gap between those two sentences decides whether this news concerns you at all.

What was actually announced

Before any analysis, it helps to separate published facts from interpretation. What Tencent released in the model's official repository includes:

• Size and activation: 770 billion total parameters, 49 billion activated per token, in a mixture-of-experts architecture.
• Internal structure: 78 layers, the first dense and the rest mixture-of-experts with 256 routed experts plus one shared expert, with eight experts selected per token.
• Context window: one million tokens, with a vocabulary size of 120,832.
• Licence: Apache 2.0, a permissive licence allowing commercial use, modification and redistribution.
• Quantised variant: an FP8 version is available alongside the full-precision model.
• Inference acceleration: a built-in multi-token prediction layer supporting speculative decoding.
• Stated focus: the model targets coding, office productivity, game development and scientific research rather than general chat.

What was not announced, and should not be assumed, is any promise of superiority over closed models in your specific case. Published comparisons on public benchmarks tell you nothing reliable about performance on your documents, your customers' language and your sector's context. That answer only comes from internal testing on your own data.

Why the Apache 2.0 licence is not a small legal detail

Most of the conversation around open models focuses on output quality, while the real value for a business owner sits in the licence clause. A permissive licence means three practical things: running the model inside your infrastructure requires nobody's approval, modifying and tuning it on your data is permitted, and the continuity of your service does not depend on a vendor continuing to offer it or holding its prices steady.

That last point is the heart of the matter. A company that built its entire customer service on a single API carries a silent risk: a pricing change, a deprecated version or a shift in usage policy can send it back to square one. An open-weight model does not eliminate that risk, but it gives you an exit: the copy you downloaded stays yours.

The hardware maths the headline usually skips

This is where enthusiasm turns into numbers. 770 billion parameters at FP8 precision means roughly one byte per parameter, which is more than 700 gigabytes for the model weights alone before anything else. Add the context memory that grows with conversation length, and a one-million-token window implies substantial additional memory in real use, then add redundancy so the service does not fall over when a single node fails.

The conclusion is that this is a data-centre model, not an office-server model. Self-hosting it is a decision that demands specialised hardware and an operations team that knows how to shard a model across multiple GPUs and monitor latency and utilisation. That is a fixed cost which does not shrink when your usage drops, unlike an API where you pay for what you consume.

The practical rule: self-hosting only makes sense under one of two conditions. Either you have large, steady usage that makes fixed cost cheaper than variable consumption, or you face a regulatory or contractual requirement that prevents data from leaving a defined boundary. Outside those two conditions, self-hosting is usually an emotional decision rather than an economic one.

What makes the design technically interesting

The striking number in Hy4 is not 770 billion but 49 billion. A mixture-of-experts architecture means the model is enormous in capacity yet activates only a small slice of itself per token, so you get flagship-tier quality at a compute cost closer to a mid-sized model. This architectural direction is exactly what pulled open models close to closed ones over the past two years.

Add to that a sparse attention mechanism that reuses sparsity indices across layers, and a built-in multi-token prediction layer that enables speculative decoding to shorten generation time. In business language: these details lower cost per token and latency, and those two factors decide whether a feature can be rolled out to thousands of users or stays an internal experiment.

Three practical paths for your business

• A managed API on a closed model: the fastest route to launch, no operational burden, and a variable cost that grows with usage. The default path for any product's first six months.
• Hy4 through a provider that hosts it for you: you get the licence flexibility and the ability to move between providers without buying hardware. This is the practical middle ground many people overlook.
• Full self-hosting: maximum control and maximum cost. Justified when you face a strict data residency requirement or run large, stable operational volume.

The questions that settle the decision

Before spending a single riyal on this path, answer four questions honestly. What kind of data will pass through the model, and does any regulatory or contractual obligation prevent it from leaving? What is the expected monthly volume six months in, not in the first week? Do you, or your technical partner, have genuine round-the-clock operational capability? And have you built an abstraction layer in your application that lets you swap models without rewriting the product?

If the answer to the last question is no, that is your priority before any discussion about which model to use. The difference between a flexible company and a trapped one is not picking the right model, but building a system that keeps the choice changeable later at a reasonable cost. See our article on a local cloud region and data residency if residency is your primary driver.

How we handle this at Origami

We build client applications so the model is a replaceable component behind a unified internal interface, and we keep an evaluation set of real client cases that we run against any candidate model before adopting it. That turns news like the Hy4 release from a technical headline into a measurable decision: run the evaluation set, compare quality, cost and latency, then decide on numbers rather than impressions.

Sources

• Official repository for Hy4 preview from Tencent's Hunyuan team: github.com/Tencent-Hunyuan/Hy4-preview
• Apache 2.0 licence text: apache.org/licenses/LICENSE-2.0
• Saudi Personal Data Protection Law and its supervising authority: sdaia.gov.sa