พักโน้ตบุ๊ก GPU แล้วกลับมาทดลองต่อจากจุดเดิมได้ไหม?

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

Google ประกาศ GKE Workspaces วันที่ 4 พฤศจิกายน สภาพแวดล้อมพัฒนาแบบโอเพนซอร์สนี้ทำงานบนคลัสเตอร์ Google Kubernetes Engine ของทีม โดยใช้แดชบอร์ดในเบราว์เซอร์เปิด JupyterLab หรือ VS Code พร้อมทรัพยากรที่กำหนดไว้ โครงการต่อยอดจาก Kubeflow Workspaces และมีเอกสารวิธีพักและกู้คืนเซสชันที่รองรับ ทีมจึงต้องตอบว่าสถานะใดที่ต้องใช้พรุ่งนี้ และต้องจองทรัพยากรอะไรไว้เพื่อรักษาสถานะนั้น

ภาพตัดจากเดโมโน้ตบุ๊กที่กลับมาทำต่อได้ของ GKE Workspaces ภายใต้ Apache 2.0 แหล่งภาพ · สัญญาอนุญาต

ไฟล์โน้ตบุ๊กกับเซสชันที่รันอยู่เก็บคนละอย่าง

พักโน้ตบุ๊ก GPU ภาพประกอบต้นฉบับโดย Telli.sh

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

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

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

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

พื้นที่ทำงานที่หยุดแล้วยังมีต้นทุน

ติดตามค่าใช้จ่ายจริง ภาพประกอบต้นฉบับโดย Telli.sh

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

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

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

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

ทีมแพลตฟอร์มยังดูแลข้อตกลงการใช้งานพื้นที่ทำงาน

การเปิดให้ผู้ใช้จัดการเองเปลี่ยนว่าใครกดปุ่ม ผู้ดูแลยังเลือกอิมเมจที่เปิดได้ ตัวเร่งที่ขอได้ วิธีจัดโควตาและแยกสภาพแวดล้อมของคลัสเตอร์ คลัง GKE Workspaces ระบุว่าโค้ดใช้ Apache 2.0 และโครงการไม่มีการสนับสนุนในฐานะผลิตภัณฑ์ Google อย่างเป็นทางการ เมื่อประเมินให้ทีม ให้คิดการติดตั้งและดูแลเป็นงานวิศวกรรมที่ต้องมีผู้รับผิดชอบ

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

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

ทดลองพักและกู้คืนหนึ่งรอบ

1. อ่านคู่มือติดตั้งของโครงการและข้อกำหนดปัจจุบันของสภาพแวดล้อม GKE สำหรับสแนปช็อตและตัวเร่ง สร้างพื้นที่ทำงานทดสอบพร้อมสิทธิ์และเพดานทรัพยากรที่สอดคล้องกับวิธีใช้งานที่เสนอ
2. เปิดโน้ตบุ๊กที่ทำซ้ำได้ เก็บข้อมูลเข้า เช็กพอยต์ของแอปพลิเคชันระหว่างทาง และไฟล์ผลขนาดเล็ก จดเวลาและทรัพยากรที่ได้รับก่อนพัก
3. พักพื้นที่ทำงานและตรวจทรัพยากรคลัสเตอร์ ดูว่าพ็อดหยุดไหม ตัวเร่งจัดสรรให้งานอื่นได้หรือยัง และพื้นที่จัดเก็บอะไรยังอยู่
4. กลับมารันพื้นที่ทำงาน ยืนยันไฟล์และสถานะที่คาดไว้ แล้วรันเซลล์หนึ่งที่ใช้โมเดลเดิม จับเวลาจากคำขอกลับมาทำต่อจนโน้ตบุ๊กใช้งานได้
5. ลองกู้จากไฟล์กับเช็กพอยต์ของแอปพลิเคชันด้วย วิธีนี้เป็นทั้งทางเลือกและจุดเปรียบเทียบหากการกู้จากสแนปช็อตช้าหรือใช้ไม่ได้
6. ทบทวนการตั้งค่าช่วงว่างกับทีม ตกลงว่าเมื่อไรจึงถือว่าไม่มีการใช้งาน และงานที่รันนานต้องใช้พื้นที่ทำงานอีกประเภทหรือมีกติกาเฉพาะหรือไม่

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

คำนวณว่าเวลา GPU หายไปตรงไหน

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

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

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

เลือกสถานะที่จะเก็บก่อนเปิดให้พัก

คลัง GKE Workspaces อธิบายวิธีใช้ VS Code แบบไม่เก็บสถานะโปรเซส และมีตัวอย่าง JupyterLab ที่เก็บสถานะแยกต่างหาก ตัวอย่างหลังสาธิตการกู้คืนโน้ตบุ๊ก GPU รวมถึงกรณีใช้โมเดล Qwen2.5 ขนาด 3B บน T4 หนึ่งตัว สแนปช็อตพ็อด Kubernetes และตัวอย่างมีเงื่อนไขความเข้ากันได้เฉพาะ เอกสาร GKE ของ Google อธิบายบทบาท GKE Sandbox ตลอดจนการตั้งค่าโหนดและอิมเมจที่รองรับ สำหรับตัวอย่าง GPU ให้ตรวจว่าโหนดใหม่ใช้ GPU รุ่นเดียวกันที่รองรับและมีสภาพแวดล้อมเข้ากันได้ก่อนพึ่งการกู้คืน

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

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

ให้ทีมเห็นต้นทุนจากการทดลองชุดเดียว

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

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

ใส่การทดสอบกลับมาทำต่อไว้ในรายการก่อนออกเวอร์ชัน

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

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

เก็บงานส่วนที่สร้างใหม่ยากที่สุด

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

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

แหล่งข้อมูล

• แนวคิดและความเข้ากันได้ของสแนปช็อตพ็อด GKE

• ตัวอย่างโน้ตบุ๊กที่กลับมาทำต่อได้ ณ รุ่นที่ใช้สาธิต

• ประกาศวันที่ 4 พฤศจิกายนและวิดีโอพื้นที่ทำงานจาก Google Open Source Blog

• ซอร์สโค้ด GKE Workspaces สถานะการสนับสนุน และคู่มือติดตั้ง

---

หากต้องการเก็บบันทึกการสนทนาและการตัดสินใจเบื้องหลังงานให้ค้นหาได้ สร้างบัญชี Telli.sh.