วิธีใช้ Gemini Live API สร้าง AI แบบ Real-Time

Gemini Live API คือ API สำหรับสร้าง AI ที่สามารถรับและตอบข้อมูลแบบ Real-Time ผ่านการเชื่อมต่อ WebSocket เหมาะกับระบบที่ต้องการการตอบสนองความหน่วงต่ำ เช่น Voice Assistant, AI Call Center, ผู้ช่วยขายสินค้าแบบพูดคุย, AI ที่มองภาพจากกล้อง หรือระบบสนทนาที่ผู้ใช้สามารถพูดแทรก AI ได้เหมือนคุยกับคนจริง

ต่างจาก Gemini API แบบ Request/Response ทั่วไปที่ทำงานประมาณนี้

User
↓
ส่ง Request
↓
Gemini ประมวลผล
↓
รับ Response
↓
จบ Connection

Live API จะรักษา Session ผ่าน WebSocket

User
↕
Microphone / Camera / Text
↕
WebSocket
↕
Gemini Live API
↕
Audio / Text / Function Calls

Connection จึงสามารถรับและส่งข้อมูลไปพร้อมกันได้อย่างต่อเนื่อง

โมเดลสำคัญสำหรับการสร้าง Voice AI แบบ Real-Time ในปัจจุบันคือ

gemini-3.1-flash-live-preview

ซึ่ง Google ออกแบบเป็นโมเดล Audio-to-Audio ที่มี Latency ต่ำ เหมาะกับ Real-time Dialogue และ Voice-first Application โดยเฉพาะ

❶ 🎙️ Gemini Live API คืออะไร

Live API เป็น Stateful API ที่ใช้ WebSocket

คำว่า Stateful หมายความว่า Session สามารถรักษาบริบทของการสนทนาระหว่าง Connection ไว้ได้

ตัวอย่าง

User:
สวัสดี ผมชื่อสมชาย

AI:
สวัสดีคุณสมชาย

User:
เมื่อกี้ผมบอกว่าชื่ออะไร

AI:
คุณชื่อสมชาย

ไม่จำเป็นต้องสร้าง Request ใหม่แบบแยกขาดจากกันทุกประโยค

เหมาะกับ Conversation ที่ต้องการความต่อเนื่อง

❷ ⚡ Live API ต่างจาก Streaming Response อย่างไร

บทความก่อนหน้าอธิบาย Streaming Response ซึ่งทำงานลักษณะ

User ส่ง Request
↓
Gemini
↓
ข้อความ Chunk 1
↓
Chunk 2
↓
Chunk 3

เป็นการ Stream Response กลับมา

แต่ Live API เป็น

Client
↕
Gemini

แบบ Bidirectional

จึงสามารถส่ง

• Audio ต่อเนื่อง
• Video Frames
• Text
• Function Results

และรับ

• Audio
• Text-related events
• Function Calls
• Transcriptions

ได้ระหว่าง Session

❸ 🆚 Streaming API กับ Live API เลือกอะไร

Chat แบบข้อความ

ใช้

Interactions API + Streaming

มักง่ายกว่า

Voice Assistant

ใช้

Live API

Real-time Camera Assistant

ใช้

Live API

Call Center Voice Agent

ใช้

Live API

งาน Batch จำนวนมาก

ใช้

Batch API

แต่ละ API ถูกออกแบบมาคนละงาน

❹ 🤖 โมเดล Live ที่ควรเริ่มใช้

ปัจจุบันโมเดลหลักสำหรับ Voice AI แบบ Real-Time คือ

gemini-3.1-flash-live-preview

Google อธิบายว่าเป็น

Low-latency
Audio-to-Audio
Real-time Dialogue
Voice-first AI

พร้อมความสามารถด้าน

• Acoustic Nuance
• Numeric Precision
• Multimodal Awareness
• Function Calling
• Google Search Grounding
• Thinking

❺ ⚠️ Gemini 3.1 Flash Live ยังเป็น Preview

จุดนี้สำคัญมาก

สถานะปัจจุบันคือ

Preview

ไม่ใช่ Stable/GA

ดังนั้นก่อนนำไปใช้กับ Production Critical System ต้องพิจารณา

• Model Lifecycle
• API Changes
• Rate Limits
• Pricing
• Reliability
• Migration Plan

Google ยังไม่ได้ประกาศ Shutdown Date ของ gemini-3.1-flash-live-preview ณ ข้อมูลปัจจุบัน

❻ 🗓️ อย่าใช้ Live Model เก่าจาก Tutorial

Tutorial เก่าอาจพบชื่อ เช่น

gemini-live-2.5-flash-preview

หรือ

gemini-2.5-flash-native-audio-preview-12-2025

Google แนะนำให้ย้ายมาที่

gemini-3.1-flash-live-preview

สำหรับ Live Conversation รุ่นปัจจุบัน

ดังนั้นก่อน Copy Code จาก Tutorial ควรตรวจ Model ID ล่าสุดเสมอ

❼ 📡 Live API ใช้ Protocol อะไร

Live API ใช้

WebSocket

หรือ

WSS

สำหรับ Connection ที่เข้ารหัส

WebSocket Reference ปัจจุบันแสดง Endpoint ใน API Version v1beta สำหรับ BidiGenerateContent

แนวคิดคือ

Client
↓
เปิด WebSocket
↓
ส่ง Session Configuration
↓
Session Ready
↓
ส่ง/รับข้อมูล Real-time
↓
Close

❽ 🧠 BidiGenerateContent คืออะไร

คำว่า

Bidi
=
Bidirectional

หมายถึงข้อมูลสามารถไหลได้สองทิศทาง

Client → Gemini
Gemini → Client

พร้อมกัน

ต่างจาก HTTP Request ทั่วไปที่มักเป็น

Request
→
Response

อย่างละหนึ่งรอบ

นี่เป็นพื้นฐานสำคัญที่ทำให้ Voice Conversation ดูเป็นธรรมชาติ

❾ 📥 Live API รับข้อมูลอะไรได้บ้าง

gemini-3.1-flash-live-preview รองรับ Input เช่น

Text
Image
Audio
Video

ทำให้สามารถสร้าง Application เช่น

Voice Assistant

Microphone
↓
Gemini
↓
Voice

Camera Assistant

Camera
+
Microphone
↓
Gemini
↓
Voice

Multimodal Support Agent

User พูด
+
แสดงสินค้าให้กล้องดู
↓
Gemini
↓
ตอบด้วยเสียง

❿ 🔊 Output ของ Native Audio Model

เมื่อใช้ Native Audio Model ปัจจุบัน Session Configuration ใช้

response_modalities = AUDIO

เป็นหลัก

ถ้าต้องการข้อความของสิ่งที่ Gemini พูด สามารถเปิด

output_audio_transcription

เพื่อรับ Transcript เพิ่ม

จึงไม่จำเป็นต้องเปลี่ยน Voice Response เป็น Text Response อย่างเดียว

⓫ 🐍 เชื่อม Gemini Live API ด้วย Python

ติดตั้ง SDK ปัจจุบัน

pip install -U google-genai

จากนั้นสร้าง Connection

import asyncio

from google import genai


client = genai.Client()

model = "gemini-3.1-flash-live-preview"

config = {
    "response_modalities": [
        "AUDIO"
    ],
}


async def main():
    async with client.aio.live.connect(
        model=model,
        config=config,
    ) as session:
        print("Live session started")


if __name__ == "__main__":
    asyncio.run(main())

เมื่อเข้าสู่

async with

WebSocket Session จะถูกเปิด

เมื่อออกจาก Block Session จะถูกปิด

⓬ 🟨 เชื่อม Live API ด้วย JavaScript

SDK

npm install @google/genai

ตัวอย่างพื้นฐาน

import {
  GoogleGenAI,
  Modality
} from "@google/genai";

const ai = new GoogleGenAI({});

const model =
  "gemini-3.1-flash-live-preview";

const session =
  await ai.live.connect({
    model,
    callbacks: {
      onopen() {
        console.log("Connected");
      },

      onmessage(message) {
        console.log(message);
      },

      onerror(error) {
        console.error(error);
      },

      onclose(event) {
        console.log(
          "Closed:",
          event.reason
        );
      },
    },

    config: {
      responseModalities: [
        Modality.AUDIO
      ],
    },
  });

JavaScript SDK ใช้ Callback สำหรับรับ Event จาก Session

⓭ 🎙️ รูปแบบ Audio Input ต้องเป็นอะไร

Live API ใช้ Raw Audio

รูปแบบหลักคือ

16-bit PCM
Little-endian

Input Native Rate คือ

16 kHz

ตัวอย่าง MIME Type

audio/pcm;rate=16000

Python

await session.send_realtime_input(
    audio=types.Blob(
        data=audio_chunk,
        mime_type=(
            "audio/pcm;rate=16000"
        ),
    )
)

⓮ 🎧 Output Audio เป็น 24 kHz

Audio ที่ Gemini ส่งกลับใช้

Raw
16-bit PCM
Little-endian
24 kHz

ดังนั้น Audio Player ต้องตั้ง Playback Format ให้ถูก

Input
16 kHz

Output
24 kHz

อย่านำ Output 24 kHz ไป Play ด้วย Configuration 16 kHz เพราะเสียงจะผิด Speed/Pitch

⓯ 🔄 Input ต้องเป็น 16 kHz เท่านั้นหรือไม่

Google ระบุว่า Native Input Rate คือ

16 kHz

แต่ Live API สามารถ Resample Input Rate อื่นได้

Developer ควรระบุ Sample Rate จริงใน MIME Type เช่น

audio/pcm;rate=48000

หากส่ง 48 kHz

อย่างไรก็ตาม 16 kHz เหมาะสำหรับ Voice Input และลด Bandwidth ได้ดี

⓰ 🔊 วิธีรับ Audio Response ด้วย Python

async for response in session.receive():
    if (
        response.server_content
        and
        response.server_content.model_turn
    ):
        for part in (
            response
            .server_content
            .model_turn
            .parts
        ):
            if part.inline_data:
                audio_data = (
                    part.inline_data.data
                )

                # ส่ง audio_data
                # ไป Audio Playback Queue

Gemini ส่ง Audio Response กลับมาเป็น Chunks

Application ควรนำ Chunk เหล่านี้เข้า Playback Buffer

⓱ 🔉 อย่ารอ Audio ทั้งหมดก่อน Play

ถ้าทำ

รับ Audio Chunk ทั้งหมด
↓
รวม
↓
รอ Gemini พูดจบ
↓
เริ่ม Play

จะเสียประโยชน์ของ Real-time API

ควรเป็น

Audio Chunk
↓
Playback Queue
↓
Speaker

Audio Chunk ถัดไป
↓
Playback Queue

ทำให้ AI เริ่มพูดก่อน Response ทั้งหมดเสร็จ

⓲ 🎙️ Microphone Pipeline ควรเป็นอย่างไร

Architecture พื้นฐาน

Microphone
↓
Capture PCM
↓
แบ่ง Audio Chunks
↓
send_realtime_input()
↓
Gemini

ฝั่ง Output

Gemini
↓
Audio Chunks
↓
Playback Queue
↓
Speaker

Input กับ Output ต้องทำงานพร้อมกัน

จึงนิยมใช้

• AsyncIO
• Threads
• Audio Queues

ตามภาษาและ Framework

⓳ ⚡ ใช้ asyncio.gather() ได้

Python Application สามารถมี Task

send_audio()

และ

receive_audio()

ทำงานพร้อมกัน

แนวคิด

await asyncio.gather(
    send_audio(session),
    receive_audio(session),
)

เพราะ Voice Conversation ต้องรับ Microphone และเล่น AI Audio พร้อมกัน

⓴ 💬 ส่ง Text เข้า Live Session ได้

Gemini 3.1 Flash Live รองรับ Text Input

สำหรับการสนทนาระหว่าง Session ปัจจุบันใช้

await session.send_realtime_input(
    text="สวัสดี ช่วยแนะนำตัวหน่อย"
)

JavaScript

session.sendRealtimeInput({
  text:
    "สวัสดี ช่วยแนะนำตัวหน่อย"
});

ทำให้ Application สามารถผสม

Voice
+
Text
+
Video

ใน Session เดียว

⚠️ send_client_content เปลี่ยนสำหรับ Gemini 3.1 Live

นี่เป็นจุดที่ Tutorial เก่าอาจทำให้สับสน

สำหรับ

gemini-3.1-flash-live-preview

send_client_content ใช้สำหรับการ Seed Initial Context History เท่านั้น โดยต้องเปิด Configuration ที่เกี่ยวข้อง

หลังจาก Model Turn แรกแล้ว Text Update ระหว่าง Conversation ควรใช้

send_realtime_input(text=...)

แทน

ดังนั้นอย่า Copy Pattern ของ Live Model รุ่นเก่าโดยไม่ตรวจ Documentation ปัจจุบัน

🖼️ ส่ง Video เข้า Live API อย่างไร

Live API รับ Video เป็น Frames

ไม่ได้ส่ง MP4 Stream ทั้งไฟล์ตรง ๆ ในรูปแบบเดียวกับ Video Player

ตัวอย่าง Python

await session.send_realtime_input(
    video=types.Blob(
        data=jpeg_frame,
        mime_type="image/jpeg",
    )
)

Google ระบุ Video Frame Rate สูงสุดประมาณ

1 frame / second

สำหรับ Live API Input ตาม Specification ปัจจุบัน

📹 1 FPS เพียงพอหรือไม่

Live Vision ไม่ได้ออกแบบเหมือนระบบ Video Streaming 30–60 FPS

เป้าหมายคือให้ Gemini รับ Context Visual เป็นระยะ

เช่น

กล้องมองสินค้า
↓
1 frame/sec
↓
Gemini เข้าใจสิ่งที่เห็น

เหมาะกับ

• Object Context
• Environment
• Screen Assistance
• Visual Support

ไม่ใช่ Video Processing Frame-by-Frame แบบ Computer Vision ความเร็วสูง

💡 Gemini Live API ใช้ภาษาไทยได้ไหม

ได้

Live API รองรับภาษาไทย

Thai
BCP-47 = th

และ Native Audio Models สามารถสลับภาษาใน Conversation ได้ตามบริบท

ตัวอย่าง

User:
สวัสดีครับ

Gemini:
สวัสดีครับ มีอะไรให้ช่วยครับ

หรือ User สามารถสลับภาษาได้ตามความสามารถของโมเดล

🌍 รองรับกี่ภาษา

Live API ปัจจุบันรองรับประมาณ

97 languages

รวมภาษาไทย

เหมาะกับ

• Multilingual Support
• Travel Assistant
• International Call Center
• Language Learning

🗣️ เปลี่ยนเสียง Gemini ได้ไหม

ได้

กำหนด Voice ผ่าน

speech_config

ตัวอย่าง Python

config = {
    "response_modalities": [
        "AUDIO"
    ],
    "speech_config": {
        "voice_config": {
            "prebuilt_voice_config": {
                "voice_name": "Kore"
            }
        }
    },
}

Developer ควรทดลองเสียงใน AI Studio เพื่อเลือก Voice ที่เหมาะกับ Brand และ Use Case

🎚️ Thinking Level ของ Live Model

Gemini 3.1 Flash Live ใช้

thinkingLevel

แทน thinkingBudget ของ Live Model รุ่น 2.5

รองรับระดับ เช่น

minimal
low
medium
high

Default ปัจจุบันคือ

minimal

เพื่อให้ Latency ต่ำที่สุด

⚡ ทำไม Default เป็น minimal

Voice Conversation ต้องตอบเร็ว

ถ้า User พูดว่า

สวัสดี

แล้ว AI ใช้ Reasoning หลายวินาทีก่อนตอบ

ประสบการณ์จะไม่เป็นธรรมชาติ

ดังนั้นงานสนทนาทั่วไปเหมาะกับ

minimal

หรือ low

ส่วนงานยากค่อยเพิ่ม Thinking

🧠 ควรใช้ High Thinking กับ Voice ไหม

ใช้ได้ตาม Requirement แต่ต้อง Benchmark

High Thinking สามารถเพิ่ม

• Quality ในโจทย์ยาก
• Latency
• Thinking Tokens
• Cost

ดังนั้น

Voice Greeting
→ minimal

แต่

Complex Technical Diagnosis
→ อาจทดลอง low/medium/high

แล้ววัดผล

📝 เปิด Transcript ของเสียง Gemini

หาก Output เป็น Audio แต่อยากแสดง Subtitle

เปิด

config = {
    "response_modalities": [
        "AUDIO"
    ],
    "output_audio_transcription": {},
}

จากนั้นตรวจ

response.server_content.output_transcription

และอ่านข้อความจาก

response
.server_content
.output_transcription
.text

เหมาะกับ

• Subtitle
• Conversation Log
• Accessibility
• Searchable History

🎤 เปิด Transcript ของ User

สามารถเปิด

input_audio_transcription

เพื่อรับ Transcript ของ Audio Input

ตัวอย่าง Configuration

config = {
    "response_modalities": [
        "AUDIO"
    ],
    "input_audio_transcription": {},
}

จากนั้นตรวจ

input_transcription

ทำให้สร้าง UI

User:
"ช่วยเช็กสถานะคำสั่งซื้อ"

Gemini:
"กรุณาบอกเลขคำสั่งซื้อครับ"

ได้ง่ายขึ้น

🗃️ Transcript ควรเก็บหรือไม่

ขึ้นกับ Product และ Privacy Policy

Conversation อาจมี

• Personal Information
• Customer Data
• Order Number
• Sensitive Business Data

ดังนั้นไม่ควร Save Transcript ทุก Session โดยอัตโนมัติโดยไม่พิจารณา

ควรกำหนด

Retention
Consent
Access Control
Encryption

ตาม Requirement

🧠 Voice Activity Detection หรือ VAD คืออะไร

VAD ย่อมาจาก

Voice Activity Detection

มีหน้าที่ตรวจว่า

User เริ่มพูดเมื่อไร
User หยุดพูดเมื่อไร

เพื่อแบ่ง Conversation เป็น Turns

Live API เปิด Automatic VAD เป็น Default

🎙️ Automatic VAD ทำให้ Voice AI เป็นธรรมชาติ

ถ้าไม่มี VAD Application อาจต้องมีปุ่ม

Start Talking
Stop Talking

ทุกครั้ง

แต่ Automatic VAD สามารถฟัง Stream ต่อเนื่องและตรวจช่วง Speech เอง

Flow

Silence
↓
User เริ่มพูด
↓
VAD ตรวจพบ
↓
ส่ง Speech Turn
↓
User หยุดพูด
↓
Gemini ตอบ

🛑 User พูดแทรก Gemini ได้

หนึ่งในความสามารถสำคัญคือ

Barge-in

สมมติ Gemini กำลังพูดว่า

จากข้อมูลที่พบ...

User พูดแทรก

หยุดก่อน

VAD สามารถตรวจ Start of Activity

แล้ว Interrupt Generation ปัจจุบัน

ทำให้ Conversation ใกล้เคียงการพูดกับคนมากขึ้น

⚠️ เมื่อเกิด Interruption ต้องหยุด Audio Playback

เมื่อ Server แจ้ง

interrupted = true

Application ควร

Stop Audio Playback
+
Clear Playback Queue

ทันที

ไม่เช่นนั้น Gemini อาจหยุดสร้างแล้ว แต่ Speaker ยังเล่น Audio เก่าที่ Buffer ไว้

ทำให้ User รู้สึกว่า AI ไม่ยอมหยุดพูด

🔄 ตัวอย่างตรวจ Interruption

async for response in session.receive():
    if (
        response.server_content
        and
        response.server_content.interrupted
    ):
        stop_audio_playback()
        clear_audio_queue()

นี่เป็น Logic สำคัญมากสำหรับ Voice Assistant

📴 หยุด Microphone ชั่วคราวต้องส่งอะไร

Google ระบุว่าเมื่อ Audio Stream หยุดนานกว่า 1 วินาที เช่น User ปิด Microphone

ควรส่ง

audio_stream_end

เพื่อ Flush Audio ที่ Server เก็บอยู่

Python

await session.send_realtime_input(
    audio_stream_end=True
)

เมื่อ User เปิด Microphone ใหม่ก็สามารถส่ง Audio ต่อได้

🧩 Hybrid VAD คืออะไร

Hybrid VAD รวม

Server Automatic VAD
+
Client-side End-of-Speech Detection

Server ยังตรวจ Speech Start

แต่ Client สามารถตรวจว่า User หยุดพูดแล้วและส่ง

audio_stream_end

ทันที

ช่วยลดเวลารอ Silence Timeout ของ Server

⚡ Hybrid VAD ช่วยลด Latency

Flow

User พูดจบ
↓
Client VAD ตรวจได้ทันที
↓
audio_stream_end
↓
Gemini เริ่มตอบ

แทน

User พูดจบ
↓
รอ Server Silence Detection
↓
Gemini ตอบ

แต่ Client VAD ต้องตั้ง Threshold ให้ดี

ถ้าตัดเร็วเกินไปอาจตัดคำพูดกลางประโยค

🎚️ silenceDurationMs ควรตั้งเท่าไร

เอกสารปัจจุบันของ Google แนะนำช่วงประมาณ

500–800 ms

เป็น Balance ที่ดีระหว่าง

• ความครบของประโยค
• Latency

Server Default ภายในอยู่ประมาณ

800 ms

หากตั้งต่ำมาก เช่น

100–200 ms

อาจตัด Turn ระหว่างที่ User หยุดคิดหรือหายใจ

⏳ ถ้าตั้ง Silence สูงเกินไป

เช่น

2,000 ms+

AI อาจรอนานหลัง User พูดจบ

ทำให้ Conversation รู้สึก

User:
สวัสดี

...เงียบ...

AI:
สวัสดีครับ

ดังนั้น VAD Configuration มีผลต่อ UX โดยตรง

🎛️ Manual VAD ทำได้ไหม

ได้

สามารถปิด Automatic VAD

config = {
    "response_modalities": [
        "AUDIO"
    ],
    "realtime_input_config": {
        "automatic_activity_detection": {
            "disabled": True
        }
    },
}

จากนั้น Client ส่ง

await session.send_realtime_input(
    activity_start=types.ActivityStart()
)

ส่ง Audio

แล้ว

await session.send_realtime_input(
    activity_end=types.ActivityEnd()
)

⚠️ Manual VAD ซับซ้อนกว่า

เมื่อปิด Automatic VAD

Client ต้องจัดการเองว่า

• Speech เริ่มเมื่อไร
• Speech จบเมื่อไร
• Pre-speech Buffer
• Silence Threshold
• False Trigger

เหมาะกับ Application ที่ต้องควบคุม Turn-taking อย่างละเอียด

สำหรับ Project แรกควรเริ่มจาก Automatic VAD ก่อน

🔊 Echo Cancellation สำคัญ

สมมติ Gemini พูดผ่าน Speaker

Microphone รับเสียง Gemini กลับเข้าไป

Gemini Speaker
↓
Microphone
↓
Gemini API

ระบบอาจเข้าใจว่า User กำลังพูด

เกิด

• False Interruption
• Audio Loop
• Conversation สับสน

Production Voice App จึงควรใช้

• Echo Cancellation
• Noise Suppression
• Appropriate Gain Control

ตาม Audio Platform

🎧 Headset ทดสอบง่ายกว่า Speaker

ช่วง Development หากเกิด AI พูดแทรกตัวเองบ่อย

ลองใช้

Headphones / Headset

ถ้าปัญหาหาย มีโอกาสสูงว่า Audio Output กำลังย้อนเข้า Microphone

จากนั้นค่อยแก้ Echo Cancellation สำหรับ Speaker Mode

🛠️ Live API ใช้ Function Calling ได้

นี่เป็น Feature สำคัญมากสำหรับสร้าง Voice Agent ที่ทำงานจริง

ตัวอย่าง

User:
เช็ก Order 12345 ให้หน่อย

Gemini สามารถสร้าง

get_order_status(
  order_id="12345"
)

Application ไปอ่าน Database

แล้วส่ง Result กลับ

Gemini จึงพูด

Order 12345 ถูกจัดส่งแล้วครับ

ทำให้ Voice Assistant ไม่ได้เพียงพูด แต่ทำงานกับ Business System ได้

⚠️ Function Calling ใน 3.1 Live เป็น Synchronous

สำหรับ

gemini-3.1-flash-live-preview

Google ระบุว่า Async Function Calling ยังไม่รองรับ

Function Calling ปัจจุบันเป็นแบบ Synchronous

โมเดลจะรอ

Tool Result

ก่อนตอบต่อ

ดังนั้น Function Backend ต้องเร็ว

ไม่เช่นนั้น User จะรู้สึกว่า AI หยุดนาน

⏱️ Tool Latency สำคัญมาก

สมมติ Gemini ใช้เวลา

300 ms

เลือก Function

แต่ Database API ใช้

5 seconds

Voice Assistant ก็ต้องรอประมาณนั้น

ดังนั้น Real-time Agent ต้อง Optimize

Model Latency
+
Network
+
Tool Latency
+
Audio Playback

พร้อมกัน

🔎 Gemini Live ใช้ Google Search ได้

gemini-3.1-flash-live-preview รองรับ

Grounding with Google Search

จึงสร้าง Voice AI ที่ตอบข้อมูลปัจจุบัน เช่น

User:
วันนี้มีข่าว AI อะไรสำคัญ

Gemini สามารถใช้ Search แล้วตอบด้วยเสียง

แต่ Search Tool มี Pricing เพิ่มตาม Usage

❌ Feature ที่ Gemini 3.1 Flash Live ยังไม่รองรับ

Model ปัจจุบันไม่รองรับบาง Feature เช่น

Context Caching
Code Execution
File Search
Google Maps Grounding
Image Generation
Structured Output
URL Context
Batch API

ดังนั้นอย่านำ Feature Matrix ของ gemini-3.7-flash มาคิดว่า Live Model รองรับเหมือนกันทั้งหมด

⚠️ Affective Dialog ยังไม่รองรับใน Gemini 3.1 Flash Live

Live API Platform มี Feature ด้าน Audio ขั้นสูงหลายแบบ

แต่ Model

gemini-3.1-flash-live-preview

ปัจจุบันไม่รองรับ

Affective Dialog

ตาม Model Capability ปัจจุบัน

อย่านำ Configuration จาก Live Model รุ่นอื่นมาใช้โดยตรง

⚠️ Proactive Audio ก็ยังไม่รองรับใน 3.1 Live

เช่นเดียวกัน

Proactive Audio

ยังไม่รองรับสำหรับ Gemini 3.1 Flash Live ตาม Migration Guidance ปัจจุบัน

หากเห็น Tutorial ที่เปิด Feature นี้ ต้องตรวจว่าใช้ Model ตัวไหน

🧱 Server-to-Server Architecture

วิธีที่ตรงไปตรงมาสำหรับ Backend คือ

Browser / Mobile
↓
Audio
↓
Your Server
↓
WebSocket
↓
Gemini Live API

ข้อดี

• API Key อยู่ Server
• Control Authentication ง่าย
• Logging ง่าย
• Business Tools อยู่ Backend

ข้อเสีย

• Audio วิ่งผ่าน Server เพิ่ม
• Latency เพิ่มได้
• Bandwidth Server สูงขึ้น

⚡ Client-to-Server Architecture

อีกแบบคือ

Browser / Mobile
↓
WebSocket
↓
Gemini Live API

ไม่ผ่าน Backend สำหรับ Media Stream

ข้อดีคือ

• Latency ต่ำกว่า
• Audio/Video ไม่ต้องวิ่งอ้อม Server
• Backend Bandwidth ลด

แต่ห้ามฝัง Gemini API Key ปกติใน Browser

🔐 Client-to-Server ต้องใช้ Ephemeral Token

Google แนะนำอย่างชัดเจนว่า Production Client-to-Server ควรใช้

Ephemeral Token

ไม่ใช่ Standard API Key

Architecture

Browser
↓
ขอ Ephemeral Token
↓
Your Backend
↓
สร้าง Token ด้วย Gemini API Key
↓
ส่ง Temporary Token ให้ Browser
↓
Browser เชื่อม Live API

API Key จริงไม่ออกจาก Server

🔑 ทำไมไม่ควรใส่ API Key ใน Browser

หากเขียน

const apiKey = "REAL_API_KEY";

User สามารถดูได้จาก

• Source
• DevTools
• Network
• JavaScript Bundle

แล้วนำ Key ไปใช้นอก Application

จึงไม่เหมาะกับ Production

⏳ Ephemeral Token มีอายุสั้น

ค่า Default ปัจจุบันของ Token คือประมาณ

expireTime
=
30 นาที

และเวลาที่อนุญาตให้เปิด Session ใหม่ ด้วย Token นั้น Default ประมาณ

newSessionExpireTime
=
60 วินาที

ช่วยลด Window ที่ Credential ถูกนำไปใช้ผิดวัตถุประสงค์

🔢 Ephemeral Token ใช้ได้กี่ครั้ง

ค่า Default ปัจจุบันคือ

uses = 1

หมายถึง Token ถูกออกแบบมาให้เปิด Session ตามข้อจำกัดที่กำหนด

สามารถกำหนด Policy เพิ่มได้เมื่อสร้าง Token

เหมาะกว่าการแจก Permanent Credential ให้ Client

🔒 จำกัด Token ให้ใช้กับ Model เดียวได้

Backend สามารถสร้าง Token ที่ผูก Constraint เช่น

model =
gemini-3.1-flash-live-preview

รวมถึง Session Configuration บางอย่าง

ทำให้แม้ Token หลุด ผลกระทบถูกจำกัดมากกว่า API Key หลัก

🕐 Live Session อยู่ได้นานแค่ไหน

ข้อจำกัดปัจจุบันคือ

Audio-only Session

ประมาณ

15 นาที

Audio + Video Session

ประมาณ

2 นาที

อย่างไรก็ตาม Google มี Session Management Technique สำหรับต่อ Session ได้ยาวขึ้น

ดังนั้น Production Voice App ไม่ควรสมมติว่า WebSocket เดียวจะเปิดได้ตลอดวัน

🔄 Session Management สำคัญมาก

ถ้าต้องการ Conversation เช่น

Call Center
30 นาที

แต่ Audio-only Session มี Limit 15 นาที

Application ต้องวาง

Session Resumption
+
Context Management

เพื่อรักษาการสนทนาเมื่อ Connection ถูกต่อใหม่

ไม่ควรรอให้ Connection ถูกปิดแล้วเริ่ม Conversation จากศูนย์

🧠 Context Window ของ Native Audio Live

Live API Session ปัจจุบันมี Context Window สำหรับ Native Audio Output Model ประมาณ

128k tokens

ดังนั้น Conversation ยาวมากก็ยังต้องมี Context Strategy

Summary
Session Management
Context Compression

ตาม Workflow ที่รองรับ

⚠️ Session ยาวไม่ได้แปลว่า Context ไม่จำกัด

แม้สร้างระบบ Reconnect ให้สนทนาหลายชั่วโมงได้

ก็ไม่ได้หมายความว่า Gemini จะจำทุกคำตั้งแต่เริ่มไปตลอดแบบ Unlimited

ควรมี

Conversation Summary
Important Facts
User State
Business State

เก็บใน Backend เมื่อ Session ยาวมาก

📹 Audio + Video จำกัด 2 นาทีทำอย่างไร

สำหรับ Live Vision App ที่ต้องเปิดกล้องเป็นเวลานาน ต้องวาง Session Management เพิ่ม

อีกเรื่องสำคัญคือ Gemini 3.1 เปลี่ยน Default Turn Coverage ให้รวม

Audio Activity
+
All Video Frames

ดังนั้นหากส่ง Video Frame ตลอดเวลาโดยไม่จำเป็น Cost สามารถเพิ่มได้

Google แนะนำให้พิจารณาส่ง Video เฉพาะช่วงที่เกี่ยวข้องกับ Audio Activity ตาม Use Case

💰 Gemini Live API ราคาเท่าไร

ราคาปัจจุบันของ

gemini-3.1-flash-live-preview

Paid Tier คือ

Input Text

$0.75 / 1M tokens

Input Audio

$3.00 / 1M tokens

หรือประมาณ

$0.005 / นาที

Input Image/Video

$1.00 / 1M tokens

หรือประมาณ

$0.002 / นาที

ตามการประมาณของ Google

💵 Audio Output ราคาเท่าไร

Audio Output ปัจจุบันอยู่ที่

$12 / 1M tokens

หรือประมาณ

$0.018 / นาที

ส่วน Text Output Pricing ปัจจุบันอยู่ที่

$4.50 / 1M tokens

ตาม Pricing Page

ราคาอาจเปลี่ยนได้เพราะ Model ยังเป็น Preview

🧮 ตัวอย่าง Voice Conversation 10 นาที

สมมติอย่างง่าย

User พูดรวม

5 นาที

Gemini พูดรวม

5 นาที

Input Audio

5 × $0.005
=
$0.025

Output Audio

5 × $0.018
=
$0.09

รวม Audio โดยประมาณ

$0.115

ยังไม่รวม

• Text
• Thinking
• Video
• Search
• Tools

เป็นเพียงตัวอย่างเพื่อให้เห็นโครงสร้างต้นทุน

🔎 ถ้าใช้ Google Search มีค่าเพิ่ม

Pricing ปัจจุบันสำหรับ Gemini 3.x ให้

5,000 Search Requests ฟรี/เดือน

แบบแชร์ระหว่าง Gemini 3.x ที่เกี่ยวข้อง

หลังจากนั้น

$14 / 1,000 Search Requests

และหนึ่ง User Request สามารถทำให้ Gemini สร้าง Search Query หลายครั้งได้

Voice Agent ที่ Search บ่อยจึงต้อง Monitor Tool Usage ด้วย

📊 Metric ที่ควรเก็บสำหรับ Live AI

ควรมีอย่างน้อย

sessions
session_duration
audio_input_minutes
audio_output_minutes

ด้าน Latency

speech_end_to_response
first_audio_latency
tool_latency

ด้าน Reliability

disconnects
reconnects
interruptions
errors

ด้าน Cost

audio_input_tokens
audio_output_tokens
search_calls
cost_per_session

⚡ Metric สำคัญที่สุดสำหรับ Voice คืออะไร

หนึ่งใน Metric ที่ User รู้สึกได้ชัดคือ

End of User Speech
↓
First AI Audio

ถ้ารอ

5 วินาที

Conversation จะรู้สึกไม่ธรรมชาติ

แต่ถ้าตอบภายในช่วงสั้นและ Turn-taking ดี จะรู้สึกเหมือนพูดคุยจริงมากกว่า

ดังนั้น Latency Optimization ต้องดูทั้ง VAD และ Model

🧠 อย่าเพิ่ม Thinking สูงโดยไม่มีเหตุผล

Voice Assistant ทั่วไปอาจใช้

minimal

แล้วเฉพาะคำถามยากจึงเพิ่ม Reasoning ตาม Architecture

ถ้าใช้ High Thinking ทุกประโยค เช่น

User:
สวัสดี

อาจเพิ่ม Latency และ Cost โดยไม่สร้างคุณค่า

🎯 System Instruction สำคัญกับ Voice Agent

ตัวอย่าง

คุณเป็นผู้ช่วยฝ่ายขาย
ตอบภาษาไทย
ตอบกระชับ
อย่าพูดยาวเกิน 3 ประโยค
หากไม่แน่ใจข้อมูลสินค้า
ให้เรียก Tool ตรวจสอบก่อน

Voice Prompt ควรกระชับกว่าบาง Text Application

เพราะคำตอบยาวเกินไปทำให้ Conversation ช้าและ User พูดแทรกบ่อย

🗣️ Voice Response ควรสั้นกว่าบทความ

มนุษย์อ่าน Text 10 ย่อหน้าได้

แต่การฟัง AI พูด 10 ย่อหน้าเป็นประสบการณ์ที่ไม่ดี

Voice Agent ควรใช้ Pattern

ตอบสั้น
↓
ถามว่าต้องการรายละเอียดเพิ่มไหม

เช่น

ได้ครับ สินค้านี้รองรับ Wi-Fi 7
และเหมาะกับบ้านที่มีอุปกรณ์จำนวนมาก
ต้องการให้ผมเปรียบเทียบกับรุ่นอื่นไหมครับ

ดีกว่าพูด Specification ทั้งหมดในครั้งเดียว

🔄 Turn-taking สำคัญกว่าความยาวคำตอบ

AI Voice ที่ดีควร

• ฟัง User จบ
• ตอบเร็ว
• ไม่พูดทับ
• ยอมให้ User พูดแทรก
• หยุด Audio ทันทีเมื่อถูก Interrupt

จึงต้อง Optimize

VAD
+
Audio Queue
+
Interruption
+
Latency

ไม่ใช่แค่ Prompt Quality

📱 Client-to-Server หรือ Server-to-Server เลือกอะไร

ต้องการเริ่ม Prototype ง่าย

Server-to-server มักควบคุม Security ง่าย

ต้องการ Audio/Video Latency ต่ำ

Client-to-server มีข้อได้เปรียบเพราะ Media ไม่ต้องวิ่งผ่าน Backend

แต่ต้องใช้

Ephemeral Token

เพื่อไม่เปิดเผย API Key

สำหรับ Production ควร Benchmark Architecture ทั้งสองแบบ

🛡️ Function Calling ต้อง Validate เหมือนเดิม

สมมติ Voice User บอก

ยกเลิก Order ของผมทั้งหมด

Gemini อาจเลือก

cancel_order()

Backend ยังต้องตรวจ

• Authentication
• Order Ownership
• Confirmation
• Permission
• Business Rules

Voice AI ไม่ควร Execute Critical Action จาก Intent เพียงอย่างเดียว

✅ Write Action ควรมี Confirmation

ตัวอย่าง

Gemini:
คุณต้องการยกเลิก Order 12345
ใช่หรือไม่ครับ

User:
ใช่

Backend:
Validate
↓
Execute

ดีกว่า Cancel ทันทีจากคำพูดครั้งแรก

โดยเฉพาะเมื่อ Speech Recognition สามารถตีความผิดได้

⚠️ Number Precision สำคัญกับ Voice

ข้อมูล เช่น

Order 15837

หรือ

ราคา 15,830 บาท

ควรมี Confirmation ใน Action สำคัญ

เช่น

ผมได้ยินว่า Order 15837
ถูกต้องไหมครับ

ช่วยลดความเสียหายจาก Audio Misrecognition

📞 Use Case: AI Call Center

Architecture

Telephone
↓
Telephony Provider
↓
Audio Stream
↓
Gemini Live
↓
Function Calling
↓
CRM / Order / Ticket

AI สามารถ

• รับสาย
• เข้าใจคำถาม
• ตรวจข้อมูล
• เปิด Ticket
• สรุป Call

แต่ต้องมี Human Escalation เมื่อ AI จัดการไม่ได้

🛍️ Use Case: Voice Shopping Assistant

Customer
↓
Voice
↓
Gemini Live
↓
Product Function
↓
Inventory
↓
Recommendation

User สามารถถาม

มีเราเตอร์ Wi-Fi 7 ราคาไม่เกิน 5,000 ไหม

AI ไปตรวจ Product Database แล้วตอบด้วยเสียง

🎮 Use Case: Gaming NPC

Live API เหมาะกับ

Player
↔
NPC

เพราะสามารถ

• รับ Voice
• เห็น Visual Context
• พูดตอบ
• ใช้ Game Function

ทำให้ NPC ไม่ต้องมี Dialog Tree ตายตัวทั้งหมด

👓 Use Case: Smart Glasses

Camera
+
Microphone
↓
Gemini Live
↓
Voice

User ถาม

สิ่งที่อยู่ตรงหน้าคืออะไร

ระบบส่ง Visual Frames และ Audio ไปพร้อมกัน

เหมาะกับ Next-generation Interface

🌐 Use Case: Real-time Translation

Live API Platform รองรับ Real-time Voice Translation

เหมาะกับ

Speaker A
ภาษาไทย
↓
AI
↓
Speaker B
ภาษาอื่น

อย่างไรก็ตาม Google มี Model/Feature เฉพาะด้าน Live Translation ด้วย จึงควรเลือก Model ให้ตรงงานหาก Product เน้น Translation โดยเฉพาะ

🎤 Transcription กับ Voice Agent ต่างกัน

ถ้าต้องการเพียง

Speech
↓
Text

ไม่จำเป็นต้องใช้ Full Voice Agent Model เสมอไป

ปัจจุบัน Google มี

gemini-3.5-transcribe-live

สำหรับ Low-latency Streaming Speech-to-Text

ดังนั้นเลือก

ต้องการ Transcript
→ Transcribe Live

ต้องการ AI สนทนาด้วยเสียง
→ Gemini Flash Live

⚠️ อย่าใช้ Voice Agent เพื่อ Transcribe อย่างเดียวโดยไม่เปรียบเทียบ

Specialized Transcription Model อาจเหมาะกว่าในเรื่อง

• Accuracy
• Features
• Cost
• Speaker Handling
• Vocabulary

ขึ้นอยู่กับ Requirement

Model Selection ต้องเริ่มจาก Task

🧪 ทดสอบ Voice AI อย่างไร

อย่าทดสอบเฉพาะห้องเงียบ

ควรมี Scenario

เสียงปกติ

พูดเร็ว

พูดช้า

เสียงเบา

Background Noise

พูดแทรก AI

หยุดคิดกลางประโยค

เปลี่ยนภาษา

ตัวเลข

ชื่อเฉพาะ

Network ช้า

จะเห็นปัญหา Real-world มากกว่า Demo

🔊 Test Speaker Echo

ทดสอบทั้ง

Headset

และ

Speakerphone

เพราะระบบที่ทำงานดีบน Headset อาจเกิด Echo เมื่อเปิด Loudspeaker

นี่เป็นปัญหา Audio Pipeline ไม่ใช่ Model อย่างเดียว

🌐 Test Network

Real-time Voice ต้องพึ่ง Connection ต่อเนื่อง

ควรทดสอบ

• Wi-Fi ดี
• Wi-Fi ช้า
• Mobile Network
• Packet Loss
• Network Switch
• Temporary Disconnect

แล้วดู

Reconnect Behavior

ก่อน Production

🔄 ต้องมี Reconnect Strategy

WebSocket สามารถหลุดได้จาก

• Network
• Session Limit
• Server Event
• Client Sleep
• Mobile Network Change

Application ควรมี

Disconnect
↓
Backoff
↓
Reconnect
↓
Resume Context

แทน Crash ทั้ง Conversation

⏳ Exponential Backoff

ตัวอย่าง

Retry 1
1 second

Retry 2
2 seconds

Retry 3
4 seconds

พร้อม Maximum Retry

ไม่ควร Reconnect ทุก 10 ms

เพราะจะเพิ่ม Traffic และ Load

💾 Conversation State ควรอยู่ Backend

แม้ Live API เป็น Stateful

ระบบธุรกิจควรเก็บ State สำคัญ เช่น

customer_id
order_id
current_task
confirmed_actions
conversation_summary

ใน Application เอง

อย่าให้ Gemini Session เป็น Database หลักของ Business

🔒 อย่าเก็บ Secret ใน Conversation

ไม่ควรส่ง

Database Password
API Key
Private Token

เข้า Voice Session

Function Calling Backend ควรจัดการ Secret เอง

Gemini ต้องเห็นเฉพาะ Result ที่จำเป็น

🧱 Production Architecture ที่แนะนำ

ตัวอย่าง

Web / Mobile
↓
Authentication
↓
Ephemeral Token Service
↓
Gemini Live API

                    ↘
                 Backend Tools
                    ↓
              CRM / Database

แยก

Media Path

ออกจาก

Business Action Path

ช่วยลด Latency พร้อมรักษา Security

📊 Voice Agent Dashboard

ควรมี

Sessions today
Average session duration
Audio minutes

ด้าน Experience

Response latency
Interruption rate
Disconnect rate

ด้าน AI

Tool calls
Tool errors
Search calls

ด้าน Cost

Cost/session
Cost/minute

สำหรับระบบ Real-time ของ comsiam การวัด Cost ต่อ Session มีประโยชน์มากกว่าดู Token รวมอย่างเดียว เพราะสามารถเชื่อมค่า AI กับ User หรือ Feature ที่สร้างรายได้จริงได้ง่ายกว่า

💰 คำนวณ Cost per Session

สมมติ

Average Session
=
8 นาที

User พูด

4 นาที

Gemini พูด

4 นาที

Audio Cost โดยประมาณจาก Pricing ปัจจุบัน

Input
4 × $0.005
=
$0.020

Output
4 × $0.018
=
$0.072

รวม

$0.092

ก่อนรวม Search, Video, Text และ Tools

จากนั้นคูณ

Sessions / เดือน

เพื่อวาง Budget

📉 วิธีลดค่า Live API

❶ ลดเวลาที่ Stream Audio โดยไม่จำเป็น

❷ อย่าส่ง Video ตลอดถ้าไม่ต้องใช้

❸ ใช้ Media Resolution ให้เหมาะ

❹ จำกัด Session Duration

❺ ตอบให้กระชับ

❻ ใช้ Thinking Level ต่ำสำหรับงานง่าย

❼ ใช้ Search เฉพาะเมื่อจำเป็น

❽ ปิด Session เมื่อ User ออก

❾ จำกัด Usage ตาม User Plan

❿ Monitor Cost per Session

เสียงไม่ควรถูก Stream แบบไม่มี Purpose ตลอดเวลาหาก Product ไม่ต้องการ

📹 Video Cost ต้องระวัง

Gemini 3.1 เปลี่ยน Turn Coverage ให้รวม Video Frame มากขึ้นตาม Default ของ Model

Application ที่ส่ง

1 FPS
ตลอด Session

อาจมี Video Input Cost เพิ่มอย่างต่อเนื่อง

ถ้ากล้องมีประโยชน์เฉพาะเมื่อ User ถามเกี่ยวกับสิ่งที่เห็น

ควรพิจารณาส่ง Frame ตาม Event หรือ Activity

🚦 Rate Limit ยังมีผล

Live API ไม่ใช่ Unlimited Connection

ต้องตรวจ Active Rate Limits ของ Project

โดยเฉพาะ Production ที่มี

100
1,000
10,000

Concurrent Voice Users

Capacity Planning ต้องดูทั้ง

• Concurrent Sessions
• Audio Tokens
• Tool Calls
• Cost

🧮 Infrastructure Cost ก็มี

ถ้าใช้ Server-to-server

Server ของเราต้องรับ

Audio Upload
+
Audio Download

ทุก Session

ดังนั้น Total Cost คือ

Gemini Cost
+
Server
+
Bandwidth
+
Telephony
+
Database
+
Tools

อย่าคำนวณเฉพาะ Gemini Token

📞 Call Center ต้องรวม Telephony Cost

ถ้า Voice Agent รับโทรศัพท์จริง

Cost อาจเป็น

Phone Minutes
+
Gemini Audio
+
Search
+
CRM API
+
Infrastructure

ควรคำนวณ

Cost per resolved call

ไม่ใช่เพียง Cost per Audio Minute

🧠 Cost per Successful Task สำคัญกว่า

AI Agent อาจใช้

$0.10 / call

แต่แก้ปัญหาสำเร็จ 90%

เทียบกับ Model/Configuration ที่

$0.07 / call

แต่แก้ได้เพียง 50%

ตัวที่ราคา Token ถูกกว่าอาจไม่คุ้มใน Business จริง

ควรวัด

Cost per Successful Resolution

🧪 Prototype ก่อน Production

ขั้นแรกควรสร้าง

Microphone
↓
Gemini
↓
Speaker

ให้ทำงานก่อน

ยังไม่ต้องเพิ่ม

• Search
• Functions
• CRM
• Database
• Video

เมื่อ Voice Loop เสถียรแล้วค่อยเพิ่ม Tool ทีละตัว

ลด Debug Complexity อย่างมาก

🪜 วิธีสร้าง Gemini Live AI แบบ Step by Step

❶ เลือก Use Case

Voice, Vision หรือ Multimodal

❷ เลือก Model

gemini-3.1-flash-live-preview

❸ ติดตั้ง GenAI SDK

❹ สร้าง API Key

เก็บ Server-side

❺ เปิด Live Connection

client.aio.live.connect()

❻ ตั้ง Response Modality

AUDIO

❼ Capture Microphone

เป็น PCM

❽ ส่ง Audio Chunks

ใช้ send_realtime_input

❾ รับ Audio Chunks

ผ่าน session.receive()

❿ Play Audio

ที่ 24 kHz

⓫ เปิด VAD

เริ่มจาก Automatic

⓬ Handle Interruption

หยุด Playback Queue

⓭ เปิด Transcript

ถ้าต้องการ

⓮ เพิ่ม System Instruction

กำหนด Persona/Rules

⓯ เพิ่ม Function Calling

เชื่อม Business Data

⓰ เพิ่ม Search

เฉพาะข้อมูลสด

⓱ เพิ่ม Ephemeral Token

หาก Client ต่อ Live API โดยตรง

⓲ เพิ่ม Reconnect

รองรับ Session หลุด

⓳ Monitor Latency

⓴ Monitor Cost

นี่เป็นลำดับที่ปลอดภัยกว่าการสร้าง Agent ใหญ่ทุก Feature ตั้งแต่ครั้งแรก

✅ Checklist ก่อนเปิด Gemini Live API Production

Model ID ปัจจุบัน

Preview Risk ได้ประเมินแล้ว

API Key ไม่อยู่ Browser

Client-direct ใช้ Ephemeral Token

Audio Input Format ถูก

Output Playback 24 kHz

Audio Queue ทำงาน

VAD ทำงาน

Interruption หยุดเสียงได้

Echo Cancellation มี

Transcript Policy ชัด

Session Duration รองรับ

Reconnect มี

Context Management มี

Function Arguments Validate

Write Actions มี Confirmation

Tool Timeout มี

Search Cost ถูก Monitor

Audio Minutes ถูก Monitor

User Quota มี

Error Logging มี

Privacy/Retention Policy มี

🚫 15 ข้อผิดพลาดเมื่อใช้ Gemini Live API

❶ ใช้ Model ID เก่าจาก Tutorial

❷ ฝัง API Key ใน Browser

❸ ใช้ Client-direct โดยไม่มี Ephemeral Token

❹ ส่ง Audio Format ผิด

❺ Play Output ด้วย Sample Rate ผิด

❻ รอ Audio ทั้งหมดก่อน Play

เสีย Real-time Experience

❼ ไม่ Handle VAD Interruption

AI ยังพูดต่อจาก Buffer

❽ Speaker Echo เข้า Microphone

ทำให้ False Barge-in

❾ ใช้ send_client_content ทุก Turn กับ 3.1

ควรใช้ Realtime Input หลัง Initial History

❿ ไม่ส่ง audio_stream_end เมื่อ Pause Stream

⓫ คิดว่า Session อยู่ได้ไม่จำกัด

มี Duration Limit

⓬ ส่ง Video ตลอดโดยไม่จำเป็น

Cost เพิ่ม

⓭ ให้ AI Execute Write Action โดยไม่มี Backend Validation

⓮ ไม่มี Reconnect Strategy

Network หลุดแล้ว Conversation จบ

⓯ ไม่วัด Cost per Session

Scale แล้วค่าใช้จ่ายคาดไม่ถึง

💡 ตัวอย่าง Voice Assistant ที่เหมาะกับผู้เริ่มต้น

System Instruction

คุณเป็นผู้ช่วยภาษาไทย
ตอบด้วยภาษาที่สุภาพและกระชับ
ตอบครั้งละไม่เกิน 3 ประโยค
หากไม่แน่ใจให้ถามกลับ

Architecture

Microphone
↓
Gemini Live
↓
Speaker

เมื่อพื้นฐานเสถียร

เพิ่ม

get_product()

แล้ว

get_order()

จากนั้นจึงเพิ่ม Search

อย่าทำทุกอย่างใน Version แรก

💡 ตัวอย่าง Customer Support Agent

Customer Voice
↓
Gemini Live
↓
Intent
↓
Function Calling
↓
CRM
↓
Gemini Voice Response

ถ้า User บอก

อินเทอร์เน็ตใช้ไม่ได้

AI สามารถถาม Troubleshooting

ถ้าจำเป็นต้องตรวจ Account

get_customer_service_status()

แล้วตอบตามข้อมูลจริง

💡 ตัวอย่าง AI ที่เห็นจากกล้อง

Camera Frame
+
Voice
↓
Gemini Live

User

สายเส้นนี้เสียบตรงไหน

Gemini ใช้ Visual Context ประกอบคำพูด

เหมาะกับ

• Technical Support
• Repair Assistant
• Training
• Education

💡 ตัวอย่าง Shopping Assistant

User

ผมต้องการเราเตอร์สำหรับบ้านสองชั้น

Gemini ถามรายละเอียด

พื้นที่ประมาณกี่ตารางเมตร
และมีอุปกรณ์กี่เครื่องครับ

จากนั้นเรียก Product Tool

find_products()

แล้วพูด Recommendation

นี่เป็น Voice Commerce ที่ Function Calling มีประโยชน์มาก

🔐 ข้อมูล Customer ต้องอยู่ Backend

Gemini ไม่จำเป็นต้องเห็น Database ทั้งหมด

Function

get_order_status()

ควรคืนเฉพาะ

{
  "status": "shipped",
  "estimated_delivery":
    "2026-09-04"
}

ไม่ใช่ Customer Record ทั้งหมด

ใช้ Data Minimization

🔄 Human Escalation ต้องมี

Voice AI ไม่ควรถูกออกแบบว่า

AI ต้องแก้ทุกเรื่อง

ควรมี Condition เช่น

User ขอพนักงาน
↓
Escalate

หรือ

AI ล้มเหลว 2–3 ครั้ง
↓
Escalate

หรือ Critical Issue

Payment / Account Security
↓
Human Review

ช่วย User Experience และลด Risk

📊 Metric สำหรับ Call Center

นอกจาก Latency ควรวัด

First Contact Resolution
Average Handling Time
Escalation Rate
Repeat Question Rate

แล้วเชื่อมกับ

Cost per Call

เพื่อดู Business Value จริง

📌 Live API ไม่ใช่เพียง Text-to-Speech

ถ้าต้องการ

Text
↓
Voice

อย่างเดียว TTS Model อาจเหมาะกว่า

Live API เหมาะเมื่อมี

Conversation
+
Listening
+
Interruption
+
Multimodal
+
Tools

แบบ Real-time

เลือก Technology ตาม Use Case

❓ คำถามที่พบบ่อย

Gemini Live API คืออะไร

เป็น Stateful WebSocket API สำหรับสร้าง AI แบบ Real-Time ที่สามารถรับ Text, Audio, Image และ Video พร้อมตอบกลับด้วย Audio และข้อมูลของ Session อย่างต่อเนื่อง เหมาะกับ Voice Assistant และ Multimodal Agent

Gemini Live API ใช้โมเดลไหนดี

สำหรับ Voice Conversation ปัจจุบันโมเดลหลักคือ gemini-3.1-flash-live-preview ซึ่ง Google ออกแบบเป็น Low-latency Audio-to-Audio Model สำหรับ Real-time Dialogue โดยตรง

Live API รองรับภาษาไทยไหม

รองรับ ภาษาไทยอยู่ในรายการภาษาที่ Live API รองรับ และ Native Audio Model สามารถสนทนาหลายภาษาได้ตาม Context

Audio Input ต้องเป็น Format อะไร

Live API ใช้ Raw 16-bit PCM แบบ Little-endian โดย Input Native Rate คือ 16 kHz และ Output Audio ใช้ 24 kHz

Gemini Live Session อยู่ได้นานเท่าไร

ข้อจำกัดปัจจุบันคือ Audio-only Session ประมาณ 15 นาที และ Audio+Video ประมาณ 2 นาที แต่สามารถใช้ Session Management Technique เพื่อสร้าง Conversation ที่ต่อเนื่องยาวกว่านี้ได้

ใส่ Gemini API Key ใน JavaScript Frontend ได้ไหม

ไม่ควร สำหรับ Client-to-Server Production Google แนะนำใช้ Ephemeral Token ที่ Backend สร้างให้ Client แทนการเปิดเผย API Key หลัก

🎯 สรุป

Gemini Live API เป็น API สำหรับสร้าง AI แบบ Real-Time ผ่าน Stateful WebSocket เหมาะกับ Voice Assistant, AI Call Center, Gaming NPC, Smart Glasses, Camera Assistant และ Multimodal Agent ที่ต้องรับ Audio/Video ต่อเนื่องและตอบกลับด้วย Latency ต่ำ

โมเดลหลักในปัจจุบันคือ gemini-3.1-flash-live-preview ซึ่งเป็น Low-latency Audio-to-Audio Model รองรับ Text, Image, Audio และ Video Input พร้อม Function Calling, Google Search และ Thinking แต่ยังอยู่ในสถานะ Preview

Audio Input ใช้ Raw 16-bit PCM แบบ Little-endian โดย Native Input Rate คือ 16 kHz ส่วน Output Audio ใช้ 24 kHz Application จึงต้องออกแบบ Capture และ Playback Pipeline ให้ถูกต้อง

Automatic Voice Activity Detection เปิดเป็น Default ช่วยตรวจว่า User เริ่มและหยุดพูดเมื่อไร รวมถึงรองรับ Barge-in ซึ่งทำให้ User พูดแทรก AI ได้ เมื่อเกิด Interruption Application ต้องหยุด Playback และล้าง Audio Queue ทันที

สำหรับ Client-to-Server Architecture ไม่ควรฝัง API Key ใน Browser Google แนะนำใช้ Ephemeral Token ซึ่งมีอายุสั้นและสามารถจำกัด Model, Session Configuration และจำนวนครั้งที่ใช้ได้

ข้อจำกัดปัจจุบันของ Session คือ Audio-only ประมาณ 15 นาที และ Audio+Video ประมาณ 2 นาที พร้อม Context Window 128k Tokens สำหรับ Native Audio Output Model จึงควรวาง Session Resumption และ Context Management สำหรับ Conversation ระยะยาว

ด้านต้นทุน Gemini 3.1 Flash Live ปัจจุบันมี Audio Input ประมาณ $0.005 ต่อนาที และ Audio Output ประมาณ $0.018 ต่อนาทีตามการประมาณของ Google แต่ Total Cost ยังต้องรวม Text, Video, Search, Tools และ Infrastructure ด้วย

แนวทางของ comsiam คือเริ่มจาก Voice Loop พื้นฐาน Microphone → Gemini → Speaker ให้เสถียรก่อน จากนั้นเพิ่ม VAD, Transcript, Function Calling, Search และ Session Management ทีละส่วน พร้อมวัด Latency, Cost per Session และ Successful Task จริง

เมื่อระบบโตขึ้น comsiam ควรแยก Media Streaming ออกจาก Business Action Layer โดยใช้ Ephemeral Token สำหรับ Client Connection และให้ Backend เป็นผู้ตรวจ Authentication, Permission และ Critical Action เสมอ วิธีนี้รักษาทั้ง Latency และ Security ได้ดีกว่าปล่อยให้ Voice Model ควบคุมระบบธุรกิจโดยตรง