OpenAI API ถูกลงแค่ไหน และธุรกิจต้องปรับตัวอย่างไร

ระบบ routing ที่ใช้งานจริงควรมีอย่างน้อย 4 ส่วน

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

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

กับดักใหญ่ยังอยู่ที่เอาต์พุต

ราคาฝั่งอินพุตที่ถูกลงไม่ได้แปลว่าบิลรวมจะถูกลงเสมอ เพราะในตระกูล GPT-4.1 OpenAI ระบุราคาเอาต์พุตไว้สูงกว่าอินพุต 4 เท่า ได้แก่ GPT-4.1 ที่ $4.00 เทียบกับ $1.00, GPT-4.1 mini ที่ $0.80 เทียบกับ $0.20 และ GPT-4.1 nano ที่ $0.20 เทียบกับ $0.05 ต่อ 1 ล้านโทเคน OpenAI ยังระบุ o3-pro ที่ $10.00 ต่อ 1 ล้านโทเคนอินพุต และ $40.00 ต่อ 1 ล้านโทเคนเอาต์พุต

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

วิธีคุมต้นทุนที่ควรมีตั้งแต่ต้น ได้แก่ จำกัดความยาวเอาต์พุต ตั้งค่าโทนคำตอบให้กระชับเป็นค่าเริ่มต้น กำหนด token budget แยกตามฟีเจอร์ ตั้ง alert เมื่อคำตอบยาวผิดปกติ และแยกบัญชีต้นทุนอินพุตกับเอาต์พุตให้เห็นชัด

Prompt ยาวกลายเป็นต้นทุนปฏิบัติการ

หน้า API Pricing ของ OpenAI แยกราคา cached input ออกจาก input ปกติ และมีรายการหนึ่งที่ระบุ cached input ที่ $0.50 ต่อ 1 ล้านโทเคน เทียบกับ input ปกติ $5.00 ต่อ 1 ล้านโทเคน รายละเอียดจริงขึ้นอยู่กับโมเดลที่รองรับและรูปแบบ workload แต่สัญญาณด้านต้นทุนชัดเจน: บริบทที่ส่งซ้ำ ๆ อาจกลายเป็นพื้นที่ประหยัดเงินก้อนใหญ่

เรื่องนี้สำคัญกับแอปที่ส่ง system prompt ยาว ๆ คำสั่งเครื่องมือ schema ข้อความนโยบาย retrieval context หรือประวัติสนทนาส่วนเดิมซ้ำไปซ้ำมา ทีมพัฒนาควรถามตั้งแต่ขั้นออกแบบว่า บริบทส่วนไหนคงที่ บริบทส่วนไหนตัดออกได้ และส่วนไหนเข้าข่ายใช้ราคาของ cached input ได้

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

งานที่ไม่ต้องตอบทันทีควรแยกไป batch

ไม่ใช่งาน AI ทุกชนิดต้องตอบภายในไม่กี่วินาที Azure OpenAI ระบุว่า Batch API สามารถคืนผลภายใน 24 ชั่วโมง และให้ส่วนลด 50% จาก Global Standard Pricing นี่ทำให้งานเบื้องหลังที่รอได้ เช่น เติมข้อมูลเอกสาร ติดแท็กคอนเทนต์ ประเมินผลคำตอบ ทำความสะอาดข้อมูล หรือ automation หลังบ้าน เหมาะกับคิวแบบ asynchronous มากขึ้น

Azure OpenAI ยังระบุ Provisioned Throughput Units หรือ PTUs เป็นวิธีจัดสรร throughput เพื่อให้ต้นทุนคาดการณ์ได้มากขึ้น พร้อมตัวเลือกจองรายเดือนและรายปีเพื่อลดค่าใช้จ่ายโดยรวม สำหรับองค์กรขนาดใหญ่ ทางเลือกจึงไม่ได้มีแค่จ่ายตามการใช้งานจริงเสมอไป แต่อาจผสมระหว่าง on-demand, batch และ capacity ที่จองไว้สำหรับงานปริมาณสูงที่คาดการณ์ได้

สิ่งที่ธุรกิจควรเปลี่ยนตอนนี้

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

เช็กลิสต์ที่ควรเริ่มทำมีดังนี้

1. ทำบัญชีต้นทุนแยกตามฟีเจอร์ เพื่อรู้ว่าหน้าจอหรือ workflow ไหนกินงบมากที่สุด
2. วัดต้นทุนแยกตามลูกค้า เพื่อไม่ให้บัญชีที่ใช้งานหนักกลายเป็นลูกค้าที่ขาดทุนโดยไม่รู้ตัว
3. ตั้งกฎ model routing เริ่มจากโมเดลราคาต่ำ แล้วค่อย escalate เมื่อคุณภาพไม่ผ่าน
4. กำหนด output budget สำหรับแชต รายงาน โค้ด และงานค้นคว้า
5. รีวิวความยาว prompt เป็นรอบ ๆ ตัดบริบทที่ไม่จำเป็น และหาบริบทซ้ำที่อาจใช้ cached input ได้
6. สร้าง batch queue สำหรับงานที่รอได้เป็นชั่วโมง ไม่จำเป็นต้องตอบทันที
7. ตั้ง budget alert และ anomaly detection เพื่อจับการใช้โทเคนที่พุ่งผิดปกติก่อนบิลปลายเดือนมาถึง

สรุป: ผู้ชนะไม่ใช่คนที่เลือกโมเดลถูกที่สุด

โครงสร้างราคาของ OpenAI API ทำให้การสร้างฟีเจอร์ AI หลายประเภทมีโอกาสคุ้มค่าขึ้น โดยเฉพาะเมื่อทีมสามารถใช้โมเดลต้นทุนต่ำอย่าง GPT-4.1 mini หรือ GPT-4.1 nano ได้อย่างเหมาะสม แต่สูตรที่ชนะไม่ใช่การเลือกโมเดลที่ถูกที่สุดเสมอไป

สูตรที่ชนะคือสถาปัตยกรรมที่รู้ต้นทุน: route ตามความยากของงาน คุมความยาวเอาต์พุต ใช้ cached input เมื่อเหมาะสม แยกงานที่รอได้ไป batch และวัดต้นทุนละเอียดพอให้ทีมผลิตภัณฑ์ วิศวกร และการเงินตัดสินใจจากข้อมูลเดียวกัน