Deep Dive: OpenRouter Fusion model panel routing

ถ้า Claude Fable 5 ใช้ไม่ได้ เราควรหา “โมเดลเทพตัวใหม่” หรือควรเปลี่ยนวิธีคิดเรื่อง AI stack ทั้งระบบ?

OpenRouter เพิ่งเปิดตัว Fusion และผมว่าข่าวนี้น่าสนใจมาก เพราะมันมาต่อจากบทเรียน Fable 5 พอดีครับ

ข่าว Fable 5 ก่อนหน้านี้สอนเราว่า: ถ้าธุรกิจผูก workflow สำคัญไว้กับโมเดลเดียว วันหนึ่งโมเดลนั้นอาจหายไปได้ ไม่ว่าจะเพราะ policy, export control, safety response, region limit, provider decision หรือ incident อื่น ๆ

ส่วน Fusion สอนอีกฝั่งหนึ่ง:

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

นี่ไม่ใช่แค่ข่าว benchmark ครับ

มันเป็นสัญญาณว่า AI ในธุรกิจเริ่มขยับจาก “เลือกโมเดลที่เก่งสุด” ไปสู่ “ออกแบบระบบ routing ของงาน”

OpenRouter Fusion คืออะไร

Fusion คือ server-side tool/API ของ OpenRouter ที่ให้เราส่ง prompt หนึ่งชุดไปยังหลายโมเดลพร้อมกัน

จากนั้นระบบจะให้ judge model อ่านคำตอบของแต่ละโมเดล แล้วสรุปเป็น structured analysis เช่น:

• อะไรที่หลายโมเดลเห็นตรงกัน
• อะไรที่คำตอบขัดกัน
• โมเดลไหนเห็นบางประเด็นที่ตัวอื่นไม่เห็น
• จุดบอดคืออะไร
• คำตอบสุดท้ายควรประกอบจากข้อมูลไหน

ถ้าอธิบายแบบบ้าน ๆ:

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

OpenRouter ทำให้ workflow นี้เรียกผ่าน API ได้เหมือนเรียกโมเดลตัวเดียว เช่นใช้ model slug openrouter/fusion หรือใช้ server tool { "type": "openrouter:fusion" }

ตัวเลขที่ทำให้คนหันมามอง

OpenRouter ทดสอบ Fusion บน DRACO ซึ่งเป็น benchmark สำหรับ deep research tasks ของ Perplexity

DRACO ไม่ได้วัดแค่ตอบถูกแบบ trivia แต่ดูหลายมิติ เช่น factual accuracy, breadth/depth, presentation quality และ citation quality

ผลที่ OpenRouter รายงานมีหลายจุดที่น่าสนใจ:

• Fusion แบบ Fable 5 + GPT-5.5 โดยมี Opus 4.8 เป็น synthesizer ได้ 69.0%
• Claude Fable 5 เดี่ยวได้ 65.3%
• Opus 4.8 + GPT-5.5 + Gemini 3.1 Pro ได้ 68.3%
• Budget panel: Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro ได้ 64.7%
• GPT-5.5 เดี่ยวได้ 60.0%
• Claude Opus 4.8 เดี่ยวได้ 58.8%

จุดที่น่าสนใจที่สุดสำหรับผมไม่ใช่แค่ top score ครับ

แต่คือ budget panel ที่ประกอบด้วยโมเดลที่ไม่ใช่ตัวท็อปสุด กลับทำคะแนนใกล้ Fable 5 และชนะโมเดลเดี่ยวบางตัวที่แพงกว่า

นี่คือสัญญาณว่า “ความหลากหลายของ reasoning path” เริ่มมีมูลค่าจริง

โมเดลแต่ละตัวอาจมี blind spot คนละแบบ ตัวหนึ่งเก่ง structured reasoning ตัวหนึ่งหา source ได้ดีกว่า ตัวหนึ่งระวัง contradiction มากกว่า ตัวหนึ่งอาจเห็นมุมที่อีกตัวไม่หยิบขึ้นมา

พอเอามารวมกัน แล้วมี judge ที่ดี คำตอบสุดท้ายอาจแข็งแรงกว่าโมเดลเดียวที่ฉลาดมากแต่คิดอยู่ใน pattern เดียว

แต่ Fusion ไม่ใช่ไม้กายสิทธิ์

ตรงนี้ต้องพูดให้ชัดครับ

OpenRouter เองก็เขียนใน FAQ ว่า Fusion ไม่ใช่ drop-in replacement for Fable

เหตุผลคือ benchmark นี้วัด DRACO deep research task ไม่ใช่งาน long-horizon agent ที่ต้องทำงานยาว ๆ หลายขั้นตอนหลายชั่วโมงหรือหลายวัน

และผล Fable-related scores ก็มี caveat สำคัญ: 7 ใน 100 tasks ไม่ได้ complete เพราะ Fable 5 content filters block งานเหล่านั้น ดังนั้นคะแนน Fable เกี่ยวข้องกับ 93 scored tasks ไม่ใช่ 100 tasks เต็มเหมือนบางโมเดลอื่น

อีกอย่าง Fusion server tool ยังเป็น beta ตาม docs API และ behavior อาจเปลี่ยนได้

แถมเมื่อ Fusion ถูกเรียกจริง OpenRouter บอกว่า process อาจช้ากว่า call ปกติประมาณ 2-3 เท่า เพราะต้องรอหลายโมเดลตอบ แล้วเอาผลไปสังเคราะห์

ดังนั้นถ้าใครอ่านแล้วสรุปว่า “ต่อไปไม่ต้องใช้โมเดลดี ๆ แล้ว เอาหลายโมเดลถูก ๆ มารวมกันก็พอ” ผมว่าข้ามขั้นไปหน่อยครับ

คำตอบที่ถูกกว่าคือ:

Fusion ทำให้เรามี อีกระดับหนึ่งของ reasoning สำหรับงานที่คุ้มจะจ่ายเวลาและต้นทุนเพิ่ม

บทเรียนจริง: อย่าเลือกโมเดล ให้เลือก routing

หลายทีมยังคิดเรื่อง AI แบบ leaderboard:

โมเดลไหนเก่งสุดตอนนี้?

คำถามนี้ยังมีประโยชน์ครับ แต่ไม่พอแล้ว

ถ้าเราเอา AI ไปใช้กับงานจริงของธุรกิจ คำถามควรเปลี่ยนเป็น:

งานแบบไหนควรใช้โมเดลไหน และเมื่อไหร่ควรให้หลายโมเดลช่วยกันคิด?

ตัวอย่าง routing แบบ practical:

1) งาน routine ใช้โมเดลเร็วและถูก

เช่น สรุปข้อความทั่วไป ร่างอีเมลภายใน จัดหมวดข้อมูลเบื้องต้น หรือแปลง format

งานกลุ่มนี้ไม่ต้องใช้ Fusion ทุกครั้ง ถ้าเอาหลายโมเดลมาช่วยทุกเรื่อง เราจะเสีย latency และ cost โดยไม่จำเป็น

2) งาน research ใช้โมเดลที่ค้นหาและอ้างอิงได้ดี

เช่น เทียบ vendor, หา market signal, สรุป policy, วิเคราะห์ competitor, หรือเตรียม briefing ก่อนตัดสินใจ

งานแบบนี้เริ่มเหมาะกับแนวคิดหลายมุมมอง เพราะ source quality สำคัญ และ blind spot อาจแพง

3) งานตัดสินใจแพง ใช้ panel

เช่น architecture decision, pricing strategy, legal/policy overview, due diligence, product comparison หรือคำถามที่ถ้าตอบผิดจะเสียเงิน เสียเวลา หรือเสียชื่อเสียง

นี่คือพื้นที่ที่ Fusion น่าสนใจ

ไม่ใช่เพราะ “หลายโมเดลต้องถูกเสมอ” แต่เพราะเราต้องการเห็น consensus และ contradiction ก่อนตัดสินใจ

4) งานเสี่ยงสูง ต้องมี human approval

ถ้าเกี่ยวกับเงิน ลูกค้า กฎหมาย การแพทย์ ความปลอดภัย ข้อมูลส่วนตัว หรือการโพสต์สาธารณะ AI ไม่ควรจบงานเองแบบเงียบ ๆ

Fusion อาจช่วยคิด แต่คนยังต้อง approve

ระบบต้องเก็บ proof ว่า AI ใช้ model อะไร ดู source ไหน สรุปอะไร และมนุษย์อนุมัติจากหลักฐานอะไร

ต่อจากบทเรียน Fable 5

ข่าว Fable 5 ถูก suspend สอนว่า single-model dependency เป็นความเสี่ยงจริง

ถ้า workflow สำคัญ hard-code อยู่กับโมเดลเดียว พอโมเดลนั้น unavailable งานก็หยุดได้ทันที

Fusion เพิ่มอีกบทเรียน:

แม้โมเดลหลักยังอยู่ เราก็ไม่จำเป็นต้องถามแค่โมเดลเดียวเสมอไป

แต่ต้องออกแบบให้ดี ไม่ใช่เปิดหลายโมเดลแบบสุ่ม

สิ่งที่ production AI ควร log ต่อไปอาจไม่ใช่แค่ model_name แต่รวมถึง:

• requested_model
• served_model
• fallback_reason
• panel_models
• judge_model
• fusion_invoked
• cost_estimate
• latency
• approval_required
• proof_artifact

ถ้าไม่มีข้อมูลพวกนี้ เวลาคำตอบผิด เราจะไม่รู้ว่าผิดจากโมเดลไหน ผิดจาก judge หรือผิดจาก source ที่ค้นมา

ตัวอย่างใช้จริงในธุรกิจไทย

สมมติบริษัทหนึ่งกำลังเลือก CRM ใหม่

ถ้าถามโมเดลเดียว อาจได้คำตอบเรียบร้อย ดูมั่นใจ และมี bullet สวย ๆ

แต่ถ้าเป็น decision ที่กระทบทั้งทีมขาย ทีม support และข้อมูลลูกค้า เราอาจอยากได้หลายมุม:

• โมเดลหนึ่งดู cost และ implementation effort
• โมเดลหนึ่งดู workflow ของทีมขาย
• โมเดลหนึ่งดู risk เรื่อง data/privacy
• โมเดลหนึ่งดู integration กับ LINE, Facebook, form, email
• judge model สรุปว่าจุดไหนเห็นตรงกัน จุดไหนยังขัดกัน และ decision risk อยู่ตรงไหน

ผลลัพธ์แบบนี้ไม่ได้แค่ “ตอบยาวขึ้น” แต่มันช่วยให้เจ้าของธุรกิจเห็น trade-off ก่อนซื้อหรือก่อน deploy

นี่คือจุดที่ผมว่า Fusion น่าสนใจสำหรับ operator มากกว่าสายเล่น benchmark

แล้วควรลอง Fusion ยังไง

ถ้าจะลอง ผมแนะนำให้เริ่มจากงานที่มีลักษณะนี้:

1. คำถามมีหลายมุมมองจริง
2. คำตอบผิดแล้วมีต้นทุน
3. ต้องเทียบ source หรือเทียบตัวเลือก
4. ไม่ใช่งานที่ต้องตอบใน 2 วินาที
5. คนพร้อมอ่าน proof ก่อนใช้ผลลัพธ์

ตัวอย่าง prompt ที่เหมาะ:

• “ช่วยเทียบ 3 ทางเลือกในการทำ AI chatbot สำหรับบริษัท SME ที่ใช้ LINE เป็นหลัก โดยแยก cost, risk, integration, data privacy และ implementation difficulty”
• “ช่วยวิจัยว่าธุรกิจ training ควรเลือกสร้าง learning platform เองหรือใช้ SaaS สำเร็จรูป โดยอ้างอิง source ปัจจุบัน”
• “ช่วยวิเคราะห์ architecture สำหรับ agent ที่อ่านเอกสารลูกค้าได้ แต่ต้องไม่ส่งข้อมูลส่วนตัวออกนอก boundary ที่กำหนด”

ตัวอย่างที่ไม่ค่อยต้องใช้ Fusion:

• “ช่วยเขียน caption สั้น ๆ”
• “สรุป meeting note ภายใน 5 bullet”
• “แปลงข้อความนี้เป็นตาราง”
• “ร่างอีเมล follow-up ธรรมดา”

ใช้ให้ถูกงานครับ ไม่อย่างนั้น Fusion จะกลายเป็นเครื่องเพิ่ม cost ที่ดูฉลาด แต่ไม่ได้เพิ่ม outcome

สรุป

ในความเห็นของผม OpenRouter Fusion ไม่ใช่ข่าวว่า “โมเดลเดี่ยวตายแล้ว”

แต่เป็นข่าวว่า AI stack เริ่มเข้าสู่ยุคที่ต้องออกแบบเหมือนระบบงานจริงมากขึ้น

มีงานที่ต้องเร็ว มีงานที่ต้องถูก มีงานที่ต้องละเอียด มีงานที่ต้องหลายมุม มีงานที่ต้องหยุดรอคน approve

หลังจาก Fable 5 ใช้ไม่ได้ คำถามที่ดีไม่ใช่แค่ “จะใช้โมเดลไหนแทน”

คำถามที่ดีกว่าคือ:

เราจะออกแบบ workflow ให้ไม่พังเมื่อโมเดลหนึ่งหาย และให้ฉลาดขึ้นเมื่องานนั้นควรใช้หลายสมองได้ยังไง?

AI หลายหัวอาจชนะโมเดลตัวท็อปในบางงาน

แต่ธุรกิจที่ชนะจริง จะไม่ใช่ธุรกิจที่มี AI หลายตัวที่สุดครับ

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