ความเชื่อผิดๆ เกี่ยวกับ serverless ที่ว่า “คุณจ่ายเพียงแค่ตามจำนวนมิลลิวินาทีที่โค้ดทำงาน” จะพังทลายลงทันทีเมื่อคุณพยายามรัน AI agent บน AWS Lambda ในทางปฏิบัติ รายการค่าใช้จ่ายที่ใหญ่ที่สุดไม่ใช่ค่า compute ของ Lambda แต่เป็น latency จาก cold-start, loop การ retry และการใช้งาน token ที่เกิดขึ้นจาก loop เหล่านั้น

ทำไมภาพจำแบบ serverless ทั่วไปถึงทำให้เข้าใจผิดเมื่อใช้กับ AI agent

นักพัฒนาส่วนใหญ่ปฏิบัติกับ Lambda function เหมือนเป็น sandbox สำหรับการคำนวณเพียงอย่างเดียว: รักษา handler ให้ทำงานเร็ว, ตั้งค่าหน่วยความจำ (memory) ไว้ในระดับพอเหมาะ และคอยดูให้บิลค่าใช้จ่ายคงที่ ซึ่งวิธีนี้ใช้ได้กับ HTTP endpoints แบบง่ายๆ แต่สำหรับ agent ที่ต้องเรียกใช้ language model, ประเมินผลลัพธ์ และอาจต้อง retry วงจรการทำงานทั้งหมดนั้น ไม่ได้มีความสัมพันธ์แบบหนึ่งต่อหนึ่งกับการเรียกใช้งาน (invocation) ของ Lambda เพียงครั้งเดียว เวิร์กโฟลว์ภายในของ agent จะเพิ่มจำนวนการเรียกใช้ model ให้มากขึ้น และการเรียกใช้แต่ละครั้งที่เพิ่มขึ้นจะนำมาซึ่งต้นทุน token ที่อาจสูงกว่าค่า compute ไปมาก

Cold starts คือต้นทุนแฝงที่มองไม่เห็น

เมื่อ Lambda container ถูกจัดเตรียมขึ้นครั้งแรก มันจะต้องทำการ unpack deployment package ตัว agent ที่เรากำลังพูดถึงนี้มีการดึง library ของ Python ชุดใหญ่เข้ามาใช้ ดังนั้น image จึงอาจมีขนาดใหญ่ การตัดเครื่องมือที่ใช้เฉพาะตอนพัฒนาออก—เช่น library สำหรับ browser automation ที่ใช้เฉพาะตอนทดสอบในเครื่อง (local testing)—จะช่วยลดขนาด image ซึ่งจะช่วยลดเวลาในการ unpack ลงด้วย package ที่เล็กลงหมายความว่า function จะพร้อมรับ request ได้เร็วขึ้น ช่วยลดเวลาที่ต้องเสียไปกับการรอให้ container อุ่นขึ้น (warm up)

อีกปัจจัยหนึ่งคือตำแหน่งที่โค้ดสำหรับ initialization อาศัยอยู่ การสร้าง agent graph ในช่วงเวลา module import จะทำให้งานหนักๆ เกิดขึ้นเพียงครั้งเดียวต่อการเริ่ม container หนึ่งครั้ง แทนที่จะเกิดขึ้นในทุกๆ request ซึ่งการเรียกใช้งานแบบ warm invocation จะข้ามขั้นตอนนั้นไปได้เลย ข้อแลกเปลี่ยนคือ cold start อาจจะนานขึ้นเล็กน้อย แต่ผลตอบแทนที่ได้คือเวลาในการ setup ต่อ request จะเกือบเป็นศูนย์หลังจากที่ container อุ่นแล้ว

หน่วยความจำ (Memory) ทำหน้าที่เป็นตัวปรับ latency

บน Lambda ปริมาณหน่วยความจำที่คุณจัดสรรให้ยังเป็นตัวกำหนดสัดส่วนของ CPU ที่ function จะได้รับ การตั้งค่า function ให้มีหน่วยความจำ 1 GB จะทำให้ได้รับ virtual CPU core แบบเต็มประสิทธิภาพ CPU ที่เพิ่มขึ้นจะช่วยเร่งการ import library และการสร้าง agent graph ซึ่งช่วยลดทั้ง latency ของ cold-start และการ warm-up

ต้นทุนจาก loop: การ retry จะทำให้การใช้ token เพิ่มขึ้นเป็นทวีคูณ

Agent จะทำงานตาม loop แบบ worker-evaluator โดย worker จะสร้างคำตอบ, evaluator จะตรวจสอบคำตอบนั้น และหาก evaluator พบข้อผิดพลาด งานจะถูกส่งกลับไปยัง worker อีกครั้ง loop นี้สามารถทำซ้ำได้สูงสุดถึงห้าครั้งก่อนที่จะยอมแพ้ นั่นหมายความว่าการ request จากภายนอกเพียงครั้งเดียวอาจกระตุ้นให้เกิด:

  • การเรียกใช้ worker model สูงสุดถึงห้าครั้ง
  • การเรียกใช้ evaluator model สูงสุดถึงห้าครั้ง
  • การเรียกใช้ tool ต่างๆ ตามที่ agent ตัดสินใจทำ

บิลค่าใช้จ่ายของ Lambda นั้นคาดเดาได้เพราะ AWS คิดเงินตามมิลลิวินาทีของการทำงาน แต่บิลค่า token อาจผันผวนอย่างรุนแรงขึ้นอยู่กับจำนวนครั้งที่ต้อง retry

กับดัก timeout: API Gateway vs. Lambda

API Gateway มีการกำหนด timeout ที่ตายตัวที่ 29 วินาทีสำหรับ HTTP request ที่มันดูแลอยู่ loop ของ agent ที่มีการทำงานห้าขั้นตอนสามารถเกินขีดจำกัดนั้นได้อย่างง่ายดาย แม้ว่า Lambda function เบื้องหลังจะถูกตั้งค่าให้ทำงานได้นานถึงห้านาทีก็ตาม การเลี่ยงไปใช้ Lambda Function URLs แทน API Gateway จะช่วยขจัดเพดาน 29 วินาทีนี้ออกไป ทำให้ function สามารถทำงานใน loop ให้เสร็จสิ้นได้โดยไม่ถูกตัดการเชื่อมต่อ

สิ่งที่นักพัฒนาควรวางแผนงบประมาณ

บทเรียนนี้เรียบง่ายมาก: การวางงบประมาณสำหรับ serverless AI agent ต้องทำมากกว่าแค่การรวมจำนวนมิลลิวินาทีของ Lambda runtime คุณจำเป็นต้องคำนึงถึง:

  • ขนาดของ deployment package และ latency จาก cold-start ที่ตามมา
  • การตั้งค่าหน่วยความจำ (memory) ซึ่งเป็นตัวกำหนด CPU และความเร็วในการ import
  • จำนวนการ retry ที่คาดว่าจะเกิดขึ้นใน worker-evaluator loop ซึ่งส่งผลโดยตรงต่อการใช้งาน token
  • การเลือก front-end (API Gateway vs. Function URL) เพื่อหลีกเลี่ยงการเกิด timeout ก่อนเวลาอันควร

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