หากคุณรันเวิร์กโหลดระดับโปรดักชันบน Large Language Models (LLM) คุณคงทราบดีว่าประสิทธิภาพของโมเดลเป็นเพียงครึ่งหนึ่งของการต่อสู้เท่านั้น อีกครึ่งหนึ่งคือบิลค่าใช้จ่ายตอนสิ้นเดือน ผู้ให้บริการสามราย ได้แก่ Mancer 2, Novita และ StreamLake เพิ่งมีการปรับราคาโมเดลเมื่อเร็วๆ นี้ หากคุณใช้งาน API เหล่านี้ ใบแจ้งหนี้ครั้งต่อไปของคุณอาจดูแตกต่างไปจากครั้งก่อน
เรื่องนี้ไม่ใช่เรื่องแปลกอีกต่อไป ตลาด LLM ยังคงอยู่ในช่วงทดลองวิธีการคิดค่าบริการสำหรับการทำ inference ผู้ให้บริการบางรายคิดเงินตามจำนวน tokens ต่อพันหน่วย บางรายจัดกลุ่มคำขอ (requests) เป็นระดับ (tiers) หรือเสนอส่วนลดสำหรับการใช้งานต่อเนื่อง เมื่อแพลตฟอร์มใดแพลตฟอร์มหนึ่งเปลี่ยนราคาต่อหน่วยหรือปรับโครงสร้างระดับการใช้งาน ผลกระทบต่องบประมาณของคุณอาจมีตั้งแต่ความรำคาญเล็กน้อยไปจนถึงงบประมาณบานปลายอย่างรุนแรง การติดตามการอัปเดตเหล่านี้ไม่ใช่ทางเลือก แต่มันคือส่วนหนึ่งของงาน
ทำไมราคา API ถึงเป็นเรื่องที่คุณต้องให้ความสำคัญ
นักพัฒนามักมองว่าราคา API เป็นรายการที่ "ตั้งค่าแล้วลืมไปได้เลย" คุณทำการทดสอบประสิทธิภาพ (benchmark) ของโมเดล เลือกผู้ให้บริการ แล้วก็ไปโฟกัสกับการสร้างฟีเจอร์ ซึ่งมันใช้ได้ผลจนกระทั่งมันใช้ไม่ได้ ในสภาพแวดล้อมปัจจุบัน การเปลี่ยนแปลงราคาอาจเกิดขึ้นได้โดยไม่มีการประกาศล่วงหน้าอย่างเป็นทางการ ผู้ให้บริการอาจลดราคาโมเดลรุ่นเก่าลงในขณะที่ขึ้นราคา endpoint รุ่นใหม่ หรือบางรายอาจเริ่มเก็บค่าธรรมเนียมเพิ่มเติมสำหรับ output tokens ที่ไม่เคยมีในไตรมาสก่อน หากคุณไม่เฝ้าสังเกต คุณจะรู้ตัวก็ต่อเมื่อใบแจ้งหนี้ค่าคลาวด์ส่งมาถึงเท่านั้น
ความละเอียดในการเรียกเก็บเงินของ LLM ทำให้เรื่องนี้ซับซ้อนเป็นพิเศษ คุณแทบจะไม่เคยจ่ายในราคาเหมาจ่ายรายเดือน แต่คุณต้องจ่ายสำหรับทุกๆ prompt token และทุกๆ completion token การขึ้นราคาในฝั่ง output อาจส่งผลกระทบมากกว่าฝั่ง input เพราะ completion มักจะยาวกว่า prompt หากแอปพลิเคชันของคุณสร้างข้อความขนาดยาว โค้ด หรือลำดับการใช้เหตุผลแบบหลายขั้นตอน (multi-step reasoning chains) การเพิ่มขึ้นเพียงเล็กน้อยต่อ token จะขยายตัวอย่างรวดเร็ว
นอกจากนี้ยังมีปัญหาเรื่อง drift หรือการเปลี่ยนแปลงตามกาลเวลา โปรไฟล์การใช้ token ของแอปพลิเคชันคุณจะเปลี่ยนไปเมื่อเวลาผ่านไป คุณอาจเพิ่ม system prompt ใหม่ที่กิน input tokens มากขึ้น หรือคุณอาจเปลี่ยนไปใช้การเขียน prompt แบบ chain-of-thought ที่ให้ output ยาวขึ้น แม้ว่าราคาของผู้ให้บริการจะคงที่ แต่ต้นทุนของคุณก็จะเปลี่ยนไป และเมื่อราคาของผู้ให้บริการขยับขึ้นพร้อมๆ กัน ผลกระทบที่รวมกันอาจทำให้ทีมที่ไม่มีการตรวจสอบข้อมูลอย่างใกล้ชิดต้องตกใจโดยไม่ทันตั้งตัว
มีอะไรเปลี่ยนแปลงไปบ้าง
Mancer 2, Novita และ StreamLake ต่างก็ได้เริ่มปรับราคาแล้ว รายละเอียดจะแตกต่างกันไปตามแต่ละแพลตฟอร์ม แต่ทิศทางนั้นเหมือนกัน นั่นคือ โครงสร้างต้นทุนที่คุณใช้เมื่อเดือนที่แล้วอาจไม่ใช่โครงสร้างที่ใช้ในตอนนี้
Mancer 2 ได้อัปเดตราคาโมเดล ซึ่งหมายความว่านักพัฒนาที่ใช้งาน endpoint ของเขาจำเป็นต้องประเมินต้นทุนต่อคำขอ (per-request costs) ใหม่ หากคุณเก็บข้อมูลราคาเก่าไว้ในเอกสารภายใน ข้อมูลเหล่านั้นก็ล้าสมัยไปแล้ว
Novita ก็ได้มีการปรับราคาในบริการต่างๆ ของตนเช่นกัน สำหรับทีมที่เลือก Novita เพราะมันอยู่ในงบประมาณที่กำหนดไว้ อัตราใหม่นี้อาจเปลี่ยนต้นทุนรวมในการเป็นเจ้าของ (total cost of ownership) สำหรับโครงการที่กำลังดำเนินอยู่
StreamLake ก็มีการปรับเปลี่ยนราคาเช่นกัน การเชื่อมต่อ (integration) ใดๆ ที่สร้างขึ้นตามอัตราค่าบริการเดิมของ StreamLake ควรได้รับการตรวจสอบก่อนที่จะเริ่มรอบการเรียกเก็บเงินถัดไป
เนื่องจากทั้งสามเป็นแพลตฟอร์มที่แตกต่างกันและมีโมเดลการคิดราคาที่ต่างกัน จึงไม่มีกฎตายตัวว่าคุณจะจ่ายมากขึ้นหรือน้อยลง ผู้ให้บริการรายหนึ่งอาจลดราคาในระดับเริ่มต้น (starter-tier) แต่ไปเพิ่มราคาสำหรับ throughput ระดับพรีเมียม อีกรายอาจปรับราคาพิเศษสำหรับ context-window ข้อสันนิษฐานเดียวที่ปลอดภัยคือ ตารางคำนวณ (spreadsheet) เก่าของคุณนั้นผิดแล้ว
ต้นทุนแฝงจากการเพิกเฉยต่อการเปลี่ยนแปลงราคา
ลองมาดูความหมายในทางปฏิบัติกัน สมมติว่าคุณรันผู้ช่วยสนับสนุนลูกค้าที่จัดการการสนทนาหนึ่งหมื่นครั้งต่อวัน แต่ละการโต้ตอบมีค่าเฉลี่ยอยู่ที่ 2,000 input tokens และ 400 output tokens การเปลี่ยนแปลงเพียงไม่กี่เซนต์ต่อหนึ่งล้าน tokens สามารถสะสมเป็นเงินหลายร้อยดอลลาร์ต่อเดือน หากการเปลี่ยนแปลงราคาส่งผลต่อ output tokens และผู้ช่วยของคุณเริ่มสร้างคำตอบที่ยาวขึ้นเนื่องจากคุณอัปเกรดโมเดล คุณก็จะโดนผลกระทบถึงสองเด้ง
นอกจากนี้ยังมีผลกระทบแบบทวีคูณ (multiplier effect) แอปพลิเคชันจำนวนมากไม่ได้เรียกใช้ LLM เพียงครั้งเดียวต่อหนึ่งคำขอของผู้ใช้ แต่เรียกใช้ในรูปแบบลูป (loop) หรือในไปป์ไลน์ (pipeline) ที่มีขั้นตอนการดึงข้อมูล (retrieval steps) หรือมีการใช้โมเดลสำรอง (fallbacks) การเปลี่ยนแปลงราคาของโมเดลสำรองอาจดูเหมือนไม่เร่งด่วน จนกระทั่งโมเดลหลักของคุณติดขัดเรื่องขีดจำกัดอัตราการใช้งาน (rate limit) และคุณต้องใช้โมเดลสำรองที่มีราคาแพงกว่าในช่วงที่เกิดปัญหา
งบประมาณบานปลายไม่ใช่ความเสี่ยงเพียงอย่างเดียว หากราคาลดลงแล้วคุณไม่สังเกตเห็น คุณอาจกำลังจำกัดการใช้งาน (throttling) โดยไม่จำเป็น คุณอาจจะสามารถให้บริการผู้ใช้ได้มากขึ้น ประมวลผลเอกสารที่ใหญ่ขึ้น หรือลดราคาให้กับลูกค้าของคุณเองได้ ความไม่รู้ส่งผลเสียได้ทั้งสองทาง
วิธีสร้างนิสัยในการติดตามค่าใช้จ่าย
คุณไม่จำเป็นต้องมีทีมการเงินระดับองค์กรเพื่อควบคุมเรื่องนี้ สิ่งที่คุณต้องการคือกิจวัตรและสถานที่สำหรับบันทึกการเปลี่ยนแปลง
เริ่มต้นด้วยการรวบรวม rate cards ของคุณไว้ที่ศูนย์กลาง ไม่ว่าจะเป็นหน้า wiki ที่ใช้ร่วมกัน, ตารางใน Notion หรือข้อความที่ปักหมุดไว้ในช่อง dev ของคุณ โดยให้ระบุราคาปัจจุบันต่อ token หรือต่อ request สำหรับทุกโมเดลที่คุณใช้งาน เมื่อผู้ให้บริการประกาศการเปลี่ยนแปลง ให้รีบอัปเดตเอกสารทันที อย่ารอจนถึงการทำ sprint review
ถัดมา ให้ติดแท็ก (tag) การใช้งานของคุณตามผู้ให้บริการและตามโมเดล เครื่องมือ observability ส่วนใหญ่ช่วยให้คุณแนบ metadata แบบกำหนดเองไปกับ API calls ได้ ให้ใช้แท็กเหล่านั้นเพื่อสร้างสรุปค่าใช้จ่ายรายสัปดาห์ หากคุณเห็นค่าใช้จ่ายพุ่งสูงขึ้น คุณจะสามารถตรวจสอบได้ทันทีภายในไม่กี่วินาทีว่าเกิดจากการใช้งานที่เพิ่มขึ้นหรือการเปลี่ยนอัตราค่าบริการ ไม่ใช่ต้องรอเป็นวันๆ
สร้างการแจ้งเตือน burn-rate (อัตราการใช้จ่าย) ซึ่งไม่จำเป็นต้องซับซ้อน เพียงแค่สคริปต์ที่ตั้งเวลาไว้เพื่อดึงข้อมูลจาก usage dashboard แล้วโพสต์ตัวเลขลงใน Slack ทุกเช้าก็เพียงพอแล้ว เมื่อตัวเลขพุ่งสูงขึ้น คุณจะทราบได้ภายในวันเดียวกัน ไม่ใช่ต้องมารู้หลังจากนั้น 30 วันเมื่อฝ่ายการเงินส่งอีเมลมาตำหนิ
ทบทวนการเลือกโมเดลของคุณทุกไตรมาส โมเดลที่ดีที่สุดสำหรับกรณีการใช้งานของคุณในเดือนมกราคม อาจไม่ใช่โมเดลที่ดีที่สุดในเดือนมิถุนายน ไม่ใช่เพราะโมเดลแย่ลง แต่เป็นเพราะสถานการณ์ด้านราคาเปลี่ยนไป ผู้ให้บริการที่เคยแพงเกินไปอาจลดราคาลง ส่วนตัวเลือกราคาถูกที่คุณชอบอาจปรับราคาขึ้น ให้ทำการทดสอบ benchmark ใหม่โดยอิงจากราคาปัจจุบัน ไม่ใช่ราคาในอดีต
สุดท้าย ให้คำนึงถึงเรื่องราคาในการตัดสินใจด้านสถาปัตยกรรม (architecture) หากคุณทราบว่าผู้ให้บริการมีการเปลี่ยนอัตราค่าบริการบ่อยครั้ง ให้คุณออกแบบระบบเพื่อให้สามารถสลับ endpoint ได้โดยไม่ต้องเขียน codebase ใหม่ครึ่งหนึ่ง สร้าง abstraction ให้กับ client ผ่าน internal interface และเก็บชื่อโมเดลไว้ในไฟล์ configuration แทนที่จะ hard-code ไว้ใน prompt layer
จะติดตามข้อมูลอัปเดตที่เชื่อถือได้จากที่ไหน
บล็อกและเอกสารของผู้ให้บริการคือแหล่งข้อมูลอย่างเป็นทางการ แต่ก็อาจพลาดได้ง่ายในช่วงสัปดาห์ที่งานยุ่ง ทางเลือกหนึ่งคือการติดตามการรวบรวมข้อมูล (curated roundups) ที่คอยติดตามการเปลี่ยนแปลงลักษณะนี้ทั่วทั้งระบบนิเวศ สำหรับรายละเอียดการปรับเปลี่ยนของ Mancer 2, Novita และ StreamLake เมื่อเร็วๆ นี้ สามารถดูสรุปโดยละเอียดได้ที่นี่:
การเปลี่ยนแปลงราคา LLM: Mancer 2, Novita และ StreamLake
หากคุณต้องการติดตามข่าวสารและแลกเปลี่ยนข้อมูลกับนักพัฒนาคนอื่นๆ ที่พยายามควบคุมค่าใช้จ่ายโครงสร้างพื้นฐาน AI ให้สมเหตุสมผล ก็ยังมีชุมชนที่น่าเข้าร่วม:
การป้องกันที่ดีที่สุดต่อบิลค่าใช้จ่ายที่น่าตกใจ คือเครือข่ายของผู้คนที่คอยแจ้งเตือนการเปลี่ยนแปลงทันทีที่เกิดขึ้น
บทสรุปที่สำคัญ
ความผันผวนของราคาคือคุณลักษณะของตลาด LLM ในปัจจุบัน ไม่ใช่ข้อผิดพลาด โมเดลมีราคาถูกลงในการใช้งาน ผู้ให้บริการทดลองโครงสร้างราคาใหม่ๆ และการแข่งขันก็ทำให้ตัวเลขต่างๆ เปลี่ยนแปลงไป นั่นเป็นข่าวดีในระยะยาว แต่ต้องอยู่ภายใต้เงื่อนไขว่าคุณต้องคอยสังเกตด้วย จงจัดการกับค่าใช้จ่าย API เหมือนที่คุณจัดการกับตัวชี้วัด uptime: วัดผล, ตั้งการแจ้งเตือน และตรวจสอบพวกมันอย่างสม่ำเสมอ การเปลี่ยนแปลงล่าสุดจาก Mancer 2, Novita และ StreamLake เป็นเพียงเครื่องเตือนใจล่าสุดว่า ราคาของ AI stack ของคุณไม่มีวันคงที่อย่างแท้จริง