กลยุทธ์หลายโมเดลคืออะไร และทำไมจึงเป็นคำตอบของบิล AI ที่บานปลาย
กลยุทธ์หลายโมเดลในบริบทของการลดต้นทุน AI คือการออกแบบสถาปัตยกรรมที่แยกงานตามระดับความซับซ้อน แล้วส่งงานง่ายไปให้โมเดล AI ราคาถูกหรือโมเดลเบารับผิดชอบ ขณะที่เก็บโมเดลระดับพรีเมียมไว้ใช้เฉพาะงานที่ต้องการตรรกะซับซ้อนและการคิดเชิงระบบ แนวคิดนี้เน้นเพิ่มประสิทธิภาพ token โดยไม่ลดคุณภาพผลลัพธ์ ผ่านการควบคุมว่าข้อมูลแบบไหนจะถูกส่งเข้าโมเดลแพง และข้อมูลแบบไหนให้โมเดลราคาถูกจัดการแทน
ใจความสำคัญคือ บิล AI พุ่งไม่หยุดไม่ได้เกิดจากตรรกะที่โง่ แต่เกิดจากการใช้ทรัพยากรผิดงาน วิศวกร Spotify เห็นชัดว่าการให้ Claude Code อ่านไฟล์ยักษ์หลายพันบรรทัดเพียงเพื่อหาฟังก์ชันเดียว คือการเผา token ทิ้งแบบไร้เหตุผล ดังนั้นพวกเขาจึงออกแบบสถาปัตยกรรมสองชั้น ให้ Gemini 2.5 Flash รับงานอ่านไฟล์และเขียนโค้ดซ้ำรูปแบบแทน และให้ Claude ทำเฉพาะการคิดเชิงลึก การตัดสินใจออกแบบ และงานที่ต้องใช้ความเข้าใจระบบ
สถาปัตยกรรมสองชั้นแบบ Spotify: ให้โมเดลถูกทำงานอ่านเขียน ให้โมเดลแพงทำงานคิด
การลดต้นทุน AI แบบมีชั้นเชิงเริ่มจากการยอมรับว่าไม่ใช่ทุกคำสั่งต้องไปเข้าโมเดลระดับเรือธง สถาปัตยกรรมสองชั้นของ Spotify เป็นตัวอย่างชัดเจนของการปรับแต่งค่าใช้จ่าย AI ผ่านการออกแบบเส้นทางงาน ตั้งแต่ต้นทางจนถึงปลายทาง พวกเขาใช้ฟีเจอร์ AiKA Modes ของแพลตฟอร์มภายใน Portal by Spotify สร้างเอเยนต์เล็กสองตัวที่ไม่ต้องมีเซิร์ฟเวอร์ตลอดเวลา ใช้ Gemini 2.5 Flash เป็นแรงงานประจำ
ตัวแรกคือ bulk-reader ทำหน้าที่อ่านไฟล์ขนาดใหญ่หลายไฟล์แบบรวดเดียว เมื่อ Claude ต้องการข้อมูลจากโปรเจกต์ขนาดใหญ่ มันจะไม่เปิดไฟล์เอง แต่ส่งพาธไฟล์และคำถามให้ bulk-reader อ่านแล้วสรุปเป็นหัวข้อย่อกลับมา ตัวที่สองคือ code-writer สำหรับงานเขียนโค้ดซ้ำรูปแบบ เช่น unit test หรือ type definition Claude แค่ให้สเปกและตัวอย่าง จากนั้นให้โมเดลเบาเขียนลงดิสก์โดยตรง โค้ดยาวๆ ไม่ต้องไหลผ่านหน้าต่างสนทนาเลย ซึ่งตามคำอธิบายของ Dimitri Mazmanov แนวทางนี้ช่วยกัน “เสียงรบกวนจากไวยากรณ์นับหมื่น token” ออกจากโมเดลหลัก
ด่านตรวจความสิ้นเปลือง: Hook, plugin และการบังคับใช้กติกาให้โมเดลทำตาม
การเพิ่มประสิทธิภาพ token ไม่ใช่แค่เขียน prompt แล้วหวังว่าโมเดลจะเชื่อฟัง Spotify พิสูจน์แล้วว่าการเตือนในไฟล์ตั้งค่าอย่าง CLAUDE.md ว่าให้ส่งงานง่ายไปให้โมเดลถูก เป็นเพียงข้อแนะนำที่โมเดลมักลืมเมื่อเผชิญงานซับซ้อน ดังนั้นพวกเขาจึงยกระดับจากคำเตือนเป็นข้อบังคับ ผ่าน Hook ที่ชื่อว่า PreToolUse ใน Claude Code และปลั๊กอินที่ตั้งชื่อว่า shunt
shunt ทำหน้าที่เป็นยามเฝ้าประตูระดับมิลลิวินาที ทุกครั้งที่ Claude จะเรียกเครื่องมืออ่านไฟล์ หากมันพยายามเปิดไฟล์เกิน 350 บรรทัด หรือใช้คำสั่งในเทอร์มินัลอย่าง cat, head, tail, less, more กับไฟล์ใหญ่ shunt จะตัดการทำงานทันทีและบังคับให้เรียก bulk-reader แทน ยอมให้ผ่านเฉพาะกรณีที่ Claude ระบุช่วงบรรทัดชัดเจนหรือใช้ pipe กรองเนื้อหา การออกแบบสามชั้นนี้ปิดลูปทั้ง Hook, Claude Code Skill และ shell script ทำให้การประหยัด token ไม่ใช่ความหวัง แต่เป็นนโยบายที่โมเดลฝ่าฝืนไม่ได้
ผลลัพธ์จริงจาก Spotify กับบทเรียนสำหรับทีมองค์กรที่อยากลดต้นทุน AI
ตามข้อมูลของ Dimitri Mazmanov การทดลองใน Java monorepo ภายในของ Spotify แสดงว่าเมื่อให้ bulk-reader กรองและสรุปไฟล์ก่อนส่งให้ Claude ปริมาณ token ฝั่ง Claude ลดลงเฉลี่ยประมาณ 90 เปอร์เซ็นต์ นี่คือหลักฐานตรงว่าการออกแบบเส้นทางงานใหม่สามารถลดต้นทุน AI ได้อย่างมีนัยสำคัญ โดยไม่จำเป็นต้องลดคุณภาพงานหลักหรือย้ายงานทั้งหมดไปอยู่บนโมเดลเล็ก
อย่างไรก็ตาม บทเรียนสำคัญคือโมเดล AI ราคาถูกไม่เหมาะกับงานทุกประเภท ทดลองของ Spotify พบว่าโมเดลเบาอาจช่วยตรวจชื่อฟังก์ชันหรือรูปแบบโค้ดได้ดี แต่กลับพลาดประเด็นซ่อนเร้นด้าน thread-safety และปัญหาความปลอดภัย ทีมองค์กรจึงควรมองกลยุทธ์หลายโมเดลเป็นการแบ่งงาน ไม่ใช่การแทนที่ โมเดลใหญ่ยังควรรับผิดชอบงานออกแบบสถาปัตยกรรม การตัดสินใจด้านระบบ และการรีวิวความเสี่ยง ส่วนงานอ่านไฟล์จำนวนมาก งานเขียนโค้ดซ้ำรูปแบบ และงาน I/O ให้ส่งต่อให้โมเดลเล็ก เพื่อให้ค่าใช้จ่าย AI เติบโตช้ากว่ามูลค่าทางธุรกิจที่ระบบสร้างขึ้น
นอกเหนือจาก Spotify: ทีมเล็กก็ใช้กลยุทธ์หลายโมเดลสร้างธุรกิจได้
แนวคิดใช้หลายโมเดลทำงานร่วมกันไม่ได้จำกัดเฉพาะองค์กรใหญ่ กรณีของ John Boyle ผู้ก่อตั้ง Music for Business Finder แสดงให้เห็นว่าคนเดียวสามารถใช้ทีมบอต AI หลายตัวสร้างแพลตฟอร์มจริงได้ เขาผสมผสานโมเดลอย่าง Gemini, Claude และบอตอัตโนมัติ เพื่อดูแลทั้ง frontend backend ออกแบบกราฟิก ทำ SEO และการส่งอีเมลการตลาดอัตโนมัติ ทำให้โปรเจกต์ที่ปกติอาจต้องใช้ทีมสี่คน ถูกสร้างเสร็จในเวลาสั้น
เขายังตั้งบอตวิเคราะห์อัตโนมัติคอยเฝ้าดู session ผู้ใช้ตลอด 24 ชั่วโมง เพื่อชี้จุดติดขัดด้าน UX และเสนอการปรับปรุง ประเด็นสำคัญคือ คนหนึ่งคนทำหน้าที่เป็นคนประสานงานความรู้ domain และกำหนดว่าแต่ละโมเดลควรทำงานไหน ซึ่งสอดคล้องกับแนวคิดของ Spotify ที่แยกงานตามความซับซ้อน แทนที่จะโยนทุกอย่างให้โมเดลเดียว แนวทางนี้เปิดโอกาสให้ทีมเล็กและสตาร์ทอัพสามารถปรับแต่งค่าใช้จ่าย AI ให้สอดคล้องกับรายได้ ขณะเดียวกันก็ยังใช้ AI เป็นกำลังหลักในการพัฒนาผลิตภัณฑ์
