📝 Originally published (in Japanese) at forge.workstyle.tech.
Building an Unmanned System for 3D Avatar Live Streaming We're developing an unmanned system where 3D avatars automatically handle live streaming.
The system boots up a cloud GPU pod at the scheduled start time, the renderer assembles and streams the video, and then the pod is discarded when the segment ends.
Since there's no human oversight, three factors directly impact the success of the business and service quality: "how many avatars can run simultaneously," "how the system recovers from failures," and "how quickly it starts up." These questions couldn't be answered through estimates alone.
Renting a GPU for a few hours costs only a few hundred yen.
In this article, we'll share three stories of how we measured and designed the system, following the structure of "stumbling block → cause → solution." Capacity: How many avatars can run on a single GPU?
The answer is 4, at a monthly cost of ¥7,600 per avatar.
However, the bottleneck wasn't the GPU.
Reliability: Despite using the same image, some hosts crashed every 60 seconds.
We implemented a mechanism to automatically switch to a different host.
Startup Speed: Reduced the time from pod startup to streaming start from 4 minutes to 95 seconds.
These three aspects seem independent but are actually interconnected.
Faster startup enabled practical host switching, and understanding capacity allowed us to set prices.
Let's dive into each one.
1.
How Many Avatars Can Run on a Single GPU? - Measured Result: 4 The first number we desperately needed was "how many avatars can run on a single GPU." Without this, we couldn't determine pricing, and without pricing, we couldn't assess the business viability.
Estimates were useless, so we measured it.
Here are the results: Item Measured Value GPU RTX 4000 Ada (Community type, $0.28/hour) Simultaneous Streams 4 avatars maintaining 720p30 in real-time (Recorded segment: 89 seconds / 89 seconds) GPU Usage 26% Bottleneck CPU (16 vCPU side saturated first) Estimated Upper Limit 5–6 avatars And the pricing: Operation Mode Monthly Cost per Avatar 24/7 Streaming Approximately ¥7,600 8-hour Daily Schedule Approximately ¥2,500 Judging Success by "Actual Segment Length," Not FPS A common mistake in measuring simultaneous execution is focusing solely on FPS.
For streaming, this is insufficient.
You need to check if the recorded segment length matches the actual time.
The reason is simple: when rendering fails, the pipeline doesn't "stutter" but skips time.
We experienced a case where a 90-second animation recorded only 6 seconds.
The FPS logs looked fine, but the output was truncated.
So, we set the success criteria as: With 4 avatars, all files were 89 seconds / 89 seconds.
This confirmed that "4 avatars can run simultaneously." We also verified that the screen capture rate was 33fps.
Surprisingly, the GPU Was Underutilized Running 4 avatars resulted in 26% GPU usage.
This means the GPU had more than triple the capacity.
The bottleneck was the CPU (16 vCPU).
The breakdown explains why: Process Uses 3D Scene Rendering GPU Frame Extraction CPU / Transfer H.264 Encoding CPU (if software encoding) Audio Mixing and Muxing CPU RTMP Streaming CPU / Network The GPU only handles rendering, while the rest of the streaming pipeline relies on the CPU.
Assuming "we're renting a GPU" leads to focusing on GPU specs, but the actual limiting factor was the number of vCPUs.
This observation suggests another improvement: using a hardware encoder (NVENC) would free up CPU resources, potentially increasing the number of avatars.
When choosing a GPU, "NVENC availability" should be a criterion.
Implementation Notes for Sharing Hosts When packing multiple avatars into one host, we made one implementation change.
The renderer originally sent audio from the page to ffmpeg via a named pipe (fifo).
If this path is shared across processes, host sharing fails.
The second avatar would grab the same pipe, causing audio in