รันเอเจนต์เสียงบนอุปกรณ์
หนึ่งไปป์ไลน์ สามงบหน่วยความจำ
เอเจนต์เสียงแบบโลคัลไม่ใช่โมเดลเดียว — แต่เป็นไปป์ไลน์สี่ส่วน: การตรวจจับกิจกรรมเสียง, การแปลงเสียงเป็นข้อความ, โมเดลภาษา และการสังเคราะห์เสียง เชื่อมกันด้วยสเตตแมชชีนที่จัดการการสลับตา ไปป์ไลน์เหมือนกันทั้งบนโทรศัพท์และแล็ปท็อป สิ่งที่เปลี่ยนคือ โมเดลไหนอยู่ในช่องไหน และนั่นถูกกำหนดด้วยสองตัวเลข: คุณมีหน่วยความจำเท่าไร และคุณกำลังป้อนตัวเร่งความเร็วตัวไหน
ตัวเลขที่ต้องจำคือทั้งลูป ไม่ใช่โมเดลเดียว: การรับรู้เสียง (STT) + การสร้างคำตอบ (LLM) + การสังเคราะห์เสียง (TTS) ทั้งหมดพอดีอยู่ในนั้น — ราว 1.2 GB บน iPhone, ราว 1.5 GB บน Galaxy S23 และต่ำกว่าราว 4 GB บน Mac ที่มีสมองสนทนาจริง ๆ
ไปป์ไลน์คือส่วนที่พกพาได้
การจัดวางอยู่ใน speech-core ในรูปสเตตแมชชีน C++ ล้วน ที่ไม่ผูกกับโมเดล: ทั้งสี่ขั้นเป็นอินเทอร์เฟซที่คุณเสียบแบ็กเอนด์ใดก็ได้ — ONNX, LiteRT, CoreML/MLX บนอุปกรณ์ หรือแม้แต่ API คลาวด์ — ไปป์ไลน์เดียวกันจึงรันตัวเรียกเครื่องมือ 270M บนโทรศัพท์ และสมอง Gemma 4 บน Mac
หนึ่งลูป สี่ขั้น เวกเวิร์ด, AEC และการเพิ่มคุณภาพเป็นขั้นก่อน VAD ที่เลือกได้; การเรียกเครื่องมือของ LLM ต่างหากที่ทำให้มัน “ลงมือทำ” ไม่ใช่แค่ตอบ
ตัวจัดวางคือ VoicePipeline ใน speech-core มันดูแลการตรวจจับตา, การขัดจังหวะ, ประวัติการสนทนา, ลูปเรียกเครื่องมือ และคิวเสียง — แต่ไม่มีโมเดลของตัวเอง ทุกขั้นสลับได้หลัง อินเทอร์เฟซ (VADInterface, STTInterface, LLMInterface, TTSInterface) ที่คุณ implement ด้วย ONNX Runtime, LiteRT, CoreML/MLX (ผ่านไลบรารีพี่น้อง speech-swift) หรือแม้แต่ API คลาวด์ ยังมีโหมดที่เบากว่า — Echo (VAD → STT → TTS) และ TranscribeOnly (VAD → STT → ข้อความ)
NPU มาก่อน และทั้งลูปพอดีในราว 1.5 GB
บนโทรศัพท์ ข้อจำกัดคือหน่วยความจำ แบตเตอรี่ และความร้อน — ไม่ใช่พลังประมวลผลดิบ เป้าหมายที่ถูกต้องคือหน่วยประมวลผลนิวรัล (NPU): Neural Engine ของ Apple บน iOS, NNAPI / Hexagon บน Android มันรันทรานส์ฟอร์เมอร์ที่ถูกควอนไทซ์ด้วยพลังงานเพียงเศษเสี้ยวของ CPU หรือ GPU และปล่อย CPU ให้ว่างสำหรับเสียงและ UI
ทำไมต้อง NPU ไม่ใช่ CPU หรือ GPU? NPU คือเครื่องยนต์ดาต้าโฟลว์ฟังก์ชันตายตัวที่สร้างมาเพื่องานเดียว — การคูณ-สะสมความแม่นยำต่ำที่โครงข่ายประสาทเทียมประกอบขึ้นมา มันเก็บน้ำหนักไว้ใน SRAM บนชิปติดกับหน่วยคำนวณ และข้ามการเฟตช์/ถอดรหัสคำสั่งและดาต้าพาธทั่วไปกว้าง ๆ ที่กินพลังงานส่วนใหญ่ของ CPU หรือ GPU การย้ายข้อมูลแพงกว่าการคำนวณมาก การเก็บทั้งสองไว้ในเครื่องจึงเป็นชัยชนะ: การคูณเมทริกซ์แบบเดิมรันด้วยพลังงานเพียงเศษเสี้ยววัตต์ — ไม่มีการลดสัญญาณนาฬิกาเพราะความร้อน ไม่กินแบต และ CPU ว่างสำหรับทุกอย่างที่เหลือ
ไปป์ไลน์มือถือจึงเป็นโมเดลเล็ก ควอนไทซ์ และเป็นมิตรกับ NPU: Silero VAD, Parakeet-EOU 120M (STT สตรีมมิ่งน้ำหนักเบาพร้อมการตรวจจับจบประโยคในตัว), FunctionGemma 270M (สมองเรียกเครื่องมือ) และ Kokoro-82M หรือ Supertonic-3 สำหรับเสียง วัดบนอุปกรณ์:
| ขั้น · โมเดล | iPhone 16 Pro (CoreML / ANE) | Galaxy S23 (LiteRT / ONNX, CPU) |
|---|---|---|
| STT · Parakeet-EOU 120M | 0.04 RTF · 297 MB | 0.21 RTF · 232 MB |
| STT · Omnilingual 300M | 0.28 RTF · 495 MB | 0.15 RTF · 831 MB |
| TTS · Kokoro-82M | 0.08 RTF · 676 MB | 0.53 RTF · 640 MB |
| TTS · Supertonic-3 99M | 0.15 RTF · 956 MB | 0.34 RTF · 832 MB |
| LLM · FunctionGemma 270M | 128 tok/s · 236 MB | 118 tok/s · 611 MB |
RTF = เวลาจริง ÷ วินาทีเสียง (ต่ำ = เร็ว; <1.0 เร็วกว่าเรียลไทม์) หน่วยความจำสูงสุดวัดแยกแต่ละโมเดล
ทุกขั้นเร็วกว่าเรียลไทม์ เมื่อโหลดพร้อมกันสำหรับเอเจนต์สด เวิร์กกิงเซ็ตที่อยู่ในหน่วยความจำคือ ราว 1.2 GB บน iPhone และ ราว 1.5 GB บน Galaxy S23 — ช่องว่างเกือบทั้งหมดคือ LLM: FunctionGemma ใช้ 236 MB บน ANE เทียบกับ 611 MB บน CPU ของ S23 iOS รันบน NPU อยู่แล้ว (จึงได้ STT 0.04 RTF และ LLM 128 tok/s); Android วันนี้เรียลไทม์บน CPU โดยเดลิเกต NNAPI/Hexagon เป็นของแถม ไม่ใช่ข้อบังคับ
ลองเลย: Examples/iOSEchoDemo รัน Parakeet + Silero + Kokoro เป็นลูปเอคโค่เต็มรูปบน iPhone; ฝั่ง Android อยู่ใน speech-android ซึ่งห่อไปป์ไลน์เดียวกัน (Examples/iOSBenchmark คือเครื่องมือเบื้องหลังตัวเลข iPhone ด้านบน)
LLM จริง ๆ ที่ขับเครื่อง — แต่ยังต่ำกว่า 4 GB
บน Mac ข้อจำกัดคลายลง: หน่วยความจำรวมที่แบ่งกันระหว่าง CPU กับ GPU Metal สี่ขั้นเดิม โมเดลใหญ่ขึ้น และที่สำคัญคือสมองสนทนาจริง ๆ แทนตัวเรียกเครื่องมือ 270M — และทั้งลูปยังพอดีในราว 4 GB
LLM คือสมอง และเป็นจุดที่ขนาดโมเดลเลิกเป็นตัวเลือก หลังทดสอบ มีสองโมเดลที่ได้งาน: บนมือถือ FunctionGemma 270M (พอสำหรับส่งการเรียกเครื่องมือ ทุกอย่างที่เอเจนต์ฝั่งโทรศัพท์ต้องการ) และบนเดสก์ท็อป Gemma 4 E2B/E4B (4-bit MLX) (การสนทนาหลายรอบและการให้เหตุผลจริง ๆ ที่อยู่ตัว ขณะที่ยังเบา) ตัวเลือกตรงกลางที่ชวนใจ — โมเดลแชตกะทัดรัดต่ำกว่า 1B — ดูเหมือนฟรีเรื่องขนาด แต่โซเซในการสนทนาหลายรอบจริง จึงตกรอบ ก้าวที่สำคัญไม่ใช่ 0.27B → 0.8B; แต่คือจากการเรียกเครื่องมือของ FunctionGemma สู่การสนทนาของ Gemma 4
ส่วนที่เหลือของสแตกก็ยกระดับด้วย: เดสก์ท็อปเปลี่ยน Parakeet-EOU ที่เบาเป็น Parakeet-TDT (หลายภาษาเต็มรูป) และ TTS ยังคงเป็น Supertonic-3 ทุกที่ — เร็ว, 44.1 kHz, เสถียร เราตั้งใจข้ามโมเดล TTS โคลนแบบ zero-shot ที่หนักกว่า; การโคลนยังไม่นิ่งพอจะอยู่ในเอเจนต์ที่เปิดตลอด
| ขั้น | มือถือ | เดสก์ท็อป (Mac / MLX) |
|---|---|---|
| VAD | Silero v6.2.1 | Silero v6.2.1 |
| STT | Parakeet-EOU (streaming) | Parakeet-TDT (multilingual) |
| LLM | FunctionGemma 270M | Gemma 4 E2B/E4B |
| TTS | Kokoro-82M / Supertonic-3 | Supertonic-3 |
| Resident set | iPhone ~1.2 GB · S23 ~1.5 GB | ~4 GB |
เส้นทางเดสก์ท็อปนั้นคือสิ่งที่ Runner Agent ส่งมอบ — แอป macOS ที่ผ่านการรับรอง รัน Mic → VAD → Parakeet-TDT → Gemma 4 → Supertonic TTS แบบโลคัลทั้งหมด ไฟล์ DMG 47 MB โดยทั้งลูปราว 4 GB บน Apple Silicon และเพราะสมองส่งการเรียกเครื่องมือ Runner ไม่ได้แค่ตอบกลับ — มัน ขับเครื่องด้วยเสียง: เปิดเบราว์เซอร์และรันการทำงานบน DOM, เปิด Telegram หรือ WhatsApp เพื่ออ่านข้อความที่เข้ามาและพิมพ์ตอบ, เปิดและควบคุมแอป — ทั้งหมดจากคำสั่งเสียง ทั้งหมดในเครื่อง นี่คือเหตุผลจริง ๆ ที่เดสก์ท็อปต้องการ Gemma 4 ไม่ใช่ตัวเรียกเครื่องมือ 270M: การลงมือทำกับเครื่องต้องใช้การให้เหตุผลจริง ไม่ใช่แค่เติมช่อง
หนึ่งไปป์ไลน์ จับคู่กับงบ
VAD → STT → LLM → TTS เหมือนกันทุกที่ ที่น่าสนใจคือจับแต่ละขั้นให้เข้ากับตัวเร่งและหน่วยความจำของอุปกรณ์
แบตและความร้อนเลือกโมเดล ANE ทำให้ iOS แทบฟรีในแง่ CPU; Android วันนี้เรียลไทม์บน CPU โดยมีที่เหลือของ NPU รออยู่
ทั้งลูปพอดีในราว 4 GB และงบนั้นซื้อการให้เหตุผลของ Gemma 4 ที่ขับเครื่องด้วยเสียง พร้อม Parakeet-TDT หลายภาษา
เสียงและสถานะการสนทนาไม่เคยออกจากอุปกรณ์ — การรับรู้ การให้เหตุผล และการสังเคราะห์ ทั้งหมดรันบนโลหะตรงหน้าคุณ