MiniMax T2A v2 vs Azure Neural TTS, Benchmarked: 6–10× Latency Gap on the Same Text

In my Sun Tzu at Work video factory, TTS is the least glamorous stage on the pipeline and the one most likely to stall the whole line. One episode synthesizes a dozen-plus Chinese and English narration segments; if each one takes several seconds, the npm run bingfa tts step stretches into a coffee break.

The factory wires up two providers: MiniMax T2A v2 (in-China api.minimaxi.com) and Azure Neural TTS (Microsoft eastasia region). Switching between them flips a single TTS_PROVIDER env var, and both outputs are normalized to 24kHz / mono / 16bit WAV, so the downstream Remotion compositor can't tell them apart. After using both for a while, my gut said MiniMax was clearly faster — but I'd never measured how much faster, or whether the slow one was the model or the network. This time I pinned it down.

The bottom line first: on my mainland-direct machine, MiniMax's median latency is 1.0–2.2s, 5–12× faster than real time; Azure's median is 6–21s, barely keeping up with real time, with a long tail that jitters to 27s. That's not "a bit faster" — it's an order of magnitude. But half the gap is the network's fault, which I'll prove with a packet capture below.

Background: TTS latency isn't voodoo — it sets the pipeline's rhythm

The video factory is batch processing, not real-time conversation, so strictly speaking first-packet latency isn't a hard requirement for me — I don't need to play while synthesizing. What actually blocks me is the wall-clock time for the full audio to return: a dozen narration segments synthesized serially, each 5s slower, adds up to over a minute of dead waiting.

Worse is variance. If latency were stable I could plan around it; but if this segment takes 3s and the next takes 27s, there's no sane way to set retry logic and timeout thresholds — set them short and you kill slow-but-valid requests, set them long and a hang never surfaces. So this benchmark records min/max alongside the median, specifically watching the long tail.

The two APIs also differ in call shape, worth stating up front: for MiniMax T2A v2 I use the non-streaming synchronous endpoint (/v1/t2a_v2, one request returns the whole hex PCM); Azure uses REST one-shot synthesis (SSML in, riff-24khz-16bit-mono-pcm out). Both are "one request, full audio back," so the measurement is apples-to-apples.

Analysis: latency is two segments, and they need separate attribution

The wall-clock latency of one synthesis call is, roughly, the sum of two parts:

1. Server-side synthesis time — how long the model takes to turn text into a waveform. This is set by the model and its inference stack, independent of where you are.
2. Network round-trip + transfer — the time the request and audio spend in transit. This scales strongly with the physical distance from your machine to the server.

If you only measure total latency, MiniMax being fast tells you nothing about why — is the model fast, or just close? And the two attributions point to opposite conclusions: if the model is fast, moving to an overseas server won't rescue Azure; if it's purely network, deploying next to Azure's region erases the gap. So I measured total latency and network RTT separately — total latency as the median over 5 rounds, network isolated via curl's connect/TLS handshake timing.

Approach: how I scoped the comparison

The classic way this kind of "provider vs provider" test goes wrong is mismatched units — different sample rates, channels, or bit depths make the resulting byte counts and audio quality meaningless. So I kept the scope tight:

• Reuse the production TTS abstraction (src/lib/bingfa/tts.ts), no bespoke test-only call code. At that layer both providers are already normalized to 24kHz / mono / 16bit PCM — identical output format is the precondition for comparability.
• Same corpus: two Chinese and two English passages, short + long, drawn from The Art of War (which happens to match the factory's real narration style). Chinese counted by non-whitespace characters, English by words.
• 5 rounds per case, median to resist jitter, min/max kept to watch the tail.
• Fixed voices: MiniMax uses the factory default speech-02-turbo; Azure uses zh-CN-YunxiNeural (Chinese) and en-US-GuyNeural (English) — the voices the factory actually ships.
• Explicitly excluding subjective audio-quality scoring (out of scope). Quality is subjective; one person's score has no statistical meaning. I only objectively record whether the format aligns (both 24kHz/mono/16bit) and waveform shape. I logged byte counts but do not treat them as a quality metric — WAV is uncompressed fixed-rate; byte count is proportional to duration only, unrelated to how good it sounds. Anyone using it as an audio-quality proxy is wrong.
• Pricing is qualitative only (out of scope). MiniMax's in-China billing has been revised several times and splits into per-token and per-character regimes; without an authoritative current rate I won't assert a number, only the order of magnitude I can confirm.

The run

Main event: a latency matrix over 40 synthesis calls

The test script directly imports the production synthesize(), switches backends via the TTS_PROVIDER env var, times full-audio return with performance.now() each round, and persists round-1 WAVs as evidence. How to run it:

npx tsx --env-file=.env tmp/2026-09-05-tts-bench/bench.ts   # 4 cases × 5 rounds × 2 providers

The raw matrix (lat.med/min/max are the median/fastest/slowest of 5 rounds; RTF = synthesis wall-clock ÷ audio duration; below 1 means faster than real time):

Two things jump out:

• MiniMax is faster than real time across the board. RTF lands at 0.08–0.18 — synthesizing 20s of audio takes 1.6s, i.e. 5–12× faster than "read as it plays." And all four cases have tight min/max spreads (e.g. en-long 1466–1892ms). Stable.
• Azure's RTF hugs 1.0 — synthesizing 20s of audio takes roughly 20s, about the pace of reading it aloud once. The long tail is more striking: zh-long's five rounds ranged from 3.3s (fastest) to 27.6s (slowest), and en-short jittered from 5.5s to 13.2s. That variance is a disaster for a pipeline.

Attribution: carving out the network segment with curl

Is Azure slow because of the model or the trans-Pacific network? I hit each endpoint once with curl, looking only at TCP connect and TLS handshake time — pure network, no synthesis:

The result is clear: MiniMax handshake connect ~0.04s, TLS ~0.13s (in-China); Azure connect ~0.13s, TLS jittering 0.25–0.82s (trans-Pacific). Just establishing the connection, Azure is already hundreds of milliseconds slower and jitters hard. That explains part of Azure's tail — but note, the network is a few hundred ms to one second in magnitude, nowhere near enough to account for a 21s median. So the primary cause is still Azure Neural's own near-real-time synthesis pace (RTF≈1); the network is a jitter amplifier layered on top. Both effects are real, but the model is the dominant term and the network is the tail term.

Cross-check: waveforms align, so it's not "short audio vs long audio"

Comparing latency is only fair if both providers' audio is genuinely the same length and format — otherwise it's apples to oranges. I overlaid the output waveforms of the same Chinese sentence from both:

Same sentence: MiniMax outputs 5.5s, Azure 6.0s — close in duration, similar envelope, identical sample rate/channels/bit depth. This confirms the latency comparison above is fair — neither provider quietly synthesized shorter audio to game the numbers.

What it means for my pipeline

Spread the median over a real scenario: a dozen narration segments synthesized serially. MiniMax produces all the audio in roughly ten to twenty seconds total; the same volume on Azure takes two to three minutes minimum for synthesis alone, up to five minutes when the tail hits. For a batch pipeline, that's the difference between "wait a moment after you hit enter" and "hit enter and go do something else."

So the factory's default TTS_PROVIDER has always been MiniMax, and this benchmark upgrades that default from "feels right" to "backed by data."

That doesn't mean Azure is worthless — its value lives in two dimensions I didn't measure here:

• Voice matrix. Azure Neural's multilingual, multi-voice coverage is industrial-grade, and the stability of voices like YunxiNeural plus fine SSML control (pauses, rate, emotion) is beyond what MiniMax offers today. When you need a specific voice texture, you eat the latency.
• Billing and compliance. Azure standard Neural TTS is $16 per 1M characters, with the first 500k characters/month free (official pricing; my volume stays within the free tier long-term, so cost is effectively zero). MiniMax's in-China billing has been revised several times this year and splits into per-token and per-character regimes; without an authoritative current rate I only give the confirmable order of magnitude — at my usage neither provider's cost is a deciding factor. The real watershed is latency and voice, not money.

One-line pick: batch, speed-sensitive, ordinary corpus → MiniMax; specific voice texture or enterprise compliance → swallow the latency and take Azure. My pipeline is the former, so the default picks itself.

Gotchas

• Don't use WAV byte count as an audio-quality metric. I initially put a KB column in the table and, seeing MiniMax and Azure land at similar byte counts, almost wrote "quality is comparable" — wrong. WAV is uncompressed fixed-rate PCM; byte count = sample rate × bit depth × channels × duration, entirely unrelated to how good it sounds, and it's guaranteed to be close when both formats match. I dropped the KB column and replaced it with RTF, the dimension that actually means something.
• Single-shot latency is meaningless, especially for Azure. Had I run one round, I might have drawn Azure's 3.3s sample and concluded "Azure isn't slow either." Its variance is large enough that you must take the median over multiple rounds — zh-long's fastest and slowest differed by 8×. Any TTS eval that "runs once and concludes" is untrustworthy.
• Attribution can't rely on total latency alone. Network and synthesis are two different things inside total latency. Without carving out RTT, you blur "Azure's model runs near real time" and "trans-Pacific network jitters" into a fuzzy "Azure is slow," and then make the wrong optimization call (e.g. assuming a region change fixes it, when it can't touch the dominant term).
• The test environment must match production to be valid. These numbers were measured on mainland-China home broadband, direct connect — which is exactly the video factory's real deployment (running on a Mac mini in China). If your service already lives in the same region as Azure, the trans-Pacific penalty vanishes, Azure's tail converges, and the conclusion needs re-measuring. Don't lift my numbers straight into your data center.