ข้ามไปยังเนื้อหา
TESA Open Knowledge

quantize และ Vela: เอาโมเดลของเราขึ้น Ethos-U55

โมดูล 5 — ฝึกโมเดลและนำไปใช้หลายเป้าหมาย · สไลด์: slides.md · ภาพรวมโมดูล · หน้าหลักสูตร

เป้าหมายสุดท้ายและยากที่สุดของ “train once, run everywhere” คือ MCU กับ Ethos-U55 เข้าใจว่าทำไม NPU ต้องมีขั้นคอมไพล์ Vela เพิ่ม ไฟล์ .tflite สามหน้าตาไปเป้าหมายใด สัญญาสี่ฟังก์ชัน AIM_* ที่ทำให้ edge_ai เรียกโมเดลได้ สองทางในการห่อโมเดล และเหตุผลที่ NPU เร็วและประหยัดกว่า

เป้าหมาย

หัวข้อที่มีชื่อว่า “เป้าหมาย”

เมื่อจบบทเรียนนี้ คุณจะ:

  1. อธิบายได้ว่าทำไมมีแค่ MCU ที่ต้องคอมไพล์ด้วย Vela และจับคู่ไฟล์ model_int8, model_int8_vela และ model_web กับเป้าหมายที่ถูกต้อง
  2. รัน quantize_vela.sh ใน Docker image เดิมจนได้ output/model_int8_vela.tflite และอธิบายตัวเลือก –accelerator-config ethos-u55-128 กับ –optimise Performance
  3. อธิบายสัญญา AIM_* สี่ฟังก์ชัน (init, enqueue, dequeue, finalize) กับรหัสคืนค่า และบอกได้ว่ากับดักหลักของการห่อโมเดลคือ feature parity ไม่ใช่ตัวกราฟ
  4. อธิบายว่าทำไม NPU จึงเร็วกว่าและใช้พลังงานต่อการอนุมานน้อยกว่า CPU และอ่านตารางเทียบโดยดู worst-case latency กับความผิดพลาดรายคลาสได้

ก่อนเริ่ม

หัวข้อที่มีชื่อว่า “ก่อนเริ่ม”

ผ่านชุดบทเรียน 5.3–5.7 มาแล้ว มี model_int8.tflite ที่ผ่าน eval_pc.py และเข้าใจ quantize กับ dequantize เปิด quantize_vela.sh ไว้อ่านคู่กับสไลด์

ดูของจริงก่อน

หัวข้อที่มีชื่อว่า “ดูของจริงก่อน”

ใน Docker image เดิม สั่ง ./quantize_vela.sh model_int8.tflite แล้วดูไฟล์ใหม่ใน output/ ไฟล์ _vela.tflite นี้เบราว์เซอร์กับ PC เปิดไม่ได้แล้ว ถามตัวเองว่า Vela เปลี่ยนอะไรในไฟล์ และทำไมเปลี่ยนแล้ว accuracy ไม่ควรเปลี่ยน

แนวคิด

หัวข้อที่มีชื่อว่า “แนวคิด”

Web, Cortex-A และ PC ล้วนรันกราฟ TFLite ทั่วไปบน CPU หรือ GPU ได้ตรง ๆ แต่ NPU ไม่ใช่ CPU มันคือวงจรคูณเมทริกซ์ int8 เฉพาะทาง Vela (ethos-u-vela ของ Arm) จึงรับ .tflite แบบ full-integer int8 แล้วแทน subgraph ที่ NPU ทำได้ด้วย custom op ตัวเดียวชื่อ ethos-u ส่วนที่ NPU ทำไม่ได้ปล่อยให้ Cortex-M55 ทำ quantize_vela.sh ห่อคำสั่ง vela --accelerator-config ethos-u55-128 --optimise Performance (U55 ที่ 128 MAC ต่อรอบ เน้นความเร็ว) ได้ output/model_int8_vela.tflite ที่ใช้ได้กับ MCU เท่านั้น ถึงตรงนี้มี หนึ่งน้ำหนัก สามบรรจุภัณฑ์: model_int8.tflite (PC, Cortex-A และต้นทางของ Vela) _vela.tflite (MCU) และ model_web.tflite (เบราว์เซอร์) เอาไฟล์ผิดที่จะโหลดไม่ขึ้นทันที

Vela ไม่แก้คณิตของโมเดล $q = \mathrm{round}(x/s) + z$ และ $x = (q - z)\cdot s$ ยังใช้ $s, z$ ที่ PTQ ฝังไว้ในทุก tensor accuracy บน NPU จึงควรเท่ากับ int8 บน PC (ต่างได้แค่ระดับการปัดเศษของ kernel) ถ้าบนบอร์ดเพี้ยนมาก ให้สงสัย front-end ก่อน ไฟล์ Vela ยังไม่ใช่โมเดลที่บอร์ดรู้จัก ต้อง ห่อ ด้วยสัญญาสี่ฟังก์ชัน <SLOT>_init, <SLOT>_enqueue(const float *in), <SLOT>_dequeue(float *out) และ <SLOT>_finalize ซึ่งคือ IPWIN streaming ABI ของ Imagimob ที่ DEEPCRAFT Studio สร้างให้ dequeue คืน −1 (NODATA) ระหว่างที่หน้าต่างยังไม่เต็มเป็นเรื่องปกติ ห่อได้สองทาง: ตัวแปลงของ DEEPCRAFT ที่สร้าง C พร้อม front-end ให้ หรือห่อ TFLite-Micro เองแล้วเขียน front-end ให้ตรงกับตอนฝึก กับดักอันดับหนึ่งคือ feature ที่ไม่ตรงกัน ไม่ใช่ตัวกราฟ ซอร์สเฟิร์มแวร์ BENTO ที่คอร์สใช้ยังไม่เปิด ใน SDK สาธารณะ ตัว engine มาเป็นไลบรารี prebuilt โมเดลใหม่จึงเข้าทะเบียนด้วย ai_engine_register() หรือใส่แทนช่องเดิม ตาม คู่มือ Filling a model slot

NPU ไม่ได้ฉลาดกว่า CPU มันทำงานเดียวคือคูณเมทริกซ์ int8 ด้วยวงจร MAC ขนาน 128 ตัวต่อรอบ งานเดียวกันจึงเสร็จในรอบน้อยกว่ามาก เสร็จเร็วคือปลุกวงจรสั้นแล้วกลับไปหลับ พลังงานต่อการอนุมานจึงต่ำตามไปด้วย ตอนอ่านตารางเทียบ ระวังสามเรื่อง: accuracy รวมอาจซ่อนคลาสที่พลาด (ดู confusion matrix) latency เฉลี่ยซ่อน worst-case และ Web ต่างเล็กน้อยได้เพราะ activation เป็น float

ตัวอย่างสมบูรณ์

หัวข้อที่มีชื่อว่า “ตัวอย่างสมบูรณ์”

สไลด์ของบทเรียนนี้อ้างถึงไฟล์ที่อยู่ในบทเรียนอื่นหรือใน shared/ ด้วย:

เช็กความเข้าใจ

หัวข้อที่มีชื่อว่า “เช็กความเข้าใจ”

คำถามชุดเดียวกันอยู่ใน quiz.yaml สำหรับระบบที่ตรวจอัตโนมัติ

  1. ไฟล์ใดควรส่งไปหน้าเว็บ (เลือกหนึ่งข้อ · เป้าหมายข้อ 1)

    • ก) model_int8_vela.tflite
    • ข) model_web.tflite ที่ I/O เป็น float และไม่มี custom op ของ NPU
    • ค) model.keras
    • ง) ไฟล์ใดก็ได้
    เฉลย

    ข — ไฟล์ Vela มี op ethos-u ที่รันได้เฉพาะบน NPU ส่วน model_web.tflite ทำมาเพื่อเบราว์เซอร์ และ model_int8.tflite ใช้กับ PC และ Cortex-A

  2. หลังรัน ./quantize_vela.sh model_int8.tflite ไฟล์ของ MCU อยู่ที่ใด (เลือกหนึ่งข้อ · เป้าหมายข้อ 2)

    • ก) ./model_int8.tflite ทับไฟล์เดิม
    • ข) ./output/model_int8_vela.tflite
    • ค) ./vela/model.bin
    • ง) ในบอร์ดโดยตรง
    เฉลย

    ข — Vela เขียนผลลงโฟลเดอร์ output ต่อท้ายชื่อด้วย _vela ไฟล์ int8 เดิมยังอยู่ไว้ใช้กับ PC และ Cortex-A

  3. AIM_GESTURE_dequeue คืน −1 ในช่วงแรกหลัง start หมายความว่าอะไร (เลือกหนึ่งข้อ · เป้าหมายข้อ 3)

    • ก) โมเดลพัง ต้อง flash ใหม่
    • ข) NODATA: หน้าต่างยังเก็บข้อมูลไม่เต็ม เป็นเรื่องปกติ
    • ค) NPU ร้อนเกินไป
    • ง) คลาสที่ชนะคือ −1
    เฉลย

    ข — ตาม IPWIN ABI ค่า −1 คือยังไม่มีผล enqueue ต่อไปจนหน้าต่างเต็ม dequeue จึงคืน 0 พร้อมคะแนน

  4. int8 บน PC แม่น 0.95 แต่บนบอร์ดทายผิดเกือบหมด ควรสงสัยอะไรก่อน (เลือกหนึ่งข้อ · เป้าหมายข้อ 3)

    • ก) Vela คำนวณผิด
    • ข) front-end บนบอร์ด (normalize, quantize หรือ feature) ไม่ตรงกับตอนฝึก
    • ค) NPU ช้าเกินไป
    • ง) ต้องฝึกใหม่ด้วย epoch มากขึ้น
    เฉลย

    ข — Vela ไม่แก้คณิต ความต่างใหญ่ขนาดนี้มักมาจากข้อมูลที่ป้อนเข้าโมเดลบนบอร์ดคนละสเกลหรือคนละ feature กับตอนฝึก

  5. ทำไม Ethos-U55 ใช้พลังงานต่อการอนุมานน้อยกว่า Cortex-M55 ทำเอง (เลือกหนึ่งข้อ · เป้าหมายข้อ 4)

    • ก) เพราะใช้ float32
    • ข) เพราะคูณเมทริกซ์ int8 ได้ขนาน 128 MAC ต่อรอบ งานเสร็จในรอบน้อยกว่า แล้วบอร์ดกลับไปหลับได้เร็ว
    • ค) เพราะข้ามการ normalize
    • ง) เพราะไม่ต้องใช้ไฟ
    เฉลย

    ข — ความเร็วกับพลังงานมาจากเหตุผลเดียวกัน วงจรเฉพาะทางทำงานเดียวได้ขนาน ใช้รอบสัญญาณนาฬิกาน้อยกว่ามาก

แล็บ

หัวข้อที่มีชื่อว่า “แล็บ”
  • รัน ./quantize_vela.sh model_int8.tflite ใน Docker image เดิม จดขนาดไฟล์ _vela.tflite เทียบกับ model_int8.tflite ลงบันทึกการเรียน
  • อ่านรายงานที่ Vela พิมพ์ออกมา แล้วหาว่ามี op ใดที่ตกไปรันบน CPU หรือไม่
  • วาดแผนผัง “หนึ่งน้ำหนัก สามบรรจุภัณฑ์” พร้อมเขียนว่าแต่ละไฟล์มาจากสคริปต์ใดและไปเป้าหมายใด

ไปต่อ

หัวข้อที่มีชื่อว่า “ไปต่อ”

บทเรียน 5.9 เราจะเติม s14_tflite_board.py ให้ bench int8 บน PC รัน Vela แล้วเติมตารางเทียบสามเป้าหมาย รวมถึงอ่าน latency จริงจากบอร์ด

บทเรียนถัดไป: บทเรียน 5.9 — ลงมือทำ: เทียบสามเป้าหมาย MCU, Web และ PC

สะท้อนคิด

หัวข้อที่มีชื่อว่า “สะท้อนคิด”
  • ถ้าโมเดลของคุณมี op ที่ Ethos-U55 ทำไม่ได้หลายตัว ผลต่อ latency จะเป็นอย่างไร และคุณจะแก้ที่ไหน
  • งานแบบไหนที่คุณยอมจ่ายขั้นคอมไพล์เพิ่มเพื่อให้แบตเตอรี่อยู่ได้นานขึ้น

คำถามทบทวน

ลองตอบเองก่อน แล้วค่อยเปิดดูเฉลย

  1. ไฟล์ใดควรส่งไปหน้าเว็บ (เป้าหมายข้อ 1)

    1. model_int8_vela.tflite
    2. model_web.tflite ที่ I/O เป็น float และไม่มี custom op ของ NPU
    3. model.keras
    4. ไฟล์ใดก็ได้
    ดูเฉลย

    คำตอบ: B. model_web.tflite ที่ I/O เป็น float และไม่มี custom op ของ NPU

    ไฟล์ Vela มี op ethos-u ที่รันได้เฉพาะบน NPU ส่วน model_web.tflite ทำมาเพื่อเบราว์เซอร์ และ model_int8.tflite ใช้กับ PC และ Cortex-A

  2. หลังรัน ./quantize_vela.sh model_int8.tflite ไฟล์ของ MCU อยู่ที่ใด (เป้าหมายข้อ 2)

    1. ./model_int8.tflite ทับไฟล์เดิม
    2. ./output/model_int8_vela.tflite
    3. ./vela/model.bin
    4. ในบอร์ดโดยตรง
    ดูเฉลย

    คำตอบ: B. ./output/model_int8_vela.tflite

    Vela เขียนผลลงโฟลเดอร์ output ต่อท้ายชื่อด้วย _vela ไฟล์ int8 เดิมยังอยู่ไว้ใช้กับ PC และ Cortex-A

  3. AIM_GESTURE_dequeue คืน −1 ในช่วงแรกหลัง start หมายความว่าอะไร (เป้าหมายข้อ 3)

    1. โมเดลพัง ต้อง flash ใหม่
    2. NODATA: หน้าต่างยังเก็บข้อมูลไม่เต็ม เป็นเรื่องปกติ
    3. NPU ร้อนเกินไป
    4. คลาสที่ชนะคือ −1
    ดูเฉลย

    คำตอบ: B. NODATA: หน้าต่างยังเก็บข้อมูลไม่เต็ม เป็นเรื่องปกติ

    ตาม IPWIN ABI ค่า −1 คือยังไม่มีผล enqueue ต่อไปจนหน้าต่างเต็ม dequeue จึงคืน 0 พร้อมคะแนน

  4. int8 บน PC แม่น 0.95 แต่บนบอร์ดทายผิดเกือบหมด ควรสงสัยอะไรก่อน (เป้าหมายข้อ 3)

    1. Vela คำนวณผิด
    2. front-end บนบอร์ด (normalize, quantize หรือ feature) ไม่ตรงกับตอนฝึก
    3. NPU ช้าเกินไป
    4. ต้องฝึกใหม่ด้วย epoch มากขึ้น
    ดูเฉลย

    คำตอบ: B. front-end บนบอร์ด (normalize, quantize หรือ feature) ไม่ตรงกับตอนฝึก

    Vela ไม่แก้คณิต ความต่างใหญ่ขนาดนี้มักมาจากข้อมูลที่ป้อนเข้าโมเดลบนบอร์ดคนละสเกลหรือคนละ feature กับตอนฝึก

  5. ทำไม Ethos-U55 ใช้พลังงานต่อการอนุมานน้อยกว่า Cortex-M55 ทำเอง (เป้าหมายข้อ 4)

    1. เพราะใช้ float32
    2. เพราะคูณเมทริกซ์ int8 ได้ขนาน 128 MAC ต่อรอบ งานเสร็จในรอบน้อยกว่า แล้วบอร์ดกลับไปหลับได้เร็ว
    3. เพราะข้ามการ normalize
    4. เพราะไม่ต้องใช้ไฟ
    ดูเฉลย

    คำตอบ: B. เพราะคูณเมทริกซ์ int8 ได้ขนาน 128 MAC ต่อรอบ งานเสร็จในรอบน้อยกว่า แล้วบอร์ดกลับไปหลับได้เร็ว

    ความเร็วกับพลังงานมาจากเหตุผลเดียวกัน วงจรเฉพาะทางทำงานเดียวได้ขนาน ใช้รอบสัญญาณนาฬิกาน้อยกว่ามาก

อ้างอิงบทเรียนนี้

ถ้านำบทเรียนนี้ไปสอน ทำสไลด์ หรือทำเอกสารต่อ ให้อ้างอิงด้วยข้อความนี้ ถ้าดัดแปลงเนื้อหา ให้เติม (ดัดแปลง)ต่อท้ายชื่อบทเรียน

"quantize และ Vela: เอาโมเดลของเราขึ้น Ethos-U55" จาก TESA Open Knowledge โดยสมาคมสมองกลฝังตัวไทย (Thai Embedded Systems Association: TESA) https://github.com/tesaiot/tesa-qualification-program สัญญาอนุญาต CC BY-NC 4.0

ข้อความอ้างอิงภาษาอังกฤษ: "Quantize and Vela: putting our model on the Ethos-U55" from TESA Open Knowledge by the Thai Embedded Systems Association (TESA), https://github.com/tesaiot/tesa-qualification-program, licensed under CC BY-NC 4.0

ลิงก์บทเรียน: https://tesaiot.github.io/tesa-qualification-program/courses/edge-ai-developer/m05-training/l08-quantize-and-vela/

วิธีอ้างอิง TESA ฉบับเต็ม

TESA Open Knowledge · © 2026 สมาคมสมองกลฝังตัวไทย (TESA) · CC BY-NC 4.0

เนื้อหาเผยแพร่ภายใต้ CC BY-NC 4.0 นำไปใช้ต่อในงานที่ไม่ใช่เพื่อการค้าได้ โปรดอ้างอิงสมาคมสมองกลฝังตัวไทย (TESA) ทุกครั้ง · วิธีอ้างอิง TESA