Microsoft ได้เพิ่ม AI Gateway tier โดยเฉพาะให้กับ Azure API Management (APIM) การเคลื่อนไหวครั้งนี้ส่งสัญญาณว่าการเรียกใช้งาน LLM จะถูกปฏิบัติในฐานะเวิร์กโหลด (workload) ที่แยกต่างหาก ไม่ใช่แค่ API endpoint ทั่วไปอีกต่อไป
ทำไมทราฟฟิก LLM ถึงทำให้เกตเวย์แบบดั้งเดิมใช้งานไม่ได้ผล
พรอมต์ (prompt) เพียงหนึ่งครั้งอาจมีค่าใช้จ่ายมากกว่าอีกครั้งถึงหนึ่งร้อยเท่า แต่ API gateway มาตรฐานจะมองว่าทั้งคู่คือหนึ่งคำขอ (request) เหมือนกัน เกตเวย์จะนับจำนวนการเรียกใช้งาน (calls) ไม่ใช่จำนวนโทเคน (tokens) ที่โมเดลประมวลผล คำขอที่ส่งโทเคนเพียงไม่กี่ร้อยโทเคนกับคำขอที่ส่งโทเคนหลายพันโทเคนจะให้ตัวชี้วัดจำนวนคำขอ (request-count metrics) ที่เหมือนกัน ทั้งที่คำขอหลังอาจมีค่าใช้จ่ายสูงกว่าหลายเท่าตัว
ข้อเท็จจริง 4 ประการที่ทำให้การจำกัดจำนวนคำขอ (request-based limits) ไร้ประโยชน์สำหรับ AI:
- ค่าใช้จ่าย ≠ จำนวนคำขอ การเรียกเก็บเงินผูกติดกับโทเคน ไม่ใช่จำนวนการเรียก HTTP ที่คุณทำ
- ปริมาณโทเคนมีความผันผวนสูง คิวรี (query) หนึ่งอาจเป็นคำถามสั้นๆ แต่อีกคิวรีหนึ่งอาจรวมถึงเอกสารขนาดยาว
- การเลือกโมเดลส่งผลต่อราคา LLM แต่ละตัวมีอัตราค่าบริการต่อโทเคนต่างกัน
- การสตรีม (Streaming) ทำให้ไม่เห็นบิลสุดท้าย เมื่อมีการสตรีมคำตอบ จำนวนโทเคนทั้งหมดจะไม่ทราบจนกว่าการสตรีมจะสิ้นสุดลง
หากคุณยังคงวัดผลแค่จำนวนคำขอ คุณจะได้ข้อมูลการตรวจสอบ (monitoring data) ที่ไม่ได้บอกอะไรเลยเกี่ยวกับค่าใช้จ่ายที่เกิดขึ้นจริง
สิ่งที่ AI Gateway tier เปลี่ยนแปลง
นโยบาย (policies) ส่วนใหญ่ที่จำเป็นในการควบคุมการใช้งานโทเคนนั้นมีอยู่แล้วใน APIM tier มาตรฐาน โดยเขียนอยู่ในรูปแบบกฎ XML และแสดงผลบนแดชบอร์ดที่ปรับแต่งเอง แต่ AI tier ได้รวบรวมความสามารถเหล่านั้นเข้าด้วยกันเป็นประสบการณ์ที่สร้างขึ้นมาเพื่อวัตถุประสงค์นี้โดยเฉพาะ:
- การแยกส่วนการขยายขนาด (Isolation of scaling) สำหรับทราฟฟิก AI
- การกำหนดค่าที่ง่ายขึ้น (Simplified configuration) ซึ่งช่วยลดความจำเป็นในการเขียนนโยบาย XML ด้วยตัวเอง
การเปลี่ยนแปลงหลักคือในเชิงปฏิบัติการ: คุณไม่จำเป็นต้องเขียนโค้ดที่ซับซ้อนหรือดูแลแดชบอร์ดแยกต่างหากเพื่อควบคุมงบประมาณโทเคนอีกต่อไป โดย tier นี้มีอินเทอร์เฟซที่พร้อมใช้งานสำหรับการควบคุมเหล่านั้น
เมื่อไหร่ควรเปลี่ยน – คู่มือตามลักษณะทราฟฟิก
- AI เป็นเพียงส่วนน้อยของทราฟฟิกของคุณ ให้ใช้ APIM tier เดิมต่อไป และเพิ่มนโยบายโทเคนหากคุณต้องการการควบคุมที่ละเอียด
- AI เป็นส่วนใหญ่ของการเรียกใช้งานของคุณ เปลี่ยนไปใช้ AI tier เพื่อแยกส่วนการขยายขนาดและรักษาการกำกับดูแลค่าใช้จ่ายให้เป็นระเบียบ
- คุณต้องการหลีกเลี่ยงภาระงานด้านวิศวกรรม (engineering overhead) เครื่องมือที่มีมาให้ใน tier นี้จะช่วยลดเวลาที่ต้องใช้ในการสร้างและดูแลนโยบายที่ปรับแต่งเอง
ค่าใช้จ่ายที่สูงที่สุดไม่ใช่ราคาค่าสมัครสมาชิก แต่คือชั่วโมงการทำงานของวิศวกรที่ต้องใช้ในการอุดช่องว่างของเกตเวย์ทั่วไปเพื่อให้มันเข้าใจเรื่องเศรษฐศาสตร์ของโทเคน (token economics)
แผนการดำเนินงานในช่วง Preview
Microsoft ยังคงเปิดให้ใช้งาน AI tier ในช่วง preview ดังนั้นควรใช้เป็นพื้นที่ทดสอบ (testbed) ไม่ใช่สำหรับการใช้งานจริง (production launch)
- เลือกเวิร์กโหลด AI ภายในที่มีปริมาณสูง เลือกบริการที่สร้างทราฟฟิกโทเคนมากที่สุด
- กำหนดเส้นทางเวิร์กโหลดนั้นผ่าน AI tier ใช้การกำหนดค่าใหม่เพื่อบันทึกการใช้งานโทเคนต่อผู้ใช้งาน (consumer)
- เก็บข้อมูลการใช้จ่ายโทเคนเป็นเวลาสองสามสัปดาห์ เปรียบเทียบจำนวนโทเคนและค่าใช้จ่ายที่เกี่ยวข้องกับการตรวจสอบที่มีอยู่เดิม
- ใช้ข้อมูลพื้นฐาน (baseline) เพื่อประกอบการวางงบประมาณ ตัดสินใจว่าประโยชน์ในการควบคุมต้นทุนของ tier นี้คุ้มค่ากับข้อจำกัดในช่วง preview หรือไม่
อย่าเพิ่งย้ายเวิร์กโหลดที่สำคัญต่อธุรกิจ (mission-critical) ไปยังบริการในช่วง preview จนกว่าจะเปิดใช้งานทั่วไป (general availability)
มุมมองต่าง: ไม่ใช่ทุกคนที่ต้องการ tier แยกต่างหาก
หากองค์กรของคุณมีการเรียกใช้งาน LLM เพียงเป็นครั้งคราว ค่าใช้จ่ายเพิ่มเติมของ AI tier อาจไม่คุ้มค่า คุณสามารถควบคุมในระดับโทเคนได้ด้วยโครงสร้างนโยบายที่มีอยู่ แม้จะต้องใช้ความพยายามในการจัดการด้วยตนเองมากขึ้นก็ตาม AI tier จะโดดเด่นก็ต่อเมื่อทราฟฟิก AI เป็นส่วนสำคัญและกำลังเติบโตใน API surface ของคุณ
บทสรุป
AI Gateway tier เป็นการยอมรับว่าทราฟฟิก LLM มีพฤติกรรมที่แตกต่างจากคำขอ API แบบดั้งเดิมอย่างสิ้นเชิง การเปลี่ยนจากการนับจำนวนคำขอมาเป็นการกำกับดูแลตามโทเคน ช่วยให้นักพัฒนาสามารถควบคุมค่าใช้จ่าย AI ได้อย่างมีประสิทธิภาพโดยไม่ต้องจมอยู่กับโค้ดที่เขียนขึ้นเอง สำหรับทีมที่มีการใช้งาน AI ในปริมาณมากอยู่แล้ว หรือคาดว่าจะเติบโตขึ้น การทดสอบในช่วง preview ตั้งแต่ตอนนี้จะช่วยสร้างข้อมูลพื้นฐาน (baseline) ของการใช้จ่ายโทเคนได้