เมตริกที่ขาดหายระหว่างโทเคนกับค่าใช้จ่ายคลาวด์

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

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

ทำไมเมตริกโทเคนและบิลคลาวด์ถึงบอกเรื่องราวที่ต่างกัน?

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

The State of FinOps 2026 แสดงให้เห็นว่า AI เคลื่อนเข้าสู่การทำงาน FinOps ธรรมดาอย่างรวดเร็วแค่ไหน: 98% ของผู้ตอบแบบสอบถามตอนนี้จัดการค่าใช้จ่าย AI, เทียบกับ 63% ในปี 2025 แต่บรรทัดงบประมาณที่ใหญ่ขึ้นก็ยังไม่บอกว่ากระบวนการทำงานใดใช้เงินไปหรือทำไม 

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

Unite.ai ได้ตรวจสอบแล้วว่าทำไม จำนวนโทเคนไม่ได้อัตโนมัติแสดงคุณค่าทางธุรกิจ. ขั้นตอนต่อไปคือการเชื่อมโยงจำนวนเหล่านั้นกับงานที่สร้างมันขึ้นมา มิฉะนั้น ทีมอาจปรับปรุงต้นทุนต่อโทเคนได้แต่ทำให้ต้นทุนต่อภารกิจที่สำเร็จแย่ลง

โซ่ต้นทุนที่ครบถ้วนควรเป็นอย่างไร?

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

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

The OpenTelemetry conventions for GenAI agents ให้คำศัพท์ใหม่สำหรับชั้นนี้ ครอบคลุมการดำเนินการ, ผู้ให้บริการ, โมเดลที่ร้องขอ, เอเจนต์, การสนทนา, การใช้โทเคน, การเรียกใช้เครื่องมือ, ข้อผิดพลาด, และกระบวนการทำงาน คำกำหนดเหล่านี้ยังอยู่ในขั้นตอนการพัฒนา ดังนั้นทีมไม่ควรถือว่าเป็นมาตรฐานสากลที่เสร็จสมบูรณ์ เพราะมันมีประโยชน์ในการทำให้ปัญหาการเชื่อมโยงเป็นรูปธรรม

Then comes infrastructure. AWS’s split cost allocation data for EKS สามารถกำหนดต้นทุนการคำนวณและหน่วยความจำที่ใช้ร่วมกันให้กับพ็อดของ Kubernetes และเปิดเผยรายละเอียดเช่น คลัสเตอร์, เนมสเปซ, การปรับใช้, โหนด, ชื่องานและประเภทงาน สำหรับอินสแตนซ์ที่เร่งความเร็วที่รองรับ ข้อมูลยังครอบคลุมการจอง GPU, Trainium, และ Inferentia ด้วย

นี่คืออีกครึ่งของโซ่ การติดตามสามารถอธิบายว่ามีแอปพลิเคชันพยายามทำอะไร; การจัดสรรของ Kubernetes สามารถแสดงว่าทรัพยากรใดรับภาระงานนั้น Unite.ai’s guide to deploying and monitoring LLMs on Kubernetes ให้ข้อมูลบริบทการผลิตที่กว้างขึ้น รวมถึงการจัดสรรทรัพยากร, การขยายขนาด, และการมองเห็น

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

เมื่อบริบทของแอปพลิเคชันนั้นพร้อม ทีมสามารถเริ่ม tracking Kubernetes costs by workload และเชื่อมต่อเนมสเปซ, CPU, หน่วยความจำ, และการใช้ GPU กลับไปยังงานที่กำลังทำอยู่ แม้ว่ามันยังไม่บอกว่ากระบวนการทำงานสร้างคุณค่าทางธุรกิจหรือไม่ แต่ก็ให้ด้านโครงสร้างพื้นฐานของการคำนวณมีสิ่งที่เป็นรูปธรรมให้เชื่อมต่อ 

เมตริกหน่วยใดที่ธุรกิจควรเชื่อถือ?

ไม่มีเมตริกต้นทุน AI เพียงอย่างเดียวที่ทุกทีมควรใช้ ต้นทุนต่อโทเคนตอบคำถามเกี่ยวกับการใช้โมเดล ต้นทุนต่อพ็อดตอบคำถามเกี่ยวกับการจัดสรรโครงสร้างพื้นฐาน ทั้งสองไม่ได้บอกเจ้าของผลิตภัณฑ์ว่าฟีเจอร์นั้นคุ้มค่าหรือไม่

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

ความสำเร็จเปลี่ยนสูตรคณิตศาสตร์

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

Unite.ai’s analysis of the economics of scaling agentic AI workloads ครอบคลุมการกำหนดเส้นทาง, การเรียกเครื่องมือ, การลองใหม่, และการอ้างอิงระดับกระบวนการทำงาน พฤติกรรมเหล่านี้ควรอยู่ในเมตริกหน่วยเมื่อใช้ทรัพยากร แม้ว่าผู้ใช้สุดท้ายจะเห็นเพียงคำตอบเดียว

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

ใครเป็นเจ้าของตัวเลข?

ส่วนที่ยากที่สุดอาจเป็นด้านองค์กร ทีม ML เข้าใจการเรียกโมเดลและการประเมินผล ทีมแพลตฟอร์มเข้าใจงานและพฤติกรรมของคลัสเตอร์ FinOps เข้าใจข้อมูลบิลและกฎการจัดสรร ทีมผลิตภัณฑ์รู้ว่าผลลัพธ์ใดสำคัญ

ไม่มีทีมใดเป็นเจ้าของโซ่ทั้งหมด

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

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

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

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

โซ่ต้นทุนต้องถูกแชร์

การควบคุมต้นทุน AI จะยังคงกระจัดกระจายตราบใดที่ทุกทีมปรับแต่งเฉพาะชั้นที่มองเห็นได้ โทเคน, การติดตาม, พ็อด, ตัวเร่งความเร็ว, และใบแจ้งหนี้ไม่ได้เป็นการวัดที่แข่งขันกัน แต่เป็นส่วนของโซ่ต้นทุนเดียวกัน

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