GitHub ทดสอบเอเจนต์ AI 5,000 ตัวในรีโพซิทอรีเดียว พุช 7,200 ครั้ง/วินาที

GitHub ประมวลผลการพุชได้ 7,200 ครั้งต่อวินาทีในการทดสอบภายในที่มีเอเจนต์ AI 5,000 ตัวทำงานพร้อมกันในรีโพซิทอรีเดียว พร้อมรองรับคำขออ่านด้วยความหน่วงต่ำ การพุชคือการส่งโค้ดที่แก้ไขแล้วไปยังรีโพซิทอรีระยะไกล

วันที่ 5 GitHub เปิดเผยในบล็อกเทคนิคอย่างเป็นทางการว่าโครงสร้างจัดเก็บ Git แบบใหม่มีชื่อว่า ‘Rubicon’ งานออกแบบเริ่มขึ้นหลังการย้ายไป Azure ในระยะแรกเมื่อเดือนพฤษภาคม 2026

ตัวอย่างที่ GitHub ยกมาระบุว่า รีโพซิทอรีแห่งหนึ่งมีคำขอเฉลี่ยต่อวันเพิ่มจาก 44 ล้านครั้งในเดือนมีนาคม 2026 เป็น 181 ล้านครั้งในเดือนพฤษภาคม หรือเพิ่มขึ้นราว 4 เท่า

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

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

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

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

Rubicon แยกการจัดการข้อมูลโค้ดออกจากข้อมูลสาขา โดยจัดเก็บชุดข้อมูลโค้ดไว้ใน Azure Blob Storage ส่วน Ref-CAS ซึ่งเป็นบริการแยกต่างหาก จะดูแลข้อมูลสาขาและรายการชุดข้อมูลที่จัดเก็บไว้

Ref-CAS ตรวจสอบและอัปเดตเฉพาะสาขาที่แต่ละงานต้องการเปลี่ยน การเปลี่ยนแปลงคนละสาขาทำพร้อมกันได้ แต่หากสองงานพยายามแก้สาขาเดียวกัน ระบบต้องจัดการความขัดแย้ง

เมื่อมีการพุชโค้ด virtual replica จะประมวลผลชุดข้อมูลใหม่และอัปโหลดไปยัง Blob Storage ก่อน จากนั้นจึงบันทึกธุรกรรมใน Ref-CAS เพื่ออัปเดตรายการชุดข้อมูลและข้อมูลสาขาพร้อมกัน

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

virtual replica สำหรับงานอ่านและเขียนใช้แคชที่สร้างใหม่ได้ เมื่อมีคำขอจำนวนมาก GitHub ออกแบบให้เพิ่มจำนวน virtual replica เพื่อรองรับภาระงานได้

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

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

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