# ทำไมเราจึงรันการรู้จำเสียงพูดบนเครื่องทั้งหมด: คณิตศาสตร์ของความหน่วงและความเป็นส่วนตัว

> speech-to-text บนคลาวด์แพ้ในงบประมาณที่คุณคำนวณได้บนกระดาษทิชชู นี่คือคณิตศาสตร์ของการเดินทางไป-กลับที่บังคับให้ Vext รันทั้งโมเดลเสียงและ LLM สำหรับการเก็บกวาดบนเครื่อง พร้อมกรอบการตัดสินใจคลาวด์-หรือ-โลคัลสำหรับฟีเจอร์เสียงของคุณเอง

ครั้งแรกที่ผมจับเวลามัน ผมไม่เชื่อตัวเลขนั้น ผมกดปุ่มลัดค้างไว้ พูดหนึ่งประโยค ปล่อย แล้วเริ่มจับเวลาในหัวเทียบกับจังหวะที่ข้อความปรากฏที่เคอร์เซอร์ จากนั้นผมทำสิ่งเดียวกันกับเครื่องมือบอกตามคำพูด (dictation) บนคลาวด์ การเดินทางไป-กลับบนคลาวด์ไม่ได้ช้ากว่าแค่สองเท่า ในเช้าวันที่ Wi-Fi ร้านกาแฟแย่ มันช้ากว่าหนึ่งระดับขนาด (order of magnitude) และที่แย่กว่านั้น มัน _คาดเดาไม่ได้_ — บางทีก็ 300 ms บางทีก็สองวินาที บางครั้งก็เป็นวงล้อหมุนที่จบลงด้วยความว่างเปล่า

ความแปรปรวนนั้นแหละคือเรื่องราวทั้งหมด การบอกตามคำพูดเป็นพื้นผิว UI แบบเรียลไทม์ และพื้นผิว UI แบบเรียลไทม์ตายเพราะความหน่วงส่วนหาง (tail latency) ไม่ใช่ความหน่วงเฉลี่ย ดังนั้นเมื่อเราสร้าง [Vext](https://getvext.app) — แอป voice-to-text สำหรับ macOS ของเราที่เป็นโคลสซอร์ส — การตัดสินใจรันทุกอย่างบนเครื่องไม่ใช่การตัดสินใจเชิงอุดมการณ์เรื่องความเป็นส่วนตัว มันเริ่มต้นในฐานะการตัดสินใจเรื่องความหน่วง ข้อโต้แย้งเรื่องความเป็นส่วนตัวร่วงออกมาจากตรงนั้นโดยฟรี

โพสต์นี้คือคณิตศาสตร์และสถาปัตยกรรมเบื้องหลังการตัดสินใจนั้น มันเขียนขึ้นสำหรับวิศวกรที่ยืนอยู่ที่ทางแยกเดียวกัน: คุณมีฟีเจอร์เสียงหรือ AI คุณกำลังจ้อง STT API บนคลาวด์ที่มี SDK เป็นมิตร และเสียงในหัวคุณกำลังถามว่าคุณควรจะรันโมเดลแบบโลคัลแทนไปเลยหรือเปล่า ผมอยากให้วิธีตอบคำถามนั้นด้วยตัวเลขแทนความรู้สึก

ขอชี้แจงไว้ก่อนหนึ่งข้อ Vext เองเป็นโคลสซอร์ส เครื่องมือสำหรับนักพัฒนาของ Muvon — [Octomind](https://github.com/Muvon/octomind), [Octocode](https://github.com/Muvon/octocode) และส่วนที่เหลือของสแต็กเอเจนต์ — เป็นโอเพนซอร์สภายใต้ใบอนุญาตแบบอนุญาตกว้าง และเราเขียนถึงรายละเอียดภายในของมันได้อย่างเปิดเผย Vext คือแอปเชิงพาณิชย์ที่จ่ายค่างานเปิด ดังนั้นสิ่งที่ตามมาจึงเป็นเรื่อง _แนวทาง_ และ _การแลกเปลี่ยน_ ชนิดที่วิศวกรคนใดก็ตามให้เหตุผลได้ ไม่ใช่ทัวร์นำชมต้นไม้ซอร์สโค้ดของเรา

---

## การบอกตามคำพูดคืองานที่เป็นศัตรูกับความหน่วง

ฟีเจอร์เสียงส่วนใหญ่ยอมผ่อนปรน ถอดเสียงพอดแคสต์ข้ามคืนน่ะหรือ ไม่มีใครจ้องนาฬิกา สร้างบันทึกการประชุมหลังจบสาย ประมวลผลสองสามวินาทีก็มองไม่เห็น เหล่านี้คืองานแบบแบตช์ และสำหรับงานแบบแบตช์ คลาวด์มักเป็นคำตอบที่ถูก — คุณได้ GPU ของคนอื่น ทีม ops ของคนอื่น และความหน่วงก็แค่ไม่สำคัญเพราะไม่มีมนุษย์รออยู่บนเส้นทางวิกฤต

การบอกตามคำพูดคือสิ่งตรงข้าม มนุษย์กำลังจ้องเคอร์เซอร์ กลางความคิด รอให้คำปรากฏ ลูปการโต้ตอบคือ: พูด ปล่อย _คาดหวังข้อความเดี๋ยวนี้_ ทุกมิลลิวินาทีระหว่าง "ปล่อย" กับ "ข้อความปรากฏ" คืออากาศตายที่ผู้ใช้รู้สึกได้ในมือ และต่างจากการโหลดหน้าเว็บ ไม่มีวงล้อหมุนที่ทำให้มันยอมรับได้ — แบบจำลองในใจคือ "ฉันกำลังพิมพ์ด้วยเสียง" และการพิมพ์ไม่มีการบัฟเฟอร์

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

ดังนั้นงบประมาณจึงคับแคบ และงบประมาณคือสิ่งที่ต้องให้เหตุผลก่อน

---

## คณิตศาสตร์ของการเดินทางไป-กลับ

มาสร้างงบประมาณความหน่วงของคลาวด์อย่างซื่อสัตย์ จากชิ้นส่วนที่คุณหลีกเลี่ยงไม่ได้

คำขอ STT บนคลาวด์ต้องทำสิ่งต่อไปนี้เป็นอย่างน้อย ก่อนที่คำเดียวจะกลับมา:

1. **จับและเข้ารหัส** เสียงบนเครื่อง
2. **สร้างหรือใช้การเชื่อมต่อซ้ำ** — การจับมือ TLS หากเย็น หรืออย่างน้อยก็ต้นทุนของซ็อกเก็ตที่คงไว้
3. **อัปโหลด** ไบต์เสียงข้ามเครือข่าย
4. **เข้าคิว** ฝั่งผู้ให้บริการจนกว่า worker จะหยิบขึ้นมา
5. **รันการอนุมาน (inference)** บนฮาร์ดแวร์ของพวกเขา
6. **ทำให้เป็นอนุกรมและดาวน์โหลด** ผลลัพธ์กลับมายังคุณ

นี่คือส่วนที่ผู้คนประเมินต่ำไป: ขั้นตอน 2, 3, 4 และ 6 เป็นค่าโสหุ้ยล้วน ๆ ที่ไม่เกี่ยวอะไรกับว่าโมเดลดีแค่ไหน มันคือภาษี และมันคือขั้นตอนที่มีความแปรปรวนแย่ที่สุด

เวลาเดินทางไป-กลับของเครือข่ายเพียงอย่างเดียวก็แทบไม่เคยเป็นมิตรกับคุณ ภูมิภาคเดียวกัน การเชื่อมต่ออุ่น เครือข่ายดี คุณอาจเห็น RTT ในระดับสิบมิลลิวินาทีต้น ๆ แต่ "ภูมิภาคเดียวกัน" กำลังแบกงานหนักอยู่ตรงนั้น ผู้ใช้ในกรุงเทพฯ ที่ยิงไปยังเอนด์พอยต์ใน us-east จ่าย RTT ไปสองสามร้อยมิลลิวินาทีก่อนที่สิ่งมีประโยชน์ใด ๆ จะเกิดขึ้น ในการเดินทางไป-กลับครั้งเดียว — และการจับมือ TLS แบบเย็นคือหลายรอบการเดินทาง เพิ่มความแออัด เพิ่มเครือข่ายโรงแรมที่ไม่เสถียร เพิ่มความลึกของคิวผู้ให้บริการในชั่วโมงเร่งด่วน แล้ว p99 ของคุณก็หลุดออกจาก p50 ของคุณโดยสิ้นเชิง

นี่คืองบประมาณเชิงแนวคิด ผมจงใจไม่อ้างตัวเลขแข็ง ๆ ราวกับว่ามันถูกวัดในสภาพแวดล้อมของคุณ — มันขึ้นกับเครือข่ายและผู้ให้บริการของคุณ — แต่สิ่งที่สำคัญคือ _รูปทรง_:

```text
Cloud STT latency = encode
                  + connection_setup        # 0 if warm, 1-3 RTT if cold
                  + upload_time             # audio_bytes / uplink_bandwidth
                  + provider_queue_wait     # the variance killer
                  + inference_time
                  + download_time
                  + deserialize

On-device STT latency = capture_to_buffer
                      + inference_time       # on local Neural Engine / GPU
```

ดูสิว่าเส้นทางบนเครื่อง _ไม่มี_ อะไร ไม่มีการตั้งการเชื่อมต่อ ไม่มีการอัปโหลด ไม่มีคิว ไม่มีการดาวน์โหลด คอลัมน์เครือข่ายทั้งหมดยุบลงเหลือศูนย์ สิ่งที่เหลือคือการจับบวกการอนุมาน และบน Apple Silicon การอนุมานเร็วพอที่พจน์ที่ครอบงำงบประมาณคลาวด์ — เครือข่าย — ก็แค่ไม่อยู่ในสมการ

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

และโมเดลเองก็ไม่ใช่ของอ่อน โมเดลเสียงที่เราใช้เป็นค่าเริ่มต้น — Parakeet ของ NVIDIA จากตระกูล NeMo — รันเร็วกว่าเรียลไทม์มาก ๆ บนชิปซีรีส์ M ราวสองระดับขนาดเร็วกว่าเรียลไทม์เมื่อแมปลงบน Neural Engine เมื่อการถอดเสียงเร็วกว่าคำพูดที่ผลิตมันมากขนาดนั้น พจน์การอนุมานในงบประมาณของคุณก็เล็กลงเมื่อเทียบกับเสียงที่คุณต้องรอให้พูดออกมาอยู่แล้ว คอขวดเลิกเป็นโมเดลและกลายเป็นฟิสิกส์: คุณถอดเสียงประโยคหนึ่งไม่ได้ก่อนที่คนจะพูดมันจบ

---

## ความเป็นส่วนตัวเป็นผลข้างเคียง แล้วมันก็กลายเป็นประเด็นหลัก

เราเลือกบนเครื่องเพื่อความหน่วง แล้วเราก็สังเกตว่าเราซื้ออะไรมาโดยบังเอิญ

ถ้าเสียงไม่เคยออกจากเครื่อง ก็ไม่มีเสียงให้รั่ว ให้หมายเรียก ให้เจาะ ให้เก็บไว้ หรือให้นำไปฝึก นี่ไม่ใช่ _นโยบาย_ ความเป็นส่วนตัว — นโยบายคือคำสัญญาว่าเซิร์ฟเวอร์ _อาจ_ กำลังทำอย่างอื่นอยู่ มันคือ _สถาปัตยกรรม_ ความเป็นส่วนตัว: ข้อมูลไม่มีที่อื่นให้ไปในเชิงกายภาพ ไม่มีถังบันทึกเสียงของคุณบนโครงสร้างพื้นฐานของใคร เพราะการบันทึกถูกประมวลผลและทิ้งไปห่างจากไมโครโฟนไม่กี่เซนติเมตร

สำหรับเครื่องมือบอกตามคำพูด สิ่งนี้สำคัญกว่าที่ดูแรกเริ่ม เพราะ _สิ่งที่_ ผู้คนบอกตามคำพูด ลองดูการใช้งานของคุณเองสักวัน คุณบอกรหัสผ่านที่คุณกำลังรีเซ็ต คุณบอกสถาปัตยกรรมของระบบที่อยู่ภายใต้ NDA คุณบอกเนื้อความของข้อความถึงทนาย ถึงหมอ ถึงผู้ร่วมก่อตั้งกลางการเข้าซื้อกิจการ ไมโครโฟนบนเครื่องของนักพัฒนาเล็งไปที่วัตถุดิบดิบที่อ่อนไหวที่สุดบางส่วนในชีวิตของเขา และท่าทีเริ่มต้นของเครื่องมือเสียงส่วนใหญ่คือสตรีมทั้งหมดนั้นไปยังบุคคลที่สามเพื่อประมวลผล

ยังมีมิติของการปฏิบัติตามข้อกำหนด (compliance) ด้วย และมันไม่นามธรรม "เสียงไม่เคยออกจากเครื่อง" คือประโยคที่ปิดทิกเก็ตการตรวจสอบความปลอดภัยได้มากมาย ไม่มีข้อตกลงการประมวลผลข้อมูลให้ต่อรอง ไม่มีรายชื่อผู้ประมวลผลย่อยให้ตรวจสอบ ไม่มีคำถามการถ่ายโอนข้อมูลข้ามพรมแดน ไม่มีพื้นผิวการแจ้งเตือนการละเมิดสำหรับข้อมูลเสียง เพราะไม่มีข้อมูลเสียงบนเซิร์ฟเวอร์ใดให้ถูกเจาะ สำหรับทีมที่พยายามส่งเครื่องมือเข้าสู่สภาพแวดล้อมที่ถูกกำกับ "มันรันแบบโลคัล" มักเป็นความแตกต่างระหว่างอนุมัติกับอยู่ระหว่างการพิจารณาไม่มีกำหนด

เวอร์ชันที่ซื่อสัตย์: เราคงไม่ทำให้ความเป็นส่วนตัวเป็นพาดหัว ถ้าคณิตศาสตร์ความหน่วงไม่ได้ชี้ไปทางเดียวกัน แต่มันชี้ และเมื่อคุณตัดสินใจแล้วว่าเสียงอยู่บ้านด้วยเหตุผลด้านประสิทธิภาพ การปฏิเสธที่จะส่ง fallback บนคลาวด์ที่ลบล้างสิ่งนั้นเงียบ ๆ คือการตัดสินใจที่ง่ายและถูกต้อง

---

## สองโมเดล หนึ่งไปป์ไลน์ โลคัลทั้งคู่

speech-to-text ให้คำกับคุณ คำไม่ใช่สิ่งที่ผู้ใช้ต้องการ

สิ่งที่เขาพูดคือ "เอ่อ คือพื้นฐานแล้วเราต้องย้ายตรรกะ retry ไปไว้ที่ที่ worker นะ รู้ไหม ตัวที่เอ่อ จัดการ webhooks น่ะ" สิ่งที่เขาอยากให้วางคือ "ย้ายตรรกะ retry ไปไว้ที่ worker ที่จัดการ webhooks" การตัดคำเติม การแก้การออกตัวผิด และการขึ้นรูปผลลัพธ์เป็นงานที่ต่างจากการถอดเสียง และมันเป็นงานทางภาษา ไม่ใช่งานทางเสียงพูด ดังนั้นไปป์ไลน์จึงมีสองสเตจ และการตัดสินใจเชิงสถาปัตยกรรมที่น่าสนใจคือการเก็บ _ทั้งสอง_ ไว้บนเครื่อง

ในเชิงแนวคิดมันคือการส่งต่อ:

```text
   audio ──▶ [ speech model ]  ──▶  raw transcript
                (Parakeet)            "uh so basically we need to..."
                                            │
                                            ▼
                              [ small local LLM ]  ──▶  clean text
                                  (Gemma 3 4B, MLX)    "Move the retry logic..."
                                            │
                              ┌─────────────┼─────────────┐
                              ▼             ▼             ▼
                          cleanup      translation   summary
```

สเตจหนึ่งคือโมเดลเสียงเฉพาะทาง: เล็ก เร็ว วัตถุประสงค์เดียว ปรับให้เหมาะกับสิ่งเดียว สเตจสองคือ LLM อเนกประสงค์ขนาดเล็ก — เราใช้ Gemma 3 4B เป็นค่าเริ่มต้น (เลือก Qwen 3, LLaMA 3.2 หรือ Phi-3.5 ก็ได้) รันผ่านเฟรมเวิร์ก MLX ของ Apple บน GPU — ทำการเก็บกวาดทางภาษา และโมเดล _เดียวกัน_ ด้วยคำสั่งที่ต่างกัน จัดการการแปลสด ๆ และการสรุปการประชุม หนึ่งโมเดล สามงาน สลับด้วยพรอมต์แทนที่จะส่งไบนารีสามตัวที่ต่างกัน

เหตุผลที่การแยกสองโมเดลนี้เป็นรูปทรงที่ถูกต้อง: แต่ละสเตจได้เก่งในงานของมัน คุณไม่อยากให้โมเดลเสียงของคุณพยายามเขียนร้อยแก้วใหม่ด้วย และคุณไม่อยากให้ LLM ทั่วไปพยายามทำการสร้างแบบจำลองทางเสียง เฉพาะทาง-แล้ว-ทั่วไปคือการแบ่งแยกที่สะอาด และมันทำให้แต่ละโมเดลเล็กพอจะใส่ในหน่วยความจำและรันเร็ว โมเดล end-to-end ขนาดยักษ์ที่ทำทั้งสองอย่างจะช้ากว่า หิวกว่า และให้เหตุผลยากกว่า — และคุณจะเสียความสามารถในการสลับโมเดลเก็บกวาดอย่างอิสระจากตัวรู้จำ

การเก็บสเตจสองไว้โลคัลคือส่วนที่ถูกล่อใจให้ข้าม โมเดลเสียงต้องโลคัลเพื่อความหน่วง แน่นอนว่าการเก็บกวาดน่าจะเป็นการเรียก API สั้น ๆ ไปยังโมเดลคลาวด์ใหญ่ ๆ ได้สิ? ได้ — แล้วคุณก็โยนคุณสมบัติความเป็นส่วนตัวทั้งหมดทิ้งไปสำหรับสเตจที่จัดการเวอร์ชันที่ _อ่านออกได้ชัดที่สุด_ ของคำพูดผู้ใช้ การถอดเสียงดิบนั้นรก ข้อความที่เก็บกวาดแล้วคือความคิดที่ชัด ยกมาอ้างได้ ก่อรูปสมบูรณ์ นั่นคือสิ่งที่คุณอยากส่งไปเซิร์ฟเวอร์น้อยที่สุดพอดี ถ้าสเตจสองไปคลาวด์ การที่สเตจหนึ่งเป็นโลคัลก็ไม่ได้ซื้ออะไรให้คุณเลย ดังนั้นทั้งคู่จึงอยู่บ้าน

---

## จุดที่การรันบนเครื่องเริ่มเจ็บ

ผมคงโกหกถ้าขายมันว่าฟรี การอนุมานบนเครื่องมีต้นทุนจริง และการแสร้งว่าไม่มีคือวิธีที่คุณส่งของที่สวยในเดโมแต่ทุกข์ทรมานในสนามจริง นี่คือจุดที่มันกัด

**ขนาดโมเดลและการดาวน์โหลด** โมเดลโลคัลคือไฟล์ และโมเดลโลคัลที่ดีคือไฟล์ใหญ่ การเปิดครั้งแรกต้องดึงมันมา — ดาวน์โหลดหลายกิกะไบต์สำหรับน้ำหนักที่คอมไพล์แล้วของโมเดลเสียง บวกดาวน์โหลดขนาดพอ ๆ กันสำหรับ LLM — และนั่นคือประสบการณ์การรันครั้งแรกที่คุณต้องออกแบบรอบ ๆ เพราะ "ดาวน์โหลด 3 GB ก่อนพูดคำแรกได้" คือ onboarding ที่โหดร้ายถ้าคุณจัดการแย่ ฝั่งคลาวด์ไม่มีสิ่งเทียบเท่า โมเดลของพวกเขาอุ่นอยู่บนฮาร์ดแวร์ของพวกเขาแล้ว

**แรงกดดันหน่วยความจำ** ทั้งสองโมเดล โหลดและพักอยู่ในหน่วยความจำ กิน RAM บนเครื่อง 64 GB ใครจะสน บนแล็ปท็อปรุ่นพื้นฐานที่ยังรันเบราว์เซอร์เก้าสิบแท็บ IDE หนึ่งตัว และแอป Electron สามตัว ตอนนี้คุณกำลังแย่งหน่วยความจำกับทุกอย่างที่ผู้ใช้เปิดแล็ปท็อปมาเพื่อทำจริง ๆ คุณต้องจงใจเรื่องว่าจะโหลดโมเดลเมื่อไร ปล่อยเมื่อไร และคุณยอมตั้งโมเดลใหญ่แค่ไหนเป็นค่าเริ่มต้น

**คุณรับมรดกพื้นฮาร์ดแวร์** STT บนคลาวด์รันบน GPU ดาต้าเซ็นเตอร์ตัวเดียวกันทั้งสำหรับโทรศัพท์เรือธงและแล็ปท็อปอายุห้าปี บนเครื่อง ประสิทธิภาพของคุณ _คือ_ ซิลิคอนของผู้ใช้ เราต้องการ Apple Silicon ก็เพราะ Neural Engine และหน่วยความจำรวม (unified memory) คือสิ่งที่ทำให้คณิตศาสตร์ความหน่วงทำงาน บนฮาร์ดแวร์เก่ากว่าหรืออ่อนกว่า ข้อโต้แย้งทั้งหมดอ่อนลง คุณกำลังเดิมพันบนพื้นฮาร์ดแวร์ และคุณกำลังตัดทุกคนที่อยู่ต่ำกว่ามันออก

**Quantization คือปุ่มหมุนที่มีเขี้ยว** เพื่อให้โมเดลใส่ได้และรันเร็ว คุณ quantize มัน — แทนน้ำหนักด้วยจำนวนบิตที่น้อยลง แลกความแม่นยำเล็กน้อยกับความเร็วและหน่วยความจำมาก ทำได้ดีก็แทบฟรี ดันไกลเกินไปก็ตายด้วยความผิดเล็ก ๆ พันจุด: การถอดเสียงเพี้ยนนิดตรงนี้ การเก็บกวาดบิดเบือนเล็กน้อยตรงนั้น การเลือกระดับ quantization คือการเลือกจุดบนเส้นโค้งความแม่นยำ-เทียบ-ทรัพยากร และมันคือการตัดสินใจทางวิศวกรรมจริง ไม่ใช่ช่องติ๊ก

**คุณส่งโมเดล ดังนั้นคุณเป็นเจ้าของการอัปเดต** ผู้ให้บริการคลาวด์ปรับโมเดลของตัวเองให้ดีขึ้นและผู้ใช้ทุกคนได้รับมันเงียบ ๆ โมเดลโลคัลของคุณดีขึ้นเมื่อคุณส่งการอัปเดตแอปและผู้ใช้ดาวน์โหลดน้ำหนักใหม่ คุณแลก "การปรับปรุงต่อเนื่องของคนอื่น" กับ "การควบคุมและความคาดเดาได้" ซึ่งเป็นการแลกที่ถูกต้องสำหรับเครื่องมือที่ต้องทำงานเหมือนกันเป๊ะแบบออฟไลน์บนเครื่องบิน — แต่มันก็เป็นการแลก

ไม่มีข้อใดในเหล่านี้ที่จมแนวทางบนเครื่องสำหรับเครื่องมือบอกตามคำพูดแบบโต้ตอบ ชัยชนะด้านความหน่วงและความเป็นส่วนตัวใหญ่เกินไป แต่ทุกข้อคือเหตุผลที่ฟีเจอร์ _ที่ต่างออกไป_ อาจเลือกคลาวด์อย่างถูกต้อง

---

## กรอบการตัดสินใจที่คุณใช้ได้จริง

ดังนั้นนี่คือสิ่งที่จะนำไปสู่ฟีเจอร์เสียงของคุณเอง คำถามไม่เคยเป็น "บนเครื่องดีกว่าไหม" มันคือ "คอลัมน์ต้นทุนไหนที่งานของฉันสนใจ" แมปฟีเจอร์ของคุณกับสิ่งนี้:

| สัญญาณ                   | เอนไปทางบนเครื่อง                        | เอนไปทางคลาวด์                    |
| ------------------------ | ---------------------------------------- | --------------------------------- |
| **แบบจำลองการโต้ตอบ**    | เรียลไทม์ มนุษย์รอผลลัพธ์                | แบตช์ ประมวลผลเบื้องหลัง          |
| **ความทนต่อความหน่วง**   | รู้สึกถึงความหน่วงส่วนหาง; p99 สำคัญ     | วินาทีก็โอเค; ไม่มีใครจ้อง        |
| **ความอ่อนไหวของข้อมูล** | เสียงเป็นส่วนตัว ถูกกำกับ หรือภายใต้ NDA | เนื้อหาสาธารณะหรือแชร์แล้ว        |
| **ข้อกำหนดออฟไลน์**      | ต้องทำงานบนเครื่องบิน / เครือข่ายแย่     | ออนไลน์ตลอดเป็นข้อสมมติที่ปลอดภัย |
| **ความถี่ต่อการใช้**     | หลายครั้งต่อวัน ต่อผู้ใช้                | นาน ๆ ครั้ง                       |
| **ฮาร์ดแวร์เป้าหมาย**    | คุณกำหนดพื้นฮาร์ดแวร์สมัยใหม่ได้         | ต้องรันได้ทุกที่ รวมอุปกรณ์อ่อน   |
| **ความสดของโมเดล**       | พฤติกรรมคาดเดาได้ เหมือนกัน ออฟไลน์ ชนะ  | การปรับปรุงเงียบ ๆ ต่อเนื่อง ชนะ  |

อ่านตารางจากบนลงล่าง ถ้าคำตอบของคุณกระจุกในคอลัมน์ซ้าย — โต้ตอบ ไวต่อความหน่วง เป็นส่วนตัว บ่อย บนฮาร์ดแวร์ที่มีความสามารถ — คุณมีปัญหาทรงการบอกตามคำพูด และบนเครื่องน่าจะเป็นสถาปัตยกรรมที่ถูกต้องมาก แม้จะงานมากกว่า ถ้าพวกมันกระจุกขวา — แบตช์ ทนความหน่วง ไม่อ่อนไหว นาน ๆ ครั้ง ต้องรันได้ทุกที่ — คลาวด์กำลังช่วยคุณ และการไปโลคัลคือความเจ็บที่ทำกับตัวเอง

ความผิดพลาดที่ผมเห็นบ่อยที่สุดคือการมองว่านี่เป็นการตัดสินใจระดับโลกครั้งเดียวสำหรับทั้งผลิตภัณฑ์ มันไม่ใช่ มันเป็นรายฟีเจอร์ เครื่องมือหนึ่งรันการบอกตามคำพูดแบบโต้ตอบบนเครื่องเพื่อความหน่วงได้แน่นอน และยังส่งมอบการบันทึกที่จัดเก็บความยาวสองชั่วโมงให้งานแบตช์บนคลาวด์ข้ามคืนได้ เพราะงานสองชนิดนั้นนั่งคนละคอลัมน์ เราตั้งทุกอย่างเป็นโลคัลโดยค่าเริ่มต้นใน Vext เพราะงานของเราบังเอิญอยู่ฝั่งซ้าย — แต่กรอบ ไม่ใช่ข้อสรุป คือส่วนที่ควรค่าแก่การขโมยไป

---

## สิ่งที่ผมจะบอกตัวเองเมื่อปีที่แล้ว

ถ้าผมส่งโน้ตหนึ่งกลับไปยังเวอร์ชันของผมที่กำลังจ้อง SDK STT บนคลาวด์ที่เป็นมิตรได้: SDK ที่เป็นมิตรกำลังขายการอนุมานให้คุณและซ่อนภาษีไว้ คุณภาพโมเดลแทบไม่เคยเป็นปัญหา คอลัมน์เครือข่าย — การตั้งค่า การอัปโหลด คิว การดาวน์โหลด และความแปรปรวนที่อยู่ในทั้งสี่ — นั่นแหละคือปัญหา และมันคือปัญหาที่คุณจ่ายในทุกการเปล่งเสียง ตลอดไป ในจังหวะที่มนุษย์กำลังรอซอฟต์แวร์ของคุณด้วยมือของเขาพอดี

บนเครื่องลบคอลัมน์นั้นทิ้งทั้งก้อนและมอบสถาปัตยกรรมความเป็นส่วนตัวให้คุณเป็นผลข้างเคียง มันคิดราคาคุณเป็นการดาวน์โหลดก้อนใหญ่ วินัยหน่วยความจำบ้าง พื้นฮาร์ดแวร์ และการตัดสินใจ quantization สำหรับงานแบบโต้ตอบ อ่อนไหว ความถี่สูง นั่นคือการแลกที่ผมจะทำทุกครั้ง — และทำไปแล้ว

คำนวณคณิตศาสตร์ของฟีเจอร์ของคุณเองก่อนเอื้อมไปหา SDK กระดาษทิชชูถูกกว่าการเขียนใหม่

— Don

---

_[Vext](https://getvext.app) คือแอป voice-to-text แบบโคลสซอร์สที่รันบนเครื่องของ Muvon สำหรับ Apple Silicon — การรู้จำเสียงพูดและ LLM สำหรับการเก็บกวาดรันแบบโลคัลทั้งคู่ และเสียงของคุณไม่เคยออกจาก Mac เครื่องมือสำหรับนักพัฒนาของ Muvon รวมถึง [Octomind](https://github.com/Muvon/octomind) เป็นโอเพนซอร์ส สถาปัตยกรรมและการแลกเปลี่ยนที่อธิบายไว้ที่นี่เป็นแพตเทิร์นทางวิศวกรรมทั่วไป ไม่ใช่การพาชมรายละเอียดภายในของ Vext_