ครั้งแรกที่ผมจับเวลามัน ผมไม่เชื่อตัวเลขนั้น ผมกดปุ่มลัดค้างไว้ พูดหนึ่งประโยค ปล่อย แล้วเริ่มจับเวลาในหัวเทียบกับจังหวะที่ข้อความปรากฏที่เคอร์เซอร์ จากนั้นผมทำสิ่งเดียวกันกับเครื่องมือบอกตามคำพูด (dictation) บนคลาวด์ การเดินทางไป-กลับบนคลาวด์ไม่ได้ช้ากว่าแค่สองเท่า ในเช้าวันที่ Wi-Fi ร้านกาแฟแย่ มันช้ากว่าหนึ่งระดับขนาด (order of magnitude) และที่แย่กว่านั้น มัน คาดเดาไม่ได้ — บางทีก็ 300 ms บางทีก็สองวินาที บางครั้งก็เป็นวงล้อหมุนที่จบลงด้วยความว่างเปล่า
ความแปรปรวนนั้นแหละคือเรื่องราวทั้งหมด การบอกตามคำพูดเป็นพื้นผิว UI แบบเรียลไทม์ และพื้นผิว UI แบบเรียลไทม์ตายเพราะความหน่วงส่วนหาง (tail latency) ไม่ใช่ความหน่วงเฉลี่ย ดังนั้นเมื่อเราสร้าง Vext — แอป voice-to-text สำหรับ macOS ของเราที่เป็นโคลสซอร์ส — การตัดสินใจรันทุกอย่างบนเครื่องไม่ใช่การตัดสินใจเชิงอุดมการณ์เรื่องความเป็นส่วนตัว มันเริ่มต้นในฐานะการตัดสินใจเรื่องความหน่วง ข้อโต้แย้งเรื่องความเป็นส่วนตัวร่วงออกมาจากตรงนั้นโดยฟรี
โพสต์นี้คือคณิตศาสตร์และสถาปัตยกรรมเบื้องหลังการตัดสินใจนั้น มันเขียนขึ้นสำหรับวิศวกรที่ยืนอยู่ที่ทางแยกเดียวกัน: คุณมีฟีเจอร์เสียงหรือ AI คุณกำลังจ้อง STT API บนคลาวด์ที่มี SDK เป็นมิตร และเสียงในหัวคุณกำลังถามว่าคุณควรจะรันโมเดลแบบโลคัลแทนไปเลยหรือเปล่า ผมอยากให้วิธีตอบคำถามนั้นด้วยตัวเลขแทนความรู้สึก
ขอชี้แจงไว้ก่อนหนึ่งข้อ Vext เองเป็นโคลสซอร์ส เครื่องมือสำหรับนักพัฒนาของ Muvon — Octomind, Octocode และส่วนที่เหลือของสแต็กเอเจนต์ — เป็นโอเพนซอร์สภายใต้ใบอนุญาตแบบอนุญาตกว้าง และเราเขียนถึงรายละเอียดภายในของมันได้อย่างเปิดเผย Vext คือแอปเชิงพาณิชย์ที่จ่ายค่างานเปิด ดังนั้นสิ่งที่ตามมาจึงเป็นเรื่อง แนวทาง และ การแลกเปลี่ยน ชนิดที่วิศวกรคนใดก็ตามให้เหตุผลได้ ไม่ใช่ทัวร์นำชมต้นไม้ซอร์สโค้ดของเรา
การบอกตามคำพูดคืองานที่เป็นศัตรูกับความหน่วง
ฟีเจอร์เสียงส่วนใหญ่ยอมผ่อนปรน ถอดเสียงพอดแคสต์ข้ามคืนน่ะหรือ ไม่มีใครจ้องนาฬิกา สร้างบันทึกการประชุมหลังจบสาย ประมวลผลสองสามวินาทีก็มองไม่เห็น เหล่านี้คืองานแบบแบตช์ และสำหรับงานแบบแบตช์ คลาวด์มักเป็นคำตอบที่ถูก — คุณได้ GPU ของคนอื่น ทีม ops ของคนอื่น และความหน่วงก็แค่ไม่สำคัญเพราะไม่มีมนุษย์รออยู่บนเส้นทางวิกฤต
การบอกตามคำพูดคือสิ่งตรงข้าม มนุษย์กำลังจ้องเคอร์เซอร์ กลางความคิด รอให้คำปรากฏ ลูปการโต้ตอบคือ: พูด ปล่อย คาดหวังข้อความเดี๋ยวนี้ ทุกมิลลิวินาทีระหว่าง "ปล่อย" กับ "ข้อความปรากฏ" คืออากาศตายที่ผู้ใช้รู้สึกได้ในมือ และต่างจากการโหลดหน้าเว็บ ไม่มีวงล้อหมุนที่ทำให้มันยอมรับได้ — แบบจำลองในใจคือ "ฉันกำลังพิมพ์ด้วยเสียง" และการพิมพ์ไม่มีการบัฟเฟอร์
ส่วนที่โหดร้ายคือนี่เป็นต้นทุนต่อการเปล่งเสียงแต่ละครั้ง คุณไม่ได้จ่ายมันครั้งเดียว คุณจ่ายมันในทุก ๆ การบอกตามคำพูด ห้าสิบหรือร้อยครั้งต่อวันสำหรับผู้ใช้หนัก บทลงโทษ 700 ms ที่คุณคงไม่มีวันสังเกตเห็นบนการโหลดหน้าเว็บ กลายเป็นความแตกต่างตลอดทั้งวันทำงาน ระหว่างเครื่องมือที่หายไปในสายงานกับเครื่องมือที่คุณต้องสู้ด้วย
ดังนั้นงบประมาณจึงคับแคบ และงบประมาณคือสิ่งที่ต้องให้เหตุผลก่อน
คณิตศาสตร์ของการเดินทางไป-กลับ
มาสร้างงบประมาณความหน่วงของคลาวด์อย่างซื่อสัตย์ จากชิ้นส่วนที่คุณหลีกเลี่ยงไม่ได้
คำขอ STT บนคลาวด์ต้องทำสิ่งต่อไปนี้เป็นอย่างน้อย ก่อนที่คำเดียวจะกลับมา:
- จับและเข้ารหัส เสียงบนเครื่อง
- สร้างหรือใช้การเชื่อมต่อซ้ำ — การจับมือ TLS หากเย็น หรืออย่างน้อยก็ต้นทุนของซ็อกเก็ตที่คงไว้
- อัปโหลด ไบต์เสียงข้ามเครือข่าย
- เข้าคิว ฝั่งผู้ให้บริการจนกว่า worker จะหยิบขึ้นมา
- รันการอนุมาน (inference) บนฮาร์ดแวร์ของพวกเขา
- ทำให้เป็นอนุกรมและดาวน์โหลด ผลลัพธ์กลับมายังคุณ
นี่คือส่วนที่ผู้คนประเมินต่ำไป: ขั้นตอน 2, 3, 4 และ 6 เป็นค่าโสหุ้ยล้วน ๆ ที่ไม่เกี่ยวอะไรกับว่าโมเดลดีแค่ไหน มันคือภาษี และมันคือขั้นตอนที่มีความแปรปรวนแย่ที่สุด
เวลาเดินทางไป-กลับของเครือข่ายเพียงอย่างเดียวก็แทบไม่เคยเป็นมิตรกับคุณ ภูมิภาคเดียวกัน การเชื่อมต่ออุ่น เครือข่ายดี คุณอาจเห็น RTT ในระดับสิบมิลลิวินาทีต้น ๆ แต่ "ภูมิภาคเดียวกัน" กำลังแบกงานหนักอยู่ตรงนั้น ผู้ใช้ในกรุงเทพฯ ที่ยิงไปยังเอนด์พอยต์ใน us-east จ่าย RTT ไปสองสามร้อยมิลลิวินาทีก่อนที่สิ่งมีประโยชน์ใด ๆ จะเกิดขึ้น ในการเดินทางไป-กลับครั้งเดียว — และการจับมือ TLS แบบเย็นคือหลายรอบการเดินทาง เพิ่มความแออัด เพิ่มเครือข่ายโรงแรมที่ไม่เสถียร เพิ่มความลึกของคิวผู้ให้บริการในชั่วโมงเร่งด่วน แล้ว p99 ของคุณก็หลุดออกจาก p50 ของคุณโดยสิ้นเชิง
นี่คืองบประมาณเชิงแนวคิด ผมจงใจไม่อ้างตัวเลขแข็ง ๆ ราวกับว่ามันถูกวัดในสภาพแวดล้อมของคุณ — มันขึ้นกับเครือข่ายและผู้ให้บริการของคุณ — แต่สิ่งที่สำคัญคือ รูปทรง:
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" การตัดคำเติม การแก้การออกตัวผิด และการขึ้นรูปผลลัพธ์เป็นงานที่ต่างจากการถอดเสียง และมันเป็นงานทางภาษา ไม่ใช่งานทางเสียงพูด ดังนั้นไปป์ไลน์จึงมีสองสเตจ และการตัดสินใจเชิงสถาปัตยกรรมที่น่าสนใจคือการเก็บ ทั้งสอง ไว้บนเครื่อง
ในเชิงแนวคิดมันคือการส่งต่อ:
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 คือแอป voice-to-text แบบโคลสซอร์สที่รันบนเครื่องของ Muvon สำหรับ Apple Silicon — การรู้จำเสียงพูดและ LLM สำหรับการเก็บกวาดรันแบบโลคัลทั้งคู่ และเสียงของคุณไม่เคยออกจาก Mac เครื่องมือสำหรับนักพัฒนาของ Muvon รวมถึง Octomind เป็นโอเพนซอร์ส สถาปัตยกรรมและการแลกเปลี่ยนที่อธิบายไว้ที่นี่เป็นแพตเทิร์นทางวิศวกรรมทั่วไป ไม่ใช่การพาชมรายละเอียดภายในของ Vext
