Hacker News new | ask | show | jobs
by AaronFriel 704 days ago
I'm impressed by the latency using a request response. It looks this uses speech detection locally using Silero voice activity detector model using the ONNX web runtime, collects audio, then performs a POST. It doesn't look like the POST is submitted though until I'm done speaking. The response depends on chaining together several AI APIs that themselves are very, very fast to provide a seamless experience.

This is very good. But this is, unfortunately, still bound by the dominant paradigm of web APIs. The speech to text model doesn't get its first byte until I'm done talking, the LLM doesn't get its first byte until the speech to text model is done transcribing, and the speech to text model doesn't get its first byte until the LLM call is complete.

When all of these things are very fast, it can be very seamless, but each of these contributes to a floor of latency that makes it hard to get to lifelike conversation. Most of these models should be capable of streaming prefill - if not decode (for the transformer like models) - but inference servers are targeting the lowest common denominator on the web: a synchronous POST.

When only 3 very fast models are involved, that's great. But this only compounds when trying to combine these with agentic systems, tool calling.

The sooner we adopt end-to-end, bidirectional streaming for AI, the sooner we'll reach more lifelike, friendly, low latency experiences. After all, inter-speaker gaps in person to person conversations are often in the sub-100ms range and between friends, can even be negative! We won't have real "agents" until models can interrupt one another and talk over each other. Otherwise these latencies compound to a pretty miserable experience.

Relatedly, Guillermo - I've contributed PRs to reduce the latency of tool calling APIs to the AI SDK and Websockets to Next.js. Let's break free of request-response and remove the floor on latency.

1 comments

I totally agree, but how, though? All these architectures work with an input-output model. What we would need for what you describe would be more akin to living organisms, some sort of AI that is actually coupled to the environment (however that is defined for them) rather than receiving inputs and giving outputs. A complex, allostatic kind of multimodality than a simplistic sequential one. I don't think there is anything like that, at least not in the timescales that make sense for any use. And my belief is that the computational demands would be too high to approach with the current methods.
In autoregressive models we can "feed forward" the model by injecting additional tokens. Computing the KV cache entries for those tokens (called"prefill"), then resuming decoding. If we can do this quickly, and on the same node that has a hot KV cache (or otherwise low latency access to shared KV cache), we are quite a ways closer to offering a full duplex, or at least near zero latency, language model API. This does require a full duplex connection (i.e.: Websocket).

For true full duplex communication, including interruption, it will be more challenging but should be possible with current model architectures. The model may need to be able to emit no-op or "pause" tokens or be used as the VAD, and positional encoding of tokens might need to be replaced or augmented with time and participant.

I imagine the first language model which has "awkward pauses" is only a year or so away.

Maybe there’s something I don’t understand, but it seems to me that it would just be a streaming-next-token input instead of a batch input.