การออกแบบงบประมาณความหน่วงสำหรับ AI Agent — วิธีควบคุมการแลกเปลี่ยนระหว่างเวลาคิดและเวลาตอบสนอง

งบประมาณความหน่วง (Latency Budget) คือวิธีการออกแบบและจัดสรรขีดจำกัดสูงสุดของเวลาในการตอบสนองที่ AI Agent สามารถยอมรับได้ในการทำงานหนึ่งงาน สำหรับ Agent ที่ต้องใช้การอนุมานหลายขั้นตอน (Multi-step reasoning) ยิ่งมีการเรียกใช้ LLM (Large Language Model) มากเท่าใด ความล่าช้าก็จะยิ่งสะสมมากขึ้นเท่านั้น หากไม่สามารถรักษาสมดุลระหว่างเวลาในการคิดและเวลาในการตอบสนองขั้นสุดท้ายได้ อาจนำไปสู่ประสบการณ์ผู้ใช้ที่แย่ลงหรือความล้มเหลวของระบบ

ในบทความนี้ เราจะอธิบายเนื้อหาต่อไปนี้อย่างเป็นระบบ โดยมุ่งเป้าไปที่วิศวกรและหัวหน้าฝ่ายเทคนิคที่รับผิดชอบด้านการออกแบบ Agent:

เมื่อถูกบอกว่า "การตอบสนองช้า" สาเหตุนั้นอยู่ที่ไหน หากเป็นแชทบอททั่วไป การสงสัยความเร็วในการประมวลผล (Inference speed) ของโมเดลก็มักจะเพียงพอแล้ว แต่สำหรับ AI Agent เรื่องไม่ได้ง่ายเช่นนั้น

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

การออกแบบ Latency Budget หมายถึงการทำความเข้าใจโครงสร้างที่ซ้อนทับกันนี้ และตัดสินใจอย่างตั้งใจว่าจะจัดสรรเวลาให้แต่ละส่วนเท่าใด หากพยายามปรับแต่งโดยบอกว่า "ทำให้เร็วขึ้นทั้งระบบ" โดยละเลยโครงสร้างไป มักจะจบลงเพียงแค่การย้ายคอขวด (Bottleneck) ไปยังจุดอื่นเท่านั้น จุดเริ่มต้นของการออกแบบจึงอยู่ที่การแยกย่อยดูว่า Agent ของคุณมีโครงสร้างความล่าช้าเป็นอย่างไรก่อนเป็นอันดับแรก

สำหรับการเรียกใช้งาน LLM แบบเดี่ยว (Single LLM call) ปัจจัยหลักที่ส่งผลต่อความหน่วง (Latency) จะมีอยู่ 2 ประการ ได้แก่ Time to First Token (TTFT) และจำนวนโทเค็นขาออก หากทราบเวลาตั้งแต่ส่งคำขอจนถึงโทเค็นแรกปรากฏ และความเร็วในการสร้างโทเค็นหลังจากนั้น (TPOT) ก็จะสามารถเข้าใจภาพรวมของความหน่วงได้เกือบทั้งหมด

ในทางกลับกัน สำหรับเอเจนต์ที่มีการอนุมานหลายขั้นตอน (Multi-step reasoning agent) โครงสร้างจะเปลี่ยนไปอย่างมาก โดยปัจจัยด้านความหน่วงสามารถสรุปได้ดังนี้:

• TTFT จะถูกสะสมตามจำนวนครั้งที่เรียกใช้งาน LLM — หากมี 5 ขั้นตอน ก็จะเกิด TTFT ขึ้น 5 ครั้ง
• เวลาในการรอการทำงานของเครื่องมือ (Tool execution) และการเรียกใช้ API ภายนอก จะแทรกอยู่ในแต่ละขั้นตอน
• ผลลัพธ์ของขั้นตอนก่อนหน้าจะเป็นอินพุตของขั้นตอนถัดไป ทำให้เกิดความล่าช้าต่อเนื่องจากการพึ่งพากันแบบลำดับ

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

เมื่อพิจารณาถึงความแตกต่างนี้ การออกแบบงบประมาณด้านความหน่วง (Latency budget) จึงต้องใช้วิธีการที่แตกต่างกันโดยสิ้นเชิงระหว่างการเรียกใช้งานแบบเดี่ยวและแบบหลายขั้นตอน ในขณะที่การเรียกใช้งานแบบเดี่ยวจะเน้นไปที่การเพิ่มความเร็วด้วยขนาดโมเดลหรือการทำ Quantization แต่สำหรับแบบหลายขั้นตอน การจัดสรรเวลาในแต่ละขั้นตอนและการลดจำนวนขั้นตอนลงจะเป็นประเด็นสำคัญที่ต้องให้ความสำคัญเป็นอันดับแรก

CoT (Chain-of-Thought) และการขยายขนาดขณะประมวลผล (Test-time Compute) เป็นเทคนิคที่มีประสิทธิภาพในการเพิ่มความแม่นยำของคำตอบสำหรับ LLM แต่ต้องแลกมาด้วยจำนวนโทเค็นขาออกที่เพิ่มขึ้นอย่างมาก

ผลกระทบหลักของ CoT ที่มีต่อความหน่วง (Latency) มีดังนี้:

• จำนวนโทเค็นขาออกเพิ่มขึ้น: เนื่องจากการสร้างขั้นตอนการคิดเชิงตรรกะแบบทีละขั้นตอน ทำให้จำนวนโทเค็นอาจเพิ่มขึ้นหลายเท่าตัวไปจนถึงหลายสิบเท่าเมื่อเทียบกับการตอบกลับเพียงคำตอบสุดท้าย
• การสะสมของ TPOT: ตามสูตรของ TPOT (Time Per Output Token) คือ TPOT(ms) = (request_latency - TTFT) / (total_output_tokens - 1) จะเห็นได้ว่าความหน่วงโดยรวมจะเพิ่มขึ้นเป็นเส้นตรงตามจำนวนโทเค็นขาออกที่เพิ่มขึ้น
• ขั้นตอนภายในของโมเดลการอนุมาน: โมเดลการอนุมาน (Reasoning models) อย่างตระกูล o1 จะสร้าง "โทเค็นความคิด" (Thought tokens) จำนวนมหาศาลไว้ภายใน ทำให้เกิดความหน่วงที่สะสมอยู่เบื้องหลังซึ่งมองไม่เห็นจากภายนอก

สำหรับการขยายขนาดขณะประมวลผล (Test-time Compute) นั้น การตัดสินใจจะขึ้นอยู่กับลักษณะของงาน: หากเป็นงานที่เน้นความถูกต้องเป็นสำคัญ เช่น การพิสูจน์ทางคณิตศาสตร์หรือการเขียนโค้ดที่ซับซ้อน การเพิ่มขั้นตอนการคำนวณถือเป็นเรื่องสมเหตุสมผล แต่หากเป็นงานที่เน้นความเร็ว เช่น การตอบคำถาม FAQ หรือการช่วยกรอกแบบฟอร์มมาตรฐาน การละเว้นหรือลดการใช้ CoT ให้เหลือน้อยที่สุดจะเหมาะสมกว่า

แนวทางปฏิบัติในการทำงานจริง สามารถอ้างอิงได้จากข้อมูลต่อไปนี้:

「แค่เอเจนต์ที่เรียกใช้เครื่องมือเพียง 5 อย่าง ทำไมถึงใช้เวลามากกว่า 30 วินาที」——เชื่อว่าวิศวกรหลายคนคงเคยเผชิญกับคำถามนี้ในการทำงานจริง

ความหน่วง (Latency) ในการทำ Agent Orchestration นั้นแตกต่างจากการเรียกใช้ LLM เพียงครั้งเดียว โดยมีโครงสร้างที่สะสมเพิ่มขึ้นแบบบวก (Additively) จากขั้นตอนการประมวลผลหลายขั้นตอนที่เรียงต่อกันเป็นลำดับ โดยสามารถสรุปแหล่งที่มาหลักของความหน่วงได้ดังนี้:

• LLM Inference Latency: ผลรวมของ TTFT (Time to First Token) และ TPOT (Time Per Output Token) ที่เกิดขึ้นในแต่ละขั้นตอน
• Tool Call Latency: เวลาในการรับส่งข้อมูล (Round-trip time) ไปยัง API ภายนอก, ฐานข้อมูล หรือ Search Engine
• Orchestrator Decision Latency: การสอบถาม LLM ซ้ำเพื่อตัดสินใจในขั้นตอนถัดไป
• Context Handoff Cost: ความยาวของ Prompt ที่เพิ่มขึ้นทุกครั้งที่มีการเพิ่มผลลัพธ์จากขั้นตอนก่อนหน้าลงใน Context Window

ปัญหาไม่ได้อยู่ที่ปัจจัยเหล่านี้เกิดขึ้นอย่างอิสระ แต่อยู่ที่โครงสร้างแบบอนุกรมที่ผลลัพธ์ของขั้นตอนก่อนหน้าเป็นอินพุตของขั้นตอนถัดไป หากกระบวนการหนึ่งใช้เวลา 3 วินาทีและมีทั้งหมด 10 ขั้นตอน จะเกิดความหน่วงอย่างน้อย 30 วินาที ยิ่งไปกว่านั้น เมื่อ Context มีขนาดใหญ่ขึ้น TTFT ของขั้นตอนท้ายๆ ก็มักจะใช้เวลานานขึ้นด้วยเช่นกัน

การค้นหาขั้นตอนที่สามารถทำแบบขนาน (Parallelize) ได้และการออกแบบ Task Graph คือวิธีรับมือแรกสำหรับโครงสร้างที่สะสมความหน่วงเช่นนี้

ในการใช้งาน Multi-step reasoning agent เรามักจะเผชิญกับความย้อนแย้งบางประการ นั่นคือ ยิ่งเพิ่มขั้นตอนการใช้เหตุผล (reasoning steps) คุณภาพของคำตอบก็จะยิ่งสูงขึ้น แต่ในขณะเดียวกัน การตอบสนองก็จะยิ่งช้าลงตามไปด้วย

ปัญหาคือระดับความล่าช้าที่ยอมรับได้นั้นแตกต่างกันอย่างสิ้นเชิง ขึ้นอยู่กับประเภทของงานและบริบทการใช้งาน หากเป็นอินเทอร์เฟซการสนทนาแบบเรียลไทม์ การให้ผู้ใช้รอเกิน 3 วินาทีอาจนำไปสู่การเลิกใช้งาน แต่ถ้าเป็น Data analysis agent ที่ทำงานอยู่เบื้องหลัง การประมวลผลที่ใช้เวลา 30 วินาทีอาจอยู่ในเกณฑ์ที่ยอมรับได้ กล่าวคือ การตัดสินใจ "เพิ่มความแม่นยำ" อาจกลายเป็นชนวนเหตุที่ทำให้ผู้ใช้เลิกใช้งานหรือเกิดความล้มเหลวของระบบได้โดยตรง หากเราไม่ควบคุมการแลกเปลี่ยน (trade-off) นี้อย่างมีสติในขั้นตอนการออกแบบ ก็อาจสายเกินไปที่จะแก้ไขในภายหลัง

การประยุกต์ใช้ CoT (Chain-of-Thought) กับโมเดลการอนุมาน (Inference Model) มักจะช่วยเพิ่มความแม่นยำของคำตอบ แต่ต้องแลกมาด้วยจำนวนโทเค็นเอาต์พุตที่เพิ่มขึ้นและค่าความหน่วง (Latency) ที่เพิ่มขึ้นเป็นเส้นตรง ซึ่งนี่คือหัวใจสำคัญของ "ภาวะกลืนไม่เข้าคายไม่ออกระหว่างความแม่นยำและความเร็ว" (Accuracy-Speed Dilemma)

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

ปัจจัยหลักที่ทำให้เกิดภาวะกลืนไม่เข้าคายไม่ออกนี้มีดังนี้:

• ต้นทุนการสร้างโทเค็น (Token Generation Cost): ยิ่งขั้นตอนการอนุมานเพิ่มขึ้น ค่า Time Per Output Token (TPOT) สะสมก็จะยิ่งสูงขึ้น ทำให้ Request Latency โดยรวมเพิ่มขึ้นอย่างมาก
• การเชื่อมโยงขั้นตอนกลาง (Chain of Intermediate Steps): ใน CoT เอาต์พุตระดับกลางจะถูกป้อนกลับเข้าไปเป็นพรอมต์ถัดไป ทำให้ Context Window ขยายใหญ่ขึ้น และส่งผลให้ค่า TTFT (Time To First Token) แย่ลงได้ง่าย
• ความไม่เป็นเส้นตรงของการขยายขนาดขณะอนุมาน (Non-linearity of Test-time Compute): แม้จะเพิ่มการคำนวณขณะทดสอบ (Test-time Compute) แต่การเพิ่มขึ้นของความแม่นยำจะค่อยๆ ลดลง ในขณะที่ค่าความหน่วงยังคงเพิ่มขึ้นอย่างต่อเนื่อง

แนวทางในการแก้ไขภาวะกลืนไม่เข้าคายไม่ออกนี้คือ "กลยุทธ์การกำหนดเส้นทาง" (Routing Strategy) ซึ่งเป็นการสลับโมเดลหรือปรับความลึกของการอนุมานแบบไดนามิกตามความซับซ้อนของงาน

ความต้องการในการสร้างสมดุลระหว่างประสบการณ์ผู้ใช้ (User Experience) และคุณภาพของงานนั้นแตกต่างกันไปอย่างมากตามการใช้งาน AI Agent

ตัวอย่างเช่น ในแชทบอทสำหรับบริการลูกค้า ความเร็วในการตอบสนองเป็นตัวกำหนดประสบการณ์ของผู้ใช้เนื่องจากผู้ใช้นั่งรออยู่หน้าจอ ในขณะเดียวกันก็ไม่สามารถลดทอนคุณภาพได้เนื่องจากคำตอบที่ผิดพลาดอาจนำไปสู่ความเสียหายต่อแบรนด์ หากเป็น Agent สำหรับสร้างหรือรีวิวโค้ด นักพัฒนายอมรอได้ในระดับหนึ่ง แต่ผลลัพธ์ที่มีบั๊กจะเพิ่มต้นทุนในกระบวนการถัดไป ส่วนการสรุปเอกสารหรือการสร้างรายงานนั้นสามารถประมวลผลแบบอะซิงโครนัส (Asynchronous) ในเบื้องหลังได้ จึงสามารถจัดสรรเวลาในการประมวลผล (Thinking time) เพื่อเน้นคุณภาพได้มากกว่า

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

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

หากดำเนินการพัฒนาโดยไม่ได้ระบุการแลกเปลี่ยน (Trade-off) นี้ให้ชัดเจนตั้งแต่ขั้นตอนการออกแบบ ในภายหลังจะได้รับฟีดแบ็กที่ขัดแย้งกันทั้งเรื่อง "ช้าเกินไป" และ "คุณภาพต่ำ" การกำหนดค่าความหน่วง (Latency) ที่ยอมรับได้และมาตรฐานคุณภาพสำหรับแต่ละการใช้งานไว้ล่วงหน้า จึงเป็นจุดเริ่มต้นของการออกแบบที่ดี

คุณเคยสงสัยหรือไม่ว่า "ทำไมแนวทางการออกแบบถึงเปลี่ยนไปอย่างมากระหว่างแบบเรียลไทม์ (Real-time) และแบบอะซิงโครนัส (Asynchronous)"? ความจริงแล้วเป็นเพราะ ธรรมชาติของข้อแลกเปลี่ยน (Trade-off) นั้นแตกต่างกันโดยสิ้นเชิง หากนำตรรกะการจัดสรรงบประมาณแบบเดียวกันไปใช้ จะทำให้การออกแบบล้มเหลวได้ง่าย

ระบบเรียลไทม์คือระบบที่ผู้ใช้คาดหวังว่าจะได้รับการตอบสนองทันทีหลังจากป้อนข้อมูล ตัวอย่างที่ชัดเจนคือ AI Chatbot หรือผู้ช่วยสั่งงานด้วยเสียง ในกรณีนี้ ยิ่งใช้เวลาคิดนานเท่าไร ความเสี่ยงที่ผู้ใช้จะเลิกใช้งานก็ยิ่งสูงขึ้น หากเพิ่มขั้นตอน CoT (Chain of Thought) เพื่อมุ่งเน้นความแม่นยำ เวลาในการตอบสนองที่เพิ่มขึ้นนั้นจะส่งผลเสียต่อประสบการณ์ของผู้ใช้โดยตรง โดยทั่วไปมักต้องการขีดจำกัดของความหน่วง (Latency) ไม่เกินสองสามวินาที ดังนั้นการลด TTFT (Time To First Token) ให้เหลือน้อยที่สุดจึงเป็นตัวชี้วัดที่สำคัญที่สุด

ในทางกลับกัน ระบบอะซิงโครนัสเป็นโครงสร้างที่ระบบสามารถรองรับการรอคอยจนกว่าการประมวลผลจะเสร็จสิ้นได้ ตัวอย่างเช่น การสรุปเอกสารแบบแบตช์ในตอนกลางคืน หรือเอเจนต์สร้างรายงานที่ทำงานอยู่เบื้องหลัง กลไกอย่าง Background mode ของ OpenAI ที่สามารถเก็บข้อมูลการตอบสนองระหว่างการสร้างไว้ได้นานประมาณ 10 นาที จึงเหมาะกับวัตถุประสงค์นี้ เนื่องจากสรูพุต (Throughput) และต้นทุนมีความสำคัญเหนือกว่าความหน่วง จึงสามารถตัดสินใจเพิ่มขั้นตอนการอนุมาน (Inference steps) เพื่อเพิ่มความแม่นยำได้ง่ายขึ้น รวมถึงสามารถตั้งค่าความละเอียดของ Timeout ให้กว้างขึ้นและออกแบบการจำกัดปริมาณงาน (Throttling) ให้ผ่อนปรนได้มากขึ้น

สิ่งที่สำคัญคือกรณีที่เอเจนต์ตัวเดียวกันต้องทำงานโดยสลับไปมาระหว่างโหมดเรียลไทม์และโหมดอะซิงโครนัส

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

เปรียบเทียบวิธีการหลักโดยแบ่งออกเป็น 3 แกน ได้แก่ การเร่งความเร็วในการอนุมาน (Inference), การลดขนาดโมเดล (Model Compression) และการจัดการความหน่วงในการค้นหา (Search Latency)

ในการเพิ่มความเร็วของการอนุมาน (Inference) เรามักจะเริ่มจากการพิจารณาปรับเปลี่ยนสถาปัตยกรรมหรือน้ำหนัก (Weights) ของโมเดล แต่ในความเป็นจริง มีรายงานจำนวนมากระบุว่าการผสมผสานแนวทางระหว่างกลยุทธ์การถอดรหัส (Decoding Strategy) และการทำควอนไทเซชัน (Quantization) สามารถลดค่าความหน่วง (Latency) ได้โดยไม่สูญเสียความแม่นยำมากนัก

Speculative Decoding คือกลไกที่ "Draft Model" ขนาดเล็กจะทำการอ่านล่วงหน้าหลายโทเค็น และให้โมเดลขนาดใหญ่ทำการตรวจสอบในคราวเดียว

• Draft Model สร้าง n โทเค็นอย่างรวดเร็ว → โมเดลขนาดใหญ่ตัดสินใจยอมรับหรือปฏิเสธแบบขนาน
• ยิ่งอัตราการยอมรับสูง จำนวนครั้งในการเรียกใช้โมเดลขนาดใหญ่จะลดลง ส่งผลให้ TPOT (Time Per Output Token) สั้นลง
• มักได้ผลดีในงานที่การกระจายตัวของคำศัพท์คาดเดาได้ง่าย (เช่น การตอบกลับตามรูปแบบมาตรฐาน หรือการเติมโค้ด)

Quantization คือการบีบอัดน้ำหนักของโมเดลจาก FP32 เป็น INT8 หรือ INT4 เพื่อลดการใช้แบนด์วิดท์หน่วยความจำ GPU และเพิ่มปริมาณงาน (Throughput) ในการอนุมาน

• สำหรับเซิร์ฟเวอร์อนุมานอย่าง NVIDIA Triton แนะนำให้ทำการวัดผล (Benchmark) ทั้งในตัวชี้วัด Time to First Token (TTFT) และ Inter-Token Latency
• แม้ว่าการทำ Quantization จะช่วยปรับปรุง TTFT ได้ แต่ต้องตรวจสอบให้แน่ใจเสมอว่าความแม่นยำที่ลดลงนั้นอยู่ในเกณฑ์ที่ยอมรับได้โดยใช้ชุดประเมินผล (Evaluation Set)
• วิธีการที่ผสมผสานการทำ Fine-tuning และ Quantization เข้าด้วยกันอย่าง QLoRA ก็เป็นอีกหนึ่งทางเลือก

ในมุมมองของการออกแบบงบประมาณด้านความหน่วง (Latency Budget) สิ่งสำคัญคือ การพิจารณาว่าตัวชี้วัดใดที่เป็นคอขวด

การใช้โมเดลขนาดใหญ่ในทุกขั้นตอนการอนุมาน (Inference) มักจะไม่มีประสิทธิภาพในแง่ของงบประมาณด้านความหน่วง (Latency budget) การเลือกใช้โมเดลให้เหมาะสมกับลักษณะของงานจะช่วยให้บรรลุทั้งความเร็วและความแม่นยำไปพร้อมกัน

เกณฑ์ในการตัดสินใจมอบหมายงานจะขึ้นอยู่กับความซับซ้อนของงานและข้อกำหนดด้านความเร็วในการตอบสนอง

• กรณีที่เหมาะกับ SLM (Small Language Model): ขั้นตอนการประมวลผลก่อนหน้า (Pre-processing) หรือหลังจากนั้น (Post-processing) ที่มีรูปแบบชัดเจน เช่น การจำแนกเจตนา (Intent classification), การสกัดคำสำคัญ (Keyword extraction) หรือการแปลงข้อมูลให้อยู่ในรูปแบบมาตรฐาน เหมาะสำหรับงานที่ให้ความสำคัญกับความเร็วในการตอบสนองและมีข้อกำหนดด้านความแม่นยำในระดับที่จำกัด
• กรณีที่เหมาะกับ LLM ขนาดใหญ่: การอนุมานหลายขั้นตอนที่ซับซ้อน, การตีความภาษาธรรมชาติที่มีความกำกวม, และการตัดสินใจที่ต้องอาศัยความเชี่ยวชาญเฉพาะทาง ใช้ในสถานการณ์ที่ความแม่นยำเป็นสิ่งสำคัญที่สุดและสามารถยอมรับความล่าช้าได้ในระดับหนึ่ง

กลยุทธ์แบบสองขั้นตอน (Two-tier approach) โดยการมอบหมายงานให้ SLM หากเป็นงานจำแนกประเภทแบบง่ายหรือประโยคสั้น และส่งต่อ (Escalate) ให้ LLM หากจำเป็นต้องมีการอนุมานที่ซับซ้อน ถือเป็นวิธีที่มีประสิทธิภาพในการประหยัดงบประมาณด้านความหน่วง

โมเดลแบบ MoE (Mixture of Experts) มีแนวคิดการออกแบบที่ทำให้เกิดการเลือกใช้โมเดลในลักษณะนี้ภายในโมเดลเดียว เนื่องจากมีการสลับการทำงานของเครือข่ายย่อยที่เป็นผู้เชี่ยวชาญ (Expert sub-network) ตามอินพุตโทเค็น ทำให้ไม่จำเป็นต้องใช้พารามิเตอร์ทั้งหมดในทุกครั้ง ส่งผลให้มีแนวโน้มที่จะลดต้นทุนการอนุมานลงได้เมื่อเทียบกับ Dense Model (โมเดลแบบเชื่อมต่อหนาแน่น) ที่มีความแม่นยำเท่ากัน

สรุปข้อควรระวังในการนำไปใช้งานมีดังนี้

หากคุณเคยใช้งาน RAG ในสภาพแวดล้อมการผลิต (Production) คุณคงเคยประสบปัญหา "การค้นหาที่ล่าช้าจนทำให้การตอบสนองของเอเจนต์โดยรวมติดขัด" มาบ้างใช่ไหมครับ

ใน RAG รูปแบบปกติ จะมีขั้นตอนการทำงานคือ การแปลงคำถามของผู้ใช้เป็น Embedding เพื่อค้นหาใน Vector Database จากนั้นจึงนำ Chunk ที่ได้ส่งต่อไปยัง LLM ซึ่งขั้นตอนการค้นหานี้เกิดขึ้นเพียงครั้งเดียว ผลกระทบต่อค่า Latency จึงค่อนข้างจำกัด

ในทางกลับกัน สำหรับ Agentic RAG สถานการณ์จะแตกต่างออกไป เนื่องจากมีการค้นหาเพิ่มเติมในทุกขั้นตอนของการอนุมานแบบหลายขั้นตอน (Multi-step reasoning) ทำให้ความล่าช้าในการค้นหาสะสมตัวอยู่ในลูป โดยจุดที่ทำให้เกิดความล่าช้าหลักๆ มีดังนี้:

• การสร้าง Embedding: กระบวนการแปลง Query เป็นเวกเตอร์เกิดขึ้นในทุกขั้นตอน
• การค้นหาเพื่อนบ้านใกล้เคียง (Nearest Neighbor Search) ใน Vector Database: ยิ่งขนาดของ Index ใหญ่ขึ้น เวลาที่ใช้ในการค้นหาก็จะยิ่งเพิ่มขึ้น
• การประมวลผลแบบ Hybrid Search: เกิดต้นทุนการคำนวณเพิ่มเติมเมื่อต้องรวมผลลัพธ์จาก Semantic Search และ BM25 เข้าด้วยกันโดยใช้ RRF หรือวิธีอื่นๆ

แนวทางปฏิบัติในการจัดการกับความล่าช้าในการค้นหามีดังนี้:

• การใช้ประโยชน์จาก Prefix Cache: ใช้ Cache เพื่อรองรับการอ้างอิงเอกสารเดิมซ้ำๆ

บทสรุป: การออกแบบงบประมาณความหน่วง (Latency Budget) มีพื้นฐานมาจากกลยุทธ์ 3 ขั้นตอน เริ่มต้นจากการจัดสรรเวลาให้กับ Task Graph ไปจนถึงการดำเนินการผ่านการทำ Throttling และการตรวจสอบ (Monitoring)

หลังจากเข้าใจแนวคิดแล้ว ขั้นตอนต่อไปคือการเข้าสู่กระบวนการออกแบบและจัดสรรเวลาจริง โดยมีเสาหลักในการนำไปใช้งาน 3 ประการ ได้แก่ การจัดสรรเวลาตามความซับซ้อนของงาน (Task), การกำหนดนโยบาย Timeout และการตรวจสอบแบบเรียลไทม์ด้วย AI Observability

ในการออกแบบงบประมาณด้านเวลาแฝง (Latency Budget) เรามักจะคิดว่า "ควรจัดสรรเวลาให้เท่าๆ กันทั้งระบบ" แต่ในความเป็นจริง การใช้ Task Graph เพื่อแสดงภาพความสัมพันธ์และระดับความสำคัญของแต่ละขั้นตอน แล้วจัดสรรงบประมาณที่แตกต่างกันในแต่ละขั้นตอนจะมีประสิทธิภาพมากกว่า

Task Graph คือการแสดงชุดกระบวนการที่เอเจนต์ดำเนินการในรูปแบบกราฟระบุทิศทางแบบไม่มีวงรอบ (Directed Acyclic Graph: DAG) โดยแต่ละโหนดจะสอดคล้องกับขั้นตอนการประมวลผล เช่น "การเรียกใช้เครื่องมือ (Tool Calling)", "การอนุมานด้วย LLM (LLM Inference)" หรือ "การค้นหาด้วย RAG (RAG Search)" และเส้นเชื่อม (Edge) จะแสดงถึงความสัมพันธ์เชิงพึ่งพา

ขั้นตอนพื้นฐานในการจัดสรรเวลามีดังนี้:

• การระบุเส้นทางวิกฤต (Critical Path): ค้นหาห่วงโซ่ความสัมพันธ์ที่ยาวที่สุดบนกราฟ และทุ่มงบประมาณส่วนใหญ่ไปที่จุดนั้น
• การจำแนกประเภทขั้นตอน: แบ่งเป็นขั้นตอนแบบซิงโครนัส (Synchronous) ที่ผู้ใช้ต้องรอ และขั้นตอนแบบอะซิงโครนัส (Asynchronous) ที่สามารถทำงานในเบื้องหลังได้ โดยให้ความสำคัญกับการจัดสรรงบประมาณให้ขั้นตอนแรกก่อน
• การกำหนดตัวเลขงบประมาณ: ตัวอย่างเช่น หากตั้งงบประมาณรวมไว้ที่ 10 วินาที ให้กำหนดขีดจำกัดสูงสุดในแต่ละโหนด เช่น การตีความเจตนา (LLM Inference) 2 วินาที, การค้นหาด้วย RAG 1.5 วินาที, การเรียกใช้เครื่องมือ 4 วินาที และการสร้างคำตอบ 2.5 วินาที
• การสำรองเวลา (Buffer): เพิ่มเวลาสำรองประมาณ 10-15% ในแต่ละขั้นตอนเพื่อรองรับความผันผวนของการรับส่งข้อมูลผ่านเครือข่ายหรือ API ภายนอก

การกำหนด Task Graph ช่วยให้สามารถติดตามสาเหตุของความล่าช้าในแต่ละขั้นตอนได้อย่างแม่นยำโดยใช้เครื่องมือ AI Observability

การควบคุมปริมาณ (Throttling) และการกำหนดเวลาหมดอายุ (Timeout) ทำหน้าที่เป็น "วาล์วนิรภัย" สำหรับงบประมาณด้านความหน่วง (Latency Budget) หลังจากที่ได้จัดสรรเวลาในกราฟงาน (Task Graph) แล้ว หากไม่มีกลไกในการควบคุมหรือตัดการทำงานที่อาจเกินงบประมาณในขณะประมวลผล ค่าที่ออกแบบไว้ก็จะเป็นเพียงแค่ทฤษฎีที่ทำไม่ได้จริง

แนวทางการตั้งค่าการควบคุมปริมาณ (Throttling)

การควบคุมปริมาณคือวิธีการควบคุมจำนวนคำขอพร้อมกันหรืออัตราการสร้างโทเค็นไม่ให้เกินขีดจำกัด โดยมีเกณฑ์ในการตัดสินใจตั้งค่าดังนี้:

• สำหรับส่วนติดต่อผู้ใช้ (User Interface) ที่ต้องการการตอบสนองแบบเรียลไทม์ ให้จำกัดจำนวนโทเค็นขาออกสูงสุดต่อคำขออย่างเข้มงวด เพื่อให้ความสำคัญกับความเร็วในการตอบสนอง
• สำหรับการประมวลผลแบบแบตช์ (Batch Processing) หรือภารกิจแบบอะซิงโครนัส (Asynchronous Task) ให้ความสำคัญกับการเพิ่มปริมาณงาน (Throughput) ให้สูงสุด และตั้งค่าขีดจำกัดจำนวนการทำงานพร้อมกันแบบผ่อนปรน

ควรระวังว่าหากตั้งค่าการควบคุมปริมาณเข้มงวดจนเกินไป อาจส่งผลให้คุณภาพของงานที่มีความซับซ้อนลดลงได้

การออกแบบลำดับชั้นของนโยบายการหมดเวลา (Timeout Policy)

การกำหนดเวลาหมดอายุไม่ควรตั้งเป็นค่าเดียว แต่ควรแบ่งเป็นลำดับชั้นตามความละเอียดของการประมวลผล:

• Step Timeout: การตั้งเวลาหมดอายุแบบสั้น (เช่น ไม่กี่วินาทีถึงสิบกว่าวินาที) สำหรับการเรียกใช้งาน LLM แต่ละครั้ง หรือการเรียกใช้เครื่องมือภายนอก
• Agent Task Timeout: เวลาจำกัดสูงสุดสำหรับภารกิจหนึ่งงาน โดยควรเผื่อเวลาไว้มากกว่าผลรวมของ Step Timeout
• Session Timeout: เวลาจำกัดสำหรับบทสนทนาแบบหลายรอบ (Multi-turn) ทั้งหมด

นอกจากนี้ จำเป็นต้องกำหนดพฤติกรรมที่จะเกิดขึ้นเมื่อมีการหมดเวลาไว้ล่วงหน้าด้วย

「ตั้งงบประมาณ Latency ไว้แล้ว แต่คุณทราบหรือไม่ว่าในสภาพแวดล้อมการใช้งานจริง (Production) แต่ละขั้นตอนใช้เวลาไปเท่าไหร่กันแน่」— หากยังคงดำเนินงานต่อไปโดยไม่สามารถตอบคำถามนี้ได้ การระบุสาเหตุที่ทำให้งบประมาณเกินจะล่าช้ากว่าที่ควรจะเป็น

AI Observability คือกลไกที่ช่วยให้สามารถมองเห็นภาพรวมของการวัดผลในแต่ละขั้นตอนการประมวลผลของ Agent ได้อย่างเป็นศูนย์กลาง ไม่ว่าจะเป็นขั้นตอนการ Inference ของ LLM, การเรียกใช้ Tool หรือการเชื่อมต่อกับ API ภายนอก ซึ่งแตกต่างจากการตรวจสอบแอปพลิเคชันแบบเดิม โดยมีความสำคัญที่จะต้องติดตามตัวชี้วัดต่อไปนี้แยกกัน:

• TTFT (Time to First Token): ระยะเวลาจนกว่าโมเดลจะส่ง Token แรกออกมา
• TPOT (Time Per Output Token): ความหน่วงในการส่งออกระหว่าง Token โดยคำนวณจากสูตร (request_latency - TTFT) / (total_output_tokens - 1)
• Cumulative Latency per Step: ผลรวมของเวลาที่ใช้ในแต่ละโหนดของ Task Graph

จุดสำคัญในการนำไปใช้งานคือการรวมการวัดผลเข้ากับชั้น Orchestration ของ Agent และกำหนด Trace ID ในระดับขั้นตอน วิธีนี้จะช่วยให้สามารถระบุได้ทันทีว่าการเรียกใช้ Tool หรือ LLM Hop ใดที่เป็นตัวการทำให้งบประมาณบานปลาย

สำหรับการออกแบบระบบแจ้งเตือน การตั้งค่าให้มีการแจ้งเตือนเมื่อใช้ไปแล้ว 80% ของงบประมาณ และสั่งการทำงานแบบ Fallback (เช่น การเปลี่ยนไปใช้คำตอบแบบย่อหรือการคืนค่าจาก Cache) โดยอัตโนมัติก่อนที่จะถึง 100% ถือเป็นโครงสร้างที่มีประสิทธิภาพ

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

การควบคุมค่า Latency ในระบบ Multi-agent จำเป็นต้องมีการออกแบบโดยกระจายงบประมาณเวลา ไม่ใช่กำหนด "เท่าไหร่สำหรับทั้งระบบ" แต่ต้องกำหนดว่า "เท่าไหร่สำหรับแต่ละเอเจนต์" ซึ่งปัจจัยที่จะส่งผลอย่างมากในตอนนั้นคือ ความล่าช้าของการสื่อสารแบบ A2A (Agent-to-Agent) และการเลือกรูปแบบการทำงานว่าจะให้เอเจนต์รันแบบขนาน (Parallel) หรือแบบลำดับ (Sequential) การรันแบบลำดับจะทำให้ความล่าช้าของแต่ละเอเจนต์ถูกนำมาบวกกันโดยตรง ในขณะที่การรันแบบขนาน เอเจนต์ที่ช้าที่สุดจะกลายเป็นคอขวด (Bottleneck) ซึ่งวิธีใดจะให้ผลดีกว่านั้นขึ้นอยู่กับความสัมพันธ์เชิงพึ่งพาของงาน (Task dependency) และไม่สามารถตัดสินได้แบบเหมารวม

ทุกครั้งที่มีการสื่อสารระหว่างเอเจนต์ จะเกิดกระบวนการสามขั้นตอนสะสมขึ้น ได้แก่ การทำ Serialization, การรับส่งข้อมูลผ่านเครือข่าย และการทำ Deserialization ความหน่วง (Latency) ที่ไม่ปรากฏให้เห็นในเอเจนต์เดี่ยวนี้ จะกลายเป็นสิ่งที่สังเกตเห็นได้ชัดเจนขึ้นในโครงสร้างแบบหลายเอเจนต์ (Multi-agent) ผ่านโปรโตคอล A2A (Agent-to-Agent Protocol)

ในตอนแรก เรามักจะคิดว่า "ยิ่งแบ่งเอเจนต์ให้ละเอียดเท่าไร ก็ยิ่งขนานการทำงานได้ง่ายขึ้นเท่านั้น" แต่ในความเป็นจริง มีรายงานว่าหากแบ่งละเอียดเกินไป ค่าใช้จ่ายแฝงในการสื่อสาร (Communication Overhead) จะสูงกว่าต้นทุนในการประมวลผล (Inference Cost) ส่งผลให้ค่าความหน่วงโดยรวมแย่ลง

ปัจจัยหลักที่ทำให้การสื่อสารผ่าน A2A เพิ่มความหน่วง:

• ขนาดของ Payload ที่ใหญ่ขึ้น: การส่งผ่าน Context Window ทั้งหมดระหว่างเอเจนต์ ทำให้ปริมาณข้อมูลที่ต้องโอนย้ายเพิ่มขึ้นอย่างรวดเร็ว
• การรอคอยแบบซิงโครนัส (Synchronous Waiting): เมื่อเกิดการพึ่งพากันแบบลำดับที่เอเจนต์ปลายทางต้องรอให้เอเจนต์ต้นทางทำงานเสร็จ ความหน่วงจะสะสมแบบทวีคูณ
• การยืนยันตัวตนและการตรวจสอบ Token ซ้ำ: ในโครงสร้างที่มีการตรวจสอบ OIDC Token ทุกครั้งที่มีการเรียกใช้งาน จะทำให้เกิดความหน่วงจากการรับส่งข้อมูลเพิ่มขึ้นไปอีก

แนวทางแก้ไขที่มีประสิทธิภาพ:

• การบีบอัด Context และการส่งเฉพาะสรุป: ส่งเฉพาะผลลัพธ์ระหว่างทางที่สรุปแล้วไปยังเอเจนต์ข้างเคียง แทนที่จะส่งประวัติทั้งหมด
• การใช้ประโยชน์จาก Prefix Caching: การแคชส่วนคำสั่งที่เป็นมาตรฐานร่วมกัน จะช่วยลดค่า TTFT (Time to First Token) ได้อย่างมาก

หากไม่มีความสัมพันธ์แบบพึ่งพากันระหว่างงาน ให้เลือกการประมวลผลแบบขนาน (Parallel Execution) แต่หากผลลัพธ์ของขั้นตอนก่อนหน้าจำเป็นต้องใช้เป็นอินพุตสำหรับขั้นตอนถัดไป ให้เลือกการประมวลผลแบบลำดับ (Sequential Execution) การจัดระเบียบเกณฑ์การตัดสินใจนี้ไว้ตั้งแต่ต้นจะช่วยป้องกันความผิดพลาดในการจัดสรรงบประมาณด้านความหน่วง (Latency Budget) ได้

กรณีที่การประมวลผลแบบขนานมีประสิทธิภาพ

• เฟสการค้นหาและดึงข้อมูลที่เรียกใช้ External API หลายตัวพร้อมกัน
• การประมวลผลสรุปเนื้อหาของ Document Chunk ที่เป็นอิสระต่อกันแบบขนาน
• งานที่สามารถเปิดใช้งานเครื่องมือต่างประเภทกัน (เช่น การคำนวณ, การรันโค้ด, การดึงข้อมูล) ได้พร้อมกัน

งานเหล่านี้จะช่วยลดความหน่วงรวมลงได้อย่างมาก เนื่องจากเวลาในการทำงานทั้งหมดจะถูกรวมศูนย์อยู่ที่คอขวดเพียงจุดเดียว

กรณีที่จำเป็นต้องมีการประมวลผลแบบลำดับ

• การใช้เหตุผลแบบหลายขั้นตอน (Multi-step Reasoning) ที่ต้องนำผลลัพธ์จากการอนุมานในขั้นตอนก่อนหน้ามาตัดสินใจในขั้นตอนถัดไป
• กระบวนการที่ต้องนำผลลัพธ์จากการเรียกใช้เครื่องมือมาประกอบเข้ากับ CoT (Chain of Thought) ในขณะที่ดำเนินการ
• เวิร์กโฟลว์ที่มีการจัดการข้อผิดพลาดหรือเงื่อนไขแบบแตกกิ่งก้านสาขาต่อเนื่องกัน

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

แนวทางปฏิบัติในการเลือก

แนวทางที่มีประสิทธิภาพคือการวาด Task Graph เพื่อแสดงภาพความสัมพันธ์ของ Edge (Dependency Edges) และจัดกลุ่มโหนดที่ไม่มีความสัมพันธ์กันให้เป็น Batch แบบขนาน การแยกส่วนที่สามารถขนานได้ออกจากส่วนที่จำเป็นต้องทำตามลำดับอย่างชัดเจน จะช่วยให้คุณใช้จ่ายงบประมาณด้านความหน่วงได้อย่างมีประสิทธิภาพสูงสุด

ทั้งนี้ ควรระวังว่าการประมวลผลแบบขนานจะใช้ทรัพยากรของ Thread หรือ Coroutine พร้อมกัน ดังนั้นหากจำนวนการทำงานของ Agent เพิ่มขึ้น อาจทำให้ GPU หรือแบนด์วิดท์เครือข่ายกลายเป็นคอขวดได้ สำหรับการออกแบบระบบ Multi-agent โดยรวม โปรดดูที่ [Multi-agent AI คืออะไร?

บทสรุป: การทำความเข้าใจรูปแบบความผิดพลาดที่มักถูกมองข้ามในขั้นตอนการออกแบบ และการวางมาตรการป้องกันไว้ล่วงหน้า คือกุญแจสำคัญสู่การบริหารจัดการ Latency Budget ให้มีเสถียรภาพ

ปัจจัยความผิดพลาดหลักมี 2 ประการ ได้แก่ "การใช้ทรัพยากรแบบไม่จำกัด" และ "การขยายตัวของ Context Window" โดยจะขออธิบายวิธีการตรวจจับและแนวทางการหลีกเลี่ยงของแต่ละหัวข้อตามลำดับดังนี้

การพยายามเติมน้ำในอ่างโดยเปิดก๊อกทิ้งไว้โดยไม่รู้ว่าจะหยุดเมื่อใด น้ำก็จะล้นออกมาเรื่อยๆ สภาวะที่เรียกว่า การใช้ทรัพยากรแบบไม่จำกัด (Unbounded Consumption) ก็เป็นเช่นเดียวกัน หากเอเจนต์ติดอยู่ในลูปที่ไม่มีเงื่อนไขการสิ้นสุดหรือมีการทำตรรกะการลองใหม่ (Retry logic) ซ้ำๆ งบประมาณด้านความหน่วง (Latency budget) ก็จะหมดลงอย่างรวดเร็ว

รูปแบบการใช้งานเกินขนาดที่พบบ่อยมีดังนี้:

• การขาดเงื่อนไขการสิ้นสุดลูป: เมื่อการเรียกใช้เครื่องมือล้มเหลวแล้วเกิดการลองใหม่แบบไม่สิ้นสุด ทำให้สิ้นเปลืองโทเค็นและเวลามากกว่างบประมาณที่ตั้งไว้หลายเท่า
• การเรียกใช้ซับเอเจนต์แบบต่อเนื่อง: ออร์เคสเตรเตอร์ (Orchestrator) เรียกใช้ซับเอเจนต์หลายตัวตามลำดับ ทำให้ความล่าช้าในแต่ละขั้นตอนสะสมรวมกัน
• การรอคอย Timeout ของ API ภายนอก: การรอการตอบกลับจากบริการภายนอกกลายเป็นการประมวลผลแบบบล็อก (Blocking process) ทำให้ความหน่วงโดยรวมหยุดชะงักเป็นเวลานาน

การตรวจจับจำเป็นต้องมีการวัดผลแบบเรียลไทม์ด้วยเครื่องมือ AI Observability โดยเฉพาะอย่างยิ่งการตรวจสอบตัวชี้วัดต่อไปนี้:

การขยายตัวของ Context Window มักทำให้เข้าใจผิดว่า "ยิ่งให้ข้อมูลมาก ความแม่นยำจะยิ่งสูงขึ้น" แต่ในความเป็นจริง ปัญหาที่มักเกิดขึ้นมากกว่าคือการเสื่อมถอยของ Latency แบบลูกโซ่

ช่องทางหลักที่การขยายตัวทำให้เกิดความล่าช้ามีดังนี้:

• TTFT (Time to First Token) เพิ่มขึ้น: ยิ่งจำนวน Input Token มากขึ้น เวลาที่โมเดลใช้ในการคำนวณ Attention จะเพิ่มขึ้นแบบมากกว่าเชิงเส้น (Super-linear)
• อัตราการ Hit ของ Prefix Cache ลดลง: หากส่งประวัติการสนทนาที่ยาวและแตกต่างกันไปในทุกครั้ง Cache จะไม่ถูกนำกลับมาใช้ใหม่ ทำให้ไม่ได้รับผลลัพธ์การลด TTFT สูงสุดกว่า 96% ตามที่แสดงในตัวอย่างการใช้งานจริงของ Vertex
• ผลกระทบต่อชั้น Orchestration: ในการอนุมานแบบหลายขั้นตอน (Multi-step inference) โครงสร้างที่ผลลัพธ์ของขั้นตอนแรกจะถูกต่อท้ายเป็น Input ของขั้นตอนถัดไป ทำให้ Input บวมขึ้นเรื่อยๆ ในขั้นตอนหลังๆ และเกิดความล่าช้าสะสม

แนวทางแก้ไขที่มีประสิทธิภาพมี 3 ประการดังนี้:

• Context Compression: แทนที่ประวัติการสนทนาที่ผ่านมาด้วย Token สรุปความ และลบรายละเอียดที่ไม่จำเป็นออก
• Sliding Window: เก็บไว้เฉพาะ N เทิร์นล่าสุด และตัดประวัติเก่าทิ้งเป็นระยะ
• การแยก Context ตาม Task Graph: ส่งเฉพาะข้อมูลที่จำเป็นสำหรับแต่ละ Subtask เพื่อป้องกันไม่ให้ Shared Context ขยายตัวจนเกินไป

สิ่งที่ต้องระวังเป็นพิเศษคือกรณีที่ Agent ตัดสินใจเก็บผลลัพธ์การเรียกใช้เครื่องมือ (Tool call) ทั้งหมดไว้เพียงเพราะ "เผื่อไว้ก่อน"

บทสรุป: การออกแบบงบประมาณความหน่วง (Latency Budget Design) คือการตัดสินใจเชิงโครงสร้างเพื่อไล่ตามทั้ง "ความเร็ว" และ "ความฉลาด" ไปพร้อมกัน โดยจำเป็นต้องมีการจัดการแบบหลายระดับตามความซับซ้อนของงาน โหมดการทำงาน และโครงสร้างของระบบ

เนื้อหาที่อธิบายในบทความนี้สามารถสรุปประเด็นสำคัญได้ดังนี้:

การทำความเข้าใจโครงสร้างความหน่วงคือจุดเริ่มต้น การแยกแยะระหว่าง TTFT (Time To First Token) และ TPOT (Time Per Output Token) เพื่อให้เห็นภาพชัดเจนว่าความหน่วงเกิดขึ้นในขั้นตอนใด คือก้าวแรกของการออกแบบ สำหรับการอนุมานแบบหลายขั้นตอน (Multi-step reasoning) ความหน่วงของแต่ละขั้นตอนจะสะสมรวมกัน ดังนั้นการจัดสรรเวลาโดยใช้ Task Graph จึงเป็นวิธีที่มีประสิทธิภาพ

ปรับเปลี่ยนกลยุทธ์ตามโหมดการทำงาน แนวทางพื้นฐานคือ การใช้ Streaming และการมอบหมายงานให้ SLM (Small Language Model) สำหรับงานแบบ Real-time เพื่อรักษาความเร็วที่ผู้ใช้สัมผัสได้ ส่วนงานแบบ Asynchronous ให้เน้นความแม่นยำโดยใช้การประมวลผลเบื้องหลัง (Background execution) ร่วมกับการขยายขนาดขณะอนุมาน (Test-time Compute)

ใช้เทคนิคการลดความหน่วงร่วมกัน Speculative Decoding, การทำ Quantization, Prefix Caching และ MoE (Mixture of Experts) ต่างมีสถานการณ์ที่เหมาะสมในการใช้งานที่แตกต่างกัน การไม่พึ่งพาเทคนิคใดเทคนิคหนึ่งเพียงอย่างเดียว แต่เลือกใช้ผสมผสานกันตามคอขวดของระบบ จะช่วยเพิ่มประสิทธิภาพได้สูงสุด