ทำไมค่าใช้จ่ายถึงพุ่งสูงขึ้นอย่างรวดเร็ว
เมื่อทีมเริ่มนำ generative AI มาใช้ครั้งแรก พวกเขาส่งทุกคำขอของผู้ใช้ไปยังโมเดลที่ใหม่ที่สุดและมีความสามารถสูงสุด เมื่อปริมาณการใช้งานเพิ่มขึ้น ต้นทุนต่อคำขอก็เพิ่มขึ้นตามกันไป และสเปรดชีตของ CFO ก็แสดงให้เห็นว่าค่าใช้จ่ายพุ่งสูงเกินกว่าอัตราการเติบโตของผู้ใช้ วิธีแก้ปัญหาแบบเร่งด่วนที่มักใช้กันอย่าง "แค่ใช้โมเดลที่ถูกกว่า" นั้นใช้ไม่ได้ผลในระบบโปรดักชัน เพราะคำถามที่แตกต่างกันต้องการระดับการใช้เหตุผลที่ต่างกัน กลไกสำคัญที่แท้จริงคือ วิธีการ ส่งคำขอ ไม่ใช่การเลือกใช้โมเดล ตัวใดตัวหนึ่ง ตลอดเวลา
การสร้างเลเยอร์การจัดเส้นทาง (routing layer) เพื่อประหยัดค่าใช้จ่าย
วิศวกรจัดการกับบริการ inference เหมือนกับส่วนประกอบโปรดักชันอื่นๆ นั่นคือการกำหนดระดับ (tiers), ตั้งค่า SLA และควบคุมงบประมาณด้านความหน่วง (latency budgets) สถาปัตยกรรมที่ได้ประกอบด้วย 4 ส่วนสำคัญที่ทำงานร่วมกันจนสามารถลดค่าใช้จ่ายลงได้ถึง 95%
การจัดเส้นทางแบบแบ่งระดับ (Tiered routing)
ส่วนหน้า (front-end) ขนาดเล็กจะจำแนกแต่ละคำขอที่เข้ามาตามระดับความยาก ประมาณ 95% ของคำถามจะตกอยู่ในระดับ "ราคาถูก" (cheap tier) ซึ่งใช้โมเดลขนาดกลาง ส่วนเพียง 5% ที่ยากที่สุดเท่านั้นที่จะถูกส่งต่อไปยังโมเดลระดับพรีเมียม (premium model) การจำแนกนี้สามารถใช้กฎเป็นเกณฑ์ (เช่น ความยาว, การมีคำสำคัญเฉพาะทาง) หรือเรียนรู้จากข้อมูลการส่งต่อในอดีต ด้วยการตั้งค่าเริ่มต้นให้เป็นระดับราคาต่ำ ค่าใช้จ่ายรายเดือนของแชทบอทจึงลดลงจาก $420 เหลือเพียง $28
การเลือกขนาดโมเดลให้เหมาะสม (Model right-sizing)
การจับคู่ความสามารถของโมเดลให้เข้ากับความซับซ้อนของงานช่วยประหยัดได้มากที่สุด:
- แชททั่วไป (Simple chat) – ใช้โมเดลขนาดเล็ก (lightweight model) แทนโมเดลตัวหลัก (flagship) (ประหยัดได้ 97.5%)
- การจำแนกประเภท (Classification) – เปลี่ยนจากโมเดลขนาดกลางเป็นทางเลือกที่ถูกกว่า (ประหยัดได้ 98.3%)
- การสรุปความ (Summarization) – เปลี่ยนจากโมเดลระดับสูงสุดเป็นโมเดลระดับกลาง (ประหยัดได้ 97.2%)
ชื่อโมเดลที่แน่นอนไม่ใช่เรื่องสำคัญ หลักการคือการสำรองโมเดลที่มีความสามารถสูงสุดไว้สำหรับคำถามเพียงไม่กี่ข้อที่จำเป็นต้องใช้จริงๆ เท่านั้น
การทำแคชอัจฉริยะ (Smart caching)
ทุกครั้งที่มีการดึงข้อมูลจากแคช (cache hit) จะช่วยลดการเรียกใช้งานเครือข่ายและค่าธรรมเนียม API Redis cache แบบกระจายตัวจะจัดเก็บทั้งคำตอบที่สำเร็จและคำตอบแบบ "ปฏิเสธ" (เช่น "ฉันไม่ทราบ") เมื่อคำถามเดิมที่ตอบไม่ได้ปรากฏขึ้นอีกครั้ง ระบบจะส่งคำตอบ "ฉันไม่ทราบ" จากแคชกลับไป แทนที่จะเรียกใช้งานโมเดลเป็นครั้งที่สอง เมื่อผ่านคำขอหลายพันรายการ เพียงแค่วิธีนี้อย่างเดียวก็สามารถลดค่าใช้จ่ายลงได้อย่างเห็นได้ชัด
การบีบอัดพรอมต์ (Prompt compression)
พรอมต์ที่ยาวทำให้มีการใช้ token มากขึ้น ซึ่งส่งผลโดยตรงต่อต้นทุน ทีมงานใช้ตัวสรุปความราคาถูกที่ฝั่งไคลเอนต์หรือในขั้นตอนการประมวลผลล่วงหน้า (pre-processing) เพื่อย่อบริบทจาก 2,000 token ให้เหลือประมาณ 400 token ก่อนจะส่งไปยังโมเดลที่มีราคาแพง การลดจำนวน token นี้จะทวีคูณขึ้นในทุกๆ คำขอ ช่วยให้ประหยัดได้อย่างมหาศาลโดยไม่กระทบต่อประสบการณ์ของผู้ใช้งานปลายทาง
การทำ Batching เชิงกลยุทธ์ (Strategic batching)
การทำ Batching คือการรวมคำขอที่เป็นอิสระต่อกันหลายๆ คำขอเข้าด้วยกันในการเรียก API เพียงครั้งเดียว หลักการง่ายๆ คือ: หากผู้ใช้กำลังรอคำตอบ ห้ามทำ batching; แต่หากคำขอนั้นทำงานเบื้องหลัง (เช่น รายงานประจำคืน, งานที่ตั้งเวลาไว้) ให้ทำ batching ทุกอย่าง เฉพาะงาน batch ในช่วงกลางคืนเพียงอย่างเดียวก็ช่วยลดค่าใช้จ่ายลงได้อีก 10-20%
การตรวจสอบลูปการเพิ่มประสิทธิภาพ (Monitoring the optimization loop)
คุณไม่สามารถปรับปรุงสิ่งที่คุณไม่ได้วัดผลได้ วิศวกรได้ตั้งค่าตัวชี้วัดรายสัปดาห์ 4 รายการ:
- ต้นทุนต่อคำขอ โดยแบ่งตามระดับ (tier)
- อัตราการดึงข้อมูลจากแคช (cache-hit rate) สำหรับแต่ละเส้นทางการจัดเส้นทาง
- อัตราการส่งต่อ (escalation rate) จากระดับราคาถูกไปยังระดับพรีเมียม
- ค่าใช้จ่ายต่อกลุ่มลูกค้า
ตัวเลขเหล่านี้จะช่วยให้เห็นความผิดปกติ (drift) เช่น อัตราการส่งต่อที่เพิ่มขึ้นอาจเป็นสัญญาณว่าตรรกะการจำแนกประเภทนั้นเข้มงวดเกินไป หรือคุณภาพของโมเดลราคาถูกลดลง ทีมงานจะปรับปรุงเกณฑ์ (thresholds), การกำหนดโมเดล และนโยบายแคชในทุกสัปดาห์ เปลี่ยนการควบคุมต้นทุนให้กลายเป็นนิสัยมากกว่าจะเป็นเพียงการแก้ปัญหาเฉพาะหน้าเมื่อเกิดวิกฤต
บทสรุป (Takeaway)
เลเยอร์การจัดเส้นทางที่มีระเบียบวินัย ซึ่งทำหน้าที่จำแนกคำขอ, เลือกขนาดโมเดลให้เหมาะสม, ทำแคชอย่างจริงจัง, บีบอัดพรอมต์ และทำ batching งานเบื้องหลัง สามารถลดค่าใช้จ่าย AI-API ได้สูงสุดถึง 95% ในขณะที่ยังคงความน่าเชื่อถือไว้ในระดับสูง จงปฏิบัติกับ inference stack เหมือนเป็นบริการโปรดักชัน: กำหนดระดับ, วัดผลลัพธ์ และปรับปรุงทุกสัปดาห์