A Practical Guide to Load Testing Realtime AI Avatars for HR Screening at Scale
Load test realtime AI avatar sessions for HR screening: burst concurrency, WebRTC latency, turn timing, GPU bottlenecks, and SLOs.
Introduction
Load testing a realtime AI avatar system is not the same as load testing a typical HTTP API. You are not just measuring request rate and latency; you are exercising a streaming pipeline that includes WebRTC or similar transport, speech synthesis, LLM turn-taking, avatar rendering, and client playback. That means the failure modes are different too: session setup becomes a bottleneck, media negotiation can fail under concurrency, latency spikes can desync audio and video, and one noisy tenant can eat a disproportionate amount of GPU or bandwidth capacity.
This post is about testing that whole path in a way that is useful for production planning, especially for HR screening workloads where traffic is bursty, sessions are interactive, and the business cares about throughput, drop rate, and perceived responsiveness more than raw TPS. By the end, you should be able to design a load test that tells you:
how many concurrent avatar sessions your stack can sustain,
where the real bottlenecks are: signaling, media, synthesis, rendering, or downstream orchestration,
what latency and quality thresholds matter for a screening interview experience, and
how to automate regressions so capacity surprises show up in CI or pre-release tests instead of in production.
Start with the right workload model
The most common mistake is to benchmark only the API that creates a session. That tells you something, but not enough. A realtime avatar session has at least four phases:
Provisioning: authenticate, create avatar/session objects, allocate runtime resources.
Connection establishment: negotiate the realtime transport, join the media session, and begin receiving audio/video.
Interactive turn-taking: the user speaks, ASR or upstream transcript arrives, the agent responds, and the avatar speaks with lip-sync.
Steady-state streaming: audio/video and control messages continue with acceptable jitter and no desync.
For HR screening, the arrival pattern is usually not perfectly uniform. It is closer to a spike at the top of the hour, after a recruiter sends batch invites, or when a job posting goes live. So model:
burst concurrency rather than only average concurrency,
session duration distributions that match real interviews,
think time between turns, and
turn length that reflects the screening script.
If you only test with 30-second sessions and constant prompt cadence, you will miss the resource pattern of a 15-minute interview where a candidate pauses, asks clarifying questions, and occasionally forces the agent into longer completions.
Measure the metrics that actually matter
For a realtime avatar pipeline, you want both system metrics and experience metrics.
System metrics typically include:
session creation success rate,
time to first media,
time to first avatar frame,
media connect time,
error rate by stage,
CPU, memory, GPU, and network saturation,
queue depth or backpressure signals in your agent stack.
Experience metrics should be measured from the client side, not assumed from server logs:
time to first audible response after user speech,
audio/video sync drift,
frame drops or stutter,
reconnect frequency,
turn truncation or barge-in failures.
For HR screening specifically, the most important threshold is often the response gap after the candidate finishes speaking. Once that gap grows beyond a couple of seconds, the interaction starts to feel broken, even if everything is technically “up.”
Set concrete SLOs before testing. Example targets might be:
p95 session setup under 5 seconds,
p95 time to first response under 2.5 seconds,
<1% failed sessions at planned peak,
no sustained audio/video desync beyond a small tolerance.
The exact thresholds depend on your model stack and UX, but having them written down keeps the exercise honest.
Build a realistic load generator
You need a harness that can open many sessions, keep them alive, and drive representative turns. A common pattern is to use a small control plane service that coordinates workers, then have each worker simulate a candidate session.
At a minimum, the simulator should:
authenticate the same way your production client does,
create or join a session,
wait for the avatar to become live,
send scripted utterances or transcript events at realistic intervals,
record timing from client perspective, and
tear down cleanly so you can distinguish saturation from leaks.
If your avatar is attached to a voice agent, you should test the entire agent path, not just the avatar rendering path. That means synthetic users must exercise the same integration that real users do: speech input, agent response, and media playback. If your app uses a WebRTC-based realtime stack, your generator should behave like a browser or a lightweight media client, not like a blind HTTP poller.
Example: session creation and orchestration via API
When you want to stress provisioning and session lifecycle, use the REST API directly from a script or load-test worker. The exact request schema depends on the endpoint definitions in the docs, but the shape is predictable: create an avatar or session, receive an ID and connection metadata, then join from the client side.
In a load test, do not reuse one session across many simulated users unless the production product does the same. Session lifecycle is part of the system under test. You want to know whether creation rate, session cleanup, and per-session resource allocation remain stable under concurrency.
Test the interactive path, not just the handshake
The hardest bugs tend to appear after connection succeeds. Under load, the agent may still be “connected” while the first response arrives late, audio packets jitter, or the avatar frames fall behind the speech stream. That is why a useful harness needs turn-level instrumentation.
For each turn, capture:
candidate speech start/end,
time transcript is available to the agent,
time the first response token or audio chunk is emitted,
time the avatar begins visible speaking,
time the turn completes.
Those timestamps let you separate LLM latency from TTS latency from rendering latency. That distinction matters because scaling the wrong layer is a common, expensive mistake. For example, if your p95 spikes only when video rendering starts, adding more LLM capacity will not help.
Also test contention. HR screening traffic often produces synchronized spikes: dozens or hundreds of sessions start at once, then each session speaks in a similar pattern because the interview script is shared. That can create bursty downstream load on any component with per-turn work, including text generation, voice synthesis, and frame generation.
Practical failure modes and how to catch them
There are a few classes of issues that show up repeatedly:
Connection churn: session creation looks fine, but joins fail once concurrency rises. Usually signaling or auth limits.
Backpressure collapse: one slow subsystem causes queue growth and eventually timeouts. Watch queue depth and tail latency, not just averages.
Resource leaks: long-running tests show memory climb, stale media tracks, or unreleased sockets.
Quality degradation: sessions stay alive, but audio/video quality falls below acceptable levels. This is often the first sign of CPU/GPU exhaustion.
Retry storms: clients retry aggressively and make an overload condition worse. Make sure your simulator uses realistic retry behavior.
Run tests in stages: baseline, ramp, sustained peak, and failure boundary. A ramp finds the knee of the curve. A sustained peak tells you whether the system is stable after warm-up. A failure-boundary test tells you how gracefully degradation starts. All three are useful; none substitutes for the others.
Where Protoface fits in
For teams using Protoface as the avatar layer, the cleanest way to load test is to exercise the same surfaces you will use in production. If you are integrating a voice agent, the LiveKit plugin path is the one to test end-to-end; the plugin is available in the quickstart examples and via the Pipecat integration documented in the Pipecat guide. If you are orchestrating sessions yourself, use the REST API and the Python SDK to create repeatable provisioning tests, then layer a client-side media harness on top for turn timing.
That split is important. API-only tests tell you about control-plane capacity. Client-side tests tell you about realtime behavior. You need both if you are preparing for HR screening at scale, because the user-visible failures are rarely confined to one layer.
For example, a provisioning test might look like this in Python, using the SDK as a control-plane client:
Keep the exact field names aligned with the docs, but the testing pattern is the same: create many sessions, observe setup latency and failure rate, then feed those sessions from a realistic media client that behaves like your production app.
Conclusion
Load testing realtime AI avatars is mostly about testing the whole interaction loop under realistic concurrency, not just hammering an endpoint. For HR screening, that means modeling bursty starts, measuring turn-level latency, and watching for desync, backpressure, and cleanup issues as sessions accumulate. If you get the workload shape right, the results are actionable: you can identify the bottleneck layer, set defensible capacity targets, and avoid discovering the first real failure in front of a candidate.
If you are building on Protoface, start with the public docs at docs.protoface.com, then validate the integration path your app actually uses: REST for lifecycle, the Python SDK for orchestration, or the LiveKit plugin / Pipecat integration for agent-driven realtime media. Build the smallest harness that reproduces your production turn pattern, then scale it until the numbers stop being comfortable. That is usually where the real work begins.