Iluvatar CoreX held its 2026 media open day in Shanghai on Tuesday, showing the Tiangai 300 general-purpose GPU running on live hardware for the first time, Qudong China reported on October 28.

What's New: It Actually Runs

The live Tiangai 300 demo was the centerpiece of the event. Until now, Iluvatar CoreX had disclosed little beyond architecture details and roadmaps; this was the first time the chip was shown running.

Iluvatar CoreX says the Tiangai 300 is the first domestic general-purpose GPU to match NVIDIA's H200 in measured performance, with third-party testing putting its normalized per-card aggregate throughput at 1.05 times that of the H200.

"Normalized per-card aggregate throughput" is a composite metric: it takes a larger multi-card test result, divides it down to a per-card average, and then compares that figure against the H200. It is not latency on a specific model, nor peak performance on a particular class of task, but a normalized measure of overall throughput. The company has not yet released the test methodology, model workloads, or workload conditions behind the comparison.

Super Node: 144 GPUs in a Single Rack

IXL144, the super node system built around the Tiangai 300, made its first appearance slightly earlier at the China International Industry Fair. It packs 144 GPUs and 18 CPUs into a single rack with roughly 10.1 TB of memory, which Iluvatar CoreX calls "the industry's highest-density single-rack GPU super node."

The super node format is an answer to the problem of individual cards not being fast enough: cram a large number of GPUs into one rack over high-speed interconnects, present them as a single logical pool of computing power, and cut the overhead of rack-to-rack communication. The 144-GPU, 18-CPU ratio suggests the CPUs are there to handle scheduling and data supply, not as an afterthought.

By Iluvatar CoreX's own calculations, the system lowers cost per million effective tokens by 40% compared with mainstream international alternatives. Cost per million effective tokens is an economic metric for the inference side, spreading hardware spend, utilization, and energy consumption across actual output. It tracks what customers actually pay far more closely than raw per-card performance does.

Heterogeneous Computing: Splitting Compute Stages Across Different Silicon

The open day also covered progress on heterogeneous deployment: the company says it has successfully run the first domestic AFD disaggregation setup spanning GPUs and XPUs, cutting inference latency by 60%.

AFD disaggregation generally refers to splitting compute stages such as attention and the feed-forward network across heterogeneous compute units and scheduling each where the hardware is strongest. During large model inference, the attention and FFN portions have different memory access profiles: one is bandwidth-hungry, the other compute-hungry. Routing each to the hardware better suited to it has been one of the more mainstream approaches to inference optimization over the past year, with scheduling and the movement of intermediate results as the hard parts. Iluvatar CoreX puts the gain at a 60% latency reduction, though like the 1.05x figure above, this is a company-disclosed number.

On-Device: A 300 TOPS Chip

On the device side, the Tongyang TY1200's measured performance was described as "surpassing the Thor T5000." Iluvatar CoreX says the TY1200 is the first domestic on-device product to deliver GPU-accelerated physics simulation based on MuJoCo-Warp.

Previously disclosed specifications put the Tongyang TY1200 at 300 TOPS of dense compute, aimed at AI PCs and embodied intelligence applications. TOPS stands for trillions of operations per second, and dense compute refers to performance without sparsity-based skipping.

The MuJoCo-Warp detail is easy to skip past, but it matters for embodied intelligence. MuJoCo is a physics simulation engine widely used in robotics, and Warp moves that simulation onto the GPU to run in parallel. Training embodied systems requires massive numbers of parallel simulation environments for trial and error; if the simulation can only run on a CPU, both the number of environments and the speed of iteration hit a ceiling. Building this capability into an on-device chip means a robot can handle part of its training and validation locally, without shipping data back to the cloud.