I build a desktop app where you talk to a VRM avatar and it answers out loud. Someone told me the gap between speaking and hearing a reply was too long.

I measured it and fixed it. Then I found out my benchmark had been running on a machine with a full disk and a load average in the low hundreds, which made the number 4x worse than reality, and the design decision I derived from it was wrong for weeks without ever failing.

The conclusion first: the split point for streaming TTS follows from the real-time factor, and you should store the formula rather than the number it produces.

Seconds are the wrong unit

You cannot compare TTS engines by how long they took. Longer sentences take longer. What matters is the ratio against the length of the audio produced.