ต้นทุนที่ซ่อนอยู่ของคลาวด์

บทที่ 5 — ต้นทุนที่ซ่อนอยู่ของคลาวด์

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

ลองมาดูรายการที่ถูกมองข้ามมากที่สุดในใบแจ้งหนี้: API ของโมเดลวิทัศน์ เมื่อบริษัทใดก็ตามนำคลังภาพถ่ายของตนเองเข้าสู่ RAG ที่ทันสมัย รูปภาพแต่ละภาพจะต้องถูก "อธิบาย" โดยโมเดลแบบมัลติโมดัลที่ดึงเนื้อหา วัตถุ บริบท ข้อความที่ซ้อนทับ อารมณ์ องค์ประกอบ ในปี 2025 ผู้ให้บริการโมเดลรายใหญ่ของยุโรป—ยังไม่เปิดเผยชื่อ—ได้นำเสนอโมเดลตระกูล Qwen ขนาด 32 พันล้านพารามิเตอร์ ซึ่งมีราคาต่อภาพที่น่าสนใจ ปัญหาที่ค้นพบจากการใช้งานจริงและหลังจากผลิตไปหลายเดือนคือ ผู้ให้บริการจะตัดคำตอบเมื่อรับภาระหนัก ไม่เสมอไป ไม่สามารถคาดเดาได้ ไม่ใช่เมื่อทีมทดสอบอยู่ตรงหน้า แต่เป็นแบบสุ่ม รูปภาพหนึ่งในสิบภาพ บางครั้งหนึ่งในห้าภาพ จะส่งคืน JSON ที่ถูกตัดครึ่ง วิเคราะห์ผิดพลาด มีเมตาดาต้าไม่สมบูรณ์หรือเป็นโมฆะ เวลาเพิ่มขึ้นจากสิบวินาทีเป็นสองร้อยวินาทีต่อภาพ โดยไม่มีรูปแบบ ค่าใช้จ่ายในการลองใหม่—เนื่องจากต้องจ่ายค่าลองใหม่ ทุกการเรียก รวมถึงการเรียกที่เซิร์ฟเวอร์ตัดทอน—สูงกว่าที่คาดไว้ ฐานข้อมูลไม่สอดคล้องกัน: รูปภาพบางภาพมีเมตาดาต้ามากมาย บางภาพถูกตัดทอน และทีมไม่สามารถจำลองปัญหาในสภาพแวดล้อมการทดสอบได้ เนื่องจากภาระในสภาพแวดล้อมการทดสอบต่ำและทุกอย่างทำงานได้ตามปกติ

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

จากนั้นก็มีเรื่องของการสืบค้น การค้นหาของผู้ใช้แต่ละครั้ง ใน RAG ที่สร้างขึ้นบนคลาวด์แบบดั้งเดิม จะกระตุ้นให้เกิดการเรียกใช้ API แบบมีค่าใช้จ่ายเป็นจำนวนมาก หนึ่งครั้งสำหรับการฝังคำถาม หนึ่งครั้งสำหรับการจำแนกเจตนา (คำถามเป็นประเภทใด) หนึ่งครั้งสำหรับการจัดอันดับเอกสารใหม่ และหนึ่งครั้งสำหรับการสร้างคำตอบสุดท้าย แต่ละครั้งมีค่าใช้จ่ายเพียงเศษของเซ็นต์ สำหรับบริการภายในที่มีผู้ใช้ห้าสิบคน และการสืบค้นหนึ่งหมื่นครั้งต่อวัน—ซึ่งไม่ใช่จำนวนน้อย แต่ก็ไม่ใช่จำนวนมหาศาลสำหรับบริษัทขนาดกลาง—ค่าใช้จ่ายรายเดือนจะสูงถึงระดับที่แม้แต่ CFO ที่ใจดีก็ต้องขมวดคิ้ว และการเติบโตเป็นไปแบบเส้นตรง: หากจำนวนผู้ใช้เพิ่มขึ้นเป็นสองเท่า ค่าใช้จ่ายก็จะเพิ่มขึ้นเป็นสองเท่า ไม่มีผลประโยชน์จากขนาดในโทเค็นที่ใช้ไป ไม่มีสำหรับคุณ

มีปัญหาหนึ่งที่ซ่อนอยู่ในปี 2025 และกลายเป็นประเด็นสำคัญในปี 2026 คือ การส่งคำถามแต่ละครั้งจะส่งส่วนหนึ่งของเอกสารของบริษัท—บางครั้งเป็นข้อมูลที่เป็นความลับ บางครั้งครอบคลุมโดย NDA บางครั้งอยู่ภายใต้กฎระเบียบของอุตสาหกรรม—ไปยังเซิร์ฟเวอร์ของผู้ให้บริการภายนอก ในเขตอำนาจศาลที่ไม่ตรงกับของคุณเสมอไป โดยมีนโยบายการเก็บรักษาบันทึกที่ไม่ชัดเจน บริษัทต่างๆ ในยุโรปจำนวนมากในช่วงสิบแปดเดือนที่ผ่านมา พบว่าสัญญา รายการราคา และข้อกำหนดทางเทคนิคของตนได้รับการประมวลผล (และอาจถูกบันทึกไว้เพื่อวัตถุประสงค์ในการ "ปรับปรุงบริการ") โดยโครงสร้างพื้นฐานนอกสหภาพยุโรป ความประหลาดใจมักมีค่าใช้จ่ายมากกว่าเงินที่ประหยัดได้จากการหลีกเลี่ยงฮาร์ดแวร์ในเครื่อง

ทางเลือกไม่ใช่หลักการที่ตรงกันข้าม "ไม่ใช้คลาวด์ ใช่แบบภายในเครื่อง" ผิดเท่ากับ "ใช้คลาวด์เสมอไป" ทางเลือกคือสถาปัตยกรรมที่ช่วยให้คุณเลือกได้ สำหรับแต่ละส่วนของไปป์ไลน์—การฝังตัว การจัดหมวดหมู่ การจัดลำดับใหม่ วิสัยทัศน์ การสร้างขั้นสุดท้าย—ว่าจะใช้โมเดลคลาวด์หรือโมเดลภายในเครื่อง และเปลี่ยนใจได้ในวันเดียว ไม่ใช่ในหนึ่งไตรมาส สิ่งนี้ต้องใช้การออกแบบที่ผู้ให้บริการสามารถเปลี่ยนแปลงได้ โดยที่ไม่มีส่วนใดถูกผูกติดกับชื่อบริษัทใดบริษัทหนึ่ง และการเปลี่ยนจาก Regolo เป็น Ollama (หรือในทางกลับกัน) เป็นเพียงบรรทัดเดียวในการกำหนดค่า ไม่ใช่การเขียนใหม่ทั้งหมด และสิ่งนี้หายากจนกระทั่งเมื่อไม่นานมานี้ เฟรมเวิร์กยอดนิยม แม้จะมีลักษณะภายนอกที่ "เป็นกลางต่อผู้ให้บริการ" แต่ก็มีความผูกพันกับใครบางคนอย่างมาก