ต้นทุนโทเคน AI Agent ต่อหนึ่งงาน: สูตรวัดค่าใช้จ่ายและงาน Android ที่ตรวจได้

วัดต้นทุนต่อหนึ่งงานที่สำเร็จจริง

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

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

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

สร้างบัญชีต้นทุนจากรายการใช้งานของผู้ให้บริการ

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

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

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

เขียนสูตรไว้ในสเปรดชีตแบบนี้: ยอดรวมค่าโทเคน = (จำนวนโทเคนขาเข้าที่ไม่เข้าแคช ÷ 1,000,000 × ราคาขาเข้าต่อหนึ่งล้านโทเคน) + (จำนวนโทเคนอ่านแคช ÷ 1,000,000 × ราคาอ่านแคชต่อหนึ่งล้านโทเคน) + (จำนวนโทเคนขาออกที่คิดเงิน ÷ 1,000,000 × ราคาขาออกต่อหนึ่งล้านโทเคน) จากนั้นค่อยบวกค่าธรรมเนียมเพิ่มเติม เช่นค่าเขียนแคช ค่าเก็บแคช หรือค่าบริการเครื่องมือถ้ามี ทุกการลองซ้ำและทุกความล้มเหลวต้องรวมอยู่ในยอดรายการใช้งานตั้งแต่ต้น ไม่ใช่คำนวณเฉพาะรอบที่สำเร็จแล้วค่อยบวกการลองซ้ำแบบประมาณเอา

คำนวณชุดงานสมมติหนึ่งชุดใหม่ได้

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

ถ้างาน 100 ครั้งนั้นมีงานที่ตรวจแล้วว่าสำเร็จ 90 ครั้ง ต้นทุนต่อหนึ่งงานที่สำเร็จคือ $3.34 ÷ 90 หรือประมาณ $0.0371 ต่อหนึ่งงาน ความล้มเหลว 10 ครั้งไม่ได้ถูกลืม เพราะรายการใช้งานและการลองซ้ำของมันรวมอยู่ในยอด $3.34 แล้ว ถ้าชุดงานจริงของคุณมีค่าเขียนแคช ค่าเก็บแคช ค่ารูปภาพที่คิดแยก หรือค่าบริการเฉพาะทาง ให้เพิ่มรายการเหล่านั้นตามใบรายการใช้งานของผู้ให้บริการ

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

งานฝั่งโทรศัพท์เปลี่ยนต้นทุนส่วนไหนได้

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

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

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

ทำการวัดงานซ้ำขนาดเล็ก

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

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

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

หากเป้าหมายคือเปรียบเทียบการทำงานในเครื่องกับการทำงานบนคลาวด์ ให้แยกคำถามเรื่องค่าใช้จ่ายออกจากคำถามเรื่องข้อมูลและความไว้ใจ บทความ AI agent trust: เมื่อควรใช้ local AI agent แทนผู้ช่วยบนคลาวด์ ช่วยวางกรอบว่าอะไรเกิดในเครื่อง อะไรพึ่งโมเดลออนไลน์ และข้อมูลใดควรถูกส่งให้น้อยที่สุด

ลดความสิ้นเปลืองโดยไม่ตัดจุดตรวจ

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

สำหรับพลังงาน ให้บันทึกแยกจากค่าโมเดล สูตรง่ายคือค่าไฟโดยประมาณ = Wh เพิ่มขึ้นจากงาน ÷ 1000 × ค่าไฟต่อ kWh ในพื้นที่ของคุณ ถ้าจะรวมเป็นต้นทุนรวม ให้รวมอย่างสม่ำเสมอทุกชุดงาน และอย่านับเวลาผู้ใช้ซ้ำทั้งเป็นชั่วโมงทำงานและเป็น “ค่าตรวจทาน” อีกรอบโดยไม่ตั้งกติกา

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