benchmark และแผนใช้งาน Edge
เวลารัน inference เฉพาะโมเดลกับเวลาตั้งแต่รับภาพถึงได้ผลเป็นคนละตัวชี้วัด ต้องระบุส่วนที่จับเวลา warm-up จำนวนรอบ เครื่อง runtime และขนาดภาพ ค่า p95 บอกว่าร้อยละ 95 ของตัวอย่างไม่เกินค่านี้ตามวิธีคำนวณที่ระบุ
A03 · บทฝึกและกรณีศึกษา
เวลารัน inference เฉพาะโมเดลกับเวลาตั้งแต่รับภาพถึงได้ผลเป็นคนละตัวชี้วัด ต้องระบุส่วนที่จับเวลา warm-up จำนวนรอบ เครื่อง runtime และขนาดภาพ ค่า p95 บอกว่าร้อยละ 95 ของตัวอย่างไม่เกินค่านี้ตามวิธีคำนวณที่ระบุ
ตรวจสูตรสถิติและจับเวลา ONNX ของโมเดล smoke test บน PC แล้ว ยังไม่ใช่ benchmark ภาพโดรนจริง หน่วยความจำ หรือบอร์ด Edge
อ่านสูตร ตัวอย่างคำนวณ และแบบฝึกเพิ่มเติม ↓
ก่อนเริ่มเรียน
ใช้คอมพิวเตอร์ Windows หรือ Linux อ่าน CSV ด้วยโปรแกรมตารางหรือ text editor และบันทึกไฟล์งานของตนแยกจากต้นฉบับ ชุด Python พื้นฐานใช้ standard library; โปรแกรม AI และ simulator จริงมีขั้นตอนติดตั้งแยก
เมื่อจบบทนี้
- วัด latency p95 และหน่วยความจำภายใต้สภาพทดสอบที่ระบุ
- ออกแบบการตรวจติดตามข้อมูลเปลี่ยนและเกณฑ์ถอยกลับ
โจทย์และขั้นตอนลงมือทำ
เวลาสังเคราะห์ 20 ค่า คือ 1 ถึง 20 มิลลิวินาที ฝึกคำนวณ nearest-rank p95 แล้วออกแบบการจับเวลาจริง ไม่ใช้ตัวเลขนี้เป็นความเร็วของโดรนหรือบอร์ด
แตก ZIP แล้วเปิด A03-guide.md และ A03-worksheet.csv เก็บสมมติฐานกับผลที่ตรวจได้แยกกัน ช่องว่างในใบงานหมายถึงต้องเก็บข้อมูล ไม่ใช่ผ่านแล้ว
- รัน python practice.py latency และตรวจผล 19 ms จาก ceil(0.95 × 20)
- เตรียม ONNX bundle จาก A02 ตรวจชื่อ input/output และ preprocessing ตามโมเดลก่อนโหลดด้วย ONNX Runtime
- กำหนด warm-up เช่น 10 รอบและวัด 100 รอบเป็นแผนเริ่มต้น เก็บ raw CSV; จับ model-only และ end-to-end แยก พร้อมบันทึกหน่วยความจำและสภาพเครื่อง
- เทียบข้อกำหนดภารกิจ เขียน model card และเหตุให้หยุดใช้/ถอยกลับเมื่อข้อมูลหรือผลเปลี่ยน แยกผล PC กับ Edge จริง
ชิ้นงานและเกณฑ์ตรวจ
ส่ง: benchmark CSV และ model card
เกณฑ์สำคัญ: วัดหลัง warm-up พร้อมจำนวนตัวอย่าง/เครื่อง/ขนาดภาพ; แยกผล PC กับบอร์ดจริง
แนบไฟล์ที่เปิดตรวจได้ วันที่ รุ่นข้อมูล และเหตุผลเมื่อยังสรุปไม่ได้ การทำใบงานสำเร็จไม่แทนผลทดลองกับโมเดล อุปกรณ์ หรือการประเมินทักษะจริง
เปิดแนวคำตอบหลังทำใบงาน
nearest-rank p95 เท่ากับ 19 ms ส่วนค่าเฉลี่ย 10.5 ms วิธี percentile อื่นอาจต่างกัน จึงต้องระบุวิธี; ไม่มีค่าใดในชุดนี้วัดจากฮาร์ดแวร์
ทดลองเส้นทางโปรแกรมที่ตรวจแล้ว
ใน ZIP มี framework-README.md และ framework-smoke.py สร้างภาพสี่เหลี่ยม 16 ภาพ ฝึก 1 epoch ส่งออก ONNX และเทียบ raw output กับ PyTorch ตรวจผ่านบน Windows 11/Python 3.14.3 และ Ubuntu/WSL/Python 3.12.3 ด้วย CPU แล้ว
ใช้ Ultralytics 8.4.144, PyTorch 2.14.0+cpu และ ONNX Runtime 1.29.0 ดูรายงานและรุ่น dependencies ในชุดดาวน์โหลด ผลนี้ยืนยันขั้นตอนโปรแกรมเท่านั้น โมเดลหลัง 1 epoch ยังตรวจจับไม่ได้ดี และไม่ใช่การประเมินกับภาพโดรนจริง
python framework-smoke.py --output my-smoke-runต้องเตรียม environment ตาม README ก่อนรัน การจับเวลาในรายงานวัดเฉพาะ ONNX บนภาพ 64×64 ที่เตรียมในหน่วยความจำ ไม่รวมกล้องหรือการสื่อสาร
แผนกิจกรรมสำหรับผู้สอน
ให้ผู้เรียนจับเวลาสองขนาดภาพ ตรวจความแม่นยำควบคู่ความเร็ว และหาสาเหตุ outlier ก่อนสรุปว่าสมควรลดโมเดลหรือเปลี่ยนอุปกรณ์
คำถามชวนทบทวน: ผลบน PC สนับสนุนข้อสรุปใดและยังไม่สนับสนุนอะไรบนโดรน?
| ชุดการเรียน | อธิบาย | ฝึก | ประเมิน | รวมสถานีอุปกรณ์ |
|---|---|---|---|---|
| AI และโดรน: จากภาพถึงการทดลองโมเดล | 150 นาที | 330 นาที | 120 นาที | 0 นาที |
เวลาสถานีอุปกรณ์เป็นส่วนหนึ่งของเวลารวมในแผน ไม่บวกซ้ำ ผู้สอนแยกผล PC กับ observed task และให้ผู้เรียนอธิบายงานรายคนก่อนเปิดแนวคำตอบ
ดูการจัดกิจกรรมครบสายและส่วนขยายพื้นฐาน →บรรณานุกรมและขอบเขตการอ้างอิง
ตรวจแหล่งเพิ่มเติม 9 กันยายน 2569 กรณีสมมติ ตัวเลข ใบงาน และเกณฑ์กิจกรรมเรียบเรียงใหม่โดย PK-Research
- ONNX Runtime — Python
การโหลดโมเดลและรัน inference; ต้องใช้ preprocessing/postprocessing ของโมเดลนั้น
- Ultralytics — Model Export
การส่งออก ONNX; compatibility ขึ้นกับรุ่น โมเดล และ runtime
- NIST — AI Risk Management Framework 1.0
กรอบจัดการความเสี่ยง AI แบบสมัครใจ ไม่รับรองความแม่นยำโมเดล
สูตรและแบบฝึกเพิ่มเติม · ปรับปรุง 2026-09-26
F18: ผลหนึ่งภาพมาถึงช้าแค่ไหน และระบบทำได้กี่ภาพต่อวินาที
Latency คือเวลาที่ภาพหนึ่งใช้เดินทางผ่านขอบเขตที่กำหนด ส่วน throughput คือจำนวนภาพที่เสร็จต่อเวลา ทั้งสองค่าตอบคนละคำถาม ระบุจุดเริ่มและจุดจบ เช่น รับภาพจากกล้องจนผลหลัง postprocess พร้อมใช้ ก่อนจับเวลา
latencyi = tout,i − tin,i
throughput = N / T
FPS = 1000 / latencyms ใช้ได้เฉพาะแบบ serial หนึ่งภาพต่อครั้ง ไม่มีช่วงว่าง และวัดขอบเขตเดียวกัน
| ตัวแปร | ความหมายและหน่วย | ช่วงและแหล่งค่า |
|---|---|---|
| t_in, t_out | timestamp เริ่ม/จบ หน่วย ms | นาฬิกา monotonic เดียวกัน; t_out ≥ t_in |
| latency_i | เวลาต่อภาพ ms | ≥ 0; คำนวณจากคู่ timestamp ของภาพเดียวกัน |
| N | จำนวนภาพที่เสร็จในหน้าต่างวัด frame | จำนวนเต็ม ≥ 0; ไม่นับภาพทิ้งเป็นภาพที่เสร็จ |
| T | ระยะหน้าต่างวัด s | > 0; ระบุการรวมเวลาเติม/ระบาย pipeline |
| throughput | อัตราภาพเสร็จ frame/s | ≥ 0; รายงาน dropped frames แยก |
ในภาพ ขั้น preprocess 10 ms, inference 30 ms และ postprocess 10 ms ใช้ทรัพยากรแยกกันได้ตามสมมติฐาน ภาพแรกจึงเสร็จที่ 50 ms แต่ช่วง steady state อาจออกทุก 30 ms หรือประมาณ 33.33 frame/s ขณะที่ latency ยังเป็น 50 ms หากมีคิวรอ latency จะเพิ่มอีก
ตัวอย่างแทนค่าทีละขั้น
ระบบ serial ใช้ภาพละ 50 ms = 0.050 s จึงได้ 1/0.050 = 20 frame/s ส่วน pipeline วัดภาพเสร็จ 300 ภาพในหน้าต่าง steady state 10 s ได้ 300/10 = 30 frame/s ต้องรายงานสองผลตามวิธีวัด ไม่ใช้ 1000/50 แทนอัตราที่วัดจริง
ข้อมูล latency สังเคราะห์เรียงจากน้อยไปมาก 20 ค่า หน่วย ms คือ 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 80 ค่า median = (40+41)/2 = 40.5 ms บทนี้เลือก p95 แบบ nearest rank: k = ceil(0.95 × n) = ceil(19) = 19 จึงได้ p95 = ค่าลำดับ 19 = 49 ms การใช้ percentile แบบ interpolation อาจได้ค่าอื่น ต้องบอกวิธีและจำนวนตัวอย่างเสมอ ชุดเล็กนี้สอนคำนวณ ไม่ใช่หลักฐาน tail latency ของฮาร์ดแวร์
วัดให้เปรียบเทียบได้
บันทึกบอร์ด รุ่น runtime/execution provider โมเดล input shape batch size precision จำนวน thread และโหมดพลังงาน แยกเวลาโหลดโมเดลกับ warm-up ออกจาก steady state โดยรายงานทั้งจำนวน warm-up และจำนวนตัวอย่าง จับเวลารอบ end-to-end และ inference แยกกัน หาก GPU ทำงาน asynchronous ต้องรอ completion/synchronize ตาม API ก่อนปิดเวลา ไม่ใช้เวลาส่งคำสั่งแทนเวลางานเสร็จ ตรวจอุณหภูมิและ throttling ระหว่างรันซ้ำ
แนวทางแยก latency/throughput และปรับ runtime อ้างอิง ONNX Runtime: Tune performance (S18) ตรวจ 26 กันยายน 2569 ส่วนตัวเลข timeline และ nearest-rank เป็นข้อตกลงของโจทย์นี้ ไม่ใช่ผล benchmark จาก ONNX Runtime และไม่ใช่เวลาตอบสนองวงควบคุมการบินทั้งหมด
แบบฝึก
เปลี่ยนระบบ serial ให้ใช้เวลา 40 ms ต่อภาพ โดยเงื่อนไขอื่นเท่าเดิม จะได้กี่ frame/s? หาก pipeline วัดได้ 250 ภาพใน 10 s ค่า throughput เท่าใด?
เฉลย F18
Serial: 1000/40 = 25 frame/s; pipeline: 250/10 = 25 frame/s เช่นกัน แต่ค่าเท่ากันไม่ได้พิสูจน์ว่า latency เท่ากัน ยอมรับความคลาดเคลื่อนการปัด ±0.01 frame/s และไม่คำนวณ N/T เมื่อ T = 0 หรือไม่มีข้อมูล
อ่านความถูกต้องควบคู่กับความเร็วใน Computer Vision และใช้ เครื่องมือเดิม ประกอบการฝึก
ดาวน์โหลดชุดตรวจคำตอบสูตรพื้นฐาน (JSON) · ข้อมูลสังเคราะห์สำหรับเปรียบเทียบคำตอบและหน่วย