เจาะลึก Benchmark ความหน่วง API สำหรับ Voice Agents: ทำไม TTFT อย่างเดียวถึงไม่ใช่คำตอบ

Time to first token (TTFT) คือเมทริกซ์สำคัญที่นักพัฒนาใช้เลือก inference API สำหรับงานเสียง แต่มันอาจเป็นตัวเลขที่ทำให้เข้าใจผิดได้ เพราะแม้ TTFT จะระบุว่าการสร้างข้อความเริ่มขึ้นเมื่อใด แต่โมเดล text-to-speech (TTS) จะยังไม่สามารถเริ่มพูดได้จนกว่าจะได้รับประโยคย่อยที่สมบูรณ์

ช่องว่างนี้เองคือจุดตัดสินว่าเอเจนท์จะให้ความรู้สึกเหมือนมนุษย์คุยกันจริงๆ หรือเป็นแค่หุ่นยนต์ที่ถูกขัดจังหวะได้ง่าย บทความนี้จึงทำการทดสอบประสิทธิภาพของทุกเลเยอร์ใน voice stack ทั้ง LLM, speech-to-text, text-to-speech และ speech-to-speech โดยอ้างอิงข้อมูลล่าสุด ณ วันที่ 30 สิงหาคม 2026

ทำไม TTFT ถึงเป็นจุดเริ่มต้นที่ถูกและเป็นเส้นชัยที่ผิด

การสร้าง Voice agent คือการบริหารจัดการงบประมาณความหน่วง (latency budget) โดยมีโมเดลภาษาเป็นหัวใจหลัก ทุกเสี้ยววินาทีที่ล่าช้าผู้ใช้งานสามารถรับรู้ได้ทันที

นิยาม ของ TTFT คือช่วงเวลาระหว่างการส่งคำขอจนถึงการได้รับ token แรกกลับมา ซึ่งสำคัญมากสำหรับแชทบอทข้อความ แต่สำหรับงานเสียง มันเป็นเพียงตัวแปรเริ่มต้นเท่านั้น

เหตุผลสำคัญคือเรื่องกลไก เพราะโมเดล TTS ไม่สามารถสังเคราะห์เสียงแค่ครึ่งคำได้ มันต้องการประโยคที่สมบูรณ์ก่อนจะส่งเสียงออกมา LiveKit จึงนำเสนอเมทริกซ์ time-to-first-sentence (TTFS) ใน โพสต์การใช้งาน Gemma 4 โดยระบุว่า TTFS คือสิ่งที่ผู้ใช้สัมผัสได้จริง

นั่นหมายความว่าคุณต้องควบคุมสองปัจจัยพร้อมกัน: TTFT (เวลาที่เริ่มสร้างข้อความ) และ Tokens per second (ความเร็วในการต่อประโยคให้จบ) หากผู้ให้บริการรายใดเด่นเรื่อง TTFT แต่ช้าเรื่องความเร็วรวม ผลลัพธ์ที่ได้ก็จะยังไม่ลื่นไหลพอ

งบประมาณความหน่วง: ต้นทุนที่แท้จริงของการสนทนาหนึ่งรอบ

ภาพรวม voice agents ของ LiveKit แบ่งขั้นตอนการสนทนาออกเป็น STT (100–200ms), LLM (300–500ms), TTS (100–200ms) และเครือข่าย (50–150ms) ทำให้เป้าหมายในทางปฏิบัติอยู่ระหว่าง 700ms ถึง 1.2 วินาที

Kwindla Hultman Kramer ผู้ร่วมสร้าง Pipecat แนะนำให้ตั้งเป้าหมาย ค่ากลางของความหน่วงแบบ voice-to-voice ที่ 800ms โดยระบุว่าหากเกิน 1,500ms จะเริ่มให้ความรู้สึกที่ไม่เป็นธรรมชาติ

จากการทดสอบของ Daily เกี่ยวกับ voice bot ที่เร็วที่สุด พบว่ามนุษย์ปกติตอบสนองต่อการสนทนาที่ประมาณ 500ms ดังนั้นการสนทนาที่เป็นธรรมชาติในระบบ AI จึงต้องการ งบประมาณ TTFT สำหรับ LLM อยู่ที่ไม่เกิน 700ms เท่านั้น

วิธีอ่าน Benchmark ของ TTFT โดยไม่ให้ถูกหลอก

ข้อเท็จจริง 5 ประการที่ส่งผลต่อตัวเลขผลการทดสอบ:

1. รูปแบบภาระงาน: Artificial Analysis รายงานผลด้วย input 10,000 tokens ซึ่งสะท้อนการใช้งานจริงที่ต้องโหลดข้อมูลนโยบายและบุคลิกเอเจนท์ไว้ล่วงหน้า
2. ตำแหน่งเซิร์ฟเวอร์: การทดสอบจาก Google Cloud โซน us-central1-a ทำให้ผู้ให้บริการที่มีเซิร์ฟเวอร์ใกล้ตำแหน่งนี้ได้เปรียบเรื่องความหน่วงเครือข่าย
3. Reasoning Tokens: สำหรับโมเดลการใช้เหตุผล ค่า TTFT จะนับจาก token การใช้เหตุผลตัวแรก ไม่ใช่คำตอบสุดท้าย
4. การวัดจากฝั่งผู้รับ: Daily วัดผลตั้งแต่ส่งคำขอจนถึง token แรกที่ใช้งานได้จริง ไม่ใช่ตัวเลขภายในระบบของผู้ให้บริการ
5. ความผันผวน: TTFT เปลี่ยนแปลงได้ตลอดเวลาตามการปรับจูนระบบหลังบ้านของผู้ให้บริการ

เลเยอร์ที่ 1: LLM Time to First Token

ข้อมูลจาก Artificial Analysis API providers leaderboard ณ วันที่ 30 สิงหาคม 2026 แสดงค่ามัธยฐานในรอบ 72 ชั่วโมง ดังนี้

ผู้ให้บริการ	โมเดล	TTFT	ความเร็วการแสดงผล
Baseten	gpt-oss-120b (high)	0.23s	266 tok/s
DeepInfra	Nemotron 3 Ultra	0.28s	371 tok/s
Modular	Gemma 4 31B (NVFP4)	0.44s	243 tok/s
Cerebras	gpt-oss-120b (high)	0.49s	1,697 tok/s

สำหรับกลุ่มโมเดลระดับแนวหน้า (Frontier) พบข้อมูลที่น่าสนใจว่า GPT-5.6 Luna บน Amazon Bedrock (0.59s) ทำเวลาได้ดีกว่าบน API ของ OpenAI เอง (0.74s) แสดงให้เห็นว่าการเลือกโฮสต์มีความสำคัญพอๆ กับตัวโมเดล

ในด้านความเร็วรวม (Throughput) Cerebras ทำได้สูงถึง 1,697 tok/s ซึ่งเหมาะมากสำหรับงานเสียงที่ต้องการ TTFS ต่ำ ในขณะที่ Mercury 2 แม้จะเร็ว 770 tok/s แต่มี TTFT สูงถึง 3.07 วินาที ซึ่งไม่เหมาะกับงาน realtime

เลเยอร์ที่ 2: Speech-to-Text และการตรวจจับการหยุดพูด

สำหรับงานเสียง ความหน่วงของ STT วัดจาก ระยะเวลาที่ผู้ใช้หยุดพูดจนระบบรู้ตัว ตัวอย่างที่น่าสนใจคือ Deepgram Flux ที่รวมการตรวจจับจุดสิ้นสุดการพูดไว้ในตัวโมเดล ช่วยลดความหน่วงลงได้ถึง 200–600ms

ด้าน AssemblyAI Universal-Streaming ใช้การส่งข้อความถอดความแบบแก้ไขไม่ได้ (immutable) ออกมาทันที ซึ่งรายงานค่ามัธยฐานที่ 307ms ในขณะที่ LiveKit เสนอแนวทาง การสร้างคำตอบล่วงหน้า (preemptive generation) เพื่อลดขั้นตอนบนเส้นทางวิกฤต

เลเยอร์ที่ 3: Text-to-Speech Time to First Audio

นี่คือจุดที่ตัวเลขมักจะคลาดเคลื่อนจากความเป็นจริงที่สุด ElevenLabs ระบุความเร็ว Flash v2.5 ไว้ที่ 75ms แต่ระบุใน แนวคิดเรื่องความหน่วง ว่าต้องรวมค่าเครือข่ายอีก 20–200ms และการทำ buffering ของโปรแกรมเล่นเสียงอีกประมาณ 500ms

ส่วน Cartesia เคลมความหน่วงต่ำกว่า 90ms สำหรับ Sonic-3.6 ซึ่งได้รับคะแนน Elo สูงสุดใน Artificial Analysis Provider Voice arena ที่ 1,288 คะแนน ทิ้งห่าง ElevenLabs Flash v2.5 ที่ 1,083 คะแนน

เลเยอร์ที่ 4: Speech-to-Speech Time to First Audio

โมเดลกลุ่มนี้รวม STT, LLM และ TTS ไว้ด้วยกัน ซึ่งควรจะเร็วกว่า แต่ Artificial Analysis speech-to-speech leaderboard พบว่าโมเดลแบบ realtime ไม่ได้เร็วกว่าเสมอไป

โมเดล	TTFA	การใช้เหตุผลจากเสียง	ความสำเร็จของงาน
Grok Voice Think Fast 2.0 High	0.70s	97%	94.7%
OpenAI GPT-Realtime-2.1 Mini	0.81s	64%	79.6%
Gemini 3.1 Flash Live High	2.99s	97%	71.8%

Grok Voice Think Fast 2.0 High โดดเด่นที่สุดด้วย TTFA 0.70s พร้อมประสิทธิภาพงานที่สูง ในขณะที่ OpenAI ระบุว่าการปรับปรุงระบบ caching ใน ต้นเดือนกรกฎาคม 2026 ช่วยลดความหน่วงช่วงปลาย (p95 latency) ลงได้ถึง 25%

สรุปงบประมาณความหน่วงอ้างอิง

• ไพป์ไลน์แบบแยกส่วน (STT + LLM + TTS): ประมาณ 790ms – 1.3s ขึ้นอยู่กับประสิทธิภาพของแต่ละเลเยอร์
• Speech-to-Speech (โมเดลเดี่ยว): ประมาณ 750ms – 1.15s แม้ความเร็วจะใกล้เคียงกัน แต่ความสามารถในการเรียกใช้เครื่องมือ (tool calls) ยังเป็นรองแบบแยกส่วน

สิ่งที่นักพัฒนาควรทำคือการวางระบบ (Colocation) ให้เซิร์ฟเวอร์อยู่ใกล้กันมากที่สุด วัดผลที่ค่า p95 และให้ความสำคัญกับ TTFS มากกว่า TTFT เพียงอย่างเดียวเพื่อให้ได้ประสบการณ์ใช้งานที่ลื่นไหลที่สุด