ต้นทุนแฝงของ AI ในระดับขนาดใหญ่

เมื่อ 1 มิถุนายน 2026, GitHub ยกเลิกการให้บริการ “premium requests” แบบอัตราคงที่สำหรับ Copilot อย่างถาวรและเปลี่ยนเป็นเครดิต AI แบบใช้ตามการใช้งาน เมื่อใบแจ้งหนี้ฉบับแรกภายใต้โมเดลใหม่มาถึงหนึ่งเดือนต่อมา ผู้ใช้บางคนที่ทำงานแบบเอเจนต์พบบิลที่พวกเขาไม่ได้เตรียมพร้อม: หนึ่งนักพัฒนารายงาน ค่าต้นเดือนพุ่งจาก $29 เป็น $750 สำหรับเวิร์กโฟลว์เอเจนต์ที่หนักที่สุด.

นี่เป็นตัวอย่างที่เห็นได้ชัดของการเปลี่ยนแปลงที่กว้างขวางในตลาดเครื่องมือ AI ตลอดปี 2026 – และอาจรอคอยองค์กรที่ยังคงจ่ายอัตราคงที่อยู่ในวันนี้.

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

บริบทที่ไม่มีใครคำนวณค่า

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

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

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

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

เมื่อคุณจ่ายค่าเสียหายสองครั้ง

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

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

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

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

การตรวจสอบไม่ใช่บั๊ก มันเป็นส่วนของงบประมาณ

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

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

พรอมต์ต้องการการบำรุงรักษา ไม่ใช่แค่ผู้เขียน

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

การสร้างกรอบการประเมินที่เหมาะสม – รวมถึงชุดทดสอบและการทดสอบ regression อัตโนมัติในทุกการเปลี่ยนแปลง – เป็นงานเพิ่มเติมที่แทบไม่ปรากฏในการคำนวณ “AI ประหยัดเวลา”

โทเค็นราคาถูก ใบเรียกที่สูงขึ้น

GitHub Copilot ก็ไม่ใช่ข้อยกเว้น การสำรวจที่ CFO Dive อ้างอิงพบว่า เกือบเจ็ดในสิบบริษัทในสหรัฐอเมริการายงานว่ามีการเกินงบประมาณ AI อย่างน้อยบางส่วน ในปีที่ผ่านมา ส่วนใหญ่เกิดก่อนที่ระบบการเรียกเก็บแบบใช้ตามการบริโภคจะเปลี่ยนเต็มรูปแบบ ไม่ใช่หลังจากนั้น.

Bain & Company ในการวิเคราะห์เศรษฐศาสตร์โทเคนเดือนมิถุนายน เพิ่มข้อขัดแย้งที่สรุปสถานการณ์ได้ดีที่สุดว่า ราคาต่อโทเคนลดลงครึ่งหนึ่งในช่วงปีเดียวกัน ในขณะที่การใช้โทเคนเพิ่มขึ้น 4.5 เท่า.

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

วิธีเตรียมตัวก่อนที่ใบเรียกเก็บจะมาถึง

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

1. เริ่มด้วยการมองเห็นก่อน

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

2. คำนวณ ROI ใหม่บนพื้นฐานสุทธิ

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

3. ใช้วินัยด้านต้นทุน แต่ไม่ควรใช้ทั่วถึง

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

4. ถือ prompt และการประเมินเป็นทรัพย์สินด้านวิศวกรรม

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

เดินเข้าสู่การต่ออายุด้วยข้อมูลของคุณเอง

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

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

ต้นทุน AI สามารถจัดการได้ เพียงแต่ไม่ใช่เมื่อคุณค้นพบว่ามันเป็นเท่าไหร่เป็นครั้งแรกจากใบเรียกเก็บ