จากการปรับเพิ่มอันดับเครดิตไปจนถึงการชำระเงิน: ภาพลวงตาของอุปสงค์ในการหลอมรวมแบบจำลอง
chaincatcherI. Model Fusion คืออะไร?
ในเดือนมิถุนายน ปี 2026 ตลาด AI ได้เห็นผลิตภัณฑ์สองตัวที่ชื่อว่า "Fusion" ปรากฏขึ้นภายในเวลาไม่ถึงสามสัปดาห์
เมื่อวันที่ 12 มิถุนายน OpenRouter ได้เปิดตัว Fusion Router ภายใต้สโลแกน " ก้าวข้ามขีด จำกัดด้านประสิทธิภาพด้วย Fusion " ในการประเมินเชิงลึกของ DRACO กลุ่มโมเดลที่ประกอบด้วย Fable 5 และ GPT-5.5 ทำคะแนนได้ 69.0 คะแนน ซึ่งสูงกว่า 65.3 คะแนนของ Fable 5 รุ่นเดียว จุดขายของ OpenRouter นั้นตรงไปตรงมา: เมื่อโมเดลเดียวไม่ดีพอ โมเดลหลายรุ่นก็สามารถตอบคำถามเดียวกันได้ จากนั้นผู้รีวิวจะทำการเปรียบเทียบและสังเคราะห์โมเดลเหล่านั้น

เมื่อวันที่ 29 มิถุนายน Cognition ได้เปิดตัว Devin Fusion แต่ใช้ชื่อว่า " ประสิทธิภาพระดับแนวหน้าในราคาที่ต่ำกว่า 35% " แทนที่จะใช้โมเดลหลายตัวทำงานซ้ำๆ กันทั้งหมด Devin Fusion จะให้โมเดลส่วนหน้าจัดการการวางแผนและการตัดสินใจ ปล่อยให้การทดสอบ การปรับแต่งเชิงกล และงานอื่นๆ เป็นหน้าที่ของโมเดลส่วนหลังที่มีราคาถูกกว่า และสลับโมเดลแบบไดนามิกในระหว่างการทำงาน

คำเดียวกันนี้ชี้ให้เห็นถึงตรรกะทางเศรษฐกิจสองอย่างที่ตรงกันข้าม OpenRouter ใช้การคำนวณมากขึ้นเพื่อซื้อ caps ที่สูงขึ้น ใน ขณะที่ Cognition พยายามลดการคำนวณที่มีราคาแพงในขณะที่ยังคงรักษาคุณภาพเดิมไว้ ความแตกต่างนี้ชัดเจนกว่าตารางจัดอันดับโมเดลใดๆ ข้อเสนอทางเทคนิคของการรวมโมเดลนั้นเป็นความจริง: ความพยายามหลายครั้งมีโอกาสที่จะเหนือกว่าความพยายามเพียงครั้งเดียว แต่ สิ่งที่ตลาดให้รางวัลอย่างแท้จริงไม่ใช่ "การเรียกใช้โมเดลมากขึ้น" แต่คือใครสามารถใช้เงินน้อยลงและส่งมอบได้เร็วกว่าหลังจากบรรลุเกณฑ์คุณภาพแล้ว
▲ รูปที่ 1: ฟิวชั่นสองประเภทในเดือนเดียวกัน บทความนี้กำหนดนิยามของ Model Fusion ว่าเป็นสถาปัตยกรรมที่แคบกว่า กล่าวคือ โมเดลหลายตัวทำงานเดียวกันแบบขนานกัน โมเดลเหล่านั้นจะได้รับการตรวจสอบและเปรียบเทียบผลลัพธ์ และสุดท้ายโมเดลหนึ่งจะส่งคำตอบออกมา Devin Fusion ไม่ตรงกับนิยามนี้ มันใกล้เคียงกับการกำหนดเส้นทางแบบไดนามิกและการมอบหมายงานมากกว่า ที่ถูกนำมาไว้ในตอนต้นเพราะตลาดใช้คำว่า "Fusion" เป็นคำทั่วไปสำหรับการจัดการหลายโมเดลทั้งหมด ในขณะที่ผลิตภัณฑ์ที่มีประสิทธิภาพอย่างแท้จริงมักจะห่างไกลจากนิยามที่แคบของ Model Fusion
การประเมินของเราค่อนข้างมองในแง่ร้าย: การรวมโมเดล (Model Fusion) เป็นเหมือนประกันคุณภาพราคาแพง มันอาจช่วยปรับปรุงประสิทธิภาพโดยรวมของงานบางอย่างได้ แต่แทบจะไม่สามารถผลักดันขีดจำกัดด้านต้นทุน คุณภาพ และความหน่วงให้สูงขึ้นได้อย่างแท้จริง มีงานเพียงไม่กี่งานเท่านั้นที่คุ้มค่ากับการซื้อประกันนี้ มันจะยังคงอยู่ แต่มีแนวโน้มที่จะเป็นฟีเจอร์ที่ถูกเรียกใช้ในความถี่ต่ำมากกว่าที่จะเป็นสถาปัตยกรรมเริ่มต้น และมีโอกาสน้อยที่จะกลายเป็นหมวดหมู่แบบสแตนด์อะโลน
II. ปัจจุบันมีตัวเลือกโมเดลใดบ้าง?
การพูดคุยเกี่ยวกับ Fusion มักจะวกเข้าสู่เรื่องการจัดอันดับความแม่นยำ แต่บริษัทต่างๆ ไม่ได้ซื้ออันดับในกระดานจัดอันดับ พวกเขาซื้อผลลัพธ์ที่ยอมรับได้สำหรับงานนั้นๆ โดยคำนึงถึงราคา ความหน่วง ความเป็นส่วนตัว และความเสถียร ด้วย ตราบใดที่มีรุ่นราคาประหยัดอยู่แล้ว...
เมื่อถึงจุดที่ธุรกิจยอมรับได้แล้ว การจ่ายเงินเพิ่มสำหรับฟีเจอร์ที่ "ฉลาดกว่า" อาจไม่คุ้มค่าทางเศรษฐกิจอีกต่อไป ประสิทธิภาพด้านต้นทุนคือแรงขับเคลื่อนที่แท้จริงในตลาดโมเดล
▲ รูปที่ 2: ความฉลาดของโมเดลและต้นทุนต่อภารกิจเดียว จุดที่น่าสนใจที่สุดบนมาตราส่วนลอการิทึม ไม่ใช่คะแนนสูงสุดในมุมบนขวา แต่เป็นจุดที่เบี่ยงเบนจากแนวโน้มราคา-ความสามารถ: จุดเหล่านี้เสนอความสามารถที่เพียงพอในราคาที่ต่ำกว่า และเป็นข้อยกเว้นด้านประสิทธิภาพสำหรับภาระงานเฉพาะ ในขณะที่ดัชนีรวมไม่สามารถตอบได้โดยตรงว่าโมเดลใดเหมาะสมที่สุดสำหรับการตรวจสอบโค้ด การวิจัยในประเทศจีน หรือการใช้งานภายใต้การกำกับดูแล แต่ก็เผยให้เห็นแนวโน้ม: อุปทานของโมเดลกำลังกลายเป็นสินค้าโภคภัณฑ์ และ "โมเดลที่แข็งแกร่งที่สุด" กำลังแยกตัวออกจาก "ตัวเลือกที่เหมาะสมที่สุด"
ปัจจุบันมีกลยุทธ์การซื้อหลักๆ สี่กลยุทธ์ในตลาดเพื่อแก้ไขปัญหาช่องว่างด้านคุณภาพเดียวกันนี้
แนวทางแรกคือการอัปเกรดโดยตรงไปยังโมเดลเดียวที่แข็งแกร่งกว่า วิธีนี้ง่ายที่สุดและตรวจสอบได้ง่ายที่สุด โดยทั่วไปแล้วยังคงเป็นตัวเลือกที่นิยมตราบใดที่ต้นทุนที่เพิ่มขึ้นเล็กน้อยของโมเดลระดับสูงนั้นต่ำกว่าต้นทุนของข้อผิดพลาดหรือการทำงานซ้ำ แนวทางที่สองคือการเพิ่มการคำนวณในระหว่างการทดสอบบนโมเดลเดียวกัน เช่น การขยายการอนุมาน ความสอดคล้องในตัวเอง หรือการสุ่มตัวอย่างหลายครั้ง แนวทางที่สามคือการกำหนดเส้นทาง การเรียงลำดับ และการมอบหมายงาน: ใช้โมเดลที่ถูกกว่าเพื่อจัดการส่วนที่ตรวจสอบได้หรือส่วนที่เป็นกลไกก่อน และอัปเกรดเฉพาะเมื่อพบปัญหา แนวทางที่สี่ ในความหมายที่แคบกว่า คือ การรวมโมเดล: การให้โมเดลหลายตัวตอบคำถามเดียวกันซ้ำๆ แล้วจึงสร้างคำตอบสุดท้ายโดยการตรวจสอบและสังเคราะห์โมเดลเหล่านั้น
ทั้งสี่วิธีสามารถ "แลกเปลี่ยนการคำนวณที่มากขึ้นกับคุณภาพ" ได้ แต่ความแตกต่างอยู่ที่ว่าใช้การคำนวณไปที่ใด การขยายแบบจำลองเดี่ยวจะให้การอนุมานที่ลึกกว่า การกำหนดเส้นทางจะให้การจัดสรรทรัพยากรที่แม่นยำกว่า ในขณะที่ Fusion จะให้คำตอบที่เป็นไปได้มากกว่า สามวิธีแรกจะเน้นงบประมาณไปที่ขั้นตอนที่มีแนวโน้มที่จะเปลี่ยนแปลงผลลัพธ์มากที่สุด อย่างไรก็ตาม Fusion จะจ่ายเงินสำหรับความคิดเห็นที่ซ้ำกันก่อน จากนั้นจึงเดิมพันว่าแบบจำลองการตรวจสอบสามารถระบุความแตกต่างที่ถูกต้องได้ แบบจำลองที่เป็นไปได้ต้องให้ข้อมูลที่เป็นอิสระเพียงพอ และผู้ตรวจสอบต้องสามารถรับรู้ข้อมูลนั้นได้
Fusion เป็นตัวเลือกเดียวที่สามารถทำงานได้ดีกว่าอีกสามตัวเลือก
การกำหนดเส้นทางพิสูจน์แล้วว่า ความแตกต่างของความสามารถระหว่างโมเดลต่างๆ นั้นเป็นโอกาสในการจัดตารางเวลาเป็นหลัก RouteLLM ลดต้นทุนได้มากกว่า 2 เท่าในบางการประเมินโดยไม่ลดทอนคุณภาพ Switchcraft ลดต้นทุนได้ 84% ด้วยความแม่นยำ 82.9% ซึ่งตามเอกสารระบุว่า จะช่วยประหยัดได้มากกว่า 3,600 ดอลลาร์ต่อคำขอหนึ่งล้านรายการ ผลลัพธ์ยังคงต้องได้รับการยืนยันซ้ำในปริมาณการใช้งานจริงขององค์กร แต่หลักการทางเศรษฐศาสตร์นั้นตรงไปตรงมา: แทนที่จะมีหลายโมเดลในการประชุม เพียงแค่กำหนดงานแต่ละอย่างให้กับโมเดลที่ถูกที่สุดและมีคุณสมบัติเหมาะสมที่สุด
นี่หมายความว่า ตลาดจะจัดการกับช่องว่างด้านคุณภาพก่อนเป็นอันดับแรก โดยผ่านการอัปเกรด การกำหนดเส้นทาง และการตรวจสอบความถูกต้อง และเมื่อวิธีการเหล่านี้ยังไม่เพียงพอ จึงจะมีเหตุผลให้ซื้อคำตอบที่เป็นไปได้เพิ่มเติมสำหรับ Fusion
III. เหตุใดการพัฒนาคะแนนจึงไม่เท่ากับการมีคุณค่า?
เนื่องจาก Fusion ต้องเอาชนะ อุปสรรคสามประการพร้อมกัน ได้แก่ คุณภาพที่เพิ่มขึ้นต้องชดเชยต้นทุนและเวลาแฝงที่เพิ่มขึ้น โมเดลที่ใช้ต้องให้ข้อมูลที่เป็นอิสระ และผู้ตรวจสอบต้องระบุคำตอบที่ดีกว่าได้อย่างสม่ำเสมอ หากสิ่งใดสิ่งหนึ่งล้มเหลว การปรับปรุงคะแนนจะไม่สามารถแปลงเป็นคุณค่าในการผลิตได้ ต้นทุนการคำนวณ: ต้องใช้งบประมาณและเวลาแฝงเพิ่มเติมเท่าใด การปรับปรุงคะแนนของ Fusion เป็นค่าใช้จ่ายในการคำนวณอย่างแน่นอน OpenRouter เรียกใช้โมเดลแผงหลายตัวพร้อมกัน จากนั้นผู้ตรวจสอบและโมเดลที่ผสานรวมจะสร้างคำตอบ กลุ่มควบคุมทั้งสามกลุ่มใน DRACO แสดงให้เห็นถึงการปรับปรุงคะแนน: Fable 5 + GPT-5.5 เพิ่มขึ้นจาก 65.3 เป็น 69.0; Opus 4.8 การรวมข้อมูลด้วยตนเองเพิ่มขึ้นจาก 58.8 เป็น 65.5; และกลุ่มโมเดลสามตัวต้นทุนต่ำเพิ่มขึ้นจาก 60.3 เป็น 64.7
อย่างไรก็ตาม การปรับปรุงการหลอมรวมตัวเองของ Opus นั้นดีกว่า ซึ่งบ่งชี้ว่าผลประโยชน์อาจมาจากการค้นหาและการสุ่มตัวอย่างเพิ่มเติมมากกว่าการเสริมความรู้ข้ามโมเดล ควรมีการเปรียบเทียบที่เป็นธรรมระหว่างความสอดคล้องในตัวเอง การอนุมานที่ยาวนานขึ้น และโมเดลตัวแทนเดี่ยวที่แข็งแกร่งภายใต้งบประมาณโทเค็นเดียวกัน งานวิจัยที่มีอยู่ยังแสดงให้เห็นว่าโมเดลหลายตัวแทนสามารถปรับปรุงประสิทธิภาพได้มากถึง 7.1 เปอร์เซ็นต์ โดยมีต้นทุนการคำนวณประมาณ 20 เท่า ด้วยงบประมาณเดียวกัน การถกเถียงและการผสมผสานตัวแทนจะมีประสิทธิภาพสูงกว่าความสอดคล้องในตัวเองเพียง 1.3 และ 2.7 เปอร์เซ็นต์ ตามลำดับ ในขณะที่การศึกษาอื่นที่มีโทเค็นการให้เหตุผลเท่ากันพบว่าโมเดลตัวแทนเดี่ยวมีประสิทธิภาพเทียบเท่าหรือดีกว่า ผลประโยชน์จากการทำงานร่วมกันจำนวนมากหายไปหลังจากมีการจัดเรียงบัญชีแยกประเภทการคำนวณ
▲ รูปที่ 3: การปรับปรุงเกณฑ์มาตรฐานและต้นทุนผลิตภัณฑ์ของ OpenRouter แผงควบคุมแบบ 3 โมเดลเริ่มต้นของ OpenRouter มีต้นทุน สูงกว่าแผงควบคุมที่สร้างขึ้นตามมาตรฐานประมาณ 4-5 เท่า และ ช้ากว่า 2-3 เท่า อย่างไรก็ตาม OpenRouter ไม่ได้เปิดเผยโทเค็น ต้นทุน และความหน่วงแฝงทั้งหมดสำหรับแต่ละการกำหนดค่า DRACO ทำให้ไม่สามารถระบุได้ว่าการปรับปรุง 3.7 จุดนั้นคุ้มค่าหรือไม่ การประเมินรวมเฉพาะงานข้อความภาษาอังกฤษธรรมดา 100 งาน โดยมีการกำหนดค่าที่เกี่ยวข้องกับ Fable เพียง 93 งานเท่านั้นที่เสร็จสมบูรณ์ การเปลี่ยนโมเดลการตรวจสอบสามารถเปลี่ยนคะแนนสัมบูรณ์ได้ 10-25 เปอร์เซ็นต์ ซึ่งพิสูจน์ได้ว่า Fusion สามารถปรับปรุงคะแนนได้ แต่ไม่ได้พิสูจน์ว่า Fusion ปรับปรุง ROI ในการผลิต
การเรียกใช้งานแบบเลือกเฉพาะส่วนที่จำเป็นจะช่วยลดต้นทุนได้เท่านั้น จากการประมาณการของ OpenRouter พบว่า ต้นทุนโดยรวมจะเพิ่มขึ้นประมาณ 1.03-1.04 เท่า เมื่ออัตราการเรียกใช้งานอยู่ที่ 1%; 1.30-1.40 เท่า เมื่ออยู่ที่ 10%; และ 1.75-2.00 เท่า เมื่ออยู่ที่ 25%
▲ รูปที่ 4: ภาพรวมทางเศรษฐศาสตร์ของการเรียกใช้ Fusion แบบเลือกสรร คำขอที่ยากที่สุดมีแนวโน้มที่จะกระตุ้น Fusion มากที่สุด แต่ระบบต้องรอสมาชิกในคณะกรรมการที่ช้าที่สุดก่อนที่จะทำการตรวจสอบและสร้างผลลัพธ์ตามลำดับ ดังนั้น ความล่าช้าจึงกระจุกตัวอยู่ที่งานที่มีค่ามากที่สุด การเรียกใช้จากหลายผู้จำหน่ายยังขยายพื้นที่ความล้มเหลว ความซับซ้อนของการตรวจสอบ และการเปิดเผยความเป็นส่วนตัว ต้นทุนของ Fusion ไม่ได้มีเพียงแค่ราคา API เท่านั้น แต่ยังรวมถึงเวลาที่รอและความเสี่ยงของระบบที่เพิ่มขึ้นด้วย ความสมบูรณ์ของข้อมูล: โมเดลหลายตัวให้ข้อมูลที่แตกต่างกันจริงหรือไม่? คุณค่าของ Fusion ขึ้นอยู่กับว่าโมเดลที่เสนอให้ข้อมูลที่เป็นอิสระหรือไม่ แต่โมเดลที่แตกต่างกันมักใช้คลังข้อมูลการฝึกอบรม แหล่งที่มาของเว็บเพจ และสมมติฐานที่ผิดพลาดร่วมกัน ในงานวิจัย สิ่งนี้จะนำไปสู่ "การฟอกขาวการอ้างอิง" : โมเดลหลายตัวสืบย้อนกลับไปยังแหล่งที่มาเดียวกัน แต่ถูกบรรจุเป็นหลักฐานอิสระหลายชิ้น หากระบบไม่เก็บรักษาที่มาและเส้นทางการค้นหาในระดับการอ้างสิทธิ์ ต้นทุน API จะเพิ่มขึ้นเกือบเป็นเส้นตรงตามจำนวนโมเดล แต่ความหลากหลายของหลักฐานไม่จำเป็นต้องเพิ่มขึ้น
ในบทความปี 2026 ของเขา เรื่อง *เมื่อใดที่การรวมโมเดลภาษาช่วยได้?* โจเซฟ เฉิน ผู้ร่วมก่อตั้งและซีอีโอของ KAIKAKU.AI ได้ศึกษาโมเดล 67 โมเดลจากผู้ให้บริการ 21 ราย ในงานคณิตศาสตร์แบบปลายเปิด ความน่าจะเป็นที่คาดการณ์ไว้ว่าโมเดลทั้งหมดจะตอบผิดพร้อมกันคือ 2.3% แต่ความน่าจะเป็นจริงสูงถึง 5.2% ซึ่งประมาณ 2.3 เท่าของค่าที่คาดการณ์ไว้ อัตราความล้มเหลวร่วมกันเพิ่มขึ้นเป็น 7.9% และ 12.7% ในงานรหัสการให้คะแนนและเวอร์ชันตอบอิสระของ GPQA-Diamond ตามลำดับ ด้วยคำถาม GPQA-Diamond 100 ข้อ ประมาณ 13 ข้อจะทำให้โมเดลผู้สมัครทั้งหมดตอบผิด ทำให้ไม่มีคำตอบที่ถูกต้องสำหรับการลงคะแนน การตรวจสอบ หรือการสังเคราะห์ ความแตกต่างของโมเดลในคำถามง่ายๆ จะเพิ่มค่ารวม ในขณะที่ในคำถามสำคัญๆ ที่ยากที่สุด โมเดลทั้งหมดอาจล้มเหลว การประเมินความน่าเชื่อถือ: ระบบสามารถระบุและสังเคราะห์คำตอบที่ดีกว่าได้หรือไม่? แม้ว่าคำตอบของผู้สมัครจะสอดคล้องกัน แต่คุณค่าก็ยังขึ้นอยู่กับการตรวจสอบ เมื่อผู้สมัครให้คำตอบที่สอดคล้องกัน ผู้ตรวจสอบอาจตีความข้อผิดพลาดที่เกี่ยวข้องว่าเป็นความมั่นใจสูง เมื่อผู้สมัครให้คำตอบที่แตกต่างกัน จำเป็นต้องใช้ความเชี่ยวชาญที่เพียงพอในการเลือกคำตอบที่ถูกต้อง นอกจากนี้ แบบจำลองแบบผสมอาจลบความคิดเห็นส่วนน้อยที่สำคัญออกไป หรือเขียนความขัดแย้งที่แท้จริงใหม่ให้กลายเป็นข้อสรุปที่ชัดเจนได้
ในงานเขียนโค้ด คอมไพเลอร์ การทดสอบ และการวิเคราะห์แบบคงที่ มักมีความน่าเชื่อถือมากกว่าความคิดเห็นของโมเดลอื่น ในงานสร้างสรรค์ การตรวจสอบและการสังเคราะห์สามารถลดความแตกต่างให้เหลือเพียงคำตอบเฉลี่ยได้ง่าย แม้แต่โมเดลการตรวจสอบสำเร็จรูปที่แข็งแกร่งที่สุดใน LitBench ก็ยังมี อัตราความสอดคล้องกับความชอบในการเขียนเชิงสร้างสรรค์ของมนุษย์เพียง 73% เท่านั้น เมื่อมีผู้ตรวจสอบภายนอกราคาไม่แพงสำหรับงานนั้น หรือเมื่อ "ความดี" ขึ้นอยู่กับการตัดสินใจส่วนตัว การปรับปรุงคะแนนของ Fusion จึงยากที่จะแปลงเป็นมูลค่าที่ได้รับจากการจ่ายเงิน
IV. ใครจะเป็นผู้จ่ายค่า Fusion?
ความต้องการใช้งาน Fusion ขึ้นอยู่กับอุปสรรคสองประการ: ประการแรกคือ งานนั้นจะได้รับประโยชน์จากโมเดลหลายแบบหรือไม่ และประการที่สองคือ ประโยชน์ที่ได้รับนั้นเพียงพอที่จะสร้างรายได้ที่ยั่งยืนหรือไม่ ประการแรกเป็นเรื่องทางเทคนิค ในขณะที่ประการที่สามเป็นเรื่องของตลาด จากความสามารถในการใช้งานทางเทคนิคไปจนถึงความคุ้มค่าทางเศรษฐกิจ Fusion ต้องการให้ความน่าจะเป็นในการแก้ไขข้อผิดพลาดคูณด้วยการสูญเสียที่หลีกเลี่ยงได้จากข้อผิดพลาดเพียงครั้งเดียว ต้องมีมากกว่าต้นทุน ความล่าช้า ความซับซ้อนในการดำเนินงาน และความเสี่ยงด้านความเป็นส่วนตัวของการเพิ่ม API ใหม่
คะแนนมาตรฐานไม่สามารถตอบคำถามเรื่องกำไรและขาดทุนนี้ได้ การผสมผสานโมเดลจะใช้ได้ผลก็ต่อเมื่อต้นทุนของความผิดพลาดสูง โมเดลที่ใช้เป็นตัวอย่างมีเส้นทางการค้นหาที่เสริมกัน ขาดตัวตรวจสอบภายนอกที่ราคาถูกกว่า และธุรกิจยอมรับความล่าช้าและความเสี่ยงจากผู้ขายได้ และผลลัพธ์สุดท้ายควรได้รับการยืนยันจากมนุษย์หรือหลักฐานภายนอก
▲ ภาพที่ 5: จากการประยุกต์ใช้เทคโนโลยีสู่ความต้องการที่ยั่งยืน สิ่งที่ ตรงตามเกณฑ์เหล่านี้ส่วนใหญ่ได้แก่ การวิจัยที่มีมูลค่าสูงและการตรวจสอบอย่างรอบคอบ การตรวจสอบสถาปัตยกรรมและความปลอดภัย และ "ความเห็นที่สอง" ก่อนการตัดสินใจที่ไม่สามารถย้อนกลับได้ สิ่ง เหล่านี้มีจุดร่วมกันคือ ข้อจำกัดที่ไม่สมบูรณ์ ต้นทุนสูงของการละเลย และคุณค่าที่แท้จริงของแนวทางที่เป็นอิสระ ในทางกลับกัน โค้ดทั่วไป แอปพลิเคชันที่ใช้งานได้ทันที เวิร์กโฟลว์ที่มีปริมาณงานสูง กำไรต่ำ และงานที่ตรวจสอบได้โดยตรงด้วยการทดสอบหรือกฎเกณฑ์ โดยทั่วไปไม่จำเป็นต้องมีการผสานรวม หน่วยงานกำกับดูแลอาจปฏิเสธแผงควบคุมจากหลายผู้ขายเนื่องจากขอบเขตของข้อมูลและข้อกำหนดการตรวจสอบ จากความเต็มใจที่จะจ่ายสู่ความต้องการที่ยั่งยืน ประโยชน์ทางเทคโนโลยีสามารถสร้างความเต็มใจที่จะจ่ายสูง แต่ไม่ได้หมายความว่าจะเกิดความต้องการที่ปรับขนาดได้ เพื่อให้ความต้องการที่ยั่งยืนเกิดขึ้นได้จริง การสูญเสียจากข้อผิดพลาดต้องสามารถวัดปริมาณได้ งานต้องเกิดขึ้นซ้ำๆ ต้องมีการกำหนดความรับผิดชอบด้านงบประมาณที่ชัดเจนภายในองค์กร และการผสานรวมต้องมีประสิทธิภาพเหนือกว่าผู้เชี่ยวชาญที่เป็นมนุษย์ โมเดลแบบหน่วยเดียวที่แข็งแกร่ง และการตรวจสอบจากภายนอกอย่างสม่ำเสมอ อย่างไรก็ตาม งบประมาณสำหรับการตรวจสอบวิเคราะห์มักจะไหลไปยังนักวิเคราะห์และแหล่งข้อมูลที่เชื่อถือได้ งบประมาณด้านความปลอดภัยมักจะไหลไปยังการตรวจสอบโดยผู้เชี่ยวชาญ และการตัดสินใจที่ไม่สามารถย้อนกลับได้เกิดขึ้นน้อยเกินไป
ดังนั้น เราจึงไม่มองในแง่ดีเกี่ยวกับบริษัทที่ให้บริการเพียงแค่ตัวห่อหุ้มโมเดลหลายแบบ เรียกใช้แผงควบคุมโดยค่าเริ่มต้น หรือมองว่าอัลกอริทึมการเลือกโมเดลแบบคงที่เป็นปราการด่านป้องกัน การเชื่อมต่อ API นั้นง่ายต่อการทำซ้ำ และกลยุทธ์แบบตายตัวจะไม่มีประสิทธิภาพอย่างรวดเร็วเมื่อความสามารถของโมเดลและราคาของโมเดลเปลี่ยนแปลงไป หากไม่ทราบอัตราข้อผิดพลาดและจำนวนครั้งที่ Fusion แก้ไขข้อผิดพลาดจริง ๆ ก็เป็นไปไม่ได้ที่จะกำหนดราคาประกันนี้ ผู้ที่ควบคุมผลลัพธ์ที่แท้จริงมีแนวโน้มที่จะได้รับมูลค่ามากกว่า ได้แก่ แพลตฟอร์มเกตเวย์และเอเจนต์ แอปพลิเคชันในแนวดิ่ง เจ้าของเวิร์กโฟลว์ และผลิตภัณฑ์การประเมินและการตรวจสอบ พวกเขารู้ต้นทุนของข้อผิดพลาด สามารถสังเกตผลลัพธ์ และสามารถเพิ่มประสิทธิภาพกลยุทธ์การกระตุ้นได้ สิ่งที่ยากอย่างแท้จริงที่จะทำซ้ำไม่ใช่รายการแผงควบคุม แต่เป็นการพิจารณาว่าเมื่อใดไม่ควรเรียกใช้ Fusion การตรวจสอบความถูกต้องของตลาด: ตลาดสาธารณะไม่เพียงพอที่จะกำหนดขนาดของความต้องการ Fusion แต่ก็แสดงให้เห็นแล้วว่ามีการใช้งานอย่างไร Perplexity Model Council มีให้บริการเฉพาะผู้ใช้ Max และ Enterprise Max ที่จ่าย 200 ดอลลาร์ต่อเดือน ผู้ใช้เลือกโมเดลสามแบบบนเว็บด้วยตนเองสำหรับการวิจัยการลงทุน การตัดสินใจที่ซับซ้อน และการตรวจสอบความถูกต้องของข้อมูล ตัวอย่างการใช้งานสาธารณะ ได้แก่ การบูรณาการ Model Council เข้ากับเวิร์กโฟลว์การวิจัยหุ้นผ่านระบบอัตโนมัติของเบราว์เซอร์ Mixture of Agents ของ Hermes นำเสนอ Fusion เป็นโมเดลเสมือนที่เลือกได้ภายในเอเจนต์: ผู้ใช้สามารถอัปเกรดเป็นปัญหาที่ยากขึ้นเพียงปัญหาเดียวผ่านทาง /moa หรือเปิดใช้งานอย่างต่อเนื่องในเซสชันที่ซับซ้อน โดยมีการวิเคราะห์จากโมเดลอ้างอิงหลายโมเดล และตัวรวมข้อมูลจะเรียกใช้เครื่องมือเพื่อทำงานให้เสร็จสมบูรณ์ ต่อมา Hermes ได้ลดความถี่การกระจายข้อมูลเริ่มต้นและนำข้อเสนอแนะจากโมเดลก่อนหน้ามาใช้ซ้ำเพื่อควบคุมต้นทุน ตัวอย่างเหล่านี้แสดงให้เห็นว่าความต้องการที่แท้จริงของ Fusion นั้นกระจุกตัวอยู่ในงานที่มีความถี่ต่ำและยาก เช่น การวิจัย การแก้ไขข้อบกพร่อง การตรวจสอบ และการตัดสินใจที่สำคัญ การใช้งานโดยทั่วไปคือการอัปเกรดเชิงรุกหลังจากที่โมเดลเดียวพบปัญหาคอขวด มากกว่ากระบวนการอัตโนมัติที่มีความถี่สูงซึ่งเปิดใช้งานโดยค่าเริ่มต้น หลักฐานที่มีอยู่พิสูจน์ได้ว่าความต้องการนี้มีอยู่จริง แต่ข้อมูลที่เปิดเผยต่อสาธารณะยังไม่เพียงพอที่จะระบุได้ว่าสามารถสร้างตลาดแบบชำระเงินขนาดใหญ่ที่เป็นอิสระได้หรือไม่
V. อนาคตของฟิวชั่น
แม้ว่าการลดลงของต้นทุนการอนุมานจะดูเหมือนเป็นประโยชน์ต่อ Fusion แต่ในขณะเดียวกันก็ลดต้นทุนของโมเดลเดี่ยวที่มีประสิทธิภาพสูง การกำหนดเส้นทาง และการตรวจสอบความถูกต้องภายนอก ลงด้วย Fusion ไม่ได้แข่งขันกับโมเดลแบบเก่า แต่แข่งขันกับการพัฒนาโมเดลเดี่ยวรุ่นใหม่และพื้นฐานการจัดการกระบวนการอย่างต่อเนื่อง
Devin Fusion ของ Cognition แสดงให้เห็นถึงทิศทางของการแข่งขันนี้: ปล่อยให้โมเดลที่มีราคาแพงอยู่ในขั้นตอนการตัดสินใจ และมอบหมายงานเชิงกลที่ตรวจสอบได้ให้กับโมเดลที่มีราคาถูกกว่า ในการทดสอบด้วยตนเองของผู้จำหน่าย คะแนนโดยรวมของ Fusion + Fable 5 เพิ่มขึ้นเล็กน้อยจาก 57.0 เป็น 57.6 โดยต้นทุนเฉลี่ยลดลงจาก 5.12 ดอลลาร์เหลือ 3.00 ดอลลาร์ อย่างไรก็ตาม ในกรณีศึกษาที่เผยแพร่ทั้งห้ากรณี แม้ว่าต้นทุนจะลดลง 25%-62% แต่คะแนนของงานกลับผันผวนระหว่าง +12 ถึง -27 การปรับโครงสร้าง ES6 ที่กำหนดไว้อย่างดีและผ่านการทดสอบอย่างละเอียดเพิ่มขึ้นจาก 98 เป็น 100 คะแนน ฟังก์ชัน React/Redux ที่อาศัยความเข้าใจปฏิสัมพันธ์และข้อกำหนดโดยนัย เมื่อมอบหมายผิดวิธี คะแนนจะลดลงจาก 54 เหลือ 27 คะแนน
▲ รูปที่ 6: คะแนนและต้นทุนของงาน Devin Fusion ตัวอย่างเหล่านี้ถูกเลือกโดยผู้ขายและไม่ได้แสดงถึงการกระจายโดยรวม แต่ชี้ให้เห็นอย่างชัดเจนถึงสิ่งต่อไปนี้: ความสามารถหลักของระบบหลายโมเดลในอนาคตไม่ใช่การเรียกใช้โมเดลเพิ่มเติม แต่เป็นการกำหนดขอบเขตการลดระดับที่ถูกต้อง งานเชิงกลที่ตรวจสอบได้สามารถมอบหมายให้กับโมเดลที่ราคาถูกกว่า ในขณะที่งานที่ต้องใช้การตัดสินใจอย่างเข้มข้นจะต้องปล่อยให้เป็นหน้าที่ของโมเดลที่ล้ำสมัย OpenRouter ขาย "ความฉลาดที่มากกว่า" ในขณะที่ Cognition ขาย "ความฉลาดที่เทียบเท่ากันในราคาที่ต่ำกว่า" ข้อเสนอที่สองนั้นใกล้เคียงกับทิศทางระยะยาวมากกว่า ยิ่งระบบใกล้เคียงกับเศรษฐศาสตร์การผลิตมากเท่าใด ก็ยิ่งไม่เหมือนกับ Model Fusion ในความหมายแคบๆ และยิ่งคล้ายกับการกำหนดเส้นทาง การมอบหมายงาน และการตรวจสอบมากขึ้นเท่านั้น
ในช่วงปลายเดือนกรกฎาคม รายงานข่าวระบุว่า Stripe กำลังเจรจาเพื่อเข้าซื้อกิจการ OpenRouter ในราคาประมาณ 10 พันล้านดอลลาร์สหรัฐฯ แม้ว่าข้อตกลงยังไม่ได้รับการยืนยันก็ตาม สัญญาณนี้ไม่ควรตีความว่า Fusion ได้รับการยอมรับจากตลาดแล้ว เพราะคุณค่าหลักของ OpenRouter ไม่ได้อยู่ที่แผงควบคุมใดแผงหนึ่งโดยเฉพาะ แต่ขึ้นอยู่กับเลเยอร์การโทรที่เป็นกลางซึ่งเชื่อมต่อนักพัฒนามากกว่า 5 ล้านคนกับโมเดลมากกว่า 400 โมเดล Stripe ให้บริการด้านการเรียกเก็บเงิน ภาษี และการควบคุมความเสี่ยงสำหรับ OpenRouter อยู่แล้ว และอนุญาตให้นักพัฒนาสร้างบัญชี รับคีย์ API และเชื่อมต่อกับการชำระเงินโดยตรงผ่าน Stripe Projects สิ่งที่ Stripe น่าจะเข้าซื้อคือเกตเวย์ธุรกรรมสำหรับการอนุมาน AI: OpenRouter ควบคุมการเลือกโมเดล การใช้โทเค็น และต้นทุน ในขณะที่ Stripe จัดการเรื่องราคา การเรียกเก็บเงิน และการชำระเงิน นี่เป็นสัญญาณของตลาดสำหรับการตัดสินคุณค่าที่กล่าวถึงก่อนหน้านี้: คุณค่าในยุคหลายโมเดลมีแนวโน้มที่จะยังคงอยู่ในเลเยอร์การจัดการ ซึ่งสามารถสังเกตงาน จัดสรรการโทร และดำเนินการชำระเงินให้เสร็จสมบูรณ์ Fusion เป็นเพียงกลยุทธ์การอัปเกรดที่มีต้นทุนสูงบนพื้นฐานนั้น
ระบบมัลติโมเดลในอนาคตจะไม่เรียกใช้แผงควบคุมโดยอัตโนมัติ แต่จะประเมินความยากของงาน ต้นทุนการตรวจสอบ และค่าปรับความผิดพลาดก่อน การค้นหาความแตกต่างแบบมัลติโมเดลจะดำเนินการก็ต่อเมื่อโมเดลเดี่ยวที่แข็งแกร่งกว่า การอนุมานแบบขยาย และเครื่องมือภายนอกไม่เพียงพอ อัตราการกระตุ้น อัตราความสำเร็จที่เพิ่มขึ้น และต้นทุนที่ตรวจสอบแล้วต่อหน่วยผลลัพธ์เป็นตัวชี้วัดผลิตภัณฑ์ที่มีความหมายเพียงอย่างเดียว การรวมโมเดลจะยังคงเป็นคุณสมบัติที่มีความถี่ต่ำ แทนที่จะกลายเป็นสถาปัตยกรรมเริ่มต้นหรือหมวดหมู่แบบแยกต่างหาก
VI. แหล่งข้อมูล
OpenRouter: ประสิทธิภาพเหนือกว่า Frontier ด้วย Fusion
เอกสารประกอบการใช้งาน OpenRouter Fusion Router
Cognition: Devin Fusion --- ประสิทธิภาพระดับแนวหน้าในราคาที่ต่ำกว่า 35%
Microsoft Research: Switchcraft --- เราเตอร์โมเดล AI สำหรับการเรียกใช้เครื่องมือ Agentic
การผสมผสานโมเดลภาษาจะมีประโยชน์เมื่อใด?
การให้เหตุผลแบบหลายเอเจนต์ช่วยเพิ่มประสิทธิภาพการคำนวณ
ระบบ LLM แบบเอเจนต์เดี่ยวมีประสิทธิภาพเหนือกว่าระบบแบบหลายเอเจนต์ในการให้เหตุผลแบบหลายฮอปภายใต้งบประมาณโทเค็นการคิดที่เท่ากัน
การผสมผสานของเอเจนต์ช่วยเพิ่มขีดความสามารถของแบบจำลองภาษาขนาดใหญ่
RouteLLM: เรียนรู้การกำหนดเส้นทาง LLM ด้วยข้อมูลการตั้งค่า
LitBench: เกณฑ์มาตรฐานสำหรับการประเมินงานเขียนเชิงสร้างสรรค์
การเปรียบเทียบแบบจำลองการวิเคราะห์ปัญญาประดิษฐ์
ราคาของความก้าวหน้า: ผลตอบแทนด้านราคา และอนาคตของปัญญาประดิษฐ์
ความสับสน: สภาจำลองคืออะไร?
ตัวอย่างการใช้งาน Perplexity: สภาแบบจำลองสำหรับการวิจัยทางการเงิน
ตัวแทนเฮอร์เมส: เอกสารประกอบจากตัวแทนหลายราย
Stripe สนับสนุนการเข้าถึงโมเดล AI ระดับโลกของ OpenRouter
Axios: อะไรอยู่เบื้องหลังข่าวการย้ายไปใช้ OpenRouter ของ Stripe
เนื้อหานี้จัดทำขึ้นโดยมีวัตถุประสงค์เพื่อแจ้งข้อมูลและให้ความรู้เท่านั้น และไม่ถือว่าเป็นคำแนะนำด้านการลงทุนที่เกี่ยวข้องกับ BTCC แต่อย่างใด BTCC ใช้ความพยายามอย่างเต็มที่ แต่ไม่สามารถรับประกันความจริงแท้ ความถูกต้อง หรือความเป็นต้นฉบับของเนื้อหาข้างต้นได้