A Dozen Physics Elements, 2000 Frames, 70fps: Moxin Binds Its 4D World Model to Ascend and Cuts Inference Cost to 30% of a GPU Stack
A Dozen Physics Elements, 2000 Frames, 70fps: Moxin Binds Its 4D World Model to Ascend and Cuts Inference Cost to 30% of a GPU Stack
Part One: Video Models Answer What It Looks Like. World Models Answer What Happens When You Move.
On November 4, 2026, at the Zhejiang sub-forum of the World Internet Conference Wuzhen Summit, Chen Tianrun — founder and CEO of Hangzhou-based Moxin Technology, and a post-2000s direct-to-PhD student in Zhejiang University’s School of Computer Science — took the stage alongside representatives of three national AI application pilot bases covering embodied intelligence, cultural tourism, and spatiotemporal geographic information. Together they launched one thing: MoWorld 2.0, an Ascend-native 4D world model.
The event itself was not small: the theme was “developing new quality productive forces — the strong increment lies in AI,” with over 1,200 attendees, and the Zhejiang sub-forum has run for 12 consecutive years. But what’s worth recording isn’t the venue. It’s the line Chen drew on stage:
Most video generation models answer “what does the picture look like.” MoWorld 2.0 answers “after an action happens, how does the world change.”
That isn’t rhetoric. It’s two fundamentally different technical goals.
Video generation models optimize for “do the pixels look real.” They don’t need to know how heavy a bookmark is — if the generated frames make the eye believe the bookmark fell, the job is done. Physics wrong? The audience probably won’t notice. Wind from the east but pages turning west? As long as the animation is smooth, nobody cares.
World models must know how heavy the bookmark is. Because their output gets consumed by an agent making decisions — if a robot trains in a virtual environment and learns the wrong physical response to “push the cup,” that training is a negative asset, and it will fall harder on real hardware.
MoWorld 2.0’s official framing is blunt: “not just depicting the world’s appearance, but teaching AI to understand the accurate, complete, deep connections among space, time, and physical laws.”
The live demo was a restrained piece of technical exposure:
A breeze turns the pages of a book, and a bookmark slips out from between them, falling to the floor.
To generate those five seconds correctly, the model must handle simultaneously: wind strength and direction (which way), paper flexibility (how the page bends), bookmark mass (how fast it falls), floor rigidity (how it bounces), and contact relationships between objects (the separation condition at the instant the bookmark leaves the page).
Miss any one and the image gives itself away — the bookmark clips through the floor, the pages stay stiff as steel plate, or the bookmark hovers in mid-air for half a second.
Officially, MoWorld 2.0 covers a dozen-plus physics elements: gravity, elasticity, buoyancy, lighting, soft bodies, fluids, rigid bodies, deformable bodies, thermal effects.
Part Two: How a Dozen Physics Elements Fit Inside One Model
There’s a technical choice that must be stated first: MoWorld takes a purely implicit spatial modelling route, not explicit 3D reconstruction.
The distinction matters.
The explicit route (3D reconstruction, point clouds, meshes) first restores the scene into a pile of geometry, then lets a physics engine compute. Pros: controllable, editable. Cons: it depends on reconstruction quality — inaccurate reconstruction means completely wrong physics, and reconstruction itself is slow, so real-time is out.
The implicit route encodes the whole scene into a high-dimensional representation via a neural network, learning physics from data rather than computing it from an engine. Pros: continuous, predictive, generalizable. Cons: opaque, hard to edit, prone to drift.
MoWorld’s answer takes both: implicit modelling underneath to learn physics, explicit 4D Gaussian assets at the output layer to stay editable.
That is — implicit during training and inference (enabling prediction of 2,000-frame dynamic scenes, which purely explicit pipelines struggle with), but what gets delivered to you is explicit (4D Gaussians: real-time renderable, repeatedly callable, editable).
The model underneath is an in-house KOKONI-World 4D world model at 14 billion parameters. KOKONI isn’t a new name — Moxin’s original business was consumer 3D printers, under exactly that brand. A 3D printer company handed its brand name to a world model.
"""
How implicit physics modelling and explicit 4D Gaussian output fit together.
"""
from dataclasses import dataclass, field
from enum import Enum
class PhysicsKind(Enum):
GRAVITY = "gravity"
ELASTICITY = "elasticity"
BUOYANCY = "buoyancy"
LIGHTING = "lighting"
SOFT_BODY = "soft_body"
FLUID = "fluid"
RIGID_BODY = "rigid_body"
DEFORMABLE = "deformable"
THERMAL = "thermal"
@dataclass
class SceneConditioning:
"""What the model must be told before it can simulate anything."""
prompt: str
initial_4d_state: dict = field(default_factory=dict)
horizon_frames: int = 2000
active_physics: list[PhysicsKind] = field(default_factory=list)
@dataclass
class FourDGaussianAsset:
"""
The delivered artifact: explicit, renderable, reusable.
Each Gaussian carries position, orientation, scale, opacity, colour,
AND a time component -- that extra t is what makes it 4D rather than 3D.
"""
positions: list[tuple[float, float, float]]
scales: list[tuple[float, float, float]]
rotations: list[tuple[float, float, float, float]]
opacities: list[float]
sh_coeffs: list[list[float]]
timestamps: list[float] # the 4th dimension
def frame_count(self) -> int:
return len(set(self.timestamps))
def supports_realtime_render(self, target_fps: int = 70) -> bool:
# Measured: 500+ fps for 3D/4D gaussian asset rendering,
# ~100 fps on phone. So yes, comfortably.
return True
def build_scene(prompt: str, kinds: list[PhysicsKind]) -> SceneConditioning:
return SceneConditioning(
prompt=prompt,
horizon_frames=2000,
active_physics=kinds,
)
def bookmark_demo() -> SceneConditioning:
"""
The live demo: breeze turns pages, a bookmark slips out and falls.
Five coupled physics effects in one shot.
"""
return build_scene(
prompt="breeze turns the pages of a book; a bookmark slips out and falls "
"to the floor; pages flex under the wind, bookmark lands and settles",
kinds=[
PhysicsKind.GRAVITY, # bookmark falls
PhysicsKind.SOFT_BODY, # pages bend
PhysicsKind.RIGID_BODY, # floor is rigid
PhysicsKind.LIGHTING, # light shifts as pages move
PhysicsKind.DEFORMABLE, # contact + separation at the page edge
],
)
if __name__ == "__main__":
scene = bookmark_demo()
print(f"prompt : {scene.prompt[:60]}...")
print(f"horizon : {scene.horizon_frames} frames")
print(f"physics : {[k.value for k in scene.active_physics]}")
print(f"coupled : {len(scene.active_physics)} simultaneous effects")
print("if any one is wrong, the eye catches it immediately")
The important word in that table isn’t “a dozen.” It’s “coupled.”
Any single physics element is easy in isolation — gravity is middle-school physics. The hard part is that they must all be correct in the same frame, and they must affect each other. Wind pushes the page → the page deforms → the gap between pages widens → the bookmark loses support → the bookmark falls → it lands and bounces → the bounce lifts the paper corner beside it. That’s a chain of propagation, and any broken link collapses the whole segment.
Video generation models can “draw each frame convincingly” independently. World models must keep the causal chain continuous across every frame. Which is why it predicts 2,000 frames — the frame count isn’t for length, it’s to give error a chance to surface. A physics error is invisible over 10 frames; over 2,000 it compounds into catastrophe.
Part Three: Ascend-Native — What Exactly Is “Native” About It
This is the part most technical write-ups skip past as marketing language, and it’s actually the most substantive.
The official claim: MoWorld 2.0 is a native 4D world model built on Huawei Ascend compute, with the entire training and deployment stack completed on a fully domestic Ascend base.
In the domestic-compute context, “native” has three concrete layers, and all three must hold.
Layer one: training actually runs. World model training has a specific difficulty — long sequences. Predicting 2,000 frames of dynamic scene means the temporal sequence length is dozens of times that of a normal video model, and attention compute plus memory footprint explode. The first item in Moxin’s joint work with Huawei is exactly long-sequence training — this isn’t moving a model over, it’s redesigning parallelism for Ascend’s memory hierarchy and communication topology.
Layer two: multi-card scheduling actually flows. Long sequences plus 14B parameters don’t fit on one card, so they must be sharded. The optimal combination of sharding strategies (sequence parallel, tensor parallel, pipeline parallel) differs completely across hardware. That’s what multi-NPU coordinated scheduling addresses.
Layer three: inference cost actually comes down. This layer decides commercial survival. The official number:
Inference cost drops to as low as 30% of an equivalent-scale GPU solution.
Thirty percent. If it holds, the same budget serves 3.3x the inference volume. For a system that must render 4D scenes in real time, this isn’t saving money — it’s the difference between “can’t afford to run it” and “can.”
"""
Why a 70% cost reduction matters more than it sounds.
"""
def inference_economics(requests_per_day: int = 100_000,
gpu_cost_per_1k: float = 1.00,
ascend_ratio: float = 0.30):
"""
Same workload, two hardware baselines.
"""
gpu_total = requests_per_day / 1000 * gpu_cost_per_1k
ascend_total = gpu_total * ascend_ratio
saved = gpu_total - ascend_total
capacity_multiple = 1 / ascend_ratio
print(f"{'Metric':<32}{'Value'}")
print("-" * 52)
print(f"{'daily requests':<32}{requests_per_day:,}")
print(f"{'GPU baseline cost':<32}${gpu_total:,.2f}")
print(f"{'Ascend-native cost (30%)':<32}${ascend_total:,.2f}")
print(f"{'daily saving':<32}${saved:,.2f}")
print(f"{'annual saving':<32}${saved * 365:,.2f}")
print(f"{'same budget serves':<32}{capacity_multiple:.1f}x the traffic")
print()
print("The interesting number is not the saving. It is the capacity multiple:")
print("a world model that renders in realtime only becomes a product")
print("when the marginal cost of one more rendered minute is near zero.")
inference_economics()
Why does “down to 30%” matter far more than “30% better performance”?
Because the world model business model is fundamentally sold by rendered duration. Embodied AI companies buy “training environment hours”; cultural tourism companies buy “virtual tour sessions”; film studios buy “reusable scene assets.”
Under that model, cost elasticity determines market size. If one minute of rendering costs 10 yuan, only top-tier clients can play. If it costs 3, mid-size teams enter, and the market grows by an order of magnitude. Cost reduction is the only road from “demo project” to “infrastructure” in this industry.
One detail from the same stage is worth noting: the forum also launched the Sunrise S3 supernode family from Xiwang, using LPDDR6 inference GPUs aimed at high-concurrency inference of trillion-parameter models. On the domestic compute line, model and silicon each moved forward a step in the same month — that synchrony is itself a signal.
Part Four: 70 fps and 500 fps Are Two Different Things
MoWorld 2.0 published three performance figures that are easy to conflate and must be separated:
| Metric | Value | Meaning |
|---|---|---|
| Video inference frame rate | 50 → 70 fps | Speed at which the model generates dynamic scenes |
| 3D/4D Gaussian asset rendering | 500+ fps | Speed at which existing assets render |
| Phone-side rendering | ~100 fps | Rendering speed on device |
These three differ by an order of magnitude because they measure entirely different things.
70 fps is “generation”: the model computing what the world becomes next. That’s neural network forward inference, running the big model once per frame. 70 fps means a per-frame budget of about 14.3 ms. Going from 50 to 70 compresses the budget from 20 ms to 14.3 ms — a 40% gain, but in engineering terms a leap from “barely usable” to “smooth,” because the human perceptibility threshold for stutter in interactive scenes sits right around there.
500+ fps is “rendering”: the asset already exists, and this is just drawing it. 4D Gaussian rendering is rasterisation, scaling with scene complexity, but no neural network — hence two orders of magnitude faster.
~100 fps is “device-side rendering”: drawing cloud-generated assets on a phone. 100 fps means the device only renders, never generates — a very smart division of labour.
"""
Generation fps vs rendering fps: two completely different budgets.
"""
def frame_budget(fps: int) -> dict:
budget_ms = 1000 / fps
return {
"fps": fps,
"budget_ms": round(budget_ms, 2),
"what_runs": None,
}
def compare_pipelines():
rows = [
("video inference (gen)", 50, "neural net forward pass, per frame", "before"),
("video inference (gen)", 70, "neural net forward pass, per frame", "after"),
("4D gaussian render", 500, "rasterisation only, no NN", "asset playback"),
("phone-side render", 100, "rasterisation on Kirin NPU/GPU", "asset playback"),
]
print(f"{'Stage':<26}{'fps':<8}{'budget':<12}{'what runs'}")
print("-" * 92)
for name, fps, what, _ in rows:
b = frame_budget(fps)
print(f"{name:<26}{fps:<8}{str(b['budget_ms']) + ' ms':<12}{what}")
gen_before = 1000 / 50
gen_after = 1000 / 70
print()
print(f"generation budget: {gen_before:.1f} ms -> {gen_after:.1f} ms "
f"({(gen_before - gen_after) / gen_before:.0%} tighter)")
print(f"render is {500 / 70:.1f}x faster than generation because it skips the NN")
print()
print("Design implication: put generation in the cloud, put rendering on the device.")
compare_pipelines()
Read together, these three figures reveal MoWorld 2.0’s architectural choice: generate in the cloud, render on the device.
That’s not a guess. The official description of the edge solution says exactly this:
The cloud generates high-quality 4D assets; the phone handles rendering and interaction.
Why must it split that way? Because a 14B-parameter model will never fit in a phone, while 4D Gaussian rendering already hits 100 fps on phones. Keep the heavy work in the cloud, push the light work to the edge — the only split that makes “high quality + low latency + interactive” all true at once.
The cost: you need a network. Offline, the device can only play cached assets.
Part Five: The 600-Million-Parameter Edge Version and That Pet App
This edge chain deserves its own section, because it’s closer to product reality than the model itself.
MoWorld 2.0 has an edge variant at roughly 600 million parameters, trained on Ascend and running inference on Kirin. Its landing form is an app called “Moxiaochong” (摸小宠), unveiled in October 2026 at Huawei’s new-device launch (Mate 90).
The premise is direct: users upload a few photos of their pet and get an interactive 4D digital twin.
The technical chain:
"""
End-to-end chain: a few phone photos -> a 4D pet companion.
"""
from dataclasses import dataclass
@dataclass
class PetPhotos:
count: int
resolution: str
angles: list[str]
@dataclass
class CloudStage:
"""Runs on Ascend. Heavy, asynchronous, tolerant of latency."""
model: str = "MoWorld 2.0 (KOKONI-World 14B class)"
task: str = "reconstruct + generate high-quality 4D gaussian asset"
output: str = "4D gaussian asset (positions, scales, rotations, "
output: str = "opacity, SH coeffs, per-frame timestamps"
latency_tolerance: str = "seconds to minutes -- user is waiting, not staring"
@dataclass
class DeviceStage:
"""Runs on Kirin. Light, synchronous, latency-critical."""
model: str = "MoWorld 2.0 edge variant, ~0.6B params"
task: str = "render + respond to touch/interaction"
target_fps: int = 100
budget_ms_per_frame: float = 10.0
def pipeline(photos: PetPhotos) -> dict:
cloud = CloudStage()
device = DeviceStage()
# Why the split works: the two stages have inverted cost profiles.
return {
"input": f"{photos.count} photos @ {photos.resolution}",
"cloud": {
"model": cloud.model,
"runs": "Ascend",
"does": cloud.task,
"tolerance": cloud.latency_tolerance,
},
"device": {
"model": cloud.model and device.model,
"runs": "Kirin",
"does": device.task,
"fps": device.target_fps,
"budget_ms": device.budget_ms_per_frame,
},
"why_it_works": [
"cloud carries the 14B model -> quality stays high",
"device carries 0.6B + rasterisation -> latency stays low",
"asset is explicit (4D gaussian) -> no NN needed at playback",
"only new asset generation needs the network",
],
}
if __name__ == "__main__":
out = pipeline(PetPhotos(count=5, resolution="12MP", angles=["front", "side", "top"]))
for k, v in out.items():
print(f"{k}: {v}")
Note the three engineering judgments here, each critical:
First, cloud uses 14B, device uses 0.6B — a 23x gap. But this isn’t “crippling the edge model,” because the device doesn’t generate at all; it only renders. The 600M version handles the “lightweight, locally-inferred parts” (pose response, interaction logic, local completion), not “shrink the whole 14B down.” The parameter gap reflects task division, not capability compromise.
Second, cloud latency tolerance is “seconds to minutes.” Generating a high-quality 4D asset takes time, and users accept it — because they’re “waiting for a thing to be built,” not “waiting for a page to load.” It’s an asynchronous task, not a synchronous request.
Third, the device budget is 10 ms. 100 fps means 10 ms per frame, the hard requirement for interactive apps. The device only rasterises, never runs the big model, so the budget holds.
Together these three say one thing: productising a world model is less about how strong the model is and more about “which compute goes where.” Stuffing 14B into a phone is fantasy. Stuffing 4D Gaussian rendering into a phone is reality.
Part Six: Why “Repeatedly Callable” Is the Key Phrase for 4D Gaussian Assets
One line in the official description is easy to skim past:
Outputs simulatable, real-time renderable, and repeatedly callable 4D Gaussian assets.
Of those three “capable ofs,” the most valuable is “repeatedly callable.”
Because that’s the dividing line between “model” and “asset.”
If every use of a scene requires re-running the model, your cost is linear — pay per use, more use costs more. In that mode, a world model can only ever be an API service.
But if the output is an asset you can store, the cost structure changes: generate once, reuse countless times. Marginal cost approaches zero.
"""
Why reusable assets change the business model from linear to near-zero marginal cost.
"""
def cost_structure(scenes: int, renders_per_scene: int,
gen_cost: float = 1.0, render_cost: float = 0.002):
"""
Compare: regenerate-on-demand vs generate-once-then-reuse.
"""
regenerate = scenes * renders_per_scene * (gen_cost + render_cost)
reuse = scenes * gen_cost + scenes * renders_per_scene * render_cost
print(f"{'Model':<34}{'Total cost':<16}{'Per render'}")
print("-" * 66)
print(f"{'regenerate each time':<34}${regenerate:,.2f}"
f"{'':<8}${regenerate / (scenes * renders_per_scene):,.4f}")
print(f"{'generate once, reuse':<34}${reuse:,.2f}"
f"{'':<8}${reuse / (scenes * renders_per_scene):,.4f}")
print(f"\nsaving: {(1 - reuse / regenerate):.1%}")
print(f"marginal cost of the Nth render: ${render_cost:.4f} (flat)")
print()
print("This is why the asset matters more than the model:")
print("a model is a service you rent; an asset is inventory you own.")
cost_structure(scenes=100, renders_per_scene=1000)
“Asset” and “service” mean completely different things commercially.
A service is rented per call; the customer pays forever and can always be swapped out. An asset is bought once; the customer can operate it independently — which sounds bad for you, but it opens entirely different customer segments: film studios want “a scene I can shoot repeatedly,” industrial digital twins want “a production line model I can repeatedly rehearse retrofits on,” cultural tourism wants “a scenic-area model I can repeatedly launch different events on.”
None of these three buy an API. They buy source material. And source material prices completely differently — APIs price by call volume; assets price by value.
Deeper still: why must it be 4D Gaussians and not something else?
Because 4D Gaussians simultaneously satisfy four conditions: ① expresses dynamics (a time dimension) ② renders in real time (rasterisation-friendly, 500+ fps) ③ is editable (each Gaussian is an independent primitive — add, delete, modify) ④ compresses (no voxel grid to store).
Compare: Mesh sequences are bulky, hard to edit, poor at dynamics; NeRF renders slowly and is hard to edit; voxels blow up memory. 4D Gaussians are currently the only choice that passes on all four axes of expressiveness, render speed, editability, and storage cost. That’s not an aesthetic choice — it’s the only solution the engineering constraints permit.
Part Seven: How a 3D Printer Company Became a World Model Company
This part is often skipped in technical analyses, and it’s actually the most informative.
Moxin Technology — full name Hangzhou Moxin Technology Co., Ltd. — was founded on June 7, 2021, with registered capital of 1.915106 million yuan. Its original business was consumer 3D printers, under the brand KOKONI — yes, the same name the 4D world model now carries.
How does a 3D printer seller become a world model company in five years?
First, while building 3D printers it was already solving “3D reconstruction.” The core pain point of consumer 3D printing isn’t printing, it’s modelling — ordinary people don’t use CAD. So the technical accumulation along the KOKONI line was fundamentally “how to get a 3D model quickly from simple input.” That’s the same technical lineage as a world model’s “reconstruct a 4D scene from images and video.”
Second, the founder’s academic direction lines up. Chen Tianrun is a direct-to-PhD student in Zhejiang University’s School of Computer Science, holding 41.31% directly and 63% on a fully-diluted basis — the actual controller. The R&D team centres on young researchers from the Zhejiang University orbit, spanning computer graphics, multimodal large models, robotics, spatial simulation, and domestic compute adaptation. Those five directions are precisely the five preconditions for a 4D world model — graphics for rendering, multimodal for input, robotics for downstream demand, spatial simulation for physics, domestic compute adaptation for cost.
Third, the funding cadence reveals the market’s read. Within 2026 Moxin closed five consecutive rounds totalling 2 billion yuan, at a valuation near 10 billion yuan. Investors include state-backed institutions such as Shenzhen Capital Group and Zhejiang Venture Capital, plus industrial capital spanning chips, compute, smart terminals, content platforms, and advanced manufacturing. A new round has launched, potentially around 1 billion yuan.
That investor structure deserves a read: chips + compute + smart terminals + content platforms + advanced manufacturing — this isn’t a financial portfolio, it’s a complete supply chain. Someone supplies compute, someone supplies devices, someone supplies content demand, someone supplies manufacturing deployment. Investing in a world model company is buying options on five downstream links at once.
"""
Reading the cap table as a supply-chain map, not a list of investors.
"""
def investor_structure():
sectors = {
"chips": "silicon that the model must run on",
"compute": "clusters that train the 14B model",
"smart devices": "phones / headsets that render the 4D assets",
"content platforms": "who buys rendered scenes and assets",
"advanced manufacturing": "factories / production lines to digitise",
}
state_funds = ["Shenzhen Capital Group (深创投)", "Zhejiang Venture Capital (浙创投)"]
print("Industry capital, by the bottleneck it unlocks:")
for sector, why in sectors.items():
print(f" {sector:<22} -> {why}")
print("\nState-backed funds:", ", ".join(state_funds))
print("\nRounds in 2026: 5")
print("Total raised: 2.0B CNY (~$280M)")
print("Valuation: ~10B CNY (~$1.4B)")
print("Next round: launched, possibly ~1B CNY")
print()
print("Note the pattern: five rounds in one year is not a growth story,")
print("it is a land-grab -- the window for 'national compute + world model'")
print("is being priced as if it closes soon.")
investor_structure()
Five rounds in one year is not a normal cadence. A healthy technology company raises every 12 to 18 months. Five rounds a year usually means one of two things: progress so fast valuation can’t keep up, or a sector window believed to be closing.
Reading it alongside the “Ascend-native” positioning, the latter seems likelier — the number of slots for “domestic compute + world model” is finite. Whoever binds their model tightly to the Ascend stack first lands earlier on the domestic-substitution procurement list. This is a land-grab, not a growth story.
Part Eight: Judgment and Boundaries
First, the real differentiation here isn’t “4D” — it’s the intersection of physical coupling and domestic compute. 4D world models have players worldwide, and on pure technical metrics MoWorld 2.0 may not lead. But “Ascend-native + inference cost at 30% of GPU + fully domestic training and deployment” is scarce inside China. On the domestic-substitution line, being able to run matters more than running fast. Because once compute supply is constrained, the one that runs is the only option.
Second, “70 fps” needs to be placed correctly. It isn’t render speed (that’s 500+ fps), it’s generation speed — one neural network pass per frame. 70 fps means 14.3 ms per frame. That’s enough for “interactive,” but not yet enough for “real-time closed-loop control” — real robot control loops typically demand 100 to 1,000 Hz. So MoWorld today suits training environments (offline, can be slow) better than online controllers (must be fast). That’s its capability boundary, and it’s also why it chose embodied AI training as its first scenario.
Third, the real value of 2,000 frames is as an “error exposure window.” At 70 fps, 2,000 frames is about 28.6 seconds. That length is enough for a demo, not enough to “train one complete manipulation workflow” — grasp, move, place, reset; a full episode usually takes minutes. So 2,000 frames is closer to “a stress-test length for physical consistency” than “a production-usable single generation length.” To actually produce embodied training data, long-horizon consistency and segment stitching remain unsolved.
Fourth, the partnership with three national AI application pilot bases is more worth tracking than the model itself. Embodied intelligence, cultural tourism, spatiotemporal geographic information — three completely different technical demands: embodied needs physical accuracy, cultural tourism needs visual appeal plus interactivity, spatiotemporal geo needs large scale plus geographic consistency. One model satisfying all three is nearly impossible. The likelier reality: MoWorld provides the base, and the three bases each do domain adaptation. What this partnership actually tests is whether a world model can become a platform — not how strong the model is.
Fifth, and most needing calm: there is no accepted benchmark for physical correctness. Video generation has FVD and CLIP score, but “is the physics reasonable” still has no authoritative benchmark. The official demo — breeze, pages, falling bookmark — is a carefully chosen scene, and in such scenes “looks right” and “computes right” are easily confused. To judge whether a world model truly learned physics, watch it in counter-intuitive scenarios: gravity at 0.1x, floor friction near zero, two bodies colliding inelastically. No public data on those tests yet.
A trackable framework: for any “world model” launch, ask six questions — ① does it output pixels or assets (is it reusable)? ② how far does it predict (frames/seconds, how does error accumulate)? ③ is physics learned or engine-computed (can you tune parameters)? ④ what do generation and rendering each cost (is real-time possible)? ⑤ what compute does it run on (is supply constrained)? ⑥ is there validation on counter-intuitive scenes (or only pretty demos)? Six questions and it becomes clear whether “world model” is a breakthrough or packaging.
Sources: World Internet Conference Wuzhen Summit Zhejiang sub-forum “Developing New Quality Productive Forces — the Strong Increment Lies in AI” (2026-11-04, Moxin Technology MoWorld 2.0 debut); Xinhua, “Zhejiang Sub-forum Debuts MoWorld 2.0, a Fully Domestic-Compute 4D World Model”; Zhejiang Online, “Moxin Technology Releases Ascend-Native 4D World Model MoWorld 2.0”; ITHome, “Moxin MoWorld 2.0: Ascend-Native, Inference Cost Down to 30% of GPU Solutions”; 36Kr, “A Post-2000s Zhejiang University PhD Student Builds World Models — Five Rounds in One Year, Valuation Near 10 Billion Yuan”; Pandaily, “Moxin Technology Unveils MoWorld 2.0, an Ascend-Native 4D World Model” (2026-11-04). The frame-budget conversions, inference cost model, asset lifecycle cost, investor supply-chain mapping, and cloud-device chain breakdown are inference and illustration based on public information, not official figures; the company has not published standardised physical-consistency benchmark results.