Reason Machines เปิดซอร์ส Aspen เซิร์ฟเวอร์ Git ความเร็วสูงสำหรับ AI Agent

Reason Machines ได้ปล่อย Aspen ซึ่งเป็น open-source Git server สำหรับรองรับทราฟฟิกของ AI agent โดยเฉพาะ โดยมีเป้าหมายเพื่อรองรับ repository ที่มีเอเจนต์หลายร้อยตัวทำการ push ข้อมูลพร้อมกัน ทั้งนี้ Aspen ได้นำแนวคิดการออกแบบ Pando ที่ OpenAI เคยอธิบายไว้มาปรับใช้พัฒนาขึ้นใหม่โดยอิสระ

TL;DR

ขนาด: เป็น binary ของ Rust เพียงตัวเดียว โดยเก็บ Branch ไว้ใน PostgreSQL (หรือ SQLite) และเก็บ pack ไว้ใน object storage
รันบน: ใช้งานได้ทั้งบนแล็ปท็อป (aspen dev), โฮสต์เดียวผ่าน Docker Compose หรือผ่าน Helm และ Terraform บนระบบคลาวด์
ประสิทธิภาพ: การ push ไปยังแต่ละ branch ทำงานแยกจากกันโดยไม่ต้องรอคิว และการ fetch จะนำ pack ที่เก็บไว้มาใช้ซ้ำได้ทันที
ดีที่สุด: รองรับการ push ได้สูงถึง 567 ครั้งต่อวินาทีต่อเนื่องนาน 5 นาทีบนเซิร์ฟเวอร์ 8-core เครื่องเดียว (อ้างอิงจากรายงานของบริษัท)
แย่ที่สุด: การ push ลง branch main ทำได้ประมาณ 4 ครั้งต่อวินาที และปัจจุบันโปรเจกต์ยังอยู่ในช่วง pre-alpha
สรุปภาพรวม: ข้อดีคือการเขียนแยกราย branch ช่วยทลายขีดจำกัดสูงสุดของการ push ต่อหนึ่ง repository แต่ข้อเสียคือยังไม่มีการออกเวอร์ชันทางการ (releases) ไม่มีหน้า web UI และยังไม่ผ่านเกณฑ์ทดสอบความคงทนของข้อมูลแบบ 24 ชั่วโมง

Aspen คืออะไร?

Aspen เป็นเซิร์ฟเวอร์ Git แบบ self-hostable จาก Reason Machines ที่ขยายขีดความสามารถในการเขียนตามราย branch แทนที่จะเป็นราย repository โดยสื่อสารผ่านโปรโตคอล Git ปกติบน HTTPS และ SSH สำหรับข้อมูล pack จะถูกส่งไปยัง object storage ที่รองรับ S3 ส่วนประวัติของ branch จะถูกจัดเก็บไว้ใน PostgreSQL

ทำไมเซิร์ฟเวอร์ Git แบบดั้งเดิมถึงมีปัญหากับ AI agents? เนื่องจากเอเจนต์มักจะทำการ push ทุกๆ ไม่กี่นาที และระบบ CI จะทำการ fetch ข้อมูลหลังการ push ทุกครั้ง ข้อมูลจาก Reason Machines ระบุว่าเซิร์ฟเวอร์แบบดั้งเดิมจะจัดคิวการ push ทุกรายการเข้าสู่ repository เดียวกัน นอกจากนี้ยังต้องสร้าง pack ใหม่สำหรับการ fetch ทุกครั้ง ทำให้ภาระงานของเซิร์ฟเวอร์เติบโตตามจำนวนไคลเอนต์ ไม่ใช่ตามปริมาณโค้ดที่เพิ่มขึ้น

OpenAI ประสบปัญหานี้ มาก่อนจึงได้สร้าง Pando ขึ้นมา ซึ่งช่วยลดค่าความหน่วง (latency) ของการ push ในระดับมัธยฐานลงเกือบ 5 เท่า และสามารถให้บริการข้อมูลได้เกือบหนึ่ง petabyte ต่อวัน

Aspen ทำงานอย่างไร?

Aspen ดำเนินตามแนวทางของ Pando โดยยอมสละข้อกำหนด 2 ประการที่เซิร์ฟเวอร์ Git ส่วนใหญ่ยังคงไว้ ดังนี้

การเปรียบเทียบและสลับ (compare-and-swap) ราย branch

แต่ละ branch จะถูกเก็บเป็นสายโซ่ของเวอร์ชันในแถวข้อมูลของ Postgres การ push หนึ่งครั้งจะทำการอัปโหลด pack และเคลื่อนย้ายตำแหน่ง branch ด้วยวิธี compare-and-swap เพียงครั้งเดียว ส่งผลให้การ push ไปยัง branch ต่างๆ ไม่ต้องรอกัน หากมีการ push แข่งกันใน branch เดียวกัน ตัวที่มาทีหลังจะได้รับข้อผิดพลาด "fetch first" ตามปกติของ Git แลกกับการที่แต่ละ branch อาจถูกอ่านในจังหวะที่ต่างกันเล็กน้อย

ใช้ pack ที่เก็บไว้แทนการสร้าง pack รายไคลเอนต์

Aspen จะไม่ทำการแตกไฟล์ (unpack) ข้อมูลที่ push เข้ามา แต่จะตรวจสอบและเก็บ pack นั้นไว้ใน object storage ทันที เมื่อมีการ fetch ระบบจะสตรีม pack ที่เก็บไว้ซึ่งไคลเอนต์ยังไม่มีให้โดยตรงโดยไม่บีบอัดข้อมูลใหม่ ซึ่งสามารถใช้ Signed URLs เพื่อเสิร์ฟ pack ผ่าน CDN ได้อีกด้วย

การโฆษณาเฉพาะสายหลัก (Trunk-only advertisement) และการบีบอัดข้อมูล

การ push จะมองเห็นเฉพาะ branch หลัก (trunk) เท่านั้น ทำให้ขั้นตอนการเจรจาข้อมูล (negotiation) มีขนาดเล็กแม้จะมีเป็นล้าน branch ก็ตาม นอกจากนี้ยังมีการบีบอัดข้อมูลเบื้องหลัง (background compaction) เพื่อรวม pack เข้าด้วยกันตามระดับชั้นคล้ายกับ log-structured merge tree ช่วยให้ไคลเอนต์ที่ล้าหลังได้รับ pack เพียงไม่กี่ชุดแทนที่จะเป็นพันชุด ส่วนการ fetch ของ CI แบบ depth-1 จะได้รับข้อมูลจาก tip pack ที่สร้างไว้ล่วงหน้าซึ่งเสิร์ฟให้กับทุกงานได้ทันที

Aspen เร็วแค่ไหน?

จากการทดสอบด้วยเซิร์ฟเวอร์ 8-core, S3 Standard และ Postgres แบบ 4-core โดยใช้ข้อมูลจาก git.git ที่มีไฟล์ราว 4,500 ไฟล์และ 75,000 commit พบว่า Aspen รองรับการ push 567 ครั้งต่อวินาทีอย่างต่อเนื่อง นาน 5 นาทีโดยไม่มีข้อผิดพลาด ข้อมูลจะถูกส่งถึง S3 และ Postgres ก่อนที่ Git จะตอบกลับว่า “ok”

ค่ามัธยฐานความหน่วงการ push: 208 ms และเปอร์เซ็นไทล์ที่ 99 อยู่ที่ 314 ms
ไคลเอนต์ตัวอื่นสามารถมองเห็นการ push ได้ภายใน 30 ms (ค่ามัธยฐาน) หลังจากได้รับการตอบรับ
การทำ Depth-1 fetch storm ใช้ข้อมูลเพียง 1.029 เท่าของไบต์ เมื่อเทียบกับมาตรฐาน git upload-pack บน git.git

ขณะที่ Cursor รายงาน การ push สูงสุดที่ 120 ครั้งต่อวินาทีสำหรับ Origin บน S3 Standard และมากกว่า 300 ครั้งเมื่อใช้ S3 Express One Zone อย่างไรก็ตาม นั่นเป็นการทดสอบบนคลัสเตอร์ monorepo ของ Cursor ซึ่งมีโครงสร้างต่างกัน โดย README ของ Aspen ระบุว่าตัวเลขนี้เป็นเพียงตัวบ่งชี้ประสิทธิภาพ ไม่ใช่การยืนยันขีดจำกัดสูงสุด

Aspen เปรียบเทียบกับ Git backend ระดับเอเจนต์ตัวอื่นอย่างไร?

คุณสมบัติ	Aspen	Cursor Origin	OpenAI Pando	GitHub Spokes
ความพร้อมใช้งาน	Open source, self-hosted	แพลตฟอร์มเชิงพาณิชย์ของ Cursor	ใช้ภายใน OpenAI	ใช้ภายใน GitHub
สัญญาอนุญาต	Apache 2.0	ไม่เปิดเผย	ไม่เปิดเผย	ไม่เปิดเผย
ลำดับการ Push	ราย branch (compare-and-swap)	ราย repository (write-ahead log ใน S3)	ราย branch	Three-phase commit ข้าม replica
การเก็บ Ref	PostgreSQL หรือ SQLite	WAL index ใน S3, ไม่มี relational DB	Metadata store	Git repos บน NVMe
การให้บริการ Fetch	Stored packs, เย็บรวมหรือผ่าน URIs	Local Git repo cache บน NVMe	ใช้ stored packs ซ้ำ	Git repo replicas
อัตรา Push ที่เผยแพร่	567/s, S3 Standard, 1 เซิร์ฟเวอร์ (รายงานเอง)	120/s S3 Standard; 300+/s S3 Express	ไม่เปิดเผย	ไม่เปิดเผย
ผลลัพธ์อื่นที่เผยแพร่	p99 push 314 ms	การขยายการอ่านแบบ linear ถึง 100 replicas	ลดมัธยฐานความหน่วงการ push เกือบ 5 เท่า	ไม่เปิดเผย

คุณจะติดตั้งใช้งาน Aspen ได้อย่างไร?

ผู้ใช้ต้องบิลด์จาก source ด้วยภาษา Rust โดยคำสั่ง aspen dev จะรันระบบผ่าน SQLite และไดเรกทอรีในเครื่อง สำหรับระดับทีมงานจะมี Docker Compose พร้อม PostgreSQL และ MinIO รวมถึง Helm chart ให้ใช้งาน ส่วน Terraform จะรองรับครอบคลุมทั้ง AWS, Google Cloud, Azure และ Hetzner นอกจากนี้ยังมีโหมด Mirror ที่สามารถวางไว้หน้า GitHub หรือ GitLab เพื่อทดลองใช้งานได้โดยไม่ต้องย้ายข้อมูลเดิม

เดโมสด แสดงให้เห็นผืนผ้าใบขนาด 64 x 64 พิกเซล ซึ่งการคลิกแต่ละครั้งคือการ push หนึ่ง commit ตามข้อมูลจากบริษัทระบุว่า เอเจนต์ของ Reason ตัวหนึ่งสามารถสร้าง Aspen ขึ้นมาจาก commit แรกจนถึงเวอร์ชันสาธารณะได้ภายใน 4 วัน โดยใช้ PR ที่ถูก merge ไปทั้งหมด 151 รายการ

ประเด็นสำคัญ

Aspen เป็นเซิร์ฟเวอร์ Git ภายใต้สัญญาอนุญาต Apache 2.0 ที่ออกแบบมาเพื่อทราฟฟิกการ push ระดับเอเจนต์
เป็นการนำโครงสร้าง Pando ของ OpenAI มาพัฒนาใหม่แบบเปิดเผยและเป็นอิสระ
ผลทดสอบระบุว่าสามารถ push ได้ 567 ครั้งต่อวินาทีบนเซิร์ฟเวอร์ 8-core เครื่องเดียว โดยมีค่า p99 อยู่ที่ 314 ms
ฝั่งไคลเอนต์ไม่จำเป็นต้องปรับเปลี่ยนค่าใดๆ โดยสามารถใช้ git มาตรฐานผ่าน HTTPS และ SSH ได้ทันที