AI แบบเอเจนต์จะชนกำแพงด้านโครงสร้างพื้นฐานก่อนกำแพงด้านความฉลาด

โมเดลพัฒนาเร็วกว่าเราจะรองรับสิ่งที่ผู้คนต้องการให้มันทำได้

ข้อถกเถียงส่วนใหญ่เกี่ยวกับทิศทางของเอเจนต์ AI ว่าด้วยความสามารถของมัน โมเดลวางแผนได้อย่างน่าเชื่อถือหรือไม่? มันแก้ไขข้อผิดพลาดของตัวเองได้หรือไม่? เราไว้วางใจให้มันลงมือทำสิ่งที่อาจส่งผลตามมาได้หรือไม่?

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

แชตบอตกับเอเจนต์เป็นเวิร์กโหลดคนละแบบ

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

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

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

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

ช่วงเวลารอนี่แหละที่มีต้นทุนสูง

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

ฮาร์ดแวร์ที่มีราคาแพงที่สุดของคุณถูกสำรองไว้ให้คำขอที่กำลังรอผลการค้นฐานข้อมูลอยู่ในขณะนั้น

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

การทำงานตามลำดับทำให้ปัญหาแย่กว่าที่ควรจะเป็น

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

บ่อยครั้งที่การเรียกใช้ทั้งสามครั้งนี้ไม่ขึ้นต่อกันเลย จึงสามารถทำพร้อมกันได้ หากทำทีละอย่าง เวลาแฝงจะเท่ากับผลรวมของแต่ละงาน แต่หากทำพร้อมกัน เวลาแฝงจะเท่ากับเวลาของงานที่ใช้เวลานานที่สุด

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

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

การลองซ้ำทบซ้อนกันโดยไม่มีใครออกแบบไว้

เฟรมเวิร์กเอเจนต์รับค่าการลองซ้ำเริ่มต้นมาจากไลบรารี HTTP ที่อยู่เบื้องหลัง โดยปกติตั้งไว้ 3 ครั้ง

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

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

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

กำแพงนี้มีหน้าตาอย่างไร

ไม่ใช่เพดานด้านความสามารถ แต่เป็นปัญหาที่ธรรมดากว่านั้น นั่นคือปัญหาเศรษฐศาสตร์ต่อหน่วยที่ทำให้โครงการไปต่อไม่ได้เมื่อเปลี่ยนจากโครงการนำร่องสู่การใช้งานจริง

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

นี่คือจุดที่การสาธิตภายในองค์กรซึ่งมีแนวโน้มดีจำนวนมากค่อย ๆ ยุติลงโดยไม่มีใครพูดถึง

อะไรช่วยขยับกำแพงนี้ได้

ไม่มีอะไรซับซ้อนแปลกใหม่ ทั้งหมดเป็นเรื่องโครงสร้างพื้นฐาน ไม่ใช่การสร้างแบบจำลอง:

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

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

จัดสรรงบประมาณการลองใหม่ให้ครอบคลุมทั้งระบบ แทนที่จะแยกตามการเรียกใช้แต่ละครั้ง การกำหนดเพดานรวม โดยจำกัดการลองใหม่ให้เป็นสัดส่วนเล็กน้อยของปริมาณการรับส่งข้อมูลทั้งหมด จะช่วยป้องกันการทบต้นดังที่อธิบายไว้ข้างต้น แนวปฏิบัติ SRE ของ Google ในเรื่องการจัดการภาวะโหลดเกินและงบประมาณการลองใหม่ของ Envoy ต่างก็นำแนวคิดนี้ไปใช้ภายนอกสแตก AI

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

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

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

ผมเผยแพร่แบบจำลองการประมวลผลที่รองรับประเด็นสุดท้ายนี้ ซึ่งคือการประมวลผลการเรียกใช้โมเดลที่ขึ้นต่อกันพร้อมกันภายใต้งบเวลาแฝงเดียวกัน ไว้ในบทความเรื่อง “การประมวลผลกราฟการอนุมานแบบอะซิงโครนัสสำหรับการกำหนดเส้นทางโมเดลในระบบแมชชีนเลิร์นนิง”, International Journal of Computer Trends and Technology 72(10), ตุลาคม 2024 สำหรับเรื่องการผสานโมเดลเชิงกำเนิดเข้ากับระบบการตัดสินใจที่มีข้อจำกัดด้านเวลาแฝงโดยเฉพาะ โปรดดู “แพลตฟอร์มการซื้อขายและการตัดสินใจที่เสริมด้วย LLM: เชื่อมโยงปัญญาเชิงกำเนิดเข้ากับระบบการตัดสินใจทางการเงิน”, Journal of Information Systems Engineering and Management 11(1s), 2026