เปลี่ยน GitHub CI ของคุณให้ทำงานบน Hugging Face Jobs: คู่มือฉบับสมบูรณ์

การจัดการระบบ Continuous Integration (CI) สำหรับโปรเจกต์ Open Source โดยเฉพาะโปรเจกต์ Machine Learning นั้นมีความท้าทายหลายประการ GitHub Actions ซึ่งเป็นเครื่องมือยอดนิยมอาจมีข้อจำกัดในเรื่องความเร็ว การบำรุงรักษา หรือการเข้าถึงฮาร์ดแวร์พิเศษอย่าง GPU ทำให้โปรเจกต์อย่าง Trackio ต้องมองหาโซลูชันที่ดีกว่า

ในบทความนี้ เราจะมาดูกันว่าคุณจะสามารถย้ายระบบ CI จาก GitHub Actions มาทำงานบน Hugging Face Jobs ได้อย่างไร เพื่อให้ได้ทั้งความเสถียร ประสิทธิภาพที่เพิ่มขึ้น และการเข้าถึงฮาร์ดแวร์ที่หลากหลาย โดยเฉพาะอย่างยิ่ง GPU ซึ่งจำเป็นสำหรับการทดสอบ ML บางประเภท

Hugging Face Jobs คืออะไร?

Hugging Face Jobs คือบริการโครงสร้างพื้นฐานแบบ Serverless ที่ให้คุณรันคำสั่งหรือสคริปต์บนฮาร์ดแวร์ที่หลากหลายของ Hugging Face ได้อย่างง่ายดาย หัวใจหลักของ Job ประกอบด้วย:

  • Docker image: สามารถเลือกใช้จาก Docker Hub หรือ Hugging Face Space ที่มีอยู่
  • Hardware flavor: เลือกประเภทฮาร์ดแวร์ที่ต้องการ เช่น CPU, t4-small หรือ GPU h200
  • Optional environment variables and secrets: ตั้งค่าตัวแปรสภาพแวดล้อมหรือข้อมูลลับเพิ่มเติมได้

ด้วยคุณสมบัติเหล่านี้ Hugging Face Jobs จึงเป็นโซลูชันที่เหมาะอย่างยิ่งสำหรับงาน CI เพราะงาน CI โดยทั่วไปมักเป็นการสั่งงานแบบ Command-driven ทำงานในสภาพแวดล้อมที่สะอาด และสามารถเลือกฮาร์ดแวร์ที่เหมาะสมกับงานได้พอดี สำหรับไลบรารี ML การใช้งาน GPU เป็นจุดเด่นที่น่าสนใจมาก เพราะช่วยให้คุณสามารถรันชุดทดสอบบนฮาร์ดแวร์ GPU จริงได้ โดยไม่ต้องดูแลรักษาระบบ Runner ของตัวเองให้พร้อมใช้งานตลอดเวลา

ภาพรวมการทำงานร่วมกัน

หัวใจสำคัญคือการเชื่อมต่อ GitHub Actions เข้ากับ Hugging Face Jobs โดยใช้ huggingface/jobs-actions ซึ่งเป็นส่วนเสริมขนาดเล็กที่ทำหน้าที่แปลง GitHub Actions job ให้กลายเป็น Self-hosted runner แบบชั่วคราวที่ทำงานภายใน Hugging Face Job

กระบวนการทำงานจะเป็นดังนี้:

  1. Pull Request Trigger: เมื่อมีการเปิด Pull Request ระบบ GitHub Actions จะเริ่มทำงาน
  2. Job Queuing: GitHub จะจัดคิวงานที่ระบุ runs-on label ที่ไม่พร้อมใช้งาน เช่น hf-jobs-cpu-upgrade หรือ hf-jobs-t4-small และส่ง Webhook workflow_job.queued ไปยัง Dispatcher ผ่าน GitHub App
  3. Dispatcher Verification & Job Launch: Dispatcher Space จะทำการยืนยัน Webhook ตรวจสอบ Label hf-jobs-* และสร้าง GitHub Runner Registration Token ที่มีอายุสั้น จากนั้นจะเริ่ม Hugging Face Job บนฮาร์ดแวร์ที่ตรงกัน
  4. Runner Boot & Registration: Hugging Face Job จะทำการบูท GitHub Actions Runner แบบชั่วคราว และลงทะเบียนเข้ากับ Repository โดยใช้ Token ที่ได้มา
  5. Job Execution & Reporting: GitHub จะมอบหมาย Workflow Job ที่ค้างอยู่ให้กับ Runner นี้ Runner จะดำเนินการตาม CI job, รายงานสถานะกลับไปยัง GitHub และปิดการทำงานไป

จากมุมมองของ GitHub นี่คือ Self-hosted runner ทั่วไป แต่จากมุมมองของ Hugging Face มันคือ Job ที่เปิด Container เพื่อรัน Workflow steps จาก GitHub Actions ของ Repository นั้น ๆ

ขั้นตอนการตั้งค่า: เปลี่ยน GitHub CI ให้ทำงานบน Hugging Face Jobs

ขั้นตอนที่ 1: Duplicate Dispatcher Space 🚀

สิ่งแรกที่คุณต้องมีคือ Dispatcher ซึ่งเป็น Space ขนาดเล็กที่ทำหน้าที่รับ Webhook จาก GitHub workflow\_job และเปิด Hugging Face Job เพื่อตอบสนอง

  • ไปที่ [huggingface/jobs-actions-dispatcher](ขอบคุณ แหล่งข้อมูล
    https://huggingface.co/spaces/huggingface/jobs-actions-dispatcher) และคลิก Duplicate this Space
  • ตั้งชื่อ Space ใหม่ภายใต้ Namespace ของคุณ หรือ Org ที่คุณมีสิทธิ์เขียน
  • สำคัญ: เลือกใช้ cpu-upgrade สำหรับ CI จริง เพื่อให้ Dispatcher พร้อมใช้งานเสมอสำหรับการรับ Webhook จาก GitHub หากใช้ cpu-basic อาจเกิดปัญหาหาก Webhook มาถึงขณะที่ Space กำลังตื่นจากการ Sleep
  • หลังจาก Space สร้างเสร็จ เปิดเข้าไป คุณจะเห็น URL ของ GitHub App Webhook ที่คุณต้องใช้ในขั้นตอนต่อไป

ขั้นตอนที่ 2: สร้างและติดตั้ง GitHub App 🛠️

ต่อไปคือการสร้างและติดตั้ง GitHub App จาก Dispatcher Space ที่คุณ Duplicate มา App นี้ต้องการสิทธิ์ในการรับฟัง Workflow job ที่ค้างอยู่ และสร้าง Token สำหรับลงทะเบียน Self-hosted runner

  • เปิด Dispatcher Space ที่คุณ Duplicate ไว้
  • ในหน้า Setup Form ให้กรอก GitHub Repository ที่คุณต้องการให้ CI ทำงานบน HF Jobs
  • คลิกปุ่มเพื่อสร้าง GitHub App ตั้งชื่อ App ตามต้องการ
  • GitHub จะขอให้คุณอัปโหลด Credentials ของ App ไปยัง Dispatcher Space โดยใช้ hf cli
  • ข้อควรจำ: คุณต้องมี Hugging Face Token ที่มีสิทธิ์ในการเปิด Jobs (สำหรับบัญชีส่วนตัวของคุณ หรือ Org ที่ต้องการให้เรียกเก็บค่าบริการ) Token นี้ควรถูกบันทึกเป็น Secret ชื่อ HF_TOKEN ใน Dispatcher Space ของคุณ
  • สุดท้าย ให้ติดตั้ง App นี้บน GitHub Repo เดียวกันกับที่คุณกรอกไว้ใน Space

การตั้งค่าโดย Agent: หากคุณต้องการใช้ Agent สามารถวาง $GITHUB_REPO ลงใน Space, คลิกปุ่มสร้าง GitHub App, เลือกชื่อ App และทำตามคำแนะนำบน GitHub จากนั้นติดตั้ง App บน Repo ของคุณ

ขั้นตอนที่ 3: ตั้งค่า Dispatcher สุดท้าย ⚙️

เมื่อถึงจุดนี้ Dispatcher Space ควรได้รับการตั้งค่าอย่างสมบูรณ์แล้ว Flow การตั้งค่า GitHub App จะสร้างคำสั่งสำหรับอัปโหลด Credentials, Webhook Secret และ Hugging Face Token ไปยัง Space

  • โดยปกติ HF Jobs จะถูกเปิดภายใต้ Namespace เดียวกับ Dispatcher Space
  • หากต้องการให้เรียกเก็บค่าบริการ Jobs ไปยัง User หรือ Org อื่น ให้ตั้งค่า HF_NAMESPACE เป็น Space Variable

ขั้นตอนที่ 4: แก้ไข runs-on label ✍️

การเปลี่ยนแปลง Workflow ที่แท้จริงนั้นเล็กน้อยมาก แทนที่จะใช้:

runs-on: ubuntu-latest

ให้เปลี่ยนไปใช้ Label ที่ Dispatcher จัดการอยู่:

runs-on: hf-jobs-cpu-upgrade

หรือสำหรับ GPU Tests:

runs-on: hf-jobs-t4-small 
# หรือ label GPU อื่นๆ ที่คุณต้องการ

การเปลี่ยนแปลงเพียง 1 บรรทัดนี้ ก็เพียงพอแล้วที่จะทำให้ GitHub Action ของคุณทำงานบน HF Jobs!

การเลือก Docker Image ที่เหมาะสม 🐳

การเลือก Docker Image ที่เหมาะสมมีผลอย่างมากต่อความเร็วและประสิทธิภาพ

  • สำหรับ CPU Jobs: หากคุณต้องการ Image ที่เบาและเร็ว ควรเลือก Image ที่มีเฉพาะสิ่งที่จำเป็น หรือใช้ Image ที่มีการติดตั้ง Build Dependencies มาให้แล้ว เช่น Image จาก Microsoft Playwright ซึ่งมีเครื่องมือที่จำเป็นสำหรับ UI Tests ครบครัน
  • สำหรับ GPU Jobs: ใช้ Image ที่รองรับ CUDA เช่น nvidia/cuda:11.8.0-base-ubuntu22.04

ผลลัพธ์ที่ได้จากการใช้งานจริง 📊

จากการทดสอบกับ Trackio พบว่า:

  • GPU CI: การทดสอบ GPU ใช้เวลาเพียง 45 วินาที และมีค่าใช้จ่ายน้อยมาก (น้อยกว่า 1 เซ็นต์ ที่อัตรา t4-small)
  • CPU CI: งาน Linux Test Job เร็วกว่า Baseline บน GitHub-hosted อย่างเห็นได้ชัด แสดงให้เห็นว่า HF Jobs เป็น Backend CI ที่มีประสิทธิภาพ โดยเฉพาะสำหรับโปรเจกต์ ML ที่ต้องการ Custom Images หรือ Accelerators

Logs: การเข้าถึง Logs บน Hugging Face Jobs ทำได้ง่ายผ่าน CLI ซึ่งสะดวกสำหรับการนำไปใช้กับเครื่องมือ Local หรือ AI Agents นอกจากนี้ ในส่วนของ Bridge ยังมีการ Mirror Log ของ GitHub Actions เข้าไปใน HF Job log ด้วย ทำให้มีข้อมูลครบถ้วนสำหรับการ Debug

Volumes: แม้ Trackio จะไม่ได้ใช้ แต่ HF Jobs รองรับการ Mount Volumes ซึ่งมีประโยชน์มากหากต้องการโหลด Datasets หรือ Models จาก Hugging Face อย่างรวดเร็วในระหว่าง CI

หวังว่าคู่มือนี้จะช่วยให้คุณสามารถนำ Hugging Face Jobs ไปใช้กับ GitHub Actions ของคุณได้อย่างมีประสิทธิภาพ!

#HuggingFace #GitHubActions #CI #OpenSource #MachineLearning

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/github-ci-hf-jobs

เปลี่ยน GitHub CI ของคุณให้ทำงานบน Hugging Face Jobs: คู่มือฉบับสมบูรณ์การจัดการระบบ Continuous Integration (CI) สำหรับโปรเจกต์ Open Source โดยเฉพาะโปรเจกต์ Machine Learning นั้นมีความท้าทายหลายประการ GitHub Actions ซึ่งเป็นเครื่องมือยอดนิยมอาจมีข้อจำกัดในเรื่องความเร็ว การบำรุงรักษา หรือการเข้าถึงฮาร์ดแวร์พิเศษอย่าง GPU ทำให้โปรเจกต์อย่าง Trackio ต้องมองหาโซลูชันที่ดีกว่าในบทความนี้ เราจะมาดูกันว่าคุณจะสามารถย้ายระบบ CI จาก GitHub Actions มาทำงานบน Hugging Face Jobs ได้อย่างไร เพื่อให้ได้ทั้งความเสถียร ประสิทธิภาพที่เพิ่มขึ้น และการเข้าถึงฮาร์ดแวร์ที่หลากหลาย โดยเฉพาะอย่างยิ่ง GPU ซึ่งจำเป็นสำหรับการทดสอบ ML บางประเภทHugging Face Jobs คืออะไร?Hugging Face Jobs คือบริการโครงสร้างพื้นฐานแบบ Serverless ที่ให้คุณรันคำสั่งหรือสคริปต์บนฮาร์ดแวร์ที่หลากหลายของ Hugging Face ได้อย่างง่ายดาย หัวใจหลักของ Job ประกอบด้วย:Docker image: สามารถเลือกใช้จาก Docker Hub หรือ Hugging Face Space ที่มีอยู่Hardware flavor: เลือกประเภทฮาร์ดแวร์ที่ต้องการ เช่น CPU, t4-small หรือ GPU h200Optional environment variables and secrets: ตั้งค่าตัวแปรสภาพแวดล้อมหรือข้อมูลลับเพิ่มเติมได้ด้วยคุณสมบัติเหล่านี้ Hugging Face Jobs จึงเป็นโซลูชันที่เหมาะอย่างยิ่งสำหรับงาน CI เพราะงาน CI โดยทั่วไปมักเป็นการสั่งงานแบบ Command-driven ทำงานในสภาพแวดล้อมที่สะอาด และสามารถเลือกฮาร์ดแวร์ที่เหมาะสมกับงานได้พอดี สำหรับไลบรารี ML การใช้งาน GPU เป็นจุดเด่นที่น่าสนใจมาก เพราะช่วยให้คุณสามารถรันชุดทดสอบบนฮาร์ดแวร์ GPU จริงได้ โดยไม่ต้องดูแลรักษาระบบ Runner ของตัวเองให้พร้อมใช้งานตลอดเวลาภาพรวมการทำงานร่วมกันหัวใจสำคัญคือการเชื่อมต่อ GitHub Actions เข้ากับ Hugging Face Jobs โดยใช้ huggingface/jobs-actions ซึ่งเป็นส่วนเสริมขนาดเล็กที่ทำหน้าที่แปลง GitHub Actions job ให้กลายเป็น Self-hosted runner แบบชั่วคราวที่ทำงานภายใน Hugging Face Jobกระบวนการทำงานจะเป็นดังนี้:Pull Request Trigger: เมื่อมีการเปิด Pull Request ระบบ GitHub Actions จะเริ่มทำงานJob Queuing: GitHub จะจัดคิวงานที่ระบุ runs-on label ที่ไม่พร้อมใช้งาน เช่น hf-jobs-cpu-upgrade หรือ hf-jobs-t4-small และส่ง Webhook workflow_job.queued ไปยัง Dispatcher ผ่าน GitHub AppDispatcher Verification & Job Launch: Dispatcher Space จะทำการยืนยัน Webhook ตรวจสอบ Label hf-jobs-* และสร้าง GitHub Runner Registration Token ที่มีอายุสั้น จากนั้นจะเริ่ม Hugging Face Job บนฮาร์ดแวร์ที่ตรงกันRunner Boot & Registration: Hugging Face Job จะทำการบูท GitHub Actions Runner แบบชั่วคราว และลงทะเบียนเข้ากับ Repository โดยใช้ Token ที่ได้มาJob Execution & Reporting: GitHub จะมอบหมาย Workflow Job ที่ค้างอยู่ให้กับ Runner นี้ Runner จะดำเนินการตาม CI job, รายงานสถานะกลับไปยัง GitHub และปิดการทำงานไปจากมุมมองของ GitHub นี่คือ Self-hosted runner ทั่วไป แต่จากมุมมองของ Hugging Face มันคือ Job ที่เปิด Container เพื่อรัน Workflow steps จาก GitHub Actions ของ Repository นั้น ๆขั้นตอนการตั้งค่า: เปลี่ยน GitHub CI ให้ทำงานบน Hugging Face Jobsขั้นตอนที่ 1: Duplicate Dispatcher Space 🚀สิ่งแรกที่คุณต้องมีคือ Dispatcher ซึ่งเป็น Space ขนาดเล็กที่ทำหน้าที่รับ Webhook จาก GitHub workflow\_job และเปิด Hugging Face Job เพื่อตอบสนองไปที่ [huggingface/jobs-actions-dispatcher](https://huggingface.co/spaces/huggingface/jobs-actions-dispatcher) และคลิก Duplicate this Spaceตั้งชื่อ Space ใหม่ภายใต้ Namespace ของคุณ หรือ Org ที่คุณมีสิทธิ์เขียนสำคัญ: เลือกใช้ cpu-upgrade สำหรับ CI จริง เพื่อให้ Dispatcher พร้อมใช้งานเสมอสำหรับการรับ Webhook จาก GitHub หากใช้ cpu-basic อาจเกิดปัญหาหาก Webhook มาถึงขณะที่ Space กำลังตื่นจากการ Sleepหลังจาก Space สร้างเสร็จ เปิดเข้าไป คุณจะเห็น URL ของ GitHub App Webhook ที่คุณต้องใช้ในขั้นตอนต่อไปขั้นตอนที่ 2: สร้างและติดตั้ง GitHub App 🛠️ต่อไปคือการสร้างและติดตั้ง GitHub App จาก Dispatcher Space ที่คุณ Duplicate มา App นี้ต้องการสิทธิ์ในการรับฟัง Workflow job ที่ค้างอยู่ และสร้าง Token สำหรับลงทะเบียน Self-hosted runnerเปิด Dispatcher Space ที่คุณ Duplicate ไว้ในหน้า Setup Form ให้กรอก GitHub Repository ที่คุณต้องการให้ CI ทำงานบน HF Jobsคลิกปุ่มเพื่อสร้าง GitHub App ตั้งชื่อ App ตามต้องการGitHub จะขอให้คุณอัปโหลด Credentials ของ App ไปยัง Dispatcher Space โดยใช้ hf cliข้อควรจำ: คุณต้องมี Hugging Face Token ที่มีสิทธิ์ในการเปิด Jobs (สำหรับบัญชีส่วนตัวของคุณ หรือ Org ที่ต้องการให้เรียกเก็บค่าบริการ) Token นี้ควรถูกบันทึกเป็น Secret ชื่อ HF_TOKEN ใน Dispatcher Space ของคุณสุดท้าย ให้ติดตั้ง App นี้บน GitHub Repo เดียวกันกับที่คุณกรอกไว้ใน Spaceการตั้งค่าโดย Agent: หากคุณต้องการใช้ Agent สามารถวาง $GITHUB_REPO ลงใน Space, คลิกปุ่มสร้าง GitHub App, เลือกชื่อ App และทำตามคำแนะนำบน GitHub จากนั้นติดตั้ง App บน Repo ของคุณขั้นตอนที่ 3: ตั้งค่า Dispatcher สุดท้าย ⚙️เมื่อถึงจุดนี้ Dispatcher Space ควรได้รับการตั้งค่าอย่างสมบูรณ์แล้ว Flow การตั้งค่า GitHub App จะสร้างคำสั่งสำหรับอัปโหลด Credentials, Webhook Secret และ Hugging Face Token ไปยัง Spaceโดยปกติ HF Jobs จะถูกเปิดภายใต้ Namespace เดียวกับ Dispatcher Spaceหากต้องการให้เรียกเก็บค่าบริการ Jobs ไปยัง User หรือ Org อื่น ให้ตั้งค่า HF_NAMESPACE เป็น Space Variableขั้นตอนที่ 4: แก้ไข runs-on label ✍️การเปลี่ยนแปลง Workflow ที่แท้จริงนั้นเล็กน้อยมาก แทนที่จะใช้:runs-on: ubuntu-latestให้เปลี่ยนไปใช้ Label ที่ Dispatcher จัดการอยู่:runs-on: hf-jobs-cpu-upgradeหรือสำหรับ GPU Tests:runs-on: hf-jobs-t4-small # หรือ label GPU อื่นๆ ที่คุณต้องการการเปลี่ยนแปลงเพียง 1 บรรทัดนี้ ก็เพียงพอแล้วที่จะทำให้ GitHub Action ของคุณทำงานบน HF Jobs!การเลือก Docker Image ที่เหมาะสม 🐳การเลือก Docker Image ที่เหมาะสมมีผลอย่างมากต่อความเร็วและประสิทธิภาพสำหรับ CPU Jobs: หากคุณต้องการ Image ที่เบาและเร็ว ควรเลือก Image ที่มีเฉพาะสิ่งที่จำเป็น หรือใช้ Image ที่มีการติดตั้ง Build Dependencies มาให้แล้ว เช่น Image จาก Microsoft Playwright ซึ่งมีเครื่องมือที่จำเป็นสำหรับ UI Tests ครบครันสำหรับ GPU Jobs: ใช้ Image ที่รองรับ CUDA เช่น nvidia/cuda:11.8.0-base-ubuntu22.04ผลลัพธ์ที่ได้จากการใช้งานจริง 📊จากการทดสอบกับ Trackio พบว่า:GPU CI: การทดสอบ GPU ใช้เวลาเพียง 45 วินาที และมีค่าใช้จ่ายน้อยมาก (น้อยกว่า 1 เซ็นต์ ที่อัตรา t4-small)CPU CI: งาน Linux Test Job เร็วกว่า Baseline บน GitHub-hosted อย่างเห็นได้ชัด แสดงให้เห็นว่า HF Jobs เป็น Backend CI ที่มีประสิทธิภาพ โดยเฉพาะสำหรับโปรเจกต์ ML ที่ต้องการ Custom Images หรือ AcceleratorsLogs: การเข้าถึง Logs บน Hugging Face Jobs ทำได้ง่ายผ่าน CLI ซึ่งสะดวกสำหรับการนำไปใช้กับเครื่องมือ Local หรือ AI Agents นอกจากนี้ ในส่วนของ Bridge ยังมีการ Mirror Log ของ GitHub Actions เข้าไปใน HF Job log ด้วย ทำให้มีข้อมูลครบถ้วนสำหรับการ DebugVolumes: แม้ Trackio จะไม่ได้ใช้ แต่ HF Jobs รองรับการ Mount Volumes ซึ่งมีประโยชน์มากหากต้องการโหลด Datasets หรือ Models จาก Hugging Face อย่างรวดเร็วในระหว่าง CIหวังว่าคู่มือนี้จะช่วยให้คุณสามารถนำ Hugging Face Jobs ไปใช้กับ GitHub Actions ของคุณได้อย่างมีประสิทธิภาพ!#HuggingFace #GitHubActions #CI #OpenSource #MachineLearninghttps://huggingface.co/blog/github-ci-hf-jobs
Shared content
HUGGINGFACE.CO
Migrating Your GitHub CI to Hugging Face Jobs
We’re on a journey to advance and democratize artificial intelligence through open source and open science.
3 Comments 0 Shares 311 Views 0 Reviews