ค่าความหน่วงของ Text-to-Speech คือช่วงเวลาตั้งแต่ส่งข้อความจนได้ยินเสียงแรก สำหรับระบบเสียงพูดหรือคำบรรยายสด ช่วงเวลานี้ส่งผลต่อประสบการณ์ใช้งานอย่างมาก Speechify API มีหลายวิธีที่ช่วยลดความหน่วงได้ บทความนี้สรุป 9 วิธี ตั้งแต่การเลือกโมเดลไปจนถึงการใช้การเชื่อมต่อซ้ำ
หากต้องการรายละเอียดเชิงวิศวกรรมของแต่ละข้อ อ่านเพิ่มเติมได้ที่ speechify.ai ในโพสต์ changelog โดยเริ่มจากคำอธิบายเรื่อง Streaming TTS ที่ speechify.ai/streaming-tts
จะเลือกโมเดล TTS ที่เร็วที่สุดได้อย่างไร?
สำหรับงานภาษาอังกฤษ แนะนำ Simba 3.2 ซึ่งออกแบบมาสำหรับการสตรีมและให้เวลาเสียงแรกต่ำที่สุด ส่วนข้อความหลายภาษา Simba 3.0 รองรับพารามิเตอร์ภาษาเพิ่มเติมโดยยังคงความเร็วได้ดี ขณะที่โมเดลเวอร์ชันเก่าเหมาะกับงานที่ต้องรองรับระบบเดิม แต่จะมีความหน่วงมากกว่า
เลือกโมเดลให้เหมาะกับลักษณะงาน หากต้องการเสียงตอบสนองไว ให้ใช้ Simba 3.2 แต่ถ้าเป็นงานแบบแบตช์ เช่น หนังสือเสียง จะใช้โมเดลใดก็ได้เพราะไม่ต้องตอบสนองแบบเรียลไทม์
ควรใช้การสตรีมหรือรอไฟล์เต็ม?
ควรใช้การสตรีมเมื่อผู้ใช้ต้องฟังแบบสด ใช้ POST /v1/audio/stream แล้วเล่นเสียงทันทีที่ได้รับ โดยไม่ต้องรอไฟล์สมบูรณ์ API จะส่งเสียงมาเป็นช่วง ๆ ทำให้ผู้ใช้ได้ยินเสียงแรกเร็วขึ้น: https://docs.speechify.ai/build/api-reference/v1/audio/stream
หากต้องการ time stamp หรือ word mark ในสตรีม สามารถใช้ endpoint POST /v1/audio/stream/with-timestamps: https://docs.speechify.ai/build/api-reference/v1/audio/stream/with-timestamps
Edge deployment ช่วยได้หรือไม่?
ช่วยลดเวลาเดินทางของข้อมูลได้ โค้ดที่รันบน edge ซึ่งดึงข้อมูลจาก API แล้วสตรีมเสียงกลับ จะอยู่ใกล้ผู้ใช้มากกว่า อย่างไรก็ตาม ความหน่วงสุดท้ายยังขึ้นอยู่กับระยะทางถึงเซิร์ฟเวอร์ API ไม่ว่าจะมาจากฝั่งผู้ใช้ แอป หรือ edge
รูปแบบเอาต์พุตใดเร็วที่สุด?
เลือกฟอร์แมตที่ฝั่ง client เล่นได้ทันทีโดยไม่ต้องแปลง สำหรับระบบโทรศัพท์ให้ใช้ ulaw_8000 ซึ่งตรงกับฟอร์แมตของ Twilio ส่วนบนเว็บ การใช้ PCM หรือฟอร์แมตที่ตัวเล่นรองรับโดยตรงจะช่วยลดขั้นตอนการถอดรหัส
ยิ่งมีการแปลงรูปแบบระหว่าง API กับลำโพงน้อยเท่าไร เวลาก็ยิ่งลดลงเท่านั้น
Concurrency ช่วยลดความรู้สึกว่ารอนานได้อย่างไร?
สังเคราะห์เสียงแบบขนานเมื่อจำเป็นต้องจัดการข้อความสั้นหลายชุดพร้อมกัน เช่น สร้างคำบรรยาย 10 บรรทัดพร้อมกันย่อมดีกว่าทำทีละรายการ API รองรับ request พร้อมกันอยู่แล้ว ดังนั้นจึงควรใช้ batch เมื่อเหมาะกับลักษณะงาน
เหตุใดจึงควร reuse การเชื่อมต่อ?
เปิด HTTP connection เพียงครั้งเดียวแล้วใช้งานต่อเนื่อง เพราะการทำ TLS handshake และตั้งค่าการเชื่อมต่อใหม่ทุกครั้งจะกินเวลา โดยเฉพาะเมื่อมีคำขอจำนวนมาก การ reuse connection ช่วยลดเวลาส่วนนี้ต่อ request ได้
ถ้าแคชข้อความเดิม จะช่วยได้หรือไม่?
ควรแคชไฟล์เสียงสำหรับข้อความที่ใช้ซ้ำ เช่น คำทักทายหรือข้อความคงที่ใน UI โดยเก็บคลิปเสียงที่สร้างไว้และผูกกับข้อความ เสียง และโมเดล แล้วเรียกใช้ซ้ำ บทความเกี่ยวกับ cache TTS จะอธิบายแนวทางนี้ไว้อย่างละเอียด
จะตัดแต่งข้อความอินพุตอย่างไร?
ข้อความที่สั้นกว่าจะสังเคราะห์ได้เร็วกว่า ลบข้อความที่ระบบสร้างให้อัตโนมัติ ตัดบทนำที่ไม่จำเป็น และส่งเฉพาะเนื้อหาที่ต้องใช้ ยิ่งส่งข้อความสั้นลงเท่าไร ก็ยิ่งได้ยินเสียงแรกเร็วขึ้นเท่านั้น
การซิงก์เวลาแต่ละคำช่วยปกปิดความหน่วงได้หรือไม่?
ช่วยได้ ใช้การสตรีมผ่าน POST /v1/audio/stream/with-timestamps เพื่อรับ word mark ไปพร้อมกับเสียง จากนั้นแสดงคำบนหน้าจอทีละคำ ผู้ใช้จะเห็นความคืบหน้าในขณะที่เสียงส่วนที่เหลือยังโหลดอยู่ ทำให้ประสบการณ์โดยรวมรู้สึกเร็วขึ้น แม้ความยาวเสียงรวมจะไม่เปลี่ยน
คำถามที่พบบ่อย
เป้าหมายความหน่วงของ TTS ที่เหมาะสมคือเท่าไร?
สำหรับ voice agent ควรตั้งเป้าให้ได้ยินเสียงแรกภายในไม่กี่ร้อยมิลลิวินาที ซึ่งการสตรีมช่วยให้ทำได้ง่ายขึ้น ส่วนงานแบบแบตช์มักให้ความสำคัญกับเวลารวมมากกว่าเวลาเสียงแรก
การสตรีมมีค่าใช้จ่ายเพิ่มหรือไม่?
ไม่มี คุณจ่ายตามจำนวนอักขระที่สังเคราะห์ การสตรีมเปลี่ยนเพียงรูปแบบการส่งข้อมูลเท่านั้น ไม่ได้เพิ่มราคา
โมเดลไหนเร็วที่สุดบน Speechify?
Simba 3.2 คือโมเดลที่แนะนำสำหรับภาษาอังกฤษ รองรับการสตรีมและให้เวลาเสียงแรกต่ำที่สุด
ควรแคชไฟล์เสียง TTS หรือไม่?
ควรแคชเมื่อมีข้อความเดิมถูกใช้ซ้ำ โดยแยกแคชตามข้อความ อินพุต เสียง และโมเดล แล้วนำคลิปเดิมกลับมาใช้แทนการสร้างใหม่ทุกครั้ง
