สำหรับองค์กรที่ใช้งาน LLM API ในหลายแผนก เนื่องจากปริมาณการใช้งานของแต่ละแผนกมีความแตกต่างกัน จึงจำเป็นต้องมีกลไกในการจัดสรรงบประมาณอย่างเป็นธรรมโดยยังคงความโปร่งใสของต้นทุนเอาไว้ ไม่ใช่เรื่องแปลกที่จะพบกรณีที่บางแผนกมีการใช้งาน API เพิ่มขึ้นอย่างรวดเร็วจนส่งผลกระทบต่อภาพรวมงบประมาณของบริษัทในช่วงสิ้นไตรมาส ในทางกลับกัน บางแผนกที่ไม่มีการติดตามสถานะการใช้งานจริงอาจถูกปล่อยทิ้งไว้จนทำให้เกิดปัญหาในการชี้แจงข้อมูลเมื่อถึงช่วงจัดทำงบประมาณสำหรับปีถัดไป บทความนี้จะสรุปขั้นตอนที่ผู้ปฏิบัติงานสามารถนำไปใช้ได้ทันที ตั้งแต่แนวคิดการแบ่งสรรต้นทุนตามแผนก การออกแบบระบบ Chargeback การกำหนดเพดานการใช้งาน ไปจนถึงระบบการตรวจสอบรายเดือนและรายไตรมาส เพื่อเป็นแนวทางสำหรับฝ่ายการเงิน ฝ่ายวางแผน และผู้ดูแลระบบ IT ในการป้องกันความรู้สึกไม่เป็นธรรมระหว่างแผนกและผลักดันการเพิ่มประสิทธิภาพต้นทุนขององค์กร โดยจะเน้นรายละเอียดในส่วนของกฎการแบ่งสรรต้นทุนและการออกแบบระบบ Chargeback พร้อมตัวอย่างการคำนวณที่ชัดเจน และสรุปประเด็นสำคัญเชิงปฏิบัติสำหรับการวางระบบตรวจสอบให้กระชับที่สุด

ร่างใบเสนอราคาที่สร้างโดยฝ่ายขาย, การเติมโค้ดที่ฝ่ายพัฒนาทดลองใช้, การสร้างร่างคำโฆษณาของฝ่ายการตลาด—แม้จะเป็น LLM API ตัวเดียวกัน แต่ละแผนกกลับมีวิธีการใช้งานและความถี่ในการเรียกใช้งานที่แตกต่างกันอย่างสิ้นเชิง หากปล่อยให้ความแตกต่างนี้ดำเนินต่อไปโดยทำได้เพียงแค่นั่งมองรายงานที่ระบุว่า "ค่าใช้จ่าย API เดือนนี้สูงกว่าที่คาดการณ์ไว้ 3 เท่า" เราก็จะไม่มีทางมองเห็นเลยว่าควรจะแก้ไขที่จุดไหน

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

ความท้าทายในการบริหารจัดการต้นทุนการใช้ LLM API แยกตามแผนก

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

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

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

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

โดยทั่วไปแล้ว งบประมาณทั้งบริษัทจะถูกกำหนดโดยฝ่ายการเงินเป็นรายปีหรือรายไตรมาส โดยอ้างอิงจากแผนธุรกิจและผลการดำเนินงานของปีก่อนหน้า จากนั้นจึงจัดสรรลงไปยังแต่ละแผนกแบบบนลงล่าง (Top-down) อย่างไรก็ตาม การปรับจูนแบบล่างขึ้นบน (Bottom-up) โดยการรวบรวมสถานะการใช้งานจริงของแต่ละแผนกเพื่อทบทวนงบประมาณทั้งบริษัทนั้นเป็นสิ่งที่ขาดไม่ได้ ตัวเลขแบบบนลงล่างและผลการดำเนินงานแบบล่างขึ้นบนไม่ใช่สิ่งที่แยกจากกัน แต่จำเป็นต้องรักษาความสอดคล้องกันอยู่เสมอ

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

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

เมื่อมีการใช้งาน LLM API ร่วมกันในหลายแผนก มักมีหลายสถานการณ์ที่ทำให้ผู้รับผิดชอบต้องปวดหัวกับวิธีการจัดสรรต้นทุน การหารเฉลี่ยเท่าๆ กันแบบง่ายมักก่อให้เกิดความไม่พอใจระหว่างแผนกที่ใช้งานมากและแผนกที่ใช้งานน้อย ในทางกลับกัน หากพึ่งพาเพียงการจัดสรรตามปริมาณการใช้งานจริงอย่างเคร่งครัด ก็มักจะทำให้การจัดการส่วนที่เป็นต้นทุนคงที่ เช่น ค่าบำรุงรักษาโครงสร้างพื้นฐานส่วนกลางมีความคลุมเครือ โดยวิธีการจัดสรรสามารถแบ่งออกเป็น 3 รูปแบบหลัก ได้แก่ การจัดสรรตามปริมาณการใช้งานจริงโดยอิงจากจำนวน Token ที่ใช้หรือจำนวน API Call, การแยกต้นทุนคงที่และต้นทุนผันแปรโดยแยกค่าบำรุงรักษาโครงสร้างพื้นฐานออกจากส่วนที่ใช้งานจริง และการกำหนดสัดส่วนการจัดสรรหลังจากทำให้เห็นภาพรวมการใช้งานจริงของแต่ละแผนกผ่านเครื่องมือจัดการ Log ในบรรดาวิธีเหล่านี้ การจัดสรรตามปริมาณการใช้งานถือเป็นพื้นฐานที่หลีกเลี่ยงไม่ได้ในการดำเนินงาน ซึ่งจะกล่าวถึงอย่างละเอียดที่สุดในหัวข้อถัดไป ส่วนการแยกต้นทุนคงที่/ต้นทุนผันแปรและการใช้เครื่องมือสร้างภาพข้อมูล (Visualization) มักจะเป็นสิ่งที่ค่อยๆ ปรับปรุงในภายหลังตามระดับความพร้อมด้านธรรมาภิบาลขององค์กร

การจัดสรรค่าใช้จ่ายตามปริมาณการใช้งานจริงของแต่ละแผนกคือการปันส่วนตามปริมาณการใช้งาน (Usage-based allocation)

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

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

ในทางปฏิบัติ วิธีที่มักจะเป็นที่นิยมคือการดึงข้อมูลบันทึก (Log) ที่มีแท็กระบุแผนกจาก API วัดปริมาณการใช้งานที่ OpenAI หรือ Anthropic จัดเตรียมไว้ แล้วนำมาสรุปยอดรายเดือนโดยอิงตามจำนวน Token การกำหนด Project ID หรือแท็กไว้ใน Log จะช่วยให้การปันส่วนค่าใช้จ่ายสามารถทำได้โดยอัตโนมัติง่ายขึ้น

เกณฑ์การตัดสินใจพื้นฐานคือการจัดประเภทค่าใช้จ่ายตามลักษณะการใช้งาน หากเป็นการจองความจุตามช่วงเวลา เช่น Provisioned Throughput ให้ถือเป็นต้นทุนคงที่ (Fixed Cost) แต่หากเน้นไปที่ค่าธรรมเนียมการใช้งานโทเค็นแบบจ่ายตามจริง ให้ถือเป็นต้นทุนผันแปร (Variable Cost) ใน Azure OpenAI มีรูปแบบการเรียกเก็บเงิน 2 รูปแบบ ได้แก่ Pay-As-You-Go และ PTU (Provisioned Throughput Units) โดย PTU เป็นกลไกที่คิดค่าบริการเป็นรายชั่วโมง จึงทำให้เกิดค่าใช้จ่ายคงที่ในทุกเดือนโดยไม่ขึ้นอยู่กับปริมาณการใช้งานจริง ในทำนองเดียวกัน Scale Tier ของ OpenAI ก็เป็นรูปแบบการซื้อหน่วยโทเค็นสำหรับอินพุตและเอาต์พุตล่วงหน้าแบบรายวัน โดยมีเงื่อนไขขั้นต่ำในการซื้อที่ 30 วัน จึงมีลักษณะใกล้เคียงกับต้นทุนคงที่ในทางปฏิบัติ

ในทางกลับกัน ค่าธรรมเนียมการใช้งานที่เรียกเก็บตามจริงจากการเรียกใช้ API ปกติถือเป็นต้นทุนผันแปร ซึ่งจะเปลี่ยนแปลงไปตามจำนวนโทเค็นที่แต่ละแผนกใช้งาน ในทางปฏิบัติสำหรับการแยกค่าใช้จ่าย ขั้นแรกให้แยกแยะว่าสัญญาดังกล่าวเป็นการจองความจุ (Dedicated Throughput) หรือเป็นสัญญาแบบจ่ายตามจริงเท่านั้น สำหรับกรณีแรกควรจัดสรรงบประมาณให้กับแต่ละแผนกไว้ล่วงหน้า ส่วนกรณีหลังควรแบ่งตามสัดส่วนการใช้งานจริงในแต่ละเดือน สำหรับบริษัทที่ใช้รูปแบบสัญญาหลายประเภทควบคู่กัน การจัดสรรส่วนที่เป็นต้นทุนคงที่ให้เป็นค่าใช้จ่ายส่วนกลางแก่ทุกแผนกก่อน แล้วจึงแบ่งส่วนที่เป็นต้นทุนผันแปรตามปริมาณการใช้งานจริง จะช่วยให้เข้าใจโครงสร้างต้นทุนได้ง่ายขึ้น

การจัดสรรค่าใช้จ่ายตามแผนกจะไม่มีความหมายหากความละเอียดของข้อมูลต้นทางไม่เพียงพอ แม้ว่าสูตรการคำนวณจะถูกต้องก็ตาม สิ่งที่เป็นเงื่อนไขเบื้องต้นคือกลไกในการรวบรวมและแสดงผลข้อมูลการใช้งาน (Usage Log) อย่างต่อเนื่อง

ผู้ให้บริการหลักต่างมีกลไกที่รองรับการกำหนด "Department Tag" หรือ "Project ID" ทั้งสิ้น ไม่ว่าจะเป็น Usage API หรือ Costs endpoint ของ OpenAI, Cost and Usage Report ของ AWS (ที่ส่งออกไปยัง S3) หรือ Cost Management export ของ Azure (ที่เขียนข้อมูลลงใน Storage แบบรายวัน รายสัปดาห์ หรือรายเดือน) ซึ่งจุดนี้ถือเป็นกุญแจสำคัญในการปฏิบัติงานจริง

หากการติดแท็ก (Tagging) ไม่ละเอียดเพียงพอ ปริมาณการใช้งานของ API Key ที่ใช้ร่วมกันระหว่างหลายแผนกจะปะปนกัน ทำให้การคำนวณจัดสรรค่าใช้จ่ายไม่สามารถใช้งานได้จริง จึงควรออกแบบแท็กให้ครอบคลุม 3 ระดับ ได้แก่ แผนก, โครงการ และวัตถุประสงค์การใช้งาน พร้อมทั้งจัดเตรียมระบบเพื่อรวบรวมบันทึกข้อมูลเข้าสู่คลังข้อมูล (Data Warehouse) เพื่อให้สามารถตรวจสอบผ่านแดชบอร์ดรายเดือนได้

เราจะเปลี่ยนข้อมูลการจัดสรร (Apportionment data) ให้เป็น "การเรียกเก็บเงิน" (Billing) อย่างไร เพื่อให้แต่ละแผนกยอมรับและสามารถบริหารจัดการงบประมาณได้? วิธีการ Chargeback คือกลไกที่นำผลการจัดสรรไปสะท้อนในงบประมาณจริงของแต่ละแผนก ซึ่งจำเป็นต้องออกแบบทั้งวิธีการเลือกรูปแบบและการกำหนดราคาต่อหน่วย โดยเฉพาะอย่างยิ่งการกำหนดราคาต่อหน่วยนั้นมักเกี่ยวข้องกับอำนาจต่อรองระหว่างแผนก ในสถานการณ์ที่มีแผนกซึ่งมีปริมาณการใช้งานและอำนาจต่อรองต่างกันอย่างสิ้นเชิง เช่น แผนกขายและแผนกวิศวกรรมมาอยู่ร่วมกัน วิธีการตัดสินใจเพียงอย่างเดียวอาจทำให้เกิดความรู้สึกไม่ยุติธรรมขึ้นมาได้ทันที ในหัวข้อ H3 ต่อไปนี้ เราจะเจาะลึกถึงรูปแบบการดำเนินงานที่เป็นตัวแทนและแนวคิดในการกำหนดราคาต่อหน่วย

วิธีการจัดสรรค่าใช้จ่ายสามารถแบ่งออกเป็น 3 รูปแบบหลัก ขึ้นอยู่กับความละเอียดในการแบ่งส่วนค่าใช้จ่าย ตามนิยามของ FinOps Foundation วิธีการจัดสรรค่าใช้จ่ายจริงลงในงบกำไรขาดทุน (P&L) ของแต่ละแผนกโดยตรงจะเรียกว่า "Chargeback" ซึ่งจะแตกต่างอย่างชัดเจนจาก "Showback" ที่เป็นการแสดงข้อมูลค่าใช้จ่ายให้เห็นเท่านั้นแต่ยังคงรวมศูนย์การบริหารจัดการไว้เช่นเดิม ความแตกต่างนี้เปรียบได้กับการเลือกว่าจะเก็บเงินจริงจากการหารค่าใช้จ่าย หรือเพียงแค่แชร์ใบเสร็จให้ดูเท่านั้น

รูปแบบพื้นฐานที่สุดคือ "การจัดสรรตามค่าใช้จ่ายจริง" (Actual Cost Allocation) ซึ่งจะคำนวณค่าใช้จ่ายจากจำนวน Token หรือจำนวนครั้งที่เรียกใช้ API ของแต่ละแผนกโดยตรง แม้จะสะท้อนการใช้งานจริงได้อย่างแม่นยำที่สุด แต่เนื่องจากแผนกที่ใช้งานมากต้องแบกรับภาระมากขึ้น จึงมักเกิดความไม่พอใจเกี่ยวกับความสมดุลระหว่างการมีส่วนร่วมต่อธุรกิจกับภาระค่าใช้จ่าย ตัวอย่างเช่น แผนกที่ต้องใช้งานโครงสร้างพื้นฐานสำหรับตอบคำถาม FAQ ส่วนกลางอย่างเข้มข้น มักจะมีจำนวนการเรียกใช้งานมากกว่าแผนกอื่นอย่างมหาศาล ซึ่งโครงสร้างการหารตามปริมาณการใช้งานเพียงอย่างเดียวมักนำไปสู่ความไม่พอใจที่ว่า "ยิ่งใช้ยิ่งเสียเปรียบ" ได้โดยตรง

"การจัดสรรแบบคงที่" (Fixed Allocation) คือวิธีการจัดสรรตามจำนวนเงินที่กำหนดไว้ล่วงหน้าโดยอิงจากขนาดของแผนกหรือจำนวนที่นั่ง แม้จะช่วยให้คาดการณ์งบประมาณได้ง่าย แต่ในบางกรณีอาจเกิดความแตกต่างอย่างมากกับปริมาณการใช้งานจริง

"รูปแบบไฮบริด" (Hybrid) คือวิธีการจัดสรรค่าใช้จ่ายส่วนพื้นฐานแบบคงที่ และจัดสรรส่วนที่เกินมาตามปริมาณการใช้งานจริง ในทางปฏิบัติ บริษัทส่วนใหญ่มักเริ่มจากการสร้างการมองเห็นด้วย "Showback" และเมื่อสามารถสร้างความเห็นพ้องต้องกันระหว่างแผนกได้แล้ว จึงค่อยเปลี่ยนผ่านไปสู่ "Chargeback" ซึ่งขั้นตอนการเปลี่ยนผ่านนี้มักเป็นประเด็นสำคัญยิ่งกว่าการเลือกรูปแบบการจัดสรรเสียอีก

หลักการพื้นฐานคือ หากใช้โมเดลเพียงประเภทเดียว ให้สะท้อนต้นทุนจริงเป็นราคาต่อหน่วยโดยตรง แต่หากมีการใช้หลายโมเดลร่วมกัน ให้คำนวณราคาต่อหน่วยโดยใช้วิธีค่าเฉลี่ยถ่วงน้ำหนัก (weighted average)

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

ในกรณีที่มีการใช้สัญญาแบบจ่ายล่วงหน้า เช่น Scale Tier หรือ Provisioned Throughput Units (PTU) จำเป็นต้องใช้ราคาตามสัญญา (การเรียกเก็บเงินรายชั่วโมง/รายวัน) เป็นเกณฑ์แทนการใช้ปริมาณการใช้งานจริง ในกรณีนี้ การออกแบบโครงสร้างราคาแบบสองระดับคือ "ราคาตามสัญญาและส่วนเกิน" จะมีประสิทธิภาพ โดยการคิดค่าใช้จ่ายส่วนที่เกินจากโควตาตามราคาแบบ On-demand ให้กับแผนกที่ใช้งานเกิน

บางบริษัทอาจมีการบวกต้นทุนทางอ้อมเข้าไปในราคาต่อหน่วยด้วยในสัดส่วนที่กำหนด เช่น ค่าดำเนินการเครื่องมือตรวจสอบ (monitoring tools) หรือค่าแรงในการประมวลผลการเรียกเก็บเงิน ตามนิยามของ FinOps Foundation การทำ Chargeback คือกลไกการจัดสรรค่าใช้จ่ายไปยังงบกำไรขาดทุน (P&L) ของแผนกที่เป็นต้นกำเนิดของค่าใช้จ่ายนั้น ดังนั้นความโปร่งใสในการกำหนดราคาจึงเป็นปัจจัยสำคัญที่ส่งผลต่อความน่าเชื่อถือ ทั้งนี้ การทบทวนราคาต่อหน่วยอย่างสม่ำเสมอตามการปรับเปลี่ยนราคาของโมเดลหรือการเปลี่ยนแปลงของสัดส่วนการใช้งาน จะช่วยให้การดำเนินงานมีความคล่องตัวมากขึ้น

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

หลายท่านที่รับผิดชอบดูแลเรื่องนี้อาจกำลังลังเลว่า ควรตั้งค่าขีดจำกัดการใช้งาน (Usage Limit) ให้เท่ากันทุกแผนก หรือควรตั้งให้แตกต่างกันไปในแต่ละแผนกดี

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

• ขนาดของแผนก: ค่าพื้นฐานของจำนวนผู้ใช้งานและความถี่ในการส่งคำขอ (Request)
• ระดับการมีส่วนร่วมต่อธุรกิจ: แผนกนั้นมีการใช้ LLM ที่ส่งผลโดยตรงต่อยอดขายหรือคุณภาพการบริการลูกค้าหรือไม่
• ลำดับความสำคัญ: การปรับน้ำหนักตามความเหมาะสม เช่น เป็นโครงการใหม่หรืออยู่ในขั้นตอนการทดสอบ (PoC) หรือเป็นงานประจำ

ตัวอย่างเช่น หากแผนกบริการลูกค้า (Customer Support) มีการใช้ AI Chatbot เพื่อตอบกลับเบื้องต้นโดยอัตโนมัติ ปริมาณการใช้งานมักจะสูงกว่าแผนกขาย ในกรณีนี้ การนำตัวชี้วัดผลงาน เช่น จำนวนเคสที่ตอบกลับหรืออัตราการแก้ไขปัญหา มาคำนวณร่วมกับขีดจำกัดการใช้งาน จะสะท้อนความเป็นจริงได้ดีกว่าการคำนวณจากสัดส่วนจำนวนคนเพียงอย่างเดียว

ในทางกลับกัน สำหรับแผนกที่อยู่ในขั้นตอน PoC (Proof of Concept) ซึ่งผลลัพธ์ยังไม่ชัดเจน การตั้งขีดจำกัดไว้ค่อนข้างสูงในช่วงเวลาจำกัด แล้วค่อยกลับมาทบทวนใหม่หลังจากเริ่มใช้งานจริงจังถือเป็นแนวทางที่ปฏิบัติได้จริง ส่วนงานประจำที่มีลำดับความสำคัญต่ำ อาจพิจารณาปรับลดขีดจำกัดลงแบบขั้นบันไดโดยอ้างอิงจากสถิติการใช้งานรายเดือนได้เช่นกัน

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

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

• ส่งการแจ้งเตือนไปยังแผนกที่รับผิดชอบและแผนกบริหารเมื่อใช้งานถึง 80%
• ระงับคำขอใหม่ชั่วคราวเมื่อใช้งานถึง 100% และขอการตัดสินใจจากผู้อนุมัติ
• จัดเตรียมโควตาการขยายขีดจำกัดชั่วคราวผ่านการยื่นคำร้องล่วงหน้าสำหรับแผนกที่ได้รับผลกระทบสูงหากต้องหยุดการทำงาน

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

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

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

การรายงานรายเดือนมีจุดเริ่มต้นจากการรวบรวมจำนวน Token ที่ใช้งานแยกตามแผนก, จำนวนการเรียกใช้ API, ยอดค่าใช้จ่ายแบบ Chargeback และอัตราการเปลี่ยนแปลงเมื่อเทียบกับเดือนก่อนหน้าไว้ในแดชบอร์ดเดียว เพื่อสร้างสภาวะที่ฝ่ายการเงินและหัวหน้าของแต่ละแผนกสามารถดูตัวเลขเดียวกันและหารือร่วมกันได้ ผู้ให้บริการหลักอย่าง OpenAI หรือ Azure OpenAI มีฟังก์ชัน Usage API และฟังก์ชันส่งออกข้อมูลค่าใช้จ่าย (Cost Export) ให้บริการอยู่แล้ว หากใช้การส่งออกข้อมูลแบบรายวันหรือรายเดือนไปยัง S3 หรือพื้นที่จัดเก็บข้อมูล ก็จะสามารถเปลี่ยนงานตรวจสอบยอดเงินกับใบแจ้งหนี้จากการทำด้วยมือให้เป็นระบบอัตโนมัติได้

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

นอกจากนี้ ในแผนกที่มีทั้งต้นทุนคงที่ (เช่น สัญญาแบบจองล่วงหน้าอย่าง Provisioned Throughput Units) และต้นทุนผันผวนปะปนกันอยู่ จุดสำคัญในทางปฏิบัติสำหรับการเพิ่มประสิทธิภาพด้านต้นทุนคือการนำข้อมูลการใช้งานจริงมาเปรียบเทียบกับช่วงเวลาต่อสัญญาในทุกไตรมาส เพื่อปรับปริมาณการจองให้เหมาะสม ไม่ให้มากหรือน้อยเกินไป

ในการบริหารจัดการการจัดสรรต้นทุนตามแผนก มักเกิดข้อสงสัยหรือความจำเป็นในการปรับเปลี่ยนที่คาดไม่ถึงขึ้นได้ง่าย ในที่นี้เราจะขอตอบ 3 คำถามที่พบบ่อยในการปฏิบัติงาน ได้แก่ การขจัดความรู้สึกไม่เป็นธรรม, การรับมือกับการใช้งานที่เพิ่มขึ้นอย่างกะทันหัน และการออกแบบการจัดสรรเมื่อมีการใช้งานหลาย API ร่วมกัน

เกณฑ์การตัดสิน: คือการแยกแยะว่าสาเหตุของความรู้สึกไม่เป็นธรรมนั้นมาจากวิธีการจัดสรร (Apportionment) หรือมาจากสภาพการใช้งานจริงกันแน่

การจัดสรรตามปริมาณการใช้งานอาจดูยุติธรรม แต่เนื่องจากความซับซ้อนของงานและปริมาณการใช้โทเค็น (Token consumption) ของแต่ละแผนกมีความแตกต่างกันอย่างมาก การเปรียบเทียบด้วยจำนวนครั้งที่เรียกใช้งาน (Call count) เพียงอย่างเดียวจึงอาจทำให้เกิดความเข้าใจผิดได้ ตัวอย่างเช่น แผนกที่เน้นงานสรุปความกับแผนกที่เกี่ยวข้องกับการสร้างข้อความยาวๆ หรือการใช้เหตุผลแบบหลายขั้นตอน (Multi-step reasoning) จะมีปริมาณการใช้โทเค็นที่แตกต่างกันแม้จะมีจำนวนครั้งที่เรียกใช้งานเท่ากันก็ตาม ในกรณีนี้ การเปลี่ยนเกณฑ์การจัดสรรจากจำนวนครั้งที่เรียกใช้งานมาเป็นจำนวนโทเค็นขาเข้าและขาออก (Input/Output tokens) มักจะช่วยขจัดความรู้สึกไม่เป็นธรรมได้

ในทางกลับกัน หากวิธีการจัดสรรไม่มีปัญหา แต่มีบางแผนกที่ใช้งานในราคาสูงอย่างต่อเนื่อง การตรวจสอบวัตถุประสงค์การใช้งานและลำดับความสำคัญของแผนกนั้นร่วมกับผู้ที่เกี่ยวข้องจะมีประสิทธิภาพมากกว่าการทบทวนราคาต่อหน่วยในการเรียกเก็บเงิน (Chargeback unit price) หากเป็นโครงการที่มีส่วนช่วยต่อธุรกิจสูง ก็ควรเจรจาจัดสรรงบประมาณใหม่ แต่หากไม่ใช่ ก็ควรนำไปสู่การทบทวนเพดานการใช้งานหรือพิจารณาทางเลือกอื่น (เช่น การใช้งาน Local LLM หรือโมเดลขนาดเล็กผ่าน PEFT)

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

หลักการพื้นฐานคือ หากเป็นการใช้งานที่เกิดขึ้นกะทันหันเพียงชั่วคราว ให้ใช้ "งบประมาณสำรอง" ในการรองรับ แต่หากเป็นการใช้งานที่เพิ่มขึ้นอย่างต่อเนื่อง ให้ดำเนินการปรับปรุงงบประมาณรายไตรมาสเพื่อรองรับ โครงการในขั้นตอน PoC (Proof of Concept) มักจะประเมินปริมาณการใช้โทเค็นล่วงหน้าได้ยาก และมีแนวโน้มที่จะเกิดการใช้งานเกินขีดจำกัดที่คาดการณ์ไว้ได้ง่าย

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

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

เมื่อใช้งาน LLM API หลายตัวร่วมกัน จำเป็นต้องปรับเกณฑ์การปันส่วนค่าใช้จ่ายให้เป็นมาตรฐานเดียวกัน เนื่องจากผู้ให้บริการแต่ละรายมีหน่วยการเรียกเก็บเงินและโครงสร้างราคาที่แตกต่างกัน อุปสรรคในทางปฏิบัติคือจำนวน Token และจำนวนครั้งที่เรียกใช้ API มีราคาต่อหน่วยไม่เท่ากันในแต่ละ Vendor หากนำมาเปรียบเทียบกันโดยตรงจะทำให้เกิดความรู้สึกถึงความเหลื่อมล้ำของภาระค่าใช้จ่ายระหว่างแผนกได้ง่าย

แนวทางแก้ไขคือ การแปลงค่าใช้จ่ายในการใช้งานของแต่ละ Vendor ให้เป็นหน่วยกลางของบริษัท (เช่น ค่าแปลงภายในที่เรียกว่า "หน่วยประมวลผลมาตรฐาน") แล้วใช้ค่าที่แปลงแล้วเป็นเกณฑ์ในการจัดสรรตามแผนก หากมีการกำหนด Vendor หลักแยกตามวัตถุประสงค์การใช้งาน การแยกกฎการจัดสรรตามประเภทการใช้งาน (เช่น สำหรับสรุปความ, สำหรับเขียนโค้ด, สำหรับการอนุมานความแม่นยำสูง ฯลฯ) จะช่วยให้บริหารจัดการได้ง่ายขึ้น

ในทางกลับกัน ในขั้นตอนที่แต่ละแผนกกำลังเปรียบเทียบและทดสอบ Vendor หลายรายด้วยตนเอง การจัดสรรตามวัตถุประสงค์หรือตามโครงการควรมีความสำคัญมากกว่าการจัดสรรตาม Vendor และการทำให้ราคาต่อหน่วยเป็นมาตรฐานควรดำเนินการหลังจากที่เลือก Vendor ได้อย่างชัดเจนแล้ว หากมีการใช้ Local LLM หรือ SLM ร่วมในบางงาน การพิจารณาทบทวนนโยบายการจัดสรรควบคู่ไปกับทางเลือกในการลดการพึ่งพา Cloud API ตามที่แนะนำไว้ใน การเปรียบเทียบการนำ Local LLM / SLM มาใช้ ก็เป็นสิ่งที่ควรพิจารณา ไม่ว่าจะกรณีใดก็ตาม สิ่งสำคัญคือฝ่ายการเงินและฝ่ายวางแผนต้องเป็นผู้บริหารจัดการเกณฑ์การแปลงค่าแบบรวมศูนย์ เพื่อป้องกันไม่ให้เกิดความคลาดเคลื่อนในการตีความของแต่ละแผนก