What happens to the server when a 3D world hosts a hundred AI characters?
AI agent server cost3D virtual world AI concurrencyAI character rendering costbrowser rendering vs server streamingvirtual world AI scalabilitydigital human bandwidthself-hosted 3D world performanceGenesis virtual world
When teams consider bringing AI into a 3D world, the same worry usually blocks them: can the server survive having many AI characters at once?
Behind that worry sits an assumption: an AI "appearing" in a 3D world means rendering it, streaming it, and therefore doubling cost as AI count doubles. In this architecture, the measured result is the opposite. This article covers three things: why the cost curve inverts, the measured numbers for one hundred agents in the same scene, and — just as important as the numbers — what those numbers do not cover.
One: the conclusion first
An AI in this world renders nothing. The server only forwards its coordinates, orientation, and spoken text; the 3D model is downloaded and drawn by each visitor's own browser.
So adding one AI does not add a video stream — it adds roughly 1 KB per second of JSON. One hundred agents in the same scene is about 0.8 Mbps of push traffic, at server load roughly equal to 1% of a single core. The real bottleneck is never "making it visible" — it is the large language model behind it, and how much that costs is decided by whichever model you choose.
Two: why the cost curve inverts
Common sense says the more an AI looks like a 3D character, the more it costs. Making a visible AI forces the question "where does the picture come from?":
| Approach | Mechanism | Where the load lands |
|---|---|---|
| Server-side rendering + video streaming | The AI's frame is rendered on the server, encoded, and streamed to every visitor | Server compute and bandwidth grow with both AI count and visitor count |
| Structured data, rendered client-side | The server only sends "where it is, where it faces, what it says"; each visitor's browser draws it from that data | The server does lightweight forwarding; AI consumes no rendering compute |
This system takes the second path. An AI is not a video feed — it is a character on a text channel: position data gets it drawn at the right coordinates, text lets it speak. More visitors means each browser draws one more model; on the server side, each AI stays around one kilobyte per second, always.
That is the mechanism behind "a visible AI costs less than an invisible one" — what you save is not rendering, but that rendering is delegated to the visitor browsers that were going to draw the whole world anyway.
Three: the measured numbers
These are measured values of the AI agent channel (acceptance scripts can be re-run):
| Metric | Measured value |
|---|---|
| Push traffic per agent | ~1 KB/s |
| Push traffic, 100 agents in one scene | ~0.8 Mbps |
| Server load | 0.19 core-seconds over 20 seconds, roughly 1% of one core |
| Human-side feel | Position lag under 3 meters, smooth interpolated movement |
| Movement speed cap | 1–20 m/s (server-authoritative, default 9, human-scale) |
| Idle exit | Leaves the world automatically after 5 minutes idle, releasing the slot |
| Sensing radius | Up to 200 m for Key identities; 30 m for guest identities |
Two design choices do the heavy lifting: movement is server-capped planar movement (no physics simulation), and the event stream has three levels (off / aggregated per second / per-event), selectable per business need.
Four: what the numbers do not cover
Listed honestly, so the measured values are not mistaken for total cost:
- LLM calls — what the AI says comes from the model you connect; that cost is independent of the agent channel and often dominates total cost;
- The world's own visitor load — asset downloads for human visitors, multi-user sync, voice — a separate ledger;
- Egress and storage — chat records land in your database and are archived daily;
- High-frequency scenarios — see the next section.
In one sentence: these numbers answer "what does it cost the server to keep one hundred AI characters present," not "what does your whole AI application cost."
Five: when the numbers grow
| Variable | Effect |
|---|---|
| Event stream set to per-event | Message frequency rises and push traffic rises with it; per-second aggregation is the middle ground |
| Speaking frequency | Text goes over the channel; high-frequency speech increases usage, but stays in the KB/s range |
| Concurrency cap | Set in the backend; excess connections are rejected — the cap defines the peak |
| Sensing radius tier | Guest identities are capped at 30 m, Key identities at 200 m; larger radius means more radar data returned |
All of these are knobs in the backend, not hidden costs.
Six: FAQ
Q: Has the hundred-agent scenario really been tested?
A: Yes. The numbers come from acceptance scripts (100 agents in one scene, moving and speaking continuously); the scripts are kept in the project and can be re-run. Note this tests the channel itself, not the load of LLM calls.
Q: What is a hundred AI characters actually for?
A: Directly, it is a capacity stress test; business uses (many points of interest, multi-character events) are up to whoever deploys. This article stands behind the capacity numbers, not any application scenario.
Q: Compared with streaming AI as video, is cost the only difference?
A: No. A text channel means the AI's behavior is structured and auditable — every command has a receipt and can be revoked. In a video-streaming approach, those governance points hide behind the picture.
Q: Do visitors notice anything?
A: Their browser downloads and draws one more character model, which is normal world-content overhead; the AI's behavior data (~1 KB/s) adds no meaningful burden on visitor devices.
Seven: Source and repositories
The three addresses have identical content; the first two are faster for visitors in mainland China. The repositories include deployment guides and a demo entry.
- Gitee (faster in mainland China): https://gitee.com/miduoxinxijeji/miduo.git
- GitCode (mirror): https://gitcode.com/qq_35054471/virtual-world
- GitHub: https://github.com/miduo100/3d-virtual-world
About Genesis
Genesis is a self-hosted 3D virtual world system built on Three.js + WebGL, helping individuals and businesses build their own 3D spaces. Accessible directly from a browser, compatible with both PC and mobile, it supports multiplayer online, federated teleportation, a shop system, and Agent integration—where an AI can enter your world as an embodied character. Your data runs on your own server, never passing through a third-party platform—so every world truly belongs to its owner.
Want to scale AI in your own world without paying a rendering bill for making it visible? Genesis (创世虚拟世界CRM系统) is a Three.js 3D virtual world foundation that deploys on your own servers — AI consumes no rendering compute, runs at about 1 KB/s per agent, and the numbers are reproducible. The official site (search for 创世虚拟世界CRM) has a demo world you can walk around in.
About the name: Genesis in this article refers to 创世虚拟世界CRM系统 — the same self-hostable 3D virtual world product. If searching "Genesis" doesn't find us, search for 「创世虚拟世界CRM」.