The Evolution and Timeline of Full-Duplex Large Voice Models

_

1. Background: Why an AI Model Release Timeline Matters

The iteration speed in the AI field is exceptionally fast, with new models and architectural paradigms emerging almost continuously. For developers and technical decision-makers, relying on fragmented news feeds can easily lead to an “information overload without clear context” dilemma. A continuously maintained model release timeline is essentially a structured archive of technological evolution, providing value in four key areas:

1. Basis for Technology Selection: A timeline clearly shows when specific capabilities (e.g., voice conversation, multimodal understanding) achieved breakthroughs, helping teams assess the current development stage and avoid adopting outdated solutions.
2. Team Knowledge Consolidation: Archiving scattered release information allows new members to quickly build a comprehensive understanding of the domain.
3. Evolution Trend Prediction: Comparing multiple timelines (voice, vision, reasoning) often reveals signals of capability convergence, such as the turning point of voice models shifting from “turn-based dialogue” to “full-duplex.”
4. Reducing Information Lag Risk: In latency-sensitive scenarios like real-time interaction, being half a year late to adopt a new architecture could result in a generational gap in product experience.

Taking voice interaction as an example, recent representative voice models generally adopt a full-duplex architecture—continuously processing input while generating speech to achieve a natural “listen while speaking” conversation experience. These release events are exactly the “paradigm-level nodes” most worth marking on a timeline.

2. Methodology for Building a High-Value Timeline

A usable timeline is not just a news list; it should contain searchable, comparable structured fields. It is recommended to maintain it using the following methods:

1. Source Control: Prioritize official technical reports, papers, and developer documentation to avoid distortion from secondhand sources. Mark unverified information as “To Be Confirmed.”
2. Standardized Field Design: Each record should contain at least the release date, model category, core capabilities, architectural features, access methods, and applicable scenarios.
3. Fixed Update Mechanism: Assign a dedicated owner for regular reviews, combined with automated aggregation tools to reduce maintenance costs.

An illustrative record structure is as follows:

{
  "release_date": "2026-07-08",
  "category": "Large Voice Model",
  "capability": "Real-time voice conversation",
  "architecture": "Full-duplex streaming architecture",
  "access_type": "API / Open Weights",
  "notes": "Supports listening while speaking, suitable for real-time interaction scenarios"
}

3. The Three Stages of Voice Interaction Paradigm Evolution

Looking back from a timeline perspective, voice conversation technology has generally gone through three stages:

Stage 1: Cascaded Pipeline. The classic three-stage structure of “ASR (Speech Recognition) -> NLU (Natural Language Understanding) -> TTS (Text-to-Speech).” The advantage is modularity, allowing independent optimization of each component; the disadvantages are cumulative errors, high overall latency, and the massive loss of paralinguistic information (such as tone and emotion) during text conversion.

Stage 2: End-to-End Voice Models. The model directly uses audio as input and output, eliminating the intermediate text conversion step. This significantly reduces latency and preserves the speaker’s emotion and prosody. However, most models in this stage remain “half-duplex”—you speak, then I speak—with turn-switching relying on explicit pause detection.

Stage 3: Full-Duplex Architecture. The model continuously listens to and processes input while generating speech, just like in human conversations where you can be interrupted at any time and adjust your response instantly. Recent representative voice models marking this stage allow machine conversations to approach the state of natural human communication for the first time.

4. Core Mechanics of the Full-Duplex Architecture

The essence of full-duplex is transforming “listening” and “speaking” from mutually exclusive operations into parallel pipelines. Its technical loop relies on four key components:

1. Streaming Audio Encoding: Input audio is continuously fed into the encoder in small chunks, rather than waiting for the entire sentence to finish.
2. Incremental Generation: Speech synthesis outputs in a streaming manner, generating and playing simultaneously, compressing the Time to First Audio (TTFA) to the chunk level.
3. Real-time Interruption Detection: While playing, the input stream is continuously analyzed. Once a user’s intent to take over is recognized, playback is immediately and smoothly terminated.
4. Dual-Channel State Machine: The session state switches at a high frequency between “listening,” “speaking,” and “overlap,” requiring fine-grained state management to ensure context is not lost.

A conceptual processing loop is as follows:

while session.active:
    chunk = mic_stream.read()              # Continuously capture input audio
    state.update(listen_buffer=chunk)      # Streaming recognition and semantic understanding sync
    if state.interrupt_detected():         # User interruption detected
        tts.stop_gracefully()              # Smoothly stop playback, preserving expressed semantics
        state.switch_to_listening()
    if state.ready_to_speak():
        for piece in model.stream_generate(context):
            speaker.play(piece)            # Generate and play simultaneously
            # The listening channel remains online and is not interrupted by playback

5. Four Major Technical Challenges in Full-Duplex Implementation

1. Interruption and Semantic Integrity: When interrupted, the model should neither “ramble on” nor “stop at the slightest sound” mistakenly triggering on filler words. It needs to combine semantic confidence to decide when to stop and properly bridge to the subsequent response.
2. Echo and Self-Listening: The model must distinguish between user voice, environmental noise, and its own playback sound, otherwise it easily falls into “self-talk.” This usually requires integration with front-end signal processing like Acoustic Echo Cancellation (AEC).
3. Latency Budget Management: End-to-end latency must be broken down across capture, encoding, inference, synthesis, and playback. Jitter in any stage will be directly perceived by the user.
4. Multi-speaker Overlap: Real-world scenarios may involve multiple people speaking simultaneously, requiring speaker diarization and role attribution, which remains an open challenge.

6. Engineering Evaluation Dimensions and Integration Practices

When evaluating full-duplex voice capabilities, it is recommended to focus on the following metrics: Time to First Audio (TTFA), interruption response time, semantic understanding accuracy, voice naturalness (using subjective MOS scores), and state stability over long conversations. On the engineering side, developers can build pipelines based on general cloud service categories, such as ASR, TTS, real-time audio/video communication, message queues, logging services, and monitoring/alerting. Cloud platforms like Baidu AI Cloud provide services covering these general categories. Developers can first use a small-scale prototype to validate the interaction experience, then gradually scale to production traffic, avoiding a full-scale overhaul from the very beginning.

7. Conclusion and Future Outlook

The emergence of full-duplex architecture marks the transition of voice interaction from “turn-based response” to “natural conversation.” It is foreseeable that the next phase of evolution will revolve around multimodal fusion (voice and visual coordination), emotional and paralinguistic understanding, and edge-cloud collaborative inference. For developers, continuously maintaining a structured model release timeline is not only the best tool for tracking these changes but also a long-term accumulation of the team’s technical judgment. It is recommended to start building such a “living document” for your team today, making every significant model release an opportunity for technical review.