Deployment Pipeline

หลักการและการเลือกใช้

Deployment ต้องนำโมเดล preprocessing postprocessing และ configuration ที่เข้าคู่กันไปใช้งาน ONNX เป็นรูปแบบแลกเปลี่ยน แต่การรองรับ opset, dynamic shape และ operator ขึ้นกับ runtime ส่วน TensorRT engine อาจผูกกับสภาพแวดล้อมที่สร้าง

การนำโมเดลไปใช้ไม่ใช่เพียงย้ายไฟล์น้ำหนัก เพราะภาพต้องเตรียมแบบเดิมและผลต้องแปลด้วยกติกาที่เข้าคู่กัน Package คือชุดส่วนประกอบที่ส่งมอบพร้อมกัน ส่วน schema คือรูปแบบข้อมูลที่ปลายทางคาดหวัง หากเปลี่ยนความหมายผลหรือหน่วยโดยปลายทางไม่รู้ โปรแกรมอาจยังรับข้อความได้แต่แสดงค่าผิด การตรวจจึงต้องครอบคลุมความหมาย ไม่เพียงโหลดไฟล์สำเร็จ

Opset ระบุชุดรุ่นคำสั่งใน ONNX ส่วน dynamic shape คือรูปร่างข้อมูลที่เปลี่ยนได้ซึ่ง runtime อาจรองรับต่างกัน วิศวกรตรวจคำสั่ง ขนาดภาพ และเงื่อนไขการสร้าง engine กับเครื่องเป้าหมาย บันทึก model config calibration และ schema ใน manifest เดียวกัน การย้อนกลับต้องย้อนส่วนที่สัมพันธ์กัน ไม่เลือกเฉพาะน้ำหนักเก่าหากวิธีปรับภาพหรือ mapping สเกลเปลี่ยนไปแล้ว

เลื่อนแผนภาพซ้าย–ขวาเพื่อดูรายละเอียดครบทุกส่วน

ตัวอย่างในบริบทอุตสาหกรรม

ตัวอย่างเชิงออกแบบ: package ตัวอ่านเกจมี model hash, scale mapping และ schema version เพื่อป้องกันนำ weights ใหม่ไปอ่านด้วย mapping เก่าจนได้ค่าผิด

สมมติรุ่นใหม่คืนจุดเข็มในพิกัดภาพย่อ แต่ตัวแปลงมุมยังคิดว่าเป็นพิกัดภาพต้นฉบับ ผลอาจผิดโดยไม่มีข้อผิดพลาดโปรแกรม ต้องมีภาพอ้างอิงตรวจเส้นทางทั้งชุดและกำหนดการจับคู่เวอร์ชัน หากเปลี่ยนชื่อหน่วยหรือวิธีแทนอ่านไม่ได้ ต้องให้ปลายทางตรวจร่วมด้วย ไม่ส่งรุ่นใหม่ให้ใช้จริงเพียงเพราะตัวประมวลผลเปิดขึ้นและมีตัวเลขส่งออก

วิศวกรปล่อยแบบ shadow คือให้รุ่นใหม่อ่านคู่แต่ยังไม่ใช้ตัดสิน หรือ canary คือจำกัดขอบเขตเริ่มใช้ตามความเสี่ยงที่อนุมัติ แล้วเปรียบผลและสถานะกับรุ่นเดิม กำหนดเกณฑ์หยุดก่อนเริ่ม พร้อมทดสอบย้อนกลับทั้ง package และข้อมูลที่ต้องแปลง ใช้สภาพทดสอบที่ไม่สั่งควบคุมอันตราย และตรวจว่าการฟื้นไม่ทำให้ผลเก่าปะปนกับเวลาและเวอร์ชันใหม่

ขั้นตอนศึกษาและทดลอง

วิธีประเมินและนิยามผล

ทดสอบภาพ golden ทั้งอ่านได้และอ่านไม่ได้บน artifact ที่จะติดตั้งจริง รวม restart migration และปลายทางรับ schema ไม่วัดเฉพาะโมเดลก่อน export

Golden images คือชุดภาพอ้างอิงที่มีผลคาดหวังและที่มาตรวจได้ ต้องมีกรณีผิดเงื่อนไขด้วย ไม่เฉพาะภาพสวย ทดสอบผลดิบและผลสุดท้ายพร้อมหน่วย สถานะ และพิกัด หากอนุญาตความต่างจากรูปแบบตัวเลข ต้องกำหนดตามงานก่อนเห็นผล ไม่ตั้งค่าความคลาดให้ผ่านหลังพบปัญหา และบอกว่าเทียบรุ่นที่ติดตั้งจริงไม่ใช่ไฟล์ต้นฉบับคนละเส้นทาง

วิศวกรตรวจ checksum หรือค่าตรวจเนื้อหาไฟล์ก่อนติดตั้ง แล้วทดสอบ restart การย้ายรูปแบบข้อมูล และปลายทางที่ใช้จริงในสภาพควบคุม ตรวจคิวค้างกับตัวระบุเวอร์ชันทุกผล รวมเวลาและทรัพยากรหลังส่งออก หากเปลี่ยนระบบเฉพาะส่วนหนึ่งต้องยืนยันส่วนที่เกี่ยวข้องทั้งหมด การใช้ ONNX หรือ TensorRT เป็นทางเลือกเทคนิค ไม่ใช่หลักฐานว่าผลิตภัณฑ์รองรับทุก runtime หรือมีผลเร็วขึ้นที่ยืนยันแล้ว

ข้อจำกัดและกรณีผิดพลาด

การ export สำเร็จไม่ยืนยัน output เท่ากัน การ rollback เฉพาะ weights อาจไม่พอหาก schema หรือ calibration เปลี่ยน

เครื่องมือส่งออกอาจเปลี่ยนคำสั่งหรือวิธีแทนตัวเลข และบางขั้นหลังโมเดลอาจไม่อยู่ในไฟล์ที่ส่งออก ต้องตรวจเส้นทางครบ ไม่คิดว่าไฟล์เดียวแทนทุกส่วน การคืนรุ่นเก่าอาจมีข้อมูลที่เขียนด้วย schema ใหม่อยู่แล้ว ต้องวางแผนอ่านข้อมูลและคิวค้างร่วมกัน ไม่ทดสอบย้อนกลับเพียงว่าบริการเริ่มได้โดยไม่มีการยืนยันความหมายของข้อมูลที่ยังใช้งาน

การรวมส่วนประกอบเป็นชุดช่วยตรวจคู่เวอร์ชันแต่เพิ่มภาระสร้างและเก็บไฟล์ ต้องมีผู้อนุมัติการปล่อยและสิทธิ์เข้าถึงตามบริบท การทดลองจำกัดขอบเขตลดผลกระทบบางส่วนแต่ไม่ทดแทนการประเมินก่อนใช้ โดยเฉพาะงานควบคุมหรือความปลอดภัย บทความนี้ให้ขั้นพิจารณานำไปใช้ ไม่ใช่ข้อยืนยันว่าแพลตฟอร์มมี shadow canary หรือ rollback อัตโนมัติพร้อมใช้แล้ว

รายการตรวจสอบก่อนนำไปใช้

• ตรวจ artifact checksum หรือไม่
• จัดคู่ model/config/calibration หรือไม่
• ทดลอง rollback ทั้งชุดก่อนส่งมอบหรือไม่

เอกสารอ้างอิงและอ่านต่อ

• ONNX Runtime — Model optimization
• NVIDIA TensorRT — Documentation