Sixteen vCPUs cap one GPU pod at four concurrent 3D avatars
A team measuring its own unmanned avatar streamer got four per pod at ¥7,600 each a month, with the GPU loafing at 26 percent. The same run turned up hosts that died every 60 seconds off an identical image.
The Engineer · Build desk
What happened
- A pass required four avatars to run for 89 seconds and every output file to measure 89 seconds, which they did, with screen capture verified at 33fps.
- Some hosts running the identical image crashed every 60 seconds, so the system now switches automatically to a different host.
- Time from pod boot to streaming start fell from four minutes to 95 seconds, which is what made automatic host switching usable mid-schedule.
Why it matters
- What it limits constraint The per-avatar price is really a per-vCPU price of roughly 4 vCPU each, so anyone shopping by GPU tier is optimising the axis that had headroom to spare.
- What it costs cost The largest lever on the bill is the calendar, not the hardware: scheduling down to eight hours a day takes the same avatar from ¥7,600 to ¥2,500 a month.
- Who's exposed exposure Anyone validating a render farm on frame rate can bill for segments that ended early, because this failure mode removes time from the file and leaves the FPS chart green.
- Who has to decide decision If the encoder is what consumes vCPU, NVENC support moves ahead of raw GPU tier in the procurement checklist for this workload.
The pass criterion is worth copying. A rendering failure in this pipeline skips time rather than stuttering: the team reports a 90-second animation that came out as a 6-second file while the FPS logs looked fine [4]. So the test asserts duration on the artefact rather than throughput in the logs [3]. The window is also well chosen for a second reason. Eighty-nine seconds is longer than the 60-second cadence on which the bad hosts died [11], which means a host-level defect surfaces inside one capacity run instead of in a live segment [19].
Packing four avatars onto one box came down to a filename. The renderer sent page audio to ffmpeg through /tmp/audio.fifo, the second avatar on the host grabbed the same pipe, and the audio interfered; the fix was to make the path unique per port, /tmp/audio-<port>.fifo [7]. The author's list of the same class of hazard is short and correct: temporary files, fixed ports, lock files, cache directories [8]. Multi-tenancy here was a naming convention.
At four avatars the card reported 26 percent utilisation, and the team names the 16 vCPUs as the resource that ran out [5], because the GPU only does rendering while the rest of the streaming pipeline sits on the CPU [6]. Scale that GPU figure linearly and the card alone would carry about fifteen avatars [23]. You are actually buying the pod, not the accelerator.
For ¥7,600 to transfer to your rig, a specific set of conditions has to hold: a pod at $0.28 an hour with 720 hours billed [9], 16 vCPU sitting behind that card [5], capture at 33fps [3], and bandwidth included in the pod price [14]. Change the vCPU-to-GPU ratio and the divisor moves. The author's own scheduling figure survives a re-check: eight hours a day is 240 hours, which at $0.28 is $67.20, or ¥2,520 per avatar across four at ¥150 to the dollar, matching the ¥2,500 quoted [20].
Bandwidth is the line most likely to break the comparison. At 2.5Mbps a stream moves roughly 27GB a day, and a cloud charging about $0.09/GB adds around ¥360 a day or ¥10,000 a month, where GPU-specialised clouds often bundle it [14]. If that 2.5Mbps describes one avatar, egress on a metered cloud costs about 1.3 times the ¥7,600 of compute underneath it [18]. The source does not say whether the bitrate is per avatar or per host, and that is worth resolving before anyone quotes either figure.
All of this is one team's self-reported measurement of its own workload, published in Japanese and reposted to dev.to [16]. The method is the transferable part. Renting a GPU for a few hours costs a few hundred yen [15], which buys a number where an estimate would have been free and wrong.
What to watch
- Whether an NVENC build raises the count above four on the same 16 vCPU pod, and by how much.
- Whether the hosts that crashed on a 60-second cadence ever get diagnosed, or whether failover remains the permanent answer.
- A published version of the same test on a pod with a different vCPU-per-GPU ratio, which would show whether 4 vCPU per avatar holds.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence46
- Adoption14
- Hype gap+12
- Incentives55
- Confidence52
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The system boots a cloud GPU pod at the scheduled start time, the renderer assembles and streams the video, and the pod is discarded when the segment ends, with no human oversight.
- [2]
The measured answer to how many avatars run on a single GPU is 4, at a monthly cost of ¥7,600 per avatar, and the bottleneck was not the GPU.
- [3]
The success criterion was to run N avatars simultaneously for 89 seconds and require all output files to have an actual length of 89 seconds; with 4 avatars all files were 89 seconds of 89 seconds, and screen capture rate was verified at 33fps.
- [4]
When rendering fails the pipeline does not stutter but skips time; the team saw a 90-second animation record only 6 seconds while the FPS logs looked fine and the output was truncated.
- [5]
Running 4 avatars resulted in 26% GPU usage, meaning the GPU had more than triple the capacity; the bottleneck was the CPU (16 vCPU).
- [6]
The GPU only handles rendering, while the rest of the streaming pipeline relies on the CPU.
- [7]
The renderer originally sent audio from the page to ffmpeg via a named pipe at /tmp/audio.fifo; sharing that path across processes broke host sharing because the second avatar grabbed the same pipe and caused audio interference, so the path was made unique per port as /tmp/audio-<port>.fifo.
- [8]
Shared resources such as temporary files, fixed ports, lock files and cache directories become issues when sharing hosts, and identifying them beforehand makes measurement smoother.
- [9]
The cost calculation given is $0.28/hour x 720 hours/month = $201.6/month per GPU, and $201.6 divided by 4 avatars = $50.4 per avatar, about ¥7,600 at ¥150/USD.
- [10]
At 24/7 operation the cost is ¥7,600 per avatar, but with 8 hours daily it is ¥2,500 per avatar, a threefold difference; the team treats this as a scheduling problem.
- [11]
Despite using the same image, some hosts crashed every 60 seconds, and the team implemented a mechanism to switch automatically to a different host.
- [12]
Time from pod startup to streaming start was reduced from 4 minutes to 95 seconds.
- [13]
Faster startup enabled practical host switching, and understanding capacity allowed the team to set prices.
- [14]
Streaming at 2.5Mbps uses about 27GB/day; clouds with egress fees of about $0.09/GB add roughly ¥360/day or ¥10,000/month, while GPU-specialised clouds often include bandwidth, creating a cost gap.
- [15]
Renting a GPU for a few hours costs only a few hundred yen, so the questions were measured rather than estimated.
- [16]
The account was originally published in Japanese at forge.workstyle.tech and reposted on dev.to.
- [17]
At the measured ceiling each avatar consumes about 4 vCPU of the pod's 16.
- [18]
On a metered cloud, ¥10,000/month of egress for a 2.5Mbps stream is about 1.3 times the ¥7,600/month of compute per avatar.
- [19]
The 89-second test window is longer than the 60-second interval at which the failing hosts crashed, so that failure class appears within a single capacity run.
- [20]
Eight hours a day is 240 billed hours a month, which at $0.28/hour is $67.20, or ¥2,520 per avatar across four at ¥150/USD, consistent with the ¥2,500 figure given.
- [21]
Cutting startup from 4 minutes to 95 seconds removes 145 seconds, a reduction of about 60 percent.
- [22]
The author suggests a hardware encoder (NVENC) would free up CPU resources and potentially increase the number of avatars, and that NVENC availability should be a criterion when choosing a GPU.
- [23]
If GPU load scaled linearly with avatar count, 26% for four implies the card alone could carry about 15 avatars.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toHow Many AI Avatars Can One GPU Handle? Real-World Test Reveals 4 Avatars at ¥7,600 Each per Month
1 article · August 29, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.