สร้างเพื่อ Scale
EDDI ทำงานบน Java 25 กับ Quarkus ใช้ Virtual Threads สำหรับ massive I/O-bound concurrency
ทำไม Virtual Threads จึงสำคัญสำหรับ AI Agents
เอเจนต์ AI สมัยใหม่นั้นมีพื้นฐานคือ I/O-bound
Java Virtual Threads แก้ปัญหานี้ได้อย่างงดงาม
จุดเด่นด้านประสิทธิภาพ
- Virtual Threads ล้านๆ lightweight threads
- Quarkus Runtime Java แบบ cloud-native พร้อม hot reload ในโหมด dev ปรับแต่งสำหรับคอนเทนเนอร์ ให้ throughput สูงกว่าและเริ่มต้นเร็วกว่าสแต็ก JVM รุ่นเก่าอย่างชัดเจน พร้อมใช้หน่วยความจำน้อยกว่า
- Connection Pool ที่รองรับ Loom Agroal connection pooling หลีกเลี่ยงปัญหา ThreadLocal bottleneck ที่อาจส่งผลต่อ pool แบบดั้งเดิมภายใต้โหลด virtual thread
- NATS JetStream horizontal scaling
- Dual Database MongoDB หรือ PostgreSQL สลับด้วย environment variable เดียว Docker image เดียวรองรับทั้งสอง
- SSE Streaming การตอบแชทแบบเรียลไทม์, ฟีดการสนทนากลุ่ม และการสตรีมล็อกสดผ่าน Server-Sent Events พร้อมเอาต์พุตทีละโทเค็นแม้ขณะที่เครื่องมือกำลังทำงาน
- One-Command Install ตัวช่วยแบบโต้ตอบที่ deploy EDDI + ฐานข้อมูลผ่าน Docker Compose และสร้างคีย์ vault
- Red Hat Certified อิมเมจ UBI 10 เผยแพร่ในแคตตาล็อกที่ได้รับการรับรองของ Red Hat พร้อมการตรวจสอบ preflight อัตโนมัติใน CI/CD
ประสิทธิภาพในบริบท
ไม่มี runtime ใดชนะในทุกสถานการณ์ Node.js อาจทำได้ดีกว่า Java ในสถานการณ์ routing แบบ pure-I/O ที่เฉพาะเจาะจงมาก ขณะที่ Java นำหน้าอย่างสม่ำเสมอในเวิร์กโหลดที่มีงานใช้ CPU หนัก ซึ่งเป็นสิ่งที่ AI agents ต้องการอย่างแท้จริง เอเจนต์สมัยใหม่ทำงานแบบผสมผสานระหว่าง I/O ปริมาณมหาศาล (การเรียก LLM API, การคิวรีเวกเตอร์) กับการประมวลผลเข้มข้น (การแปลงข้อมูล, ลอจิกการเราท์, การประมวลผล embedding, การประเมินความเชื่อมั่น) โปรไฟล์เวิร์กโหลดแบบผสมนี้คือจุดที่ virtual threads บน Quarkus ให้ข้อได้เปรียบสูงสุด
สถาปัตยกรรมของ EDDI ได้รับการปรับแต่งโดยเจตนาสำหรับความเป็นจริงนี้: Quarkus กับ virtual threads สำหรับเลเยอร์การจัดการเอเจนต์ที่หนัก I/O รวมกับ connection pools ที่เข้ากันกับ Loom (Agroal) ซึ่งหลีกเลี่ยงปัญหาการแย่งชิง ThreadLocal ที่พบในไลบรารี pooling แบบดั้งเดิมภายใต้ virtual thread concurrency สูง