Tencent’s 214 GiB Hy4 build makes open weights deployable—not practical
AngelSlim has released two GGUF builds of Tencent’s Hy4 preview. The smaller one sharply lowers the memory threshold, but it still demands substantial GPU infrastructure, a patched runtime and independent quality testing.
What changed
Tencent’s AngelSlim team has published two GGUF builds of Hy4 preview. The conventional Q4_K_M file is 435.20 GiB, while a mixed 1–2-bit build reduces that to 213.66 GiB. The underlying Apache 2.0 model has 770 billion parameters, activates 49 billion per token and supports a one-million-token context.
Not desktop AI
The smaller artifact roughly halves the memory required for full GPU residency, but 214 GiB is still far beyond ordinary developer hardware. Both builds also require a patched llama.cpp because the Hy4 architecture is not yet supported by the stock runtime.
What we would do
We would start with the hosted endpoint and evaluate real tasks at production concurrency. Self-hosting becomes rational only when steady utilisation or data-control requirements outweigh the hardware, runtime integration and maintenance costs; a preview model on a custom inference stack should not become a default dependency.
The arrival of a 213.66 GiB GGUF build matters, but not because Hy4 preview suddenly belongs on a developer desktop. It does not. This is still a serious server deployment with a large GPU-memory requirement, and neither published build runs on stock llama.cpp without architecture patches. At Virtual Arc, we would not buy hardware or anchor a production architecture to this preview yet. We would first run the hosted API against our own workloads and measure cost per accepted completion, p95 latency, tool-call reliability and failure recovery. Only if sustained utilisation, sensitive data or control requirements made infrastructure ownership defensible would we run a bounded trial of the smaller build. Even then, we would keep it behind a provider-neutral routing layer with a tested rollback path. Open weights remove vendor permission from the equation; they do not remove electricity, capacity planning, observability, patching or on-call work. For most software teams, Hy4 has become worth benchmarking, not worth migrating to.