Adventists AI unveils Sophon voice model with a claimed 0.31-second response time

You call a voice assistant and start correcting an address, but it keeps reading out its previous response. For the user, that means several frustrating seconds. For the product team, it is a reason to check whether the system can listen while speaking. Adventists AI has unveiled the open Sophon-Realtime-v1 with precisely this capability: users can interrupt the assistant and continue the conversation. For the faster Flash version, its creators claim a time to first audio of 0.31 seconds.

This has practical appeal for support teams, voice interface developers and founders of services using phone bots. But it is too early to choose a model based on a single latency figure: first, teams need to understand what happens during pauses, clarifications and errors.

How the assistant decides when to speak

Sophon supports full-duplex operation: it listens and speaks simultaneously. The family is built around a 32-billion-parameter model. According to the developers, it distinguishes between a completed turn, continuing speech, a brief reaction from the other person and a pause for thought. It prepares a draft response in advance; if the person continues speaking, the system discards it.

Consider a delivery order. The customer says: "Deliver it tomorrow... hmm, better make that the day after tomorrow." When testing an assistant like this, it is important to check that it waits for the correction and confirms the right day. If the bot has already started responding and the customer adds "after six," the conversation should incorporate that clarification too. This is an example of a test scenario, not a confirmed result from Sophon.

The creators also claim that DuplexJev enables recognition of intonation, laughter, sighs and sarcasm. For a product team, that calls for separate tests of ambiguous phrases. "Well, great" can express either customer satisfaction or irritation. However, the ability to identify tone does not, by itself, prove that the assistant will choose the correct next action.

Three versions with different trade-offs

The Tag variant focuses on expressiveness: the model annotates the response, and a separate speech module produces laughter, sighs and emphasis. Flash uses faster speech synthesis. The third version, E2E, has been released as a preview for experiments with speech generation within the shared architecture.

The source material lists approximately 0.6 seconds to first audio and 16 concurrent users for Tag, versus 0.31 seconds and 40 users for Flash. An important clarification from the project repository: the creators measured latency and load on an H100 with 80 GB of memory. These figures cannot automatically be applied to any GPU with that amount of memory.

The choice between versions should depend on the task. Expressiveness may be useful for a character or a conversation practice tool. For a short call to check an order's status, it is more important to test speed, intelligibility and whether actions are performed correctly. An assistant's laughter does not make up for an incorrect address.

What to test before integrating it into a product

Start with a small set of your own conversations: a person interrupts the bot, takes a long time to think, changes their mind or speaks over background noise. You also need separate tests for your audience's languages and accents. The reported results do not support any conclusion about the quality of Russian speech.

Measure the time from the end of the user's turn to the first audio, how quickly the bot stops when interrupted, and the proportion of conversations in which it correctly retains a clarification. Test this under the expected load. Fast initial audio is of little help if the response subsequently stalls or the system loses context after the user intervenes.

Scenarios involving actions require another set of checks: whether the assistant calls tools correctly and confirms the result. The 48% Pass@1 reported in the material for the tool-calling test does not justify entrusting it with operations without verification. It makes sense to start by testing status retrieval and action preparation, then assess more complex scenarios.

Sophon deserves consideration as a candidate for a voice service prototype. A deployment decision should be based on your conversation recordings, operating costs and the number of tasks successfully completed. The comparisons published by its creators can help shape a test program; you will need to verify readiness for customer use yourself.