เจาะลึก Time to First Token (TTFT) สำหรับ Voice Agents
วิเคราะห์เกณฑ์ความหน่วงของ Voice Agents พร้อมตัวเลข TTFT และ TTFS จากการทดสอบของ LiveKit และ Artificial Analysis ประจำเดือนสิงหาคม 2026
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การสนทนาด้วยเสียงที่ลื่นไหลต้องมีเวลาตอบสนองรวมต่ำกว่า 1,500 มิลลิวินาที โดยมีงบประมาณสำหรับ TTFT ประมาณ 700 มิลลิวินาที
- เกณฑ์ชี้วัดหลักสำหรับผู้ใช้คือ Time to First Sentence (TTFS) เนื่องจากโมเดล Text-to-Speech ต้องประมวลผลให้ครบประโยคจึงจะสร้างเสียงได้
- LiveKit เผยผลทดสอบ Gemma 4 31B ทำเวลา TTFT ได้ 192 มิลลิวินาที และ TTFS ที่ 354 มิลลิวินาที เมื่อรันผ่าน SGLang
- การเลือกผู้ให้บริการโฮสติ้งและโครงสร้างพื้นฐานส่งผลอย่างมากต่อความเร็ว เช่น GPT-5.6 Luna บน Amazon Bedrock ใช้เวลา 0.59 วินาที แต่บน OpenAI API ใช้เวลา 0.74 วินาที
เอเจนต์เสียง (Voice Agent) เปรียบเสมือนงบประมาณด้านความหน่วง (Latency Budget) ที่มีโมเดลภาษาขนาดใหญ่อยู่ข้างใน โดยทุกขั้นตอนการประมวลผลจะกินเวลาเป็นมิลลิวินาทีที่ผู้ใช้สามารถสัมผัสได้ทันที Time to First Token (TTFT) คือช่วงเวลานับตั้งแต่การส่งคำขออินฟอเรนซ์จนกระทั่งได้รับโทเคนแรกกลับมา ซึ่ง IBM ให้คำนิยามว่าเป็นจุดเปลี่ยนผ่านของระบบจากสถานะว่าง (Idle) ไปสู่การทำงานที่มองเห็นได้ชัดเจน
สำหรับการแชทข้อความทั่วไป TTFT ถือเป็นหัวใจสำคัญเกือบทั้งหมด แต่สำหรับระบบเสียงแล้ว มันเป็นเพียงส่วนหนึ่งในสมการเท่านั้น เนื่องจากเหตุผลทางกลไกของโมเดลแปลงข้อความ Text-to-Speech ที่ไม่สามารถสังเคราะห์เสียงครึ่งคำได้ จำเป็นต้องรอให้ครบทั้งประโยคก่อนจึงจะผลิตเสียงออกมาได้ ทาง LiveKit จึงได้เรียกตัวชี้วัดนี้ว่า Time-to-First-Sentence (TTFS) และระบุในโพสต์เผยแพร่ระบบ Gemma 4 ว่า TTFS คือสิ่งที่ผู้ใช้งานรู้สึกได้จริง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
แนวทางนี้ทำให้ผู้พัฒนามีตัวปรับแต่งหลักสองส่วน คือ TTFT ที่ควบคุมเวลาเริ่มสร้าง และ Tokens per Second ที่ควบคุมความเร็วจนกระทั่งประโยคแรกเสร็จสมบูรณ์ หากผู้ให้บริการชนะด้านหนึ่งแต่แพ้doesอีกด้าน ระบบก็จะไม่รู้สึกว่าทำงานได้รวดเร็ว ภาพรวมของวงจรการทำงานจาก LiveKit ระบุว่า STT ใช้เวลาประมาณ 100–200 มิลลิวินาที, LLM ใช้ 300–500 มิลลิวินาที, TTS ใช้ 100–200 มิลลิวินาที และเครือข่ายผ่าน WebRTC อีก 50–150 มิลลิวินาที ส่งผลให้เป้าหมายการทำงานปลายทางอยู่ที่ 700 มิลลิวินาทีถึง 1.2 วินาที
Kwindla Hultman Kramer ผู้ร่วมสร้าง Pipecat แนะนำให้ตั้งเป้าหมายความหน่วงเสียงต่อเสียงไว้ที่มัธยฐาน 800 มิลลิวินาที และยอมรับได้สูงสุด 1,500 มิลลิวินาทีสำหรับระบบ Proof of Concept โดยแบ่งสัดส่วนออกเป็นสี่ส่วน ส่วนละประมาณ 200 มิลลิวินาที ได้แก่ การขนส่งและการประมวลผลสื่อ, STT รวมการตรวจจับจุดสิ้นสุดวลี, การอนุมาน LLM และ TTS ส่วน Daily ได้ระบุเกณฑ์มาตรฐานของมนุษย์ไว้ว่า เวลาตอบสนองปกติในการสนทนาคือประมาณ 500 มิลลิวินาที และการเว้นช่วงนานเกิน 800 มิลลิวินาทีจะเริ่มรู้สึกว่าผิดธรรมชาติ
"Natural conversation needs voice-to-voice under 1,500ms, which works out to roughly 700ms of TTFT budget for a text-mode LLM inside a transcription-to-LLM-to-voice harness."
Daily
การทำความเข้าใจเรื่องความหน่วงในระบบเสียงเอเจนต์มีความซับซ้อนกว่าการประมวลผลข้อความทั่วไป เนื่องจากต้องอาศัยการทำงานประสานกันของหลายโมเดล (STT, LLM, TTS) การปรับปรุงความเร็วในส่วนของ LLM อย่างเดียวจึงไม่เพียงพอ หากโมเดลแปลงเสียงพูดไม่สามารถสังเคราะห์ประโยคได้อย่างรวดเร็ว การเลือกใช้สถาปัตยกรรมและการปรับแต่งอินฟอเรนซ์ เช่น การใช้ speculative decoding จึงกลายเป็นกุญแจสำคัญในการลดเวลา TTFS ลง
ข้อเท็จจริงเกี่ยวกับการทดสอบจาก Artificial Analysis ในเดือนมีนาคม 2026 ระบุว่าการเปลี่ยนแปลงรูปแบบภาระงานมาใช้พรอมต์อินพุตขนาด 10,000 โทเคนส่งผลให้ทั้ง TTFT และความเร็วเอาต์พุตเพิ่มขึ้น เนื่องจากเอเจนต์ในระบบจริงต้องรองรับนโยบาย, บุคลิกภาพ, กฎการส่งต่อ และสคีมาเครื่องมือที่ซับซ้อน นอกจากนี้ การทดสอบจากเซิร์ฟเวอร์ในโซน us-central1-a ของ Google Cloud และความแปรปรวนระหว่างรอบการรันก็เป็นปัจจัยสำคัญที่ผู้พัฒนาต้องนำมาพิจารณา
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ที่มา: MarkTechPost
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น