4

การสนับสนุนการสำรวจแบบขนานด้วยการคำนวณแบบเทนเซอร์และสถาปัตยกรรมแบบรวมศูนย์

AI999第6课:系统级持续演化:Genesis 与软件世界的沉淀
00:00

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

ทำไมความหลากหลายจึงต้องการอัตราการประมวลผล

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

วิวัฒนาการของวิธีการ: นำ “วิธีการสร้างตัวเลือก” เข้าสู่กระบวนการวิวัฒนาการด้วย

เมื่อขีดความสามารถด้านพลังการประมวลผลเปิดกว้างขึ้น EvoX ได้ยกระดับวัตถุที่ปรับให้เหมาะสมขึ้นไปอีกชั้น ไม่ได้เพียงแก้ปัญหาเท่านั้น แต่ยังนำวิธีการสร้างคำตอบที่เป็นตัวเลือกเข้ามาเป็นวัตถุของวิวัฒนาการด้วย นี่คือ วิวัฒนาการของวิธีการ ตัวอย่างเช่น MetaDE อัลกอริทึมชั้นในแก้ปัญหาจริงในขณะที่อัลกอริทึมชั้นนอกวิวัฒนาการการตั้งค่าและกลยุทธ์ของอัลกอริทึมชั้นใน (เช่น กลยุทธ์การกลายพันธุ์และไฮเปอร์พารามิเตอร์ของ Differential Evolution) พร้อมทั้งรันงานชั้นในจำนวนมากแบบขนานด้วย GPU เพื่อให้ประสิทธิภาพของงานย้อนกลับมาชี้แนะการเลือกการตั้งค่าของชั้นนอก AutoPSO และ EvoGO ยิ่งไปกว่านั้นยังใช้การประกอบส่วนประกอบของ Particle Swarm และใช้ผลตอบกลับจากประวัติเพื่อเรียนรู้วิธีการสร้างตัวเลือก ทำให้ก้าวข้ามจาก “ปรับพารามิเตอร์” ไปสู่ “ปรับโครงสร้างอัลกอริทึม” วิวัฒนาการสองชั้นทั้งภายในและภายนอกนี้ย่อมต้องการให้งานชั้นในจำนวนมากได้รับการประเมินและอัปเดตสถานะแบบกลุ่มในรุ่นเดียวกันหรือแม้แต่ในขณะเดียวกัน จึงตั้งข้อกำหนดที่สูงขึ้นต่ออัตราการประมวลผลและขีดความสามารถแบบขนาน

กราฟการคำนวณแบบเทนเซอร์: เปลี่ยนลูปให้เป็นการดำเนินการเทนเซอร์แบบกลุ่ม

ลูป CPU แบบอนุกรมดั้งเดิมมักดำเนินการ “ประเมิน—บันทึก—อัปเดต” ทีละตัว โดยแต่ละครั้งจะเรียกใช้โอเปอเรเตอร์ขนาดเล็กเท่านั้น ซึ่งนำมาซึ่งต้นทุนสามประเภท ต้นทุนการจัดตารางสูง โอเปอเรเตอร์กระจัดกระจาย อัตราการใช้งาน GPU ต่ำ วิธีของกราฟการคำนวณแบบเทนเซอร์คือการนำ การดูแลรักษาประชากร การประเมินแบบกลุ่ม และการอัปเดตสถานะมาจัดระเบียบเป็นชุดของการดำเนินการเทนเซอร์แบบกลุ่ม ทำให้ตัวเลือกในรุ่นเดียวกันหรือแม้แต่หลายรุ่นถูกคำนวณแบบขนาน ตัวอย่างเช่น เมื่อรุ่น同一มีคำตอบที่เป็นตัวเลือก N ตัว การทำงานแบบอนุกรมจะวนซ้ำทีละตัว แต่การทำงานแบบเทนเซอร์จะจัดระเบียบประชากรให้เป็นเทนเซอร์เดียว และทำการประเมินแบบกลุ่มพร้อมการอัปเดตสถานะแบบขนานในครั้งเดียว จึงลดต้นทุนการจัดตารางและเพิ่มอัตราการใช้งาน GPU ได้อย่างมีนัยสำคัญ

สถาปัตยกรรมแบบรวมศูนย์: ทำให้กลไกแบบขนานนำกลับมาใช้ซ้ำได้

เพียงเขียนลูปใหม่ให้เป็นเทนเซอร์ยังไม่พอ หากอัลกอริทึม ปัญหา และตรรกะการจัดตารางผูกติดกัน การเปลี่ยนอัลกอริทึมเชิงวิวัฒนาการหรือเปลี่ยนประเภทของงานก็ต้องเขียนใหม่ทั้งหมด สถาปัตยกรรมแบบรวมศูนย์จึงแยก 算法、问题、工作流、Runtime 调度 โมดูลเหล่านี้ให้เป็นอิสระจากกัน ทำให้กลไกแบบขนานเชิงเทนเซอร์สามารถนำกลับมาใช้กับอัลกอริทึมเชิงวิวัฒนาการและงานที่แตกต่างกันได้ (เช่น สถานการณ์วิวัฒนาการของวิธีการอย่าง MetaDE, AutoPSO) พร้อมกับ การจัดตารางพลังการประมวลผลแบบต่างชนิด ซึ่งสามารถจัดการทรัพยากร เช่น CPU และ GPU ในระดับงานแบบกลุ่ม เพื่อรองรับการสำรวจแบบขนานที่ประกอบรวมได้และขยายได้

ลูป CPU แบบอนุกรมดั้งเดิมตัวเลือก 1ประเมินอัปเดตตัวเลือก 2ประเมินอัปเดตตัวเลือก 3ประเมินอัปเดต⋯อัตราการใช้งาน GPUการใช้งานต่ำแบบอนุกรมทีละตัว: ประเมิน → บันทึก → อัปเดตต้นทุนการจัดตารางสูง · โอเปอเรเตอร์กระจัดกระจาย · อัตราการใช้งาน GPU ต่ำการคำนวณเทนเซอร์แบบกลุ่มด้วย GPU1เทนเซอร์ประชากร (คำตอบที่เป็นตัวเลือก N ตัว)2การประเมินแบบกลุ่ม3การอัปเดตสถานะแบบขนาน4การจัดตารางพลังการประมวลผลแบบต่างชนิด (CPU / GPU)การดำเนินการเทนเซอร์แบบกลุ่มในครั้งเดียวต้นทุนการจัดตารางต่ำ · โอเปอเรเตอร์กระจัดกระจายน้อย · การใช้งาน GPU สูงฐานรากแบบรวมที่เปิดกว้างและแยกส่วนอัลกอริทึมปัญหาเวิร์กโฟลว์การจัดตารางของ Runtime

ทำไมนี่จึงเป็นขีดความสามารถระดับ “ฐานราก”

ฐานรากทางวิศวกรรมที่ GPU และโมเดลขนาดใหญ่นำมา ทำให้การคำนวณแบบกลุ่มเชิงเทนเซอร์ยกระดับจากการปรับให้เหมาะสมเฉพาะจุดขึ้นเป็นขีดความสามารถพื้นฐานที่รองรับการสำรวจเชิงวิวัฒนาการระดับระบบ กล่าวอีกนัยหนึ่ง การคำนวณแบบเทนเซอร์ตอบโจทย์ “ทำงานได้เร็ว” ส่วนสถาปัตยกรรมแบบรวมที่เปิดกว้างและแยกส่วนตอบโจทย์ “เปลี่ยนได้คล่อง” โดยอย่างแรกมอบอัตราการประมวลผล และอย่างหลังมอบขอบเขตการนำกลับมาใช้ซ้ำที่ประกอบรวมได้และขยายได้ เมื่อทั้งสองรวมกัน การสำรวจเชิงวิวัฒนาการแบบขนานที่มีความเข้มข้นสูงและหลากหลายสูงจึงกลายเป็นขีดความสามารถทางวิศวกรรมได้จริง

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