Realtime Voice AI Agents 2026 - Kiến trúc Speech-to-Speech Multi-Agent với LiveKit, Pipecat, gpt-realtime, Deepgram, Cartesia, Redis và ClickHouse

Posted on: 4/15/2026 7:31:07 AM

Nếu bạn đã từng gọi tổng đài một ngân hàng và nghe thấy "Xin chào, em có thể giúp gì cho anh ạ?" với giọng tự nhiên như một nhân viên thật, rất có khả năng bạn vừa nói chuyện với một voice AI agent. Năm 2026, giọng nói không còn là một tính năng phụ trên đỉnh stack chat — nó là một kênh giao tiếp chính, có đặc tả riêng, có latency budget riêng, và có một bộ framework, mô hình, hạ tầng riêng không dùng chung với text chat. Bài viết này đi sâu vào kiến trúc thực sự của một realtime voice AI agent ở quy mô sản xuất: cascaded pipeline versus speech-to-speech, WebRTC versus WebSocket, voice activity detection, turn-taking, barge-in, STT/TTS/LLM stack, LiveKit versus Pipecat, Redis cho session state, ClickHouse cho telemetry, và cách multi-agent dàn nhạc khi tất cả các actor đều nói cùng một ngôn ngữ: âm thanh.

1. Vì sao voice agent là một bài toán riêng

Với text chat, người dùng sẵn lòng chờ 3-5 giây trước khi token đầu tiên xuất hiện. Với voice, ngưỡng đó là 800 mili-giây tính từ lúc người nói xong câu cho đến lúc agent bắt đầu nói trở lại. Nếu bạn vượt quá ngưỡng này, con người — một sinh vật đã tiến hoá để phối hợp turn-taking qua hàng trăm nghìn năm — sẽ cảm thấy "ngắt quãng", "robot", "không an tâm". Các đội Cerebrium, Hamming AI và Daily đã cùng công bố benchmark cho thấy khi voice-to-voice vượt 1.500 ms, tỷ lệ bỏ cuộc gọi tăng gấp đôi; khi xuống dưới 700 ms, chỉ số hài lòng người dùng gần bằng tổng đài viên con người. Nói cách khác, voice agent không phải là "chat có âm thanh" — nó là một hệ thống real-time có ngân sách độ trễ khắc nghiệt gấp 5 đến 10 lần chat thông thường.

Thêm vào đó, voice mang theo một chồng bài toán mà text không bao giờ gặp: voice activity detection (khi nào người bắt đầu và kết thúc nói), turn-taking (ai tới lượt), barge-in (xử lý khi người dùng cắt ngang agent), prosody (ngữ điệu của câu trả lời), echo cancellation (không nghe chính mình nói), noise suppression (loại bỏ tiếng ồn nền), jitter buffer (chống giật mạng), và packet loss concealment (lấp trống khi UDP rơi gói). Mỗi bài toán đều có giải pháp riêng trong thế giới WebRTC, nhưng khi ghép với một LLM thì toàn bộ thiết kế phải được cân lại vì LLM chạy chậm hơn codec âm thanh 100 lần.

Và cuối cùng, khi bước vào multi-agent, chuyện trở nên thú vị thêm: bạn có một agent nhân viên đặt lịch, một agent tra cứu đơn hàng, một agent xử lý khiếu nại. Ai sẽ cầm micro? Chuyển giao giữa họ ra sao khi người gọi vẫn còn đang nói dở câu? Giọng của họ có giống nhau hay khác nhau? Đây không phải câu hỏi khoa học viễn tưởng nữa — các đội LiveKit, Pipecat, Plivo và Amazon Bedrock đã xuất bản pattern cho những kịch bản này từ cuối 2025.

2. Hai họ kiến trúc: cascaded pipeline versus speech-to-speech

Mọi voice agent 2026 đều thuộc một trong hai họ kiến trúc rõ ràng. Việc chọn đúng họ ngay từ đầu quyết định hầu hết các đánh đổi phía sau: chi phí, độ trễ, khả năng debug, khả năng tuỳ biến, và khả năng phát triển tính năng.

Nhìn bảng trên, có cảm giác speech-to-speech thắng về UX và latency. Nhưng thực tế sản xuất 2026 vẫn nghiêng mạnh về cascaded vì ba lý do rất thực dụng. Thứ nhất, compliance. Ngân hàng, y tế, bảo hiểm bắt buộc phải có transcript — một đoạn văn bản ký tên được, lưu được, tra được — và cascaded cho họ transcript miễn phí ở bước STT. Speech-to-speech phải chạy thêm một bước transcription song song chỉ để sinh log. Thứ hai, debug. Khi một cuộc gọi đi sai, bạn cần biết "agent đã nghĩ gì?". Với cascaded, câu trả lời nằm ở transcript STT và response text của LLM. Với speech-to-speech, bạn chỉ có audio và một tensor embedding — rất khó điều tra một incident sản xuất. Thứ ba, linh hoạt. Nếu TTS vendor hiện tại tăng giá, bạn đổi sang vendor khác trong 30 phút. Nếu OpenAI tăng giá gpt-realtime, bạn không có đường lui dễ dàng.

3. Giải phẫu chi tiết cascaded pipeline

Một cascaded voice agent sản xuất 2026 có năm tầng, mỗi tầng có độ trễ và lỗi đặc trưng riêng. Biểu đồ dưới mô tả luồng hoàn chỉnh cho một turn hội thoại từ lúc người dùng mở miệng đến lúc nghe được âm thanh phản hồi.

sequenceDiagram
    participant U as User (mic)
    participant V as VAD
    participant S as STT (Deepgram Nova-3)
    participant L as LLM (Claude Sonnet 4.6)
    participant T as TTS (Cartesia Sonic 3)
    participant P as Playout (speaker)
    U->>V: PCM 20ms chunks
    V->>V: Detect speech start (10-30ms)
    V->>S: Forward audio frames
    S-->>V: Partial transcript (200-400ms)
    V->>V: Detect end-of-turn (300-500ms)
    V->>L: Final transcript + context
    L-->>T: Text delta (300-500ms TTFT)
    T-->>P: Audio chunk (40-100ms TTFA)
    P->>U: Speaker output

Cộng năm con số latency: 30 + 400 + 500 + 500 + 100 ≈ 1530 ms cho một implementation ngây thơ. Để chạm đích 800 ms, mỗi tầng phải được tối ưu và phải chồng chéo thời gian bằng kỹ thuật streaming. Một số điểm chìa khoá:

• STT streaming, không batch. Deepgram Nova-3 phát ra partial transcript từ chunk âm thanh đầu tiên và cập nhật liên tục. Bạn bắt đầu đẩy tokens vào LLM ngay khi end-of-turn còn chưa xác nhận, dùng transcript dự đoán. Khi end-of-turn xác nhận, bạn có thể commit hoặc rollback request LLM.
• LLM streaming. Bắt đầu gửi tokens tới TTS từ token đầu tiên, không chờ cả câu. TTS modern như Cartesia Sonic nhận input dạng stream và phát âm thanh ngay khi đủ ngữ cảnh (thường là một cụm từ).
• Pre-warm connection. Kết nối WebSocket đến STT và TTS phải đã mở sẵn khi cuộc gọi bắt đầu — không bao giờ mở kết nối mới giữa turn.
• Single-region routing. Tất cả các service (STT, LLM, TTS) phải ở cùng một region với SFU (LiveKit/Daily). Chênh lệch region là thủ phạm ẩn của 200-400 ms tail latency.

4. WebRTC, WebSocket, SIP — lựa chọn giao thức đúng

Ở tầng mạng, voice agent có ba lớp kết nối khác nhau mà thường bị gộp chung thành "streaming". Ta phải phân biệt rõ:

• Người dùng ↔ SFU (hoặc agent). Đây là chặng khó nhất vì mạng người dùng không đáng tin: có thể 4G ở hầm, có thể WiFi công cộng, có thể đang di chuyển. Lựa chọn hợp lý: WebRTC qua UDP với STUN/TURN fallback. WebRTC có packet loss concealment, jitter buffer, DTLS encryption, và có thể bỏ gói không quan trọng — tất cả miễn phí.
• SFU ↔ LLM gateway. Đây là chặng data center đến data center, mạng ổn định, TLS đã sẵn. WebSocket hoặc gRPC streaming đơn giản hơn nhiều so với WebRTC và đủ nhanh.
• PSTN (điện thoại truyền thống) ↔ SFU. Đây là chặng bắt buộc với call center: SIP là tiêu chuẩn không thể tránh. LiveKit SIP bridge, Twilio Media Streams, Plivo, Vonage đều cung cấp.

Một quyết định kiến trúc then chốt: nên dùng SFU hay mesh? Mesh (mỗi peer kết nối trực tiếp) không phù hợp khi một phía là agent chạy trong cluster — bạn không muốn mỗi pod agent phải đàm phán ICE với từng người dùng. SFU (Selective Forwarding Unit) đóng vai trò trung gian, người dùng chỉ kết nối tới SFU, agent cũng kết nối tới SFU, và SFU route media giữa hai phía. LiveKit viết bằng Go là SFU mã nguồn mở phổ biến nhất 2026 cho voice agent use case.

5. VAD, turn detection, và nghệ thuật biết khi nào đến lượt

Với một con người, turn-taking đến một cách vô thức: chúng ta đọc hơi thở, ngữ điệu xuống, sự chậm lại cuối câu, ánh mắt. Với một voice agent, bạn phải thiết kế lại tất cả tín hiệu đó từ đầu. Ba khái niệm phải không bao giờ nhầm lẫn:

• Voice Activity Detection (VAD). Phát hiện "có ai đang nói không?" trong 10-50 ms. Silero VAD, WebRTC VAD, Pipecat Smart Turn VAD đều là lựa chọn tốt. VAD quá nhạy cắt đầu câu; quá ì cho tiếng ồn đi vào STT.
• Turn detection. Phát hiện "người dùng đã nói xong chưa?" — khác VAD ở chỗ im lặng 300 ms chưa chắc là nói xong (đang suy nghĩ), còn có khi chưa im lặng cũng là xong ("Tôi muốn đặt bàn, ờm... cho ba người ạ"). Turn detection tốt kết hợp VAD, prosody (pitch drop), và context ngữ nghĩa từ transcript tạm.
• End-of-utterance (EOU). Một mô hình học máy nhận âm thanh và transcript để dự đoán xác suất "người này đã kết thúc lượt nói". LiveKit phát hành mô hình turn detection V2 dùng Transformer audio + text vào 2025, cho ra F1 cao hơn VAD thuần 18%.

Trong thực tế 2026, pattern được dùng phổ biến là "VAD + hysteresis + EOU": VAD chạy liên tục, khi im lặng đạt 200 ms thì bắt đầu chấm điểm EOU, nếu EOU vượt ngưỡng thì commit end-of-turn, ngược lại tiếp tục chờ đến 800 ms tối đa. Config tốt cho câu chuyện tiếng Việt thường đặt ngưỡng hysteresis dài hơn tiếng Anh vì người Việt hay chèn "ờ", "à" ở giữa câu.

from pipecat.audio.vad.silero import SileroVADAnalyzer
from pipecat.transcriptions.language import Language

vad = SileroVADAnalyzer(
    sample_rate=16000,
    start_secs=0.05,          # 50 ms tín hiệu đầu tiên đã coi là bắt đầu nói
    stop_secs=0.6,            # 600 ms im lặng mới coi là kết thúc
    min_volume=0.6,           # lọc tiếng ồn nền
    confidence=0.7,           # ngưỡng Silero cho speech probability
)

turn_analyzer = LocalSmartTurnAnalyzer(
    params=SmartTurnParams(
        stop_secs=0.4,        # bắt đầu chấm điểm khi im lặng 400 ms
        pre_speech_ms=120,    # nhìn lại 120 ms trước im lặng
        max_duration_secs=8.0 # hard cut sau 8 giây
    )
)

Hai giá trị stop_secs khác nhau là có chủ đích: VAD commit nhanh hơn để bắt đầu gửi tín hiệu tới EOU analyzer, và EOU analyzer mới là nơi quyết định cuối cùng. Đây là kỹ thuật "two-stage silence" mà Daily và LiveKit đều khuyến nghị từ giữa 2025.

6. Barge-in — khi người dùng cắt lời agent

Barge-in là tình huống người dùng nói chen ngang khi agent đang phát âm thanh. Nếu xử lý sai, bạn có một agent "cãi khách hàng" hoặc một agent chết lặng nửa chừng. Xử lý barge-in phải trả lời ba câu hỏi đồng thời:

1. Đây có thật sự là barge-in không? Hay chỉ là "ừ", "vâng ạ" — gọi là backchannel. Nếu mỗi backchannel đều bị tính là barge-in, agent sẽ ngừng nói mỗi 2 giây và hội thoại gãy.
2. Phải dừng TTS nhanh bao nhiêu? Lý tưởng là dưới 100 ms tính từ lúc VAD phát hiện speech. Nếu chậm hơn, người dùng cảm thấy agent "điếc".
3. State LLM hiện tại phải làm gì? Cancel request đang chạy? Đánh dấu message "đã nói tới đâu"? Rollback hay commit?

LiveKit đã công bố adaptive interruption handling cuối 2025 với một mô hình audio phụ chạy song song VAD: khi VAD phát hiện speech, audio 300 ms đầu được gửi cho mô hình này để phân loại thành "true barge-in" hay "backchannel". Theo số liệu LiveKit, mô hình này loại bỏ 51% barge-in giả và bắt 64% barge-in thật nhanh hơn VAD thuần. Cerebrium và Daily cũng có cách tiếp cận tương tự với mô hình nhẹ hơn chạy trên GPU cạnh SFU.

stateDiagram-v2
    [*] --> Listening
    Listening --> Thinking: end_of_turn
    Thinking --> Speaking: llm_first_token
    Speaking --> BargeInCheck: vad_speech_detected
    BargeInCheck --> Speaking: classified_as_backchannel
    BargeInCheck --> Interrupted: classified_as_barge_in
    Interrupted --> Listening: tts_cancelled + pipeline_flushed
    Speaking --> Listening: tts_complete
    Thinking --> Listening: llm_error

Khi chuyển trạng thái Interrupted, hệ thống phải làm 4 việc trong dưới 100 ms: (1) cancel upstream LLM request qua abort signal, (2) flush queue audio chờ gửi đến user, (3) gửi speech.interrupted event tới conductor để rollback trạng thái phiên, (4) reset TTS session pool để lần nói kế sạch state. Bỏ sót bất kỳ bước nào đều để lại âm thanh "còn dư" hoặc state kẹt trong lần tiếp theo.

7. STT — chọn mô hình nghe

STT là tầng có biến động công nghệ mạnh nhất 2025-2026. Bốn mô hình đứng đầu hầu hết benchmark voice agent:

Cho production voice agent tiếng Việt 2026, lựa chọn mặc định là Deepgram Nova-3 vì họ đã bổ sung tiếng Việt vào cuối 2025 với WER dưới 10% cho giọng miền Bắc và miền Nam, và có interim results (partial transcripts) rất ổn định. Nếu bạn cần tự host vì lý do data residency, Whisper Large v3 Turbo chạy trên vLLM hoặc faster-whisper với CUDA là phương án khả thi nhưng đắt hơn về vận hành 3-5 lần.

8. TTS — chọn giọng nói

TTS 2026 đã vượt qua "uncanny valley" — người nghe không phân biệt được giọng AI và giọng người trong các test blind với câu ngắn. Cuộc đua hiện tại là về latency và emotion control. Ba nhà dẫn đầu cho voice agent real-time:

Với tiếng Việt, Cartesia và ElevenLabs đều đã phát hành giọng native chất lượng production từ cuối 2025. Cartesia Sonic 3 đặc biệt mạnh ở các câu có tông hỏi — cao độ đi lên đúng ngữ điệu tiếng Việt thay vì "đọc máy". Nếu bạn đang xây một sản phẩm cho người Việt, hãy thử blind test với 10-15 người trước khi khoá vendor, vì cảm nhận chất lượng giọng khác biệt rất lớn giữa tai người và benchmark WER.

9. LiveKit — SFU WebRTC cho voice agent

LiveKit là dự án mã nguồn mở SFU viết bằng Go, ra đời 2021 cho video conferencing, nhưng từ 2024 đã được rewrite để trở thành hạ tầng voice agent hàng đầu 2026. Ý tưởng cốt lõi: voice agent là một participant headless trong một room WebRTC. Người dùng join room, agent join room, SFU route media giữa họ. Không có khái niệm client-server — chỉ có peer-to-peer qua SFU.

graph TB
    subgraph "Client"
        Browser["Browser
WebRTC"]
        Mobile["Mobile App
LiveKit SDK"]
        Phone["PSTN Phone
SIP Gateway"]
    end
    subgraph "LiveKit Cloud"
        SFU["LiveKit SFU
Go, Pion"]
        SIP["LiveKit SIP Bridge
RTP ↔ WebRTC"]
        Room["Room State
Redis"]
    end
    subgraph "Agent Worker"
        Agent["Python Agent
livekit-agents"]
        STT["Deepgram Nova-3"]
        LLM["Claude Sonnet 4.6"]
        TTS["Cartesia Sonic 3"]
    end
    Browser --> SFU
    Mobile --> SFU
    Phone --> SIP
    SIP --> SFU
    SFU --> Room
    SFU <--> Agent
    Agent --> STT
    Agent --> LLM
    Agent --> TTS
    style SFU fill:#e94560,stroke:#fff,color:#fff
    style Agent fill:#0f3460,stroke:#fff,color:#fff
    style Room fill:#dc3545,stroke:#fff,color:#fff

Agent worker là một Python process chạy livekit-agents framework. Mỗi khi có một room mới được tạo (người dùng gọi đến), LiveKit dispatcher sẽ assign một agent worker còn trống vào room đó. Agent nhận tham chiếu Room object, subscribe audio track của người dùng, và publish audio track của chính nó. Chuyện "kết nối WebRTC" hoàn toàn transparent — bạn viết như viết một chương trình xử lý stream bình thường.

from livekit import agents
from livekit.agents import Agent, AgentSession, RoomInputOptions
from livekit.plugins import deepgram, anthropic, cartesia, silero

async def entrypoint(ctx: agents.JobContext):
    await ctx.connect()

    session = AgentSession(
        vad=silero.VAD.load(),
        stt=deepgram.STT(model="nova-3", language="vi"),
        llm=anthropic.LLM(model="claude-sonnet-4-6"),
        tts=cartesia.TTS(model="sonic-3", voice_id="vi-female-natural"),
        turn_detection="multilingual",
    )

    agent = Agent(
        instructions=(
            "Bạn là trợ lý đặt bàn của nhà hàng Sen Xanh. "
            "Luôn trả lời ngắn gọn, tối đa 2 câu. "
            "Nếu khách yêu cầu món ăn không có, lịch sự gợi ý món thay thế."
        ),
        tools=[search_reservation, create_reservation, cancel_reservation],
    )

    await session.start(
        room=ctx.room,
        agent=agent,
        room_input_options=RoomInputOptions(
            noise_cancellation=noise_cancellation.BVC(),
        ),
    )

    await session.generate_reply(
        instructions="Chào khách hàng và hỏi họ muốn đặt bàn cho mấy người, thời gian nào."
    )

if __name__ == "__main__":
    agents.cli.run_app(agents.WorkerOptions(entrypoint_fnc=entrypoint))

Điểm đáng chú ý: framework tự xử lý VAD, turn detection, barge-in, interim transcripts, và interruption recovery. Bạn chỉ cần mô tả chính sách và cung cấp tools. Khi agent đang nói và VAD phát hiện user, framework tự cancel TTS và dispatch lại transcription. Khi tool call được dispatch, framework tự inject status message ("Đang tra cứu...") để lấp trống tâm lý trong lúc LLM chờ.

10. Pipecat — frames pipeline linh hoạt

Pipecat được Daily phát hành 2024 với triết lý khác LiveKit: thay vì một framework "đóng" có sẵn state machine, Pipecat cho bạn một pipeline of frames — giống Unix pipe — trong đó mỗi processor xử lý một loại Frame cụ thể (AudioFrame, TextFrame, UserStartedSpeakingFrame) và forward các frame khác cho bước tiếp theo. Đây là model rất quen với kỹ sư backend vì nó chỉ là stream processing.

graph LR
    Transport["DailyTransport
audio in/out"] --> VAD["VADAnalyzer"]
    VAD --> STT["DeepgramSTTService"]
    STT --> LLM["AnthropicLLMService"]
    LLM --> TTS["CartesiaTTSService"]
    TTS --> Transport
    LLM -.-> RAG["QdrantRetrieval
Processor"]
    RAG -.-> LLM
    LLM -.-> Tools["FunctionCalls
Processor"]
    Tools -.-> LLM
    style Transport fill:#4CAF50,stroke:#fff,color:#fff
    style LLM fill:#e94560,stroke:#fff,color:#fff

Ưu thế của Pipecat: bạn có thể chen bất kỳ processor tuỳ biến nào vào bất kỳ vị trí nào trong pipeline. Cần kiểm tra PII trước khi gửi tới LLM? Chen một processor. Cần lưu audio raw xuống S3 cho QA? Chen một processor. Cần switching dynamic giữa hai LLM? Chen một processor routing. LiveKit rất mạnh nhưng ít khả năng tuỳ biến theo kiểu này.

from pipecat.pipeline.pipeline import Pipeline
from pipecat.pipeline.runner import PipelineRunner
from pipecat.pipeline.task import PipelineTask
from pipecat.services.deepgram import DeepgramSTTService
from pipecat.services.anthropic import AnthropicLLMService
from pipecat.services.cartesia import CartesiaTTSService
from pipecat.transports.services.daily import DailyTransport
from pipecat.processors.aggregators.llm_response import LLMUserResponseAggregator

transport = DailyTransport(room_url, token, "Voice Agent", DailyParams(
    audio_out_enabled=True,
    audio_in_enabled=True,
    vad_enabled=True,
    vad_analyzer=SileroVADAnalyzer(),
))

stt = DeepgramSTTService(api_key=DEEPGRAM_API_KEY, model="nova-3", language="vi")
llm = AnthropicLLMService(api_key=ANTHROPIC_API_KEY, model="claude-sonnet-4-6")
tts = CartesiaTTSService(api_key=CARTESIA_API_KEY, voice_id="vi-female-natural")

pipeline = Pipeline([
    transport.input(),
    stt,
    LLMUserResponseAggregator(),
    llm,
    tts,
    transport.output(),
])

task = PipelineTask(pipeline, PipelineParams(allow_interruptions=True))
runner = PipelineRunner()
await runner.run(task)

Sự khác biệt triết học: LiveKit là "agent joining a room", Pipecat là "data flowing through a pipe". Nếu bạn đã quen với stream processing (Kafka Streams, Flink, Go channels), Pipecat sẽ trực quan hơn. Nếu bạn đang xây một call center cần SIP + dispatch queue + multi-participant, LiveKit có tooling đầy đủ hơn.

11. OpenAI Realtime API và cuộc chơi speech-to-speech

Khi OpenAI phát hành gpt-realtime và công bố GA cho Realtime API vào tháng 8 năm 2025, cuộc chơi voice agent thay đổi một bước quan trọng: lần đầu tiên có một mô hình đa modal nhận audio vào và trả audio ra trong một lần forward pass duy nhất. Không có STT, không có TTS, không có text trung gian. Chỉ có audio.

sequenceDiagram
    participant C as Client (WebRTC)
    participant R as Realtime API
    participant T as Tool (MCP)
    C->>R: audio_buffer.append (PCM16)
    C->>R: input_audio_buffer.commit
    R-->>C: response.audio.delta (voice)
    R-->>C: response.audio_transcript.delta (text)
    R-->>T: response.function_call (MCP tool)
    T-->>R: function_call_output
    R-->>C: response.audio.delta (final)
    R-->>C: response.done

Điểm khác biệt thú vị: Realtime API không chỉ là một mô hình, mà là một session protocol stateful. Bạn mở một WebSocket hoặc WebRTC connection, gửi audio buffer liên tục, và nhận audio + event stream ngược lại. Session có nhớ ngữ cảnh hội thoại trong vùng context window của nó, nên bạn không cần gửi lại lịch sử mỗi lần. Điểm yếu: session chỉ sống trong memory của một data center, nếu bạn cần multi-region hay reconnect cross-region thì phải tự xây lớp persistence bên ngoài.

Từ cuối 2025, Realtime API hỗ trợ:

• SIP calling. Bạn có thể chỉ định một số điện thoại, API sẽ thực hiện outbound call qua Twilio/Vonage và agent sẽ nói chuyện với người nghe.
• MCP server integration. Agent có thể gọi bất kỳ MCP tool nào từ remote server — tra cứu knowledge base, gọi API nội bộ, truy vấn database. Không cần viết adapter riêng.
• Image input. Có thể đẩy ảnh (chụp màn hình, biểu đồ) vào session cùng với audio. Agent có thể mô tả những gì nó "thấy" trong khi đang hội thoại.
• Function calling chính xác hơn. Version gpt-realtime (tháng 8 năm 2025) cải thiện instruction following và tool calling lên mức gần với text-mode GPT-4.1.

12. Redis — session state và short-term memory

Mỗi cuộc gọi voice agent là một session có state: danh tính người gọi, context conversation, tool state trung gian, biến trạng thái máy. State này phải có độ trễ dưới 1 ms cho read/write vì nó nằm trên đường găng của mỗi turn. Đây chính xác là miền mạnh của Redis.

Pattern Redis được dùng phổ biến nhất cho voice agent 2026:

• Session key theo room_id lưu metadata cuộc gọi: người gọi, tenant, language preference, RBAC claims. TTL 2-4 giờ.
• Conversation history theo room_id lưu danh sách messages dạng Redis List hoặc Stream. Dùng để truyền vào LLM mỗi turn. Có thể nén dạng JSON + zstd khi history dài.
• Tool call state theo room_id lưu pending function call, kết quả trung gian, tránh trùng lặp khi barge-in xảy ra giữa tool call.
• Lock theo phone_number tránh một số điện thoại mở hai phiên song song, bằng SET NX EX 7200.
• Rate limit theo tenant dùng token bucket với Redis Lua script — một trong những use case "cổ điển" mà Redis giải quyết xuất sắc.
• Pub/Sub cho conductor events khi có nhiều agent worker cùng listen vào một room và cần coordinate transfer.

import redis.asyncio as redis
import json, time

r = redis.Redis()

class VoiceSessionStore:
    async def start(self, room_id: str, metadata: dict):
        key = f"voice:{room_id}"
        await r.hset(key, mapping={
            "started_at": time.time(),
            "caller": metadata["caller"],
            "tenant": metadata["tenant"],
            "lang": metadata.get("lang", "vi"),
        })
        await r.expire(key, 7200)

    async def append_turn(self, room_id: str, role: str, text: str):
        key = f"voice:{room_id}:history"
        entry = json.dumps({"role": role, "text": text, "ts": time.time()})
        await r.rpush(key, entry)
        await r.ltrim(key, -40, -1)  # giữ tối đa 40 lượt gần nhất
        await r.expire(key, 7200)

    async def load_context(self, room_id: str, max_turns: int = 20):
        key = f"voice:{room_id}:history"
        raw = await r.lrange(key, -max_turns, -1)
        return [json.loads(x) for x in raw]

    async def set_pending_tool(self, room_id: str, call_id: str, state: dict):
        key = f"voice:{room_id}:tools:{call_id}"
        await r.set(key, json.dumps(state), ex=300)

Với Redis 8 và Redis Cluster, một cluster 3 node đủ phục vụ 50.000 cuộc gọi song song mà vẫn giữ latency p99 dưới 2 ms cho tất cả các thao tác trên. Chi phí hạ tầng cho lớp session là một phần nhỏ so với chi phí LLM/STT/TTS, nên đây là nơi bạn nên "chi mạnh" để không bao giờ phải nghĩ về latency session.

13. ClickHouse — voice analytics và telemetry

Sau mỗi cuộc gọi, bạn cần trả lời được các câu hỏi: TTFT trung bình turn bao nhiêu? Bao nhiêu turn bị barge-in? Có bao nhiêu tool call fail? Chi phí cuộc gọi là bao nhiêu? Giọng nào của TTS có tỷ lệ khách hàng bỏ cuộc cao nhất? Các câu hỏi này đòi hỏi một kho event có thể scan hàng trăm triệu record trong giây, group theo nhiều chiều, và giữ chi phí lưu trữ thấp. Đây là bài toán ClickHouse giải quyết tự nhiên nhất.

CREATE TABLE voice_events (
    event_time DateTime64(3),
    room_id String,
    tenant String,
    caller String,
    event_type LowCardinality(String),
    turn_id UInt32,
    latency_ms UInt32,
    stt_partial_ms UInt32,
    stt_final_ms UInt32,
    llm_ttft_ms UInt32,
    tts_ttfa_ms UInt32,
    barge_in UInt8,
    tool_name LowCardinality(String),
    tool_latency_ms UInt32,
    audio_duration_ms UInt32,
    input_tokens UInt32,
    output_tokens UInt32,
    cost_usd Float32,
    metadata String CODEC(ZSTD(6))
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)
ORDER BY (tenant, event_time, room_id)
TTL event_time + INTERVAL 90 DAY;

Mỗi turn hội thoại sinh ra 5-8 event (turn_started, stt_partial, stt_final, llm_first_token, llm_done, tts_first_audio, tts_done, turn_ended). Một cuộc gọi 5 phút trung bình có 20 turn, tức 100-160 event. Với 50.000 cuộc gọi mỗi giờ, bạn nhận 5-8 triệu event/giờ. ClickHouse MergeTree ngốn con số này không đổ mồ hôi: insert rate trên một node modern có thể đạt 500.000 row/s, và partition theo tháng cho phép dọn dữ liệu cũ đơn giản bằng DROP PARTITION.

Từ dữ liệu này, các query realtime cực nhanh:

-- TTFT p50 / p95 theo tenant trong 1 giờ qua
SELECT tenant,
       quantile(0.5)(llm_ttft_ms) AS p50,
       quantile(0.95)(llm_ttft_ms) AS p95,
       count() AS turns
FROM voice_events
WHERE event_type = 'llm_first_token'
  AND event_time > now() - INTERVAL 1 HOUR
GROUP BY tenant
ORDER BY p95 DESC;

-- Tỷ lệ barge-in theo agent
SELECT tenant,
       sum(barge_in) / count() * 100 AS barge_rate,
       count() AS total_turns
FROM voice_events
WHERE event_type = 'turn_ended'
  AND event_time > now() - INTERVAL 1 DAY
GROUP BY tenant
HAVING total_turns > 100
ORDER BY barge_rate DESC;

-- Chi phí theo tool và thời gian
SELECT tool_name,
       toStartOfHour(event_time) AS hour,
       sum(cost_usd) AS total_cost,
       count() AS calls
FROM voice_events
WHERE event_type = 'tool_done'
  AND event_time > today()
GROUP BY tool_name, hour
ORDER BY total_cost DESC;

Các câu query này chạy trong vài trăm mili-giây trên billions of rows. ClickHouse đã sáp nhập Langfuse vào tháng 1 năm 2026, biến stack này trở thành "nền tảng observability chuẩn" cho LLM và voice agent — Langfuse chính là client UI, ClickHouse là storage engine bên dưới.

14. Multi-agent voice — chuyển giao giữa các agent

Giả sử sản phẩm của bạn có ba agent chuyên môn: đặt bàn, tra cứu menu, và xử lý khiếu nại. Khi khách hàng gọi đến, hệ thống không biết họ sẽ hỏi gì. Câu trả lời thông thường: có một receptionist agent đón đầu, phân loại yêu cầu, và chuyển giao cho agent chuyên môn phù hợp. Nhưng "chuyển giao" trong voice không giống chuyển giao trong chat — nó có ba yêu cầu khó đồng thời:

1. Không làm gián đoạn luồng âm thanh. Khách hàng không được nghe "đang chuyển cuộc gọi" hay silence 2 giây.
2. Duy trì context. Agent thứ hai phải biết khách hàng đã nói gì với agent đầu, không bắt họ nhắc lại.
3. Giữ giọng hoặc đổi giọng rõ ràng. Nếu hai agent cùng dùng một giọng, người nghe không phân biệt. Nếu khác giọng, phải có transition "tôi sẽ chuyển anh sang đồng nghiệp chuyên về mục này".

graph TB
    Caller["Khách hàng
đang nói"] --> SFU["LiveKit SFU"]
    SFU --> Rec["Receptionist
Claude Sonnet 4.6"]
    Rec -->|intent: đặt bàn| A1["Agent A
Reservation"]
    Rec -->|intent: menu| A2["Agent B
Menu QA"]
    Rec -->|intent: khiếu nại| A3["Agent C
Complaint"]
    A1 --> SFU
    A2 --> SFU
    A3 --> SFU
    Redis["Redis
shared session + handoff"] <--> Rec
    Redis <--> A1
    Redis <--> A2
    Redis <--> A3
    CH["ClickHouse
turn events"] <-.- Rec
    CH <-.- A1
    CH <-.- A2
    CH <-.- A3
    style SFU fill:#e94560,stroke:#fff,color:#fff
    style Redis fill:#dc3545,stroke:#fff,color:#fff
    style CH fill:#2c3e50,stroke:#fff,color:#fff

Pattern hay dùng 2026: "agent swap" thay vì "call transfer". Trong agent swap, cùng một LiveKit room chỉ có một tracked participant là "agent voice" — backend chuyển từ agent A sang agent B mà không thay đổi participant. SFU không thấy khác biệt, người dùng không thấy khác biệt, chỉ có conductor biết. Context được load từ Redis cho agent mới; agent mới nói câu mở đầu nối liền hội thoại ("Vâng, tôi là Linh, mình sẽ giúp anh xử lý khiếu nại về món ăn nhé").

class ConductorAgent:
    async def handle_turn(self, room_id: str, transcript: str):
        context = await session_store.load_context(room_id)
        intent = await self.classifier.classify(transcript, context)

        current_agent = await session_store.get_active_agent(room_id)
        target_agent = self.route_by_intent(intent)

        if current_agent != target_agent:
            await self.swap_agent(room_id, current_agent, target_agent)
            handoff_msg = self.generate_handoff_msg(target_agent, intent)
            await self.speak(room_id, handoff_msg)

        response = await target_agent.respond(transcript, context)
        await self.speak(room_id, response)

    async def swap_agent(self, room_id: str, old: str, new: str):
        await session_store.set_active_agent(room_id, new)
        await r.publish(f"conductor:{room_id}", json.dumps({
            "type": "agent_swapped",
            "from": old,
            "to": new,
        }))

Lưu ý: với Realtime API OpenAI, bạn không thể dễ dàng "swap agent" vì session gắn với model và không có API shared context ngoài session. Trong trường hợp đó, pattern đúng là giữ một agent duy nhất và dùng tool call để truy cập knowledge base chuyên môn — khác nhau về kỹ thuật nhưng cùng hiệu quả về UX.

15. Deployment pattern và scale horizontally

Một voice agent worker chỉ có thể phục vụ một số lượng nhất định phiên song song do giới hạn bộ nhớ, CPU, và quota LLM per-connection. Thực nghiệm phổ biến: một Python process với Pipecat hoặc LiveKit Agents chạy tốt 20-40 phiên song song, tuỳ độ phức tạp của prompt và tần suất tool call. Khi vượt ngưỡng, bạn cần horizontal scale.

graph TB
    subgraph "Edge"
        SFU1["LiveKit SFU node 1"]
        SFU2["LiveKit SFU node 2"]
        SFU3["LiveKit SFU node 3"]
    end
    subgraph "Dispatcher"
        D["LiveKit Dispatcher
Redis-backed queue"]
    end
    subgraph "Worker Pool"
        W1["Worker 1
(20 sessions)"]
        W2["Worker 2
(20 sessions)"]
        Wn["Worker N
(20 sessions)"]
    end
    subgraph "Shared State"
        R["Redis
session/context"]
        CH["ClickHouse
events"]
    end
    SFU1 --> D
    SFU2 --> D
    SFU3 --> D
    D --> W1
    D --> W2
    D --> Wn
    W1 <--> R
    W2 <--> R
    Wn <--> R
    W1 -.-> CH
    W2 -.-> CH
    Wn -.-> CH
    style D fill:#e94560,stroke:#fff,color:#fff
    style R fill:#dc3545,stroke:#fff,color:#fff

Vài bài học từ các đội đã chạy voice agent ở production scale:

• Không chia sẻ GPU giữa STT/TTS với LLM. LLM inference có burst pattern khác STT/TTS hoàn toàn. Trộn chung làm cả hai chậm.
• Pre-warm TTS voice cache. Lần đầu load một voice có thể mất 2-3 giây. Worker phải warmup trước khi nhận session.
• Sticky session nhưng không sticky pod. Session dính với một room, nhưng room có thể chuyển pod khi pod đang drain — pod mới reload context từ Redis. Không bao giờ dùng in-memory state.
• Graceful shutdown 60-90 giây. Khi autoscaler muốn kill một pod, cho phép các phiên hiện tại chạy xong, chặn phiên mới, rồi mới exit. Trung bình cuộc gọi 3-5 phút, nên 90 giây là đủ.
• Circuit breaker theo upstream. Nếu Deepgram bị chậm, worker phải tự động cắt và rơi về fallback (ví dụ Whisper self-host) thay vì kéo toàn bộ TTFT lên.
• Region pinning. User ở Đông Nam Á phải được route tới worker đặt tại Singapore hoặc Tokyo. LLM và SFU đều cần cùng vùng. Chênh lệch 100 ms giữa region là ngân sách latency khổng lồ.

16. So sánh các framework 2026

17. Checklist đưa voice agent vào sản xuất 2026

• Đã chọn kiến trúc: cascaded hay speech-to-speech, và có lý do rõ ràng cho từng lĩnh vực compliance.
• Đã đo voice-to-voice p50 và p95 trên cùng region production, không chỉ ở dev.
• VAD + turn detection có hai ngưỡng (quick-commit và hard-commit) cho tiếng Việt.
• Barge-in handling loại được backchannel bằng mô hình audio phụ, không dùng VAD thuần.
• STT có fallback tự động khi TTFB tăng quá p95 historical.
• TTS đã pre-warm voice trước khi pod nhận session đầu tiên.
• LLM request có abort signal, bị cancel đúng lúc khi barge-in xảy ra.
• Session state trong Redis có TTL và được reload từ Redis khi pod chuyển.
• ClickHouse có bảng voice_events partition theo tháng, TTL 60-90 ngày.
• Dashboard theo dõi TTFT, voice-to-voice latency, barge-in rate, tool failure rate, cost per minute.
• Kill-switch cắt stream về IVR truyền thống khi LLM hoặc STT upstream sự cố.
• SIP bridge test với ít nhất 3 nhà mạng PSTN nếu phục vụ số điện thoại.
• Compliance: nếu là ngân hàng/y tế, bắt buộc có transcript + voice recording encrypted tại rest.
• Load test với 2x throughput đỉnh dự kiến, theo dõi p99 và failure mode.
• Multi-region deploy với failover tự động nếu SLA voice yêu cầu.
• Dynamic throttling theo tenant khi upstream LLM hit rate limit.
• Phonenumber abuse detection (gọi nhiều cuộc liên tục, brute force IVR).

18. Kết luận

Voice agent không phải "chat app có âm thanh" — nó là một hệ thống real-time có ngân sách latency khắc nghiệt, bộ công cụ riêng, và pattern production khác hẳn text chat. Stack năm 2026 đã trưởng thành đến mức một team ba người có thể dựng một voice agent production-grade trong vài tuần: LiveKit hoặc Pipecat làm khung, Deepgram Nova-3 làm tai, Claude Sonnet 4.6 làm não, Cartesia Sonic 3 làm miệng, Redis giữ trạng thái, ClickHouse giữ ký ức lâu dài. Lựa chọn giữa cascaded và speech-to-speech là lựa chọn kiến trúc đầu tiên và lớn nhất, định hình mọi quyết định phía sau.

Multi-agent voice đẩy các đánh đổi lên một nấc mới: ai cầm micro, làm sao chuyển giao không lộ, giọng nào cho agent nào. Đây là nơi pattern "shared session + conductor + agent swap" trên Redis và LiveKit đang dần trở thành chuẩn không chính thức. Và với Realtime API OpenAI cộng MCP, bạn có thể tích hợp hàng trăm tool chuyên môn vào một phiên voice duy nhất — viễn cảnh một assistant voice biết mọi thứ về doanh nghiệp của bạn, nói chuyện tự nhiên 24/7, và chi phí thấp hơn trực tổng đài 10-20 lần, không còn là khoa học viễn tưởng.

Nếu bạn đang xây một sản phẩm có khách hàng gọi điện đến — hoặc nên gọi điện đến — bây giờ là thời điểm tốt để bắt đầu. Công cụ đã sẵn, mô hình đã đủ tốt, hạ tầng đã chín. Điều còn lại là UX cụ thể của bạn, chính sách của bạn, và dữ liệu của bạn. Đó mới là phần khó duy nhất còn lại của bài toán.

Nguồn tham khảo

• LiveKit, Introduction - LiveKit Agents Documentation — docs.livekit.io/agents
• LiveKit GitHub, A framework for building realtime voice AI agents — github.com/livekit/agents
• LiveKit Blog, Sequential Pipeline Architecture for Voice Agents — livekit.com/blog sequential pipeline architecture
• LiveKit Blog, Solving unwanted interruptions with Adaptive Interruption Handling — livekit.com/blog adaptive interruption handling
• Pipecat GitHub, Open Source framework for voice and multimodal conversational AI — github.com/pipecat-ai/pipecat
• WebRTC.ventures, Bedrock vs Vertex vs LiveKit vs Pipecat: Choosing a Voice AI Agent Production Framework — webrtc.ventures choosing voice ai agent framework
• Gustavo Garcia (Medium), RealTime AI Agents frameworks comparison: LiveKit, Pipecat and TEN — medium.com realtime ai agents frameworks
• Arun Baby, Voice Agent Frameworks: LiveKit & Pipecat — arunbaby.com voice agent frameworks
• Softcery, Real-Time (Speech-to-Speech) vs Turn-Based (Cascading STT/TTS) Voice Agent Architecture — softcery.com real-time vs turn-based
• TeamDay.ai, Voice AI Architecture Guide: Cascaded vs Speech 2026 — teamday.ai voice ai architecture guide 2026
• OpenAI, Introducing gpt-realtime and Realtime API updates for production voice agents — openai.com gpt-realtime
• OpenAI Developers, Updates for developers building with voice — developers.openai.com updates audio models
• OpenAI Platform, Realtime API Documentation — platform.openai.com realtime guide
• MarkTechPost, OpenAI Releases Advanced Speech-to-Speech Model with MCP, Image Input and SIP Support — marktechpost.com openai realtime s2s mcp sip
• Deepgram, Best Text-to-Speech AI 2026 — deepgram.com best text-to-speech 2026
• Deepgram Docs, Voice Agent TTS Models — developers.deepgram.com voice agent tts
• Inworld, Best TTS APIs for Real-Time Voice Agents (2026 Benchmarks) — inworld.ai best tts real-time voice 2026
• Hamming AI, Best Voice Agent Stack: A Complete Selection Framework — hamming.ai best voice agent stack
• Cerebrium, Deploying a global scale, AI voice agent with 500ms latency — cerebrium.ai voice agent 500ms latency
• Ruh.ai, Voice AI Latency Optimization: How to Achieve Sub-Second Agent Responses in 2026 — ruh.ai voice ai latency optimization
• Daily.co, Benchmarking LLMs for Voice Agent Use Cases — daily.co benchmarking llms voice agent
• Famulor, The Art of Listening: Mastering Turn Detection and Interruption Handling — famulor.io turn detection interruption
• Sky-Scribe, AI Voice Recognition: Barge-In, Turn-Taking, and VAD — sky-scribe.com barge-in turn-taking vad
• Sayna.ai, Handling barge-in : What Happens When Users Interrupt Your AI mid-sentence — sayna.ai handling barge-in
• CallBotics, AI Voice Agent Interruption Handling Guide 2026 — callbotics.ai voice agent interruption handling
• Redis Blog, AI Agent Architecture: Build Systems That Work in 2026 — redis.io ai agent architecture 2026
• ClickHouse Blog, The Agentic Data Stack — clickhouse.com agentic data stack
• ClickHouse Blog, Tracing OpenAI agents with ClickStack — clickhouse.com tracing openai agents
• Getbluejay, Voice AI Agent Architecture Patterns: How to Design Agents That Scale — getbluejay.ai voice ai agent architecture
• AWS Machine Learning Blog, Deploy voice agents with Pipecat and Amazon Bedrock AgentCore Runtime — aws.amazon.com deploy voice agents pipecat bedrock
• Plivo Docs, OpenAI Realtime (Speech-to-Speech) Integration Guide — plivo.com openai realtime integration