ทำไมบิลค่าคลาวด์ในยุค AI ถึงคุมไม่อยู่? คู่มือเริ่มต้น FinOps และการเลือกเครื่องมือ

เช้าวันจันทร์วันหนึ่งในเดือนมิถุนายน CFO ของบริษัท SaaS ขนาด 30 คนในกรุงเทพฯ เปิดกล่องอีเมล เห็นบิลรายเดือนของ AWS มากกว่าเดือนก่อนไปราว 500,000 บาท เธอส่งต่อให้หัวหน้าทีมวิศวกรรม พร้อมถามเพียงประโยคเดียวว่า "นี่คืออะไร"

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

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

สี่สาเหตุจริงที่ AI ทำให้ต้นทุนคลาวด์คุมไม่อยู่

หนึ่ง ระดับราคาต่อหน่วยของ GPU ต่างกันโดยสิ้นเชิง

เครื่อง compute instance ทั่วไปหนึ่งตัว ลืมปิดไปหนึ่งเดือนก็เผาเงินไปไม่กี่พันบาท เจ็บแต่ไม่ถึงตาย แต่เครื่อง GPU instance ตัวหนึ่ง ลืมปิดหนึ่งเดือนเหมือนกัน อาจเป็นหลักแสนบาทขึ้นไป แต่ก่อน "ลืมปิดเครื่อง" เป็นความพลาดเล็ก ๆ ตอนนี้มันคือเหตุการณ์ทางการเงิน

สอง ค่า API ของโมเดลไม่ได้อยู่ในบิลคลาวด์

นี่คือส่วนที่ถูกมองข้ามง่ายที่สุด ค่า API ของ OpenAI, Anthropic, Google เป็นบิลแยกต่างหาก ไม่ปรากฏในรายงานต้นทุนของ AWS หรือ GCP หลายทีมเวลาทบทวนต้นทุนดูแค่คอนโซลคลาวด์ ไม่ได้นับค่าโมเดลเข้าไปเลย เท่ากับมองข้ามรายจ่ายไปสามสิบถึงห้าสิบเปอร์เซ็นต์

สาม ความสัมพันธ์ระหว่างปริมาณการใช้กับปริมาณธุรกิจขาดสะบั้น

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

สี่ สภาพแวดล้อมทดลองกับการผลิตปนกัน

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

FinOps ทำอะไรกันแน่

คำว่า FinOps ฟังดูน่ากลัว แต่จริง ๆ แก่นมีแค่สามเรื่อง และลำดับกลับกันไม่ได้

ขั้นที่หนึ่ง มองเห็น (Inform) นำรายจ่ายทั้งหมดมาไว้บนตารางเดียว รวมทั้งคลาวด์ ค่าสมัคร SaaS และ API ของโมเดล กุญแจของขั้นนี้ไม่ใช่เครื่องมือ แต่คือการจัดการแท็ก (tag governance) ทุกทรัพยากรต้องแมปกับทีม โปรเจกต์ หรือสายผลิตภัณฑ์ได้ ถ้าไม่มีแท็ก เครื่องมือใด ๆ ก็ให้ได้แค่คำตอบไร้ประโยชน์อย่าง "EC2 ใช้ไป 300,000 บาท"

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

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

บริษัทส่วนใหญ่ติดอยู่ระหว่างขั้นที่หนึ่งกับสอง คือทำรายงานออกมาแล้ว แต่ไม่มีใครมีเวลาดู ดูแล้วก็ไม่มีใครกล้าลบ

เลือกเครื่องมืออย่างไร: ดูขนาดก่อน แล้วค่อยดูสถานการณ์

เครื่องมือ FinOps ในตลาดมีเยอะ แต่ความแตกต่างของจุดยืนค่อนข้างชัดเจน ผมจัดเครื่องมือหลายตัวที่ประเมินในปีนี้ออกเป็นหลายกลุ่ม

ผสานหลายบริการ ต้องมองกว้าง: Vantage รองรับคลาวด์และบริการ SaaS กว่ายี่สิบชนิด บริการที่กินเงินอย่าง Datadog, Snowflake ก็นับรวมได้ อีกทั้งมี MCP Server ให้คุณถามคำถามเรื่องต้นทุนผ่าน ChatGPT หรือ Claude ได้โดยตรง เหมาะกับทีมที่ใช้บริการหลากหลาย

ต้นทุน Kubernetes ต้องแยกละเอียด: การออกแบบแท็กเสมือน (virtual tag) ของ Finout เป็นหนึ่งในทางออกของสนามนี้ ไม่ต้องย้อนกลับไปแก้แท็กของโครงสร้างพื้นฐาน ก็นิยามการปันส่วนต้นทุนใหม่บนแพลตฟอร์มได้ การปันส่วนต้นทุนของคลัสเตอร์ K8s แบบหลายผู้เช่าคือจุดแข็ง อีกทั้งไม่คิดค่าตามที่นั่ง ทั้งบริษัทดูบัญชีได้

เจอปัญหาแล้วต้องจัดการได้เลย: Cloudchipr เน้นการทำอัตโนมัติที่ลงมือได้จริง คุณตั้งกฎให้ "ทรัพยากรที่ว่างต่อเนื่องเจ็ดวันแจ้งเจ้าของก่อน แล้วปิดเครื่องอัตโนมัติหลังสามวัน" ได้ มันแก้อุปสรรคทางจิตใจในองค์กรเรื่อง "ไม่มีใครกล้าลบ"

ส่วนลดแบบผูกมัดต้องบริหารอัตโนมัติ: nOps และ Usage.ai เชี่ยวชาญด้านนี้ทั้งคู่ ตัวแรกเด่นที่การผสานเข้ากับ AWS อย่างลึกซึ้ง ตัวหลังคิดค่าแบบอิงผลงาน หักเปอร์เซ็นต์จากเงินที่ประหยัดได้จริงเท่านั้น ถ้าไม่ได้ประหยัดก็ไม่ต้องจ่าย

ขนาดไม่ใหญ่ ต้องเรียบง่าย: Amnic ใช้ AI Agent แบบมีบทบาทคอยผลักข้อสรุปมาให้คุณ ส่วน Economize Cloud เดินแนวเบา เหมาะกับสตาร์ทอัพที่จ่ายเดือนละไม่กี่พันดอลลาร์

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

แนวทางเริ่มต้นสำหรับทีมขนาดกลางถึงเล็กในไทย

หากรายจ่ายคลาวด์ต่อเดือนของบริษัทคุณอยู่ระหว่าง 30,000 ถึง 300,000 บาท ผมแนะนำให้เริ่มแบบนี้ ไม่ต้องรีบซื้อเครื่องมือ:

1. ทำสัปดาห์นี้เลย: ทำรายการแหล่งบิลทั้งหมดเป็นตารางเดียว ทั้งคลาวด์ API ของโมเดล บริการฐานข้อมูล บริการมอนิเตอร์ และค่าสมัคร SaaS ทุกตัว ทีมส่วนใหญ่พอทำเสร็จจะพบว่ามีค่าสมัครสองสามตัวที่ไม่มีใครจำได้ยังถูกตัดเงินอยู่
2. ภายในสองสัปดาห์: เติมแท็กของทรัพยากรให้ครบ อย่างน้อยต้องมีสองมิติคือ "สภาพแวดล้อม" (โปรดักชัน/เทสต์/พัฒนา) และ "ผู้รับผิดชอบ" เรื่องนี้ไม่มีทางลัด แต่ก็ไม่ต้องใช้เครื่องมือ
3. ภายในหนึ่งเดือน: ตั้งการแจ้งเตือนงบประมาณ ฟังก์ชันแจ้งเตือนที่มากับคลาวด์ก็เพียงพอ จุดสำคัญคือตั้งที่เกณฑ์ที่ถูกต้อง และส่งไปที่ที่มีคนดู (Slack หรือ Teams ไม่ใช่อีเมล)
4. หลังสามเดือน: ตอนนี้คุณจึงจะมีข้อมูลพอที่จะตัดสินว่าต้องการเครื่องมือแบบไหน หากปัญหาคือ "มองไม่ชัด" เลือกแบบผสานรวม หากปัญหาคือ "ไม่มีใครลงมือ" เลือกแบบอัตโนมัติ หากปัญหาคือ "ซื้อส่วนลดผูกมัดไม่ถูก" เลือกแบบอิงผลงาน

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

บทสรุปและความเห็นจาก TheAI Academy

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

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

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

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

เครื่องมือที่เกี่ยวข้องเพิ่มเติมดูได้ที่ หมวดเครื่องมือสำหรับนักพัฒนา AI บนเว็บไซต์ หรือดู สถานการณ์งาน AI เพื่อหาทางออกที่ตรงกับปัญหา