โครงสร้างพื้นฐาน Voice AI: การสร้าง Speech Agent แบบเรียลไทม์

อัปเดต 11 ธันวาคม 2025

อัปเดตธันวาคม 2025: Deepgram STT ที่ 150ms, ElevenLabs TTS ที่ 75ms—แต่ agent ส่วนใหญ่ใช้เวลา 800ms-2s เนื่องจากความหน่วงสะสมในระบบ การสนทนาของมนุษย์ต้องการหน้าต่างตอบสนอง 300-500ms ความหน่วงของ Pipeline: STT (100-500ms) + LLM (350ms-1s+) + TTS (75-200ms) ทุกมิลลิวินาทีมีความสำคัญสำหรับ voice agent ระดับ production

Deepgram ส่งมอบ speech-to-text ใน 150 มิลลิวินาที ElevenLabs สังเคราะห์เสียงใน 75 มิลลิวินาที แต่ voice AI agent ส่วนใหญ่ยังคงใช้เวลา 800 มิลลิวินาทีถึงสองวินาทีในการตอบสนอง—เพราะความหน่วงสะสมตลอดทั้ง stack¹ ช่องว่างระหว่างความสามารถของแต่ละ component และประสิทธิภาพแบบ end-to-end เผยให้เห็นความท้าทายด้านโครงสร้างพื้นฐานที่เป็นหัวใจของ voice AI: การจัดการ speech recognition, language model และ synthesis ให้เป็น pipeline ที่ตรงกับจังหวะการสนทนาของมนุษย์

การสนทนาของมนุษย์ทำงานภายในหน้าต่างตอบสนอง 300-500 มิลลิวินาที² ความล่าช้าเกิน 500 มิลลิวินาทีรู้สึกไม่เป็นธรรมชาติ เกิน 1.2 วินาที ผู้ใช้จะวางสายหรือขัดจังหวะ การสร้าง voice agent ที่ตอบสนองตามเกณฑ์เหล่านี้ต้องเข้าใจแต่ละชั้นของ stack เลือก component ที่เหมาะสม และออกแบบระบบที่ทุกมิลลิวินาทีมีความสำคัญ

Voice AI stack

Voice agent ทุกตัวพึ่งพา component สี่ตัวทำงานร่วมกัน:³

Speech-to-Text (STT/ASR): "หู" ที่ถอดเสียงพูดเป็นข้อความ ความหน่วงอยู่ในช่วง 100-500 มิลลิวินาทีขึ้นอยู่กับการตั้งค่า streaming

Large Language Model (LLM): "สมอง" ที่ประมวลผลข้อความที่ถอดแล้วและสร้างคำตอบ ความหน่วงอยู่ในช่วง 350 มิลลิวินาทีสำหรับโมเดลที่ปรับแต่งแล้วจนถึงมากกว่าหนึ่งวินาทีสำหรับโมเดล frontier

Text-to-Speech (TTS): "เสียง" ที่สังเคราะห์ข้อความตอบกลับเป็นเสียง TTS แบบ streaming สมัยใหม่ทำได้ 75-200 มิลลิวินาที time-to-first-audio

Orchestration: "วาทยกร" ที่จัดการการไหลแบบเรียลไทม์ระหว่าง component, จัดการ turn-taking, การขัดจังหวะ และ session state

สมการความหน่วง

ความหน่วงของ Voice AI สะสมตลอด pipeline:⁴

Total Latency = STT + LLM + TTS + Network + Processing
             = 200ms + 500ms + 150ms + 50ms + 100ms
             = 1000ms (ปกติ)

การบรรลุการตอบสนองต่ำกว่า 500 มิลลิวินาทีต้องบีบอัดแต่ละ component หรือทำ pipeline แบบขนานผ่าน streaming—เริ่ม speech synthesis ก่อนที่ LLM จะสร้างเสร็จ ประมวลผล partial transcription ก่อนที่ผู้ใช้จะพูดจบ

โครงสร้างพื้นฐาน Speech-to-text

ชั้น ASR แปลง audio stream เป็นข้อความที่ language model สามารถประมวลผลได้ การเลือกผู้ให้บริการเกี่ยวข้องกับการสร้างสมดุลระหว่างความหน่วง ความแม่นยำ และต้นทุน

การเปรียบเทียบผู้ให้บริการ

Deepgram Nova-3:⁵ - Time-to-first-token: ~150ms (US), 250-350ms (global) - Word error rate: 18.3% - ปรับแต่งสำหรับ Streaming พร้อม real-time factor 0.2-0.3x - ราคา: $0.0043/นาที (pay-as-you-go) - เหมาะสำหรับ: Voice agent ที่ต้องการความหน่วงต่ำโดยให้ความสำคัญกับความเร็ว

AssemblyAI Universal-2:⁶ - ความหน่วง: 300-600ms - Word error rate: 14.5% (ความแม่นยำดีที่สุดในบรรดา streaming model) - ประสิทธิภาพดีใน domain เฉพาะทางในบริบทการแพทย์และการขาย - ราคา: $0.00025/วินาที - เหมาะสำหรับ: แอปพลิเคชันที่ต้องการความแม่นยำมากกว่าความเร็ว

Whisper (self-hosted):⁷ - ความหน่วง: 1-5 วินาที (batch), 380-520ms (WhisperX ปรับแต่ง) - ความแม่นยำสูงสุดสำหรับ offline transcription - ต้องการวิศวกรรมอย่างมากสำหรับ production streaming - เหมาะสำหรับ: Batch processing, hybrid architecture

Groq-accelerated Whisper: - ความหน่วง: ต่ำกว่า 300ms บน LPU hardware - รวมความแม่นยำของ Whisper กับ streaming latency - มีจำกัดผ่าน GroqCloud - เหมาะสำหรับ: แอปพลิเคชันเรียลไทม์ที่เน้นคุณภาพ

รูปแบบโครงสร้างพื้นฐาน ASR

Streaming architecture: เริ่ม transcription ทันทีเมื่อ audio มาถึงแทนที่จะรอ utterance ที่สมบูรณ์ ผลลัพธ์บางส่วนส่งไปยัง downstream component ก่อนที่ผู้ใช้จะพูดจบ

# Streaming ASR pattern
async def transcribe_stream(audio_stream):
    async for chunk in audio_stream:
        partial = await asr_client.transcribe_chunk(chunk)
        if partial.is_final:
            yield partial.text
        else:
            # Send interim results for prediction
            yield partial.interim_text

Voice Activity Detection (VAD): ตรวจจับว่าผู้ใช้เริ่มและหยุดพูดเมื่อไหร่ VAD ที่ไม่ดีสร้างทั้งการตัดก่อนเวลา (ขัดจังหวะผู้ใช้) หรือความล่าช้ามากเกินไป (รอความเงียบที่เกิดขึ้นไปแล้ว)

Endpointing: กำหนดว่าผู้ใช้จบ turn ของตนเมื่อไหร่ Endpointing ที่ aggressive ลดความหน่วงแต่เสี่ยงที่จะตัดผู้พูด Endpointing ที่ conservative รับประกันความสมบูรณ์แต่เพิ่มความล่าช้า

ความต้องการ GPU สำหรับ Self-hosted ASR

การ deploy Whisper แบบ self-hosted ต้องการ GPU acceleration:⁸

Production speech-to-text มักรันบน A100 หรือ RTX 6000 Ada แทนที่จะเป็น H100—workload ได้ประโยชน์จาก memory bandwidth มากกว่า raw compute

ชั้น Large language model

LLM ประมวลผล transcribed speech และสร้างข้อความตอบกลับ การเลือกโมเดลส่งผลอย่างมากต่อทั้งความหน่วงและคุณภาพการสนทนา

โปรไฟล์ความหน่วงของโมเดล

เร็วมาก (ต่ำกว่า 350ms):⁹ - Gemini Flash 1.5: ~300ms time-to-first-token - Groq-served Llama: ~200ms บน LPU - เหมาะสำหรับ: การตอบสนองสูงสุด, query ที่ง่ายกว่า

เร็ว (350-700ms): - GPT-4o-mini: ~400ms - Claude 3.5 Haiku: ~350ms - เหมาะสำหรับ: สมดุลระหว่างความเร็วและความสามารถ

มาตรฐาน (700ms-1s+): - GPT-4o: ~700ms - Claude 3.5 Sonnet: ~800ms - เหมาะสำหรับ: การให้เหตุผลที่ซับซ้อน, แอปพลิเคชันที่เน้นคุณภาพ

กลยุทธ์การเพิ่มประสิทธิภาพ

Streaming generation: เริ่ม TTS synthesis เมื่อ LLM token มาถึงแทนที่จะรอ response ที่สมบูรณ์ Orchestration pipeline สมัยใหม่ stream token โดยตรงไปยัง speech synthesis

Speculative execution: ทำนาย response ที่น่าจะเป็นไปได้จาก partial transcription เริ่มสร้าง response ก่อนที่ผู้ใช้จะพูดจบ ยกเลิก prediction ที่ไม่ตรงกับ intent สุดท้าย

Model routing: Route query ง่ายๆ ไปยังโมเดลเร็ว query ซับซ้อนไปยังโมเดลที่มีความสามารถ Classifier กำหนดความซับซ้อนของ query ในเวลาหลักหน่วยมิลลิวินาที

# Model routing pattern
def route_query(transcript, context):
    complexity = classify_complexity(transcript)
    if complexity == "simple":
        return "gemini-flash"
    elif complexity == "moderate":
        return "gpt-4o-mini"
    else:
        return "gpt-4o"

Prompt optimization: Prompt ที่สั้นกว่าลดเวลาประมวลผล Cache system prompt ที่ผู้ให้บริการรองรับ prompt caching (Anthropic ลดต้นทุน 90% บน cached prefix)

โครงสร้างพื้นฐาน Text-to-speech

TTS แปลงข้อความที่ LLM สร้างเป็นเสียงพูดที่เป็นธรรมชาติ ชั้นนี้เปลี่ยนจากคอขวด (2-3 วินาทีในอดีต) เป็นจุดแข็ง (75-150ms กับผู้ให้บริการสมัยใหม่)

การเปรียบเทียบผู้ให้บริการ

ElevenLabs Flash v2.5:¹⁰ - Time-to-first-audio: 75ms - คุณภาพเสียง: ความเป็นธรรมชาติดีที่สุดในอุตสาหกรรม - ช่วงอารมณ์: การแสดงออกที่ยอดเยี่ยม - ราคา: $0.050/1,000 ตัวอักษร - เหมาะสำหรับ: แอปพลิเคชันที่เน้นคุณภาพ

Cartesia Sonic:¹¹ - Time-to-first-audio: 40-95ms - สร้างมาเพื่อการสนทนาเรียลไทม์โดยเฉพาะ - ความหน่วงต่ำสม่ำเสมอภายใต้ภาระงาน - ราคา: $0.038/1,000 ตัวอักษร - เหมาะสำหรับ: แอปพลิเคชันที่เน้นความหน่วง

Deepgram Aura-2:¹² - Time-to-first-audio: ต่ำกว่า 150ms - ความน่าเชื่อถือระดับ Enterprise - คุ้มค่าในระดับ scale - ราคา: $0.030/1,000 ตัวอักษร - เหมาะสำหรับ: Enterprise deployment ปริมาณสูง

PlayHT: - ความหน่วง: ~300ms - คลังเสียงกว้างขวาง - ความสามารถในการโคลนเสียง - ราคาต่ำกว่า - เหมาะสำหรับ: แอปพลิเคชันที่คำนึงถึงงบประมาณ

รูปแบบโครงสร้างพื้นฐาน TTS

Streaming synthesis: สร้าง audio แบบก้าวหน้าเมื่อข้อความมาถึงจาก LLM ส่ง audio chunk ไปยังผู้ใช้ก่อนที่ประโยคที่สมบูรณ์จะสังเคราะห์เสร็จ

Audio buffering: รักษา buffer ขนาดเล็กเพื่อให้การเล่นราบรื่นแม้มีเวลา synthesis ที่แปรผัน Buffer มากเกินไปและความหน่วงจะแย่ลง Buffer น้อยเกินไปและ audio จะกระตุก

Voice caching: Cache วลีที่ใช้บ่อย (การทักทาย, response ทั่วไป) เป็น audio ที่สังเคราะห์ล่วงหน้า กำจัดความหน่วง TTS ทั้งหมดสำหรับเนื้อหาที่ cache

แพลตฟอร์ม Orchestration

ชั้น Orchestration เชื่อมต่อ ASR, LLM และ TTS component ในขณะที่จัดการ telephony, turn-taking และ session management การเลือกแพลตฟอร์มกำหนดความเร็วในการพัฒนาและความน่าเชื่อถือของ production

การเปรียบเทียบแพลตฟอร์ม

Vapi:¹³ - โฟกัส: แพลตฟอร์ม voice agent แบบ turnkey - Telephony: Native SIP/PSTN integration - การปรับแต่ง: เลือก component แบบ modular - ราคา: $0.05/นาที + ค่า component - เหมาะสำหรับ: Deploy รวดเร็ว, แอปพลิเคชันที่เน้นโทรศัพท์

LiveKit:¹⁴ - โฟกัส: โครงสร้างพื้นฐานเรียลไทม์แบบ open-source - สถาปัตยกรรม: WebRTC-native พร้อม agent framework - การปรับแต่ง: ควบคุมเต็มที่, self-hostable - ราคา: Free tier (100 concurrent, 5,000 นาที/เดือน), แบบชำระเงินจาก $50/เดือน - เหมาะสำหรับ: แอปพลิเคชันที่กำหนดเอง, ทีมที่ต้องการควบคุมเต็มที่

Retell AI:¹⁵ - โฟกัส: การไหลของการสนทนาที่เป็นธรรมชาติ - จุดเด่น: Turn-taking และการจัดการการขัดจังหวะที่ปรับแต่ง - Compliance: HIPAA และ SOC 2 Type II - ราคา: $0.07+/นาที - เหมาะสำหรับ: ให้ความสำคัญกับคุณภาพการสนทนา, enterprise compliance

Pipecat: - โฟกัส: Agent framework แบบ open-source - Integration: ทำงานกับ cloud provider หลัก - การปรับแต่ง: สร้าง pipeline ได้ยืดหยุ่นมาก - เหมาะสำหรับ: นักพัฒนาที่ต้องการ framework โดยไม่ติด platform lock-in

เกณฑ์การเลือก

รูปแบบสถาปัตยกรรม

Cascading pipeline (ASR → LLM → TTS)

สถาปัตยกรรมแบบดั้งเดิมประมวลผล audio ผ่านขั้นตอนที่แยกกัน:¹⁶

Audio → ASR → Text → LLM → Response Text → TTS → Audio

ข้อดี: - Component modularity (เปลี่ยนผู้ให้บริการได้ง่าย) - Tooling และ debugging ที่เป็นผู้ใหญ่ - โครงสร้างต้นทุนที่คาดเดาได้ (~$0.15/นาที ไม่ว่าการสนทนาจะยาวเท่าไหร่) - Intermediate representation ที่โปร่งใส (ข้อความตรวจสอบได้)

ความท้าทาย: - ความหน่วงสะสมตลอดขั้นตอน - สูญเสียข้อมูลใน text representation (prosody, อารมณ์) - การประสานงาน streaming ที่ซับซ้อน

Speech-to-speech (S2S)

End-to-end model ประมวลผล audio โดยตรงเป็น audio:¹⁷

Audio → Multimodal Model → Audio

ตัวอย่าง: - GPT-4o voice mode - Moshi (Kyutai Labs) - Ultravox

ข้อดี: - รักษาข้อมูล prosodic - ความหน่วงที่อาจต่ำกว่า (โมเดลเดียว) - จัดการ overlapping speech ได้เป็นธรรมชาติ

ความท้าทาย: - ต้นทุนสูงกว่า (~$0.30-1.50/นาที สำหรับการสนทนาที่ยาวกว่า) - การปรับแต่งจำกัด (ไม่สามารถเปลี่ยน component ได้) - ความทึบในการ debug (ไม่มี intermediate text)

แนวทางแบบ Hybrid

ระบบ production ใช้สถาปัตยกรรมผสมมากขึ้น:

Cascading พร้อม S2S fallback: ใช้ cascading สำหรับ interaction มาตรฐาน เปลี่ยนเป็น S2S สำหรับ overlapping dialogue ที่ซับซ้อน

Parallel processing: รัน ASR และ intent prediction พร้อมกัน เริ่มสร้าง response จาก predicted intent ขณะที่ ASR ทำงานเสร็จ

Speculative TTS: สร้าง response audio ที่น่าจะเป็นไปได้ล่วงหน้า เล่น cached audio ทันทีถ้า prediction ตรง; fallback ไปยัง synthesis ถ้าไม่ตรง

การ Scale โครงสร้างพื้นฐาน Voice AI

การวางแผน Concurrent capacity

Voice AI scale แตกต่างจาก text-based AI แต่ละ concurrent call ต้องการทรัพยากรประมวลผลเฉพาะตลอด pipeline¹⁸

Per-GPU capacity (self-hosted):

Managed service capacity: Cloud provider จัดการ scaling อัตโนมัติ

[เนื้อหาถูกตัดทอนสำหรับการแปล]