Loading today’s stories
Build1 distinct publisher3 min readPublished
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
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
An H100's MIG slices hand Chromium's WebGL straight back to the CPU rasteriser1 distinct publisher
build
Every viewer hits your HLS key endpoint in the same second, and almost nobody tests it1 distinct publisher
build
Five coding agents on one repo is a staffing problem, and worktrees only fix the filesystem1 distinct publisher
build
Two timeout numbers, not new code, fixed a nightly job that failed 2-3 mornings a week1 distinct publisher
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 [12], which means a host-level defect surfaces inside one capacity run instead of in a live segment [4].
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 [8]. The author's list of the same class of hazard is short and correct: temporary files, fixed ports, lock files, cache directories [9]. 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 [2]. 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 [10], 16 vCPU sitting behind that card [5], capture at 33fps [3], and bandwidth included in the pod price [15]. 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 [7].
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 [15]. If that 2.5Mbps describes one avatar, egress on a metered cloud costs about 1.3 times the ¥7,600 of compute underneath it [3]. 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 [17]. The method is the transferable part. Renting a GPU for a few hours costs a few hundred yen [16], which buys a number where an estimate would have been free and wrong.
Ranked by verification strength, evidence, and original report placement.
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.
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.
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.
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.
Running 4 avatars resulted in 26% GPU usage, meaning the GPU had more than triple the capacity; the bottleneck was the CPU (16 vCPU).
The GPU only handles rendering, while the rest of the streaming pipeline relies on the CPU.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Auditable arithmetic, unreproducible run
The costs check out on paper — $0.28 × 720 ÷ 4 really is about ¥7,600 at ¥150 to the dollar, and 240 billed hours really does land near ¥2,500 — and the pass condition (file duration equals wall time) is a stricter test than most concurrency write-ups bother with. What is absent is everything needed to run it again: no provider, no GPU model, no renderer version, no logs behind the 90-second clip that recorded six seconds. And the text dev.to published stops mid-sentence before the second component of the host-switching fix, so the reliability design is described only halfway.
One team, one pod
Everything observed here happens inside a single team's own pipeline. Four avatars, 95-second starts and the per-port fifo fix are all in production for the people who wrote them up, and nobody else appears in the story as a user, customer or replicator. The 16 vCPU ceiling has been reported once, by the party that measured it.
A vCPU finding sold as a GPU answer
The framing asks how many avatars one GPU can handle and answers four. The body says the opposite: the GPU idled at 26 percent and 16 vCPUs ran out. Change the instance shape or add a hardware encoder and the answer moves, which the piece itself concedes. That is the whole of the overstatement — otherwise this reporting understates rather than inflates, volunteering the truncated recordings, the minute-by-minute crashes and the egress bill that can outrun compute.
The seller doing its own pricing math
The team states outright that knowing capacity is what let it set prices, and mentions choosing its in-house inference platform over external TTS and LLM APIs — so the numbers that set a price are published by the party charging it. Against that, this reads like an engineering post-mortem rather than a pitch: no product name is pushed, no benchmark is cherry-picked against a rival, and the failures are described in more detail than the wins.
Believable, unverified, half-finished
I would trust the direction of this without trusting the digits. A CPU-bound media pipeline behind an idle GPU is an ordinary result, the arithmetic is self-consistent, and the specificity — 26 percent, 33fps, 89 of 89 seconds, /tmp/audio-<port>.fifo — is the kind that comes from a terminal rather than a marketing draft. But it is one team, one unnamed pod, one publication, and the reliability half of the story is cut off before it finishes.