4 คะแนน โดย GN⁺ 2026-02-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อิมพลีเมนเทชัน บน Rust ที่สามารถรัน การรู้จำเสียงพูดแบบสตรีมมิง ได้ทั้งในสภาพแวดล้อมเนทีฟและเบราว์เซอร์ โดยใช้เฟรมเวิร์ก Burn ML
  • โมเดลอ้างอิงจาก Mistral Voxtral Mini 4B Realtime และทำ inference ฝั่งไคลเอนต์แบบสมบูรณ์ ในแท็บเบราว์เซอร์ผ่าน WASM + WebGPU
  • โมเดลแบบ quantized Q4 GGUF (2.5GB) สามารถรันในเบราว์เซอร์ได้ ส่วน โมเดล F32 บน SafeTensors (9GB) ทำงานในสภาพแวดล้อมเนทีฟ
  • ใช้เทคนิคอย่าง sharding, การโหลด 2 ขั้นตอน, การประมวลผลเทนเซอร์แบบอะซิงก์ เพื่อแก้ข้อจำกัดของเบราว์เซอร์ (การจัดสรร 2GB, พื้นที่แอดเดรส 4GB, ข้อจำกัดการอ่านจาก GPU ฯลฯ)
  • เผยแพร่ภายใต้ไลเซนส์ Apache-2.0 และสามารถทดลองเดโมแบบเรียลไทม์ได้บน HuggingFace Spaces

ภาพรวม Voxtral Mini 4B Realtime (Rust)

  • อิมพลีเมนต์ โมเดล Mistral Voxtral Mini 4B Realtime อย่างครบถ้วนด้วย Rust และเฟรมเวิร์ก Burn ML
    • สามารถรันการรู้จำเสียงพูดแบบสตรีมมิงได้ทั้งใน สภาพแวดล้อมโลคัลและเบราว์เซอร์
    • เวอร์ชันเบราว์เซอร์ทำงานฝั่งไคลเอนต์โดยใช้ WASM (WebAssembly) และ WebGPU
  • โมเดล quantized Q4 GGUF (ประมาณ 2.5GB) รันในเบราว์เซอร์ได้ ขณะที่ โมเดล F32 SafeTensors (ประมาณ 9GB) ใช้ในสภาพแวดล้อมเนทีฟ
  • มี เดโมแบบเรียลไทม์ บน HuggingFace Spaces

สถาปัตยกรรม

  • เสียงอินพุต (16kHz mono) จะถูกแปลงเป็น Mel spectrogram ก่อนส่งผ่าน encoder (32 ชั้น) และ decoder (26 ชั้น) เพื่อแปลงเป็นข้อความ
  • ขั้นตอนการประมวลผลหลัก
    • Mel spectrogram → encoder (32 ชั้น, 1280 มิติ) → Conv downsample 4x → adapter (3072 มิติ) → decoder (GQA 32Q/8KV)
  • มี เส้นทาง inference 2 แบบ
    • F32 (native): อิง SafeTensors, ใช้การคำนวณเทนเซอร์ของ Burn
    • Q4 GGUF (native + browser): quantized แบบ GGUF Q4_0, ใช้ custom WGSL shader

วิธีแก้ปัญหาเชิงเทคนิคเพื่อรันบนเบราว์เซอร์

  • เพื่อรันโมเดล 4B ในเบราว์เซอร์ จึงแก้ ข้อจำกัด 5 ประการ
    1. ข้อจำกัดการจัดสรร 2GB → ใช้ ShardedCursor อ่านจากหลายบัฟเฟอร์
    2. ข้อจำกัดพื้นที่แอดเดรส 4GB → โหลดแบบ 2 ขั้นตอน (parse แล้วปล่อย reader จากนั้นค่อย finalize)
    3. embedding table ขนาด 1.5GiB → ใช้ Q4 embedding บน GPU + lookup แถวบน CPU
    4. ห้ามอ่านแบบ synchronous จาก GPU → ใช้ into_data_async().await
    5. ข้อจำกัด workgroup 256 → จำกัดขนาดเคอร์เนลด้วยแพตช์ cubecl-wgpu

การแก้ padding สำหรับ Q4

  • mistral-common ปกติจะ padding เสียงด้วย โทเคนเงียบ 32 ตัว แต่ครอบคลุมได้เพียงครึ่งเดียวของ prefix 38 ตัวใน decoder
  • โมเดล quantized Q4_0 จึงเกิด ข้อผิดพลาดเมื่ออินพุตเริ่มด้วยเสียงทันที
  • เพื่อแก้ปัญหานี้ จึง ขยาย padding เป็น 76 โทเคน (= 38 decoder token) เพื่อเติมทั้ง prefix ให้เป็นความเงียบ

การ build และการทดสอบ

  • ตัวเลือกการ build
    • ค่าเริ่มต้น: cargo build --release (wgpu + native-tokenizer)
    • สำหรับเบราว์เซอร์: wasm-pack build --target web --features wasm
  • การทดสอบ
    • รองรับ unit test และ integration test ที่ใช้ GPU
    • การทดสอบ E2E บนเบราว์เซอร์ทำด้วย Playwright + สภาพแวดล้อม GPU จริง
    • ใน CI จะข้ามการทดสอบที่เกี่ยวข้อง เพราะไม่มี GPU

การเตรียมโมเดลและ sharding

  • เพื่อรองรับข้อจำกัด ArrayBuffer ของเบราว์เซอร์ (ไม่เกิน 512MB) จึง แบ่งไฟล์ GGUF ออกเป็น shard
    split -b 512m models/voxtral-q4.gguf models/voxtral-q4-shards/shard-  
    
  • dev server และการทดสอบ E2E จะค้นหา shard โดยอัตโนมัติ

ไลเซนส์และทรัพยากร

  • ไลเซนส์ Apache-2.0
  • มี เดโมบนเบราว์เซอร์ บน HuggingFace Spaces: TrevorJS/voxtral-mini-realtime

1 ความคิดเห็น

 
GN⁺ 2026-02-11
ความคิดเห็นจาก Hacker News
  • ถ้าคนสนใจ @antirez ได้ปล่อย เวอร์ชัน C ของ Voxtral Mini 4B แล้ว
    ดูได้ที่ antirez/voxtral.c
    ผมทำ เวอร์ชัน fork ของตัวเอง และกำลังเพิ่ม อิมพลีเมนต์ CUDA กับฟีเจอร์ปรับปรุงอีกเล็กน้อย
    ใช้งานได้ค่อนข้างดี แต่ยังไม่เร็วเท่า API endpoint ของ Mistral AI

    • อยากรู้ว่าถ้าจะเริ่มศึกษาพวก โค้ด inference หรืออิมพลีเมนต์ CUDA แบบนี้ ควรเริ่มเรียนจากตรงไหน
      คิดว่าน่าจะต้องอ่านและเรียนรู้จากเอกสารที่เกี่ยวข้องก่อน ไม่ใช่ลงมือเขียนโค้ดทันที เลยอยากได้ไกด์ที่พอใช้อ้างอิงได้
    • ยังมีอิมพลีเมนต์ Mistral อีกตัวคือ mistral.rs
      ผมไม่แน่ใจว่าต่างกันอย่างไร แต่ดูเหมือนฝั่งนี้จะได้รับเสียงตอบรับจากชุมชนดีกว่า
  • ลองใช้เดโมแล้ว ต้อง กดปุ่ม Mic เพื่ออัดเสียง แล้วกด “Stop and transcribe” ถึงจะได้ผลลัพธ์
    เลยสงสัยว่าจะทำเป็น โหมดเรียลไทม์จริง ๆ ที่ขึ้นคำบรรยายภายใน 1–2 วินาทีหลังผู้ใช้พูดได้ไหม
    เดโมเซิร์ฟเวอร์ของ Hugging Face ทำแบบนั้นอยู่ โดยใช้โมเดลขนาด 8.5GB บน GPU

    • ด้วยความเร็วตอนนี้ คงทำเรียลไทม์เต็มรูปแบบได้ยาก
      แต่ถ้าทำ UI แบบ ring buffer ก็พอจำลองประสบการณ์คล้ายกันได้
      ผมใช้ Whisper แบบนี้บน Flutter และรัน GGUF inference ของ llama.cpp ด้วย Dart
      แม้แต่บน M4 Max ก็ยังไม่เรียลไทม์ ส่วน Whisper บนอุปกรณ์หลังปี 2022 ผ่าน ONNX ก็เกือบเรียลไทม์
      สำหรับฮาร์ดแวร์ฝั่งผู้บริโภค ผมคิดว่า ความเร็วในการ inference สำคัญกว่าการเพิ่มความแม่นยำ (WER)
  • นี่แหละคือทิศทางที่ควรมีจริง ๆ สำหรับ โอเพนโมเดลแบบ on-premises
    ทั้งผู้ใช้และองค์กรต่างก็ชอบรูปแบบนี้ ดูเหมือน Mistral จะจับจุดนี้ได้ดี

    • Mistral อาจกำลังเจอกับช่วงเวลาแบบ จุดเปลี่ยนของ RedHat
      ยุคของโอเพนโมเดลน่าจะน่าตื่นเต้นขึ้นอีกมาก
  • งานเจ๋งมาก ถ้าเชื่อมกับ handy.computer ได้ก็น่าจะดี และอยากรู้ว่ามีแผนรองรับ streaming ไหม

    • ผมกำลังจะพอร์ตสิ่งนี้ไปเป็น transcribe-rs เพื่อให้ใช้กับ Handy ได้
      เวอร์ชันแรกน่าจะยังไม่รองรับ streaming
    • ผมลองใช้ Handy แล้ว รู้สึกว่า เบากว่าและ UI สะอาดกว่า โซลูชันก่อนหน้าเยอะ
      เลยได้รู้จักเครื่องมือดี ๆ และตอนนี้ก็รู้สึกว่าควรมีการรองรับ Voxtral จริง ๆ
  • ผมไม่ได้รู้เรื่องโมเดลมากนัก แต่เคยลอง Nvidia Parakeet แล้วทำงานได้ดีมาก
    เลยสงสัยว่าโมเดลขนาด 9GB แบบนี้ ถ้าจะใช้แบบเรียลไทม์จำเป็นต้องโหลดค้างไว้ในหน่วยความจำ GPU ตลอดไหม หรือจะโหลดใหม่ทุกครั้งก็ได้

    • ผมก็ใช้ Parakeet V3 เหมือนกัน และมันให้ สมดุลระหว่างความเร็วกับความแม่นยำ ดีที่สุด
      ประโยคสั้น ๆ แทบจะได้ผลลัพธ์ทันที ส่วนประโยคยาวใช้เวลา 1–3 วินาที
      การเสียความแม่นยำไปเล็กน้อยแทบไม่มีความหมายสำหรับการใช้งานคุยกับ AI
      ตอนนี้แอปโอเพนซอร์สชื่อ Handy (ลิงก์) ใช้ Parakeet V3 อยู่ และอิมพลีเมนต์แบบ C ช้ากว่ามาก
      สำหรับ STT แล้ว ความเร็ว คือแกนหลักของ UX
    • ผมรัน เซิร์ฟเวอร์ ollama อยู่ และการโหลดโมเดลค่อนข้างเร็ว
      อาการหน่วงจะเกิดตอนโหลดโมเดลใหม่หรือสลับ context ขนาดใหญ่
      ส่วนใหญ่โมเดลถูกโหลดค้างไว้แล้ว ดังนั้นตัวแปรหลักคือ tokens per second
      ถ้าเป็นสถาปัตยกรรมซับซ้อนที่มีหลายเอเจนต์ จะช้าลงเพราะการสลับ context
      prompt caching ของ ik_llama ช่วยเพิ่มความเร็วในกรณีแบบนี้ได้
      สรุปคือ ถ้าไม่ได้เปลี่ยนโมเดลหรือ context บ่อย ๆ ดีเลย์จากการโหลดน้ำหนักโมเดลก็ไม่ใช่ปัญหาใหญ่
  • ผมสงสัยว่าโครงสร้างที่ให้แท็บเบราว์เซอร์หนึ่งแท็บ ดาวน์โหลดโมเดล 2.5GB แล้วเดี๋ยวก็ลบทิ้ง มันมีประสิทธิภาพจริงหรือ
    ถึงอินเทอร์เน็ตกับพื้นที่เก็บข้อมูลจะถูกลง แต่ก็ยังรู้สึกว่าวิธีนี้สิ้นเปลือง
    การประมวลผลฝั่งไคลเอนต์เป็นเรื่องดี แต่โมเดลขนาดนี้ น่าจะเหมาะกับการรันบนเซิร์ฟเวอร์มากกว่า

    • ในสภาพแวดล้อมเบราว์เซอร์ปัจจุบัน โมเดลโลคัลคงยังยากจะเป็นกระแสหลัก
      แต่ถ้ามี มาตรฐานเว็บ API สำหรับ LLM สถานการณ์อาจเปลี่ยนไป
      ถ้าเบราว์เซอร์สื่อสารกับโมเดลที่ผู้ใช้เลือกและ abstract การ inference แบบโลคัล/รีโมตได้ เว็บไซต์ต่าง ๆ ก็จะใช้โมเดลร่วมกันได้
    • เทคโนโลยีใหม่ย่อมมีคนบ่นเสมอ
      ถ้าในปี 2026 โมเดลโลคัลขนาด 2.5GB ยังถือว่าเป็นปัญหา งั้นจะมีอะไรที่เรียกว่าปลอดภัยแล้วบ้าง
      เส้นทางมันพัฒนาจาก ทำไม่ได้ → รวมศูนย์ → รันแบบโลคัล และถ้าราคาของสิ่งนั้นคือ 2.5GB ก็ถือว่ายอมรับได้มากพอ
  • การรันในเบราว์เซอร์ก็ดูน่าสนใจ แต่ผมไม่อยากอยู่ในโลกที่ เว็บไซต์ดาวน์โหลด 2.5GB อยู่เบื้องหลัง

    • ผมเคยเปรียบเทียบ Gemini Nano (โมเดล AI ที่ฝังอยู่ใน Chrome) กับโซลูชันแบบเซิร์ฟเวอร์
      Nano จะ เก็บใน local storage และแชร์ข้ามเว็บไซต์ได้ ดังนั้นดาวน์โหลดครั้งเดียวก็พอ
      ส่วน Mistral ดูเหมือนจะไม่เป็นแบบนั้น
      สถิติที่เกี่ยวข้องสรุปไว้ในบล็อกโพสต์นี้
    • แน่นอนว่าผมก็ไม่อยากให้มันดาวน์โหลดอัตโนมัติทันทีที่เข้าเว็บ
      แต่ก็คิดว่าสภาพแวดล้อมแบบ sandbox ของเบราว์เซอร์ปลอดภัยกว่าการ ติดตั้งแพ็กเกจหรือดาวน์โหลดไฟล์ executable
    • ทุกวันนี้แค่เปิดหน้า landing page แบบ static หน้าเดียวก็ยังโหลดกันเป็นสิบ ๆ MB
      อีกหน่อยคนก็คงชินกับเรื่องแบบนี้เอง :-)
  • ในสภาพแวดล้อมของผม (Firefox, Asahi Linux, M1 Pro) มัน ทำงานผิดปกติ
    พอพูดคำว่า “hello” ไป ประมาณหนึ่งนาทีต่อมาก็พิมพ์คำแปลก ๆ ซ้ำไปซ้ำมา

  • ขอถามแบบพื้นฐานหน่อยว่า โอเพนโมเดลอย่าง Mistral ถ้าเทียบกับ OpenAI หรือ Anthropic แล้วอยู่ระดับไหน
    มันดีพอสำหรับใช้ฟังก์ชัน LLM แบบ เป็นส่วนตัวบนเครื่องส่วนตัว ได้หรือยัง
    หรือว่ายังตามหลังโมเดลเชิงพาณิชย์อยู่มาก

  • เป็นโปรเจ็กต์ที่น่าสนใจ และก็ดีใจที่เห็นมีการใช้ เฟรมเวิร์ก burn
    แต่พอลองรันบน Chromium เวอร์ชันล่าสุด ระบบกลับค้างและ OS ถูกบังคับปิด
    หลังดาวน์โหลดโมเดลเสร็จ VPN ก็หลุดด้วย ทั้งที่ไม่ได้ตั้ง bandwidth limit เลยไม่รู้ว่าเกิดจากอะไร