สร้างเวิร์กโฟลว์ AI แบบสหพันธ์ (Federated AI) ที่รองรับหลายรูปแบบข้อมูล (Multimodal) ด้วย NVIDIA FLARE

ในยุคปัจจุบัน โมเดล AI ที่สามารถประมวลผลได้ทั้งภาพและข้อความ (Vision-Language Models - VLMs) มีความสามารถหลากหลาย ตั้งแต่การตอบคำถามจากภาพ การสร้างคำบรรยายภาพ ไปจนถึงการให้เหตุผลระหว่างรูปภาพและข้อความ อย่างไรก็ตาม การจะปรับปรุงโมเดลเหล่านี้ให้มีประสิทธิภาพสูงขึ้น มักต้องการข้อมูลจำนวนมากที่อาจกระจายตัวอยู่ตามสถาบันหรือองค์กรต่างๆ ซึ่งทำให้การรวบรวมข้อมูลทั้งหมดมาไว้ที่ส่วนกลางเป็นเรื่องท้าทาย

การเรียนรู้แบบสหพันธ์ (Federated Learning) เป็นแนวทางที่ช่วยให้สามารถฝึกฝนโมเดล AI ร่วมกันได้ โดยไม่ต้องย้ายข้อมูลดิบออกจากแหล่งกำเนิด แต่สำหรับ VLM นั้น ความท้าทายไม่ได้อยู่ที่การจัดการฝึกฝนเท่านั้น แต่ยังรวมถึงการที่แต่ละไซต์ (Client) อาจมีส่วนผสมของข้อมูลและงาน (Task) ที่แตกต่างกัน และขนาดของการอัปเดตโมเดลก็อาจใหญ่เกินกว่าที่แบนด์วิดท์เครือข่ายหรือหน่วยความจำของเซิร์ฟเวอร์จะรองรับได้

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

1. ควรส่งข้อมูลสถานะโมเดลส่วนใดข้ามเครือข่ายบ้าง?
2. จะถ่ายโอนและรวมการอัปเดตโมเดลเหล่านั้นอย่างมีประสิทธิภาพได้อย่างไร?

เราจะแสดงให้เห็นว่า NVIDIA FLARE สามารถช่วยประสานงานการฝึกฝนแบบสหพันธ์ได้อย่างไร และจัดการกับการอัปเดตโมเดลขนาดใหญ่ผ่านเทคนิคต่างๆ เช่น การทำให้วัตถุขนาดใหญ่เป็นภายนอก (Externalization), การสตรีมเทนเซอร์ (Tensor Streaming) และการรวมข้อมูลโดยใช้ดิสก์เป็นส่วนรองรับ (Disk-backed Aggregation)

ความท้าทายในการทำ Federated VLM

ในการทดลอง Vision-Language แบบรวมศูนย์ (Centralized) ข้อมูลต่างๆ เช่น รูปภาพ คำบรรยาย ภาพตัวอย่างคำถาม-คำตอบ หรือพรอมต์สำหรับสร้างข้อความ สามารถป้อนเข้าสู่ไปป์ไลน์การฝึกฝนเดียวได้ แต่ในสภาพแวดล้อมแบบสหพันธ์ ข้อมูลเหล่านี้จะกระจายตัวอยู่ตามไซต์ต่างๆ ซึ่งแต่ละไซต์อาจมีข้อมูล งาน หรือข้อจำกัดในการทำงานที่แตกต่างกัน

ปัญหานี้ก่อให้เกิดความท้าทายทางวิศวกรรมสองประการ:

1. ความหลากหลายของข้อมูลและงาน: แต่ละไซต์อาจฝึกฝนบนชุดงานหรือรูปแบบข้อมูลที่แตกต่างกัน ดังนั้น เวิร์กโฟลว์ต้องกำหนดอย่างชัดเจนว่าแต่ละไคลเอนต์ควรจะอัปเดตส่วนใดของโมเดล และจะรวมการอัปเดตเหล่านั้นเข้าด้วยกันอย่างไร
2. ขนาดของการอัปเดตโมเดล: การส่งพารามิเตอร์โมเดลทั้งหมดอาจใช้ทรัพยากรในการแปลงเป็นซีเรียล (Serialization) ถ่ายโอน และเก็บไว้ในหน่วยความจำเซิร์ฟเวอร์เป็นจำนวนมาก

ดังนั้น การตัดสินใจแรกที่สำคัญคือ "จะทำ Federation กับอะไร?" บางแนวทางอาจเลือกแลกเปลี่ยนความรู้ที่กลั่นกรองมา (Distilled Knowledge) แทนที่จะเป็นน้ำหนักโมเดล (Model Weights) ในขณะที่บางแนวทางจะตรึง (Freeze) ส่วน backbone ของโมเดลที่ได้รับการฝึกฝนล่วงหน้าไว้ แล้วจึงรวมเฉพาะส่วนประกอบที่สามารถฝึกฝนได้ซึ่งมีขนาดเล็กกว่า

เมื่อจำเป็นต้องมีการอัปเดตที่ใหญ่ขึ้น ระบบก็ต้องรองรับการสตรีมและการรวมข้อมูลที่ใช้หน่วยความจำอย่างมีประสิทธิภาพ NVIDIA FLARE ซึ่งเป็น SDK และเฟรมเวิร์กแบบโอเพนซอร์สที่ขยายได้สำหรับ Federated Learning และการประมวลผลร่วมกัน สามารถรองรับรูปแบบการสื่อสารทั้งแบบ Parameter-Efficient (เช่น การใช้ Adapter) และแบบ Full-Model ได้

การประสานงานการฝึกฝนระหว่างไคลเอนต์

NVIDIA FLARE แยกการประสานงานส่วนกลาง (Global Coordination) ออกจากการดำเนินการในแต่ละไซต์ (Local Execution) อย่างชัดเจน โดยเซิร์ฟเวอร์จะทำหน้าที่กำหนดตารางรอบการฝึกฝน (Rounds) และรวบรวมการอัปเดต ในขณะที่แต่ละไคลเอนต์จะทำการฝึกฝนหรือประเมินผลโดยใช้ข้อมูลในเครื่องของตนเอง การประมวลผลล่วงหน้า (Preprocessing) การสร้างพรอมต์ (Prompt Construction) และการจัดกลุ่มข้อมูล (Batching) จะยังคงอยู่ภายในไคลเอนต์

API ที่ชื่อว่า Recipe API ของ NVIDIA FLARE เป็นจุดเริ่มต้นที่กระชับ โดยสูตร FedAvg จะจับคู่โมเดลเข้ากับสคริปต์การฝึกฝนของไคลเอนต์ ซึ่งสูตรเดียวกันนี้สามารถนำไปใช้ในการจำลอง (Simulation) หรือการติดตั้งใช้งานจริงแบบหลายไซต์ได้

ก่อนที่จะเริ่มการเขียนโค้ดโมเดล ควรมีการกำหนด "สัญญาการอัปเดตของไคลเอนต์" (Client Update Contract) ซึ่งระบุว่า:

• ข้อมูลส่วนใดจะยังคงอยู่ภายในเครื่อง (Local)
• ข้อมูลส่วนใดที่อาจถูกส่งออกจากไซต์ได้
• ส่วนประกอบโมเดลใดบ้างที่แต่ละไคลเอนต์สามารถอัปเดตได้
• เมตริกใดบ้างที่จะส่งกลับไปยังเซิร์ฟเวอร์
• เมื่อไคลเอนต์อัปเดตส่วนประกอบโมเดลที่แตกต่างกัน สัญญาดังกล่าวควรกำหนดวิธีการรวมการอัปเดตระดับส่วนประกอบเหล่านั้นเข้าด้วยกันด้วย

การเคลื่อนย้ายและรวมการอัปเดตโมเดลขนาดใหญ่ให้มีประสิทธิภาพ

วิธีการพื้นฐานที่นิยมใช้ในการฝึกฝน VLM แบบสหพันธ์ คือการปรับแต่ง (Fine-tuning) และรวมพารามิเตอร์โมเดลทั้งหมด ซึ่งจะส่งผลให้การอัปเดตโมเดลมีขนาดใหญ่ เมื่อมีไคลเอนต์จำนวนมากเข้าร่วมในการทำ Federation จะเกิดแรงกดดันต่อหน่วยความจำสองประการหลักๆ คือ การแปลงเป็นซีเรียลและถ่ายโอนการอัปเดตหนึ่งครั้ง และการเก็บการอัปเดตจากหลายไคลเอนต์ไว้ในหน่วยความจำระหว่างการรวม NVIDIA FLARE รองรับคุณสมบัติหลายประการเพื่อจัดการกับความท้าทายนี้

1. ทำให้วัตถุขนาดใหญ่เป็นภายนอก (Externalize Large Objects)

NVIDIA FLARE สามารถแทนที่วัตถุขนาดใหญ่ในข้อความด้วยการอ้างอิงที่มีน้ำหนักเบา และถ่ายโอนข้อมูลจริงแยกต่างหาก วิธีนี้ช่วยให้ข้อความควบคุม (Control Message) มีขนาดเล็ก และรองรับเพย์โหลด (Payload) ที่เกินขีดจำกัดของข้อความที่ถูกแปลงเป็นซีเรียลตามปกติ โมดูลที่สร้างไว้ล่วงหน้า (Built-in decomposers) รองรับ PyTorch tensors, NumPy arrays และโครงสร้าง FLARE ทั่วไป การสร้าง decomposer แบบกำหนดเองจะจำเป็นเฉพาะสำหรับประเภทวัตถุที่เฉพาะเจาะจงของแอปพลิเคชันเท่านั้น

สำหรับเวิร์กโฟลว์ PyTorch, FLARE Tensor Downloader จะสตรีมเทนเซอร์แบบค่อยเป็นค่อยไปโดยใช้โปรโตคอลแบบดึง (Pull-based protocol) โดยจะมีการแปลงเป็นซีเรียลเพียงบางส่วนในแต่ละครั้ง ซึ่งช่วยลดหน่วยความจำสูงสุด (Peak Memory) ระหว่างการกระจายโมเดล ขนาดของชิ้นส่วน (Chunk size) สามารถปรับได้เพื่อสร้างสมดุลระหว่างค่าใช้จ่ายในการร้องขอ (Request Overhead) กับหน่วยความจำต่อชิ้นส่วน

2. การใช้ดิสก์ช่วยในการรวมข้อมูล (Offload Aggregation to Disk)

การสตรีมช่วยลดแรงกดดันต่อหน่วยความจำระหว่างการถ่ายโอน แต่เซิร์ฟเวอร์อาจยังคงต้องเก็บการอัปเดตจากหลายไคลเอนต์ไว้ในหน่วยความจำระหว่างการรวม ซึ่งอาจทำให้หน่วยความจำสูงสุดของเซิร์ฟเวอร์เพิ่มขึ้นตามจำนวนไคลเอนต์ ใน NVIDIA FLARE เวอร์ชัน 2.8.0 เป็นต้นมา Tensor Disk Offload จะเขียนการอัปเดต FedAvg ของ PyTorch ที่เข้ามาไปยังไฟล์ safetensors ชั่วคราว และโหลดข้อมูลเมื่อจำเป็น วิธีนี้ช่วยป้องกันไม่ให้หน่วยความจำ CPU เพิ่มขึ้นตามสัดส่วนเชิงเส้น

กลไกเหล่านี้จะช่วยเสริมการลดเพย์โหลดจากการฝึกฝนแบบใช้ Adapter (Adapter-based training) เพื่อเปิดใช้งานการฝึกฝนแบบ Full-model, การใช้ Adapter ที่มีขนาดใหญ่ขึ้น หรือ Federated Learning ที่มีไคลเอนต์จำนวนมาก

การทำ Federation สำหรับ Adapter ขนาดเล็กบน VLM ที่ตรึงไว้ด้วย FedUMM

FedUMM เป็นตัวอย่างที่จับต้องได้ในการลดขนาดข้อมูลที่ต้องส่งข้ามเครือข่ายใน NVIDIA FLARE โดยแต่ละไคลเอนต์ที่จำลองขึ้นจะรักษา backbone ของโมเดล BLIP ที่ถูกตรึงไว้ และทำการฝึกฝน Adapter ในระดับท้องถิ่น NVIDIA FLARE จะทำหน้าที่ประสานงานรอบการฝึกฝนและรวมเฉพาะการอัปเดต Adapter เท่านั้น FedUMM ได้รับการออกแบบมาเพื่อความยืดหยุ่น โดยมีตัวเข้ารหัสเฉพาะสำหรับแต่ละรูปแบบข้อมูล (Modality-specific encoders) สำหรับภาพ เสียง และข้อความ แม้ว่าการทดลองในปัจจุบันจะเน้นไปที่การประมวลผลภาพและข้อความก็ตาม

การทดลองที่รายงานได้ประเมินโมเดลบนชุดข้อมูล VQA v2 และ GenEval ภายใต้สภาวะความไม่สม่ำเสมอของข้อมูลที่ควบคุมโดย Dirichlet (Dirichlet-controlled heterogeneity) ด้วยไคลเอนต์สูงสุด 16 ราย ในการเปรียบเทียบกับไคลเอนต์ 8 ราย การทำ Federation เฉพาะ Adapter ช่วยลดการสื่อสารต่อไคลเอนต์จาก 28.6 GB เหลือเพียง 0.094 GB ต่อรอบ และปรับปรุงประสิทธิภาพบน VQA v2 ได้ 0.7 คะแนน เมื่อเทียบกับ FedAvg แบบ Full-model ที่ไคลเอนต์ 8 ราย ประสิทธิภาพยังคงอยู่ที่ประมาณ 97% ของการอ้างอิงแบบรวมศูนย์ในทั้งสองเกณฑ์มาตรฐาน

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

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

Checklist สำหรับการออกแบบ Federated Multimodal AI Workflows

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

1. กำหนดสัญญาการอัปเดต (Define the Update Contract): ตัดสินใจว่าอะไรจะยังคงอยู่ภายในเครื่อง (Local) อะไรที่แต่ละไคลเอนต์จะส่งกลับมา และจะรวมการอัปเดตเหล่านั้นเข้าด้วยกันอย่างไร
2. ลดขนาดเพย์โหลด (Minimize the Payload): เลือกแลกเปลี่ยน Adapter ที่มีน้ำหนักเบาเมื่อเป็นไปได้ และใช้การอัปเดตแบบ Full-model เฉพาะเมื่อจำเป็นสำหรับงานนั้นๆ
3. เลือกวิธีการเคลื่อนย้ายและรวมการอัปเดต (Choose how Updates Move and Aggregate): ใช้ Externalization และ Tensor Streaming สำหรับการอัปเดตขนาดใหญ่ที่อยู่ในหน่วยความจำ ร่วมกับการใช้ Disk Offload บนเซิร์ฟเวอร์ เมื่อการรวมการอัปเดตหลายรายการอาจเกินขีดจำกัดหน่วยความจำของเซิร์ฟเวอร์
4. ประเมินแบบ End-to-End (Evaluate End-to-End): วัดคุณภาพของโมเดล ควบคู่ไปกับการสื่อสาร เวลาประมวลผล การใช้หน่วยความจำ ความไม่สม่ำเสมอของข้อมูล และข้อผิดพลาดที่อาจเกิดขึ้น

เริ่มต้นสร้าง Federated Multimodal AI Workflows

เริ่มต้นด้วยการกำหนดสัญญาการอัปเดตสำหรับเวิร์กโฟลว์ของคุณ: อะไรจะยังคงอยู่ภายในเครื่อง, สถานะโมเดลใดบ้างที่แต่ละไคลเอนต์สามารถส่งกลับมาได้, และไคลเอนต์ใดบ้างที่ควรมีส่วนร่วมในการรวมข้อมูลแต่ละครั้ง ใช้ NVIDIA FLARE Recipe API เพื่อนำเวิร์กโฟลว์ไปใช้งานและตรวจสอบความถูกต้องในการจำลองด้วยจำนวนไคลเอนต์ที่คาดหวัง

ถัดไป เลือกกลไกการจัดการเพย์โหลดที่ตรงกับคอขวด (Bottleneck) ของคุณ ใช้ Large-Object Externalization และ FLARE Tensor Downloader สำหรับการอัปเดตโมเดลขนาดใหญ่ ควบคู่ไปกับการใช้ Tensor Disk Offload เมื่อหน่วยความจำในการรวมข้อมูลฝั่งเซิร์ฟเวอร์กลายเป็นข้อจำกัด

สำหรับตัวอย่างที่จับต้องได้ของการฝึกฝนแบบใช้

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/

UMAP ขนาดใหญ่ ทำงานเร็วขึ้นด้วย Multi-GPU: ลดเวลาประมวลผลโดยไม่เสียความแม่นยำ

Uniform Manifold Approximation and Projection (UMAP) เป็นเทคนิคการลดมิติข้อมูลที่ได้รับความนิยมอย่างแพร่หลายสำหรับการแสดงภาพข้อมูล (Visualization) และการสกัดคุณลักษณะ (Feature Extraction) การใช้งาน UMAP นั้นครอบคลุมหลากหลายด้าน ตั้งแต่การวิเคราะห์ข้อมูลเชิงสำรวจ (Exploratory Data Analysis) การสร้างแบบจำลองหัวข้อ (Topic Modeling) ไปจนถึงการวิเคราะห์เซลล์เดี่ยว (Single-cell Analysis)

ในโลกของการวิเคราะห์ข้อมูลที่ข้อมูลมีขนาดใหญ่ขึ้นเรื่อย ๆ กระบวนการ UMAP มักต้องทำซ้ำหลายครั้งเพื่อสำรวจข้อมูลหรือปรับแต่งพารามิเตอร์ ยิ่งชุดข้อมูลมีขนาดใหญ่ขึ้นเท่าใด ต้นทุนในการประมวลผล UMAP แต่ละครั้งก็จะยิ่งสูงขึ้น ทำให้การสำรวจข้อมูลแบบโต้ตอบ (Interactive Exploration) และการวิเคราะห์แบบซ้ำ ๆ ทำได้ยากขึ้น

กุญแจสำคัญ: การสร้างกราฟ kNN แบบ All-Neighbors

หัวใจสำคัญของอัลกอริทึม UMAP คือการสร้างกราฟ k-Nearest Neighbors (kNN) แบบ "all-neighbors" ซึ่งหมายถึงการค้นหาเพื่อนบ้านที่ใกล้ที่สุด k อันดับแรกสำหรับทุกจุดข้อมูลในชุดข้อมูล การสร้างกราฟแบบนี้จะมีความซับซ้อนและใช้ทรัพยากรสูงขึ้นอย่างมาก เมื่อชุดข้อมูลมีขนาดใหญ่ถึงหลักสิบล้านหรือหลายร้อยล้านจุด

NVIDIA cuML และ cuVS: พลิกโฉม UMAP ด้วย Multi-GPU

NVIDIA ได้เปิดตัวฟีเจอร์ใหม่ใน NVIDIA cuML และ NVIDIA cuVS เวอร์ชัน 25.06 ที่ช่วยแก้ปัญหาคอขวดนี้ ด้วยการรองรับการประมวลผลแบบหลาย GPU (Multi-GPU) สำหรับการสร้างกราฟ kNN แบบ all-neighbors ซึ่งช่วยให้สามารถประมวลผล UMAP ได้อย่างมีประสิทธิภาพเต็มรูปแบบ และลดระยะเวลาการทำงานลงอย่างมหาศาล สำหรับชุดข้อมูลที่มีเวกเตอร์หลายสิบล้านถึงหลายร้อยล้าน

UMAP ทำงานบน Multi-GPU ได้อย่างไร?

แนวคิดหลักเบื้องหลังการประมวลผล UMAP ขนาดใหญ่ด้วย Multi-GPU คือการสร้างกราฟ kNN แบบ all-neighbors โดยไม่ต้องให้ชุดข้อมูลทั้งหมดต้องอยู่ในหน่วยความจำ GPU พร้อมกัน วิธีการนี้ทำได้โดยการแบ่งชุดข้อมูลออกเป็นกลุ่มย่อย (Clusters) ที่มีความสมดุล และมีการทับซ้อนกันของเวกเตอร์ระหว่างกลุ่มที่อยู่ใกล้เคียงกัน เพื่อรักษาความสัมพันธ์ของเพื่อนบ้านที่ใกล้ที่สุดข้ามขอบเขตของกลุ่ม

จากนั้น กราฟ kNN จะถูกคำนวณแยกกันสำหรับแต่ละกลุ่มย่อย และนำกราฟเหล่านี้มารวมกันเพื่อสร้างเป็นกราฟ all-neighbors ระดับโลก (Global) การทำเช่นนี้ทำให้สามารถกระจายการคำนวณไปยัง GPU หลายตัวได้ โดยไม่จำเป็นต้องมีการสื่อสารแบบ "all-to-all" ที่ซับซ้อน ซึ่งมักเป็นข้อจำกัดของการประมวลผลแบบกระจายในงานที่ต้องสร้างกราฟ all-neighbors

การปรับแต่ง UMAP สำหรับ Multi-GPU

การตั้งค่า UMAP สำหรับ Multi-GPU จะเหมือนกับการใช้งาน UMAP บน GPU เดี่ยว โดยมีพารามิเตอร์สำคัญสองตัวที่ช่วยในการปรับสมดุลระหว่างพื้นที่ (Space), เวลา (Time), และคุณภาพ (Quality) ดังนี้:

• knnnclusters: จำนวนกลุ่มย่อยที่ข้อมูลจะถูกแบ่งออก การเพิ่มค่านี้จะลดจำนวนจุดข้อมูลในแต่ละกลุ่ม ทำให้ข้อมูลที่ต้องโหลดเข้าหน่วยความจำ GPU ของแต่ละตัวน้อยลง
• knnoverlapfactor: ปัจจัยการทับซ้อนของจุดข้อมูลระหว่างกลุ่มที่อยู่ใกล้เคียงกัน การเพิ่มค่านี้จะช่วยรักษาความสัมพันธ์ของเพื่อนบ้านที่ใกล้ที่สุดได้ดียิ่งขึ้น ส่งผลให้คุณภาพของกราฟ kNN และผลลัพธ์ UMAP ดีขึ้น แต่ก็จะเพิ่มเวลาและหน่วยความจำที่ใช้ในการประมวลผล

การปรับค่า knnnclusters และ knnoverlapfactor ร่วมกัน จะช่วยให้สามารถควบคุมการแลกเปลี่ยนระหว่างทรัพยากรและคุณภาพได้อย่างมีประสิทธิภาพ

ข้อควรพิจารณาในการตั้งค่าจริง

• ค่าเริ่มต้นที่ดี: knnoverlapfactor=2 มักเป็นจุดเริ่มต้นที่ดีสำหรับผลลัพธ์ที่มีคุณภาพ
• การปรับเพิ่ม: การเพิ่มค่า knnoverlapfactor ทีละน้อย (เช่น 2 -> 3 -> 4) จะได้ผลดีกับชุดข้อมูลขนาดปานกลาง
• ชุดข้อมูลขนาดใหญ่: สำหรับชุดข้อมูลที่ใหญ่มากและมี knnnclusters สูง (มากกว่า 100) อาจได้ประโยชน์จากการเพิ่ม knnoverlapfactor ในสัดส่วนที่มากขึ้น (เช่น 2 -> 4 -> 6)
• การจัดการหน่วยความจำ: เพื่อรักษาการใช้หน่วยความจำให้คงที่ พร้อมทั้งปรับปรุงคุณภาพ ควรเพิ่ม knnoverlapfactor และเพิ่ม knnnclusters ไปพร้อม ๆ กัน

การใช้งาน Multi-GPU UMAP ใน NVIDIA cuML

การใช้งาน Multi-GPU UMAP ใน NVIDIA cuML ทำได้ง่าย เพียงแค่กำหนดค่าเพิ่มเติมเล็กน้อย นอกเหนือจากการใช้งาน cuML UMAP แบบเดิม

• device_ids: ระบุ ID ของ GPU ที่ต้องการให้เข้าร่วมในการประมวลผล
• knnnclusters และ knnoverlapfactor: ใช้ควบคุมการสร้างกราฟ kNN แบบ all-neighbors

การเพิ่มจำนวน GPU จะช่วยลดเวลาประมวลผลได้โดยการกระจายการสร้างกราฟ all-neighbors ไปยังอุปกรณ์ต่าง ๆ

ผลลัพธ์ที่น่าประทับใจ

การทดสอบประสิทธิภาพบนชุดข้อมูลขนาดใหญ่ เช่น MIRACL และ Wiki ด้วย GPU NVIDIA H100 จำนวน 8 ตัว แสดงให้เห็นถึงความเร็วที่เพิ่มขึ้นถึง 74 เท่า เมื่อเทียบกับการประมวลผลด้วย CPU ทำให้ UMAP สามารถทำงานกับชุดข้อมูลขนาดหลายร้อยกิกะไบต์ได้ภายในเวลาเพียงไม่กี่นาที แทนที่จะเป็นชั่วโมงหรือวัน อีกทั้งยังคงรักษาคะแนนความน่าเชื่อถือ (Trustworthiness Score) ของผลลัพธ์การฝังตัว (Embeddings) ไว้ได้อย่างสูง

การแสดงภาพข้อมูลขนาดใหญ่ด้วย UMAP

การเปรียบเทียบผลลัพธ์การฝังตัว (Embeddings) ที่สร้างขึ้นจากชุดข้อมูล MIRACL ขนาด 106 ล้านเวกเตอร์ x 2048 มิติ โดยใช้การประมวลผลบน CPU เทียบกับการใช้ cuML UMAP แบบ Multi-GPU แสดงให้เห็นว่า ผลลัพธ์ที่ได้มีการรักษาโครงสร้างโดยรวม (Global Structure) ไว้ได้เป็นอย่างดี แม้ว่าภาพอาจดูแตกต่างกันเล็กน้อยเนื่องจากการแปลงสเกล การเลื่อนตำแหน่ง หรือการหมุน

ผลลัพธ์ที่ได้นี้ยืนยันว่าการสร้างกราฟ all-neighbors บน GPU สามารถรักษาความสัมพันธ์ของเพื่อนบ้านที่จำเป็นต่อการสร้างภาพข้อมูลคุณภาพสูง แม้ในระดับสเกลที่ใหญ่มากก็ตาม

สรุป

NVIDIA cuML และ cuVS ได้นำพา UMAP ไปสู่อีกระดับ ด้วยการรองรับ Multi-GPU ที่ช่วยให้การประมวลผลข้อมูลขนาดใหญ่ทำได้รวดเร็วขึ้นอย่างก้าวกระโดด โดยไม่สูญเสียความแม่นยำหรือคุณภาพของผลลัพธ์ นี่คือเครื่องมือสำคัญที่จะช่วยให้นักวิเคราะห์ข้อมูลสามารถสำรวจและทำความเข้าใจชุดข้อมูลที่มีขนาดมหึมาได้อย่างมีประสิทธิภาพยิ่งขึ้น

#UMAP #MultiGPU #NVIDIA #cuML #DataScience #MachineLearning

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/run-massive-scale-umap-in-minutes-using-multiple-gpus-without-losing-accuracy/

ปลดล็อกการจำลองวัสดุด้วย AI Coding Agents และ NVIDIA ALCHEMI Toolkit

การจำลองระดับอะตอม (Atomistic simulation) เป็นหัวใจสำคัญของการพัฒนาวัสดุและวิทยาศาสตร์แขนงต่าง ๆ ซึ่งจำเป็นต้องอาศัยองค์ประกอบสำคัญ 3 ประการ ได้แก่ ความรู้ความเข้าใจในหลักการทางวิทยาศาสตร์, การนำโค้ดไปใช้งานได้อย่างมีประสิทธิภาพบนฮาร์ดแวร์ที่ทรงพลัง, และการเข้าถึงอินเทอร์เฟซที่ใช้งานง่ายสำหรับกระบวนการจำลอง

NVIDIA ALCHEMI Toolkit ซึ่งเปิดตัวไปเมื่อต้นปี 2026 ได้เข้ามาช่วยลดอุปสรรคด้านการนำโค้ดไปใช้งานอย่างมีประสิทธิภาพสำหรับ Machine Learning Interatomic Potentials (MLIP) ด้วยการสร้างเวิร์กโฟลว์ที่สามารถประกอบกันได้ (composable) รองรับ PyTorch-native และเร่งความเร็วด้วย GPU โดยใช้ AI coding agents ร่วมกับ reference files เพื่อเชื่อมโยงระหว่างคำสั่งที่เป็นภาษาธรรมชาติ (natural-language prompts) กับการสร้างโค้ดจำลองที่แข็งแกร่งบน NVIDIA GPUs

AI Coding Agents: สะพานเชื่อมสู่การจำลองที่ซับซ้อน

แม้ว่า AI coding agents จะสามารถสร้างและประมวลผลโค้ดจากคำอธิบายที่เป็นภาษาธรรมชาติได้ แต่เอเจนต์ทั่วไปอาจไม่คุ้นเคยกับ API ของ ALCHEMI Toolkit โดยตรง และอาจสร้างโค้ดที่ดูเหมือนจะใช้งานได้ แต่จริง ๆ แล้วไม่ได้ใช้ API อย่างถูกต้อง

ALCHEMI Toolkit จึงมาพร้อมกับ agent skills และ reference files ที่ช่วยเติมเต็มช่องว่างของ API โดยอัตโนมัติ ทำให้ผู้ใช้สามารถมุ่งเน้นไปที่วิทยาศาสตร์ที่ต้องการจำลอง เช่น ชนิดของวัสดุ, สภาวะแวดล้อม, และข้อจำกัดของโปรโตคอลการจำลอง

การสร้างเวิร์กโฟลว์การจำลองด้วย AI Coding Agent

กระบวนการทำงานร่วมกับ ALCHEMI Toolkit และ AI coding agent จะเริ่มต้นจากการที่นักวิจัยป้อนคำสั่ง (prompt) ซึ่งจะถูกนำไปสร้างเป็นโค้ดและไปป์ไลน์การจำลอง โดยผลลัพธ์ที่ได้จะถูกนำไปตรวจสอบความถูกต้องบน NVIDIA H200 GPUs

การทดสอบเชิงระบบ (systematic benchmarks) กับ 45 ไปป์ไลน์ที่แตกต่างกัน แสดงให้เห็นว่ารายละเอียดของ prompt มีผลต่อโครงสร้างและความสามารถในการนำโค้ดกลับมาใช้ซ้ำ (reusability) แต่ไม่มีผลต่อความถูกต้องทางฟิสิกส์ โดยทุกเวิร์กโฟลว์ที่ทดสอบ เช่น equation of state ของซิลิคอน, การดูดซับออกซิเจนบน Cu(111), และการแพร่ของลิเทียม (Li self-diffusion) ล้วนให้ผลลัพธ์ที่สอดคล้องกับข้อมูลอ้างอิงเมื่อตรวจสอบบน NVIDIA H200 GPUs

ข้อกำหนดระบบและแพ็กเกจที่จำเป็น

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

• CUDA: เวอร์ชัน 12 หรือ 13 พร้อมไดรเวอร์ NVIDIA ที่เข้ากันได้ (แนะนำ 570+)
• ระบบปฏิบัติการ: Linux (หลัก), macOS
• NVIDIA GPU: RTX 20xx หรือใหม่กว่า, CUDA Compute Capability ≥ 7.0
• RAM: ขั้นต่ำ 4 GB (แนะนำ 16 GB สำหรับระบบขนาดใหญ่)

การติดตั้ง Toolkit ในสภาพแวดล้อม Python ที่สามารถรันได้ และปล่อยให้เอเจนต์ดำเนินการสคริปต์ที่สร้างขึ้น จะช่วยลดข้อผิดพลาดทางกล (mechanical errors) ได้อย่างมาก

ขั้นตอนการติดตั้งและการตั้งค่า

1. สร้างสภาพแวดล้อม Python และติดตั้ง ALCHEMI Toolkit:

ใช้ uv package manager และเลือก extra ที่ตรงกับสภาพแวดล้อม CUDA ของคุณ เช่น สำหรับ CUDA 13 ให้ติดตั้ง nvalchemi-toolkit[mace,ase,cu13]==0.2.0

1. ดาวน์โหลด agent skills:

ต้องตรงกับเวอร์ชัน API ของ Toolkit ที่ติดตั้ง

1. ติดตั้ง AI Coding Agent:

รองรับเอเจนต์ที่รองรับมาตรฐาน open Agent Skills เช่น Claude Code, Cursor, หรือ OpenCode

แนวทางปฏิบัติที่ดีที่สุดสำหรับการเขียน Prompt ที่มีประสิทธิภาพ

การเขียน prompt ที่ดีคือหัวใจสำคัญที่จะช่วยให้ AI coding agent สร้างโค้ดที่น่าเชื่อถือและมีประสิทธิภาพ โดยมีหลักการที่สังเคราะห์ได้จากการวัดผลลัพธ์คุณภาพต่างๆ ดังนี้:

• ระบุชื่อระบบ, วิธีการ, และสเกลเสมอ: การระบุวัสดุ, วิธีการ, และสเกลของการจำลองอย่างชัดเจน ช่วยให้ได้ผลลัพธ์ที่ดีที่สุด การเพิ่ม CLI contract จะช่วยให้โค้ดสามารถนำกลับมาใช้ซ้ำได้ง่ายขึ้น แต่ก็เพิ่มจำนวน token และความยาวของโค้ด
• ระบุวัสดุ, เฟส, และ convention ของการอ้างอิงอย่างชัดเจน: การระบุรายละเอียดเหล่านี้อย่างครบถ้วนจะช่วยหลีกเลี่ยงความผิดพลาดทางฟิสิกส์ที่เกิดจากการตีความที่ไม่ถูกต้อง
• ระบุข้อจำกัด (constraint) ไม่ใช่การนำไปใช้ (implementation): อธิบายว่าสคริปต์ควรทำอะไร แทนที่จะระบุคลาส API ภายใน การระบุ API pattern ควรมาจากตัวอย่างและ skills ที่มีอยู่
• ขอให้มีการประเมินตนเองและตรวจสอบสมมติฐานอย่างชัดเจน: เอเจนต์อาจไม่ได้ตั้งคำถามเกี่ยวกับความสมเหตุสมผลทางฟิสิกส์ของงานที่ร้องขอ ควรขอให้มีการตรวจสอบสมมติฐาน, การตรวจสอบความถูกต้อง, และการประมาณค่าความไม่แน่นอนเสมอ

ตัวอย่างเวิร์กโฟลว์ 3 แบบ จาก Prompt สู่การทำงานบน GPU

1. Bulk Silicon Equation of State (EOS)

• งาน: คำนวณสมการสถานะของซิลิคอนในรูปเพชร-ลูกบาศก์ (diamond-cubic)
• ผลลัพธ์: ผลการคำนวณค่า lattice constant (a0) และ bulk modulus (B0) สอดคล้องกับค่าอ้างอิง PBE อย่างแม่นยำ แสดงให้เห็นว่าความเฉพาะเจาะจงของ prompt มีผลต่อโครงสร้างและต้นทุนของโค้ด แต่ไม่ส่งผลต่อหลักการทางฟิสิกส์

2. Oxygen Adsorption on Cu(111)

• งาน: จัดอันดับตำแหน่งการดูดซับสำหรับอะตอมออกซิเจนบนพื้นผิว Cu(111)
• ผลลัพธ์: ทุกระดับ prompt สามารถระบุตำแหน่ง fcc hollow ได้ว่าเป็นตำแหน่งที่มีความเสถียรที่สุด โดยมีค่า Eads ใกล้เคียงกัน แสดงให้เห็นถึงความแม่นยำของผลลัพธ์เมื่อใช้ convention การอ้างอิงที่ชัดเจน

3. Lithium Self-Diffusion via Molecular Dynamics (MD)

• งาน: ประเมินค่าสัมประสิทธิ์การแพร่ของลิเทียมเหลว (self-diffusion coefficient D)
• ผลลัพธ์: กระบวนการสามารถจำลองการแพร่ที่อุณหภูมิต่างๆ และคำนวณค่า D จาก mean-squared displacement (MSD) ได้อย่างถูกต้อง

ข้อค้นพบจากการทดสอบเชิงระบบ

การทดสอบ systematic benchmark ได้ให้ข้อค้นพบที่สำคัญ 3 ประการ:

1. ความเฉพาะเจาะจงของ Prompt ส่งผลต่อโครงสร้างโค้ด: แม้ว่าความถูกต้องทางวิทยาศาสตร์จะคงที่ แต่ prompt ที่ละเอียดขึ้นช่วยเพิ่มการครอบคลุม API pattern และความสามารถในการนำโค้ดกลับมาใช้ซ้ำ
2. เอเจนต์มักเลือกใช้อัลกอริทึมที่คุ้นเคย: เอเจนต์จะใช้สิ่งที่ปรากฏในตัวอย่างและ skills ที่มีอยู่ หากไม่มีข้อมูล เอเจนต์จะใช้ความรู้จากการ pretraining ซึ่งอาจไม่ใช่แนวทางที่ดีที่สุดเสมอไป
3. การทำงานบนฮาร์ดแวร์จริงเผยให้เห็นข้อผิดพลาด: การรันสคริปต์บน GPU ช่วยตรวจจับข้อผิดพลาดที่การทดสอบบน CPU ไม่สามารถหาเจอได้ การตรวจสอบความถูกต้องบนฮาร์ดแวร์เป้าหมายจึงยังคงมีความสำคัญ

ข้อควรระวัง: ความสำคัญของวิจารณญาณทางวิทยาศาสตร์

แม้ว่า AI coding agents และ ALCHEMI Toolkit จะช่วยให้กระบวนการจำลองมีประสิทธิภาพมากขึ้น แต่สิ่งสำคัญคือ วิจารณญาณทางวิทยาศาสตร์ยังคงเป็นสิ่งจำเป็น

• การตรวจสอบความถูกต้องด้วยตนเอง: เอเจนต์ไม่สามารถตรวจสอบความสมเหตุสมผลทางฟิสิกส์ของงานที่ร้องขอได้ นักวิจัยต้องตรวจสอบให้แน่ใจว่าสิ่งที่ร้องขอสามารถวัดผลได้จริงภายใต้เงื่อนไขการจำลอง
• การตรวจสอบข้อมูล: MLIP models อาจมีความแม่นยำแปรผันนอกเหนือจากโดเมนการฝึกฝน การตรวจสอบผลลัพธ์เทียบกับข้อมูลการทดลองหรือ DFT จึงเป็นสิ่งสำคัญ

ALCHEMI Toolkit และ AI coding agents เป็นเครื่องมือที่ทรงพลังในการเร่งการค้นพบทางวิทยาศาสตร์ แต่การใช้งานอย่างชาญฉลาดและรอบคอบ จะนำไปสู่ผลลัพธ์ที่น่าเชื่อถือและมีคุณค่าสูงสุด

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/how-ai-coding-agents-can-unlock-materials-simulation-with-nvidia-alchemi-toolkit/

พัฒนาโมเดล Nemotron 3.5 Lightning NVFP4 ด้วย QAD ผ่าน NVIDIA Model Optimizer

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

หนึ่งในความก้าวหน้าล่าสุดคือ Nemotron 3.5 Lightning NVFP4 ที่สามารถรักษาความแม่นยำไว้ได้ใกล้เคียงกับต้นฉบับ BF16 แต่เพิ่ม Throughput ได้ถึง 4 เท่า และลดขนาดโมเดลจาก 66 GB เหลือเพียง 22 GB ซึ่งทั้งหมดนี้ทำได้ด้วยเทคนิคการลดขนาดโมเดล (Quantization) ที่เข้มข้นขึ้น

Quantization-Aware Distillation (QAD) คืออะไร?

QAD เป็นกระบวนการที่ช่วยให้โมเดลที่ถูกลดขนาด (Student Model) สามารถเรียนรู้และรักษาความแม่นยำใกล้เคียงกับโมเดลต้นฉบับที่มีความละเอียดสูง (Teacher Model) ได้ดียิ่งขึ้น โดยมีขั้นตอนหลัก 2 ระยะ:

1. Post-Training Quantization (PTQ): ในขั้นตอนนี้ โมเดลต้นฉบับที่มีความละเอียดเต็ม (Full-Precision) จะถูกแปลงเป็นโมเดลที่มีความละเอียดต่ำ (Quantized Model) เพื่อสร้าง Student Checkpoint
2. Quantization-Aware Distillation (QAD): จากนั้น Student Model จะถูกฝึกฝนอีกครั้ง โดยใช้ Teacher Model แบบคงที่ (Frozen Teacher) เป็นต้นแบบในการเรียนรู้ ผ่านการเปรียบเทียบค่า Logits ด้วย KL Divergence Loss และการจำลองกระบวนการ Quantization เพื่อชดเชยความแม่นยำที่สูญเสียไปจากการลดขนาดอย่างเข้มข้น

ประโยชน์ของ QAD

• เพิ่ม Throughput สูงสุด 4 เท่า: ทำให้การประมวลผลเร็วขึ้นอย่างเห็นได้ชัด
• ลดขนาดโมเดลอย่างมาก: จาก 66 GB เหลือเพียง 22 GB ช่วยประหยัดพื้นที่จัดเก็บและหน่วยความจำ
• รักษาความแม่นยำ: ชดเชยความผิดพลาดที่เกิดจากการลดขนาดอย่างเข้มข้น ทำให้ได้โมเดลที่มีคุณภาพใกล้เคียงต้นฉบับ
• รองรับการ Quantization ที่เข้มข้น: สามารถใช้การ Quantization ที่มากกว่า PTQ ปกติได้ โดยไม่สูญเสียความแม่นยำจนยอมรับไม่ได้

กระบวนการพัฒนา Nemotron 3.5 Lightning NVFP4 ด้วย QAD

NVIDIA Model Optimizer และ Megatron-Bridge เป็นเครื่องมือสำคัญที่ช่วยให้การทำ QAD กับ Nemotron 3.5 Lightning สามารถทำได้ตั้งแต่ต้นจนจบ ตั้งแต่การเลือกสูตร (Recipe) การฝึกฝน ไปจนถึงการส่งออก Checkpoint ทำให้การนำโมเดล LLM ไปใช้งานจริงที่ประหยัดหน่วยความจำและพลังการประมวลผลเป็นไปได้ง่ายขึ้น

ขั้นตอนที่ 1: การสร้าง PTQ Checkpoint (Student)

เริ่มต้นด้วยโมเดลต้นฉบับ NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16 ซึ่งจะทำหน้าที่เป็น Teacher Model

จากนั้นทำการ Quantization กับโมเดลเดียวกันเพื่อสร้าง Student Checkpoint โดยตั้งเป้าหมายการลดขนาดให้เข้มข้นขึ้น เช่น การ Quantize Mamba Linear Layers ไปที่ W4A16 แทน FP8 ซึ่งจะปลดล็อก Throughput ที่สูงขึ้นโดยไม่ทำให้ความแม่นยำลดลงมากนัก

• เป้าหมายความแม่นยำ: ตั้งเป้าให้เกิดความแม่นยำลดลงเล็กน้อย (ประมาณ 95-99%) ในขั้นตอนนี้ เพราะ QAD จะช่วยกู้คืนความแม่นยำในขั้นตอนต่อไป
• การเลือก Recipe: มี PTQ Recipes ที่หลากหลายให้เลือก โดยพิจารณาจากรูปแบบของ Weight, วิธีการ Calibration, รูปแบบ Mamba In/Out Projection, และรูปแบบ KV Cache
• การทดลอง: จากการทดลอง พบว่าสูตร "fouroversix" ที่มีการ Quantize Mamba Linears ไปที่ W4A16 ให้ผลลัพธ์ที่ดีที่สุดระหว่างความแม่นยำที่ลดลงกับการเพิ่มประสิทธิภาพ Inference

ขั้นตอนที่ 2: การฝึกฝนด้วย QAD

เมื่อได้ Student Checkpoint จาก PTQ แล้ว ขั้นตอนต่อไปคือการฝึกฝนด้วย QAD:

• Sequence Length: การใช้ Sequence Length ที่ยาวขึ้น (เช่น 522K Tokens) มีความสำคัญอย่างยิ่งในการรักษาประสิทธิภาพสำหรับงานที่ต้องการ Context ยาว
• ชุดข้อมูล (Datasets): แนะนำให้เริ่มต้นจากชุดข้อมูลเปิดของ NVIDIA เช่น Nemotron-Post-Training v1 และ v2 ซึ่งมีลักษณะการกระจายข้อมูลคล้ายคลึงกับที่ใช้ในการพัฒนา
• Distillation Recipe:
• เริ่มต้นจาก PTQ Checkpoint
• ทำการ Distill จาก Teacher Model (BF16) ไปยัง Student Model (NVFP4) โดยใช้ KL Divergence Loss บน Logits
• ตั้งค่าการฝึกฝน: Learning Rate 5e-6, ไม่มี Warmup, ปิด Dropout, Gradient Clipping ที่ 1.0, ใช้ 2 Nodes x 8 GPUs (TP=2, EP=4)
• การจัดการ Quantization Scale: มี 2 กลยุทธ์หลัก ขึ้นอยู่กับวิธีการ Calibration ในขั้นตอน PTQ:
• Dynamic Scale QAD: เริ่มต้นจาก PTQ Checkpoint ที่ใช้ Max Calibration โดย Weight และ Scale จะถูกคำนวณใหม่ทุก Step
• Frozen Scale QAD: เริ่มต้นจาก PTQ Checkpoint ที่ใช้ MSE-based Calibration โดย Scale จะถูกล็อคไว้ตั้งแต่แรก และมีการอัปเดตเฉพาะ Weight

การทำ QAD ด้วย NVIDIA Model Optimizer นี้ ช่วยให้สามารถพัฒนาโมเดล Nemotron 3.5 Lightning NVFP4 ที่มีประสิทธิภาพสูง ใช้หน่วยความจำน้อย และยังคงความแม่นยำไว้ได้อย่างยอดเยี่ยม

คำถามที่พบบ่อย (FAQ)

QAD แตกต่างจาก PTQ อย่างไร?

A: PTQ เป็นการลดขนาดโมเดลหลังจากการฝึกฝนเสร็จสิ้นแล้ว ส่วน QAD เป็นกระบวนการที่ซับซ้อนกว่า โดยมีการฝึกฝนโมเดลที่ลดขนาดแล้วอีกครั้ง โดยใช้โมเดลต้นฉบับที่มีความละเอียดสูงเป็นต้นแบบ เพื่อชดเชยความแม่นยำที่สูญเสียไปจากการลดขนาด

Quantization แบบ W4A16 หมายถึงอะไร?

A: หมายถึงการลดขนาด Weight ให้เหลือ 4 บิต และ Activation ให้เหลือ 16 บิต ซึ่งเป็นการลดขนาดที่ค่อนข้างเข้มข้น

การใช้ Nemotron 3.5 Lightning NVFP4 เหมาะกับงานประเภทใด?

A: เหมาะสำหรับงานที่ต้องการประมวลผลเร็ว ใช้หน่วยความจำน้อย และยังคงต้องการความแม่นยำสูง เช่น การประมวลผลภาษาธรรมชาติ (NLP) หรือการสร้างสรรค์เนื้อหา (Generative AI)

NVIDIA Model Optimizer ช่วยอะไรในการทำ QAD?

A: ช่วยอำนวยความสะดวกในกระบวนการทำ QAD ตั้งแต่ต้นจนจบ รวมถึงการเลือกสูตรการฝึกฝน, การกำหนดค่า, และการส่งออก Checkpoint ทำให้การพัฒนาโมเดลมีประสิทธิภาพมากขึ้น

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/developing-nemotron-3-5-lightning-nvfp4-with-qad-using-nvidia-model-optimizer/

Qwen3.8-2.4T-A95B: โมเดล AI ขนาด 2.4 ล้านล้านพารามิเตอร์ พร้อมการให้เหตุผลที่ปรับแต่งได้บน NVIDIA GB300 NVL72

Alibaba ได้เปิดตัวโมเดลภาษาขนาดใหญ่ (LLM) ชื่อ Qwen3.8-2.4T-A95B หรือที่รู้จักในชื่อ Qwen3.8-Max ซึ่งเป็นโมเดลโอเพนเวตที่ใหญ่ที่สุดจาก Alibaba โดยนำความสามารถระดับใกล้เคียงแนวหน้ามาสู่ระบบนิเวศแบบเปิด โมเดลนี้มีพารามิเตอร์รวมถึง 2.4 ล้านล้านพารามิเตอร์ โดยมีการใช้งาน 95 พันล้านพารามิเตอร์ต่อโทเค็น ถูกออกแบบมาสำหรับงานที่ต้องการการให้เหตุผลที่ซับซ้อนและเวิร์กโฟลว์แบบเอเจนต์ (Agentic Workloads) ด้วยสถาปัตยกรรมแบบ Mixture of Experts (MoE) ที่มีรายละเอียดสูง ผสานกับการใช้เทคนิค Attention แบบเต็มรูปแบบและแบบเชิงเส้น (Linear Attention) มีความสามารถในการจัดการ Context Window ได้สูงสุดถึงหนึ่งล้านโทเค็น และมีความยาว Output สูงสุด 128K

การนำโมเดลโอเพนเวตขนาด 2.4 ล้านล้านพารามิเตอร์มาใช้งานจริงนั้น ต้องการพลังประมวลผลระดับ Data Center ที่ได้รับการเร่งความเร็ว (Accelerated Compute) การอนุมาน (Inference) ในระดับนี้ขึ้นอยู่กับการออกแบบร่วมกันอย่างสุดขั้วระหว่างชิป สถาปัตยกรรมระบบ และซอฟต์แวร์ NVIDIA กำลังทำงานร่วมกับระบบนิเวศโอเพนซอร์ส เพื่อนำโมเดลนี้ไปสู่การใช้งานแบบ Multi-node ผ่าน Kernel ที่ปรับให้เหมาะสม, Inference Runtimes และสูตรการให้บริการแบบกระจาย (Distributed Serving Recipes)

นวัตกรรมสถาปัตยกรรมเพื่อการอนุมาน Context ยาว

Qwen3.8-2.4T-A95B ถูกสร้างขึ้นมาเพื่อรองรับเวิร์กโฟลว์แบบเอเจนต์ที่ท้าทายที่สุด เช่น การเขียนโค้ด, การวิเคราะห์เอกสารขนาดใหญ่ และเวิร์กโฟลว์แบบหลายขั้นตอนที่ทำงานต่อเนื่อง ต่างจากโมเดลแชททั่วไปที่ส่ง Prompt เพียงครั้งเดียวและรับ Reply เดียว แอปพลิเคชันแบบเอเจนต์จะสะสมคำสั่งระบบ, ผลลัพธ์จากเครื่องมือ, เอกสารที่ดึงมา, โค้ด, ล็อก และร่องรอยการให้เหตุผลหลายขั้นตอนตลอดเวิร์กโฟลว์ เมื่อ Context ยาวขึ้น Attention, Compute และหน่วยความจำ KV Cache จะกลายเป็นข้อจำกัดที่สำคัญ

สถาปัตยกรรมแบบผสมผสานระหว่าง Full-Attention และ Linear Attention ที่โมเดลใช้ จะช่วยแก้ไขปัญหานี้ โดยในชั้น Full-Attention แต่ละโทเค็นจะสามารถ Attend ไปยังโทเค็นอื่นๆ ได้ทั้งหมด ส่วนในชั้น Linear Attention นั้น KV Cache ที่กำลังเติบโตจะถูกแทนที่ด้วย Recurrent State ที่มีขอบเขตจำกัด ทำให้ Qwen3.8-2.4T-A95B สามารถควบคุมทั้ง Compute และ Memory ให้มีขอบเขตที่จำกัดได้ แม้ Context จะขยายไปถึงหนึ่งล้านโทเค็น

สถาปัตยกรรมแบบ Fine-grained MoE ทำให้การให้บริการโมเดลที่มี 2.4 ล้านล้านพารามิเตอร์มีความเป็นไปได้ แทนที่จะใช้ Expert จำนวนน้อยแต่มีขนาดใหญ่ ความสามารถจะถูกกระจายไปยัง Expert จำนวนมากที่มีขนาดเล็กกว่า ซึ่งช่วยปรับปรุงการเชี่ยวชาญและประสิทธิภาพการ Routing ต่อหน่วย Compute ที่ใช้งาน Router ที่ได้รับการเรียนรู้จะเปิดใช้งานเฉพาะ Expert ที่จำเป็นต่อโทเค็นเท่านั้น ทำให้ค่าใช้จ่ายในการให้บริการสอดคล้องกับพารามิเตอร์ที่ใช้งานจริง ไม่ใช่ทั้งหมด 2.4 ล้านล้านพารามิเตอร์ ส่งผลให้ได้ความสามารถระดับแนวหน้าในราคาที่ถูกกว่าโมเดลแบบ Dense ที่เทียบเคียงกัน

นอกจากนี้ Qwen3.8-2.4T-A95B ยังมีระบบควบคุมการให้เหตุผลในตัว (ระดับ Low/High/XHigh) ที่ช่วยให้นักพัฒนาสามารถปรับความลึกของการอนุมานต่อ Request ได้ โดยแลกเปลี่ยน Compute กับคุณภาพของการให้เหตุผล ขึ้นอยู่กับลักษณะงาน สามารถปรับระดับสูงสำหรับงานที่ต้องการการให้เหตุผลหลายขั้นตอนที่ซับซ้อน หรือปรับระดับต่ำสำหรับงานประมวลผลเอกสารที่ต้องการ Throughput สูง

ประสิทธิภาพที่ปรับให้เหมาะสมของ Qwen3.8-2.4T-A95B บน GB300 NVL72

NVIDIA GB300 NVL72 มาพร้อมสถาปัตยกรรมระดับ Rack ที่รวม GPU NVIDIA Blackwell Ultra จำนวน 72 ตัวไว้ในแพลตฟอร์มเดียว โดเมน NVIDIA NVLink ขนาดใหญ่ 72 GPU นี้ช่วยให้การสื่อสารแบบ All-to-All มีประสิทธิภาพสูงถึง 130 TB/s ขจัดคอขวดที่เกิดขึ้นเมื่อการรับส่งข้อมูลระหว่าง Expert ต้องวิ่งผ่านเครือข่ายแบบ Off-the-shelf ทั่วไป

เมื่อใช้งาน Qwen3.8 2.4T-A95B บน NVIDIA Blackwell GB300 NVL72 แบบ Out-of-the-box สามารถให้ Throughput ได้มากกว่า 4K โทเค็นต่อวินาทีต่อ GPU และมากกว่า 350 โทเค็นต่อวินาทีต่อผู้ใช้ ช่วยให้ AI Factory สามารถรันโมเดลขนาดใหญ่ในระดับ Production ด้วย Throughput สูงและ Latency ต่ำ

การ Post-train Qwen3.8-2.4T-A95B และเลือกเส้นทางการให้บริการ

NVIDIA รองรับ Inference Stack หลากหลายรูปแบบเพื่อตอบสนองความต้องการที่แตกต่างกันของนักพัฒนา SGLang, vLLM และ NVIDIA Dynamo เป็นสูตรการให้บริการแบบโอเพนซอร์สสำหรับนักพัฒนาที่ต้องการการควบคุมประสิทธิภาพที่มากขึ้นบนแพลตฟอร์มที่เร่งความเร็วด้วย NVIDIA

นอกจากนี้ยังสามารถ Deploy ผ่าน NVIDIA NIM ซึ่งเป็น Container การอนุมานแบบ Model-free ที่รองรับการให้บริการโมเดลได้หลากหลาย ดาวน์โหลด Model Weights และ Deploy บน Day-0 เพื่อให้บริการ Checkpoint ที่ผ่านการ Fine-tune และ Scale ไปสู่ระดับ Production ได้

นักพัฒนาสามารถทำการ Post-train โมเดลสำหรับ Use Case เฉพาะทางได้โดยใช้ NVIDIA NeMo AutoModel ซึ่งเป็น Library สำหรับ Fine-tuning แบบ PyTorch-native ที่รองรับ Hugging Face Checkpoint ตั้งแต่วันแรก สามารถ Train ได้โดยตรงบน Checkpoint ที่มีอยู่โดยไม่ต้องแปลงโมเดล พร้อมรองรับการ Fine-tuning แบบ Full SFT หรือแบบประหยัดหน่วยความจำอย่าง LoRA

เริ่มต้นใช้งาน Qwen3.8-2.4T-A95B

ดาวน์โหลด Qwen3.8-2.4T-A95B Model Weights ได้จาก Hugging Face หรือ ModelScope และ Deploy ด้วย NVIDIA NIM แบบ Model-free จาก NVIDIA NGC

#AI #LLM #NVIDIA #Qwen

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/serve-qwen3-8-2-4t-a95b-a-2-4t-parameter-model-with-configurable-reasoning-on-nvidia-gb300-nvl72/

เลือกเครื่องมือ Observability สำหรับ NVIDIA AI Factories อย่างไรให้มีประสิทธิภาพ

โครงสร้างพื้นฐาน AI นั้นซับซ้อน ครอบคลุมหลายชั้น ตั้งแต่การประมวลผล (Compute) เครือข่าย (Networking) ไปจนถึงการจัดเก็บข้อมูล (Storage) การจัดการ (Orchestration) และแอปพลิเคชัน เมื่อประสิทธิภาพลดลง การระบุต้นตอของปัญหาอาจเป็นเรื่องยาก เพราะอาการที่พบในชั้นหนึ่งอาจมีสาเหตุมาจากชั้นอื่นในสแต็กได้

การมีกลยุทธ์ Full-Stack Observability ที่ดี จะช่วยเชื่อมโยงข้อมูล Telemetry จากทุกชั้นเข้าด้วยกัน ทำให้ทีมปฏิบัติการสามารถตรวจจับปัญหา แยกแยะสาเหตุ และรักษาความเสถียรของเวิร์กโหลด AI ได้อย่างมีประสิทธิภาพ บทความนี้จะนำเสนอแนวทางปฏิบัติเพื่อเลือกเครื่องมือ Observability ที่เหมาะสมสำหรับโครงสร้างพื้นฐาน NVIDIA AI และแสดงวิธีการนำไปใช้ในสถานการณ์ทั่วไป

ทำไม Full-Stack Observability จึงสำคัญสำหรับ AI Factories?

ลองนึกภาพการเทรนโมเดล AI แบบกระจายที่ดำเนินมาสามวันแล้ว แต่พบว่าอัตราการผลิตลดลงอย่างเห็นได้ชัด แม้ว่าการใช้งาน GPU และเวลารอคอยคิวจะยังคงปกติ การไล่ตรวจสอบพบว่าสาเหตุมาจาก "ความล้มเหลวแบบสีเทา" (Gray Failure) ในลิงก์ InfiniBand เพียงลิงก์เดียว ที่เริ่มมีอัตราข้อผิดพลาดของบิต (Bit Error Rate) สูงขึ้น

นี่คือตัวอย่างคลาสสิกที่ฮาร์ดแวร์เริ่มเสื่อมสภาพ แต่ระบบยังไม่รายงานว่า "ดาวน์" (Down) การเทรน AI มักใช้โมเดล Bulk Synchronous Parallel (BSP) ซึ่งระบบที่เชื่อมต่อกันอย่างใกล้ชิดเหล่านี้มีความอ่อนไหวต่อ "Stragglers" หรือส่วนที่ทำงานช้า หากมีส่วนใดส่วนหนึ่งช้า จะส่งผลกระทบต่อทั้งระบบ โดยเฉพาะการดำเนินการแบบ Collective Operations เช่น NVIDIA Collective Communications Library (NCCL) all-reduce ที่หากลิงก์มีปัญหา การส่งข้อมูลจะล่าช้า ทำให้ส่วนที่เหลือต้องรอ ส่งผลให้ประสิทธิภาพโดยรวมลดลง

ปัญหานี้พบได้บ่อยใน AI Factories ข้อมูล Telemetry ที่จำเป็นมักมีอยู่แล้ว แต่ความท้าทายคือการเลือกสัญญาณที่ถูกต้องจากเครื่องมือที่เหมาะสมตั้งแต่เนิ่นๆ เพื่อให้สามารถดำเนินการได้ทันท่วงที ผู้ปฏิบัติงานไม่จำเป็นต้องมีเมตริกทั้งหมดจากทุกผลิตภัณฑ์ แต่ต้องการ เส้นทางการตัดสินใจ ที่เชื่อมโยงส่วนประกอบต่างๆ เข้ากับเครื่องมือ ชุดการแจ้งเตือนที่กระชับ และแดชบอร์ดเดียวสำหรับการตรวจสอบปัญหา (Triage)

การระบุ Failure Domains ที่ต้องสังเกตการณ์

ก่อนที่จะเลือกซอฟต์แวร์การตรวจสอบ ควรระบุ "โดเมนความล้มเหลว" (Failure Domains) ที่อาจทำให้เวลา GPU สูญเปล่าโดยไม่รู้ตัว:

• สุขภาพแพลตฟอร์ม (Platform Health): พัดลม, แหล่งจ่ายไฟ (PSU), BMC, แชสซี, CPU, หน่วยความจำ, พื้นที่จัดเก็บข้อมูลภายใน
• สุขภาพและประสิทธิภาพ GPU (GPU Health & Performance): การใช้งาน (Utilization), อุณหภูมิ, การใช้พลังงาน, XID/ECC, และปริมาณงาน NVLink
• เครือข่าย (Fabric): ความสมบูรณ์ของลิงก์ InfiniBand หรือ Ethernet, ความแออัด, สุขภาพสวิตช์/สายเคเบิล; NVLink ระดับแร็ค (Rack-scale NVLink) หากมี
• คลัสเตอร์และงาน (Cluster & Jobs): การจัดตารางเวลา (Scheduling), การจองทรัพยากร (Reservations), GPU ที่ถูกจัดสรรแต่ไม่ได้ใช้งาน, เวลาที่ต้องรอในคิว
• บริการ Inference (Inference Services): ความหน่วง (Latency), อัตราความสำเร็จ (Success Rate), และพฤติกรรมแคช เมื่อใช้ NVIDIA NIM microservices หรือบริการที่คล้ายกัน

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

การจับคู่ส่วนประกอบ AI Infrastructure กับเครื่องมือ Telemetry

ทีมปฏิบัติการต้องการการจับคู่ที่ชัดเจนระหว่างส่วนประกอบและแหล่งที่มาของ Telemetry เครื่องมือหลักที่ใช้กัน ได้แก่:

• NVIDIA Data Center GPU Manager (DCGM): สำหรับการจัดการและตรวจสอบ GPU
• NVIDIA System Management (NVSM): สำหรับตรวจสอบสุขภาพระบบโดยรวมของโหนด DGX
• NVIDIA Unified Fabric Manager (UFM): สำหรับจัดการและตรวจสอบเครือข่าย InfiniBand
• NVIDIA NetQ: สำหรับตรวจสอบเครือข่าย Ethernet/RoCE
• NVIDIA NMX: สำหรับตรวจสอบ NVLink ระดับแร็ค
• NVIDIA Base Command Manager (BCM): สำหรับการจัดการคลัสเตอร์และงาน
• NVIDIA Run:ai / NIM: สำหรับการจัดการเวิร์กโหลดและบริการ Inference

ข้อควรพิจารณาในการเลือกเครื่องมือ:

• DCGM vs NVSM สำหรับ GPU: แนะนำ DCGM สำหรับการส่งข้อมูลการใช้งาน, พลังงาน, อุณหภูมิ, NVLink, และ XID/ECC ไปยัง Prometheus ส่วน NVSM ยังคงจำเป็นสำหรับสุขภาพระบบโดยรวมของโหนด DGX (ไดรฟ์, พลังงาน, สุขภาพทั่วไป)
• UFM vs NetQ: เลือกตามประเภทเครือข่าย InfiniBand ใช้ UFM, Spectrum Ethernet/RoCE ใช้ NetQ หากมีทั้งสองประเภท ให้ใช้งานทั้งคู่
• NMX: จำเป็นสำหรับ Rack-scale NVLink หากไม่ได้ใช้ในโทโพโลยีแบบเดิม ก็สามารถละเว้นได้
• BCM: ใช้เป็นตัวรวบรวมข้อมูลระดับคลัสเตอร์และงาน ไม่ใช่แหล่งข้อมูลระดับต่ำ เครื่องมือเฉพาะทางยังคงรับผิดชอบ Telemetry เชิงลึก
• Run:ai และ NIM: นำมาใช้เมื่อการจัดตารางงานที่เป็นธรรม (Fairness) หรือ SLOs ของ Inference เป็นข้อกำหนดการปฏิบัติงานที่สำคัญ แต่ไม่สามารถทดแทน DCGM หรือการตรวจสอบเครือข่ายได้

กฎสำคัญ: ครอบคลุมทุกความต้องการด้วยเครื่องมือที่น้อยที่สุด เครื่องมือเพิ่มเติมที่ไม่มีเส้นทางการตรวจสอบที่ชัดเจนจะเพิ่มสัญญาณรบกวน ทำให้เกิด "Alert Fatigue" หรือความเหนื่อยล้าจากการแจ้งเตือน

การประยุกต์ใช้ Observability Framework กับ InfiniBand Cluster

สำหรับ DGX cluster ที่ใช้ InfiniBand, BCM, และ Slurm โดยเน้นที่งานเทรนเป็นหลัก ข้อกำหนดคือมีแดชบอร์ด Triage เพียงแดชบอร์ดเดียว และการแจ้งเตือนที่ตรวจจับความเสื่อมของเครือข่ายและ GPU ได้ก่อนที่งานจะสูญเสียเวลาหลายชั่วโมง

ขั้นตอนการตัดสินใจ:

1. โดเมนที่เกี่ยวข้อง: สุขภาพแพลตฟอร์ม, GPU, เครือข่าย InfiniBand, คลัสเตอร์/งาน
2. เครื่องมือที่เลือก:

• Redfish/IPMI สำหรับสุขภาพ BMC (พัดลม, PSU, แชสซี)
• DCGM สำหรับประสิทธิภาพ GPU (การใช้งาน, พลังงาน, อุณหภูมิ, XID/ECC, NVLink)
• NVSM สำหรับการรวบรวมสุขภาพระบบบนโหนด DGX
• UFM สำหรับสุขภาพพอร์ต InfiniBand, BER, ความแออัด, และการกำหนดเส้นทาง
• BCM สำหรับการรวบรวมข้อมูลคลัสเตอร์, งาน, การจอง, และการแจ้งเตือนฮาร์ดแวร์แบบรวม

1. เหตุผล: การมีเพียง DCGM จะพลาดการถดถอยของ BER ใน InfiniBand ซึ่งส่งผลกระทบต่อเวิร์กโหลดที่ต้องทำงานพร้อมกัน การมีเพียง UFM จะพลาดปัญหา GPU XID Storm หรือ Node Power Fault ส่วน BCM อย่างเดียวก็ไม่สามารถให้ข้อมูลระดับต่ำได้ การรวมเครื่องมือเหล่านี้เข้าด้วยกันจะครอบคลุมโดเมนที่ทำให้เสียเวลา GPU
2. เครื่องมือที่ยกเว้น (สำหรับตอนนี้): NetQ, NMX, Run:ai, NIM เนื่องจากยังไม่มีการใช้งาน Ethernet, Rack-scale NVLink, หรือบริการ Inference

ผลลัพธ์คือ Stack เริ่มต้นที่ประกอบด้วย IPMI, DCGM, NVSM, UFM, และ BCM ซึ่งรวมศูนย์อยู่ใน Prometheus/Grafana

การสร้างชุดการแจ้งเตือนที่ดำเนินการได้ (Actionable Alert Set)

เครื่องมือส่วนใหญ่มีเมตริกหลายร้อยรายการ ควรเลือกชุดการแจ้งเตือนสั้นๆ ที่เชื่อมโยงกับ Service Level Indicators (SLIs) และ Service Level Objectives (SLOs) ไม่ใช่การรวบรวมเคาน์เตอร์ฮาร์ดแวร์ทั้งหมด การแจ้งเตือนแต่ละรายการควรเชื่อมโยงกับการดำเนินการแก้ไขที่ชัดเจน

ตัวอย่างการแจ้งเตือนเบื้องต้น:

• แพลตฟอร์ม: ความเร็วพัดลม, สถานะ PSU, อุณหภูมิสำคัญ (ผ่าน Redfish/IPMI)
• GPU: DCGMFIDEVGPUUTIL, DCGMFIDEVMEMCOPYUTIL, DCGMFIDEVPOWERUSAGE, DCGMFIDEVXID_ERRORS, รวมถึงสุขภาพ GPU/ระบบจาก NVSM
• InfiniBand: PortXmitDataExtended, SymbolErrorCounterExtended, EffectiveBER, TotalRawBER, ChipTemp
• งาน: สัญญาณจาก BCM/Slurm สำหรับงานที่กำลังทำงาน, การจอง GPU, และเวลารอคอย เพื่อให้การแจ้งเตือนเครือข่ายหรือ GPU สามารถเชื่อมโยงกับผลกระทบของเวิร์กโหลดได้

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

การสร้าง Unified AI Infrastructure Triage Dashboard

เมื่อเลือกเครื่องมือและเมตริกหลักได้แล้ว ให้สร้างแดชบอร์ด Triage แบบรวมศูนย์:

1. ติดตั้ง Exporter: ติดตั้ง IPMI และ DCGM exporters บนทุก GPU node
2. รวบรวมข้อมูลเครือข่าย: รัน UFM Telemetry และ scrape หรือ export เข้าสู่ Prometheus
3. จัดการคลัสเตอร์: ใช้ BCM เป็นแกนหลักในการจัดการและรวบรวมข้อมูล
4. แสดงผล: ชี้ Grafana ไปที่ Prometheus เพื่อสร้างแดชบอร์ดและการแจ้งเตือนสำหรับสัญญาณ GPU, Node, และ Fabric
5. บริบทงาน: เพิ่มแดชบอร์ด Slurm หากบริบทระดับงานยังไม่มีใน BCM

ใช้วิธีการตรวจสอบสองชั้น: ชั้นที่ 1 ให้มุมมองระดับสูงสำหรับการ Triage (ปัญหาอยู่ที่ GPU, Node, หรือ Fabric?) ชั้นที่ 2 คือการเจาะลึกใน UI ของผู้จำหน่าย (UFM web UI, BCM Base View) เมื่อทราบโดเมนที่เสียหายแล้ว การดำเนินการในวันที่สอง (Day 2 operations) จะเร็วขึ้นเมื่อชั้นที่ 1 สามารถตอบคำถาม Triage ได้จากบอร์ดเดียว

เกณฑ์การยอมรับ Observability

คุณจะพร้อมดำเนินการต่อเมื่อ:

• ทุก Failure Domain ที่อยู่ในขอบเขต มีเครื่องมือที่รองรับอย่างน้อยหนึ่งรายการจาก Framework
• การแจ้งเตือนเชื่อมโยงกับรายการเมตริกสั้นๆ ที่มีเจ้าของและการดำเนินการที่ชัดเจน
• สัญญาณ GPU, Node, และ Fabric อยู่บนไทม์ไลน์เดียวกันในมุมมองเดียว
• เครื่องมือเพิ่มเติม (Ethernet, Rack-scale NVLink, Run:ai, NIM) ถูกเพิ่มเข้ามาเมื่อจำเป็นเท่านั้น ไม่ใช่ตามค่าเริ่มต้น

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

การขยาย Stack NVIDIA AI Infrastructure Observability

หลังจากที่การติดตั้งเริ่มต้นตรงตามเกณฑ์ที่กำหนดแล้ว ให้ขยายการครอบคลุมตามลำดับนี้:

1. เปิดใช้งาน GPU Telemetry: ใช้ DCGM User Guide และ GPU Telemetry
2. ตรวจสอบสุขภาพระบบ DGX: ตรวจสอบเส้นทางสุขภาพระบบ DGX ใน NVSM User Guide
3. กำหนดค่าการมองเห็นเครือข่าย: ใช้ UFM Telemetry หรือ NetQ ขึ้นอยู่กับประเภทเครือข่าย
4. การรวบรวมระดับคลัสเตอร์: เริ่มต้นด้วย Base Command Manager และ NVIDIA Mission Control (หากมี)
5. บริการ Inference: เพิ่ม Observability สำหรับ NVIDIA NIM Operator

ใช้ Decision Framework เพื่อให้เหตุผลในการเพิ่มแต่ละรายการ จัดทำคู่มือ Metric Dictionary และ Protocol Matrix ใน Runbooks หรือเอกสารผลิตภัณฑ์ และรักษาชุดการแจ้งเตือนการผลิตให้สั้นพอสำหรับการใช้งานของทีม On-call

กรอบการตัดสินใจที่ดี จะช่วยให้คุณเลือกสัญญาณที่เหมาะสมเพียงไม่กี่อย่างและแดชบอร์ด Triage เพียงแดชบอร์ดเดียว แทนที่จะมีแดชบอร์ดมากมายที่ไม่มีใครอ่าน

#AI #NVIDIA #Observability #AIInfrastructure

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/how-to-choose-full-stack-observability-for-nvidia-ai-factories/

NVIDIA NeMo Switchyard: เส้นทางอัจฉริยะสู่การจัดการ Workload AI Agent

การสร้าง AI Agent ที่มีประสิทธิภาพไม่ใช่แค่การเลือกรุ่นโมเดลภาษา (LLM) ที่ดีที่สุดเพียงโมเดลเดียว เพราะแต่ละโมเดลต่างมีจุดแข็ง จุดอ่อน และต้นทุนที่แตกต่างกันไป ซึ่งอาจเปลี่ยนแปลงได้ตามลักษณะงาน หรือแม้แต่ภายในงานเดียวกัน หากเราส่งทุกคำขอไปยังโมเดลที่ใหญ่และทรงพลังที่สุดเสมอ อาจทำให้ต้นทุนและเวลาในการตอบสนอง (Latency) สูงเกินความจำเป็น ในทางกลับกัน การใช้โมเดลขนาดเล็กกับทุกงานก็อาจส่งผลต่อคุณภาพของผลลัพธ์ในงานที่ซับซ้อนได้

NVIDIA NeMo Switchyard คือคำตอบสำหรับความท้าทายนี้ โดยทำหน้าที่เป็น "สวิตช์บอร์ด" อัจฉริยะสำหรับ AI Agent ช่วยให้สามารถเลือกใช้โมเดลที่เหมาะสมที่สุดสำหรับแต่ละงานได้อย่างไดนามิก โดยพิจารณาจากความสามารถของโมเดล, ต้นทุน, และสัญญาณจากโครงสร้างพื้นฐาน เพื่อให้ได้สมดุลระหว่างประสิทธิภาพ, ค่าใช้จ่าย, และความรวดเร็ว

ทำความเข้าใจการตัดสินใจของ Model Router

ลองนึกภาพระบบที่ประกอบด้วยโมเดลหลายๆ ตัวทำงานร่วมกัน เช่น ในการทำงานที่ต้องมีการจำแนกประเภท (Classification) ในขั้นตอนหนึ่ง, การให้เหตุผล (Reasoning) ในอีกขั้นตอนหนึ่ง, และอาจมีโมเดลขนาดเล็กสำหรับการทำงานทั่วไปในขั้นตอนสุดท้าย การส่งทุกคำขอไปยังโมเดลที่ใหญ่ที่สุดอาจไม่คุ้มค่าเสมอไป

Model Router ที่ทำงานด้วย NVIDIA NeMo Switchyard จะประเมินแต่ละคำขอพร้อมกับบริบทที่มีอยู่ แล้วส่งงานไปยังโมเดลที่เหมาะสมที่สุดกับความต้องการ, ข้อจำกัด, และนโยบายของงานนั้นๆ ซึ่งวิธีการนี้สามารถช่วยเพิ่มความแม่นยำและลดต้นทุนได้ เมื่อเทียบกับการใช้โมเดลที่เก่งที่สุดสำหรับทุกคำขอ

การตัดสินใจของ Router อาศัยสัญญาณจาก 3 ส่วนหลัก:

• ความสามารถของโมเดล: โมเดลใดสามารถทำงานให้สำเร็จได้
• โปรไฟล์ต้นทุนของโมเดล: ค่าใช้จ่ายและเวลาในการตอบสนอง (Latency) ของแต่ละโมเดล
• โครงสร้างพื้นฐาน: สัญญาณระดับระบบที่ช่วยให้การส่งต่อข้อมูลเป็นไปอย่างราบรื่นและเชื่อถือได้

สัญญาณที่ใช้ในการตัดสินใจ

Router สามารถใช้สัญญาณจากหลายแหล่งเพื่อประกอบการตัดสินใจ เช่น:

• การวิเคราะห์คำขอ: การจำแนกประเภทของคำถามหรือหัวข้อ เพื่อจับคู่กับโมเดลที่เหมาะสม หรือการใช้โมเดล Embedding เพื่อดึงคุณลักษณะจากคำขอ
• สถานะของโมเดล: การตรวจสอบ logprobs, cascades, หรือข้อมูลอื่นๆ จากโมเดล
• ระบบ: การพิจารณาข้อมูลราคา, Latency, โหลดของระบบ, หรือแม้แต่สัญญาณเฉพาะของ Agent เช่น ข้อผิดพลาด

สิ่งสำคัญคือ Router ต้องพิจารณาว่าจะใช้สัญญาณใด, เมื่อใด, และที่ไหน เช่น ในงาน Agent ที่มีหลาย Turn Router อาจเลือกส่งทั้งคำขอไปยังโมเดลที่เฉพาะเจาะจง หรืออาจเลือกเส้นทางที่โมเดลในแต่ละ Step ของการทำงาน

NeMo Switchyard ช่วยให้การ Routing เป็นไปได้อย่างไร

NeMo Switchyard นำเสนอ SDK ที่ชื่อว่า neMo-switchyard-libsy ซึ่งเป็นหัวใจสำคัญในการจัดการการสื่อสารระหว่าง Router และโมเดลต่างๆ โดยมีความสามารถดังนี้:

• Provider-Agnostic: ไม่ผูกติดกับผู้ให้บริการโมเดลรายใดรายหนึ่ง ทำให้สามารถสลับสับเปลี่ยนหรือเพิ่มโมเดลใหม่ๆ ได้ง่าย
• จัดการการสื่อสาร: รับคำขอ, กำหนดโมเดลที่พร้อมใช้งาน, และจัดการการเรียกใช้งานโมเดลที่เลือก
• แยก Logic: แยกส่วนของ Logic การ Routing ออกจากส่วนของผู้ให้บริการโมเดล ทำให้สามารถอัปเดตหรือเปลี่ยนแปลงโมเดลได้โดยไม่ต้องปรับแก้ส่วนของ Routing
• รักษา State: สามารถส่งต่อข้อมูลสถานะ (State) ระหว่าง Turn ของ Agent ได้ หากนโยบายกำหนด หรือเลือกที่จะไม่เก็บ State หากไม่จำเป็น
• การทำงานร่วมกับ Gateway: มี NeMo Switchyard Server เป็น Reference implementation สำหรับการทำ Routing ผ่าน API มาตรฐาน เช่น OpenAI, Anthropic, และ Responses API ซึ่งช่วยให้ Agent มี Gateway ที่ควบคุมการรับส่งคำขอได้อย่างมีประสิทธิภาพ

กลยุทธ์การ Routing ใน NeMo Switchyard

NeMo Switchyard รองรับทั้ง Router แบบ Tuning-Free (ไม่ต้องฝึกฝนข้อมูลเฉพาะ) และ Tunable (เรียนรู้จากข้อมูลจริง)

1. Tuning-Free Routers

เหมาะสำหรับการนำไปใช้ได้ทันทีโดยไม่ต้องผ่านกระบวนการฝึกฝนข้อมูลเฉพาะ:

• LLM Classifier: ใช้ LLM ตัวหนึ่งทำหน้าที่เป็น "ผู้พิพากษา" ในการเลือก LLM ที่เหมาะสมสำหรับคำขอ และรักษาการเชื่อมต่อกับโมเดลนั้นตลอดการสนทนา เพื่อหลีกเลี่ยงการประเมินซ้ำๆ หากงานยังไม่เปลี่ยนแปลงมากนัก เหมาะสำหรับระบบเฉพาะทาง เช่น งานด้านการเขียนโค้ด, คณิตศาสตร์, หรือการแพทย์
• Stage Router: วิเคราะห์กิจกรรมล่าสุดของ Agent เพื่อตัดสินใจว่าต้องการโมเดลที่มีความสามารถระดับใดในแต่ละ Stage ของงาน หากพบข้อผิดพลาดรุนแรง หรือการทำงานที่ไม่มีประสิทธิภาพ จะเลือกใช้โมเดลที่มีความสามารถสูงขึ้น แต่หากการทำงานเริ่มคงที่และมีประสิทธิภาพ จะเลือกใช้โมเดลที่ประหยัดกว่า
• Escalation Router: เริ่มต้นการสนทนาด้วยโมเดลที่มีต้นทุนต่ำ จากนั้น LLM Judge จะคอยติดตามความคืบหน้า และหากพบว่างานเริ่มมีความซับซ้อนหรือติดขัด ก็จะเลื่อนระดับไปใช้โมเดลที่มีความสามารถสูงขึ้น เหมาะสำหรับ Agent ที่ทำงานหลาย Turn และต้องการการปรับตัวตามสถานการณ์

2. Tunable Routers

ต่อยอดจาก Router แบบ Tuning-Free โดยใช้สัญญาณที่เรียนรู้จากข้อมูลการใช้งานจริง เพื่อคาดการณ์ว่าโมเดลใดมีแนวโน้มที่จะตอบคำถามได้ถูกต้องที่สุด แทนที่จะอาศัยกฎเกณฑ์ที่ตายตัว

• Prefill Router: เรียนรู้จากข้อมูลใน Residual Stream ของ LLM เพื่อประเมินความซับซ้อนของคำขอ และคาดการณ์ความสำเร็จของแต่ละโมเดล จากนั้นจะนำคะแนนความน่าจะเป็นมารวมกับนโยบาย เช่น ต้นทุน หรือ Latency เพื่อเลือกรุ่นโมเดลที่ให้ผลตอบแทนคุ้มค่าที่สุด

การปรับปรุงประสิทธิภาพ Agent ด้วย NeMo Switchyard

NVIDIA ได้ร่วมมือกับพันธมิตรในหลากหลายอุตสาหกรรม เพื่อนำ NeMo Switchyard ไปใช้ใน Workflow ของนักพัฒนาได้อย่างราบรื่น ตัวอย่างความร่วมมือ ได้แก่:

• Agent Workflows: การทำงานร่วมกับ Cognition สำหรับ Coding Agent, Nous Research สำหรับ Hermes Agent, Ramp สำหรับ Financial Software Engineering, และ LangChain สำหรับการประเมินผล Model Routing
• Application & Infrastructure Integrations: การรวมเข้ากับ LiteLLM, Kong, Classmethod, และ Boomi Agent Garden
• Industry-Specific AI Agents: การทำงานกับ Cadence ใน ChipStack AI Super Agent และ Siemens สำหรับ EDA Agent Workflows

การทดสอบ Benchmark โดย LangChain บนชุดการประเมิน Agent แบบ Multi-turn กว่า 145 งาน พบว่าการใช้ Escalation Router ในการส่งคำขอระหว่าง NVIDIA Nemotron 3.5 Lightning และ Claude Opus 4.8 สามารถลดต้นทุนได้ถึง 74% เมื่อเทียบกับการใช้เฉพาะโมเดล Frontier (โมเดลที่ทรงพลังที่สุด)

NVIDIA NeMo Switchyard เป็นเครื่องมือสำคัญที่ช่วยให้นักพัฒนาสามารถสร้าง AI Agent ที่มีประสิทธิภาพ, ควบคุมได้, และคุ้มค่าต่อการใช้งานจริงในสภาพแวดล้อมการผลิต

คำถามที่พบบ่อย

NeMo Switchyard แตกต่างจาก Load Balancer ทั่วไปอย่างไร?

NeMo Switchyard ไม่เพียงแค่กระจายโหลดงาน แต่ยังพิจารณาถึงความสามารถ, ต้นทุน, และ Latency ของโมเดลแต่ละตัว เพื่อเลือกโมเดลที่เหมาะสมที่สุดสำหรับแต่ละงานโดยเฉพาะ

สามารถนำ Router Algorithm ของตัวเองมาใช้กับ NeMo Switchyard ได้หรือไม่?

ได้ NeMo Switchyard อนุญาตให้นักพัฒนาสามารถนำ Algorithm หรือข้อมูลการปรับแต่ง (Customization Data) ของตนเองมาใช้ร่วมได้

NeMo Switchyard เหมาะกับใคร?

เหมาะสำหรับนักพัฒนาและองค์กรที่ต้องการสร้าง AI Agent ที่มีประสิทธิภาพสูง, ต้องการควบคุมต้นทุนและ Latency, และต้องการความยืดหยุ่นในการเลือกใช้โมเดลภาษาที่หลากหลาย

การใช้งาน NeMo Switchyard มีค่าใช้จ่ายเพิ่มเติมหรือไม่?

NeMo Switchyard เป็น SDK และ Library ที่เปิดให้นักพัฒนาใช้งานได้ฟรี ส่วนค่าใช้จ่ายจะขึ้นอยู่กับการใช้งานโมเดลภาษาที่คุณเลือกใช้ ซึ่ง NeMo Switchyard จะช่วยให้การเลือกโมเดลเหล่านี้มีประสิทธิภาพมากขึ้น

ประโยชน์หลักของการใช้ NeMo Switchyard คืออะไร?

ประโยชน์หลักคือการเพิ่มประสิทธิภาพ, ลดต้นทุน, และเพิ่มความยืดหยุ่นในการเลือกใช้โมเดล AI Agent ให้เหมาะสมกับแต่ละงาน

#AI #NVIDIANeMo #LLM #Agent

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/route-ai-agent-workloads-across-models-with-nvidia-nemo-switchyard/

NVIDIA JetPack 7.2.1: ยกระดับการประมวลผลวิดีโอด้วย Agentic Video Skills และ T3000 Emulation 🚀

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

การทำงานแต่ละขั้นตอนอาจดูไม่ซับซ้อน แต่หัวใจสำคัญอยู่ที่การเลือกอินเทอร์เฟซที่เหมาะสม, ตัวแปลงสัญญาณ (Codec), รูปแบบพิกเซล, เส้นทางการส่งข้อมูล (Memory Path), การควบคุมอัตราบิต (Rate Control) และการจัดการบัฟเฟอร์ให้เข้ากับอุปกรณ์ Jetson รวมถึงการพิสูจน์ว่ากระบวนการทั้งหมดสามารถทำงานได้ตามเป้าหมายด้านเวลาแฝง (Latency), ปริมาณงาน (Throughput) และคุณภาพ

JetPack 7.2.1: ความสามารถใหม่ที่น่าสนใจ ✨

NVIDIA JetPack 7.2.1 ได้นำเสนอความสามารถใหม่ที่สำคัญหลายประการ เพื่อช่วยให้นักพัฒนาสามารถสร้างเวิร์กโฟลว์วิดีโอที่ซับซ้อนและมีประสิทธิภาพยิ่งขึ้น:

1. Agentic Video Skills: การทำงานอัตโนมัติที่ชาญฉลาดยิ่งขึ้น 🤖

JetPack 7.2.1 ได้เพิ่ม "Agentic Video Skills" ซึ่งเป็นชั้นการทำงานอัตโนมัติที่ชาญฉลาดเหนือกว่า SDK เดิม ความสามารถนี้ช่วยเชื่อมโยงเจตนาของนักพัฒนาเข้ากับการค้นพบอุปกรณ์แบบเรียลไทม์, การตั้งค่าที่รองรับ, กระบวนการที่สามารถทำซ้ำได้ และการตรวจสอบประสิทธิภาพ

• การค้นพบและตั้งค่าความสามารถ: ระบุแพลตฟอร์ม Jetson และซอฟต์แวร์ที่ติดตั้ง, แนะนำการตั้งค่าที่รองรับ, และสอบถามเกี่ยวกับตัวแปลงสัญญาณสำหรับเข้ารหัสและถอดรหัส, รูปแบบข้อมูล, เส้นทางการส่งข้อมูล และความสามารถของเซสชันบนอุปกรณ์จริง
• การสร้างสูตรเข้ารหัส (Encoder Recipes): แปลงเป้าหมาย เช่น เวลาแฝงต่ำ, คุณภาพคงที่, บิตเรตจำกัด, ความละเอียด, อัตราเฟรม และการเลือกตัวแปลงสัญญาณ ให้เป็นการตั้งค่าที่ชัดเจนและเส้นทางที่สามารถรันได้ผ่าน Video Codec SDK หรือ PyNvVideoCodec
• การวัดประสิทธิภาพและคุณภาพ: ดำเนินการวัดผลที่สามารถทำซ้ำได้สำหรับปริมาณงาน, เวลาแฝง, การใช้งานทรัพยากร, บิตเรต และคุณภาพของผลลัพธ์
• การตรวจสอบเวิร์กโฟลว์ตัวแปลงสัญญาณ: เชื่อมโยงการตั้งค่า, การเลือกสูตร, การเข้ารหัส/ถอดรหัส, การวัดผล และการส่งต่อข้อมูลที่ผิดปกติ จากนั้นส่งคืนการกำหนดค่า, ผลลัพธ์, คำเตือน และหลักฐานที่จำเป็นสำหรับการทำซ้ำกระบวนการ

2. PyNvVideoCodec 2.2: การจัดการวิดีโอด้วย Python บน GPU 🐍

สำหรับนักพัฒนา Python, JetPack 7.2.1 ได้เพิ่มการรองรับ PyNvVideoCodec 2.2 ซึ่งเป็นไลบรารี Python ของ NVIDIA สำหรับการเข้ารหัสและถอดรหัสวิดีโอแบบเร่งความเร็วด้วยฮาร์ดแวร์บน GPU ของ NVIDIA

• การทำงานร่วมกับ AI Pipeline: PyNvVideoCodec สร้างและรับเฟรมวิดีโอในรูปแบบหน่วยความจำบน GPU (GPU-resident device memory) ซึ่งสามารถเข้าถึงได้ผ่านโปรโตคอล DLPack และ CUDA device buffers ทำให้การผสานรวมกับไปป์ไลน์ AI เป็นไปอย่างราบรื่น
• คุณสมบัติเพื่อประสิทธิภาพ: รวมถึงการสุ่มตัวอย่างเฟรมแบบหลายโหมด (multi-mode frame sampling) และ ThreadedDecoder ที่ช่วยเพิ่มประสิทธิภาพของไปป์ไลน์โดยการถอดรหัสเฟรมล่วงหน้าในเธรดเบื้องหลัง ซึ่งช่วยแยกเวลาแฝงของการถอดรหัสออกจากเวลาแฝงของการอนุมาน (inference)

3. T3000 Emulation: เร่งการพัฒนา AI Video Pipeline 🛠️

JetPack 7.2.1 ยังเปิดใช้งานการจำลองประสิทธิภาพของ Jetson T3000 บน Jetson T5000 โดยใช้ Jetson Thor AGX Developer Kit ซึ่งช่วยให้นักพัฒนาสามารถเร่งการพัฒนาไปป์ไลน์ AI วิดีโอที่มีประสิทธิภาพสูงและประหยัดพลังงานได้อย่างรวดเร็ว

• การพัฒนาที่รวดเร็ว: ช่วยให้นักพัฒนาสามารถเริ่มต้นโครงการได้ทันที โดยการจำลองประสิทธิภาพของ T3000 ซึ่งเหมาะสำหรับงาน Humanoid และ Robotics โดยที่ใช้ฮาร์ดแวร์ T5000 ที่มีอยู่
• การประหยัดพลังงานและต้นทุน: T3000 ถูกออกแบบมาให้มีประสิทธิภาพการอนุมานเทียบเท่า T5000 แต่ใช้พลังงานน้อยลงและมีขนาดกะทัดรัดกว่า

สร้าง AI Video Pipeline ด้วย PyNvVideoCodec และ Jetson Video Skills 🎬

เมื่อมีคำสั่ง เช่น “ถอดรหัสวิดีโอนี้, ประมวลผลด้วย AI หรือ Computer Vision ของฉัน, และตรวจสอบว่าขั้นตอนตัวแปลงสัญญาณเป็นไปตามเป้าหมายประสิทธิภาพหรือไม่” ผู้ช่วยเขียนโค้ดสามารถใช้ Jetson Video Skill เพื่อกำหนดค่าและตรวจสอบ PyNvVideoCodec ได้ โดยมีแอปพลิเคชันตัวอย่างที่มาพร้อมกับ PyNvVideoCodec เป็นโครงร่างอ้างอิง

ขั้นตอนการทำงาน:

1. ตรวจสอบและกำหนดค่า: ผู้ช่วยเขียนโค้ดจะเรียกใช้ Skill เพื่อตรวจสอบแพลตฟอร์ม Jetson, ซอฟต์แวร์ และความสามารถของตัวแปลงสัญญาณ จากนั้นเลือกตัวถอดรหัส, รูปแบบผลลัพธ์, เส้นทางการส่งข้อมูล และการบัฟเฟอร์
2. ถอดรหัสเป็นข้อมูล Framework: แอปพลิเคชันตัวอย่าง PyNvVideoCodec สามารถเตรียมเฟรมในเธรดเบื้องหลัง และส่งแต่ละเฟรมไปยัง Tensor Framework โดยไม่ต้องเขียนโค้ดตัวแปลงสัญญาณที่เฉพาะเจาะจง
3. ทำให้แอปพลิเคชันสมบูรณ์: เมื่อขั้นตอนตัวแปลงสัญญาณถูกกำหนดค่าแล้ว ผู้ช่วยเขียนโค้ดสามารถขยายแอปพลิเคชันตัวอย่างด้วยขั้นตอนที่จำเป็นสำหรับคำสั่งนั้นๆ เช่น การประมวลผลล่วงหน้า (preprocessing), การตรวจจับ (detection) หรือการจำแนกประเภท (classification), การกรองความเป็นส่วนตัว (เช่น การเบลอ), การแสดงภาพ (visualization) และการจัดการผลลัพธ์ (output handling) โมเดล AI หรือตรรกะของแอปพลิเคชันยังคงเป็นทางเลือกของนักพัฒนา
4. วัดผลและตรวจสอบ: Skill จะบันทึกการกำหนดค่าตัวแปลงสัญญาณ และตรวจสอบสถานะการทำงาน, ปริมาณงาน, เวลาแฝง, การใช้งานทรัพยากร, คำเตือน และหลักฐาน

การเลือก Jetson Video Interface ที่เหมาะสม 🌟

Jetson มีการเข้าถึงวิดีโอผ่านเลเยอร์ซอฟต์แวร์ที่ทำงานร่วมกัน:

• GStreamer: ให้การประกอบไปป์ไลน์ระดับสูง
• V4L2: ควบคุมอุปกรณ์วิดีโอและบัฟเฟอร์ของ Linux
• Video Codec SDK: การเข้าถึงระดับล่างผ่าน C/C++ สำหรับ NVENC และ NVDEC
• PyNvVideoCodec: สร้างบน API ของ Video Codec SDK หลัก พร้อมอินเทอร์เฟซ Python ที่ง่ายกว่า

เลเยอร์เหล่านี้สามารถทำงานร่วมกันได้เมื่อเวิร์กโฟลว์ข้ามขั้นตอนการจับภาพ, การแปลงสัญญาณ, AI และการส่งมอบ

JetPack 7.2.1 มอบเส้นทางที่ชัดเจนยิ่งขึ้นสำหรับนักพัฒนา จากเจตนาไปสู่หลักฐาน: เลือกอินเทอร์เฟซ Linux, C/C++ หรือ Python ที่เหมาะสม, รักษาข้อมูลที่เร่งความเร็วให้ใกล้กับ GPU, และใช้ foundational video skills เพื่อกำหนดค่าและตรวจสอบขั้นตอน Video Codec SDK หรือ PyNvVideoCodec

#NVIDIAJetson #JetPack #AI #VideoAnalytics #Robotics

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/nvidia-jetpack-7-2-1-adds-agentic-video-skills-and-t3000-emulation/

NVIDIA Nemotron 3.5 Lightning: ปฏิวัติการทำงานของ AI Agent ด้วยความเร็วและความแม่นยำ ⚡

ในโลกของปัญญาประดิษฐ์ (AI) ที่พัฒนาไปอย่างรวดเร็ว "เอเจนต์ AI" (AI Agents) กำลังเข้ามามีบทบาทสำคัญในการทำงานที่ซับซ้อนและต่อเนื่องยาวนาน แต่การทำงานของเอเจนต์เหล่านี้มักต้องอาศัยการประมวลผลจำนวนมาก เช่น การเรียกใช้เครื่องมือ (Tool Calls), การตรวจสอบผลลัพธ์, และการมอบหมายงานย่อย (Subagent Delegation) ซึ่งหากใช้โมเดลภาษาขนาดใหญ่ (LLM) แบบดั้งเดิมทุกครั้ง อาจทำให้เกิดค่าใช้จ่ายและเวลาในการตอบสนองที่สูงเกินไป

NVIDIA เข้าใจถึงความท้าทายนี้ จึงได้เปิดตัว NVIDIA Nemotron 3.5 Lightning ซึ่งเป็นโมเดลภาษาขนาดเล็กแต่ทรงประสิทธิภาพ ที่ออกแบบมาเพื่อตอบโจทย์การทำงานของเอเจนต์ AI ที่ต้องการความรวดเร็ว แม่นยำ และประหยัดทรัพยากรได้อย่างดีเยี่ยม

Nemotron 3.5 Lightning คืออะไร? 🤔

Nemotron 3.5 Lightning เป็นโมเดลแบบ Mixture-of-Experts (MoE) ขนาด 30 พันล้านพารามิเตอร์ โดยมีพารามิเตอร์ที่ทำงานจริง (Active Parameters) เพียง 3 พันล้านพารามิเตอร์ จุดเด่นของโมเดลนี้คือการออกแบบมาเพื่อ การประมวลผลปริมาณมาก (High-volume Execution) และ การตอบสนองที่ล่าช้าต่ำ (Low-latency Execution) ซึ่งจำเป็นอย่างยิ่งสำหรับเอเจนต์ AI ที่ต้องทำงานตลอดเวลา (Always-on AI Agents) และเวิร์กโฟลว์แบบเอเจนต์ (Agentic Workflows)

ทำไม Nemotron 3.5 Lightning ถึงเหมาะสำหรับ AI Agent ระยะยาว? 🚀

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

Nemotron 3.5 Lightning แก้ปัญหานี้ด้วยการเป็นโมเดล MoE ที่มีขนาดเล็ก แต่ยังคงความสามารถในการประมวลผลได้อย่างมีประสิทธิภาพ โดยเฉพาะอย่างยิ่งในส่วนของการ "Execution Layer" หรือชั้นการประมวลผลของเอเจนต์ AI

จุดเด่นที่ทำให้ Nemotron 3.5 Lightning โดดเด่น:

• สถาปัตยกรรม MoE ที่มีประสิทธิภาพ: ด้วยโครงสร้างแบบ MoE ทำให้โมเดลสามารถเลือกใช้ "ผู้เชี่ยวชาญ" (Experts) เพียงไม่กี่ตัวในการประมวลผลแต่ละโทเค็น (Token) ส่งผลให้ใช้พลังการประมวลผลน้อยลงมาก เมื่อเทียบกับโมเดลแบบ Dense ที่มีขนาดใกล้เคียงกัน ทำให้ได้ความสามารถของโมเดลขนาดใหญ่ในต้นทุนการประมวลผลที่ต่ำกว่า
• Speculative Decoding: เทคนิคนี้ช่วยให้โมเดลสามารถคาดการณ์และสร้างโทเค็นได้หลายตัวพร้อมกันอย่างรวดเร็ว ทำให้การสร้างข้อความหรือผลลัพธ์มีความเร็วสูงขึ้นอย่างเห็นได้ชัด
• Harness-Optimized Training: โมเดลได้รับการฝึกฝนมาโดยเฉพาะสำหรับ "Harness" หรือเฟรมเวิร์กยอดนิยมที่ใช้สร้างเอเจนต์ AI ทำให้สามารถเรียกใช้เครื่องมือและประมวลผลงานได้อย่างแม่นยำและลดความล่าช้า
• Quantization (NVFP4 และ BF16): การรองรับ Quantization ช่วยให้โมเดลทำงานได้เร็วขึ้นและใช้หน่วยความจำน้อยลง โดยยังคงรักษาความแม่นยำไว้ได้ดีเยี่ยม
• ความเร็วที่เหนือกว่า: ให้ความเร็วในการสร้างผลลัพธ์ (Output Speed) สูงกว่าโมเดลขนาดใกล้เคียงกันถึง 4 เท่า ทำให้เหมาะอย่างยิ่งสำหรับงานที่ต้องการการตอบสนองที่รวดเร็ว
• ปรับแต่งได้ง่าย: เนื่องจากเป็นโมเดลขนาดเล็ก การ Fine-tune หรือปรับแต่ง Nemotron 3.5 Lightning จึงทำได้ง่าย รวดเร็ว และประหยัดค่าใช้จ่ายกว่าโมเดลขนาดใหญ่ สามารถนำไปปรับใช้กับงานเฉพาะทางได้อย่างยืดหยุ่น

การปรับแต่ง Nemotron 3.5 Lightning ให้เหมาะกับงานของคุณ 🛠️

NVIDIA เปิดกว้างให้ผู้พัฒนาสามารถนำ Nemotron 3.5 Lightning ไปปรับแต่งได้ตามต้องการ โดยปล่อย Weights, Training Data, และ Recipes ออกมาภายใต้ใบอนุญาตแบบ OpenMDW-1.1 ที่ยืดหยุ่น คุณสามารถ:

• Fine-tune: ใช้เทคนิค LoRA หรือ Full SFT ผ่าน NeMo Automodel และ NeMo Megatron Bridge
• Reinforcement Learning: ฝึกฝนและประเมินผลด้วย NeMo RL และ NeMo Gym
• Agentic Terminal Pivot: ใช้ชุดข้อมูลการฝึกฝนแบบ Reinforcement Learning สำหรับงาน Coding Agent ที่เปิดเผยออกมา

การจัดการงานด้วย NeMo Switchyard 🔄

เพื่อเพิ่มประสิทธิภาพสูงสุด NVIDIA ยังได้เปิดตัว NVIDIA NeMo Switchyard ซึ่งเป็นไลบรารีที่ช่วยในการ "เราท์" (Route) งานไปยังโมเดลที่เหมาะสมที่สุดได้อย่างชาญฉลาด

ด้วย NeMo Switchyard คุณสามารถนำ Nemotron 3.5 Lightning ไปใช้ร่วมกับโมเดลอื่นๆ (ทั้งแบบ Open และ Closed Source) เพื่อให้ทุกคำขอถูกส่งไปยังโมเดลที่มีความสามารถและประสิทธิภาพสูงสุดในการจัดการกับงานนั้นๆ เช่น โมเดล Frontier สำหรับการวางแผนที่ซับซ้อน และ Nemotron 3.5 Lightning สำหรับการประมวลผลงานปริมาณมาก ทำให้การใช้ทรัพยากรมีประสิทธิภาพสูงสุด

ประสิทธิภาพที่เหนือกว่า: ความเร็วและแม่นยำบนเส้นกราฟ Pareto 📈

Nemotron 3.5 Lightning ได้รับการยอมรับว่ามีประสิทธิภาพที่ยอดเยี่ยม โดยอยู่ในจุดสูงสุดของเส้นกราฟ Accuracy-Speed Pareto Frontier บนดัชนี Artificial Analysis Intelligence Index ซึ่งเป็นการวัดผลจาก 9 เกณฑ์ประเมิน ครอบคลุมทั้งงานแบบ Agentic, การเขียนโค้ด, การให้เหตุผลทางวิทยาศาสตร์, และความฉลาดทั่วไป

นอกจากนี้ บน Benchmark อย่าง PinchBench โมเดลนี้สามารถทำงานได้แม่นยำถึง 86% และประมวลผล 10,000 งานได้เร็วกว่า Qwen3.6 35B ถึง 30% ในขณะที่ยังคงความแม่นยำในระดับใกล้เคียงกัน

Nemotron 3.5 Lightning เหมาะสำหรับ AI บนเครื่อง Local หรือไม่? 💻

ใช่! Nemotron 3.5 Lightning ทำให้ AI Agent ที่มีความสามารถสูง สามารถเข้าถึงได้บนระบบ Local มากขึ้น รวมถึง:

• NVIDIA Jetson
• GeForce RTX 5090
• DGX Spark

นอกจากนี้ ยังรองรับการทำงานร่วมกับเครื่องมือมาตรฐานในอุตสาหกรรม เช่น LM Studio, llama.cpp, Ollama, และ Unsloth

เริ่มต้นสร้างสรรค์กับ Nemotron 3.5 Lightning 🚀

Nemotron 3.5 Lightning เป็นโมเดลแบบ Open อย่างแท้จริง ทั้ง Weights, Data, และ Recipes คุณจึงสามารถนำไปปรับใช้กับเวิร์กโฟลว์ของคุณ และ Deploy ได้ทุกที่

• ทดลองใช้งาน: ที่ build.nvidia.com หรือผ่าน OpenRouter
• ดาวน์โหลด Weights: จาก Hugging Face และ ModelScope
• ศึกษาเพิ่มเติม:
• Nemotron 3.5 Lightning cookbook
• คู่มือการ Deploy ด้วย vLLM, SGLang, และ TensorRT-LLM
• เอกสารการตั้งค่า Switchyard

ติดตามข่าวสารล่าสุดเกี่ยวกับ NVIDIA Nemotron ได้ทาง NVIDIA News และ NVIDIA AI บน LinkedIn, X, Discord, และ YouTube

#NVIDIA #Nemotron #AI #AIAgent #LLM #MoE #Tech

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/nvidia-nemotron-3-5-lightning-delivers-fast-accurate-specialized-task-execution-for-long-running-agents/

NVIDIA Dynamo Snapshot: เร่งสปีดการเริ่มต้น Inference Workloads บน Kubernetes

ในโลกของการพัฒนา AI ที่เติบโตอย่างรวดเร็ว การนำโมเดลไปใช้งานจริง (Production Inference) เป็นหัวใจสำคัญ แต่บ่อยครั้งที่ระบบต้องเผชิญกับความต้องการที่ผันผวน ทำให้ต้องมีการปรับขนาด (Scale) ระบบ Inference Replica ให้ยืดหยุ่นตามไปด้วย ปัญหาที่มักพบเจอคือ "Cold Start" หรือการเริ่มต้นระบบ Inference ใหม่ ซึ่งอาจใช้เวลานานหลายนาทีบน Kubernetes ทำให้ GPU ว่างเปล่า ไม่สามารถตอบสนองคำขอได้ทันเวลา ส่งผลกระทบต่อข้อตกลงระดับการให้บริการ (SLA)

NVIDIA Dynamo Snapshot คือโซลูชันที่เข้ามาแก้ปัญหานี้ โดยใช้เทคนิค Checkpoint/Restore เพื่อให้การเริ่มต้นระบบ Inference ทำได้เร็วขึ้นอย่างไม่น่าเชื่อ ใกล้เคียงกับ "ความเร็วแสง" สำหรับ Single-GPU Workloads เรามาทำความเข้าใจเบื้องหลังการออกแบบและเทคนิคการปรับปรุงประสิทธิภาพของ Dynamo Snapshot กัน

ปัญหา Cold Start คืออะไร?

เมื่อเกิดความต้องการใช้งาน AI สูงขึ้นอย่างกะทันหัน ระบบ Inference จำเป็นต้องเพิ่มจำนวน Replica อย่างรวดเร็ว แต่การเริ่มต้น Instance ใหม่ (Cold Start) บน Kubernetes นั้นใช้เวลานาน ซึ่งช่วงเวลานี้ GPU จะถูกจัดสรรไปแต่ยังไม่ได้ประมวลผลใดๆ ทำให้เกิดความล่าช้า และอาจทำให้ไม่สามารถตอบสนองความต้องการได้ทันเวลา

สำหรับ vLLM (v0.20.0) Single-GPU Workload เดียว การเริ่มต้นระบบแบบ Cold Start อาจใช้เวลานานหลายนาที ซึ่งกินเวลาไปกับ:

• การจัดสรรทรัพยากร
• การโหลดโมเดล
• การคอมไพล์ Kernel
• การตั้งค่าต่างๆ

เพื่อลดเวลาเริ่มต้นระบบให้เหลือน้อยที่สุด NVIDIA Dynamo Snapshot จึงถูกพัฒนาขึ้นมา

หัวใจหลัก: CRIU และ cuda-checkpoint

Dynamo Snapshot ทำงานโดยการบันทึกสถานะของ Inference Worker ที่กำลังทำงานอยู่ ซึ่งประกอบด้วย 2 ส่วนหลัก:

1. สถานะฝั่ง GPU (Device State): รวมถึง CUDA contexts, streams, หน่วยความจำ GPU (Device Memory), การแมป Address เสมือน และอื่นๆ ที่มองไม่เห็นจากฝั่ง Host โดยใช้ความสามารถของ CUDA Driver ผ่านเครื่องมือ cuda-checkpoint เพื่อบันทึกสถานะเหล่านี้ไปยังหน่วยความจำ CPU ของ Process ที่เป็นเจ้าของ CUDA Context นั้นๆ
2. สถานะฝั่ง Host (Host State): รวมถึงหน่วยความจำ CPU, Threads, File Descriptors, Namespaces และอื่นๆ ระบบ Linux มีกลไกในการบันทึกสถานะเหล่านี้อยู่แล้ว โดยใช้เครื่องมือโอเพนซอร์สอย่าง CRIU (Checkpoint/Restore in Userspace) เพื่อบันทึกสถานะของ Process Tree ทั้งหมดไปยัง Disk

เมื่อรวมเครื่องมือทั้งสองนี้เข้าด้วยกัน จะสามารถทำการ Checkpoint และ Restore สถานะของ Inference Worker ได้อย่างสมบูรณ์

ขั้นตอนการทำงาน:

• Checkpoint:
• cuda-checkpoint บันทึกสถานะ GPU ลงในหน่วยความจำ CPU
• CRIU บันทึกสถานะ Host-side ของ Process Tree ลงในโฟลเดอร์บน Storage
• Restore:
• CRIU กู้คืน Process Tree จากสถานะที่บันทึกไว้บน Storage (เช่น NFS/SMB) ทำให้สามารถดึง Artifact จาก Node อื่นได้
• cuda-checkpoint กู้คืนสถานะ GPU จากข้อมูลที่บันทึกไว้ในหน่วยความจำ CPU ลงบน GPU ใหม่

CRIU ทำงานแบบ "Freeze-and-Thaw" คือหยุดการทำงานของ Process ชั่วคราวเพื่อบันทึกสถานะ และเมื่อ Restore กลับมา การทำงานจะกลับมาดำเนินต่อจากจุดที่หยุดไปทันที โดยที่ Process ไม่รู้ตัวว่ามีการ Checkpoint หรือ Restore เกิดขึ้น

Dynamo Snapshot ในสภาพแวดล้อม Kubernetes

ใน Kubernetes Workloads จะทำงานภายใน Container ซึ่งอยู่ภายใน Pod การ Checkpoint ที่ระดับ Container จะทำให้สถานะของ Process Tree และ Filesystem เดินทางไปด้วยกัน

Dynamo Snapshot มีการติดตั้งผ่าน Helm Chart โดยใช้ snapshot-agent ซึ่งเป็น Privileged DaemonSet ที่จะทำงานบนทุก Node เพื่อจัดการการ Checkpoint และ Restore สำหรับ Container ที่จัดการโดย runc โดยไม่ต้องแก้ไข runc เอง

• เมื่อ Checkpoint: Agent จะรอจนกว่า Workload จะพร้อม (Readiness Probe) จากนั้นจึงเรียกใช้ cuda-checkpoint และ CRIU จากฝั่ง Host ก่อนที่จะเขียน Artifact ไปยัง Shared Storage
• เมื่อ Restore: Agent จะเปิดใช้งาน Placeholder Pod, กู้คืน Filesystem และกู้คืน Checkpoint ของ CRIU/CUDA เข้าไปใน Namespaces ของ Pod ใหม่ จากนั้น Worker ที่กู้คืนมาจะเข้ามารับช่วงการทำงานต่อ

Agent แต่ละตัวทำงานบน Node ของตนเอง ทำให้การ Checkpoint และ Restore สามารถทำงานแบบ Parallel ทั่วทั้ง Cluster ได้

Dynamo Snapshot และ Workload

Inference Worker ของ Dynamo จะเริ่มต้นทำงานเป็น 2 ระยะ:

1. การเริ่มต้น Inference Engine: ตั้งค่า Engine, โหลด Weights, Compile Kernels, Warm up จนพร้อมใช้งาน แต่ยังไม่สามารถถูกค้นพบจากภายนอก Pod ได้
2. การเริ่มต้น Distributed Runtime: Worker จะเชื่อมต่อไปยัง Control Plane ของ Dynamo และลงทะเบียนตัวเอง เพื่อให้ Router และส่วนประกอบอื่นๆ ค้นพบได้ Worker จึงจะ "Live" อย่างสมบูรณ์

หากทำการ Checkpoint/Restore แบบพื้นฐานโดยไม่คำนึงถึงสถานะการทำงานของ Workload จะเกิดปัญหา เพราะ Readiness Probe ของ Checkpoint Job จะตรงกับสถานะที่ Worker ถูกลงทะเบียนกับ Discovery Plane แล้ว ซึ่งหมายถึงมีการเชื่อมต่อ TCP ที่เปิดอยู่ ซึ่ง CRIU ไม่สามารถจับภาพได้

Quiesce/Resume Hooks คือทางออก:

กลไกนี้ช่วยให้ Workload เข้าสู่สถานะ "สงบ" (Quiescent State) ก่อนการ Checkpoint และจะกลับมาทำงานต่อ (Resume) เมื่อการ Restore เสร็จสมบูรณ์ ซึ่งมีประโยชน์ดังนี้:

• ลดขนาด Checkpoint: Workload สามารถล้างทรัพยากรที่ไม่จำเป็นก่อน Checkpoint ได้
• สร้างทรัพยากรที่ไม่สามารถ Checkpoint ได้: สำหรับ Multi-GPU/Multi-Node การเชื่อมต่อ RPC หรือสถานะ NIC ที่ต้องถูกสร้างขึ้นใหม่หลัง Restore

Dynamo Snapshot ใช้ Hooks เหล่านี้โดยกำหนดให้ Readiness Probe คือการปรากฏของไฟล์สัญญาณ "ready for checkpoint" ซึ่ง Worker จะเขียนไฟล์นี้หลังจาก Engine เริ่มต้นเสร็จสมบูรณ์ แต่ก่อนการเริ่มต้น Distributed Runtime จากนั้น Worker จะเข้าสู่ Loop รอรับสัญญาณ "restore complete" ในขณะที่ Agent ทำการ Checkpoint ภายนอก

การปรับปรุงประสิทธิภาพ (Optimizations)

1. การยกเลิกการแมป KV Cache (KV Cache Unmap and Release)

หนึ่งในการลดขนาด Checkpoint คือการคืนหน่วยความจำ KV Cache ที่ไม่ได้ใช้งานก่อน Checkpoint เนื่องจาก Checkpoint ถูกทำในขณะที่ Worker ยังไม่เคยประมวลผลคำขอใดๆ KV Cache จึงยังว่างเปล่า แต่ต้องรักษา Address เสมือนของ KV Cache ให้คงเดิม

ด้วยการใช้ API ของ CUDA Virtual Memory Management (cuMemCreate และ cuMemMap) การยกเลิกการจัดสรรหน่วยความจำจริง (cuMemUnmap และ cuMemRelease) ในขณะที่ยังคง Address เสมือนไว้เป็นเรื่องง่าย ทำให้ขนาด Artifact ลดลงอย่างมาก ตัวอย่างเช่น Qwen3-0.6B บน B200 ลดขนาดจาก ~190 GiB เหลือเพียง ~6 GiB

2. เร่งความเร็ว CRIU (Speeding up CRIU)

แม้จะมีการปรับปรุงข้างต้น เวลา Restore ก็ยังอาจนานเกินไป โดยเฉพาะอย่างยิ่งสำหรับโมเดลขนาดใหญ่

2.1 การ Restore แบบ Parallel ด้วย memfd:

vLLM และ SGLang มีกลไกย้าย GPU Allocation ที่เกี่ยวข้องกับ Weights ไปยัง CPU Shadow Buffer ซึ่ง CUDA ใช้ Shared Anonymous Memory ในการรองรับ และจะปรากฏใน Linux Kernel เป็น memfds (Anonymous, RAM-backed files)

CRIU แบบเดิมจะ Restore memfds เหล่านี้แบบ Serial คือสร้าง Object, ปรับขนาด, Map, อ่านข้อมูล แล้วค่อยไป Object ถัดไป

การปรับปรุง CRIU จะทำการ Enumerate shmem-backed objects ที่ไม่ซ้ำกันทั้งหมด จากนั้นใช้ Thread Pool เพื่อ Restore แบบ Parallel ทำให้การ Restore ใช้ประโยชน์จาก Bandwidth ของ Storage และ CPU Parallelism ได้เต็มที่

2.2 Linux Native AIO สำหรับ Anonymous Memory:

หลังจาก CRIU กู้คืนทรัพยากรที่แชร์กันแล้ว (Files, Sockets, shmem objects, memfds) ขั้นตอนต่อไปคือการเติมข้อมูลให้กับ Process Memory ของแต่ละ Process ซึ่งเป็นส่วนสำคัญที่ต้องใช้ความเร็วในการดำเนินการ

ผลลัพธ์ที่น่าทึ่ง

ผลการทดลองแสดงให้เห็นว่า Dynamo Snapshot สามารถลดเวลา Startup ได้สูงสุดถึง 21 เท่า สำหรับโมเดลขนาดใหญ่ เช่น gpt-oss-120b โดยใช้เวลา Restore ที่ใกล้เคียงกับ "ความเร็วแสง" ซึ่งดีกว่า Cold Start แบบดั้งเดิมอย่างมีนัยสำคัญ

เทคโนโลยีนี้ปูทางไปสู่การรองรับ Multi-GPU/Multi-Node ในอนาคต รวมถึงการผสานรวมกับ TensorRT-LLM เพื่อมอบประสิทธิภาพสูงสุดในการใช้งาน AI Inference Workloads บน Kubernetes

#คำถามที่พบบ่อย

Dynamo Snapshot แตกต่างจาก Kubernetes Native Checkpoint/Restore อย่างไร?

Dynamo Snapshot ใช้ DaemonSet ที่ทำงานบนทุก Node และควบคุม CRIU ได้อย่างใกล้ชิดสำหรับการปรับแต่งประสิทธิภาพ รวมถึงสามารถจัดเก็บ Checkpoint Artifact ไว้ใน Storage Backend ที่ยืดหยุ่นได้ ต่างจาก Kubernetes Native ที่อาจมีข้อจำกัดมากกว่า

Quiesce/Resume Hooks สำคัญอย่างไร?

Hooks เหล่านี้ช่วยให้ Workload สามารถจัดการทรัพยากรได้อย่างเหมาะสมก่อน Checkpoint และสร้างทรัพยากรที่จำเป็นใหม่หลัง Restore ทำให้การทำงานราบรื่นและมีประสิทธิภาพ โดยเฉพาะอย่างยิ่งสำหรับระบบที่ซับซ้อน

การปรับปรุง CRIU มีผลต่อการ Restore อย่างไร?

การ Restore แบบ Parallel ด้วย memfd และการใช้ Linux Native AIO สำหรับ Anonymous Memory ช่วยลดคอขวดในการกู้คืนข้อมูล ทำให้เวลา Restore เร็วขึ้นอย่างมาก โดยเฉพาะกับโมเดลขนาดใหญ่

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/nvidia-dynamo-snapshot-fast-startup-for-inference-workloads-on-kubernetes/

Meta Muse Glimmer: ปลดล็อกพลัง AI Agent ทำงานบนเครื่องของคุณด้วย NVIDIA

Meta กลับมาสู่ชุมชนโอเพนซอร์สอีกครั้งด้วยการเปิดตัว Muse Glimmer โมเดลภาษาขนาดใหญ่ (LLM) แบบหนาแน่น (dense model) ขนาด 30 พันล้านพารามิเตอร์ ที่มาพร้อมกับความสามารถในการจัดการบริบทที่ยาวกว่า 120,000 โทเค็น ออกแบบมาเพื่อการทำงานของ AI Agent ที่ต้องการรันแบบออฟไลน์และต่อเนื่องยาวนาน โดยเฉพาะอย่างยิ่งบนแพลตฟอร์ม NVIDIA ที่หลากหลาย

Muse Glimmer คืออะไร และทำไมถึงน่าสนใจ?

Muse Glimmer ไม่ใช่แค่โมเดล LLM ทั่วไป แต่ถูกสร้างขึ้นมาเพื่อตอบโจทย์การทำงานของ AI Agent โดยเฉพาะ ซึ่งแตกต่างจากโมเดลที่เน้นการสนทนา (chat-first models) ที่มักจะปรับแต่งมาเพื่อการโต้ตอบแบบครั้งเดียวและเน้นความเร็วในการตอบสนองคำแรก

ความแตกต่างที่สำคัญสำหรับ AI Agent

• การทำงานที่ต่อเนื่องยาวนาน: AI Agent ที่ทำหน้าที่เขียนโค้ด, แก้ไขเอกสาร, หรือจัดการฐานข้อมูล อาจต้องเรียกใช้เครื่องมือหลายอย่างในเซสชันเดียว Muse Glimmer ถูกออกแบบมาเพื่อรองรับการทำงานลักษณะนี้ โดยให้ความสำคัญกับความน่าเชื่อถือ, ความสอดคล้องของบริบทที่ยาว, และประสิทธิภาพที่คงที่
• สถาปัตยกรรมแบบ Dense: โมเดลนี้ใช้สถาปัตยกรรมแบบหนาแน่น ซึ่งหมายความว่าทุกพารามิเตอร์จะถูกใช้งานสำหรับแต่ละโทเค็นที่ประมวลผล ทำให้ได้ผลลัพธ์ที่แม่นยำ, การจัดการบริบทที่ยาวได้อย่างมีประสิทธิภาพ, และความหน่วง (latency) ที่คาดเดาได้ สิ่งนี้ช่วยลดปัญหาที่อาจเกิดขึ้นในโมเดลแบบ Mixture-of-Experts (MoE) ที่ต้องมีการเลือก "ผู้เชี่ยวชาญ" ในแต่ละครั้ง
• ความเป็นส่วนตัวและความปลอดภัย: ด้วยขนาดที่เหมาะสม Muse Glimmer สามารถรันได้เต็มรูปแบบบน GPU ของ NVIDIA เพียงตัวเดียว โดยไม่จำเป็นต้องแบ่งโมเดล (model sharding) หรือใช้การประมวลผลร่วมกับ CPU ทำให้ข้อมูลที่ละเอียดอ่อน เช่น ไฟล์ส่วนตัว, ข้อมูลประจำตัว, หรือเอกสารสำคัญ ไม่ต้องออกจากเครื่องของผู้ใช้งาน

ประสิทธิภาพบนแพลตฟอร์ม NVIDIA

Muse Glimmer ได้รับการปรับแต่งให้ทำงานได้อย่างยอดเยี่ยมบนฮาร์ดแวร์ NVIDIA หลากหลายระดับ ตั้งแต่เดสก์ท็อปไปจนถึงเวิร์กสเตชันและระบบ Edge

• NVIDIA GeForce RTX 5090: การ์ดจอรุ่นนี้ให้ VRAM สูงถึง 32GB พร้อม Tensor Cores รุ่นที่ 5 ทำให้ Muse Glimmer สามารถรันบนอุปกรณ์ของนักพัฒนาได้อย่างเต็มที่ ช่วยรักษาความปลอดภัยของโค้ดที่เป็นกรรมสิทธิ์และลดต้นทุนในการประมวลผล
• NVIDIA DGX Spark: มอบประสิทธิภาพระดับเวิร์กสเตชันสำหรับ AI Agent ในระบบขนาดกะทัดรัด พร้อมการเชื่อมต่อหน่วยความจำความเร็วสูงผ่าน NVIDIA NVLink และการติดตั้งที่ง่ายด้วย NVIDIA NIM containers
• NVIDIA DGX Station: สำหรับองค์กรที่ต้องการประสิทธิภาพระดับสูงในสภาพแวดล้อมภายในองค์กร (on-premise) โดยเฉพาะอย่างยิ่งในกรณีที่มีข้อกำหนดเรื่องความปลอดภัยสูง (air-gap mandates) หรือกรอบการปฏิบัติตามข้อกำหนดที่การประมวลผลบนคลาวด์ไม่สามารถทำได้
• NVIDIA Jetson: ขยายขีดความสามารถของ Muse Glimmer ไปสู่ระบบ Edge สำหรับหุ่นยนต์, ระบบอัตโนมัติในอุตสาหกรรม, และระบบฝังตัว (embedded systems) ที่ต้องการการตัดสินใจแบบเรียลไทม์ ณ จุดปฏิบัติงาน และต้องการการแยกเครือข่าย

บน NVIDIA Blackwell Ultra, Muse Glimmer สามารถทำความเร็วได้สูงกว่า 20,000 โทเค็นต่อวินาทีต่อ GPU ทำให้สามารถรัน AI Agent แบบเปิดตลอดเวลา (always-on agents) ได้อย่างมีประสิทธิภาพและตอบสนองได้รวดเร็ว

การพัฒนาและปรับแต่ง AI Agent

NVIDIA มีเครื่องมือที่ช่วยให้นักพัฒนาสามารถสร้างและปรับแต่ง Muse Glimmer สำหรับกรณีใช้งานที่หลากหลาย:

• NVIDIA NeMo Claw: ใช้ในสภาพแวดล้อม OpenShell ที่ปลอดภัย เพื่อสร้างผู้ช่วยส่วนตัวที่ทำงานต่อเนื่องยาวนาน สำหรับงานต่างๆ เช่น การสร้างโค้ด, ผู้ช่วยส่วนตัว, หรือระบบสนับสนุนอัตโนมัติ
• NVIDIA NeMo AutoModel: ช่วยให้สามารถปรับแต่งโมเดล (fine-tune) ได้อย่างมีประสิทธิภาพสูง รองรับการทำงานร่วมกับ Hugging Face checkpoints โดยตรง ทำให้การทดลองทำได้อย่างรวดเร็วบน NVIDIA GPUs
• NeMo RL: สำหรับการเรียนรู้แบบเสริมกำลัง (reinforcement learning)

ตัวเลือกการติดตั้งที่ยืดหยุ่น

NVIDIA รองรับการติดตั้ง Muse Glimmer หลายรูปแบบ เพื่อตอบสนองความต้องการของนักพัฒนาที่แตกต่างกัน:

• SGLang และ vLLM: เป็นไลบรารีโอเพนซอร์สสำหรับการประมวลผล (inference) ที่นักพัฒนาต้องการควบคุมประสิทธิภาพบนแพลตฟอร์ม NVIDIA อย่างละเอียด
• NVIDIA NIM: คอนเทนเนอร์สำเร็จรูปที่ปรับแต่งมาอย่างดี ช่วยให้การติดตั้งและการตั้งค่าทำได้ง่าย เพียงดาวน์โหลดและใช้งาน ทำให้ทีมสามารถมุ่งเน้นไปที่การสร้างและขยายขนาดของ AI Agent ได้อย่างเต็มที่

เริ่มต้นใช้งาน Muse Glimmer และ AI Agent ออฟไลน์

หากต้องการเริ่มต้นใช้งาน เพียงดาวน์โหลดน้ำหนักโมเดล (weights) ของ Muse Glimmer จาก HuggingFace และเลือกวิธีการติดตั้งที่เหมาะสม ไม่ว่าจะเป็นการใช้ไลบรารี inference ที่กล่าวมา, NVIDIA NIM, หรือทดลองบน build.nvidia.com เพื่อปลดล็อกศักยภาพของ AI Agent ที่ทำงานได้อย่างมีประสิทธิภาพและปลอดภัยบนเครื่องของคุณเอง

#AI #Meta #NVIDIA #MuseGlimmer #LLM

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/run-local-agentic-ai-workflows-with-metas-muse-glimmer-on-nvidia/

Step 3.7 Flash: โมเดล AI อัจฉริยะที่พร้อมใช้งานระดับองค์กรบน NVIDIA GPU

ในยุคที่ AI ก้าวข้ามการสร้างข้อความธรรมดา ๆ ไปสู่ระบบที่สามารถรับรู้ ค้นหา และประมวลผลข้อมูลหลากหลายรูปแบบ ทั้งรูปภาพ เอกสาร วิดีโอ และภาษา ได้แบบเรียลไทม์ เทคโนโลยีนี้กำลังเปลี่ยนข้อมูลที่กระจัดกระจายให้กลายเป็นข้อมูลเชิงลึกที่นำไปปฏิบัติได้จริง ล่าสุด Step 3.7 Flash จาก StepFun ได้ยกระดับความสามารถเหล่านี้สู่ระดับการใช้งานจริงในระดับองค์กร โดยพร้อมใช้งานบนโครงสร้างพื้นฐานที่เร่งความเร็วด้วย NVIDIA GPU

Step 3.7 Flash คืออะไร? 💡

Step 3.7 Flash เป็นโมเดลภาษา-ภาพ (Vision-Language Model) แบบ Mixture-of-Experts (MoE) ที่มีพารามิเตอร์ถึง 198 พันล้านตัว แต่ใช้พารามิเตอร์ที่ทำงานจริงเพียงประมาณ 11 พันล้านตัวต่อการประมวลผลหนึ่งครั้ง ถูกปรับแต่งมาเพื่อเวิร์กโฟลว์แบบ Agentic ที่ผสมผสานการรับรู้ (Perception) การค้นหา (Search) และการให้เหตุผลหลายขั้นตอน (Multi-step Reasoning) ในระดับ Production Scale

จุดเด่นของโมเดลนี้คือ:

• รองรับการป้อนข้อมูลรูปภาพและวิดีโอโดยตรง: ทำให้เข้าใจบริบทได้กว้างขวางขึ้น
• ระดับการให้เหตุผลที่ปรับได้ 3 ระดับ: Low, Medium, และ High เพื่อความยืดหยุ่นในการใช้งาน
• Context Window ขนาดใหญ่ 256k: สามารถประมวลผลข้อมูลจำนวนมหาศาลในครั้งเดียว
• เหมาะสำหรับองค์กร: ออกแบบมาเพื่อการใช้งานในระดับองค์กร เช่น การวิเคราะห์ทางการเงิน, Agent สำหรับการเขียนโค้ดพร้อมกัน, และการใช้งาน Multimodal อื่น ๆ ที่ต้องการปริมาณงานสูง (High-throughput)

นอกจากนี้ ยังมี StepFun’s NVFP4-quantized checkpoint ที่พร้อมใช้งานผ่าน Hugging Face เพื่อเพิ่มประสิทธิภาพการ Inference ด้วยการลดความต้องการหน่วยความจำและพื้นที่จัดเก็บ

การใช้งานและพัฒนาบนโครงสร้างพื้นฐาน NVIDIA 🛠️

Step 3.7 Flash สามารถทำงานร่วมกับ Framework แบบ Open Source ได้หลากหลาย เช่น SGLang, NVIDIA TensorRT-LLM, และ vLLM โดยใช้ประโยชน์จาก Kernels ที่ปรับแต่งมาสำหรับฮาร์ดแวร์ NVIDIA โดยเฉพาะ

สำหรับนักพัฒนา:

• NVIDIA Endpoints: สามารถใช้ GPU-accelerated endpoints ที่มีให้บน build.nvidia.com สำหรับการสร้างต้นแบบและประเมินผล Step 3.7 Flash ได้ ลองใช้งานใน Demo Notebook ที่รวม Step 3.7 Flash และ NVIDIA Nemotron Parse เพื่อสกัดข้อมูลเชิงลึกจากเอกสารที่ซับซ้อน เช่น รายงานทางการเงิน, สไลด์นำเสนอ, และบทความทางวิทยาศาสตร์ (รวมถึง PDF) และจัดระเบียบผลลัพธ์
• การปรับแต่ง (Fine-tuning) ด้วย NVIDIA NeMo Framework: สามารถปรับแต่ง Step 3.7 Flash ให้เข้ากับข้อมูลเฉพาะทางขององค์กรได้ โดยใช้ไลบรารีแบบ Open Source จาก NVIDIA NeMo Framework โดยเฉพาะไลบรารี NVIDIA NeMo Automodel ที่รองรับการทำ Supervised Fine-Tuning (SFT) และ LoRA แบบประหยัดหน่วยความจำ ด้วยความเร็วสูงถึง 600 tokens/sec บน Hopper GPUs นอกจากนี้ ยังมี NeMo Megatron-Bridge สำหรับการฝึกโมเดลขนาดใหญ่ที่ต้องการประสิทธิภาพขั้นสูง

การนำไปใช้งานจริงในระดับ Production ด้วย NVIDIA NIM ✅

NVIDIA NIM (NVIDIA Inference Microservices) ช่วยให้การนำ Step 3.7 Flash จากการพัฒนาไปสู่ Production เป็นเรื่องง่าย ด้วยบริการ Inference ที่ปรับแต่งมาในรูปแบบ Container ที่มี API มาตรฐาน ทำให้มีความยืดหยุ่นในการปรับใช้ สามารถดาวน์โหลดและรันได้ทั้งแบบ On-premises, บน Cloud, หรือในสภาพแวดล้อมแบบ Hybrid NIM ยังรองรับ OpenAI inference มาตรฐานสำหรับการส่งคำขอไปยัง NIM Server

ขั้นตอนการใช้งาน NIM:

1. ดาวน์โหลด NIM container จาก NVIDIA container registry (ต้องมี Enterprise License)
2. เริ่ม Server ด้วย OpenAI client
3. ส่ง Input ทั้งแบบข้อความหรือรูปภาพไปยัง Endpoint

ตัวเลือกการปรับใช้ที่หลากหลาย 🚀

NVIDIA มีตัวเลือกที่ครอบคลุมสำหรับการนำ Step 3.7 Flash ไปใช้ในทุกขั้นตอนของการพัฒนาและปรับใช้ ตั้งแต่การใช้งานใน Data Center ด้วย NVIDIA Blackwell, การใช้งานบนเครื่องของนักพัฒนาด้วย NVIDIA DGX Station, ไปจนถึงบริการ NIM microservices และเวิร์กโฟลว์การปรับแต่งแบบ Day 0

NVIDIA เป็นผู้สนับสนุนสำคัญของ Open Source Ecosystem และมุ่งมั่นที่จะสนับสนุนโมเดลแบบเปิดอย่าง Step 3.7 Flash เพื่อส่งเสริมความโปร่งใสของ AI และเปิดโอกาสให้ผู้ใช้ได้แบ่งปันผลงานด้านความปลอดภัยและความทนทานของ AI

เริ่มต้นใช้งาน:

• สำรวจ Step 3.7 Flash บน Hugging Face
• ทดสอบกับข้อมูลของคุณเองบน build.nvidia.com
• ทดลองใช้งานในเครื่องบน DGX Station โดยใช้ vLLM Playbook

#AI #MultimodalAI #NVIDIA #Step3.7Flash

ขอบคุณ แหล่งข้อมูล
https://developer.nvidia.com/blog/run-step-3-7-flash-on-nvidia-gpus-with-enterprise-ready-multimodal-ai/