Google เปิดตัว LiteRT.js — รันโมเดล .tflite ในเบราว์เซอร์ เร็วกว่า runtime เว็บอื่นถึง 3 เท่า

Google ประกาศเปิดตัว LiteRT.js เมื่อ 9 กรกฎาคม 2026 บน Google Developers Blog — เป็น JavaScript binding ของ LiteRT (ตัวสืบทอดของ TensorFlow Lite) ที่ทำให้นักพัฒนาเว็บรันโมเดล ML และ GenAI ในเบราว์เซอร์ทั้งหมด ได้โดยไม่ต้องส่งข้อมูลออกไปหาเซิร์ฟเวอร์

จุดขายไม่ใช่แค่ “รันได้” แต่คือ รันได้เร็วจริง Google อ้างว่า LiteRT.js ทำได้ เร็วกว่า runtime เว็บตัวอื่นถึง 3 เท่า ทั้งบนเส้นทาง CPU และ GPU และเมื่อผลักงานลง GPU หรือ NPU ผ่าน WebGPU/WebNN ก็ได้ เร็วขึ้น 5–60 เท่าเทียบกับการรันบน CPU มาตรฐาน (ตัวเลขวัดบน MacBook Pro M4 ปี 2024 — ผลจริงแปรตามฮาร์ดแวร์และสภาพความร้อน)

สามเส้นทางเร่งความเร็ว: CPU, GPU, NPU

สิ่งที่ทำให้ LiteRT.js ต่างจากการ “เอาโมเดลมาแปะบนเว็บ” คือมันมี backend เร่งความเร็วครบสามชั้น:

• CPU — ใช้ XNNPACK ไลบรารีเร่งความเร็ว CPU ที่ Google ปรับจูนมาแล้วสำหรับงาน on-device รองรับทั้ง multi-thread และ build แบบ relaxed SIMD
• GPU — ขับด้วย ML Drift ผ่าน WebGPU ซึ่งเป็น API มาตรฐานตัวใหม่ที่เบราว์เซอร์สมัยใหม่รองรับแล้ว
• NPU — เกาะไปกับ WebNN API (ยังเป็น experimental ใน Chrome และ Edge) เพื่อยิงงานลงชิป NPU โดยเฉพาะ ได้ latency ต่ำและกินไฟน้อย

ชั้น NPU คือส่วนที่น่าจับตาที่สุด เพราะโน้ตบุ๊กและมือถือรุ่นใหม่แทบทุกตัวมี NPU ติดมาแล้ว แต่นักพัฒนาเว็บแทบไม่มีทางแตะมันได้เลย WebNN เพิ่งเปิดประตูนั้น และ LiteRT.js คือหนึ่งใน runtime แรก ๆ ที่ต่อท่อให้

API ที่ตั้งใจให้ย้ายมาแล้วไม่เจ็บ

ถ้าคุณมีไฟล์ .tflite อยู่แล้ว การ deploy ขึ้นเว็บแทบไม่ต้องเขียนอะไรใหม่ ติดตั้งจาก npm ด้วยแพ็กเกจ @litertjs/core แล้วโค้ดหน้าตาประมาณนี้:

import { loadLiteRt, loadAndCompile, Tensor } from '@litertjs/core';

const model = await loadAndCompile('model.tflite', { accelerator: webgpu });
const results = await model.run(inputTensor);

Google วางตำแหน่ง LiteRT.js ว่าเป็น วิวัฒนาการต่อจาก TensorFlow.js สำหรับการรันโมเดล .tflite โดยเฉพาะ ส่วนงาน LLM ในเบราว์เซอร์แยกไปอยู่แพ็กเกจ LiteRT-LM.js ต่างหาก — แปลว่าทีมนี้ไม่ได้ยัดทุกอย่างลงก้อนเดียว แต่แยกเลเยอร์ inference ทั่วไปออกจากเลเยอร์ generative

ตัวเลข 3 เท่าที่ Google อ้างมาจากกลุ่มโมเดล computer vision แบบคลาสสิกและงานประมวลผลเสียง ไม่ใช่ LLM ขนาดใหญ่ — อ่านตัวเลขนี้ตามบริบทของมัน

มุมมอง AI Curator

ข่าวนี้ไม่หวือหวาเท่าโมเดลใหม่ แต่สำหรับคนสร้างของจริง มันอาจสำคัญกว่า

เหตุผลคือ โครงสร้างต้นทุน ทุกวันนี้ฟีเจอร์ AI เล็ก ๆ บนเว็บ — ตัดพื้นหลังรูป, ตรวจจับใบหน้า, แปลงเสียงเป็นข้อความ, จัดหมวดหมู่รูป — ยังต้องยิงขึ้น API แล้วจ่ายต่อ request ทั้งที่งานพวกนี้เล็กพอจะรันบนเครื่องผู้ใช้ได้สบาย LiteRT.js ทำให้ต้นทุน inference ของงานกลุ่มนี้ เป็นศูนย์ และ latency ลดลงเหลือระดับ frame

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

ข้อควรระวังคือ อย่าเพิ่งเชื่อตัวเลข 3 เท่าแบบเหมารวม มันวัดจากโมเดล vision/audio บนแมค M4 ซึ่งเป็นฮาร์ดแวร์ระดับบน ผู้ใช้จริงจำนวนมากในภูมิภาคเราถือ Android ราคากลาง-ล่างที่ WebGPU อาจยังไม่เปิด และ WebNN ยัง experimental อยู่ทั้งใน Chrome และ Edge แผนที่ปลอดภัยคือทำ graceful degradation — ลอง NPU → GPU → CPU แล้วมี fallback ขึ้นเซิร์ฟเวอร์เมื่อเครื่องไม่ไหว ไม่ใช่ย้ายทุกอย่างลง client แล้วหวังว่าเบราว์เซอร์จะรองรับ

ภาพใหญ่ที่น่าสนใจคือทิศทาง: Google กำลังไล่ปิดช่องว่างระหว่าง “AI ที่รันบนคลาวด์” กับ “AI ที่รันตรงหน้าผู้ใช้” ทีละชั้น — จาก LiteRT บนมือถือ มาจนถึง LiteRT.js บนเว็บ เมื่อ NPU กลายเป็นของมาตรฐานในเครื่องทุกเครื่อง คำถามจะเปลี่ยนจาก “โมเดลนี้รันบนเครื่องได้ไหม” เป็น “ทำไมยังต้องส่งขึ้นคลาวด์”

แหล่งข่าว

• LiteRT.js, Google’s high performance Web AI Inference — Google Developers Blog (9 ก.ค. 2026)
• LiteRT for Web with LiteRT.js — Google AI Edge documentation
• google-ai-edge/LiteRT — GitHub